Metodologias de desenvolvimento ágil de softwares

Informática

21/04/2015

Resumo

Os métodos ágeis possuem como objetivo fornecer aumento na produtividade e aplica-se melhor em equipes de pequeno e médio porte, isso porque os métodos ágeis apresentam falhas em alguns pontos, por exemplo: integração complexa de vários sistemas de software e a separação física das equipes de desenvolvimento. Métodos ágeis enfatizam comunicações em tempo real, a documentos escritos. A maioria dos componentes de um grupo ágil deve estar agrupada em uma sala.


Isso inclui todas as pessoas necessárias para terminar o software: no mínimo, os programadores e seus clientes. Nesta sala devem também se encontrar os testadores, projetistas de iteração, redatores técnicos e gerentes. Métodos Ágeis são algumas vezes caracterizados como o oposto de metodologias guiadas pelo planejamento ou disciplinadas. Embora os métodos ágeis apresentem diferenças entre suas práticas, eles compartilham inúmeras características em comum, incluindo o desenvolvimento iterativo, e um foco na comunicação interativa e na redução do esforço empregado em situações intermediárias. O desenvolvimento ágil, assim como qualquer metodologia de software, oferece uma estrutura conceitual para embasar projetos de engenharia de software. Grande parte dos métodos ágeis tenta diminuir o risco pelo desenvolvimento do software. Assim sendo através de um levantamento bibliográfico entende-se que no cenário atual as metodologias de desenvolvimento ágil tonaram-se importantes para definir uma vantagem competitiva, contudo precisam melhorar em alguns aspectos.


1 Introdução

Por meio de uma análise bibliográfica será apresentado à importância do método ágil para o crescimento de qualquer modelo de negócio, com o passar do tempo à carga de informação obteve um crescimento exponencial e continua crescendo a cada dia. Assim sendo encontrar meios ágeis para gerenciar o grande volume de informação é fundamental.


Como exemplo podemos estabelecer uma comparação com o comercio realizado em tempos passados onde toda a informação do cliente era geralmente arquivada em uma pequena caderneta, esse método foi e ainda continua sendo praticado por algumas pessoas.


Com isso temos poucas informações sobre o cliente impossibilitando traçar um perfil desse cliente para persuadi-lo com novos produtos ou tendências, é justamente isso que os sistemas computadorizados oferecem controle de todas as informações de todos os clientes, podendo assim ter conhecimento de quais produtos foram mais vendidos, qual é a preferência de cada cliente, quando esse cliente poderá voltar, enfim as possibilidades oferecidas superam qualquer método de controle manual, pois além de armazenar as informações é possível processa-las e obter resultados comparativos importantes para qualquer plano de ação.


Para conseguir uma ferramenta que forneça esse tipo de controle é necessário criar um sistema computadorizado adaptado ao modelo de negócio, e devido ao elevado nível de abstração desenvolver esse sistema demanda tempo e investimento, muitas vezes os prazos estabelecidos são estendidos e consequentemente os custos elevados. Os métodos ágeis foram criados para oferecer uma criação rápida e de qualidade possibilitando o comprimento dos prazos e orçamentos.


Segundo Borborema (2007) existe várias metodologias ágeis, neste artigo será enfatizado o Extreme Programming, desenvolvida por Kent Beck em 1997 requisitada em projeto pela Chrysler (fabricante de veículos norte-americana). É uma técnica eficaz, que possui uma série de conceitos e ações, viabilizando aos desenvolvedores trabalhar ativamente, sem deixar de lado aspectos como orçamento e qualidade de software.


Como parâmetro de comparação para o desenvolvimento de software, vamos utilizar especificamente a engenharia civil, ao pensar em construir qualquer obra, os engenheiros colocam a sua disposição anos de trabalho e experiências, a obra não é iniciada antes que a concepção do projeto esteja terminada, os desenvolvedores de softwares a anos tentam construir tendo como termo de comparação a construção civil, a complicação é que os requisitos do sistema software sofrem mudanças, não importando sua dimensão (MEDEIROS, 2006).

As metodologias ágeis sofrem variações em ações e ênfase, contudo, compartilham certas características, tais como: desenvolvimento iterativo e incremental, comunicação e redução de produtos intermediários, documentação extensiva (KOSCIANSKI E SOARES, 2006). A pressão para manter a entrega dentro do prazo e ainda garantir a qualidade levou a criação de metodologias de desenvolvimento de softwares que tem por função melhorar o processo de criação, as operações de negócios em ambientes globais estão sujeitos a rápidas mudanças, é preciso responder rapidamente as novas oportunidades e mercados, alterações de condições econômicas e ao surgimento de produtos e serviços concorrentes (MEDEIROS, 2006).


