Quando falamos de agilidade, é bem comum pensarmos em Scrum, XP, Kanban ou ainda em programação pareada e TDD. Estamos acostumados a pensar em algum processo ou prática ágil. Isso não é um problema, mas essas são todas formas de aplicar os conceitos mais fundamentais, que definem o que é Agile.
Fazer uma visita à página do Manifesto Ágil de tempo em tempo para revisar a definição da agilidade e rever comportamentos recentes é uma ideia que é aplicada e recomendada a todos.
O Manifesto é, no entanto, apenas a porta de entrada. Seguindo, caímo-nos Princípios Ágeis: fases mais específicas e mais fáceis de pôr em prática imediatamente! Nesse post vamos destrinchar esses princípios, onde eles se aplicam e ver quais práticas está associado a eles.
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 si não podem ser contadas como evidência de que o projeto anda bem. Só o produto do desenvolvimento é que conta.
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 para o cliente entender o que vai trazer mais valor ainda em um futuro próximo: só mesmo usando o sistema é que percebemos que alguns detalhes que ficaram de fora são muito importantes para o usuário e que 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 princípio seguinte.
Entregar o software funcionando e 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.
Contudo, 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 os agilistas, levam tais mudanças como acontecimentos normais e oportunidades.
Receber bem a mudança de requisitos, mesmo se o projeto estiver em desenvolvimento, irá facilitar o processo ágil, sendo que essas mudanças são uma vantagem para o 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 do 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. Sempre é bom manter um product backlog devidamente priorizado, isso facilita imensamente na troca de requisitos e na visibilidade do que será removido do projeto com a entrada de uma nova necessidade.
Figura 1: Princípios ágeis: entrega de valor
Práticas relacionadas são agora os princípios e 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, melhorar 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 ser utilizável o mais cedo possível permite que os feedbacks sejam assertivos;
Iteração / Sprint: uma das formas de trabalho incremental, a iteraçã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 são métodos que trabalham com fluxo contínuo e 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 e o time de desenvolvimento é uma excelente oportunidade de criar um ambiente de críticas produtivas, focando na melhoria do software em um todo.
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 e possibilita o acompanhamento mais fino da consistência do projeto e é pré-requisito para a próxima;
Entrega contínua: uma vez que seus processos de build estejam automatizados, com mais alguns poucos passos é possível automatizar também a entrega de software e, quanto mais fácil fazê-la, menos empecilhos para entregar desde cedo e com boa frequência.
E você? Como interpreta cada um dos princípios?
Então finalizamos aqui este breve artigo. Quaisquer dúvidas, sugestões ou críticas podem ser registradas na seção de comentários, abaixo.
Um grande abraço!
