2

Fibonacci e Planning Poker, parece fácil, mas é uma revolução

As vezes alguém me pergunta como converter pontos de esforço do planning poker em horas e a resposta sai fácil: Pontos não são para isso! Horas são uma medida universal, comparativa, extrínseca, enquanto os tais pontos de esforço estimados usando a série de Fibonacci em um planning poker são intrínsecas, que só fazem sentido a ela sobre uma linha evolutiva no passar do tempo.

Phillipe Zarifian, um ícone da Gestão por Competências, cita a parábola do relógio, onde é difícil mudar para um novo modelo produtivo enquanto métricas de controle forem monitoradas em horas, minutos e segundos de trabalho.

Zarifian detalha que “há um enfrentamento entre duas concepções do tempo: o tempo espacializado, quantitativo e físico, medido pela sucessão de instantes materializados no relógio; e o tempo-devir, qualitativo e psicológico, entendido como duração, na qual há um ímpeto permanente da totalidade do passado em direção ao futuro. Esses tempos apresentam frente ao trabalho modos diferentes de manifestação social: o tempo espacializado se manifesta como disciplina e regulação dos atos de trabalho e o tempo-devir como mobilização da experiência passada e antecipação do porvir.”

Os pontos de esforço estimados em um planning poker são uma estimativa de transformação, uma medida interna a equipe, você não encontrará uma tabela price com taxas de conversão entre pontos e horas, se houvesse não teria muito sentido seu uso, pois havendo proporção genérica de 1:N seria dizer que trata-se de uma só dimensão que usa duas bases de cálculo. Horas são do relógio, os pontos de esforço oferecem uma percepção longitudinal de produtividade.

Por ser uma medida interna, própria de cada equipe, está relacionada ao seu perfil, talvez mais júnior ou mais sênior dos integrantes, depende da tecnologia, das facilidades em suporte, etc. Não é uma medida que se preste a comparações externas, não aponta se uma equipe é melhor que outra, mas pode gerar um histórico de produtividade e apóia a criação de planos de ação para refino do método e processo de desenvolvimento de software.

Há no bojo desta questão, a proposta do uso de uma métrica sobre produção que não o relógio, uma métrica que ao usar Fibonacci persegue a máxima que estimar horas é um preciosismo pouco válido, com uma tarefa estimada em 8Hrs, outra 9,5Hrs, outra 10Hrs, pois com pontos queremos saber a natureza da tarefa, se é algo que exigirá 1, 2, 3, 5, 8, 13 ou 21, se ela está mais para 8 ou 13.

Em uma reunião de Planning

Primeiro distribui-se as US`s que precisamos entender claramente para poder estimar pontos de esforço, a importância de estimar pontos primeiro é estabelecer uma percepção do que e quais são pequenas, médias e grandes dentro da série de Fibonacci.

Para cada US, em determinado e apropriado momento, nós a quebramos em tarefas que serão dimensionadas em horas pela equipe, não pela conversão dos pontos em horas, mas olhando cada tarefa e estimando em horas de trabalho, que depois comporão o nosso Scrum Board ou Kanban.

São coisas diferentes, como Litros e Centímetros, os pontos são usados para entender a produção e dimensão do trabalho da equipe em uma escala longitudinal própria que poderá ser comparada e usada para auto-comparação e estimativas de alto nível, que serão aos poucos refinadas com a repetição de iterações da equipe e tendem a gerar apurada visão de volume com o tempo.

Horas são horas, ótimas para previstos x realizados sob um prisma tradicional, facilmente entendido e monitorado por todos no seu principal destino, que são os postits e gráficos como burndown afixado no quadro de tarefas ou Kanban. Apesar de sabermos que orçamentos em horas são ainda mais imprecisos, as empresas e até mesmo os nosso cérebros estão acostumados a este sistema.

Em uma reunião de Mapping

Lembrem que estamos falando de software, tecnologia, sistemas complexos, fossem sistemas simples e nada disso seria necessário. Mas, cientes da média de pontos realizados pela equipe em seus últimos Sprints é possível inferir pontos às US`s resultantes de uma dinâmica de Mapping e assim quebrar com sucesso relativo um projeto, fragmentando-o em releases e sprints.

