Uma das formas mais interessantes de ilustrar o ganho com uma metodologia ágil é trabalhar em cima do conceito de valor. Você quer mostrar aos seus colegas a principal diferença entre processos ágeis e processos tradicionais? A resposta para essa pergunta está neste post.Observe o gráfico abaixo. Você consegue associar a relação “esforço x tempo” ao conceito de geração de valor?
O gráfico representa o esforço realizado em um projeto em relação ao tempo. Vamos analisar o que acontece nos dois cenários.
No método tradicional, normalmente se inicia com toda a fase de requisitos. Senta-se com o cliente, discute contrato, depois requisitos de todo o projeto. Raramente são discutidos se os requisitos irão gerar, de fato, valor ao projeto. A idéia aqui é apenas mapear tudo o que o cliente quer. Após a geração de uma vasta documentação (documento de projeto, documento de start-up, declaração do escopo, cronograma, etc. todos – teoricamente – aprovados pelo cliente) o projeto é devidamente iniciado. Nas primeiras reuniões com a equipe são discutidos todos os casos de uso que serão implementados. A equipe acaba começando pelo mais fácil. O cliente só é consultado em pontos pré-definidos (aprovação de layout, homologação, etc), ou seja, um dia ele verá o sistema… pronto. A equipe normalmente começa a se desesperar ao perceber que não dará conta das deadlines com tantas funcionalidades difíceis a serem implementadas.
O resultado disso? O que era mais difícil foi deixado para o fim. Só que o tempo é cruel e não pára. Logo, o esforço sobe de forma vertiginosa no final do projeto. Cronogramas atrasam, testes e bugs são esquecidos, horas extras explodem, o escopo acaba sendo mudado apenas para agradar o já furioso cliente. Inclusive aquela funcionalidade absurda que foi pedida lá no início do projeto, para que o sistema “toque uma música divertida toda vez que for aniversário de alguém”. Funcionalidade, aliás, que foi uma das mais complexas de serem feitas.
E como seria no método ágil? Temos uma total inversão de mentalidade! Após uma breve discussão de contrato com o cliente, toda a equipe senta com o cliente e as funcionalidades são discutidas. É o momento da criação das estórias. Após terem um material suficiente, o cliente é convidado a priorizar o que é mais importante para ele. Enquanto é discutido isso, uma pessoa da equipe se dá conta da funcionalidade “toque uma música divertida toda vez que for aniversário de alguém” e comenta com o cliente da real necessidade da função. O cliente diz que quer, de fato isso, mas aceita priorizar outras coisas na frente. A equipe inicia o desenvolvimento com base no que foi definido para cada ciclo. O cliente é convidado a participar ativamente do desenvolvimento. Dúvidas são tiradas diretamente com ele. Soluções alternativas são propostas em alguns casos e já no primeiro ciclo o cliente vê funcionalidades importantes do seu sistema entregues. Em alguns casos já pode sair inclusive utilizando! Ao final de um dos ciclos, mesmo antes do final do desenvolvimento de todas as funcionalidades, o cliente já se dá por satisfeito e diz que tem tudo o que precisa. Ele se dá conta que a funcionalidade “toque uma música” de fato era totalmente inútil e pede para a equipe esquecê-la.
O resultado disso? O cliente participa ativamente do desenvolvimento. Ele vê como o seu dinheiro está sendo aplicado, ele sabe de antemão de qualquer problema, ele confia na equipe, ele sabe que pode acrescentar novas funcionalidades quando quiser… para ele fica claro que será desenvolvido o que tem mais valor! E mais do que isso, ele vê valor logo no fim do primeiro ciclo. O prazo é cumprido e, em alguns casos, até mesmo antecipado.
Notem como os dois casos são ilustrados no gráfico. E observem como o método ágil proporciona ao cliente um acompanhamento e, mais do que isso, uma colaboração direta com seus parceiros. O conceito de valor não precisa sequer ser explicado. Se você o compreendeu a mensagem deste artigo, então poderá responder a pergunta que entitula este texto.
Toda vez que você tiver que enfrentar um cliente furioso devido aos atrasos de cronograma, negociações de contrato e demais atritos comuns, lembre-se: com um pouco de vontade isso pode ser mudado 
Um grande abraço!
Muito bom o post Flavio!
Só discordo do gráfico apresentado. Acredito que ele ficaria mais ou menos assim: http://img81.yfrog.com/i/esforoxtempo.jpg/
No começo do projeto, a equipe ainda está compreendendo o projeto, por isso o esforço vai crescendo no início, e depois estabiliza.
E a proposta agile prega por entrega valor constantemente, então ainda teríamos aquele “corre corre” no final de um sprint, por exemplo, mas logicamente, que num grau bem menor comparado ao método tradicional.
Alguns pontos são interessantes de notar:
1. A proposta agile faz com que o esforço se torne constante;
2. Os picos antes do término de um sprint tendem a diminuir, a partir que o time se torna mais maduro;
3. Com agile, entregamos valor constantemente e a entrega final ocorre antes do método tradicional.
Abraços! E parabéns pelo EXCELENTE blog!!!
[...] Por que gerar valor só no final? - Flavio Steffens (agileway); [...]
[...] Porque Gerar Valor Só no Final? – “Uma das formas mais interessantes de ilustrar o ganho com uma metodologia ágil é trabalhar em cima do conceito de valor.” [...]
Ótimo artigo.
[]‘s
Muito bom o artigo, simples, claro e direto!
[...] Porque Gerar Valor Só no Final? – “Uma das formas mais interessantes de ilustrar o ganho com uma metodologia ágil é trabalhar em cima do conceito de valor.” [...]