Priorização de bugs

Quando ocorre um problema em produção, segundo uma visão ágil, ele deveria entrar no backlog do produto e disputar prioridade — como qualquer outro item. A justificativa dessa visão é que os itens de maior valor de negócio sejam priorizados sobre os de menor valor, afinal o objetivo é maximizar o valor entregue em relação ao esforço empreendido. Dado que um bug pode ocorrer em um trecho pouco utilizado do sistema, ou ser de pequeno impacto, talvez não seja estritamente necessário resolvê-lo imediatamente, ou talvez nunca venha a valer a pena investir em sua correção.

Em uma visão Lean, contudo, a ideia é um pouco diferente. Deveríamos encontrar imediatamente a causa-raiz de um defeito, pois ela pode continuar gerando outros problemas até ser atacada — um exemplo claro de desperdício. A questão aqui não é resolver o problema imediatamente, mas diagnosticar não só a causa imediata, como também a mediata. Ou seja, em uma visão Lean, não deveria haver problemas conhecidos cuja causa-raiz não estivesse plenamente identificada.

Como é comum que muito do tempo gasto para corrigir um problema seja justamente no diagnóstico, será que faz sentido fazer uma análise da causa-raiz imediatamente e postergar a correção do defeito?

Minha tendência é acreditar mais na linha Lean de pensamento e buscar logo a razão da geração dos problemas e atacá-la o mais rápido possível, pois uma das ideias mais fundamentais tanto do Lean quanto do Agile é a busca pela melhoria contínua, e para isso precisamos que os problemas apareçam o mais rapidamente possível. Não identificar a causa-raiz de um problema imediatamente é desprezar sinais de problemas subjacente.

Qual a opinião de vocês sobre o assunto? Faz sentido?

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.