As Multiplas Curvas S no Gerenciamento de Projetos Ageis

E bem que um dia chega o post número 100. Aleluia irmãos!

E o assunto é sobre Gráficos Burn Up/Down e Curvas S no gerenciamento de projetos ágeis.

From this [moment]...
Escrevo este post pois li algo análogo (e muito, muito bom) no site do Leading Answers, do nosso (muito bom, idem) camarada Mike Griffiths.

Na prática, este texto é quase uma cópia espúria do post dele. Apenas não confirmo isso porque, realmente, li o PDF de base (também muito bem escrito) do texto e pratiquei bastante o assunto.

Assim, acredito que não fiz uma simples cópia...

Curvas S e Gráficos de Gannt
Curvas S são típicas em projetos. Uma equipe de projeto forma uma curva S ao longo do tempo: no início, temos o gerente, o arquiteto e um analista de sistemas; logo depois a equipe vai crescendo (progamadores, projetistas, designers, testadores, etc.) e depois, novamente, ao fim do projeto ela diminui até chegar a zero. Se montarmos um gráfico disso, teremos uma curva S!

Os gráficos de Gannt (ou pseudo-Gannt, como diria meu professor no curso PMBOK) são muito bons para mostrar a hierarquia das coisas no tempo e os marcos do projeto. E, de quebra, ele nos mostra os atrasos existentes.

Em suma, cada uma dessas ferramentas pode mostrar algo bom em determinada situação.

Projetos ágeis
Projetos ágeis não se sentem confortáveis com gráficos de Gannt. Simplesmente, podemos dizer que projetos ágeis focam o Sprint corrente (e quiçá o próximo). E nada mais. Ou seja, um bonito e horizontalmente longo gráfico de Gannt não ajuda muito quando nosso (constante e iterativo) foco são os próximos 15, 21 dias de projeto ;)

Em projetos ágeis, o importante são os (plajeando o Mike e o próprio... esqueci o nome do outro autor que fala a mesma coisa) "nebulosos" points (ou, no brazuquês, pontos).

Pontos? Sim, aquela coisinha maravilhosa que os caras do XP chamam de User Stories e os caras do RUP de Use Cases e os caras da FDD de Features (embora as features têm sim uma conotação muito plausível e realmente válida no mundo dos negócios - falo mais disso outra hora).

O problema básico é que "pontos" é difícil de engolir. Imagine um GP dizendo ao cliente "...olha, neste sprint nós entregamos 113 pontos, embora o esperado era 124. Os 11 pontos de diferença foram em virtude de um problema de dependência mal calculado, o que implica que, na verdade, nós entregamos 121 pontos, ou seja, apenas 3,5% a menos dos pontos esperados...".

Enfim, um ponto não representa nada para o cliente. Ele quer saber se a funcionalidade do sistema está OK. É simples, hora essa!

Além disso...

Gráficos Burn Down/UP
Gráficos Burn Down ou mesmo os gráficos Burn Up não correlacionam uma parte vital nos projetos.

E que parte é essa? Money, é claro.

Se entrarmos em um cara (diga-se: software para gerenciamento de projetos ágeis) muito bom, como o GreenHopper no JIRA e olharmos um gráfico Burn Down ou Burn Up podemos ter claramente os pontos (ou issues) que foram desenvolvidos no sprint corrente.

Porém, cadê a relação com o dinheiro consumido no período?

Simplesmente, esses gráficos não têm isso por natureza.

Aí entra uma outra coisa no cenário...

Os Gráficos de múltiplas curvas S
Lembro dos famosos gráficos de curva S e ABC quando eu estava desenvolvendo um ERP para uma empresa, lá nos idos de 2006.

Na época eu era projetista, e meu analista de negócio falava muito desses gráficos na parte de controle e manutenção de volumes de estoque...

Depois disso, eles foram para uma parte oculta do meu cérebro até que... umas duas semanas atrás eu li o post do Mike.

Coisa linda isso.

Um gráfico de múltiplas curvas S é simples: Ele mostra a variação de uma informação (os pontos, por exemplo) em relação a outra informação (o dinheiro investido) em função de uma outra informação que, geralmente, varia de forma linear (o tempo decorrido, por exemplo - embora Einstein tenha demonstrado lá na década de 20 passada que o tempo não é tão linear assim...).