Quase toda a operação de negócio está embasada em software, sendo assim é essencial o desenvolvimento rápido para aproveitar as novas oportunidades e responder as pressões competitivas. Segundo Medeiros (2006) o desenvolvimento e entrega rápidas são, portanto, muitas vezes o requisito mais importante para sistemas de software, dessa forma muitos negócios estão dispostos a equilibrar a qualidade e compromisso com requisitos do software com a entrega rápida. A construção de sistemas de software baseadas em especificações completas de requisitos, projeto, construção e teste de sistemas está fora da metodologia de desenvolvimento ágil, ou seja, quanto os requisitos mudam ou quando problemas são descobertos, e o projeto de sistema precisa ser retrabalhado.


Dessa forma um processo em cascata convencional ou baseado em especificações é geralmente prolongado e o software final é entregue para o cliente muito depois de ter sido originalmente especificado, para um ambiente de negócios de rápidas mudanças, o método convencional pode causar graves problemas, ao concluir o projeto do software a razão original para sua aquisição pode ter mudado tão radicalmente que o mesmo poderá ser inútil. Portanto, para sistemas de negócios específicos, processos de desenvolvimento voltados para criação rápida são fundamentais.


De acordo com Pressman (2006) a “Agilidade” tornou-se indispensável ao descrever um processo moderno de software, ou seja, tudo deve ser ágil. Uma equipe ágil dever ser capaz de responder adequadamente as possíveis modificações solicitadas, que envolve o desenvolvimento de software, como as regras de negócios mudança de membros da equipe, novas tecnologias; entre outras.


Os métodos de criação rápida de software foram projetados para desenvolver um software útil em pouco tempo, em grande parte são processo iterativos nos quais os requisitos, o projeto o desenvolvimento e o teste são intercalados (MEDEIROS, 2006). O software não é criado e disponibilizado integralmente, mas em uma série de incrementos, e cada incremento inclui uma nova funcionalidade do sistema, contudo as metodologias de desenvolvimento rápido de software compartilham algumas características fundamentais: como o processo de especificações, projeto e implementações são concorrentes, o sistema é desenvolvido em uma série de incrementos e a interface é desenvolvida usando-se um sistema de desenvolvimento interativo.


Um dos princípios da metodologia ágil de desenvolvimento é o envolvimento dos clientes que devem se aprofundar no processo de desenvolvimento, seu papel é fornecer e priorizar novos requisitos do sistema e avaliar as iterações do sistema. O software é desenvolvimento em incrementos e o cliente especifica os requisitos a serem incluídos em cada incremento. As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas, os membros da equipe devem desenvolver suas próprias maneiras de trabalhar sem processos preescritivos. Aceitar as mudanças dos requisitos do sistema e adaptar as alterações, concentrar-se na simplicidade do software que está sendo desenvolvido e do processo desenvolvimento.
2 Métodos ágeis

Segundo Koscianski e Soares (2006) a ideia principal do Manifesto Ágil é primeiro, Indivíduos e interações ao invés de processos e ferramentas, segundo, software executável ao invés de documentação, terceiro, colaboração do cliente ao invés de negociação de contratos e quarto, respostas rápidas a mudanças ao invés de seguir planos. De acordo com os autores, o Manifesto Ágil não exclui os processos e ferramentas, a documentação, a negociação de contratos ou o planejamento, simplesmente atribui uma importância secundária quando comparados com os elementos humanos do projeto, desenvolvedores e clientes e a rápida disponibilização de um software executável, de acordo com a necessidade do cliente.


A realidade dos princípios básicos dos métodos ágeis pode ser complicada de compreender: Enquanto a ideia de envolvimento do cliente no processo de criação é pertinente, para dar certo é preciso de um cliente disposto e apto e ceder tempo para a equipe de desenvolvimento e que possa representar todos os stakeholders, é comum que os representantes do cliente fiquem sujeito a outras pressões e não possam participar totalmente do desenvolvimento do software (SOMMERVILLE, 2007). Nesta etapa é importante deixar claro para o cliente que sua participação será fundamental para adequação do software as suas necessidades.


As vontades dos membros da equipe podem ser incompatíveis para o envolvimento intenso típico dos métodos ágeis, eles podem não interagir bem entre si (SOMMERVILLE, 2007). Assim sendo cabe ao gerente do projeto analisar e entender o perfil de cada integrante da equipe dessa forma será possível delegar funções de acordo com a personalidade de cada um. Sommerville (2007) informa que priorizar mudanças é uma tarefa difícil, especialmente em sistema em que há muitos stakeholders, em geral cada um adota diferentes prioridades e manter a simplicidade gera um trabalho extra, sob a pressão dos cronogramas de entrega, os membros da equipe podem não ter tempo de realizar as simplificações desejáveis no sistema.


Um problema geral no desenvolvimento de entrega incremental ocorre quando:
O cliente usa organização externa para o desenvolvimento do sistema. A lista de requisitos de software é geralmente parte do contrato entre o cliente e o fornecedor. Devido à especificação incremental ser inerente aos métodos ágeis, definir um contrato para esse tipo de desenvolvimento pode ser difícil. Consequentemente, os métodos ágeis têm de contar com contratos em que o cliente para pelo tempo necessário para o desenvolvimento do sistema em vez de pelo desenvolvimento de um conjunto especifico de requisitos (SOMMERVILLE, 2007, p.263).


Todos os métodos possuem alguma limitação, já os métodos ágeis se adequam a alguns tipos de desenvolvimento de sistema, pode-se dizer que são mais adequados para o desenvolvimento de sistema de pequenas e médias empresas e produtos para computadores pessoais, para o desenvolvimento em larga escala podem não serem adequados, pois as equipes de desenvolvimento geralmente estão em locais deferentes e pode haver interações complexas com outros sistemas de hardware e software (SOMMERVILLE, 2007). Contudo em minha opinião pode ser possível criar uma metodologia hibrida que integra o desenvolvimento ágil ao convencional.


A abordagem ágil de desenvolvimento de software leva em consideração o projeto e a implementação como atividades centrais no processo de software, dessa forma são incorporadas outras atividades, como o esclarecimento de requisitos e testes no projeto de implementação, em contrapartida uma abordagem de engenharia de software dirigida a planos identifica estágios separados do processo de software com saídas associadas a cada estágio, essas saídas são utilizadas como base para o planejamento da atividade do processo a seguir (SOMMERVILLE, 2011).


Em uma abordagem dirigida a planos, acontecem iterações no ambiente de atividades com documentos formais que são utilizados para estabelecer a comunicação entre os estágios do processo. Por exemplo, os requisitos vão evoluir e, finalmente, será produzida uma especificação de requisitos. Considerando uma entrada para o processo de projeto e implementação. Em uma abordagem ágil, iterações ocorrem em todas as atividades. Portanto, os requisitos e o projeto são desenvolvidos em conjunto, e não separadamente, um processo de software dirigido a planos pode apoiar o desenvolvimento incremental (SOMMERVILLE, 2011).
Contudo a questão de rotular o projeto como dirigido a plano ou ágil não é muito importante, a principal preocupação dos compradores de um sistema de software é se estão comprando um sistema executável que atenda às suas necessidades e tenha uma usabilidade útil para o usuário individual ou para a organização. Na pratica, muitas empresas que afirmam ter usado métodos ágeis adoraram algumas práticas ágeis e integraram-nas em seus processos dirigidos a planos (SOMMERVILLE, 2011). Pelo desconhecimento do cliente em termos de linguagem de programação, banco de dados e outras questões técnicas o que realmente será levado em consideração é o desempenho, segurança e praticidade. Sendo assim cabe a equipe de desenvolvimento garantir esses atributos.


Para um melhor aproveitamento das metodologias ágeis, durante o processo de desenvolvimento do sistema de software, é necessário à motivação dos membros da equipe e seu entrosamento. Dessa forma é possível sincronizar as tarefas desenvolvidas, entregar os incrementos de software operacional no prazo estimado e orçamento definido. Além disso, os membros da equipe precisam ser capazes de suportar qualquer alteração no software ou na equipe.


Contudo até o momento não existe uma medida de produtividade aceita universalmente, existe diferentes formas de conseguir dados confiáveis, usando métricas para medir os conhecidos padrões de referencias que agem como substitutos de produtividade. Certos valores podem ser tidos como padrões de referencia com o número de linhas de código, o número de recursos distribuídos, prazo, esforço, dentre outros que podem variar dependendo da empresa responsável pela pesquisa (COHN, 2011).


