Imagine o ponto de partida I sendo a intersecção 0 dos
vetores altura x, comprimento y e largura z.
Imagine o objetivo final como ponto F, em qualquer lugar
de todo o plano cartesiano tridimensional.
A linha p que liga o ponto de partida I com o ponto final
F indica o esforço e e o tempo t gastos realizando o projeto para atingir o
objetivo.
Tem-se que quando a linha p é reta, o projeto teve foco
máximo e gasto mínimo, resultando no fantasioso lucro ideal.
Fantasioso, pois o ser humano não possui controle sobre a
variável tempo t, tão pouco sobre os riscos r que acometerão o projeto enquanto
o esforço e atuar desenvolvendo a linha p.
E essa falta de controle se dá desde o ponto de partida
I: o dono do projeto pode achar que o objetivo final F está em um ponto, onde
ele resolverá uma série de problemas que hoje são tidos como os mais
importantes. Porém, muitas vezes, os problemas que hoje parecem ser os mais
prementes não se mostram sequer como problemas no passar do tempo t do projeto
ao utilizar o esforço e para desenhar a linha p, muito menos no seu objetivo
final no ponto F.
Assim, qualquer milímetro de diferença entre o real e
desconhecido objetivo F e o inicial idealizado fantasioso objetivo final F já
resultam em uma distorção muito grande do projeto. Distorção essa que apenas
vai piorando conforme o tempo t e o esforço e agem sobre a linha, causando os
conhecidos prejuízos nos projetos cascatas tradicionais.
Há de se lembrar que a maioria dos projetos simplesmente
é mal arquitetado. Assim, as revisões internas criam linhas curvas p, que
passeiam por vários quadrantes do plano cartesiano x/y/z, apenas gerando mais
horas extras, mais estresse, mais brigas, menos retenção de talentos, mais
ressentimentos e, o pior de tudo, menos lucros.
Assim, a metodologia ágil chega para tentar solucionar
esse problema recorrente nos projetos tradicionais.
A metodologia ágil se baseia em duas premissas: maior
contato com o cliente e redução de ciclos de entrega.
Em um projeto tradicional, o cliente é consultado antes
da linha p começar a ser desenhada. Protótipos não-funcionais são feitos,
validados e aprovados pelo cliente. Todo o plano perfeito é apresentado,
especificando nos mínimos detalhes cada passo do projeto, do ponto I até seu
ponto F. O cliente paga por todo esse período acreditando que a equipe está
trabalhando conforme o projeto apresentado. E o cliente verá o projeto apenas
após o ponto F ser atingido. Nesse momento que o cliente conseguirá dar um
feedback real sobre o produto que encomendou.
E todos sabemos que os riscos r durante o projeto
tradicional fazem com que o projeto entregue NUNCA seja igual ao projeto
arquitetado. O ponto F nunca é atingido. E mesmo que seja atingido, muitas
vezes não era o ponto correto, com as soluções que o cliente precisava para seus
problemas reais. Na melhor das hipóteses, o sistema entregue é algo inútil.
A metodologia ágil traz o cliente para dentro do projeto.
É necessário cativar o cliente para que ele se sinta e faça parte da equipe.
Afinal de contas, é ele quem está pagando, é ele quem tem as necessidades e é
para ele que o time está trabalhando.
O cliente entra no projeto ágil no seu papel: Dono do
Produto. É ele quem está pagando, é ele quem vai usar, são dele as decisões
finais sobre o desenvolvimento do sistema.
Mas o Dono do Produto não é o especialista em tecnologia.
O Dono do produto diz ONDE o sistema deve chegar, mas não diz COMO o sistema
atingirá esse objetivo.
Assim, é papel do time de desenvolvimento extrair e
documentar as NECESSIDADES do Dono do Produto. Sempre ajudando o Dono do
Produto a encontrar as suas necessidades reais, mais prementes para aquele
momento. Se o Dono do Produto quer controlar o caixa, o controle de caixa
deverá ser feito primeiro, não o cadastro de países, estados e cidades. Coloque
essas informações em uma tabela com insert e só depois do fluxo de caixa
funcionando o time de desenvolvimento deve voltar para fazer esses cadastros
básicos. Teorema de Pareta Básico: 20% de um sistema representa 80% do seu
valor e 80% do sistema representa 20% do seu valor. É necessário encontrar e
focar nos 20% antes de mais nada.
Trazer essas necessidades para “dentro de casa” e
trabalhar em um “Time Box”: uma, duas ou três semanas. Os 20% ficaram prontos?
O Time de Desenvolvimento já tem algo funcional para apresentar para o Dono do
Produto? Algo que, caso o Dono do Produto precise, já dê para ser utilizado
resolvendo problemas reais?
Caso positivo, o Time de Desenvolvimento apresenta uma
demonstração para o Dono do Produto.
Essa apresentação é crucial para o ágil funcionar bem.
Pois o Time de Desenvolvimento começou a se movimentar a partir do ponto I e
trabalhou um esforço e em um tempo t de uma, duas ou três semanas traçando uma
pequena linha p no plano cartesiano x/y/z.
A demonstração do produto é o momento que o Dono do
Produto poderá ver o que a equipe é capaz de fazer. E não apenas isso: quais
soluções o produto está entregando. E já no final da primeira, segunda ou
terceira semana o Dono do Produto poderá dizer se o produto está atendendo suas
necessidades, se novas necessidades foram descobertas ou se o produto não está
indo para o ponto F corretamente.
O feedback do cliente vira o norte do projeto: o objetivo
final F pode ser mantido ou alterado.
O Time de Desenvolvimento deve usar esse feedback para
ajustar o rumo do projeto até a próxima demonstração do produto.
Ao eleger junto do cliente as partes mais importantes do
sistema e trabalhar nelas primeiro, já nos primeiros meses de projeto o Dono do
Produto terá uma ótima ideia do produto que receberá. Conseguirá visualizar
necessidades que não descreveu antes do projeto iniciar no ponto I. E
conseguirá detectar necessidades descritas inúteis, que não solucionam nenhum
problema e, assim, podem ser descartadas do projeto.
A utilização precoce gera alterações constantes no
planejamento do desenvolvimento do sistema. E essas alterações visam sempre
criar um produto mais alinhado com a real necessidade que ele deve suprir.
O resultado é que a linha do projeto p caminha para o
objetivo real F. A linha não é uma curva passeando por todos os quadrantes, tão
pouco é uma linha reta fantasiosa. É mais parecida com um galho, cheia de
pequenas curvas e correções. Com o trabalho mais pesado em sua base, no seu
início e, conforme o projeto se desenrola, os itens mais simples ramificados,
sendo feitos em paralelo no final.
Todos esses itens convergem para o real objetivo final F,
geralmente muito longe do ideal objetivo final F, idealizado fantasiosamente
antes do início do projeto.
Assim, temos um cliente envolvido no dia a dia do projeto,
empoderado pelas decisões de norte do produto. Temos um Time de Desenvolvimento
envolvido no projeto, empoderado pelas decisões técnicas para satisfazer as
necessidades do Dono do Produto. E temos um produto que evolui constantemente,
buscando satisfazer o mais plenamente possível o cliente.