Deu pra entender? Não?

Bom, deixamos a figura falar:



Neste gráfico de múltiplas curvas S eu mostro o total de issues (no meu caso Features da FDD) do sprint comparado ao volume de dinheiro (gasto na equipe de desenvolvimento) em função do tempo decorrido para o sprint (15 dias, sendo 10 os dias úteis).

Percebam ainda que eu tenho no gráfico tanto os valores realizados quanto as estimativas (de issues e financeiras).

No caso das estimativas, isso é uma informação que vai depender de vários fatores (como ter ou não históricos de desenvolvimento; ter ou não um mapeamento claro de tipos de issues que podem existir no meu projeto/processo/metodologia; saber ou não saber enquadrar as complexidades das issues; saber ou não saber quanto sua equipe trabalha efetivamente - regra de Paretto dos 80/20 é uma boa se você não souber nada; saber ou não saber que sua equipe mudou de tamanho durante uma sprint e... uma série de outras informações :() e, é por isso que você terá um bom acerto se, e somente se, tiver uma boa base para estimativas...

Enfim, mas tendo ou não as estimativas, o gráfico ainda mostra em background as partes (ou módulos, ou ainda - como preconizam a FDD e a DDD - os domínios do sistema).

Óbvio! Se eu priorizei minhas features (ops, issues - ops ainda, points - ops, ainda mais user stories) e começei a desenvolver o sistema/sprint por partes, é provável que durante o desenvolvimento, conforme as features forem sendo implementadas, cada parte do sistema será finalizada uma após a outra e assim sucessivamente, até eu ter o sistema completo.

E finalmente, de quebra, eu ainda tenho outras informações nesse lindo e belo gráfico...

PMBOK
Para os adeptos do PMBOK (que Sim meninos, em nada ele se opõe em relação aos projetos ágeis - muito pelo contrário), com este gráfico de múltiplas curvas S eu posso identificar várias informações:

VP - Valor Planejado - Quantas features (ops, issues) eu deveria ter prontas na data tal?
VA - Valor Agregado - Quantas features eu efetivamente tenho prontas na data tal?
CA - Custo Acumulado - Qual é o meu gasto financeiro na data tal?
ONT - Orçamento No Término - Qual deve ser o meu gasto na data tal? (NOTA: Claro, aqui eu mostrei um sprint finalizado, mas nada impede de eu usar uma linha de tendência no meu Excel da vida pra ter essa informação projetada no tempo no meio de um sprint/projeto)
IDC - Indice de Desempenho de Custos - Quanto o projeto está me retornando para cada R$/U$ investido? Ou quanto estou perdendo, se for o caso...
IDP - Indice de Desempenho de Prazo - Quanto o projeto está adiantado ou atrasado em relação ao planejado.

Toda essa sopa de letrinhas têm fórmulas clássicas na literatura, e o gráfico acima é capaz de mostrar tudo isso, bastando a você GP, usar as fórmulas dos livros para obter essas informações!

Finalmente, o 3PUP
Hoje, como disse (eu disse?), uso o JIRA e o GreenHopper, e não tenho as múltiplas curvas S automáticas.

Acabo fazendo elas por fora, num Excel da vida como mostrei acima.

Entretanto, com o ótimo suporte da wiki Confluence, minha idéia é colocar tudo isso integrado ao nosso processo 3PUP, de forma que os GPs nossos possam simplesmente acessar a wiki do projeto e, como dois plugins bacanas do Confluence (o Chart Plugin e SQL Plugin) eu ter essa informação online sem delonga alguma.

Não sei para quando conseguirei fazer essa automação, mas o importante não é nem isso, e sim o fato que, o post do Mike me ajudou muito (mesmo) e que, com o auxílio das formulazinhas que estão no PMBOK (e outros) e um pouco de trabalho num Excel (ou Calc) eu já posso melhorar muito o controle nos meus projetos e (quantos e's!), principalmente, mostrar informações úteis para meus clientes.

Boa Mike.