FACULDADE FORTIUM LEANDRO MEDEIROS DA SILVA DE LIMA COMPARATIVO ENTRE AS METODOLOGIAS ÁGEIS E AS TRADICIONAIS NO DESENVOLVIMENTO DE SOFTWARE NA ADMINISTRAÇÃO PÚBLICA BRASÍLIA­DF 2015 LEANDRO MEDEIROS DA SILVA DE LIMA Comparativo Entre as Metodologias Ágeis e as Tradicionais no Desenvolvimento de Software na Administração Pública Trabalho de Conclusão de Curso apresentado ao curso de Pós­Graduação em Gestão e Desenvolvimento de Sistemas de Informação da Faculdade Fortium, como requisito parcial para obtenção do título de Especialista em Gestão e Desenvolvimento de Sistemas de Informação. Orientador: MSc. César Augusto Borges de Andrade. BRASÍLIA­DF 2015 LEANDRO MEDEIROS DA SILVA DE LIMA Comparativo Entre as Metodologias Ágeis e as Tradicionais no Desenvolvimento de Software na Administração Pública Trabalho de Conclusão de Curso apresentado ao curso de Pós­Graduação em Gestão e Desenvolvimento de Sistemas de Informação da Faculdade Fortium, como requisito parcial para obtenção do título de Especialista em Gestão e Desenvolvimento de Sistemas de Informação. Aprovado em _____/_____/______. Banca Examinadora _______________________________________________________________ Presidente: Prof. MSc. César Augusto Borges de Andrade - Faculdade Fortium (Orientador) ____________________________________________________________________ Membro Titular: Prof. Dr. Marcio de Carvalho Victorino - Universidade de Brasília _______________________________________________________________ Membro Titular: Prof. MSc. Rômulo Ferreira dos Santos - Faculdade Fortium _______________________________________________________________ Membro Suplente: Prof. MSc. Gleyson Azevedo da Silva - Faculdade Fortium BRASÍLIA­DF 2015 Comparativo Entre as Metodologias Ágeis e as Tradicionais no Desenvolvimento de Software na Administração Pública Leandro Medeiros da S. de Lima Faculdade FORTIUM Especialização em Gestão e Desenvolvimento de Sistemas de Informação SGAS Quadra 616 Módulo 114, Asa Sul ­ Brasília/DF ­ CEP 70.200­760 Abstract. This article deals with the use of agile methodologies by the Federal Public Administration (APF) in software development, considering the characteristics inherent to this sector which differs profoundly from the private sector. The study addresses the concepts of traditional and agile development methodologies and shows a comparison between them. Finally, it should be noted that under the APF was found that to use an agile development methodology, it should be compatible with the current Brazilian legislation, since there is no distortion or loss of the essence of the methodology. Keywords: software process; agile development; tradicional development; public administration Resumo. O presente artigo trata da utilização das metodologias ágeis pela Administração Pública Federal (APF) no desenvolvimento de software, levando em consideração as características inerentes à este setor que diverge profundamente do setor privado. O estudo aborda os conceitos sobre metodologias tradicionais e ágeis de desenvolvimento e faz um comparativo entre elas. Por fim, cumpre ressaltar que no âmbito da APF constatou­se que para se utilizar uma metodologia de desenvolvimento ágil, esta deverá se compatibilizar com a legislação pátria vigente, desde que não haja descaracterização ou perda da essência da metodologia. Palavras­chave: processo de software; desenvolvimento desenvolvimento tradicional; administração pública. ágil; 1. Introdução Em um mercado competitivo, os softwares devem responder de forma rápida às mudanças requeridas por seus usuários, de modo que elas acrescentem valor ao negócio da organização, gerando um diferencial sobre a concorrência. No setor público brasileiro a realidade difere profundamente, haja vista que nesse setor os sistemas devem ser construídos visando ao atendimento do interesse público, levando em consideração os programas e as metas governamentais, o orçamento público e a legislação pátria existentes. Nestes termos, o próprio contexto em que a Administração Pública1 está inserida eleva bastante as restrições impostas à construção de software. Sendo assim, é fundamental um processo de desenvolvimento que aborde necessariamente as boas práticas de mercado, para que os sistemas consigam atender plenamente às expectativas de seus usuários, no prazo, custo e qualidade definidos. Atualmente, existem duas correntes principais para o desenvolvimento de software conhecidas como metodologias tradicionais e metodologias ágeis. A primeira tem por objetivo a construção do software seguindo um modelo de processo definido previamente em etapas, ou seja, a cada estágio do desenvolvimento gera­se um entregável que serve de insumo para o próximo estágio do processo; o software operacional é disponibilizado após a conclusão de todos estes estágios. A segunda visa a construção do software iterativamente, de modo que a cada iteração um produto operacional seja disponibilizado para seus usuários. Neste cenário, ocorre a indagação: qual destas metodologias é a melhor? Como resposta, vários autores apontam que a melhor abordagem para se desenvolver software depende de sua natureza, do contexto no qual ele será desenvolvido e das características da organização como maturidade da equipe, requisitos externos e formas de contrato. Ainda alguns ressaltam, como Sommerville (2011) e Pressman (2011), que a melhor abordagem seria a adoção das melhores características existentes em ambas as metodologias. Considerando a Administração Pública Federal (APF), a aplicação dos métodos ágeis na esfera pública vem sendo, recorrentemente, objeto de estudo do Tribunal de Contas da União (TCU). Nos estudos levantados pelo próprio Tribunal, constatou­se que é viável a aplicação dos métodos ágeis na APF desde que não se deixem de observar os fundamentos legais vigentes. O papel do referido tribunal na APF acerca do tema é fundamental, uma vez que este órgão vem realizando fiscalizações e auditorias em alguns de seus jurisdicionados com o objetivo de estudar a aplicação dessas metodologias na esfera pública federal, como está registrado no relatório TC 010.663/2013­4, com destaque para o Banco Central do Brasil (Bacen) que possui expertise na adoção dessas metodologias. Impende ressaltar que nos termos constitucionais, o TCU é o responsável por realizar o controle externo técnico de modo a fiscalizar nos aspectos contábeis, operacionais, fiscais, organizacionais e patrimoniais o erário público. Ele ainda é responsável por verificar se os recursos públicos estão sendo bem aplicados e da forma mais eficiente possível. Depreende­se daí que, no tocante às metodologias ágeis, esse tribunal estude a forma mais viável e eficiente para a aplicação destas metodologias no âmbito público. De toda forma, o artigo propõe que a utilização destas metodologias são viáveis e importantes na APF para a obtenção da eficiência, da economicidade e da qualidade 1 Segundo Pietro (2011), divide­se em dois sentidos: em sentido objetivo, material ou funcional, a Administração Pública pode ser definida como a atividade concreta e imediata que o Estado desenvolve, sob regime jurídico de direito público, para a consecução dos interesses coletivos. Em sentido subjetivo, formal ou orgânico, pode­se definir Administração Pública, como sendo o conjunto de órgãos e de pessoas jurídicas aos quais a lei atribui o exercício da função administrativa do Estado. dos softwares produzidos para o setor público e no setor público. Neste ínterim, o presente estudo está organizado da seguinte forma: após a introdução, a Seção 2 tem o intuito de esclarecer ao leitor sobre as definições de processo de software e modelo de processo de software. Ainda nesta seção, o artigo aborda os principais modelos de processo utilizados até então, tais como: o modelo sequencial linear, os modelos incrementais, os modelos evolucionários e os modelos especializados, cujas contribuições e dificuldades são apresentadas no decorrer do estudo. Já na Seção 3, é feita uma análise do desenvolvimento ágil abordando a programação extrema e o Scrum, ambos bastante em voga na atualidade. Por fim, segue a Seção de Conclusão na qual trata do desenvolvimento de software na Administração Pública realizando, assim, as considerações finais sobre o estudo. 2. Processos de Software Conforme Pressman (2011), processo é um conjunto de atividades, ações e tarefas realizadas na criação de algum produto de trabalho. De forma análoga, o processo de software é um conjunto de atividades associadas que levam à construção de um produto de software. Esse processo não é uma prescrição rígida, mas é algo adaptável que possibilita a equipe de desenvolvimento selecionar as ações e tarefas mais adequadas para a entrega do software dentro do custo, prazo e qualidade acordados. As atividades dos processos podem variar em quantidade e em nomenclatura a depender do autor que as mencione, porém de forma geral os processos de software possuem quatro atividades fundamentais que são: (1) Especificação de Software – define as necessidades e restrições do sistema, (2) Projeto e Implementação de Software – analisa as necessidades e as restrições do sistema e o constrói baseado nas suas especificações, (3) Validação de Software – garante que o sistema atende ao solicitado pelo cliente e (4) Evolução de Software – estipula que o software deverá estar apto às necessidades de mudança do cliente. Não obstante, os processos de softwares são complexos em si mesmos pois são frutos do intelecto humano e depende das pessoas para tomar decisões e fazer julgamentos. Um processo será mais bem empregado em relação à outro dependendo das características do sistema a ser desenvolvido, portanto não há um processo de software ideal e sim o mais apropriado ou adequado. Por exemplo, sistemas críticos necessitam de um processo de desenvolvimento mais formal, enquanto os sistemas negóciais cujos requisitos são alterados com maior frequência se encaixam melhor numa abordagem menos formal e mais flexível. Importantes autores, como Sommerville (2011) e Pressman (2011), destacam dois tipos de processos de software mais comuns: os processos dirigidos a planos, também conhecidos como processos prescritivos ou processos preceptivos, e os processos ágeis. Os primeiros definem um fluxo de processo previamente acertadas que têm suas atividades definidas com antecedência cujo progresso é avaliado comparando seu andamento atual com o planejamento inicial. Os segundos, são mais flexíveis de modo a facilitar a alteração do processo para atender às necessidades prioritárias dos usuários. Vale lembrar o que menciona Boehm (1988) em que cada abordagem é apropriada para diferentes tipos de software. Geralmente, é necessário encontrar um equilíbrio entre os processos dirigidos a planos e os processos ágeis. Por fim, as organizações buscam adaptá­los à suas realidades e padronizá­los na medida do possível. Isso faz com que seus esforços sejam dispendidos com a melhoria do processo introduzindo novos métodos e técnicas. 2.1. Modelos de Processos de Software Um modelo é uma abstração dos aspectos relevantes de uma realidade. No desenvolvimento de software, existem vários modelos que expressam de forma simplificada o meio pelo qual o software será elaborado de modo que suas atividades pormenorizadas não são destacadas, mas somente o aspecto estrutural do modelo. O presente estudo abordará os modelos tradicionais, também conhecidos como sequencial ou cascata, os incrementais, os evolucionários, os especializados e os ágeis. Os modelos supracitados, embora enfatizem determinados aspectos no desenvolvimento de software não são exclusivos, visto que resultados surpreendentes podem ser obtidos combinado­os em suas melhores características. Por exemplo, suponha que para a construção do software X, um sistema de grande porte com vários subsistemas, seja utilizado o modelo tradicional por conta da melhor visibilidade deste processo cujas etapas são bem definidas. No entanto, pode­se utilizar uma metodologia evolucionária ou um incremental para a construção de seus subsistemas, pois eles estão sujeitos à maior volatilidade dos requisitos do usuário. 2.1.1. Modelo Sequencial Linear ou Cascata O Modelo em Cascata, também chamado de Ciclo de Vida Clássico, foi inicialmente proposto por Winston Royce na década de 70 e continha sete etapas bem definidas. Desde a sua criação, os diversos autores que o abordaram realizaram nele pequenas variações, sejam na quantidade ou no objetivo das etapas, porém a essência deste modelo permanece a mesma. Tal modelo segue um fluxo sequencial linear e suas etapas são distintas uma das outras, elas devem ser previamente planejadas antes do início do trabalho. Desta forma, a etapa posterior não deve iniciar antes que a anterior termine classificando­se, portanto, como dirigido a planos. Contudo, a prática tem demonstrado que essas etapas se sobrepõe em alguns momentos. Na Figura 1 é exibido o Modelo em Cascata mencionado em Sommerville (2011). De acordo com o renomado autor o processo possui cinco etapas: 1. Definição de Requisitos – tem por objetivo estabelecer a compreensão do sistema a ser construído entre usuários e desenvolvedores. Nesta etapa, os requisitos são expostos e as restrições ao sistema estabelecidas; 2. Projeto do Software – tem por objetivo elaborar modelos os quais representam a estrutura do sistema em diversas perspectivas, considerando os aspectos de hardware e software, plataforma de desenvolvimento e ambiente de execução. Em suma, visa estabelecer um projeto de solução do um problema a ser resolvido; 3. Implementação e Teste de Unidades – esta etapa consiste na construção efetiva do sistema e os testes unitários garantem que as funcionalidades do sistema atendem a especificação delas; 4. Integração e Teste de Sistema – as unidades de testes individuais são integradas e são testadas como um sistema completo. Isso garante que as funcionalidades em conjunto representam os requisitos estabelecidos em (1); e 5. Operação e Manutenção – o sistema entra efetivamente em produção2, no qual ele é instalado no ambiente real de uso. Erros podem ser descobertos, e melhorias são identificadas em razão das novas necessidades de seus usuários. Figura 2.1. Modelo em Cascata. Fonte: (SOMMERVILLE, 2011, p.20) A título de comparação a Figura 2 exibe o modelo em cascata definido por Pressman (2011). De acordo esse autor, o modelo também apresenta as cinco etapas sequencializadas, uma iniciando após o término da outra, porém perceba que apenas a nomenclatura diverge da mencionada mencionada na Figura 1, mantendo em essência o modelo proposto por Royce (1970). Em princípio, o referido modelo é recomendado para o desenvolvimento de sistemas cujos requisitos sejam pouco voláteis e, por ser sequencial, sua documentação é produzida a cada fase, desta forma pode­se monitorar o processo conforme o planejado e sua gerência fica facilitada. Essas são as principais vantagens deste modelo. Por exemplo, sistemas com requisitos rígidos de segurança, desempenho e confiabilidade, geralmente, utilizam este processo, pois tais sistemas exigem uma gerência mais rígida sobre o caminhar do desenvolvimento do sistema e exigem requisitos conhecidos e estáveis, logo no início do projeto. 2 Um sistema somente gera valor para seus usuários após sua entrada efetiva em produção. Ao entrar em produção o sistema está em pleno funcionamento no ambiente real de uso. Figura 2.2. Modelo em Cascata. Fonte: (PRESSMAN, 2011, p. 60) No entanto, a maioria dos usuários não conhece logo no início do desenvolvimento todos os requisitos de um sistema, tampouco os conhece em um nível suficientemente apropriado. Portanto, em projetos reais dificilmente os sistemas seguirão o fluxo sequencial estático proposto pelo Modelo em Cascata, além do mais há a dificuldade em se reduzir os riscos do desenvolvimento, pois somente após a publicação do sistema no ambiente real é que os usuários conseguirão avaliar os resultados. Desta forma, o risco de o sistema não contemplar as necessidades dos clientes é alta e de custo elevado. 2.1.2. Modelo Incremental O Modelo Incremental aplica sequências lineares iterativas à medida que o tempo avança, na qual cada incremento adiciona um produto operacional que será entregue ao usuário (Figura­3). Ou seja, este modelo passa por uma sequência de atividades várias vezes até que o sistema seja completamente construído funcionalidade a funcionalidade, incremento a incremento. Figura 2.3­ Modelo Incremental Fonte: (PRESSMAN, 2011, p. 61) Quando comparado ao modelo em cascata, o modelo incremental apresenta as seguintes vantagens: (1) Menor custo para adicionar mudanças; (2) É mais fácil obter feedback do cliente sobre o que já foi implementado; e (3) O software consegue agregar valor ao negócio do cliente mais rapidamente. Todavia de acordo com Sommerville (2011), este tipo de metodologia tende a degradar a estrutura do sistema, pois adicionar novos incrementos torna­se uma tarefa onerosa e difícil sendo necessários, para manter a qualidade do código­fonte, investir tempo e dinheiro com a refatoração constante do código. Um outro problema é a falta de visibilidade do processo para os gerentes, uma vez que se torna inviável a produção de documentos que reflitam as várias versões do sistema. 2.1.3. Modelos Evolucionários Os modelos evolucionários são bastante semelhantes aos modelos incrementais vistos na seção anterior. Ambos são iterativos, porém os primeiros entregam uma versão cada vez mais completa do software, não necessariamente prontos para serem utilizados; e os segundos entregam um produto operacional a cada iteração, ou seja, adicionam um incremento utilizável de software. Na Figura­2.4 pode­se observar uma analogia entre as duas abordagens: na parte superior a abordagem incremental (Incremental plan, em inglês) e na parte inferior a evolucionária (Iterative plan, em inglês). Naquela, observa­se a imagem crescer com a adição de incrementos, seria a analogia com a funcionalidade utilizável do software, até o sistema se tornar completo por inteiro. Ao passo que nessa, a imagem vai se tornando cada vez mais completa no decorrer das iterações. Figura 2.4­ Abordagem Incremental x Abordagem Evolucionária Fonte: http://www.applitude.se Observadas tais diferenças, Pressman (2011) define dois tipos principais de modelos evolucionários: a Prototipação e o Espiral. A prototipação visa ao esclarecimento de dúvidas que os engenheiros de softwares, clientes e desenvolvedores possuem acerca de uma solução de software; e o modelo espiral estabelece um processo que combina aspectos da prototipação com os aspectos sistemáticos e controlados do modelo em cascata, desenvolvendo versões cada vez mais completas do software. A prototipação pode entendida como um paradigma 3. Porém ela é mais comumente utilizada como uma técnica, passível de ser aplicada nos demais modelos supracitados para ajudar a elicitar os requisitos dos stakeholders4, validá­los ou estudar as soluções para um problema específico, como avaliar o desempenho de um algorítimo. De acordo com Sommerville (2011), a prototipação possui cinco etapas que estão demonstradas na Figura­4. Para o referido autor, a etapa – (1) Estabelecer objetivos do protótipo ­, deve estabelecer os objetivos do protótipo logo no início do processo, de tal forma que sua função seja exposta aos principais interessados. Por exemplo, se ele servirá para demonstrar uma interface visual ou o funcionamento de determinada funcionalidade. Já a fase – (2) Definir a funcionalidade do protótipo –, busca­se determinar quais funcionalidades serão demonstradas no protótipo e quais delas não serão contempladas. Essa etapa é importante para a economia dos recursos a serem dispendidos na elaboração do protótipo seja na redução do cronograma, seja na supressão do tratamento dos erros ou no relaxamento dos requisitos não funcionais. Na etapa seguinte, (4) desenvolve­se o protótipo e por último (5) realiza­se uma avaliação afim de descobrir possíveis erros e omissões de requisitos e pontos de melhorias em uma interface. Figura 2.5­ Processo de desenvolvimento de protótipo Fonte: (SOMMERVILLE, 2011, p. 30) Em geral, os protótipos podem ser classificados como exploratórios – que servem para avaliar determinada característica do software e, após isso, são descartados ­, ou evolutivos ­ que podem evoluir até tornar­se um sistema real para o uso. 3 Paradigma, no âmbito da engenharia de software pode ser entendido como a abordagem, um modelo. 4 Stakeholders podem ser definidos como os principais interessados em um software. Podem ser clientes, analistas, gerentes. Por fim, esta abordagem apresenta algumas dificuldades como: 1. Os interessados podem enxergar os protótipos como softwares operacionais. Isto torna­se um problema porque os protótipos, em geral, não são construídos visando o desempenho, a qualidade e segurança de um sistema; 2. Os engenheiros se comprometem a entregá­lo o mais rápido possível, comprometendo a qualidade final do software. Nos termos do Modelo Espiral, inicialmente proposto por Barry Boehm em 1988, o desenvolvimento de software é tratado como uma espiral na qual cada volta nela representa uma fase do desenvolvimento. Nesse sentido, os ciclos mais internos podem verificar a viabilidade do software, os seguintes os requisitos do sistema, os próximos o projeto do sistema, e assim por diante. Uma característica fundamental deste modelo, que o distingue dos demais, é seu tratamento explícito dos riscos ao assumir que as mudanças são resultados dos riscos inatos a todos os projetos. Figura 2.6­ Modelo em Espiral de Boehm Fonte: (SOMMERVILLE, 2011, p. 33) A Figura 2.6 exibe o Modelo em Espiral, nele observa­se uma divisão em quatro setores, sendo que o processo começa no quadrante superior esquerdo e prossegue no sentido horário para os demais quadrantes. Cada quadrante representa uma etapa do processo: 1. Definição de Objetivos. Neste setor os objetivos para essa fase do projeto são levantados, os requisitos elicitados e os riscos são identificados. Em função dos riscos identificados, uma estratégia alternativa pode ser traçada em função deles; 2. Avaliação e Redução dos Riscos. Nesta etapa, cada risco identificado é avaliado e medidas saneadoras são tomadas para a redução ou eliminação destes riscos; 3. Desenvolvimento e Validação. Após a avaliação dos riscos é escolhida uma abordagem para o desenvolvimento do sistema. Caso o projeto tenha seus requisitos bem conhecidos e relativamente estáveis, o modelo em cascata pode ser utilizado, caso o projeto tenha os requisitos instáveis e com riscos elevados, uma abordagem ágil pode ser a melhor opção; e 4. Planejamento. Nesta etapa é realizada uma revisão do projeto e uma decisão é tomada acerca da continuidade ou não dele, caso se opte pelo prosseguimento do projeto, novos planos são elaborados para a fase seguinte. Nas palavras de Pressman (2011): “Este modelo é uma abordagem realista para o desenvolvimento de software em larga escala. Pelo fato de o software evoluir à medida que o processo avança, o desenvolvedor e o cliente compreendem e reagem melhor aos riscos em cada nível evolucionário.” (PRESSMAN, ROGER. 2011. p. 66). Contudo, este modelo pode exige considerável avaliação do risco pois seu fluxo depende disto para que ocorra com sucesso. Um risco ignorado pode se tornar um grande problema caso não seja bem administrado. 2.1.4. Modelos Especializados Dentre os modelos especializados, o que mais se destaca é o Modelo de Desenvolvimento Baseado em Componentes (em inglês, Component­Based Software Engineering – CBSE). Há, ainda, os modelos de métodos formais e os modelos de desenvolvimento de software orientado a aspectos. Porém estes dois últimos não serão abordados por se afastarem demasiadamente do escopo proposto no presente estudo. A CBSE é o processo de definir, implementar, integrar ou compor componentes independentes em sistemas. Componente é uma abstração de software que realiza determinada tarefa específica, mantendo oculto seus detalhes de implementação e lógica negocial e expondo serviços através de interfaces bem definidas às quais são pontos de integração com os sistemas. Por conseguinte, Sommerville (2011) elenca cinco características para melhor definir um componente. Segundo ele, o componente deve ter suas interfaces padronizadas; deve ser independente, visto que não pode depender de outros componentes para sua utilização; deve ser passível de composição; deve ser implantável ou autocontido, significa que ele é capaz de operar de forma autônoma; e deve ser documentado, para que seus potenciais usuários saibam de suas características antes de utilizá­lo. A engenharia baseada em componentes ganhou impulso na década de 90, uma vez que os softwares foram se tornando cada vez mais complexos e, adicionalmente à isso, tiveram seu tempo para desenvolvimento reduzido por exigência de seus clientes. Neste cenário, a única maneira para entregar software complexo, confiável, o mais rápido possível é reutilizar ao invés de reimplementar. Para que a CBSE seja viabilizada, um processo distinto deve ser utilizado. Esse processo, na abordagem de Sommerville (2011) possui as seguintes etapas (Figura 2.7): Figura 2.7­ Ciclo do CSBE Fonte: (SOMMERVILLE, 2011, p. 324) 1. Esboço dos requisitos do sistema. Ao contrário da abordagem incremental para requisitos, neste processo é necessário o maior número possível de requisitos especificados logo no início do desenvolvimento para a identificação do maior número de componentes a serem utilizados; 2. Identificação dos componentes candidatos. Esta etapa envolve uma série de subatividades – buscar os componentes, selecioná­los e validá­los; 3. Modificação dos requisitos de acordo com os componentes descobertos. Nesta etapa, os requisitos são refinados e modificados para se adequarem aos componentes disponíveis e àqueles não atendidos são renegociados ou descartados; 4. Projeto de arquitetura. É a etapa para se refinar os componentes escolhidos, uma vez que eles podem não trabalhar corretamente ou apresentar problemas de integração quando utilizados juntos num mesmo sistema; 5. Identificação dos componentes candidatos. Escolha de alguns outros componentes ou substituição dos que já foram escolhidos, caso seja necessário; e 6. Composição dos componentes para criação dos sistemas. Trata­se da integração dos componentes. Nesta etapa pode ser necessário adaptar as interfaces destes componentes através da geração de códigos próprios do sistema. Esta abordagem é bastante útil, uma vez o reúso de software acontece independentemente da metodologia escolhida. Por isso é uma recomendação que os softwares sejam projetados visando à utilização de componentes. Isso produz como benefícios o aumento da qualidade do sistema, o aumento da produtividade e a redução dos custos globais do sistema. Porque ao reutilizar um componente, evita­se que novos códigos sejam produzidos nos quais poderiam introduzir novos erros no software que elevariam os custos do projeto e reduziriam a confiabilidade do sistema como um todo. Por fim, podem ocorrer situações nas quais o cliente não aceita a mudança de seus requisitos para se utilizar um determinado componente. Porém eles estão dispostos a mudar de opinião caso isso se comprove uma forma mais barata ou mais rápida de se entregar o sistema. 3. Desenvolvimento Ágil A abordagem ágil surgiu como uma alternativa à forma de se desenvolver software tradicionalmente. A necessidade de respostas rápidas às mudanças em requisitos negociais e a diminuição no custo destas mudanças fizeram com que, no início da década de 1990, os métodos ágeis se popularizassem nos centros de desenvolvimento de software. Figura 3.1­ Custo das alterações em função do tempo de desenvolvimento Fonte: (PRESSMAN, 2011, p. 83) Na Figura 3.1, pode­se observar o custo do desenvolvimento comparando­se processos convencionais e processos ágeis de software. Segundo Pressman (2011), o custo cresce rapidamente ao efetuar uma mudança num requisito do sistema utilizando a abordagem convencional, porque ela impacta diretamente nas outras etapas da cadeia de desenvolvimento como o planejamento, análise e projeto, codificação e testes. Ao contrário, com a utilização dos métodos ágeis, a curva do custo da mudança é “achatada” pois a entrega incremental reduz o risco de incertezas acerca do projeto e prepara a equipe a assimilar as mudanças posteriores de forma que não gere impactos significativos nos custos ou no tempo do projeto. Para um método de desenvolvimento ser considerado ágil, existem diversas características que podem ser mencionadas. Dentre elas Sommerville (2011) realça que desenvolvimento ágil é aquele que produz software de forma rápida em uma série de incrementos, onde cada incremento possui uma nova funcionalidade útil ao usuário e cujo tempo de desenvolvimento leve de duas a três semanas. O autor ainda enumera algumas características comuns às metodologias ágeis, tais como: 1. Desenvolvimento incremental; 2. Planejamento, especificação e projeto intercalados, nos quais são elaborados o mais simples possível que atenda à necessidade do usuário; 3. Documentação reduzida ao mínimo necessário; e 4. Utilização de ferramentas para a geração das interfaces visuais. como: Já para Abrahamsson (2002), algumas outras características são mencionadas 1. Modularidade no desenvolvimento; 2. Iteratividade com ciclos curtos e de duração fixa, com verificações e correções rápidas; 3. Priorizar pessoas à processos e tecnologia; e 4. Colaboração e comunicação como formas de trabalho. Em suma, ambos os autores mencionam características análogas umas às outras que servem de norte às metodologias ágeis de desenvolvimento como o XP – Extreme Programming. 3.1. XP ­ Programação Extrema Atualmente, o XP (Programação Extrema, em português) é uma das metodologias mais populares de desenvolvimento de código cuja orientação filosófica proveio do Manifesto Ágil5. Elaborado por Kent Beck na década de 1990, o XP busca desenvolver softwares de maior qualidade, de forma mais econômica e produzidos em menos tempo que as formas tradicionais. Isso, portanto, é alcançado por de um conjunto de princípios, práticas e valores nos quais diferenciam o XP das metodologias tradicionais. No processo XP – Figura 3.2 ­, os clientes estão intimamente envolvidos na especificação do software e fazem parte da equipe. As necessidades deles são levantadas em cenários conhecidos como “histórias de usuário” e são descritas em 5 O Manifesto Ágil, criado em 2001 nos Estados Unidos, é uma fonte de princípios que norteia as metodologias ágeis para o desenvolvimento de software, elaborado por profissionais de software que buscavam elevar o desempenho de seus projetos. cartões CRC6 (Classe­Responsabilidade­Colaborador). Após este levantamento os clientes priorizam as suas necessidades mais urgentes e importantes que serão enviadas à equipe de desenvolvimento. Nessa equipe, as histórias são transformadas em tarefas menores e um conjunto de testes são elaborados antes mesmo da implementação concreta da funcionalidade. Ao ser construída, a nova funcionalidade é integrada às demais e, à medida que novas vão sendo desenvolvidas, todos os testes são executados para garantir que não houve quebra das funcionalidades já existes. Quando todas as tarefas previstas são concluídas, um release7 é disponibilizado ao cliente para avaliação. É importante observar que o tempo para a disponibilização de um release seja pequeno permanecendo de duas a quatro semanas. Figura 3.2­ Ciclo de vida de um release em Extreme Programming Fonte: (SOMMERVILLE, 2011, p. 44) Obviamente que o sucesso do processo depende de um conjunto de boas práticas, sem as quais não seria possível o uso do XP. As principais, segundo Beck (1999), são: 1. Jogo do planejamento. Os clientes decidem o escopo da próxima iteração baseado nas estimativas fornecidas pelos programadores. Eles implementarão apenas as funcionalidades exigidas na história desta iteração. 2. Pequenas releases. O sistema é colocado em produção dentro de alguns meses antes de resolver todos os problemas. Novas releases são liberadas diariamente e depois, mensalmente. 3. Metáforas. O sistema é definido através de metáforas que são compartilhadas entre clientes e programadores. 4. Projeto simples. A todo momento o projeto executa todos os testes que garantem que o projeto não contém códigos duplicados e está na sua forma mais simples possível. 6 Os cartões CRC são os únicos artefatos produzidos durante o processo XP. 7 Um release é o fim de um ciclo de desenvolvimento, a entrega final de uma versão de produto ou a versão de software que o cliente irá utilizar. 5. Testes. Os programadores elaboram os testes de unidade que devem funcionar corretamente e os clientes elaboram os testes de aceitação nos quais formam os critérios de aceitação do software. 6. Refatoração. Ela garante que a estrutura do sistema não se degrade com a adição de novas funcionalidades. 7. Programação em pares. Toda a produção do código é feita por duas pessoas utilizando o mesmo monitor, o mesmo mouse e o mesmo teclado. 8. Integração contínua. O código é integrado ao sistema corrente várias vezes por dia e, ao integrá­lo, o sistema é construído do zero. Portanto, todos os testes devem passar ou as modificações são descartadas. 9. Propriedade coletiva do código. Todo programador pode melhor qualquer código do sistema a qualquer momento. 10. Cliente sempre disponível no local. O cliente está disponível a todo momento. 11. Semanas com 40 horas semanais. Ninguém pode trabalhar na segunda semana consecutiva com horas­extras. 12. Horas­extras com frequência são sinais de problemas profundos. Tendo em vista tais práticas, de nada elas serviriam quando utilizadas isoladamente, alheias à realidade da organização ou da equipe de desenvolvimento. Ainda conforme o autor, ele estabelece cinco valores – comunicação, simplicidade, feedback, coragem e respeito ­, que servem para direcionar para as atividades, ações e tarefas específicas da XP. Sendo a primeira delas a comunicação, o XP tem o objetivo de mantê­la fluindo através do emprego das práticas, nas quais não podem realizadas sem a comunicação. Sem dúvida, ela não está limitada a meros procedimentos formais e se utiliza, portanto, o melhor meio possível para viabilizá­la como uma conversa informal, diagramas ou, até mesmo, o próprio código. O segundo valor, a simplicidade, restringe os desenvolvedores a projetarem para as necessidades imediatas, ou seja, para a solução mais simples que funcione neste momento. O feedback é o terceiro valor da XP. Este valor garante que respostas rápidas sejam enviadas em várias etapas do processo. Para o desenvolvedor, seu feedback são os testes unitários; para os clientes e testadores, os testes funcionais. Coragem, o quarto valor, é gerada a partir das práticas do XP. Tendo em vista que elas aumentam a confiança do desenvolvedor, ele tará a coragem suficiente para manter o código ou corrigir algum erro do sistema. O quinto valor, respeito, é gerado quando se entrega com sucesso os incrementos de software. Desta forma, gera­se respeito entre os membros da equipe e entre os demais envolvidos, culminando no respeito ao próprio XP. É interessante notar que a abordagem ágil, bem como os demais processos de software supracitados no presente estudo, não se aplica a todas as situações indistintamente. Há situações em que um processo formal é mais oportuna que a abordagem ágil, pois alguns softwares podem apresentar requisitos críticos para o sucesso do projeto nos quais exigem um maior controle para sua definição. De toda forma, é fato que a metodologia ágil vem tomando espaço ao longo dos anos principalmente nos projetos pequenos ou médios, cujos requisitos sejam voláteis e estejam num ambiente negocial onde a resposta a mudança é mais interessante que a garantia dos requisitos. Por fim, Sommerville (2011) aponta algumas características que dificulta a adoção da abordagem ágil pelas empresas. Pode ser difícil manter um cliente disponível durante todo o processo de desenvolvimento, uma vez que o cronograma dele pode­se diferenciar do cronograma da equipe de desenvolvimento. Outro problema é que alguns dos membros da equipe podem não ter a personalidade adequada à tal metodologia, e priorizar as mudanças pode ser extremamente oneroso, principalmente quando um sistema possui vários stakeholders onde cada um deles prioriza diferentemente cada mudança. 3.2. Scrum Originado na década de 1990 e criado por Ken Shwaber e Jeff Sutherland, o Scrum é um framework8 simples no qual as pessoas utilizam para resolver problemas complexos e adaptativos, enquanto criam e entregam produtos de qualidade. Apesar de sua simplicidade e fácil entendimento, é extremamente difícil de dominar este framework. Com raízes na teoria empírica9 para o controle do processo de desenvolvimento, três pilares são fundamentais para o Scrum: transparência, inspeção e adaptação. O primeiro deles transparência, significa que aspectos relevantes do processo devem ser expostos a todos os responsáveis de forma clara, inequívoca e definidos por um padrão comum para que os responsáveis compartilhem do mesmo entendimento sobre algo. O segundo, inspeção, serve para averiguar se não há variações indesejadas nos artefatos do Scrum ou se progresso do trabalho está caminhando conforme o esperado. O terceiro, adaptação, sugere que os artefatos desviados de seus objetivos devam ser corrigidos o quanto antes para se evitar maiores problemas. O Scrum não é um um processo nem uma técnica, mas é uma estrutura processual que suporta o desenvolvimento de produtos complexos. Por conseguinte, apresenta uma abordagem coerente com os conceitos de agilidade definidos até então no Manifesto Ágil. Logo, ele consiste em equipes associadas a papéis, eventos, artefatos e regras cada qual cumprindo com seu devido propósito e unidos através de regras. Para uma melhor didática acerca deste framework, serão abordados os conceitos na seguinte ordem: 1. Papéis; 2. Eventos; e 8 Framework pode ser entendido como uma estrutura de suporte ao desenvolvimento de software. 9 O empirismo, em suma, é uma teoria na qual prega que o conhecimento provém da experiência e a tomada de decisões, por sua vez, é baseada naquilo em que se conhece. 3. Artefatos. As regras estarão diluídas no transcorrer destes conceitos. De todo modo, a Figura 3.3 exibe o funcionamento do Scrum, na qual exibe um esquema para facilitar o entendimento. 3.2.1. Papéis Os papéis no Scrum são claros e definidos e possuem características próprias que garantem o sucesso do framewok. Juntos eles formam o Time Scrum que, uma vez formados, são auto­organizáveis e multifuncionais, são responsáveis por entregar o produto em funcionamento, têm liberdade para escolher a melhor forma de entrega do trabalho e possuem todas as competências necessárias para a conclusão do trabalho. Os papéis são: 1. Product Owner (PO) ou Dono do Produto. É o único responsável por definir as funcionalidades do produto e priorizá­las dentro do Backlog do Produto – uma lista priorizada de necessidades. Nesta lista de tarefas o PO pode alterar prioridades ou redefinir tarefas. 2. Scrum Master. É o responsável por intercambiar os interesses do PO, da Equipe de Desenvolvimento e da Organização, ou seja, é um facilitador do time Scrum que remove impedimentos. Dentre suas principais competências, estão as de promover e aplicar corretamente o Scrum na organização. 3. Equipe de Desenvolvimento. Essa equipe é mais que um conjunto de pessoas ou um papel. É aquela que efetivamente cria incrementos funcionais de software. Tem a característica de ser auto­organizada e multifuncional ao ponto de não ser pequena demais nem grande demais. Figura 3.3­ Ciclo de Vida do Scrum Fonte: http://www.projectprime.com.br 3.2.2. Eventos Os eventos no Scrum são os responsáveis por garantir os princípios da transparência, da inspeção e da adaptação nos quais ele se fundamenta. Os eventos têm uma duração máxima e são realizados com no intuito de reduzir o número de reuniões não previstas, garantindo uma quantidade adequada de tempo gasto no planejamento. Sprint é o evento principal do Scrum. Ela é um período de tempo no qual um incremento funcional de software é produzido, possui duração fixa e é iniciada após o término da sprint anterior. As sprints são compostas pelas quatro reuniões a seguir: 1. Planejamento. A reunião de planejamento é o passo inicial da sprint (Figura 3.3) onde são planejados os trabalhos que serão entregues no fim do ciclo e são descritos os modos de execução desses trabalhos. Essa reunião possui dois períodos: o primeiro para definir a meta da sprint que é baseada no Backlog do Produto; o segundo, é a seleção de tarefas do Backlog do Produto cuja execução cabem em uma sprint. Essa seleção forma um outra lista chamada de Backlog da Sprint. 2. Diária. A reunião diária serve para a equipe de desenvolvimento alinhar as atividades que estão sendo realizadas na sprint. Esta reunião tem o objetivo de inspecionar o trabalho realizado e verificar o que foi feito desde a última reunião diária, o que está sendo feito e o que será feito até a próxima reunião diária. Desta forma a equipe de desenvolvimento pode se auto­organizar para manter o trabalho nos trilhos caso ele venha a se desviar. 3. Revisão. A reunião de revisão da sprint serve para o time scrum avaliar os pontos positivos e negativos ocorridos durante a sprint e demonstrar o incremento de software entregue. Nessa reunião o Backlog do Produto é ajustado para a próxima sprint. 4. Retrospectiva. A reunião de retrospectiva serve para o time scrum inspecionar­se a si mesmo. Com base nisso, é elaborado um plano de melhorias para o trabalho ser realizado de forma mais eficiente e com maior qualidade na próxima sprint. Por fim, mudanças não são admitidas na sprint em execução. Caso surjam mudanças, elas serão consideradas somente na próxima sprint. Contudo, caso achar necessário, o PO pode determinar o cancelamento dela alegando, por exemplo, que seus objetivos não serão cumpridos. 3.2.3. Artefatos Os artefatos no Scrum são definidos para que colaborem com a transmissão das informações chave necessárias para a entrega do incremento de software. Nele são definidos dois tipos de artefatos: Backlog do Produto e Backlog da Sprint. 1. Backlog do Produdo. É uma lista ordenada de todas as necessidades do PO e a única fonte de requisitos do software. Os itens desta lista possuem atributos como descrição, ordem e estimativa; e estão ordenados por suas características como valor, risco, prioridade e necessidade. Nesta lista, quanto mais ao topo ele estiver um item, maior será sua prioridade, e quanto mais ao fim da lista, menor é a sua prioridade. Depreende­se disto dois fatos: o primeiro é de que os itens prioritários serão mais detalhados, ao passo que os itens de prioridade baixa terão poucos detalhes. 2. Backlog da Sprint. É uma lista gerada a partir do Backlog do Produto com determinados itens selecionados que definem o trabalho necessário para a entrega do incremento funcional de software, com uma diferença fundamental do backlog anterior: o backlog da sprint pode ser alterado durante a execução dela pela equipe de desenvolvimento. Por fim, o Scrum ainda define mais dois conceitos importantes para o framework que é a definição de “pronto” e a definição de “incremento”: esse é a soma de todos os itens construídos na sprint atual e nas sprints anteriores, desde que sejam utilizáveis; aquele é o entendimento compartilhado por todos do time acerca do trabalho, ou seja, todos devem saber exatamente o que será considerado como trabalho pronto. 4. Administração Pública e o Desenvolvimento de Software A crescente popularização dos métodos ágeis para o desenvolvimento de software, tanto no mercado nacional quanto no mercado internacional, tem suscitado o interesse da APF quanto à adoção destes métodos. Esse interesse, somado às constantes insatisfações e frustrações com os softwares entregues até então por meio do desenvolvimento tradicional, levou o Tribunal de Contas da União (TCU) 10 a realizar um importante estudo acerca da adoção das metodologias ágeis nas instituições públicas federais. No ano de 2013, o tribunal realizou uma fiscalização expressa no relatório TC 010.663/2013­4, sobre a viabilidade de adoção das metodologias ágeis por órgãos da APF. A fiscalização consistiu em análises feitas por meio dos contratos administrativos entre algumas instituições públicas federais e empresas terceirizadas. Nesta fiscalização, o tribunal buscou investigar como esses órgãos celebravam seus contratos com as empresas terceirizadas, à luz da legislação nacional, adotando os métodos ágeis. Adicionalmente, diversos riscos a que estes órgãos estão sujeitos ao realizar este tipo de contratação foram identificados. Dentre os órgãos que se destacaram na tentativa de aplicação das metodologias ágeis, de acordo com o TCU, foram: Tribunal Superior do Trabalho (TST); Banco Central do Brasil (Bacen); Instituto do Patrimônio Histórico e Artístico Nacional (Iphan), Instituto Nacional de Estudos e pesquisas Educacionais Anísio Teixeira (Inep) e Supremo Tribunal Federal (STF). Embora em nenhum dos citados tenha se observado a aplicação dessas metodologias em sua totalidade, mas se identificou um constante esforço para compatibilizá­las com a legislação do país. De forma exemplificativa e de acordo com o relatório, para o planejamento do produto das entidades supracitadas o framework Scrum foi utilizado. Quanto à aceitação do produto, o framework estipula que deva haver uma reunião de revisão da sprint, porém essa prática não é executada por força da Lei de Licitações e Contratos 8.666/1993, art. 73. Nisso as instituições verificam se os artefatos exigidos contratualmente foram entregues e, assim, fica caracterizada a entrega provisória do produto no lugar da sprint de revisão. Já o TST afasta­se dos princípios do Scrum ao tolerar atrasos na entrega do produto. Sendo que para o Scrum uma sprint tem duração fixa e deve ser executada no prazo estabelecido, se porventura houver possibilidade de atrasos o escopo da sprint deverá ser reduzido. O tribunal, também, elencou alguns riscos inerentes a tais contratações a que estão submetidos os órgãos quando desenvolvem software utilizando as metodologias ágeis. Ele ainda destaca que alguns dos riscos expostos não são exclusivos dos métodos ágeis, podendo ocorrer também ao se utilizar os métodos tradicionais de desenvolvimento de software. Não obstante, esses riscos elencados podem trazer sérios prejuízos à instituição como diminuição da competitividade da licitação, conflitos entre instituição e empresa contratada, entrega de produtos de baixa qualidade e, o mais grave, prejuízo ao erário. Didaticamente, o acórdão citado divide os riscos em três categorias: processos, pessoas e produtos. Os primeiros podem distorcer a essência da metodologia ágil, no início ou durante a execução do contrato; pode exigir artefatos desnecessários ou que se tornem obsoletos rapidamente; ou, ainda, elaborar um contrato de desenvolvimento tradicional de software e, na prática, utilizar métodos ágeis. Os segundos tratam dos 10 Nos termos constitucionais, o TCU é o responsável por realizar fiscalizações e auditorias em qualquer instituição que, de alguma forma, envolva recursos públicos da União. riscos relativos às pessoas como a falta de comprometimento ou colaboração do Product Owner (PO) com o desenvolvimento do software; a equipe da empresa contrata não ter a expertise para o desenvolvimento ágil; e dificuldades de comunicação entre o PO e a equipe de desenvolvimento. Por último, os riscos envolvendo os produtos referem­se às alterações constantes da lista de funcionalidades; pagamento pela mesma funcionalidade mais de uma vez, pois algumas funcionalidades são impossíveis de se implementar em um único ciclo; e a falta do planejamento adequado do software a ser construído. De todo modo, as metodologias de desenvolvimento de software – sejam tradicionais ou sejam ágeis ­, apresentam pontos fortes e fracos devendo ser consideradas em um contexto específico. No contexto da APF, há de se compatibilizar as metodologias ágeis com os princípios legais vigentes, para poder aplicá­las e extrair delas todos os seus benefícios. Por fim, apesar do estudo feito pelo TCU, ele deixa claro que maiores estudos são necessários para identificar os riscos de forma mais precisa visando uma melhor orientação acerca do tema a seus jurisdicionados. 5. Conclusão O setor público e o privado diferem profundamente. No entanto, há certas características visadas que lhes são comuns, como: a eficiência, a qualidade, a produtividade e a redução dos gastos. No que tange ao desenvolvimento de software, a abordagem ágil se popularizou e se tornou protagonista em grande parte do cenário mundial de desenvolvimento de sistemas. Um fluxo iniciado na iniciativa privada que, posteriormente, adentrou as administrações governamentais. Por isso, ao longo deste trabalho, abordou­se uma forma de demonstrar as metodologias de desenvolvimento de software mais utilizadas ao longo do tempo, desde o modelo sequencial linear até a abordagem ágil, enfatizando suas principais características positivas e negativas. Por sua vez, este estudo propôs uma solução para o uso das metodologias e processos ágeis na Administração Pública Federal (APF), que resulta na harmonização das metodologias ágeis com a legislação existente de modo que as metodologias não sejam descaracterizadas e nem as leis desrespeitadas. Por fim, com base nesta pesquisa, conclui­se pela viabilidade da adoção das práticas e metodologias ágeis na APF, pois elas demonstraram ser mais aplicáveis a softwares negociais com requisitos de alta volatilidade que necessitem de um retorno rápido, mesmo que o software não esteja totalmente concluído. Vale ainda esclarecer que a abordagem ágil na APF é um tema recente que carece de maiores estudos para se alcançar resultados mais profundos. Com isso, deve­se levar em consideração que algumas práticas ágeis não se adéquam inteiramente ao setor público, haja vista que tal setor conta com demasiada burocracia e exige um alto grau de formalidade em seus processos. Referências ABRAHAMSSON, PEKKA; SALO, OUTI; RONKAINEN, JUSSI. Agile Software Development Methods: Review and Analysis. University of Oulu. Espoo. p. 18­27. 2002. BOHEM, BARRY W. A Spiral Model of Software Development and Enhancement. IEEE Computer Society. p. 61­72. 1988. BECK, KENT. Extreme Programming Explained: Embrace Change. Addison­ Wesley Professional. p. 42­46. 1999. SCHWABER, KEN. SUTHERLAND, JEFF. Guia do Scrum: Um Guia definitivo para Scrum: As Regras do Jogo. Scrum.Org and ScrumInc. Disponível em: <http://www.scrumguides.org/>. Acesso em 24 de jan. 2015. ROYCE, W. Managing The Development Of Large Software Systems. Los Angeles. USA. Technical Papers of Western Electronic Show and Convention (WesCon). p. 1­11. 1970. PRESSMAN, ROGER S. Engenharia de Software: Uma Abordagem Profissional. 7 ed. McGraw­Hill. p.53­78 .2011. SOMMERVILLE, IAN. Engenharia de Software. 9 ed. Pearson. p.4­11. p. 38­57. 2011. TRIBUNAL DE CONTAS DA UNIÃO. Levantamento Sobre Aplicação de Metodologias Ágeis em Desenvolvimento de Software. Disponível em: <http://portal2.tcu.gov.br/portal/page/portal/TCU/imprensa/trabalhos_em_destaque/ TECNOLOGIA_INFORMA%C3%87%C3%83O_Levantamento%20Sobre%20a %20Aplica%C3%A7%C3%A3o.pdf>. Acesso em 24 de jan. 2015. TRIBUNAL DE CONTAS DA UNIÃO. Acórdão 2.314/2013 Ata 33 – Plenário. Disponível em: <https://contas.tcu.gov.br/juris/Web/Juris/ConsultarTextual2/Jurisprudencia.faces? colegiado=PLENARIO&numeroAcordao=2314&anoAcordao=2013>. Acesso em 24 de jan. 2015. GABARDO, MARCO AURÉLIO; GOMES, ALEXANDRE RODRIGUES. Discussão sobre Motivação de Equipes na Implementação de Métodos Ágeis no Desenvolvimento de Sistemas na Administração Pública Federal. Fundação Universa–Universidade Católica de Brasília. Brasil. DF. Brasília. p.1­17. 2009. PIETRO, MARIA SYLVIA ZANELLA DI. Direito Administrativo. 27 ed. Atlas. p.49­60. 2014.