Transparência para estimativas e planejamento de projetos

A importância do planejamento

 

Para realizar grandes conquistas, devemos não apenas agir, mas também sonhar; não apenas planejar, mas também acreditar.

Anatole France

Planejamos para termos “previsibilidade aproximada” quanto às entregas e diminuirmos os riscos para se atingir determinados objetivos.

Para um planejamento bem sucedido é fundamental termos a presença de alguém que esteja alinhado com o negócio e auxilie o time técnico a priorizar as necessidades de acordo com as metas da empresa e as necessidades que vão surgindo ao longo do caminho. Aqui denominaremos esta pessoa de Product Owner (dono do produto).

O planejamento é fundamental para manter o foco nas metas da empresa que podem estar relacionadas com campanhas de marketing, regulamentações normativas, estratégia de concorrência de mercado ou ainda quando o custo do atraso de não realizar uma entrega em uma determinada data é muito grande.

O Fluxo do Conhecimento

 

Entre falar e se fazer entender; Entre o entendimento e a conivência existe um grande abismo.

Agni Shakti

Para planejar é preciso entender.

É natural, ao pensarmos no tempo que será necessário para executar uma determinada tarefa, pararmos ao menos que alguns minutos para pensar em como executá-la.

Mas a grande questão é: Será que entendemos o que deve ser feito?

Fluxo do Conhecimento

Por esse motivo, verificamos que é necessário passar por um fluxo de conhecimento respondendo às seguintes questões:

  1. Eu tenho dúvidas quanto ao negócio?

Neste momento eu devo ter uma noção sobre o que deve ser feito, ou seja, qual o problema que nos propomos a resolver.

2. Eu tenho dúvidas quanto à tecnologia?

Uma vez que você sabe o que deve ser feito, o próximo passo é pensarmos em como fazer, ou seja, se temos o conhecimento técnico e as ferramentas necessárias para resolver o problema.

3. Qual é o esforço?

Por fim, somente após estas perguntas respondidas é que conseguiremos de forma mais assertiva, chegarmos ao esforço.

T-Shirt Size

 

Calcula aquilo que o homem sabe e não haverá comparação com aquilo que ele não sabe.

Chuang Tzu

T_Shirt SizeO ser humano tem dificuldades em realizar cálculos de precisão, porém tem mais facilidade em fazer comparações.

Uma maneira simplificada para classificarmos o tamanho de uma tarefa é compará-la com outras existentes e atribuir os tamanhos (P) Pequeno, (M) Médio ou (G) Grande, similar a comparação de tamanho de camisas.

Esta é uma boa forma de classificação para times que estão iniciando um projeto e necessitam de uma visão do tamanho das atividades que estarão envolvidas.

Mais Conhecimento e Menos Riscos

 

Uma vaga noção de tudo, e um conhecimento de nada.

Charles Dickens

Complexidade

Quanto maior o nosso conhecimento, menores serão os riscos quanto a entregarmos algo de valor e ao seu prazo de entrega.

Em contrapartida, quanto mais longe estivermos do entendimento sobre o que e como deve ser feito, maiores serão os riscos quanto à assertividade do esforço e o atendimento das expectativas sobre a funcionalidade que estamos desenvolvendo.

Esta conjunção de fatores representa a complexidade sistêmica.

Porém, há de se ter o equilíbrio, sobre o quanto de esforço iremos empregar para buscarmos todo o conhecimento no início de um planejamento.

Definição de Preparado

 DoR – Definition of Ready

 

Existe o risco que você não pode jamais correr, e existe o risco que você não pode deixar de correr.

Peter Drucker

O Agile Planning Board permite também estabelecer restrições que ajudem a mitigar os riscos. Uma maneira é criar acordos de trabalho sobre os itens antes de trazê-los para o desenvolvimento.

Desta forma, determinamos qual o nível de detalhe esperado pelo time de desenvolvimento para iniciar a construção dentro de uma iteração.

É uma boa forma de transformar itens que são entendidos como épicos e transformá-los em itens menores.

Vejamos alguns exemplos:

  1. Critérios de aceite definidos

Esta é uma boa maneira de melhorar a comunicação entre o Product Owner e o time de desenvolvimento e melhorar o entendimento sobre o comportamento esperado para os itens que serão construídos.

Podemos estabelecer que um item só pode ser avaliado tecnicamente, após o PO definir quais são os comportamentos esperados, diminuindo as dúvidas de negócio.

Os comportamentos podem ser facilmente descritos com o Grooming Backlog, uma técnica que permite a um ou mais membros do time participar do entendimento em conjunto com o Product Owner e auxiliar na criação dos critérios de aceite.

2. Spikes

O Spike é uma técnica do XP (extreme program) onde é possível criar pequenas provas de conceito para validar itens com alta complexidade técnica.

Podemos vivenciar situações em que aparecerão itens de grandes dúvidas técnicas, onde o time necessitará do auxílio de um especialista.

Neste caso, toda vez que o time se deparar com um item nestas condições, poderá estabelecer uma regra de que será necessário primeiro realizar uma prova de conceito para validar a tecnologia antes de se implementar o item em sua totalidade.

3. Quebrando itens

Existem ocasiões onde atividades que requerem grande esforço acabam se tornando muito cansativas e tediosas, consequentemente tomando um tempo além do esperado.

Uma sugestão é tentar quebrar os itens todas as vezes que estes forem estimados com um grande esforço.  Procure atuar em itens com esforço menor de forma que outros membros do time também possam atuar.

De maneira comportamental, também notamos que conforme os itens vão sendo finalizados, os indivíduos vão se mantendo motivados.

Planning Poker

 