A pergunta que me fazem é como ter um mínimo de confiança que dá para se fiar e a resposta na ponta da lingua é: Depende! Se você escolheu as pessoas certas e confia no conhecimento e na expertise acumulada delas, podemos errar, mas provavelmente erraremos e gastaremos menos que em um processo tradicional.

Não é fácil, menos ainda para amadores, ao introduzir SCRUM em uma empresa ou equipe piloto, deixo isso para bem mais adiante, pois a mudança proporcionada pela adoção não pode significar mudar tudo, neste caso é muito possível que a galera se perca no meio de tantas mudanças … introduza novos conceitos em doses ágeis, homeopáticas. Lembre do James Shore e de seu modelo de fluência (maturidade) e faça um passo de cada vez.

2

Sprint Planning “Visual”

Estava eu conversando com um colega sobre o “como” se desenrola o Planning na equipe dele e percebi que independente da proximidade e alinhamento, para qualquer uma das reuniões ágeis sempre teremos uma infinidade de execuções, cada equipe criará nuances e possibilidades variadas para se sentir bem na sua condução, usando os recursos a sua maneira.

Quadro branco

Por exemplo, eu vejo a reunião de Planning como algo 100% visual, como tudo o mais em nossas timeboxes … característica minha talvez. Tudo o que é dito no transcorrer do planning, vou colocando na parede, no quadro branco. Quando a reunião é em uma sala com pouco quadro, colo folhas brancas nas paredes.

Quadros brancos de 5 por 2 metros é um privilégio e eu teimo em utilizá-los em todo o seu potencial e extenção, mesmo que isto acabe gerando trabalho extra para mim mesmo, pois ao final tenho que reescrever tudo nos postit’s, mas faz com que tudo esteja a vista durante todo o tempo … o que é bom!

Sprint Planning Visual

Começo expondo o calendário de nossa Sprint, normalmente na extrema esquerda, seguido de um espaço para DoD (definitions of done) que irá sendo preenchido no transcorrer da reunião e um espaço para os cálculos de disponibilidade e velocidade, prosseguirei fatiando espacialmente o quadro em espaços para cada User Story, tarefas necessárias e observações.

Quem olha para o quadro, verá nele absolutamente tudo o que foi tratado em seus detalhes, acredito que é útil a todo momento, quando voltamos a algum ítem já discutido ou quando traço uma linha relacionando diferentes ítens ou observações. Também, sempre que temos a mão, colamos o desenho de interface, com as telas ou blocos que construiremos.

Sempre com minha câmera na cintura, pois fotografo todos os nossos eventos e reuniões, ao final, transcrevo para os PostIts, fotografo tudo mais de uma vez e arquivo, não necessariamente nesta ordem.Agora percebi que não tenho fotos gerais de TODO o quadro, mas neste post colei alguns pedaços do quadro para exemplificar, assim espero que tenha ficado claro meu ponto de vista.

13

Sprint Planning

Se você leu o post sobre Ciclos Scrum de Discovery e Delivery, sabe que planejar uma Iteração (Sprint) inicia pelo menos duas semanas antes, quando é selecionado um possível Sprint Backlog que será desenvolvido pelo PO (Product Owner), com participação do UX (User Experience), SEO (Search Engine Optimization), Tester ou SQA (System Quality Assurance), usuários, convidados e referências da equipe técnica.

Aqui, focarei apenas na timebox de Planning, quando pressupomos que podemos iniciar o ciclo de Delivery, quando estimaremos frente as definições apresentadas pelo PO e pactuaremos o que é possível trabalhar e entregar dentro do tempo de uma Sprint (nós fazemos Sprints de 2 ou 3 semanas). Quero compartilhar aprendizados e dicas para que o Planning não seja “apenas mais uma reunião”, mas que cumpra seu papel.

