O que é o Agile Planning Board?

O Agile Planning Board  surge com o objetivo de auxiliar times de projetos na execução de planejamentos e estimativas com transparência e boa comunicação entre todos os envolvidos.

Criado para auxiliar times iniciantes, com o passar do tempo se mostrou uma boa ferramenta de facilitação, definição de métricas e propósitos além da resolução de conflitos através do uso da gestão visual e o alinhamento de restrições.

Uso do Agile Planning Board

 

Para aqueles que têm apenas um martelo como ferramenta, todos os problemas parecem pregos.

Mark Twain

Em alguns passos, a ideia é demonstrar como o agile planning board pode ser utilizado.

Caso você ainda não conheça o Agile Planning Board, faça o download aqui.

  1. Identificação e Propósito.

Identifificação e Proposito

Aqui identificamos qual o projeto (ou nome do time) e também o objetivo que queremos alcançar, dando um propósito claro a todos os envolvidos no planejamento.

2. Participantes.

Nesta área vamos identificar dois papéis:

Participantes

O Product Owner será o responsável por tirar as dúvidas de negócio, criar todas as hipóteses (itens do backlog), priorização e definição das metas a serem atingidas.

O Time é formado pelos indivíduos que estarão diretamente envolvidos com a construção e que participarão do planejamento de esforço.

2.1 O papel do Facilitador

É comum termos a presença de um facilitador para auxiliar na condução da dinâmica e na discussão entre todos os envolvidos. Se você atua com Scrum, o Scrum Master é a pessoa indicada para assumir este papel.

Entretanto, com o passar do tempo temos notado que equipes experientes conseguem utilizar o agile planning board sem a necessidade de um facilitador.

3. Backlog Priorizado

Backlog Priorizado

Nesta área serão dispostos os itens priorizados para se atingir o objetivo (determinado no primeiro passo).

Aqui não importa se você utiliza user stories, user cases, features, etc… .

Comece com o que você tem hoje.

O Agile Planning Board irá auxiliar na discussão se o nível de granularidade está suficiente para o entendimento do time de desenvolvimento.

A quantidade de itens nesta área pode variar bastante, pois o board pode ser utilizado para planejar sprints, releases ou todo o projeto.

Uma sugestão é utilizar um board por release, mas esta decisão depende do contexto de cada projeto.

4. Alinhando as Restrições

Definition of Done

Agora que sabemos qual o nosso propósito e quais funcionalidades serão necessárias para atendê-lo, vamos alinhar as restrições entre todos os envolvidos no planejamento.

Fazemos isto através da Definição de Pronto (DoD – Definition of Done).

Aqui deixamos claro para todos o que é esperado para que se considere um item pronto, através de uma política explícita.

Por exemplo: Todos os itens devem ter o seu manual de usuário, testes automatizados e entregues em ambientes de produção.

Desta forma, o time deverá considerar todos estes parâmetros na construção de cada item e o Product Owner terá visibilidade de que estas foram as premissas que deverão ser validadas na sua entrega.

Conseguimos então, alinhar as expectativas e evitar futuros conflitos.

5. Classificando os itens (jogo do planejamento)

Para cada item priorizado do backlog, pergunte ao seu time como classificá-lo dentro do fluxo do conhecimento.

Se o seu time tiver dúvidas de negócio, sobre o que deve ser feito, pergunte se esta dúvida é (G) Grande, (M) Média ou (P) Pequena.

Caso não as tenha, verifique se há dúvidas técnicas, sobre o como deve ser feito, pergunte se esta dúvida é (G) Grande, (M) Média ou (P) Pequena.

Mas caso tudo já esteja entendido, simplesmente classifique o tamanho do esforço como (G) Grande, (M) Média ou (P) Pequena.

Esta ação pode ser repetida para cada item do backlog, enquanto o time tiver entendimento e os itens estiverem de acordo com o propósito do planejamento.

A Importância da Comunicação

Se durante a classificação existir dúvidas de negócio, o Product Owner pode ser acionado para para explicar qual o comportamento esperado daquele item.

Se o time perceber que há muitas dúvidas técnicas, pode acionar um especialista para auxiliar na explicação ou criação de provas de conceito.

Este é um bom momento para entendimento, diminuindo os riscos que podem aparecer durante o desenvolvimento.

Acima de tudo, o importante é a comunicação.

Acompanhando times que utilizam o agile planning board, iremos observar que após iniciar o uso, o jogo do planejamento vai se tornando cada vez mais simples.

Veja alguns casos:

  • Triangulação:

Triangulação

Supondo que você já tem um item classificado com esforço pequeno e outro item classificado com esforço grande. Então surge um terceiro item, que é um pouco maior que o primeiro, mas não tão grande quanto o segundo.

Podemos facilmente, realizar o conceito de triangulação, classificando o novo item com um tamanho médio, sem a necessidade de grandes discussões.

  • Analogia:

Analogia

Se surgir um item similar a outro previamente discutido, basta classificá-lo na mesma coluna.

  • Desagregação:

Desagregacao

Vamos supor que o time de desenvolvimento entendeu que há um item com grande complexidade técnica e por isso será necessário realizar uma prova de conceito para validar algumas hipóteses de desenvolvimento.

Neste momento, o time decide quebrar o item em um mais simples para testes tecnológicos (spikes) e manter outro item com as regras de negócio, sendo que se este último não tiver os riscos técnicos, pode ser avaliado com um nível de complexidade menor ao teria se tivesse que fazer tudo ao mesmo tempo.

Sendo assim, é sugerido que o item para validação técnica seja realizada em uma interação que antecede a que será realizado o item de negócio.


Dê maneira bem visual, conseguimos dar visibilidade a todos os envolvidos sobre o nível de conhecimento dos itens.

A transparência e a comunicação são premissas fundamentais para realizarmos um bom planejamento.

Em breve falaremos mais sobre os  conceitos por trás do Agile Planning Board, estimativas e métricas.

 

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

Anúncios

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.