MVP e a Gestão de Custos em Projetos Ágeis – Parte 2 (Final)

Olá Pessoas,

Antes de mais nada eu gostaria de agradecer o wordpress, por ceder este espaço para que a gente possa, em alto nível, discutir a gestão de projetos no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)

Eis que vos apresento, meu caro e paciente leitor, a segunda e última parte do post MVP e a Gestão de Custos em Projetos Ágeis – Parte 1. (aqueles que estavam esperando ansiosamente por esta segunda parte, dê um curtir… cri cri cri cri cri… #CigarrasFeeling)

Sem muitas delongas, avancemos… o seu projeto, como vimos na parte 1 do post, agora possui um MVP. Com base neste MVP e na velocidade média do seu time, conseguimos planejar a primeira release do projeto. O que nos resta agora — para gerenciarmos o valor agregado — é estimar os custos, que em particular eu prefiro fazê-lo da seguinte forma, a saber:

1) Estime o Tamanho, Esforço e/ou Complexidade das Estórias

  • Separe todas as estórias que compõem o seu MVP; aquelas 12 estórias granularizadas que se formaram a partir das 4 funcionalidades iniciais.
  • Reúna seu time e promova uma sessão de estimativa, utilizando por exemplo T-shirt sizing (XL, L, M, S). Para facilitar, oriente o seu time a utilizar a técnica de planning poker (pode ser outra, se preferir) e com base no tamanho, esforço e/ou complexidade estime cada estória.

O que teremos como saída deste processo é um MVP estimado, ou seja, todas as estórias que entrarão na sua release, estimadas com base no tamanho, esforço e/ou complexidade. Algo parecido com isso:

projectAqui utilizei o Project 2013, mas você pode perfeitamente utilizar uma planilha de excel.

Nota: Concluídas as estimativas, conseguiremos distribuir o custo total da sprint, pelas estórias. Ex.: num cenário onde temos 3 estórias, sendo uma L (large), uma M (medium) e uma S (small), podemos fazer a seguinte distribuição de custo: 50% do custo na estória de tamanho L, 30% na M e 20% na S. Pergunto. Esta distribuição faz sentido para você? (se não faz, mande sua dúvida no comentário 😉 )

2) Calcule a soma dos valores pagos ao Time de Desenvolvimento (Folha de Pagamento) 

Suponha que o seu time possua 3 Desenvolvedores e 1 Analista de Testes e que os custos com salário + encargos de cada um deles, somados, equivalem à R$ 150.000,00 (Cento e Cinquenta Mil Reais). Como as sprints são de duas semanas, dividiremos este valor por 2. Passamos então a ter um custo de R$ 75.000,00 (Setenta e Cinco Mil Reais) por sprint.

Boa Prática em foco: Times maduros, promovem periodicamente sessões de Refinamento (gromming) do Backlog. O resultado disto são estórias bem preparadas, pequenas o suficiente, facilitando assim a apuração dos custos por atividade e reduzindo, dramaticamente, os riscos e incertezas.

Uma vez levantado o custo bruto por sprint, podemos facilmente dividi-lo pelas estórias que planejamos entregar por sprint: R$ 75.000,00 dividido por 3. — Vejamos então, como ficou o nosso Project, agora contemplando a coluna Custo:

project_com_custoNota: Dividi o custo total da Sprint por 3, pelos seguintes motivos:

  1. É uma boa prática todos do time atuarem sobre a mesma estória, até que esta estória esteja concluída (done), portanto, os custos incorridos serão uniformes;
  2. Como todas as estórias estão estimadas com o mesmo tamanho (small), concluímos que elas têm o mesmo custo.
  3. Como mencionado anteriormente, se uma das estórias, por exemplo, estivesse estimada com tamanho M (medium), poderíamos estimar seu custo em 50% do custo total da sprint e as outras duas em 25% cada.

E agora ladys and gentlemen que rufem os tambores… (lembrei da Porta dos Desesperados do Programa do Sérgio Malandro 😀 ) — Com todos estes inputs criados, finalmente Gerenciaremos o Valor Agregado do seu Projeto… AaEEeeEe caçarola! — Para contextualizar, porém, farei um breve introito, colocando na nossa receita uma pitada de conceito:

  • O Gerenciamento do Valor Agregado (GVA) ou Earned Value Management (EVM) é uma técnica que permiti, de forma clara e objetiva, avaliar e medir o avanço de um projeto no que se refere a custos e prazos, baseando-se no trabalho realizado versus o planejado. É desta técnica, que podemos extrair importantes indicadores como o CPI (Cost Performance Index) ou Índice de Desempenho de Custos e o SPI (Schedule Performance Index) ou Índice de Desempenho de Prazos.
  • Valor Agregado ou Earned Value (EV) é o quanto de trabalho foi realizado baseando-se no planejado (linha de base). Exemplo: Uma estória de usuário estava estimada em R$ 30.000,00 e realizou-se 20% dela, então o valor agregado é de R$ 6.000,00, pois 20% de R$ 30.000,00 = R$ 6.000,00.

Entremos agora rapidamente na Planning da Sprint #01 (Planning rápida só existe em post do wordpress :/ )

