sexta-feira, 14 de dezembro de 2018

Ágil


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.

Assim, a linha p evolui por módulos. Pequenos vetores, representando o tempo t e o esforço e indo a uma direção que é constantemente validada. Cada final de módulo representa o início do próximo, sempre corrigindo o curso para o objetivo final F.

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.

Nenhum comentário:

Postar um comentário