Desenvolvimento ágil de software

Desenvolvimento Ágil de Software (em inglês: Agile software development) ou Método ágil é uma disciplina que estuda um conjunto de comportamentos, processos, práticas e ferramentas utilizados para a criação de produtos (geralmente de, mas não limitados a, software) e sua subsequente disponibilização para os usuários finais. Uma abordagem onde produtos são desenvolvidos colaborativamente com equipes multidisciplinar baseado na criatividade e na flexibilização, muito usado atualmente por gestores de várias áreas devido o mercado exigir mais agilidade. As metodologias e frameworks que fazem parte do conceito de desenvolvimento ágil (como o Scrum, por exemplo) providenciam uma estrutura conceitual para conduzir projetos de engenharia de software.

Métodos ágeis também enfatizam o software funcional como uma medida primária de progresso. Combinado com a comunicação cara-a-cara, métodos ágeis produzem pouca documentação em relação a outros métodos, sendo este um dos pontos que podem ser considerados negativos.

Existem inúmeros frameworks de processos para desenvolvimento de software. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projeto de software em miniatura e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projeto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa em que a equipe responsável reavalia as prioridades do projeto.

Métodos ágeis enfatizam comunicação frequente, preferencialmente cara a cara, em vez de 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 (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem também se encontrar os testadores, projetistas de iteração, redatores técnicos e gerentes.

História

As definições modernas de desenvolvimento de software ágil evoluíram a partir da metade de 1990 como parte de uma reação contra métodos "pesados", caracterizados por uma pesada regulamentação, regimentação e micro gerenciamento usado o modelo em cascata para desenvolvimento. O processo originou-se da visão de que o modelo em cascata era burocrático, lento e contraditório a forma usual com que os engenheiros de software sempre realizaram trabalho com eficiência.

Uma visão que levou ao desenvolvimento de métodos ágeis e iterativos era retorno a prática de desenvolvimento vistas nos primórdios da história do desenvolvimento de software.

Inicialmente, métodos ágeis eram conhecidos como métodos leves. Em 2001, membros proeminentes da comunidade se reuniram em Snowbird e adotaram o nome métodos ágeis, tendo publicado o Manifesto ágil, documento que reúne os princípios e práticas desta metodologia de desenvolvimento. Mais tarde, algumas pessoas formaram a Agile Alliance, uma organização não lucrativa que promove o desenvolvimento ágil.

Os métodos ágeis iniciais—criado a priore em 2000— incluíam Scrum (1986), Crystal Clear, Programação extrema (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (1995).

O Manifesto para o Desenvolvimento Ágil do Software

Valores ágeis de desenvolvimento de software

Segundo a página Agile Manifest - Manifesto ágil os valores relacionados ao Desenvolvimento ágil de software são:

• Indivíduos e iterações mais que processos e ferramentas;
• Software funcional mais que documentação abrangente;
• Colaboração do cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano

Ou seja, o item à esquerda sempre tem maior importância do que o item à direita

Princípios ágeis de desenvolvimento de software

Os princípios do desenvolvimento ágil valorizam

• Garantir a satisfação do consumidor entregando rapidamente e continuamente software funcionais;
• Até mesmo mudanças tardias de escopo no projeto são bem-vindas para garantir a vantagem competitiva do cliente;
• Software funcionais são entregues frequentemente (semanas, ao invés de meses);
• Cooperação diária entre pessoas que entendem do 'negócio' e desenvolvedores;
• Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.
• A maneira mais eficiente e efetiva de transmitir informações é conversar cara a cara;
• Software funcionais são a principal medida de progresso do projeto;
• Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes para manter um ritmo constante indefinidamente.
• Design do software deve prezar pela excelência técnica;
• Simplicidade é essencial;
• As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas;
• Em intervalos regulares, a equipe reflete sobre como para tornar-se mais eficaz, então sintoniza e ajusta seu comportamento apropriadamente.

Comparações com outros métodos

Métodos Ágeis são algumas vezes caracterizados como o oposto de metodologias guiadas pelo planejamento ou disciplinadas. Uma distinção mais acurada é dizer que os métodos existem em um contínuo do adaptativo até o preditivo. Métodos ágeis existem do lado adaptativo deste contínuo.

Métodos adaptativos buscam a adaptação rápida a mudanças da realidade. Quando uma necessidade de um projeto muda, uma equipe adaptativa mudará também. Um time adaptativo terá dificuldade em descrever o que irá acontecer no futuro. O que acontecerá em uma data futura é um item de difícil predição para um método adaptativo. Uma equipe adaptativa pode relatar quais tarefas se iniciarão na próxima semana. Quando perguntado acerca de uma implantação que ocorrerá daqui a seis meses, uma equipe adaptativa deve ser capaz somente de relatar a instrução de missão para a implantação, ou uma expectativa de valor versus custo.

Métodos preditivos, em contraste, colocam o planejamento do futuro em detalhe. Uma equipe preditiva pode reportar exatamente quais aspectos e tarefas estão planejados para toda a linha do processo de desenvolvimento. Elas porém tem dificuldades de mudar de direção. O plano é tipicamente otimizado para o objetivo original e mudanças de direção podem causar a perda de todo o trabalho e determinar que seja feito tudo novamente. Equipes preditivas freqüentemente instituem um comitê de controle de mudança para assegurar que somente as mudanças mais importantes sejam consideradas.

Métodos ágeis têm muito em comum com técnicas de Desenvolvimento rápido de aplicação de 1980 como exposto por James Martin e outros.

Comparação com o desenvolvimento iterativo

A maioria dos métodos ágeis compartilha a ênfase no Desenvolvimento iterativo e incremental para a construção de versões implantadas do software em curtos períodos de tempo. Métodos ágeis diferem dos métodos iterativos porque seus períodos de tempo são medidos em semanas, ao invés de meses, e a realização é efetuada de uma maneira altamente colaborativa. estendendo-se a tudo.

Comparação com o modelo em cascata

O desenvolvimento ágil tem pouco em comum com o modelo em cascata. Na visão de alguns este modelo é desacreditado, apesar de ser um modelo de uso comum. O modelo em cascata é uma das metodologias com maior ênfase no planejamento, seguindo seus passos através da captura dos requisitos, análise, projeto, codificação e testes em uma sequência pré-planejada e restrita. O progresso é geralmente medido em termos de entrega de artefatos—especificação de requisitos, documentos de projeto, planos de teste, revisão do código, e outros. O modelo em cascata resulta em uma substancial integração e esforço de teste para alcançar o fim do ciclo de vida, um período que tipicamente se estende por vários meses ou anos. O tamanho e dificuldade deste esforço de integração e teste é uma das causas das falhas do projeto em cascata. Métodos ágeis, pelo contrário, produzem um desenvolvimento completo e teste de aspectos (mas um pequeno subconjunto do todo) num período de poucas semanas ou meses. Enfatiza a obtenção de pequenos pedaços de funcionalidades executáveis para agregar valor ao negócio cedo, e continuamente agregar novas funcionalidades através do ciclo de vida do projeto.

Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata inteiro em cada iteração. Outras equipes, mais especificamente as equipes de Programação extrema, trabalham com atividades simultaneamente.

Comparação com a "codificação cowboy"

A codificação cowboy, também chamada de Modelo Balbúrdia, é a ausência de metodologias de desenvolvimento de Software: os membros da equipe fazem o que eles sentem que é correto. Como os desenvolvedores que utilizam métodos ágeis freqüentemente reavaliam os planos, enfatizam a comunicação face a face e fazem o uso relativamente esparso de documentos, ocasionalmente levam as pessoas a confundirem isto com codificação cowboy. Equipes ágeis, contudo, seguem o processo definido (e freqüentemente de forma disciplinada e rigorosa).

Como em todas as metodologias, o conhecimento e a experiência dos usuários definem o grau de sucesso e/ou fracasso de cada atividade. Os controles mais rígidos e sistematizados aplicados em um processo implicam altos níveis de responsabilidade para os usuários. A degradação de procedimentos bem-intencionados e organizados pode levar as atividades a serem caracterizadas como codificação cowboy.

Estimativas em Métodos ágeis

O desenvolvimento de software ágil enfatiza a flexibilidade e a rápida adaptação às mudanças durante o processo de desenvolvimento. Dentro deste contexto, as técnicas de estimativa são fundamentais para o planejamento e execução eficazes dos projetos. Entre as diversas técnicas disponíveis, o Planning Poker, ou "Poker de Planejamento", destaca-se como uma abordagem interativa e democrática para a estimativa de tempo e recursos necessários para a execução de tarefas de software.

Planning Poker em Métodos ágeis

O Planning Poker é uma técnica de estimativa que promove o comprometimento e a participação de todos os membros da equipe no processo de planejamento. A técnica é baseada no consenso e busca envolver todos os participantes, garantindo que várias perspectivas e conhecimento do negócio sejam consideradas antes de se chegar a uma decisão, do custo da tarefa. Além disso, o aspecto lúdico do jogo cativa os envolvidos, tornando o processo de estimativa mais agradável e menos tedioso.

Durante uma sessão de Planning Poker, cada membro da equipe recebe cartas que representam diferentes níveis de esforço, normalmente sequências numéricas que podem seguir a série de Fibonacci ou qualquer outra distribuição acordada. Os elementos a serem estimados podem incluir histórias de usuário, casos de uso, pacotes de trabalho, atividades, entre outros. A seguir, são destacados os passos básicos do processo:

1. Apresentação da Tarefa: O facilitador (geralmente o Product Owner ou um gerente de projeto) apresenta uma tarefa a ser estimada.
2. Discussão: A equipe discute os requisitos e detalhes da tarefa, esclarecendo quaisquer dúvidas.
3. Estimação Individual: Cada membro seleciona uma carta que representa sua estimativa de esforço necessária para completar a tarefa.
4. Revelação e Justificativas: Todos ao mesmo tempo revelam suas cartas. Se houver discrepâncias significativas nas estimativas, os membros com estimativas mais altas e mais baixas explicam seus pontos de vista.
5. Consenso: O processo é repetido até que haja consenso entre todos os membros da equipe.

O uso do Planning Poker em métodos ágeis oferece várias vantagens:

• Democrático e Inclusivo: Todos os membros da equipe têm voz igual no processo de estimativa, o que aumenta o envolvimento e comprometimento com o projeto.
• Rápido e Eficiente: Permite chegar a uma estimativa de forma rápida e eficiente, reduzindo o tempo gasto em longas discussões.
• Preciso: Ao combinar as diferentes perspectivas e experiências dos membros da equipe, a precisão das estimativas tendem a aumentar.
• Dinâmico: O aspecto lúdico engaja os participantes, tornando o processo menos monótono e mais dinâmico.

Aplicabilidade dos métodos ágeis

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 artefatos intermediários. (Cohen et al., 2004) A aplicabilidade dos métodos ágeis em geral pode ser examinada de múltiplas perspectivas. Da perspectiva do produto, métodos ágeis são mais adequados quando os requisitos estão emergindo e mudando rapidamente, embora não exista um consenso completo neste ponto (Cohen et al., 2004). De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando três dimensões chaves da organização: cultura, pessoal e comunicação. Em relação a estas áreas inúmeros fatores chave do sucesso podem ser identificados (Cohen et al., 2004):

• A cultura da organização deve apoiar a negociação.
• As pessoas devem ser confiantes.
• Poucas pessoas, mas competentes.
• A organização deve promover as decisões que os desenvolvedores tomam.
• A Organização necessita ter um ambiente que facilite a rápida comunicação entre os membros.

O fator mais importante é provavelmente o tamanho do projeto (Cohen et al., 2004).. Com o aumento do tamanho, a comunicação face a face se torna mais difícil. Portanto, métodos ágeis são mais adequados para projetos com pequenos times, com no máximo de 20 a 40 pessoas.

De forma a determinar a aplicabilidade de métodos ágeis específicos, uma análise mais sofisticada é necessária. O método dinâmico para o desenvolvimento de sistemas, por exemplo, provê o denominado 'filtro de aplicabilidade' para este propósito. Também, a família de métodos Crystal provê uma caracterização de quando selecionar o método para um projeto. A seleção é baseada no tamanho do projeto, criticidade e prioridade. Contudo, outros métodos ágeis não fornecem um instrumento explícito para definir sua aplicabilidade a um projeto.

Alguns métodos ágeis, como DSDM (Dynamic Systems Development Method) e FDM (Feature Driven Development), afirmam se aplicar a qualquer projeto de desenvolvimento ágil, sem importar suas características (Abrahamsonn et al., 2003).

A comparação dos métodos ágeis irá revelar que eles suportam diferentes fases de um ciclo de vida do software em diferentes níveis. Estas características individuais dos métodos ágeis podem ser usadas como um critério de seleção de sua aplicabilidade.

Desenvolvimentos ágeis vêm sendo amplamente documentados (ver Experiências relatadas, abaixo, como também em Beck, e Boehm & Turner) como funcionando bem para equipes pequenas (< 10 desenvolvedores). O desenvolvimento ágil é particularmente adequado para equipes que têm que lidar com mudanças rápidas ou imprevisíveis nos requisitos.

A aplicabilidade do desenvolvimento ágil para os seguintes cenários é ainda uma questão aberta:

• esforços de desenvolvimento em larga escala (> 20 desenvolvedores), embora estratégias para maiores escalas tenham sido descritas.
• esforços de desenvolvimento distribuído (equipes não co-alocadas). Estas estratégias tem sido descritas em Bridging the Distance e Using an Agile Software Process with Offshore Development
• esforços críticos de missão e vida.
• Companhias com uma cultura de comando e controle.

Barry Boehm e Richard Turner sugeriram que análise de risco pode ser usada para escolher entre métodos adaptativos ("ágeis") e preditivos ("dirigidos pelo planejamento"). Os autores sugerem que cada lado deste contínuo possui seu ambiente ideal"

Ambiente ideal para o desenvolvimento ágil:

• Baixa criticidade
• Desenvolvedores sênior
• Mudanças frequente de requisitos
• Pequeno número de desenvolvedores
• Cultura que tem sucesso no caos.

Ambiente ideal para o desenvolvimento direcionado ao planejamento:

• Alta criticidade
• Desenvolvedores Junior
• Baixa mudança nos requisitos
• Grande número de desenvolvedores
• Cultura que procura a ordem.

Adaptabilidade dos métodos ágeis

Um método deve ser bastante flexível para permitir ajustes durante a execução do projeto. Há três problemas chaves relacionados ao tópico de adaptação dos métodos ágeis: a aplicabilidade dos métodos ágeis (no geral e no particular), e finalmente, o suporte ao gerenciamento de projeto.

Na Agile Culture, o profissional tem mais liberdade. Ele recebe um conjunto de métricas, objetivos e orientações para planejar o seu trabalho da melhor forma possível, agregando valor ao negócio e dando mais flexibilidade interna.

Métodos ágeis e o gerenciamento de projeto

Os métodos ágeis diferem largamente no que diz respeito a forma de serem gerenciados. Alguns métodos são suplementados com guias para direcionar o gerenciamento do projeto, mas nem todos são aplicáveis.

PRINCE2™ tem sido considerado como um sistema de gerenciamento de projeto complementar e adequado.

Uma característica comum dos processos ágeis é a capacidade de funcionar em ambientes muito exigentes que tem um grande número de incertezas e flutuações (mudanças) que podem vir de várias fontes como: equipe em processo de formação que ainda não trabalhou junto em outros projetos, requisitos voláteis, baixo conhecimento do domínio de negócio pela equipe, adoção de novas tecnologias, novas ferramentas, mudanças muito bruscas e rápidas no ambiente de negócios das empresas: novos concorrentes, novos produtos, novos modelos de negócio.

Sistemas de gerenciamento de projetos lineares e prescritivos, neste tipo de ambiente, falham em oferecer as características necessárias para responder de forma ágil as mudanças requeridas. Sua adoção pode incrementar desnecessariamente os riscos, o custo, o prazo e baixar a qualidade do produto gerado, desgastando a equipe e todos os envolvidos no processo.

A abordagem Scrum, para gestão de projetos ágeis, leva em consideração planejamento não linear, porém de maneira mais exaustiva e está focada em agregar valor para o cliente e em gerenciar os riscos, fornecendo um ambiente seguro. Pode ser utilizada na gestão do projeto aliada a uma metodologia de desenvolvimento como Programação Extrema, FDD, OpenUP, DSDM, Crystal ou outras.

Práticas Ágeis de Desenvolvimento de Software

O desenvolvimento de software ágil é apoiado por várias práticas concretas, abrangendo áreas como requisitos, design, modelagem, codificação, teste, planejamento, gerenciamento de risco, processo, qualidade, etc. Algumas práticas notáveis ​​de desenvolvimento ágil de software incluem:

Pratica	Contribuidor principal (s)
Desenvolvimento orientado a testes de aceitação (ATDD)	Kent Beck
Modelagem ágil	Scott Ambler
Teste ágil
Backlogs (produto e Sprint)	Ken Schwaber
Desenvolvimento Orientado por Comportamento (BDD)	Dan North, Liz Keogh
Integração Contínua (CI)	Grady Booch
Equipe multifuncional
Design dirigido por domínio (DDD)	Eric Evans
Desenvolvimento Iterativo e Incremental (IID)
Plataformas de desenvolvimento de baixo código
Programação par	Kent Beck
Pôquer planejando	James Grenning, Mike Cohn
Refatoração
Retrospectivo
Eventos Scrum (planejamento de sprint, scrum diário, revisão de sprint e retrospectiva)
Especificação por exemplo
Modelagem orientada por história	Albert Zündorf
Desenvolvimento orientado a testes (TDD)	Kent Beck
Timeboxing
História do usuário	Alistair Cockburn
Rastreamento de velocidade

Metodologia

• Programação extrema

Albert Joseph; Ercilia Chilaule; Francelino Itc(I2cv)

• Feature Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• Adaptive Software Development
• Crystal
• Pragmatic Programming
• «Test Driven Development» 

Críticas

O método de desenvolvimento ágil é algumas vezes criticado como codificação cowboy. O início da Programação extrema soava como controverso e dogmático, tal como a programação por pares e o projeto contínuo, tem sido alvo particular de críticos, tais como McBreen e Boehm e Turner. Contudo, muitas destas críticas têm sido vistas pelos defensores dos métodos ágeis como mal entendidos a respeito do desenvolvimento ágil.

Em particular, a Programação extrema é revista e criticada por Matt Stephens' Extreme Programming Refactored.

As críticas incluem

• falta de estrutura e documentação necessárias
• somente trabalhar com desenvolvedores de nível sênior
• incorpora de forma insuficiente o projeto de software
• requer a adoção de muita mudança cultural
• poder levar a maiores dificuldades nas negociações contratuais

Indicação de uso: Scrum

Inicialmente, o Scrum, metodologia ágil criada por Ken Schwaber e Jeff Sutherland, compreende um método de trabalho produzido a partir de pequenos ciclos de atividades dentro de um projeto, os quais são conhecidos como Sprint. Assim, cada um desses ciclos é composto por um período de tempo predefinido em que as tarefas devem ser realizadas pela equipe, aprimorando a velocidade de produção de um determinado sistema.

Além disso, de acordo com Jeff: "A estrutura do Scrum procura aproveitar a maneira como as equipes de fato trabalham, fornecendo ferramentas para se auto-organizarem e otimizarem em pouco tempo a rapidez e a qualidade do trabalho". Dessa forma, tendo em mente que uma das principais vantagens é que a equipe consiga entregar a produção com maior agilidade, corrigindo problemas ao longo do processo a partir dos Sprints, em que se obtém feedback do usuário. Ou seja: a equipe não espera a entrega final do produto para que o cliente avalie, e sim faz as correções necessárias ao longo da produção, durante os Sprints.

Ver também

• Scrum (desenvolvimento de software)
• Kanban
• Test Driven Development
• Modelo em cascata
• Modelo em espiral
• Rup
• Dsdm
• Asd

Futuras leituras

• Fowler, Martin. Is Design Dead?. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
• Riehle, Dirk. A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn From Each Other. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
• Tomek, Ivan. What I Learned Teaching XP. http://www.whysmalltalk.com/articles/tomek/teachingxp.htm
• M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. Apress L.P., Berkeley, California. 2003. (ISBN 1-59059-096-1)
• D. Rosenberg, M. Stephens. Agile Development with ICONIX Process. Apress L.P., Berkeley, California. 2005. (ISBN 1-59059-464-9)
• Beck, et. al., Manifesto for Agile Software Development. [4]
• Larman, Craig and Basili, Victor R. Iterative and Incremental Development:A Brief History IEEE Computer, June 2003
• Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254.
• Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478.
• Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), 127-138
• Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On the Adaptation of An Agile Information Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24
• Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In Advances in Computers (pp. 1–66). New York: Elsevier Science.
• Karlstrom, D., & Runeson P. (2005). Combining agile methods with stage-gate project management. IEEE Software, 22(3), 43-49

Ligações externas

• «Manifesto para Desenvolvimento Ágil de Software» (em inglês) 
• «Agile Alliance Brasil» 
• Cronapp - Freedom to Develop (em português)
• O que é o Ágil? Uma nova definição formal
• Treinamento Gratuito de Metodologias Ágeis (em vídeo)