Subtarefa inicial no início de cada sprint

Entrei para uma nova equipe que usa o Agile / Scrum, e o processo de desenvolvimento é o seguinte:

1) os desenvolvedores revisam cada história antes de cada sprint para garantir que não perca nada de crítico. Há um estado formal para isso no fluxo de trabalho.

2) durante o kickoff da Sprint, toda a equipe faz uma estimativa (planejamento de pôquer) de quantos pontos de história cada história custaria.

3) finalmente, imediatamente após o início de cada sprint, cada desenvolvedor deve dividir ansiosamente todas as histórias atribuídas em subtarefas com estimativas de tempo (em oposição à subtarefa antes de iniciar cada história).

O principal argumento para a última etapa é que ajuda a descobrir se a implementação de uma história levaria mais tempo do que o previsto e alertar o mestre de scrum sobre os riscos potenciais de perder os prazos de sprint.

No entanto, acho isso contraproducente, principalmente pelos seguintes motivos:

• se o objetivo é fornecer uma estimativa aproximada, os pontos da história (etapa 2) são o que faz o trabalho. Caso contrário, por que se preocupar com os pontos da história? - apenas faça subtarefas desde o início.
• se o objetivo é fornecer estimativas precisas, este é um exemplo claro do que é descrito em Interruptores de tarefas humanas considerados prejudiciais . Acho que esse é especialmente o caso de novos desenvolvedores que se juntam às equipes existentes em grandes projetos, onde a compreensão do que precisa ser feito pode levar até 50% do tempo. Você é obrigado a entrar em detalhes da história nº 1, depois da história nº 2, nº 3, etc. etc., o que gera muitas informações.

Também me disseram que essa prática é "obrigatória" e não pretendo discutir isso. Alguém pode fornecer uma referência a essa prática - se isso está claramente definido nas Bíblias do Scrum, e / ou talvez fornecer alguma visão extra?

Isso não é diferente de como executamos parte do nosso processo de scrum. Nós

1. Estimar histórias perto do topo da lista de pendências em "pontos da história"
2. Selecione / explique histórias com base nos pontos que pensamos que "compensarão" o sprint
3. Divida as histórias em tarefas técnicas mais detalhadas
4. Estime as tarefas técnicas e compare com a estimativa original dos pontos da história (sabemos aproximadamente quanto tempo de desenvolvimento um ponto da história normalmente equivale a)

Mas o que você quer saber é por que estimamos duas vezes!

• Fazemos uma estimativa grosseira (com base na história) porque gostamos de poder fazer previsões sobre o que pode ser no próximo sprint, e talvez até o seguinte. Em última análise, a gerência deve ser capaz de se comunicar com o cliente sobre escalas de tempo prováveis; portanto, se não tivermos essa estimativa de escala grossa, o planejamento a longo prazo é praticamente impossível.
• Obviamente, isso significa que fazemos estimativas aproximadas para mais do que apenas o sprint atual. Como não há garantia de que o pedido de backlog não seja alterado para o próximo sprint, não queremos investir tempo em detalhamento de tarefas e estimativas em escala reduzida até que sejam necessárias.
• Dividimos a tarefa para garantir que todas as tarefas foram enumeradas e que as histórias possam ser trabalhadas em paralelo mais facilmente.
• Fazemos estimativas em escala reduzida (com base na tarefa) porque isso nos fornece um gráfico de detalhamento muito mais suave (principalmente quando não há uma maneira fácil de dividir uma grande história em "recursos" viáveis).
• Como fazemos as duas coisas, elas agem como sanções mútuas - uma discrepância selvagem indica que precisamos de um erro em algum lugar que precisamos identificar. Este é um subproduto útil, mas não é o motivo por que calculamos "duas vezes".

Relendo sua pergunta e comentário, vejo que existem algumas diferenças entre nosso fluxo de trabalho e o seu.

• Realizamos colapsos em equipe , mas, embora a sobrecarga seja maior, a discussão técnica que obtemos disso geralmente é muito valiosa e pode detectar deficiências em nossa história. Quando temos uma disparidade de experiência, conhecimento ou capacidade, essa discussão também é onde aqueles com mais podem ajudar aqueles com menos (muito útil para novos contratados).
• Fazemos estimativas no nível da tarefa como uma equipe , uma das razões pelas quais o "planejamento do poker" funciona é por causa do fenômeno "sabedoria das multidões" - como mencionei nos comentários, neste ponto, estimar que uma tarefa deve levar menos de 30 segundos , portanto, a sobrecarga é insignificante.