Obviamente, quanto mais produtiva for a equipe, menores serão os gastos do projeto Cohn (2011) apresenta detalhadamente alguns resultados obtidos com esta pesquisa que afirma isto, de acordo com os estudos realizado pela VersionOne (2008), pesquisa online com mais de 3 mil pessoas sobre Desenvolvimento ágil, em parceria com a revista Dr. Dobb’s Journal (Ambler, 2008).


De acordo com Cohn (2011) uma pesquisa realizada em 2008 por David Rico, Ph.D, que examinou 51 estudos publicados sobre projetos ágeis. Foi possível observar o grande impacto dos processos ágeis sobre a produtividade e os custos para o desenvolvimento de projetos.
2.1 Extreme programming

O XP é o mais utilizado dos métodos ágeis, o nome foi elaborado por Beck, pois a abordagem foi desenvolvida para impulsionar práticas reconhecidamente eficazes, como o desenvolvimento iterativo, a níveis extremos. Como exemplo, em extreme programming várias novas versões de um sistema podem ser desenvolvidas, integradas e testadas em um único dia por programadores diferentes (SOMMERVILLE, 2011). Podemos citar que isso garante uma maior produtividade no desenvolvimento e os problemas encontrados serão apenas de uma parte do sistema de software.


Cardoso (2006) relata que uma particularidade do desenvolvimento de software tradicional é que o cliente não precisa, ou até mesmo não deve estar presente durante o processo de desenvolvimento. A extreme programming derruba esse paradigma, tornando a presença do cliente muito importante para o sucesso do projeto. O feedback que o cliente fornece é parte essencial de uma iteração.


O método extreme programming tem seus requisitos apresentados em cenários, conhecidos como história do usuário, que são implementados diretamente como uma série de tarefas. Os desenvolvedores atuam em pares e criam testes para cada tarefa antes de escreverem o código. Quanto o código é integrado ao sistema, todos os testes devem ser executados com sucesso (SOMMERVILLE, 2011). A sinergia entre os processo também devem avaliadas pois um processo pode ser executado com sucesso individualmente, mas ao integra-lo aos outros processos podem ocorrer inconsistências.


O desenvolvimento incremental é baseado em pequenos e frequentes releases do sistema, seus requisitos são apresentados em cenários ou em simples histórias de clientes, usadas como base para decidir a funcionalidade que deve ser incluída em um incremento do sistema, o envolvimento do cliente é sustentado por meio do engajamento contínuo do cliente a equipe de desenvolvimento. O representante do cliente participa do desenvolvimento e é responsável por definir os testes de aceitação para o sistema (SOMMERVILLE, 2011). Com a participação do cliente é possível moldar melhor sistemas as suas reais necessidades.


Segundo Sommerville (2011) o foco são as pessoas e não os processos, a programação se da por pares, o código tem sua autoria dividida e o processo de desenvolvimento sustentável não envolve horas de trabalho excessivamente longas, cada mudança é aceita por meio de releases contínuos para os clientes, do desenvolvimento test-first, da refatoração para evitar a degeneração do código e integração contínua de nova funcionalidade.


A manutenção da simplicidade é realizada através do retrabalho constante que melhora a qualidade do código bem como por meio de projetos simples que não antecipam desnecessariamente futuras mudanças no sistema (SOMMERVILLE, 2011). Refactoring é o processo de reordenar o código fonte de um software para aumentar sua qualidade interna, facilitar a leitura e diminuir o tempo gasto com manutenção, evitando prejudicar o desempenho e alterar seu comportamento externo. Essa técnica é fundamental para tornar o código mais legível e detectar erros em algoritmos mal escritos (GONÇALVES, 2009).
Em um processo XP, cada cliente está intimamente envolvido na especificação e priorização dos requisitos do sistema. Os requisitos não são especificados como uma lista de funções requeridas do sistema, pelo contrário, o cliente do sistema é parte da equipe de desenvolvimento e discute cenários com outros membros da equipe (SOMMERVILLE, 2011). Com isso é possível desenvolver um cartão de histórias englobando as necessidades do cliente, logo o desenvolvimento tenta implementar esse cenário em um release futuro do software.


Os cartões de histórias são as principais entradas para o processo de planejamento:
Em XP ou jogo de planejamento. Uma vez que tenham sido desenvolvidos, a equipe de desenvolvimento os divide em tarefas e estimas os esforços e os recursos necessários para a realização de cada tarefa. Esse processo geralmente envolve discussões com o cliente para o refinamento dos requisitos. O cliente, então prioriza as histórias para implementação, escolhendo aquelas que podem ser usadas imediatamente para oferecer apoio aos negócios. A intenção é identificar funcionalidade útil que possa ser implementada em cerca de duas semanas, quando o próximo release do sistema é disponibilizado para o cliente (SOMMERVILLE, 2011, p.46).