Analisando a estória granularizada 01, o seu time visualizou que seria necessário implementar 10 tasks (tarefas) para concluí-la; o mesmo aconteceu com as outras duas estórias (02 e 03). Vejamos como ficou uma prévia do nosso Board:

Slide1

Estória Granularizada 01:

  1. Criar Tela de Login
  2. Criar Tabela Usuário…
  3. Task 1.9
  4. Task 1.10

Estória Granularizada 02:

  1. Task 2.1
  2. Task 2.2…
  3. Task 2.10

Com base no andamento das tasks pela cadeia de valor (ToDo | Doing | Done) verificaremos o percentual de completude da estória, e com isso obteremos o Valor Agregado do seu Projeto.

Sprint Running

Iniciada a Sprint #01, verificou-se que no 2º dia, 6 tasks da estória 01 foram para a coluna DONE. Podemos concluir então que, como a estória 01 possui 10 tasks, o percentual de conclusão (work completion) é de 60%. Concorda? E como ela está estimada em R$ 25.000,00 — aplicando o EVM (60% de R$ 25.000,00) — obtemos um valor agregado de R$15.000,00… Continua concordando?

Pergunta: Com base nestas informações, podemos afirmar que o projeto vai bem ou vai mal?

Para responder, façamos então a seguinte análise: se temos 3 estórias para concluir neste sprint, e no 2º dia temos 60% de percentual de completude de uma delas – sem precisar fazer nenhuma continha — é loucura da minha cabeça dizer que chegaremos provavelmente no 10º dia da sprint com todas as 3 estórias prontas? Se você concordar que eu não estou falando bobagem, então podemos dizer que o projeto está indo bem, ou seja, o “valor agregado”, medido até agora, é positivo.

Olhando ainda para este cenário, tecnicamente, temos um CPI (Cost Performance Index) de 1,00. Este é um índice ideal, pois foi obtido aplicando-se a fórmula (CPI = EV / AC) onde:

1,00 (CPI) = R$15.000 (EV) / R$15.000,00 (AC) ou seja, para cada R$ 1,00 gasto, obtivemos R$ 1,00 de trabalho realizado. (Nota: AC é o mesmo que Actual Cost, ou Custo Atual)

Agora supondo que o CPI, fosse 0,60. A conclusão que chegaríamos, inevitavelmente, é que o projeto vai mal, pois para cada R$ 1,00 gasto, obteve-se apenas R$ 0,60 de trabalho realizado.

Conclusão

Para gerenciar os custos de um projeto, teremos que constantemente inspecionar (monitorar e controlar) e atualizar o plano deste projeto, durante todo o seu ciclo de vida, permitindo-nos desta forma, tomar ações corretivas a fim de trazer o projeto (caso haja necessidade) para próximo da linha de base de custos aprovada, e com isto, reduzindo efetivamente a variação de custo (cost variance).

Se você é um Gerente de Projetos/Scrum Master que monitorando/inspecionando a execução seu projeto, verificou que passado-se por exemplo, 4 dias de trabalho, realizou-se apenas 20% de trabalho, quando o planejado era a realização de 80%; há neste contexto um forte sinal de que alguma coisa não esteja indo bem… e com certeza tal cenário, exigirá de você muita atenção e porque não dizer criatividade.

Lembre-se: Em última instância você poderá recorrer a reserva de gerenciamento, para tanto será necessário a aprovação do Comitê ou do Sponsor do Projeto. Este por sua vez, certamente, solicitará que você aponte os desvios e o quanto de recursos será consumido desta reserva. Por esta razão recomenda-se que se faça, assim como nas demais áreas de conhecimento, um forte monitoramento e controle dos custos incorridos durante a execução do seu projeto.

Em tempo: para dirimir eventuais dúvidas que possam remanescer, darei um exemplo de uma estória de usuário que foi granularizada, a partir de uma estória que se tornou um épico.

Vejamos, então, um exemplo de “estória de usuário”, que é uma forte candidata a se tornar um épico:

epico 01

Agora um exemplo de granularização (do épico) em estórias menores:

estoria 01      estoria 02

Bem, espero ter ajudado com esta breve introdução à Gestão de Custos em Projetos Ágeis!

Saudações. Ψ

2 comentários em “MVP e a Gestão de Custos em Projetos Ágeis – Parte 2 (Final)

    • Olá bom dia,

      Supondo que um pintor cobre 1000 reais para pintar sua casa, dividindo todo o trabalho a ser feito em 3 tarefas e estimando-as com base no tamanho. Imagine agora que a tarefa 1 (pintar a casa) ele estimou em G, a tarefa 2 (preparar a tinta) em M e a tarefa 3 (forrar o chão) em P. Faz sentido eu afirmar que para apurar o custo unitário de cada tarefa eu preciso dividir o custo total, ou seja, os 1000 reais em cada uma das tarefas? E que se uma tarefa é maior do que a outra eu preciso dividir o custo total, proporcionalmente, com base nos tamanho de cada tarefa?

      Desta forma os percentuais do post eu cheguei aplicando esta lógica, que aqui, para este exemplo, ficaria mais ou menos assim: tarefa 1 (50% do custo total) = 500 reais, tarefa 2 (30% do custo total) = 300 reais e tarefa 3 (20% do custo total) = 200 reais.

      Você, entretanto, poderia chegar a outros percentuais de distribuição.

      Espero ter ajudado.

      Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: