No primeiro post relacionado ao aniversário de 10 anos do manifesto Ágil, publicado aqui no blog, sugeri a leitura do artigo escrito por Martin Fowler e Jim Highsmith, publicado em 2001, falando a cerca do Manifesto Ágil e seus princípios. Apresento então, o que eles comentaram sobre o 7º princípio do manifesto: Software funcionando é a principal medida de progresso (Working software is the primary measure of progress). Eles disseram o seguinte:
Muitas vezes, temos visto equipes de projeto que não percebem que estão com problemas até pouco tempo antes da entrega. Eles fizeram os requisitos no prazo, o projeto em tempo, talvez até mesmo o código no tempo previsto, mas os testes e a integração demorou muito mais do que eles imaginavam.
Nós favorecemos primariamente o desenvolvimento iterativo porque proporciona marcos que não podem ser falsificados, o que dá uma medida precisa do progresso e um profundo entendimento dos riscos envolvidos em qualquer projeto. Como Chet Hendrickson, co-autor de Extreme Programming Installed (Addison-Wesley, 2000), observa: "Se um projeto vai falhar, eu prefiro saber disso depois de um mês do que depois de 15."
"Software funcionando é a medida de progresso, porque não há outra maneira de captar as sutilezas dos requisitos: Documentos e diagramas são demasiadamente abstratos para permitir que o usuário 'chute os pneus"(*)', diz Dave Thomas, co-autor de The Pragmatic Programmer (Addison-Wesley, 1999).
A metodologia ágil, com suas curtas iterações permite ao cliente ter o conhecimento de como o projeto está evoluindo, ou não. Ao final de cada iteração é esperado um incremento do produto, ou seja, software funcionando. O trabalho de uma iteração não pode quebrar o que já está funcionando, ao contrário, deve agregar mais valor ao que já se tinha. Portanto, o importante é entregar ao final de cada iteração o produto funcionando com o que foi priorizado a ser feito.
O produto sendo incrementado a cada iteração, permite ao dono do produto avaliar se o que já se tem está de acordo com o esperado ou não. Como Martin Fowler e Jim Highsmith disseram: "Software funcionando é a medida de progresso, porque não há outra maneira de captar as sutilezas dos requisitos…" Nem sempre a especificação do sistema consegue expressar de forma precisa e exata o que se espera do software. Mas ao vê-lo funcionando cria-se uma dinâmica, onde o dono do produto e a equipe possuem base para discutir o que ficou bom e o que não ficou e o que pode ser melhorado e acrescentado.
Soma-se também o fato de que se o projeto tem risco de insucesso, é melhor saber o quanto antes para que medidas sejam tomadas. O objetivo do desenvolvimento de um projeto, acima de tudo, é ser bem sucedido. Não é desejo de ninguém nadar, nadar e morrer na praia. Mas infelizmente é possível isso acontecer e por diversas razões. Exemplos:
- Deixar os testes para o final e perceber que o que foi implementado está falhando e não há mais tempo e orçamento para correção.
- O sistema implementado agrega pouco valor para o usuário final.
- O sistema tem a usabilidade baixa e com isso o sistema fica sem uso ou até mesmo nem chega a ser implantado.
- O que foi implementado não era exatamente o que o dono do produto queria.
- O sistema está com diversos bugs dificultando o seu uso.
- O sistema já não tem mais valor, pois a conjuntura atual já é outra diferente de quando o sistema foi encomendado.
- O orçamento do projeto estourou e o que se tem implementado para lançamento não é o que de mais valor o sistema possui.
A lista é enorme, quem trabalha com desenvolvimento de software conhece.
Portanto, se queres avaliar como anda o progresso de seu projeto, comece avaliando como está o funcionamento de seu software. A cada iteração a equipe entrega o software funcionando com mais valor agregado? Se sim, estás no caminho certo. Continue nesse caminho de agilidade, que todos serão beneficiados: equipe e dono do produto, que ao final de cada iteração se sentem satisfeitos por verem o Retorno do Investimento em forma de produto.
(*) Chutar os pneus – tradução literal para a expressão 'kick the tires' originada da tendência das pessoas em dar um pontapé no pneu frontal do carro usado que estão avaliando para compra, para ter certeza que não são velhos e flácidos. Pneu é uma despesa extra que o consumidor não quer assumir.