Como os requisitos mudam, as histórias não consideradas mudam ou podem ser descartadas, caso haja necessidade de mudanças em um sistema que já tenha sido entregue, novos cartões de história são desenvolvidos e novamente o cliente resolve se essas mudanças devem ser prioridade sobre a nova funcionalidade, eventualmente durante o planejamento surgem questões que não podem ser facilmente respondidas, tornando necessário algum trabalho adicional para explorar possíveis soluções (SOMMERVILLE, 2011). A equipe pode montar um modelo ou desenvolvimento-teste para compreender o problema e a solução.


A abordagem extrema do XP leva ao desenvolvimento incremental, novas versões do software podem ser construídas várias vezes por dia e releases são entregues aos clientes a cada duas semanas, aproximadamente. Prazos de releases nunca são desrespeitados e se existir problemas de desenvolvimento o cliente é consultado, e a funcionalidade é removida do release planejado. Quanto um programador desenvolve um sistema para criar uma nova versão, deve executar todos os testes automatizados existentes, bem como os testes para a nova funcionalidade (SOMMERVILLE, 2011).


Um preceito fundamental da engenharia de software tradicional é que você deve projetar para mudar:
Ou seja, você deve antecipar futuras alterações do software e projeta-lo para que essas mudanças possam ser facilmente implementadas. O extreme programming, no entanto, descartou esse principio com base na concepção de que muitas vezes a mudança é um esforço desperdiçado. Não vale a pena perder tempo adicionando generalidades a um programa para lidar com mudanças. Frequentemente, mudanças previstas não se materializam e solicitações por mudanças completamente diferentes podem ser feitas. Portanto, a abordagem XP aceita que as mudanças acontecerão e reorganizarão o software quando essas mudanças realmente acontecerem (SOMMERVILLE, 2011, p.46).


No geral um problema que afeta o desenvolvimento incremental é a degradação da estrutura do software, assim sendo, as alterações para o software tornam-se cada vez mais complicadas de serem implementadas, essencialmente, o desenvolvimento prossegue, encontrado soluções para os problemas, mas o resultado final frequentemente é a duplicação do código; partes do software são reusadas de maneira inadequada, e a estrutura global do código degrada-se quando ele é adicionado ao sistema (SOMMERVILLE, 2011). Uma forma de evitar esse tipo de situação é manter uma revisão constante do código para evitar duplicidades que futuramente interferirão no desempenho e qualidade do sistema de software.
O XP sugere que o software seja constantemente refatorado, isso significa que a equipe de programação deve focar em possíveis melhorias para o software e implementação imediatas destas, quando um membro da equipe percebe que o código pode ser melhorado, essas melhorias são feitas, mesmo quando não existe necessidade imediata. Exemplos de refatoração incluem a reorganização da hierarquia de classes para eliminação de código duplicado, e renomeação de atributos e métodos, bem com a substituição do código com chamadas para métodos definidos em uma biblioteca de programas (SOMMERVILLE, 2011). Assim sendo é possível garantir a qualidade do código mantendo a simplicidade e o desempenho do software em alto padrão.


Contudo o software deve ser sempre fácil de compreender e mudar à medida que novas histórias efetivadas, na prática, isso nem sempre acontece. Em alguns casos, a pressão pelo desenvolvimento significa que a refatoração será postergada, por que a maior parte do tempo é dedicada à implementação de nova funcionalidade. Algumas novas características e mudanças não podem ser facilmente acomodadas por refatoração do nível do código, e exigem modificações da arquitetura do sistema. Na realidade, muitas empresas que adotaram XP não usam todas as práticas da Extreme Programming, elas escolhem de acordo com sua organização (SOMMERVILLE, 2011).


Os desenvolvedores de um modo geral estão dando mais ênfase aos testes de software para tentar diminuir o máximo possível à margem de falhas durante a aplicação real do sistema de software. De acordo com Sommerville (2011), uma das diferenças pertinentes entre o desenvolvimento incremental e o desenvolvimento dirigido a planos está na forma como o sistema é testado. Com o desenvolvimento incremental, não existe especificações do sistema que possa ser usada por uma equipe de teste externa para a criação de testes de sistema. Como consequência, algumas abordagens para o desenvolvimento incremental tem um processo de testes muito informal em comparação com os testes dirigidos a planos, sendo assim para evitar alguns dos problemas de teste e validação do sistema, a abordagem XP prioriza a importância dos testes de programa.