Parece que o motivo pelo qual sua equipe realiza as quebras de tarefas e as estimativas de tarefas são para uma redução suave - o que é bom, isso faz parte do monitoramento do progresso do sprint e permite que o scrum-master detecte e resolva problemas com antecedência. Se você quer esta informação que você tem que fazer as avarias e estimativas e você tem que fazê-las em primeiro lugar.

Na minha opinião, a troca de tarefas provavelmente não será um problema para você aqui, não acho que dividir tarefas diferentes seja realmente uma troca de tarefas no mesmo sentido que passar do desenvolvimento de um recurso para outro parcialmente é uma troca de tarefas . Eu acho que entender a "arquitetura" geral do sprint é provavelmente uma coisa bastante útil.

No entanto, acho que pode haver outros problemas que você poderia considerar. Como sempre com o Agile, você deve identificar um problema que você tem e propor uma solução e decidir se sua solução funcionou na retrospectiva . Esse é o ponto crucial da criação de uma solução ágil que funcione para sua empresa e sua equipe. Portanto, alguns problemas que você pode ter:

• Você está fazendo avarias individualmente - então, como os membros de sua equipe júnior / inexperiente estão aprendendo com os membros de sua equipe sênior? Claro, eles provavelmente podem aprender tudo sozinhos - mas aprenderão mais rápido se forem orientados. Os membros da equipe júnior estão demorando muito para quebrar as coisas? Eles estão cometendo erros ou faltando coisas que custam o tempo da equipe a longo prazo? Dividir a equipe pode ajudar aqui.
• Você está fazendo estimativas individualmente - o mesmo se aplica ao primeiro ponto, mas além disso, essas estimativas são menos precisas do que poderiam ser?
• Parece que as tarefas são atribuídas no início do sprint, mas, se for esse o caso, qual é o preço da sua alteração quando é necessário alterar a tarefa? Se alguém está ficando para trás ou doente, quão fácil é para outra pessoa realizar suas tarefas? Eles precisam passar pelas quebras de tarefas e tentar entendê-las sem interromper o responsável original? Se você analisar e estimar como uma equipe, todos deverão trabalhar em tudo!
• Suas histórias são grandes demais? Se a quebra levar 50% do tempo, as histórias parecerão muito envolvidas - talvez elas possam ser menores? Mantemos nossas histórias dentro de 1 semana de trabalho.
• Suas tarefas são muito pequenas? Se você está gastando muito tempo fazendo listas de tarefas, talvez esteja entrando em muitos detalhes? Tendemos a ter tarefas entre 1 e 8 horas de trabalho, para que, ao longo de um dia, todos façam algum progresso para relatar na próxima lista diária.

Se é assim que sua empresa deseja executar o desenvolvimento e interrompeu a discussão, suas escolhas são limitadas ou você corre pelo menos o risco de perturbar as pessoas.

Como o objetivo final do agile é trabalhar com software de valor, você pode tentar ajudar a medir a capacidade de entrega de sua equipe (pontos entregues / estimados, erros no sprint, número de testes, cobertura de código, tempo de atividade, vendas geradas - tanto faz). Esteja preparado para todos os resultados - pode ser que essa maneira de trabalhar funcione para eles, mesmo que não faça sentido para você. Se você estiver certo, o desperdício se tornará evidente.

Desconfie de seguir o processo por causa do processo - isso perde tempo e ainda oferece produtos ruins. Uma boa equipe ágil experimenta, mede e aprende. A melhor maneira de mudar o comportamento sem se desentender é com decisões baseadas em evidências.

Essa também é a minha opinião. Eu sugiro que você tente por si mesmo e avalie o resultado - veja o que eu fiz lá :)

Suponho que o seu Sprint Kickoff significa a reunião de Planejamento da Sprint. Eu acho que seu Scrum Master interpretou mal como esta reunião deveria ser. Você não apenas decide quais histórias desenvolver, mas também as testa para sua equipe sua definição de pronto para garantir que elas não percam nada (geralmente usando o INVEST ), e também as subdivide em tarefas. Para citar Mike Cohn (um dos fundadores da Scrum Alliance);

A lista de pendências do sprint é a outra saída do planejamento do sprint. Um backlog do sprint é uma lista dos itens de backlog do produto que a equipe se compromete a entregar, além da lista de tarefas necessárias para entregar esses itens do backlog do produto. Cada tarefa no backlog do sprint também é geralmente estimada.

Portanto, dividir as histórias e calculá-las faz parte da sessão de Planejamento da Sprint; não após o término da sessão de planejamento e não individualmente.

Para fornecer mais informações, nosso fluxo de trabalho durante a reunião de Planejamento da Sprint é o seguinte:

1. pegamos uma história da parte superior da lista de pendências do produto e dividimos em tarefas. Como regra geral, uma tarefa geralmente deve ser menor que um dia.

2. Estimamos a história, considerando as tarefas que deduzimos. Se a história for grande, tentamos dividi-la em histórias menores.

3. Enxágüe e repita até atingir o total de pontos estimados

Ao contrário do que Cohn diz, descobri que não há necessidade real de estimar cada uma das tarefas separadamente, pois as tarefas são especificadas como menores que um dia. Dado que as tarefas são menores que um dia de trabalho, você pode notar facilmente durante o Standup diário quando uma tarefa está demorando mais que o esperado, pois a pessoa que trabalha na tarefa específica diz que ainda está trabalhando nela.

Durante o sprint, a equipe percorre as histórias e, no final, deve refletir sobre o quanto realmente foi feito. É para isso que serve a reunião retrospectiva do scrum. Se ainda houver histórias sobre a mesa, você pode deduzir que sua estimativa foi otimista demais e agir de acordo com ela no próximo sprint. Como alternativa, pode ter ocorrido certos incidentes que afetam o quanto você foi feito, etc. Você descobrirá que as estimativas melhoram com o tempo ao refletir sobre elas.

"pelo livro" - esse é o seu problema. Você está se afogando em mais processos do que teria se estivesse trabalhando em cascatas.

Não existe um livro para o Agile, apenas o manifesto ágil que diz "faça as coisas sem toda a sobrecarga". Portanto, se você está estimando tamanhos e depois dividindo as histórias em tarefas para reestimá-las, é um processo desnecessário que precisa ser mais eficiente - é disso que trata o ágil. O Scrum e todos os outros são realmente diretrizes de ponto de partida para como você começa a agir com agilidade. Ao fazê-lo, você deve identificar esses pontos que não fazem sentido ou não ajudam sua equipe a trabalhar com mais eficiência e deve alterá-los.

No entanto, algumas pessoas pensam que maneiras proibidas de trabalhar precisam ser escritas em pedra e nunca se desviar, por mais estúpidas que sejam. Eu tentaria dividir as histórias em tarefas antes da reunião do scrum - você diz que os desenvolvedores precisam revisar cada história, bem, aqui está a chance de fazer a divisão ao mesmo tempo como parte da revisão. Em seguida, você pode declarar as tarefas que compõem a história na reunião do scrum (não alocar tempo para elas!) E permitir que as pessoas decidam o tamanho de um pacote de trabalho, com base nessas informações adicionais contidas (o que nunca é uma coisa ruim, A tomada de decisão informada é muito melhor que a adivinhação, e isso só pode ser feito quando você tiver informações para alimentar a tomada de decisão).

Após a reunião, você ainda pode atribuir horários às tarefas (embora eu não consiga entender o ponto disso, os sprints não são baseados no tempo, são baseados em "quanta coisa você espera fazer", que é medida nos pontos da história Esse é um problema comum no scrum, os pontos não significam tempo, mas você precisa completar, digamos, 20 pontos por quinzena, portanto, 2 pontos = 1 dia de trabalho. É suposto ser um palpite rápido sobre quantas tarefas colocar no sprint, para que você não fique sobrecarregado nem com muito trabalho, nem quantas serão realmente executadas. Os melhores sprints são aqueles que têm algumas tarefas restantes, o que mostra uma estimativa perfeita. atrasou a conclusão no final - nem é produtivo).

Então, resumindo - imprima uma cópia do Manifesto Ágil e a versão anti-ágil . Aposto que você está fazendo mais anti-ágil. Scrum tende a ser assim. A única maneira de corrigi-lo é se envolver com sua equipe e obter apoio para a mudança. Não deixe a gerência dizer como sua equipe deve trabalhar, isso também não é ágil e isso será escrito em The Book.

Em algum momento durante cada Sprint, você deverá ter uma Reunião de refinamento de backlog de produtos . Nesta reunião, você garante que a parte superior do Backlog do Produto seja dividida o suficiente para que os itens nessa parte sejam adicionados ao próximo Backlog do Sprint.

Se o Refinamento do Backlog do Produto for bem gerenciado, a Sprint Planning Meeting poderá ser mais eficiente. Idealmente, isso evitaria a necessidade de os desenvolvedores "avisar ansiosamente" as histórias após o início do Sprint.

Se os itens do Backlog do produto forem adicionados ao Backlog do Sprint antes de serem suficientemente detalhados para uma estimativa realista, isso dificultará a tomada de boas decisões sobre o que adicionar ao Sprint.