Não sou aficionado por scrum e tenho apenas um ano de experiência prática. Portanto, o seguinte deve ser lido com um grão de sal.
Vejo várias bandeiras vermelhas no que você escreve:
5 horas de planejamento de sprint
Isso é muito longo para uma corrida de uma semana.
O objetivo do planejamento do sprint é AFAIR
- permitir que a equipe saiba quais são as prioridades atuais e
- para desenvolver um plano de batalha para o próximo sprint.
Para fazer isso de forma eficaz, cada lado precisa entender o Product Backlog items
.
Para entender o Product Backlog items
backlog, deve estar em boa forma.
Na fase de planejamento concreto, eles Product Backlog items
são transformados em Sprint Backlog items
.
Uma causa possível é que esses itens não são esclarecidos / refinados o suficiente.
Outra causa possível é que os itens são muito complexos e deixam espaço para muita interpretação.
Discutir muito detalhado no planejamento de sprint
Como dito acima, a fase de discussão será mais curta, quando os itens forem mais concretos.
Por outro lado: o planejamento da Sprint espera um comportamento profissional de todos os participantes. Isso inclui evitar discussões sobre ciclismo .
Talvez as coisas estejam claras, mas alguém inicia uma discussão sobre ciclismo .
Mais: evite discussões sobre detalhes de implementação . Embora toda idéia acabe no código em algum momento, não é o objetivo do planejamento do sprint discutir se uma matriz simples fará o truque ou será melhor usar uma lista vinculada.
Como a maioria dos membros da equipe não é sênior
No scrum, não há distinção entre senior e junior . Ambos são apenas desenvolvedores. E esse é um bom ponto de partida, o que ajuda a manter sua discussão focada em uma solução viável, apoiada nos melhores argumentos e não no salário.
Erros de implementação e reprojeto durante o sprint
Parece haver um problema fundamental na coleta de requisitos, seguido por um estoque muito vago de produtos.
Como eu disse acima: Desde que Product Backlog
esteja em boa forma, deve ser difícil não entender.
Não consigo imaginar uma situação como:
»Como usuário, quero ver alguns clientes!«
»Oh, você não quis dizer todos os nossos 2 milhões de clientes?«
OTOH: O que significa, neste contexto, redesenho ? Se um desenvolvedor escolheu um algoritmo de desempenho lento , existe o próximo objetivo claro: escolha um algoritmo de melhor desempenho. Mas isso não é "redesign", é uma otimização.
Para suas principais perguntas:
Como lidar com isso?
É trivial mencionar, mas eu faço assim mesmo: não esqueça que você está lidando com humanos .
É muito difícil ter um grupo de mentes diferentes, capazes de compartilhar conceitos comuns (como em Rashomon ). Para lidar efetivamente com isso, use o máximo de redundância possível em sua comunicação: por exemplo, explique o contexto do item extensivamente, mesmo que todos "saibam" o que fazer. Faça perguntas, se todos entendem qual é o tópico de um determinado item.
Se você está jogando no planejamento de pôquer, um bom indicador, se o entendimento é bom o suficiente, é que as tarefas são classificadas como baixas. Baixo significa baixa complexidade, fácil de entender e difícil de perder.
Um efeito colateral da iteração é que os números de determinadas tarefas aumentam (porque a equipe tem um entendimento de seus recursos e das complexidades ocultas). Depois, há a chance de dividir o item em vários itens menos complexos e com menor complexidade.
Quantos detalhes devo discutir durante o planejamento para caber 2 horas de duração por uma semana de corrida?
Resposta salomônica: o menos possível e o necessário, mas não mais.
tl; dr
Escolha um idioma fácil (se ajudar, use inglês simples ou ELI5
) para evitar mal-entendidos
Melhorar a coleta de requisitos
Melhorar lista de pendências
Aumentar a confiança dos membros da equipe em suas capacidades individuais, bem como em suas habilidades como equipe
Evite ciclismo
Melhore a disciplina pessoal
Talvez use caixas de tempo fixas para cada item para discutir
Reforçar a posição do scrum master
moderar de forma eficaz.