Imprimir planejamento

Artigo
02/25/2013

Por Mitch Lacey.Proprietário, Mitch Lacey & associados, Inc, uma empresa de consultoria especializada em adoções e aprimoramentos de agile e scrum.

Janeiro de 2012.

O planejamento de sprint não precisa ser desafiador.É geralmente divertido e às vezes para toda a equipe Scrum construir camaradagem trabalhando juntos para responder à pergunta de "O que nós podemos nos comprometer?" Neste artigo, os autores fornecem exemplos e estratégias para manter o planejamento de sprint focado e eficaz, e soluções de detalhes possíveis para as equipes de problemas comuns encontrados ao planejar um sprint.

Aplica-se a

Gerenciamento do ciclo de vida do aplicativo; Team Foundation Server

Neste artigo:

Introdução
Previsão contra Confirmação
Que é um planejamento de Sprint?
Como fazemos isso?
Problemas comuns
- Cenário: A equipe não pode comprometer-se com todas as histórias que o proprietário do produto solicitou.
- Cenário: O proprietário do produto não vem preparado.
- Cenário: A parte 1 excede o timebox.
- Cenário: A parte 2 excede o timebox.
- Cenário: O proprietário do produto não está disponível.
- Cenário: A equipe não tem os critérios de aceitação de que precisa.
- Cenário: O proprietário do produto não souber que significa concluído.
- Cenário: O proprietário do produto ou o ScrumMaster está estimando/influenciando as estimativas/o trabalho da equipe.
Conclusão

Nós não planejamos.Fazemos o scrum, portanto apenas executamos.

Eu ouço isto o tempo todo.As pessoas pensam que Scrum e Agile não requerem planejamento, estimativa, reuniões: nada!Isso está longe de ser verdade.Nós planejamos em uma variedade de níveis em um projeto ágil: o plano diário ou o standup diário, os planos semanais (sprint, ou iteração, reserva), o plano de versão (a reserva do produto), e possivelmente mais.

Vamos focar no planejamento de um sprint.

Previsão contra Confirmação

No verão de 2011, Ken Schwaber e Jeff Sutherland revisaram o Guia de Scrum.Nela, removeram um longo comportamento estabelecido conhecido por Scrum, que é o compromisso que a equipe faz com o proprietário do produto e os clientes.O comprometimento foi substituído pela previsão.Eles dizem que as equipes pode prever seu trabalho, mas não se comprometer com ele.

Enquanto eu compreendo sua lógica, eu prefiro comprometer as seguintes razões:

Confirmar algo coloca a equipe em um mindset diferente do que apenas a previsão.Se nas previsões de uma equipe está implícito que não cumpriu com tudo o que eles disseram que poderiam fazer, é um comportamento aceitável.Enquanto as equipes aprendem com previsões, tendo por fim menos variação de avaliação, eu constato que as equipes que preveem levam mais tempo para reduzir a variação em relação às equipes que confirmam.
Prever, ou estimar, são apropriados para o retorno do produto.No entanto, quando as equipes movem os artigos da lista de pendências do produto para a lista de pendência sprint e as dividindo, elas estão adicionando outro nível de granularidade, localizando pequenos detalhes que permitem que eles se perguntem "nós podemos nos comprometer com isto?" Prevendo corre o risco de voltar para um estado lento pela equipe em vez de "nós somente precisamos prever, está OK se perdemos algum material, nós podemos descobrir tudo mais tarde."

E uma nota mais leve, imagine se você disse a sua esposa, marido, parceiro “Eu previ que nós estaremos juntos por dez anos” contra “Me comprometo com você” – sim, isso acabará bem.

No final, o Scrum é sobre o senso comum.Eu sugiro que você tente tanto a abordagem de compromisso como a abordagem de previsão.Trata-se de aprender, e não das palavras que você usa, então seja esperto. Experimente ambos e use o que for melhor para você, para sua equipe e sua empresa.

O que é um planejamento de sprint?

Nós realizamos uma reunião de planejamento de sprint para planejar o que a equipe compilará no próximo sprint e como a equipe compilará.Embora mencionamos como reunião de planejamento de sprint, é realmente composto de duas partes muito diferentes.A parte 1 se concentra naquilo que a equipe deve criar e é integrada pelo proprietário do produto e pela equipe.A parte 2 aborda como a equipe planeja criar a funcionalidade desejada.Embora a toda a equipe deva participar da Parte 2, o comparecimento pelo proprietário do produto é opcional.Se, por qualquer motivo, o proprietário do produto não atende a parte 2, o proprietário do produto deve permanecer disponível para perguntas.