Sprint Planning

A nossa experiência mostra que uma boa reunião de Planning é para ser produtiva, eficiente, mas não precisa ser tensa ou chata, o melhor turno é o da manhã, com todos de buffer vazio, com frequência organizamos um café antes, entre aqueles que querem chegar um pouco mais cedo e descontrair, pois depois é trabalho focado, no geral temos:

1. Os primeiros minutos são alinhamento, datas, o que foi e para onde vamos;
2. Em seguida, calendário, cálculo de velocidade e DoD (Definition of Done);
3. Apresentação e estimativas, podendo ser na totalidade ou em blocos afins;
4. Vou transcrevendo e subtotalizando, puxando setas, alertas, explicitando;
5. Sempre que necessário ou no fim, análise geral de ocupação, P&D, Pair, …;
6. Revisão e debate até fechar pacto de trabalho para o sucesso da Sprint.

Durante a apresentação a ser feita pelo PO, a participação do UX é fundamental, pois o pleno entendimento de cada detalhe e variantes do layout e arte desenvolvidos é crítico para que as estimativas sejam o mais realistas possível. Se PO e UX não tiverem todas ou a maior parte das respostas, o volume de dúvidas e debates podem dispersar e eventualmente inviabilizar as estimativas de parte ou do todo das histórias apresentadas.

O manual diz que Sprint Planning demandam 4 Horas, separadas em 2 Horas para a apresentação do QUE precisa ser feito e qual o valor caso a caso, seguidos de até mais 2 Horas no debate para estimativas do COMO será feito, entretanto nós usamos uma variação, pois as histórias são apresentadas em pequenos grupos corelacionados, seguidos de debate e estimativa, evitando delay com repetição de perguntas ou esquecimento de respostas.

Na prática, se após algum tempo de Planning sentimos que existem mais dúvidas que entendimento, que o Discovery estava muito frágil e que não há como estimar as histórias, eu transformo aquela reunião em uma reunião de DISCOVERY, fechamos as pontas e fazemos o PLANNING na sequência ou na manhã do dia seguinte, isto evita frustrações e estabelemos um passo de cada vez, mitigando o fato de que não estávamos preparados.

Um aspecto fundamental, o Sprint Planning é Visual

Se não houver uma parede forrada de fórmica branca ou um grande quadro branco, não tem problema, use postits e folhas de flipchart colados diretamente na parede que houver, pois é lá que eu transcrevo TUDO o que é debatido, decidido e todos os números, estimados por papel, normalmente [Java] [FrontEnd] [tester], de forma visual construo uma única visão do todo e partes, destacando gargalos e oportunidades, um pacto em tempo real;

Quem olha para o quadro, verá nele absolutamente tudo o que foi tratado, com seus detalhes, pois acredito que é útil todo momento, quando voltamos a algum ítem já discutido ou quando traço uma linha relacionando diferentes ítens ou observações. Também, sempre que temos a mão, colamos o desenho de interface, com as telas ou blocos que construiremos, assim tentamos que nada passe desapercebido e que o sucesso de cada parte envolve as demais.

Como podemos ver nas fotos acima, a maioria das User Story (ou demandas) acabam gerando várias linhas com as tarefas técnicas necessárias para sua construção, como scripts de banco, serviços, frontend, …, dependendo do volume de Histórias e Tarefas pertinentes, uma das formas de montar o kanban é criando uma linha para cada História ou grupo delas, facilitando a visualização do fluxo de cada uma.

Sugestão final, tenha sempre uma câmera de qualidade a mão, não importa o tamanho, mas sempre fotografe suas reuniões, cada parte do quadro, coloque em um repositório, deixe acessível a todos … as vezes quebra o galho.

Boa sorte! Comenta ai se sua experiência aponta outras soluções ou se algo não ficou claro, sempre é difícil ser assertivo em uma lauda, sobre um assunto tão rico quanto uma timeboxe … mas a gente tenta  \o/