Os 12 princípios do Manifesto Ágil

Semana passada, no meu artigo Equipe ágeis querem método ágeis prometi que essa semana publicaria o Manifesto Ágil, na íntegra, lembram-se?

O Manifesto prioriza flexibilidade, equilíbrio de práticas e colaboração

Em fevereiro de 2001, uma reunião nas montanhas nevadas do estado norte-americano de Utah no resort de inverno e verão Snowbird, marcava o surgimento e propagação do paradigma dos Métodos Ágeis, disponibilizando os principais e mais eficientes métodos adotados por profissionais e empresas de software. Essa reunião desencadeou o que conhecemos hoje como Manifesto Ágil e que se tornou um grito de guerra para a indústria de software e para as dezessete pessoas que deram o primeiro grito. O Manifesto tornou uma referência na área de TI e de Gestão de Projeto.

O  Manifesto Ágil possui 12 princípios e 4 valores.

Os 4 valores

1. Indivíduos e interação entre eles - acima de processos e ferramentas;
2. Software em funcionamento - mais que documentação abrangente;
3. Colaboração com o cliente - mais que negociação de contratos;
4. Responder às mudanças - mais que seguir um plano.

Os 12 princípios

1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. Observe três palavras chaves no princípio acima: “adiantada”, “contínua” e “valor”. Projetos Ágeis focam em agregar valor ao cliente, e uma das formas de se fazer isso é produzir software o mais cedo possível de forma contínua. Quanto mais cedo o cliente receber software, mais cedo ele pode testá-lo, usá-lo e melhorá-lo. Receber software de forma contínua significa que o cliente terá periodicamente novas funcionalidades em suas mãos. Receber o software mais rapidamente e constantemente pode significar vantagens competitivas para o cliente na área em que atua. Isso é agregar valor para o cliente.

2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. Esta é uma das maiores quebras de paradigma entre os modelos Ágil e Tradicional, projetos tradicionais evitam e dificultam mudanças, isso porque em projetos tradicionais é importante seguir um plano e qualquer variação pode significar um grande risco para o sucesso do projeto, deste modo mudanças devem passar pelo controle integrado de mudanças, inúmeras aprovações revisão de impacto e replanejamento. Projetos Ágeis estão sempre de braços abertos para mudanças que agreguem mais valor ao cliente, em qualquer fase do projeto, basta o cliente reorganizar as prioridades do que deve ser feito no início de cada iteração, não importa se é um requerimento completamente novo jamais mencionado antes. Se o cliente precisa de uma mudança, por que dizer não? Por que complicar ou penalizar o cliente? Quem dita as prioridades é quem vai usar o produto, o cliente. Pode ser um conceito difícil de entender para quem trabalha há muito tempo com projetos tradicionais, mas é uma das bases do modelo Ágil.

3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos. As metodologias Ágeis trabalham com o conceito de iterações (no Scrum são chamadas de Sprint). Iterações podem ser vistas como esforços cíclicos com duração fixa, onde o trabalho a ser feito é selecionado e priorizado antes do início e então entregue no final. Uma ou mais iterações vão gerar software funcionando nas mãos do cliente, com as funcionalidades priorizadas por ele. Este princípio corrobora com o primeiro princípio, que é o de entregar software funcionando de forma adiantada e contínua.

4. Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. Houve um tempo em que desenvolvedores trabalhavam separadamente de analistas ou profissionais de negócio. Cada grupo trabalhava independentemente e normalmente seus líderes ou pessoas chave se comunicavam para fazer a ponte entre as duas equipes. Isso comumente gera desentendimentos, falta de foco, falta de comprometimento, lentidão nos processos e perda de tempo. Quem já não participou de reuniões intermináveis, poucas vezes por semana, com 10 ou mais pessoas ao mesmo tempo? Porque esse era o único momento em que a maioria estava disponível, mesmo assim ainda faltavam participantes. Usuários falavam com Analistas de Negócio, que por sua vez se comunicavam com Analistas de Sistemas e só depois de muitas rodadas e muita documentação, a demanda chegava aos desenvolvedores. No momento em que o trabalho chegava aos desenvolvedores, o cliente ou seus representantes eram liberados para outras tarefas, se havia dúvidas, estas demoravam a ser respondidas. No modelo Ágil desenvolvedores e cliente trabalham no mesmo local físico durante todo o dia e todo o projeto. A comunicação é livre e desimpedida de quaisquer barreiras. Dúvidas são respondidas imediatamente e a possibilidade de desentendimentos ou falta de clareza no que deve ser feito é praticamente eliminada.

5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. Isso parece óbvio, porém projetos tradicionais focam em líderes dizendo às suas equipes o que fazer. A pessoa com o maior cargo ou maior nível de experiência literalmente “manda” nos outros e diz a todos como o trabalho deve ser feito e por quem. Eles praticam o micro gerenciamento, o que pode trazer bastante desmotivação pela falta de autonomia e senso de responsabilidade dada à equipe, além de não desenvolver os membros da equipe. Em projetos Ágeis, as equipes se auto-organizam, todos possuem senso de responsabilidade e não precisam de alguém ao seu lado oito horas por dia dizendo que fazer. Todos conversam e discutem entre si e em consenso de forma igualitária e democrática decidem por quem e como algo será feito. Equipes Ágeis possuem autonomia para tomar decisões e se auto-organizam, como causa e consequência disso precisam estar motivadas.

6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. O modelo Ágil dá preferência à comunicação verbal e informal do que a comunicação escrita e formal. A ideia é que duas pessoas sentando juntas trabalhando numa solução é muito mais eficiente do que se elas estivessem mandando e-mails com documentos. Como vimos no princípio número quatro, reuniões intermináveis e troca de e-mails são improdutivas e podem causar desentendimentos e distorções sobre o que o cliente realmente precisa. Para cada dúvida uma nova rodada de reuniões ou e-mails extensos são produzidos. Comunicação cara a cara é a espinha dorsal do Ágil, projetos tradicionais têm o costume de produzir muito documento e fazer a comunicação de tempos em tempos em reuniões de status ou revisões. Nada substitui uma conversa cara a cara, onde ambas as partes podem esclarecer um assunto de forma rápida e sem deixar sombras de dúvidas ou espaços para desentendimento. No modelo Ágil toda a equipe incluindo o cliente são colocados no mesmo ambiente de trabalho e todos têm acesso a todas as conversas e informações relativas ao projeto. (Comunicação Osmótica).

7. Software funcional é a medida primária de progresso. Projetos tradicionais se preocupam tanto em medir seu progresso e status que acabam gastando muito tempo com documentações e ferramentas. Projetos tradicionais podem tornar-se tão obcecados por manter toda a documentação sempre atualizada, que isso acaba virando um fardo para eles mesmos. Em projetos tradicionais podem-se gastar meses em fases de análise e desenho e um projeto pode ser reportado, por exemplo, como 30% completo sem mesmo antes ter iniciado sequer uma linha de código. O modelo Ágil mede progresso baseado no valor agregado ao cliente, e como visto até agora valor agregado é o mesmo que software funcionando. A medida primária para determinar o progresso de um projeto é a quantidade do produto que foi entregue ao cliente. Você jamais verá um projeto ágil reportar 40% de trabalho concluído sem que o cliente tenha algo em mãos, se ao menos 5% estiver concluído significa que o cliente já está com software funcionando.

8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. Quem nunca trabalhou num projeto onde na fase de análise tudo era uma calmaria e alegria, porém depois que a fase de desenvolvimento iniciava e conforme o projeto ia chegando ao final, toda a equipe tinha que trabalhar horas extras e finais de semana para poder cumprir o prazo? Projetos tradicionais costumam exigir esforços extras e estafar a equipe nas fases finais de execução do trabalho. No Modelo Ágil, ao contrário do que o nome pode sugerir, todos devem trabalhar focados e rapidamente sim, porém num ritmo sustentável. A ideia é que eles possam manter o mesmo ritmo indefinidamente sem que a equipe experimente cansaço ou exaustão. Trabalhar rápido e de forma otimizada, mas mantendo a integridade física e, por consequência, a motivação da equipe. Apressar e estafar a equipe não aumenta a agilidade e comumente leva à desmotivação e à queda de qualidade no trabalho.

9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade. Técnicas atuais de desenho e modelagem de software aumentam a produtividade de equipe, evitam retrabalho e permitem a entrega de software incremental. Um software bem desenhado pode ser entregue em módulos. Outras ferramentas como, por exemplo, as de geração de código com base em diagramas de classe, também podem adicionar agilidade ao projeto. Refatoração constante do código garante que ele esteja no padrão de desenvolvimento e facilita manutenção posterior ou adição de funcionalidade nova por parte da equipe.

10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. Este princípio é comum em todas a metodologias Ágeis, mas principalmente no Lean. A ideia é manter o foco no que agrega valor ao cliente e ser implacável com atividades que não agregam valor. Manter as coisas simples e eliminar o que é considerado lixo ou desperdício. Se não vai ser útil, mesmo que seja lindo e maravilhoso, não deve ser feito.

11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. A auto-organização é uma das principais características de uma equipe Ágil. Isso significa que a própria equipe decide como o trabalho será distribuído e quem vai trabalhar em cada componente, ao invés de um líder ou gerente fazer isso. Equipes auto-organizáveis se gerenciam, estimam atividades, definem padrões, tecnologia, arquitetura e resolvem conflitos entre si. Auto-organização requer indivíduos com mais autonomia e senso de responsabilidade, e pessoas com essas características são mais comprometidas e motivadas, o que gera melhores resultados, qualidade e produtividade. Esta é uma das grandes diferenças entre projetos Ágeis e tradicionais, a equipe é desafiada a pensar na melhor forma de como desenvolver algo, ao invés de receber instruções prontas de alguém. O envolvimento de toda a equipe e o entendimento requerido sobre o produto é maior.

12. Em intervalos regulares, a equipe reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. Projetos Tradicionais preveem reuniões e documentação de lições aprendidas no final de fases do projeto ou no final do projeto. O Modelo Ágil faz o mesmo, mas com mais frequência através das Retrospectivas. No final de cada iteração a equipe olha para o trabalho que foi concluído e faz uma reflexão sobre o que deu certo e o que deu errado. O que deu certo é mantido e o ambiente para que mais coisas continuem dando certo é preservado. O que deu errado é corrigido imediatamente já para a próxima iteração. Iterações podem variar de uma ou duas semanas até poucos meses, quanto menor a sua duração melhor. Isso significa que equipes ágeis vão refletir sobre seus erros e acertos com muito mais frequência do que num projeto tradicional, portanto corrigem problemas e desvios com muito mais rapidez antes que causem maiores impactos no produto e no projeto. Em projetos tradicionais isso é feito somente depois que muito trabalho já foi feito, no final de uma fase ou no final de todo o projeto. Deste modo perdem-se oportunidades de melhorias ainda na fase de execução do projeto onde elas são mais importantes. Depois que o projeto terminou, contabilizar lições aprendidas já não ajuda mais esse projeto, e sim projetos futuros.

Quer ler o Manifesto Ágil em qualquer idioma? Acesse Manifesto for Agile Software Development.

Um abraço e até a próxima semana!

Sobre o autor:

Robson Camargo, PMP, MBA, GWCPM é professor nos cursos de MBA das Principais Escolas de Negócio do País: FGV, Fundação Dom Cabral e FIA/USP com Certificação PMP – Project Management Professional emitida pelo PMI, MBA em Administração de Projetos pela FEA/USP e Master Certificate pela George Washington. Robson Camargo é autor do livro PM VISUAL e criador do Método PM VISUAL. Sua equipe realiza treinamentos e consultorias em empresas do Brasil e exterior. Está à frente da RC ROBSON CAMARGO - Projetos e Negócios, um Centro de Capacitação com um dos portfólios de treinamentos e consultorias mais completos do Brasil, na área de Gestão de Projetos e de Portfólio.

Para ver mais vídeos inscreva-se no Canal RC, no YouTube!