Na parte 1 da reunião de planejamento do sprint, o proprietário do produto tem a oportunidade para descrever um conjunto desejado de artigos para a equipe.Essa é uma sessão profunda em qual parte das histórias.O proprietário do produto apresenta as histórias, mostra como as coisas interagem e percorre a interface.Além disso, pode revisar a infra-estrutura ou itens arquitetônicos.O objetivo é encher os chefes dos membros da equipe com informações suficientes para que eles possam começar a imaginar como criar funcionalidade.A equipe irá fazer uma série de perguntas para coletar informações para a reunião de como - perguntas como:

“Qual é o critério de aceitação de todas estas histórias?”
“Quais fontes de dados você pensa que está usando?”
“Como deve ser a aparência da interface neste componente?”

Durante a Parte 2 de reunião de planejamento de Sprint, a equipe direciona sua atenção para a criação da reserva de sprint - a lista de histórias e tarefas necessárias para concluir durante o sprint.Para criar a reserva, a equipe divide cada artigo que o proprietário do produto solicitou no nível da tarefa; cada tarefa recebe a avaliação de hora em hora.Até o final da Parte 2, a equipe decide quais histórias pode utilizar para concluir durante o sprint.

Juntas, as duas partes da reunião de planejamento de sprint podem ir a qualquer lugar de duas a oito duas horas.A regra geral do elevador que eu usei é a de que cada parte deve levar uma hora para cada semana de comprimento da sprint.Isso significa que se eu estou executando sprints de uma semana, a reunião terá um total de duas horas (uma hora para a Parte 1 e uma hora para a Parte 2).Se, por outro lado, eu estou executando sprints de quatro semanas, a reunião terá um total de oito horas (quatro horas para a Parte 1 e quatro horas para a Parte 2).

Como fazemos isso?

Conforme a equipe deixa a reunião de planejamento de sprint comprometida a concluir uma lista de histórias, a equipe obteve a finalidade do planejamento de sprint.Levar a equipe para o ponto onde cada membro se sente confortável em realizar este compromisso. No entanto, exige um pouco de pré-planejamento e facilitação.

O proprietário do produto tem um trabalho durante o planejamento de sprint: vir à reunião apto a descrever um conjunto de histórias desejadas.O objetivo da equipe é entender as histórias do ponto de vista do proprietário do produto, para compartilhar na visão do proprietário do produto.O ScrumMaster deve garantir que a equipe esteja fazendo perguntas suficientes e capturando todos os dados resultantes, incluindo os critérios de aceitação, esboços e todas as suposições.O ScrumMaster também deve informar ao proprietário do produto que a equipe pode ter perguntas adicionais depois que as perguntas começam a se decompor em tarefas.Embora o proprietário do produto apresente histórias cujos totais de ponto correspondem à velocidade de história da equipe, a equipe decidirá se pode finalmente, de fato, levar todas as histórias em um determinado sprint com base no que aprende durante a Parte 1 e a Parte 2 da reunião de planejamento de sprint.

Depois que a equipe obter qualquer informação do proprietário do produto, deve dividir as histórias em tarefas e criar um retorno de sprint, que captura todas as histórias, notas, critérios aceitação, tarefas e avaliações para uma sprint específico.Quando há várias maneiras para fazer isso, eu emprego o seguinte método, que tira vantagem das ideias de todos os membros da equipe e concede a todos uma voz na decomposição de tarefa.

Ter o ScrumMaster ou o facilitador de reunião ler uma história e pedir, “Todos compreenderam?” A equipe deve, como apenas passa tempo com o propriedade do produto discutindo.Se alguém da equipe não compreende, dedique algum tempo revisitando o artigo, fazendo todas as perguntas necessárias relativas ao proprietário do produto.
Em seguida, peça que cada membro de cada equipe pegue um bloco.Solicite que cada membro da equipe grave uma única tarefa em cada anotação e lance no meio da mesa.
- Conforme cada anotação é enviada para o meio da mesa, o atirador anuncia a tarefa.Se o “atualizar procedimento armazenado” for escrito, deverá ser dito em voz alta.Isso é importante porque trará ideias e fará com que os outros digam “Ah, sim, e nós precisamos atualizar a fonte de dados.” Nesse momento, alguém irá escrever em um bilhete, “atualizar fonte de dados,” dizer isso e jogar no meio.Essa atividade de brainstorming realmente funciona para revelar todas as tarefas associadas.Não se preocupe sobre duplicatas no momento.Jogar fora todas as anotações de tarefa geralmente leva de cinco a dez minutos por história.
Quando todos os stickies estiverem na tabela, é hora de classificar-los.Coloque todos eles em uma parede, dê um passo atrás e veja só: montes de anotações!Comece identificando qualquer duplicata; substitua qualquer anotação que parecerem estar duplicada.Procure as tarefas que aparecem juntas, tanto por serem semelhantes ou por dependerem umas das outras.Por exemplo, se duas anotações têm uma relação similar, coloque-os junto, mas desloque-os, como mostra a ilustração a seguir:

Se duas tarefas são tão intimamente relacionadas a ponto de serem quase idênticas, sobrepor-las quase totalmente, como mostrado abaixo:

Classificando as anotações, a equipe pode selecionar a lista de tarefas e visualizar os relacionamentos entre aqueles que permanecem.
Quando as tarefas são classificados, é hora de estimar.Eu uso a técnica de planejamento do pôquer para estimativa de tarefa, com uma diferença: os números nas cartas representam horas em vez de pontos.Eu faço isso porque as pessoas tendem a ficar muito tempo presas em detalhes inúteis no que diz respeito às horas, especialmente em grandes tarefas.Há um bom motivo para trepidação.Muito frequentemente, as empresas usam a avaliação como uma vara para bater na equipe.“Você disse que levaria 8 horas e levou 12.O que está errado?” ou “disse que levaria 8 horas e recebe apenas 4.Você está preenchimento suas classificações.”

Da mesma forma que os cartões ajudam a manter o resumo das estimativas e classificações de artigo-ponto, usando cartões para estimativa de tarefa permite que a equipe tenha a liberdade que vem com um conjunto de números fixos para escolher, enquanto força-os a, finalmente, fazer uma escolha.Ele também elimina discussões calorosas de se uma tarefa deve ser estimada em 6 horas, 6.5 horas ou 7 horas.

Seja qual for a avaliação final, lembre-se que ela é feita por uma equipe e destinada a ser usada somente pela equipe para ajudar a aumentar sua confiança e a determinar se pode fazer o trabalho que o proprietário do produto solicitou com base na velocidade.As estimativas de tarefa não são métricas e não deve ser usadas como tal.Nunca use avaliações como uma arma contra a equipe.
Agora que as tarefas foram estimadas, a equipe deve determinar se pode aceitar mais trabalho.Para fazer isso, você precisará saber a capacidade de equipe, o total de horas que a equipe tem disponível durante a sprint.Determinar a capacidade é fácil se você tiver uma equipe totalmente dedicada, mas se torna mais fácil se tiver uma equipe composta de pessoas de meio período que estão divididas em vários projetos.Peça a todos para escrever o número de hora em que cada um pode trabalhar no projeto por dia (ou o total por sprint).Adicione todos os números juntos para obter o número total de horas disponíveis para a equipe.Vamos dizer que a capacidade da equipe passa a ser de 200 horas.Se a soma das tarefas para um artigo é estimada para consumir 30 horas, perguntar a equipe, "Podemos pegar mais trabalho?" Neste estágio inicial, a resposta é um óbvio sim.

Como você tem mais capacidade para preencher, continue na história a seguir e repita as etapas de um a cinco.

(Para obter informações sobre como realizar essa tarefa usando o Team Foundation Server, consulte Planejamento ágil e iterações.)

Em algum ponto, você terá dificuldade em respondem a pergunta, "Como podemos pegar mais trabalho?". Isto ocorre porque você está aproximando a capacidade de sua equipe.Conforme você trabalha com esse processo, considere que você não deseja preencher o sprint para capacidade.Se você encher um copo com água até a borda, é muito provável que derrame.O mesmo vale para as sprints.Se a hora estimadas consomem todo o tempo disponível e uma nova tarefa é identificada posteriormente no sprint, as coisas derramarão.Você deve deixar espaço para tarefas emergentes.

Ao considerar o comprometimento de sprint, isso ajudar a considerar dados retrospectivos de sprints do passado.A equipe é que tem que consistentemente trazer mais trabalho?Talvez a equipe possa se comprometer mais durante o planejamento de sprint.A equipe é consistentemente incapaz de terminar todo o trabalho para um sprint?A equipe pode precisar ser mais conservadora com seus compromissos até tratar da causa raiz dos sprints incompletos.

Uma maneira de responder à pergunta se “seu copo está meio cheio ou meio vazio” é considerar o crescimento do tamanho do plano.O planejamento do crescimento avalia como as horas foram realmente gastas em comparação às estimativas iniciais.Vamos dizer, por exemplo, que nossa equipe tem a capacidade de 200 horas disponíveis.A equipe se compromete como o que ela acredita que serão 190 horas, com base nas estimativas.No final do sprint, a equipe calcula que estas histórias contiveram um valor real de 240 horas de trabalho, resultando em um crescimento de tamanho do plano de 20%.

