Reunião diárias - realmente necessárias?

Contato visual e reuniões diárias.

Em um post recente do Mike Cohn ele fala sobre reuniões diárias. Discute o propósito delas e uma sugestão controversa de evitar o contato visual com os integrantes da equipe.
Uma notícia sobre este post também foi publicada na InfoQ com algumas considerações adicionais, as quais nos fez começar a discutir alguns casos reais, mas um em específico gerou uma questão:

Logo no dia em que li o post do Mike, aconteceu de um desenvolvedor estar explicando uma tarefa diretamente para mim em uma reunião diária. Procurei desviar o olhar conforme a sugestão do Mike Cohn, mas senti como algo extremamente artificial e optei por explicar para a equipe de que eles tem uma meta comum e que a reunião diária serve para a equipe se sincronizar e pensar na melhor forma de se atingir o resultado compromissado.

Quando falei isso para a equipe, eles me explicaram que já sabiam o que estava ocorrendo e estavam direcionando a conversa para o SM (PO em outras ocasiões) só porque estas pessoas seriam as que não estavam "por dentro" do que estava acontecendo.

Minha questão: em uma equipe pequena com, digamos, três desenvolvedores, sentados um ao lado do outro e que se conversam o tempo todo, a reunião diária é realmente necessária?


Por favor, deixem suas opiniões!

Entrevista com Ken Schwaber - IT Martini

Ken Schwaber

Ken Schwaber, um dos criadores do Scrum, concedeu uma entrevista aberta para a revista digital IT Martini pelo LinkedIn, onde os participantes do grupo poderiam fazer perguntas para ele. Tive a oportunidade de fazer três perguntas...

leia mais

Inspect & Adapt

Neste post curto falarei de uma receita bastante simples sobre inspeção e adaptação (ou kaizen, se você prefere um termo mais Lean) para tornar o seu dia-a-dia - ou processo - mais eficiente:

1. Dado um problema, esqueça a realidade e concentre-se apenas na solução ideal.
2. Confronte-a com a realidade. Ela atenderia todas as necessidades?
3. Agora, ou atualize sua percepção do que é ideal (volte ao passo 1), ou lute para atualizar sua realidade para torná-la ideal.
4. Caso você esteja aqui, quer dizer que está buscando melhorar a realidade. Continue verificando se os efeitos das suas ações estão, de fato, levando a uma melhoria do seu dia-a-dia e continue a  inspecionar e adaptar o tempo todo.

Por favor, deixem seus pensamentos e críticas.

Re-estimar estórias já Done

Final de Sprint, equipe realizando o review com o PO, apresentando um estória estimada originalmente em 13 pontos mas que, na prática, levou bem mais. O que fazer? Re-estimar a estória?

Minha primeira resposta é não. Vamos aos pontos:

Ponto 1 - Comparando bananas com maças

Cenário hipotético:

Time Bar

Backlog:

1. Estoria A - 3 Pontos
2. Estória B - 5 Pontos
3. Estória C - 2 Pontos
4. Estória D - 13 Pontos
5. Estória E - 5 Pontos
6. Estória F - 13 Pontos
7. Estória G - 20 Pontos

Imaginemos que a equipe fez seu primeiro Sprint e entregou as estórias A, B e C, tendo uma velocidade de 13. Assim, começam o próximo com apenas a estória D.

Ao final do sprint a equipe percebe que, na verdade, aquela estória deveria ter sido 20, dado o esforço não previsto de trabalhar com uma biblioteca legada, por exemplo. Esses 20 pontos são registrados e passam a contar na velocidade da equipe.Então temos que a nova velocidade da equipe pode ser considerada 20, e não mais 13. Desta forma, para o próximo Sprint, a equipe deve ser capaz de incluir os itens 5 e 13, certo?

Errado. Quando estimamos os itens em uma sessão de planning, todos os itens são tratados da mesma forma, considerando apenas as informações que temos antes de iniciar o desenvolvimento. É por isso que usar Fibonacci faz todo o sentido [referencia].

Quando misturamos estas estimativas com itens já desenvolvidos e por isso re-estimados, passamos a trabalhar com medidas que não são comparáveis. Nosso backlog irá ser todo estimado com bananas, mas teremos uma  maça no meio, o que bagunçará tudo.

No exemplo, o time Bar deve continuar usando a velocidade de 13 pontos para estimar os próximos Sprints.

Caso o esforço extra encontrado na estória D possa ser novamente encontrado em estórias futuras, estas podem ser re-estimadas com as lições aprendidas, a fim de melhorar a previsibilidade. Mas veja que a incerteza continua tendo seu papel.

Ponto 2 - A média resolve

Todas as estórias de peso 3 são iguais? A resposta é obviamente não, algumas poderiam ser 2, outras 5, algumas raras seriam 1 ou 8. Mas se analisarmos uma quantidade grande o suficiente, veremos que a maior parte gravitará corretamente em torno de 3, e as exceções tenderão a se anular.

Ponto 3 - Vale a pena o esforço?


Se estórias sub estimadas forem revistas para tentar "acertar" a velocidade, estórias super estimadas também devem, correto? Quanto tempo seria perdido para rever os esforços das estórias? O pequeno (e na minha opinião, inexistente) benefício compensaria?

Ainda Rascunho

Senhores, este texto ainda é um rascunho, e precisa ser melhorado e finalizado, mas já serve para iniciarmos as discussões.