Capítulo 3 – Desenvolvimento ágil de software
3.2 Desenvolvimento ágil e dirigido a planos
3.4 Gerenciamento ágil de projetos
3.5 Escalamento de métodos ágeis
Cont
eúdo
Desenvolvimento
ágil de software
Objetivos
O objetivo deste capítulo é apresentar os métodos ágeis de desen- volvimento de software. Ao terminar de ler este capítulo, você:
t compreenderá a lógica dos métodos ágeis de desenvolvimento de software, o manifesto ágil, e as diferenças entre desenvolvi- mento ágil e desenvolvimento dirigido a planos;
t conhecerá as práticas mais importantes da Extreme Program- ming e o modo como elas se relacionam com os princípios gerais dos métodos ágeis;
t compreenderá a abordagem Scrum para gerenciamento ágil de projetos;
t estará ciente das questões e problemas de escalamento de mé- todos ágeis de desenvolvimento para o desenvolvimento de sis- temas de software de grande porte.
N
os dias de hoje, as empresas operam em um ambiente global, com mudanças rápidas. Assim, precisam responder a novas oportunidades e novos mercados, a mudanças nas condições econômicas e ao surgimento de produtos e serviços concorrentes. Softwares fazem parte de quase todas as operações de negócios, assim, novos softwares são desenvolvidos rapidamente para obterem proveito de novas oportunidades e responder às pressões competitivas. O de- senvolvimento e entrega rápidos são, portanto, o requisito mais crítico para o desenvolvimento de sistemas de software. Na verdade, muitas empresas estão dispostas a trocar a qualidade e o compromisso com requisitos do software por uma implantação mais rápida do software de que necessitam.Essas empresas operam em um ambiente de mudanças rápidas, e por isso, muitas vezes, é praticamente impossível ob- ter um conjunto completo de requisitos de software estável. Os requisitos iniciais inevitavelmente serão alterados, pois os clientes acham impossível prever como um sistema afetará as práticas de trabalho, como irá interagir com outros sistemas e quais operações do usuário devem ser automatizadas. Pode ser que os requisitos se tornem claros apenas após a entrega do sistema e à medida que os usuários ganhem experiência. Mesmo assim, devido a fatores externos, os requisitos são suscetíveis a mudanças rápidas e imprevisíveis. Por exemplo, quando for entregue, o software poderá estar desatualizado.
Processos de desenvolvimento de software que planejam especificar completamente os requisitos e, em seguida, projetar, construir e testar o sistema não estão adaptados ao desenvolvimento rápido de software. Com as mudanças nos requisitos ou a descoberta de problemas de requisitos, o projeto do sistema ou sua implementação precisa ser refeito ou
39
Capítulo 3 Desenvolvimento ágil de software
retestado. Como consequência, um processo convencional em cascata ou baseado em especificações costuma ser demo- rado, e o software final é entregue ao cliente bem depois do prazo acordado.
Para alguns tipos de software, como sistemas críticos de controle de segurança, em que uma análise completa do sistema é essencial, uma abordagem dirigida a planos é a melhor opção. No entanto, em um ambiente de negócio que se caracteriza por mudanças rápidas, isso pode causar problemas reais. Quando o software estiver disponível para uso, a razão original para sua aquisição pode ter mudado tão radicalmente que o software será efetivamente inútil. Portanto, para os sistemas de negócios, particularmente, os processos de desenvolvimento que se caracterizem por desenvolvimento e entrega rápidos de software são essenciais.
Há algum tempo já se reconhecia a necessidade de desenvolvimento rápido e de processos capazes de lidar com mudan- ças nos requisitos. Na década de 1980, a IBM introduziu o desenvolvimento incremental (MILLS et al., 1980). A introdução das linguagens de quarta geração, também em 1980, apoiou a ideia de desenvolvimento e entrega rápidos de software (MARTIN, 1981). No entanto, a ideia realmente decolou no final da década de 1990, com o desenvolvimento da noção de abordagens ágeis, como Metodologia de Desenvolvimento de Sistemas Dinâmicos (DSDM, do inglês dynamic systems development me- thod) (STAPLETON, 1997), Scrum (SCHWABER e BEEDLE, 2001) e Extreme Programming (BECK, 1999; BECK, 2000).
Os processos de desenvolvimento rápido de software são concebidos para produzir, rapidamente, softwares úteis. O software não é desenvolvido como uma única unidade, mas como uma série de incrementos — cada incremento inclui uma nova funcionalidade do sistema. Embora existam muitas abordagens para o desenvolvimento rápido de software, elas compartilham algumas características fundamentais:
1. Os processos de especificação, projeto e implementação são intercalados. Não há especificação detalhada do sis-
tema, e a documentação do projeto é minimizada ou gerada automaticamente pelo ambiente de programação usado para implementar o sistema. O documento de requisitos do usuário apenas define as características mais importantes do sistema.
2. O sistema é desenvolvido em uma série de versões. Os usuários finais e outros stakeholders do sistema são envolvi-
dos na especificação e avaliação de cada versão. Eles podem propor alterações ao software e novos requisitos que devem ser implementados em uma versão posterior do sistema.
3. Interfaces de usuário do sistema são geralmente desenvolvidas com um sistema interativo de desenvolvimento
que permite a criação rápida do projeto de interface por meio de desenho e posicionamento de ícones na inter- face. O sistema pode, então, gerar uma interface baseada na Web para um navegador ou uma interface para uma plataforma específica, como o Microsoft Windows.
Os métodos ágeis são métodos de desenvolvimento incremental em que os incrementos são pequenos e, normal- mente, as novas versões do sistema são criadas e disponibilizadas aos clientes a cada duas ou três semanas. Elas envolvem os clientes no processo de desenvolvimento para obter feedback rápido sobre a evolução dos requisitos. Assim, minimiza- -se a documentação, pois se utiliza mais a comunicação informal do que reuniões formais com documentos escritos.
3.1 Métodos ágeis
Na década de 1980 e início da de 1990, havia uma visão generalizada de que a melhor maneira para conseguir o melhor software era por meio de um planejamento cuidadoso do projeto, qualidade da segurança formalizada, do uso de métodos de análise e projeto apoiado por ferramentas CASE (Computer-aided software engineering) e do processo de desenvolvimento de software rigoroso e controlado. Essa percepção veio da comunidade de engenharia de software, responsável pelo desenvolvimento de sistemas de software grandes e duradouros, como sistemas aeroespaciais e de governo.
Esse software foi desenvolvido por grandes equipes que trabalham para diferentes empresas. Geralmente, as equipes eram dispersas geograficamente e trabalhavam com o software por longos períodos. Um exemplo desse tipo de software é o sistema de controle de uma aeronave moderna, que pode demorar até dez anos desde a especificação inicial até a implantação. Tais abordagens dirigidas a planos envolvem um overhead significativo no planejamento, projeto e documentação do sistema. Esse overhead se justifica quando o trabalho de várias equipes de desenvolvimento tem de ser coordenado, quando o sistema é um sistema crítico e quando muitas pessoas diferentes estão envolvidas na manutenção do software durante sua vida.
No entanto, quando essa abordagem pesada de desenvolvimento dirigido a planos é aplicada aos sistemas corporativos de pequeno e médio porte, o overhead envolvido é tão grande que domina o processo de desen- volvimento de software. Gasta-se mais tempo em análises de como o sistema deve ser desenvolvido do que no
40 Engenharia de software
desenvolvimento de programas e testes. Como os requisitos do sistema se alteram, o retrabalho é essencial, e, pelo menos em princípio, a especificação e o projeto devem mudar com o programa.
A insatisfação com essas abordagens pesadas da engenharia de software levou um grande número de desen- volvedores de software a proporem, na década de 1990, novos ‘métodos ágeis’. Estes permitiram que a equipe de desenvolvimento focasse no software em si, e não em sua concepção e documentação. Métodos ágeis, univer- salmente, baseiam-se em uma abordagem incremental para a especificação, o desenvolvimento e a entrega do software. Eles são mais adequados ao desenvolvimento de aplicativos nos quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento. Destinam-se a entregar o software rapidamente aos clien- tes, em funcionamento, e estes podem, em seguida, propor alterações e novos requisitos a serem incluídos nas iterações posteriores do sistema. Têm como objetivo reduzir a burocracia do processo, evitando qualquer trabalho de valor duvidoso de longo prazo e qualquer documentação que provavelmente nunca será usada.
A filosofia por trás dos métodos ágeis é refletida no manifesto ágil, que foi acordado por muitos dos principais desenvolvedores desses métodos. Esse manifesto afirma:
Estamos descobrindo melhores maneiras de desenvolver softwares, fazendo-o e ajudando outros a fazê-lo. Atra- vés desse trabalho, valorizamos mais:
Indivíduos e interações do que processos e ferramentas
Software em funcionamento do que documentação abrangente Colaboração do cliente do que negociação de contrato
Respostas a mudanças do que seguir um plano
Ou seja, embora itens à direita sejam importantes, valorizamos mais os que estão à esquerda.
Provavelmente, o método ágil mais conhecido é a Extreme Programming (BECK, 1999; BECK, 2000), que descre- vo adiante neste capítulo. Outras abordagens ágeis incluem Scrum (COHN, 2009; SCHWABER, 2004; SCHWABER e BEEDLE, 2001), Crystal (COCKBURN, 2001; COCKBURN, 2004), Desenvolvimento de Software Adaptativo (Adaptative Software Development), (HIGHSMITH, 2000), DSDM (STAPLETON, 1997; STAPLETON, 2003) e Desenvolvimento Diri- gido a Características (Feature Driven Development), (PALMER e FELSING, 2002). O sucesso desses métodos levou a uma certa integração com métodos mais tradicionais de desenvolvimento baseados na modelagem do sistema, resultando no conceito de modelagem ágil (AMBLER e JEFFRIES, 2002) e instâncias ágeis do Rational Unified Process (LARMAN, 2002).
Embora esses métodos ágeis sejam todos baseados na noção de desenvolvimento e entrega incremental, eles propõem diferentes processos para alcançar tal objetivo. No entanto, compartilham um conjunto de prin- cípios, com base no manifesto ágil, e por isso têm muito em comum. Esses princípios são mostrados na Tabela 3.1. Diferentes métodos ágeis instanciam esses princípios de maneiras diferentes, e eu não tenho espaço para discutir todos os métodos ágeis. Em vez disso, foco em dois dos mais usados: Extreme Programming (Seção 3.3) e Scrum (Seção 3.4).
Tabela 3.1 Os princípios dos métodos ágeis
Princípios Descrição
Envolvimento do cliente
Os clientes devem estar intimamente envolvidos no processo de
desenvolvimento. Seu papel é fornecer e priorizar novos requisitos do sistema e avaliar suas iterações.
Entrega incremental O software é desenvolvido em incrementos com o cliente, especificando os requisitos para serem incluídos em cada um.
Pessoas, não processos
As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas. Membros da equipe devem desenvolver suas próprias maneiras de trabalhar, sem processos prescritivos.
Aceitar as mudanças Deve-se ter em mente que os requisitos do sistema vão mudar. Por isso, projete o sistema de maneira a acomodar essas mudanças.
Manter a simplicidade
Focalize a simplicidade, tanto do software a ser desenvolvido quanto do processo de desenvolvimento. Sempre que possível, trabalhe ativamente para eliminar a complexidade do sistema.
41
Capítulo 3 Desenvolvimento ágil de software
Métodos ágeis têm sido muito bem-sucedidos para alguns tipos de desenvolvimento de sistemas:
1. O desenvolvimento de produtos, em que uma empresa de software está desenvolvendo um produto pequeno
ou médio para venda.
2. Desenvolvimento de sistema personalizado dentro de uma organização, em que existe um compromisso claro
do cliente de se envolver no processo de desenvolvimento, e em que não há muitas regras e regulamentos externos que afetam o software.
Como discuto na seção final deste capítulo, o sucesso dos métodos ágeis indica que há um grande interesse em usar esses métodos para outros tipos de desenvolvimento de software. No entanto, devido a seu foco em pe- quenas equipes bem integradas, existem problemas em escalá-los para grandes sistemas. Existem também experi- ências de uso de abordagens ágeis para engenharia de sistemas críticos (DROBNA et al., 2004). No entanto, devido à necessidade de proteção, segurança e análise de confiança em sistemas críticos, exigem-se modificações signi- ficativas nos métodos ágeis antes que possam ser rotineiramente usados para a engenharia de sistemas críticos.
Na prática, os princípios básicos dos métodos ágeis são, por vezes, difíceis de se concretizar:
1. Embora a ideia de envolvimento do cliente no processo de desenvolvimento seja atraente, seu sucesso depende
de um cliente disposto e capaz de passar o tempo com a equipe de desenvolvimento, e que possa representar todos os stakeholders do sistema. Frequentemente, os representantes dos clientes estão sujeitos a diversas pres- sões e não podem participar plenamente do desenvolvimento de software.
2. Membros individuais da equipe podem não ter personalidade adequada para o intenso envolvimento que é
típico dos métodos ágeis e, portanto, não interagem bem com outros membros da equipe.
3. Priorizar as mudanças pode ser extremamente difícil, especialmente em sistemas nos quais existem muitos
stakeholders. Normalmente, cada stakeholder dá prioridades diferentes para mudanças diferentes.
4. Manter a simplicidade exige um trabalho extra. Sob a pressão de cronogramas de entrega, os membros da
equipe podem não ter tempo para fazer as simplificações desejáveis.
5. Muitas organizações, principalmente as grandes empresas, passaram anos mudando sua cultura para que os
processos fossem definidos e seguidos. É difícil para eles mudar de um modelo de trabalho em que os proces- sos são informais e definidos pelas equipes de desenvolvimento.
Outro problema não técnico — que é um problema geral do desenvolvimento e da entrega incremental — ocorre quando o cliente do sistema usa uma organização externa para desenvolver o sistema. O documento de requisitos do software é normalmente parte do contrato entre o cliente e o fornecedor. Como a especificação incremental é inerente aos métodos ágeis, escrever contratos para esse tipo de desenvolvimento pode ser difícil.
Consequentemente, os métodos ágeis têm de contar com contratos nos quais o cliente paga pelo tempo necessário para o desenvolvimento do sistema, e não pelo desenvolvimento de um determinado conjunto de requisitos. Enquanto tudo vai bem, isso beneficia o cliente e o desenvolvedor. No entanto, se surgirem problemas, poderão acontecer disputas nas quais fica difícil definir quem é culpado e quem deve pagar pelo tempo extra, bem como os recursos necessários para a solução dos problemas.
A maioria dos livros e artigos que descrevem os métodos ágeis e experiências com eles fala sobre o uso desses métodos para o desenvolvimento de novos sistemas. No entanto, como explico no Capítulo 9, um enorme esforço da engenharia de software é dedicado à manutenção e à evolução de sistemas de software já existentes. Existe apenas um pequeno número de relatos de experiências com o uso de métodos ágeis na manutenção de software (POOLE e HUISMAN, 2001). Há duas questões que devem ser consideradas ao tratarmos de métodos ágeis e ma- nutenção:
1. É possível fazer manutenção dos sistemas desenvolvidos em uma abordagem ágil, dada a ênfase do processo
de desenvolvimento em minimização da documentação formal?
2. Os métodos ágeis podem, efetivamente, ser usados para a evolução de um sistema em resposta às solicitações
de mudança do cliente?
Supostamente, a documentação formal deve descrever o sistema e, assim, tornar sua compreensão mais fácil para as pessoas que fazem as mudanças. Porém, na prática, a documentação formal nem sempre é atualizada, e, portanto, não reflete exatamente o código do programa. Por essa razão, os entusiastas de métodos ágeis argumen- tam que é um desperdício de tempo criar essa documentação e que a chave para a implementação de software manutenível é a produção de códigos de alta qualidade, legíveis. Práticas ágeis, portanto, enfatizam a importância de se escrever códigos bem-estruturados e investir na melhoria do código. Portanto, a falta de documentação não deve ser um problema na manutenção dos sistemas desenvolvidos por meio de uma abordagem ágil.
42 Engenharia de software
No entanto, minha experiência em manutenção de sistemas sugere que o documento-chave é o documento de requisitos do sistema, que informa ao engenheiro de software o que o sistema deve fazer. Sem esse conhe- cimento, é difícil avaliar o impacto das mudanças propostas. Muitos métodos ágeis coletam requisitos informal- mente, de forma incremental, e não desenvolvem um documento coerente de requisitos. Nesse sentido, o uso de métodos ágeis pode tornar mais difícil e cara a manutenção posterior do sistema.
Práticas ágeis, usadas no processo de manutenção em si, provavelmente são mais eficazes, independente de ter sido usada uma abordagem ágil para o desenvolvimento do sistema. Entrega incremental, projeto para mudan- ças e manutenção da simplicidade — tudo isso faz sentido quando o software está sendo alterado. Na verdade, você pode pensar em um processo ágil de desenvolvimento como um processo de evolução do software.
No entanto, a principal dificuldade após a entrega do software é manter o envolvimento dos clientes no pro- cesso. Apesar de, durante o desenvolvimento do sistema, um cliente poder justificar o envolvimento de um re- presentante em tempo integral, isso é menos provável durante a manutenção, período em que as mudanças não são contínuas. Representantes do cliente são propensos a perder o interesse no sistema. Portanto, para criar novos requisitos do sistema podem ser necessários mecanismos alternativos, como as propostas de mudanças discutidas no Capítulo 25.
O outro problema que pode surgir está relacionado à continuidade da equipe de desenvolvimento. Métodos ágeis dependem de os membros da equipe compreenderem aspectos do sistema sem consultar a documentação. Se uma equipe de desenvolvimento ágil é alterada, esse conhecimento implícito é perdido, e é difícil para os novos membros da equipe construir o mesmo entendimento do sistema e seus componentes.
Os defensores dos métodos ágeis foram evangelizadores na promoção do uso desses métodos e tenderam a negligenciar suas deficiências. Isso provocou uma resposta igualmente extrema, que, em minha opinião, exagera os problemas dessa abordagem (STEPHENS e ROSENBERG, 2003). Críticos mais fundamentados, como DeMarco e Boehm (2002), destacam as vantagens e desvantagens dos métodos ágeis. Eles propõem uma abordagem híbrida, na qual os métodos ágeis incorporam algumas técnicas do desenvolvimento dirigido a planos, que pode ser o melhor caminho a seguir.
3.2 Desenvolvimento ágil e dirigido a planos
Abordagens ágeis de desenvolvimento de software consideram o projeto e a implementação como ativida- des centrais no processo de software. Eles incorporam outras atividades, como elicitação de requisitos e testes no projeto e na implementação. Em contrapartida, uma abordagem de engenharia de software dirigida a planos identifica estágios distintos do processo de software com saídas associadas a cada estágio. As saídas de um estágio são usadas como base para o planejamento da atividade do processo a seguir. A Figura 3.1 mostra as distinções entre as abordagens dirigidas a planos e ágil para a especificação do sistema.
Em uma abordagem dirigida a planos, ocorrem iterações no âmbito das atividades com documentos formais, usados 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. Essa é, então, 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 e a entrega incremental. É per- feitamente possível alocar requisitos e planejar as fases de projeto e desenvolvimento como uma série de incre- mentos. Um processo ágil não é, inevitavelmente, focado no código, e pode produzir alguma documentação de projeto. Como vou discutir na seção seguinte, a equipe de desenvolvimento ágil pode decidir incluir um ‘spike’ de documentação, no qual, em vez de produzir uma nova versão de um sistema, a equipe produz documentação do sistema.
Na verdade, a maioria dos projetos de software inclui práticas das abordagens dirigidas a planos e ágil. Para optar por um equilíbrio entre as abordagens, você precisa responder a uma série de questões técnicas, humanas e organizacionais:
1. É importante ter uma especificação e um projeto muito detalhados antes de passar para a implementação? Se
sim, você provavelmente necessita usar uma abordagem dirigida a planos.
2. É realista uma estratégia de entrega incremental em que você entrega o software aos clientes e rapidamente
obtém um feedback? Em caso afirmativo, considere o uso de métodos ágeis.
43
Capítulo 3 Desenvolvimento ágil de software
3. Quão grande é o sistema que está em desenvolvimento? Os métodos ágeis são mais eficazes quando o sistema
pode ser desenvolvido com uma pequena equipe colocalizada capaz de se comunicar de maneira informal. Isso pode não ser possível para sistemas de grande porte que exigem equipes de desenvolvimento maiores — nesse caso, uma abordagem dirigida a planos pode ter de ser usada.
4. Que tipo de sistema está sendo desenvolvido? Sistemas que exigem uma análise profunda antes da imple-
mentação (por exemplo, sistema de tempo real com requisitos de tempo complexos) geralmente demandam um projeto bastante detalhado para atender a essa análise. Nessas circunstâncias, uma abordagem dirigida a planos pode ser a melhor opção.