Uma equipe encontrar esta discrepância deve passar algum tempo durante a retrospectiva investigando as razões:

Muitas tarefas estão sendo descobertas durante a execução que não foram identificadas durante o planejamento?
A equipe está subestimando suas tarefas baseada em seu conjunto de habilidades atual?
A equipe superestimou sua capacidade?
E assim por diante.

A equipe também deve considerar seu crescimento de tamanho de plano durante a próxima reunião de planejamento de sprint ao determinar se pode se comprometer com uma história.Volta para nosso exemplo, se a equipe ainda estima uma capacidade de 200 horas, deve subtrair 20% da parte superior para compensar o crescimento de tamanho do plano “esperado” com base nos dados históricos.Em outras palavras, pelo menos este sprint, para evitar derramamentos, quando a equipe chega a 160 horas, deve declarar-se em capacidade.

Considerar o plano de crescimento de tamanho é uma maneira de quantificar como completo um sprint deve ser.Perceba que, no entanto, o objetivo é não corresponder exatamente à capacidade.Em vez de isso, é para permitir que a equipe sinta-se à vontade para comprometer-se com um número apropriado de histórias — um que pressione a equipe sem sobrecarregá-la.Planejar o crescimento é apenas uma maneira de determinar o volume aproximado de conteúdo do sprint seguinte, caso todos os outros fatores permaneçam iguais.

Quando todas as estórias são estimadas ou todo o tempo é consumido por estórias volte ao proprietário do produto, e compartilha a fallback sprint que o team comprometeu para fornecer.O sprint começa agora — então vamos ao trabalho!

Problemas comuns

Em meus anos de consultoria com equipes com ajudá-los a adotar o Scrum, eu já vi muitos dos mesmos problemas que impedem o planejamento do sprint com êxito.Embora o planejamento de sprint pareça simples, as equipes que estão apenas começando com Scrum tendem a ter dificuldades.Muitos destes problemas e suas soluções potenciais são detalhadas nesta seção.

Cenário: A equipe não pode comprometer-se com todas as histórias que o proprietário do produto solicitou.

Você deve esperar que isso aconteça ocasionalmente.Enquanto a equipe pode fazer backup do compromisso com os dados das etapas quatro e cinco anteriormente neste tópico, o proprietário do produto deve ser satisfeito.Convém manter a atenção para se certificar que essa falha de confirmação não é um resultado de preenchimento excessivo ou de grandes tarefas.O ScrumMaster deve contestar o que parecem ser avaliações excessivamente conservadoras para garantir sua exatidão.O proprietário do produto deve questionar toda tarefa que tenha uma avaliação de dois dígitos.Qualquer tarefa estimada para levar mais do que dois dias úteis deve ser dividida em tarefas menores e ser estimada novamente.Isso é verdade para todos os projetos, mas é especialmente preocupante para equipes que executam sprints de uma ou duas semanas.

Cenário: O proprietário do produto não vem preparado.

O valor de um Scrum é respeitado.É desrespeitoso vir a uma reunião despreparado.O que uma equipe deve fazer se o proprietário do produto aparecer sem informações as necessidades de equipe?Embora uma opção é adiar a reunião até que o proprietário do produto esteja pronto, fazer isso apenas incentiva o mesmo comportamento - evite.Outra opção é cancelar o sprint.Embora isso possa funcionar, é extremo.

Eu achei que a melhor solução deve ser duas-dobras.Primeiro, a reserva do produto deve estar em algum tipo de ordem de prioridade, portanto, se o proprietário do produto não tem um determinado conjunto de histórias, a equipe e o proprietário do produto podem apenas discutir as histórias na ordem de prioridade até atingir um ponto onde acreditam que estará em sua capacidade ou além.A equipe pode decidir sobre o compromisso exato durante a parte 2 de reunião, como de costume.

Após a reunião, o ScrumMaster deve funcionar para compreender como o proprietário do produto não foi preparado.Se o problema foi perda de compromisso, o ScrumMaster pode educar o proprietário do produto sobre a importância de chegar à reunião preparado com um conjunto de artigos.Se, por outro lado, o problema foi que o proprietário do produto foi incapaz de se preparar, talvez porque a equipe falhou ao ajudar com a preparação, o ScrumMaster deve ajudar a resolver esses problemas também.

Cenário: A parte 1 excede o timebox.

