Princípios

Os valores anteriores inspiraram os 12 princípios a seguir. Esses princípios são as carac- terísticas que diferenciam um conjunto de práticas ágeis de um processo peso-pesado. 1. Nossa maior prioridade é satisfazer o cliente com a entrega antecipada e contínua

de software de valor. O MIT Sloan Management Review publicou uma análise das práticas de desenvolvimento de software que ajudam as empresas a fazer produtos de alta qualidade.1 O artigo revelou várias práticas que tinham um impacto signi- ficativo na qualidade do sistema final. Uma delas era uma forte correlação entre qualidade e a entrega antecipada de um sistema em funcionamento parcial. O artigo relatou que quanto menos funcional é a entrega inicial, maior é a qualidade na

1

“Product-Development Practices That Work: How Internet Companies Build Software”, MIT Sloan Manage-

36

entrega final. O artigo também revelou uma forte correlação entre a qualidade final e entregas frequentes de funcionalidade crescente. Quanto mais frequentes são as entregas, maior é a qualidade final.

Um conjunto de práticas ágeis faz entregas antecipada e frequentemente. Esfor- çamo-nos para entregar um sistema rudimentar dentro das primeiras semanas do início do projeto. Daí em diante, nos esforçamos para continuar a entregar sistemas com funcionalidade crescente a cada poucas semanas. Os clientes podem optar por colocar esses sistemas em produção, se acharem que são funcionais o bastante. Ou podem optar simplesmente por examinar a funcionalidade existente e informar as alterações que desejam fazer.

2. Mudanças nos requisitos são bem-vindas, mesmo com o desenvolvimento já adian- tado. Os processos ágeis canalizam a mudança para a vantagem competitiva do cliente. Essa é uma declaração de atitude. Os participantes de um processo ágil não têm medo de mudanças. Eles consideram as mudanças nos requisitos como coisas boas, pois elas significam que a equipe aprendeu mais sobre o que será necessário para satisfazer o cliente.

Uma equipe ágil trabalha arduamente para manter a estrutura de seu software flexível, a fim de que, quando os requisitos mudarem, o impacto no sistema seja mí- nimo. Mais adiante neste livro, discutiremos os princípios, os padrões e as práticas de projetos orientados a objetos que nos ajudam a manter esse tipo de flexibilidade. 3. Entregar com frequência software funcionando, de poucas semanas a poucos me- ses, dando preferência à escala de tempo mais curta. Entregamos software que funciona e o entregamos antecipada e frequentemente. Não ficamos contentes de entregar um punhado de documentos ou planos. Não consideramos isso como ver- dadeiras entregas. Nossa atenção está no objetivo de entregar software que atenda as necessidades do cliente.

4. Executivos e desenvolvedores devem trabalhar juntos diariamente ao longo de todo o projeto. Para que um projeto seja ágil, clientes, desenvolvedores e interessa- dos devem ter uma interação significativa e frequente. Um projeto de software não é como uma arma do tipo “atire e esqueça”. Um projeto de software deve ser continua- mente orientado.

5. Construir projetos com indivíduos motivados. Fornecer a eles o ambiente e o apoio necessários e ter confiança de que eles farão o trabalho. As pessoas são o fator de sucesso mais importante. Todos os outros fatores – processo, ambiente, administra- ção etc. – são de segunda ordem e estão sujeitos à mudança, caso estejam prejudi- cando as pessoas.

6. O método mais eficiente e eficaz de transmitir informações para e dentro de uma equipe de desenvolvimento é a conversa face a face. Em um projeto ágil, as pes- soas falam umas com as outras. O principal modo de comunicação é a interação humana. Os documentos escritos são criados e atualizados de forma incremental no mesmo cronograma que o software e somente quando necessário.

7. Software funcionando é a principal medida do progresso. Os projetos ágeis medem seu progresso pela quantidade de software que está satisfazendo a necessidade do cliente atualmente. Eles não medem o progresso em termos da fase em que estão nem pelo volume de documentação que foi produzida ou pela quantidade de código de infraestrutura criada. Eles estão 30% prontos quando 30% da funcionalidade ne- cessária está funcionando.

8. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem manter um ritmo constante indefinidamen- te. Um projeto ágil não é como uma corrida de 50 metros; é como uma maratona. A equipe não parte a toda velocidade e tenta manter essa velocidade durante o percurso. Em vez disso, ela corre em um ritmo rápido, porém sustentável. Correr demais leva ao esgotamento, a atalhos e ao fracasso. As equipes ágeis têm seu rit- mo próprio. Elas não se permitem ficar cansadas demais. Não utilizam a energia de amanhã para fazer um pouco mais hoje. Elas trabalham em uma velocidade que lhes permite manter os padrões de qualidade mais alta durante todo o proje- to.

9. Atenção contínua à excelência técnica e ao bom projeto aumenta a agilidade. Alta qualidade é o segredo da alta velocidade. O modo de ir rápido é manter o software o mais limpo e robusto possível. Assim, todos os membros da equipe ágil estão com- prometidos a produzir somente o código da mais alta qualidade que puderem. Eles não fazem bagunça e depois dizem para si mesmos que arrumarão tudo quando tiverem mais tempo. Eles arrumam toda a bagunça quando ela é feita.

10. Simplicidade – a arte de maximizar o volume de trabalho que não precisou ser feito – é essencial. As equipes ágeis não tentam construir o sistema grandioso no céu. Em vez disso, elas sempre tomam o caminho mais simples que seja coerente com seus objetivos. Elas não dão muita importância à antecipação dos problemas de amanhã e também não tentam se defender de todos os de hoje. Em vez disso, fazem o trabalho mais simples e de qualidade mais alta hoje, confiantes de que ele será mais fácil de alterar, se e quando os problemas de amanhã surgirem.

11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organi- zadas. Uma equipe ágil é auto-organizada. As responsabilidades não são dadas de fora aos membros individuais da equipe, mas, em vez disso, são comunicadas para a equipe como um todo. A equipe determina a melhor maneira de cumprir essas responsabilidades.

Os membros da equipe ágil trabalham juntos em todos os aspectos do pro- jeto. Cada membro pode contribuir com o todo. Nenhum membro da equipe sozi- nho é exclusivamente responsável pela arquitetura, pelos requisitos ou pelos tes- tes. A equipe compartilha essas responsabilidades e cada membro tem influência sobre elas.

12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, en- tão, adapta e ajusta seu comportamento de forma correspondente. Uma equipe ágil ajusta continuamente sua organização, suas regras, suas convenções, seus re- lacionamentos etc. Uma equipe ágil sabe que seu ambiente está mudando continua- mente e que deve mudar com ele para permanecer ágil.

Conclusão

O objetivo profissional de todo desenvolvedor de software e de toda equipe de desenvolvi- mento é proporcionar o maior valor possível para empregadores e clientes. Apesar disso, nossos projetos muitaz vezes fracassam ou não proporcionam valor. A espiral ascendente da inflação do processo, embora bem intencionada, é culpada por pelo menos parte desse fracasso. Os princípios e valores do desenvolvimento ágil de software foram concebidos como um modo de ajudar as equipes a romper o ciclo da inflação do processo e para se concentrar em técnicas simples a fim de atingir seus objetivos.

38

Quando escrevíamos este livro, havia muitos processos ágeis para se escolher: Scrum,2 Crystal,3 desenvolvimento baseado em recursos (FDD),4 desenvolvimento adap- tativo de software (ADP)5 e Programação Extrema (XP).6 Contudo, a ampla maioria das equipes ágeis bem-sucedidas tem recorrido a todos esses processos para ajustar sua for- ma de agilidade. Essas adaptações parecem se aglutinar em torno de uma combinação de Scrum e XP, na qual as práticas de Scrum são utilizadas para gerenciar várias equipes que usam XP.

Bibliografia

[Beck99] Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.

[Highsmith2000] James A. Highsmith, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House, 2000.

[Newkirk2001] James Newkirk and Robert C. Martin, Extreme Programming in Practice, Addison-Wesley, 2001. 2 www.controlchaos.com 3 crystalmethodologies.org 4

Peter Coad, Eric Lefebvre and Jeff De Luca, Java Modeling in Color with UML: Enterprise Components

and Process, Prentice Hall, 1999.

5

[Highsmith2000]

6

Capítulo 2

VISÃO GERAL DA