O test-first segundo Sommerville (2011) é uma das mais importantes inovações no Extreme Programming. Em vez de escrever algum código e, em seguida, escrever testes para esse código, você escreve os testes antes de escrever o código. Isso significa que você pode executar o teste enquanto o código é elaborado e também encontrar problemas durante o desenvolvimento. Ao escrever os testes, implicitamente se definem uma interface e uma especificação de comportamento para a funcionalidade a ser desenvolvida, dessa forma problemas de requisitos e mal-entendidos de interface são reduzidos. Essa abordagem pode ser utilizada em qualquer processo em que exista uma relação clara entre um requisito do sistema e o código que implementa esse requisito.


Com isso pode-se dizer que no desenvolvimento test-firt, os criadores de tarefas precisam compreender plenamente a especificação para então escrever testes para o sistema, dessa forma duplicidades e omissões da lista de especificações devem ser esclarecidas antes do começo do desenvolvimento. De acordo com Sommerville (2011), com isso evitamos o problema de ‘test-lag’. Isso pode acontecer quando o desenvolvedor do sistema trabalha em um ritmo mais rápido que o testador. A implementação fica mais a frente dos testes e desenvolve-se uma tendência a ignorar os testes, a fim de que o cronograma de desenvolvimento possa ser mantido.
Sommerville (2011) diz que outra prática inovadora introduzida no Extreme Programming é a programação em pares, para desenvolver o software os programadores sentam juntos, na mesma estação de trabalho. No entanto os mesmo pares nem sempre programa juntos. Pelo contrario, os pares são criados de forma dinâmica para que todos os membros da equipe atuem uns com os outros durante o processo de desenvolvimento. O uso da programação em pares apresenta algumas vantagens como suporte à ideia de propriedade e responsabilidade coletiva, atua como um processo de revisão informal, por que cada linha de código é observada por, pelo menos, duas pessoas e oferece suporte a refatoração, que é um processo de melhoria de software.


Na programação em pares, os desenvolvedores determinam um user story e sentam-se em um único computador para codificar uma funcionalidade. O desenvolvedor com menor experiência tem como responsabilidade assumir o controle do teclado e conduzir ativamente a programação do código fonte, enquanto o outro com maior experiência inspeciona o código a procura de erros e defeitos, questionando as decisões e buscando estrategicamente as soluções mais simples para o código (BORBOREMA, 2007).


A metodologia Extreme Programming está fundamentada em cinco princípios básicos: simplicidade, comunicação, feedback, coragem e respeito. Contendo doze práticas de suporte: planejamento, pequenas fases, metáfora, design simples, testes, refatoração, programação em pares, propriedade coletiva, integração contínua, carga horária de 40 horas, cliente integrado ao projeto participando da equipe de desenvolvimento e padrões de código.



3 Conclusão

É possível determinar que as metodologias ágeis não ofereçam um suporte amplo ao controle de risco, ou seja, não existe o cuidado formal em realizar uma análise e planejamento de riscos. Podemos dizer que esse é um ponto negativo para as metodologias ágeis, como estratégia para resolver esse problema é fundamental a implantação de políticas para o controle e gerenciamento de risco sem tornar a metodologia ágil complexa. Outro ponto avaliado é o fato dos métodos ágeis serem mais bem empregados em pequenas equipes ou médias de desenvolvimento e pouca complexidade na integração de diversos sistemas, esse é mais um fator que precisar ser superado.


Contudo quanto mais as metodologias ágeis forem usadas, melhores serão os resultados, sua adoção por empresas de grande porte é fundamental para fornecer resultados empíricos em termos de vantagens e desvantagens, riscos e procedimentos para seu emprego nas organizações. O uso de métodos ágeis para o desenvolvimento de software oferece vantagens competitivas porem é preciso ter o cuidado para garantir a qualidade do produto assim como determina as metodologias tradicionais que precisam de mais tempo para entrega do software, pois utilizam diversas diretrizes de controle visando minimizar os pontos fracos do desenvolvimento, assim sendo os métodos ágeis tendem a adotar algumas rotinas de segurança dos métodos tradicionais, porém é preciso respeitar a essência da metodologia ágil.