Outro valor é foco.Se a Parte 1 da reunião está sendo executada, é sintomática de uma falta de foco.Às vezes o proprietário do produto não está focado devido à falta de preparação, de priorização ou ao tentar explicar muitas histórias.Outras vezes, a falta de foco pode ocorrer porque a equipe mistura aos debates sobre “o que” especificidades sobre “como”.

O ScrumMaster deve ajudar a movimentar as coisas, insistindo o proprietário do produto apresenta todas as histórias que não podem ser totalmente explicadas e que a equipe mantém discussões detalhadas de implementação além da parte 1.Uma solução simples para discussões sem foco é o uso de um cronômetro ou um temporizador.

Cenário: A parte 2 excede o timebox.

Novamente foco.Se você tem uma equipe que fala muito, às vezes ter a disciplina para limitar discussões é tudo que é necessário para trazer a reunião de volta a linha.Trazer um egg timer e manter as conversas para um minuto ou dois entre estimativas de tarefas.O objetivo é a precisão, não 100% de precisão.

Outras vezes, a perda de foco na Parte 2 mostra descuido no gerenciamento da lista de pendências do produto durante a execução do sprint.Preparar é um horário em que a equipe pode examinar as histórias e o trabalho futuros com o proprietário do produto para adicionar as histórias ou pontos para indicar instruções de design ou abordar perguntas de arquitetura.Sem a reserva normal do produto que prepara, o planejamento de reserva de sprint se torna incômodo e doloroso.

Cenário: O proprietário do produto não está disponível.

Se o proprietário do produto não pode comparecer à reunião por qualquer motivo e não designou um proxy, atuar como se o proprietário do produto veio a reunião despreparado.Trabalhar pelos itens superiores e confirmar a eles o melhor que você pode.Você pode ter tentado mudar a hora de reunião para acomodar a agenda do proprietário do produto.Não.Mudar a hora de reunião atende à necessidade de uma pessoa às custas de várias outras.Não vale à pena.

Cenário: A equipe não tem os critérios de aceitação de que precisa.

Eu sempre aconselho as equipes a perguntar ao proprietário do produto durante a Parte 1, "Qual é a aceitação dos critérios para isto?" ou "O que precisamos fazer para levá-lo a aceitar o trabalho?". Se isto estiver faltando na parte 2, quando a equipe estiver determinando as tarefas, a equipe não terá idéia de como começar a fechar o artigo história.Se a equipe tem que descobrir, baseada no que ela ouviu na Parte 1, a equipe corre o risco do proprietário do produto decidir no final do sprint que o artigo não está concluído.Peça pelos critérios de aceitação do início de cada história.ScrumMasters — treinem os proprietários de produtos a fornecerem esses dados.

Cenário: O proprietário do produto não souber que significa concluído.

Assim como a equipe quer critérios de aceitação, o proprietário do produto merece uma descrição atualizada do que a equipe entende por "a história está feita". Esta lista feita deve ser colocada em local visível atualizada e disponível para o proprietário do produto em todos os momentos.Uma lista de tarefas desatualizadas torna difícil planejar porque não há uma compreensão comum do que será feito.Certifique-se de que a atualização da lista concluída é uma parte de cada revisão ou retrospectiva de sprint.

Cenário: O proprietário do produto ou o ScrumMaster está estimando/influenciando as estimativas/o trabalho da equipe.

O proprietário do produto é bem-vindo na parte 2 da reunião, mas a função do proprietário do produto na parte 2 deve ser limitada a esclarecer um requisito ou para endereçar uma pergunta específica.O proprietário do produto nunca deve interferir na discussão da equipe sobre como implementar uma história, e não deve dizer nada na avaliação de uma tarefa.O proprietário do produto precisa confiar na equipe para fazer o trabalho.

Se o proprietário do produto está agindo fora destas diretrizes, o ScrumMaster deve treinar o proprietário do produto para uma função mais apropriada.Se o proprietário do produto se recusa a aceitar uma função mais passiva, o ScrumMaster tem a autoridade para solicitar que o proprietário do produto saia.

O planejamento de sprint não precisa ser desafiador.É geralmente divertido e às vezes para toda a equipe Scrum construir camaradagem trabalhando juntos para responder à pergunta de "O que nós podemos nos comprometer?" Lembre-se, se você achar que suas reuniões duram muito, a raiz causa problemas que são provavelmente a causa disto.Se você for o ScrumMaster, manter a reunião focada garantindo que o proprietário do produto e a equipe limpe a lista de pendência do produto.Ajuda o proprietário do produto a vir preparado ter os critérios de aceitação dessa história prontos antes de reunião.Finalmente, ajude a manter o proprietário do produto e a equipe focalizados na tarefa em mãos - determinar em que podem se comprometer para o sprint.