Uma vez tomada a decisão de não dar ouvidos mesmo aos melhores contra-argumentos: sinal do caráter forte. Também uma ocasional vontade de se ser estúpido.

Friedrich Nietzsche

É uma excelente técnica que estabelece comunicação e transferência de conhecimento entre todos os envolvidos, além de possibilitar que todos possam emitir as suas opiniões e discutir sobre elas.

Já que estamos citando analogia, triangulação e desagregação, não poderia deixar de citar o planning poker.

É possível utilizar o planning poker em conjunto com o agile planning board, estabelecendo transparência sobre o nível de conhecimento de todos os participantes envolvidos no planejamento.

 

Planning Poker

 

Por Exemplo:

Se um participante escolher a carta 3, saberemos que ele não tem dúvidas de negócio e nem técnicas, considerando somente um grande esforço.

Se um participante escolher a carta 8, quer dizer que ele possui algumas dúvidas técnicas relacionadas a como desenvolver o item.

Conseguiremos ser bem mais assertivos nas discussões durante nossas sessões de planejamento.

O Cone da Incerteza

 

A melhor maneira de prever o futuro é criá-lo.

Dennis Garbo

Cone da Incerteza

 

O Cone da Incerteza nos demonstra que quanto mais no início da ideia do produto, maior será a incerteza quanto ao tempo que será necessário para desenvolvê-lo.

O gráfico acima demonstra que no início do projeto, podemos errar as estimativas em 4X pra mais ou 4X pra menos. Com a definição aprovada, ainda podemos errar 2X pra mais ou para menos no tempo estimado, e assim sucessivamente.

Agora vejamos o que acontece quando plotamos o cone da incerteza sob o agile planning board:

Cone da Incerteza e o APB

 

Ficou mais fácil visualizar as incertezas?

A ideia é sempre diminuir as dúvidas de negócio e técnicas e trabalhar com itens menores (itens à direita), diminuindo riscos e incertezas e aumentando o conhecimento de todos os integrantes da equipe.

 

Métricas

 

O menor desvio inicial da verdade multiplica-se ao infinito à medida que avança.

Aristóteles

Agora que temos o conceito do cone da incerteza e sabemos que só saberemos o tempo exato de conclusão de um item após ele estiver finalizado, então utilizaremos esta informação como uma métrica.

Lead Time

leadtime

O Lead Time é uma métrica que nos mostra o tempo que determinado item levou para ser concluído desde o momento que entrou em desenvolvimento.

 

É importante considerar as restrições que o time e o Product Owner definiram para a definição de pronto (DoD).

Por exemplo:

leadtime kanban

Para que o item A, que foi estimado com esforço pequeno, o que equivale a 1 ponto, satisfaça todas as definições de pronto, foram percorridos 2 dias.

O item B que equivale a 3 pontos, pois tem o esforço grande e o Item C que equivale a 5 pontos, pois tem dúvidas técnicas pequenas, levaram 4 e 9 dias respectivamente.

 

Baseados nestas informações, podemos plotar a quantidade de dias na área de métricas de acordo com o tamanho de cada item.

ideal days

Desta forma, começamos a ter uma métrica que poderá ser seguida para todos os itens daquela coluna, que estão com a mesma classificação de tamanho.

 

Planejamento

 

Assumir uma atitude responsável perante o futuro sem uma compreensão do passado é ter um objetivo sem conhecimento. Compreender o passado sem um comprometimento com o futuro é conhecimento sem objetivo.

Ronald T. Laconte

OK.  Chegamos ao planejamento.  Com as métricas definidas fica mais fácil e explícita a realização de um planejamento.

Se você chegou até aqui e definiu o Lead Time das colunas, agora será possível pegar os itens de maior prioridade, verificar as métricas e informar qual a estimativa simplesmente somando a quantidade de dias especificados para cada item.

Metas

Se você atua com iterações ou sprints, a sugestão é definir as metas por conjunto de itens, verificando se estas fazem sentido e agregam valor de negócio quando atingidas.

Naturalmente, conseguiremos determinar o roadmap com metas, dias estimados e quantidade de pontos.

E se eu ainda não tiver métricas?

A primeira estimativa é sempre complicada se não tivermos histórico de métricas. Neste caso, vale a experiência do time em itens semelhantes.

Procure trabalhar com poucos itens em interações curtas como experimentação.

Vale a estimativa por comprometimento, pergunte ao time em quanto tempo ele acredita que leva para desenvolver cada item e sempre que necessário, solicite a opinião de um especialista. Após realizar algumas interações, o tempo de execução servirá como base histórica.

Este ponto é muito importante e deve ser considerado: tenha o equilíbrio entre o nível de conhecimento atual da equipe e os recursos que serão consumidos (tempo, dinheiro…) para se estimar todo o seu backlog.

O conhecimento será adquirido com o progresso do projeto e os itens prontos serão o melhor feedback para estimarmos os demais itens prioritários.

Precisão X Acurácia

 

É melhor estar aproximadamente certo do que precisamente errado.

Warren Buffett

Os métodos tradicionais de planejamento de projetos vem se baseando na busca da precisão na definição de datas e durações precisas e com exatidão.

Porém, dadas as incertezas que ocorrem no projeto, muito que raramente a precisão será alcançada.

O que buscamos não é a precisão, mas sim a acurácia, que é a capacidade de estarmos o mais próximo possível de uma meta dentro de intervalos planejados.

Portanto, é melhor nos comprometermos em realizar a entrega do projeto em determinado mês, ou na última semana do mês, do que buscarmos a precisão de entregá-lo no dia 20, por exemplo.

Como citamos no início deste texto, planejamos, pois precisamos dar previsibilidade.

Verifique a apresentação no SlideShare. Clique Aqui.

Anúncios

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