Princípios ágeis revisitados: entrega de valor

O Manifesto é, no entanto, apenas a porta de entrada. Seguindo o próximo link, caímos nos Princípios Ágeis: frases mais específicas e mais fáceis de por em prática imediatamente! Nessa série de posts, vamos destrinchar esses princípios, mostrando exemplos de onde eles se aplicam e ver quais práticas estão associadas a eles.

Vale dizer que a ordem não será a mesma da página original e que a tradução é uma versão nossa. Comecemos!

Software funcionando é a primeira medida de progresso.

Esse princípio toca em um assunto delicado: ele desafia as medidas tradicionais de progresso que incluem geração de documentos, análise e design como formas de ver que um projeto está andando.

Note, contudo, que ele não impede a criação da mesma documentação e nem entra em conflito com equipes formadas por especialistas de cada área. Apenas diz que a construção das documentações e as fases pré-desenvolvimento em sí não podem ser contadas como evidência de que o projeto anda bem. Só o produto do desenvolvimento é que conta.

Essa idéia é fortemente complementada pelo próximo princípio.

Nossa maior prioridade é satisfazer o cliente através de entregas frequentes e desde cedo de software de valor.

Entregar valor o mais cedo possível ajuda o cliente a entender o que vai trazer mais valor ainda em um futuro próximo: só mesmo usando o sistema é que percebemos que alguns detalhezinhos que ficaram de fora são muito importantes para o usúário e qie outros planos mirabolantes feitos a princípio seriam desnecessários.

Aqui entra o conceito de desenvolvimento incremental priorizando a felicidade do cliente e do entendimento de que software é orgânico e deve crescer como tal. E para que ele tome o rumo necessário, falamos do príncipio seguinte.

Entregue software funcionando com frequência, em intervalos de semanas ou meses, dando preferência para períodos mais curtos.

As entregas com frequência destacadas aqui aparecem por uma razão simples: não é possível ter a certeza de que estamos avançando pelo caminho certo enquanto o software não tiver usuários reais.

Pense em quantos pontos de potencial perda de informação um projeto tem: quando o cliente fala com o levantador de requisitos, quando este repassa para o restante da equipe e, progressivamente -- quanto mais especialistas no meio do caminho, mais falhas podem acontecer. E ainda que seu time funcione perfeitamente bem, seu cliente ainda tem a potencial falha de comunicação com os usuários reais do sistema.

Agora, esse feedback constante cria uma situação que os métodos tradicionais tratam como um grande problema: o cliente vai tender a fazer novos pedidos e mudanças no que havia sido combinado. E, como o último princípio desse post ilustra, agilistas levam tais mudanças como acontecimentos normais e oportunidades.

Receba bem a mudança de requisitos, mesmo tardias no desenvolvimento. Processos ágeis encaram mudanças para vantagem competitiva do cliente.

Muitas vezes temos fortes convicções sobre o que um software vai ser quando completo e se viciar nessas expectativas iniciais é uma perigosa armadilha: é mais do que comum que encontremos formas melhores de resolver problemas do que as previstas no início do projeto.

Esse apego a um plano inicial prejudica o potencial do projeto e não são poucas as histórias de terror que ouvimos por aí de casos que seguiram um plano inicial e, no fim, não foram implantados por incompatibilidades com a realidade.

O problema de entendimento que acontece sobre esse princípio é atrelar o recebimento de novos requisitos à necessidade do aumento de prazo ou do custo do projeto. Embora essas soluções devam ser consideradas, elas não são as únicas possibilidades! Manter um product backlog devidamente priorizado facilita imensamente na troca de requisitos e na visibilidade do que será removido do projeto com a entrada de uma nova necessidade.

Práticas relacionadas

Agora que já conhecemos esses princípios e vimos exemplos de suas aplicações, uma sopa de letrinhas de artefatos, práticas e papéis para você saber o que procurar para se aprofundar nesses assuntos:

Product Backlog

manter uma lista priorizada do que há para fazer melhora a visibilidade das trocas que estão sendo feitas e dos efeitos delas;

Product Owner / Cliente próximo

o cliente próximo é o que nos dá a certeza de que o projeto está andando no melhor caminho possível e colaborar com esse cliente é fundamental;

Desenvolvimento incremental

a construção de partes do software que foca em ele ser utilizável o mais cedo possível permite que os feedbacks sejam assertivos;

Iteração / Sprint

uma das formas de trabalho incremental, as iterações são uma delimitação pequena de tempo que tem o propósito de agregar valor para o cliente, com a vantagem de adicionar um foco palpável e com prazo próximo de entrega para a equipe de desenvolvimento;

Fluxo contínuo

outra forma de desenvolvimento incremental, métodos que trabalham com fluxo contínuo focam em entregar o item de maior importância o mais cedo possível, sem a pré-delimitação de trabalho por tempo;

Review Meeting

a reunião que junta em uma mesma sala os usuários (preferencialmente, na nossa opinião) e o time de desenvolvimento é uma excelente oportunidade de criar um ambiente de críticas produtivas, focando na melhoria do software em sí.

Automatização de build

linguagens diversas têm boas ferramentas de automatização do build de projetos. Essa prática se associa aos princípios na possiblitação do acompanhamento mais fino da consistência do projeto e é pré-requisito para a próxima;

Entrega contínua

uma vez que seu processo de build esteja automatizados, com mais alguns poucos passos é possível automatizar também a entrega de software e, quanto mais fácil fazê-la, menos impecilhos para entregar desde cedo e com boa frequência.

E aí? Quais desses princípios você segue e quais deles ainda precisam ser absorvidos? Compartilhe conosco seus próprios exemplos de aplicação desses quatro princípios e os desafios que você enfrenta ao seguí-los no ambiente em que você está!

Você pode aprender mais sobre o assunto em nosso curso PM-83, onde discutimos sobre agilidade, Scrum, XP, ou em nosso curso PM-87, onde falamos sobre TDD, programação pareada, e outras práticas.

E você? Como interpreta cada um dos princípios?