Scrum: Sprint curto VS longo

8

Estávamos tentando descobrir a duração ideal do sprint para o nosso projeto. Depois de trabalhar em 3 semanas, pensamos que cortar o sprint para 2 semanas proporcionaria uma velocidade melhor.

As vantagens eram claras: ciclo de feedback mais curto, pequenas histórias (com valor para o usuário) e assim por diante. Por outro lado, existem muitas desvantagens, como cerimônias (planejamento retrospectivo) e outras que não produzimos e agora acontecem com mais frequência.

Fiquei me perguntando como, para uma nova equipe, podemos decidir sobre a duração ideal do sprint?

— Avi
fonte

1

Embora o planejamento e a retrospectiva ocorram com mais frequência, você também não tem 2/3 do que falar? E assim, você não pode encurtar a reunião?

— PDR

3

Minha experiência com o scrum mostra que a retrospectiva levará o maior tempo possível. O planejamento pode ser um pouco mais curto, mas não tenho certeza disso. Além disso, há a demonstração na reunião de clientes / po e sprint-review.

— Avi

2

Isso deixa duas possibilidades. 1. Sua retrospectiva foi, talvez ainda seja, muito curta. Não veja isso como um tempo improdutivo, porque aumenta sua produtividade o resto do tempo. 2. Sua retrospectiva carece de estrutura e não está conseguindo muito. Nesse caso, a solução é óbvia.

— PDR

1

Aproximadamente 1 - não costumo concordar que foi curto. As pessoas da minha equipe adoram conversar :) Tentamos manter o foco, mas muitas vezes acontece que a discussão chega a lugares onde nada produtivo será resultado. A estruturação temporal da retrospectiva ajuda a reduzir essa discussão e retomar o caminho para uma discussão produtiva com conclusões claras e itens de ação para o futuro. Em relação a 2 - concordo e tenho investigado maneiras de melhorar nossas retrospectivas recentemente. Mabye Vou abrir uma pergunta diferente para retrospectiva.

— Avi

1

@pdr: Há um custo fixo para cada reunião (por exemplo, antes e depois de uma interrupção, você não trabalha em nada sério). Portanto, menos reuniões podem ser mais eficientes do que muitas reuniões curtas.

— Giorgio

8

Eu acho que você está olhando para trás um pouco. A velocidade é um efeito posterior do trabalho que sua equipe está realizando. É não um fator causal - ie. é algo que você mede e não é algo que você pode ajustar diretamente.

Esta explicação da velocidade tem um detalhe relevante para sua pergunta.

A maneira mais simples de definir velocidade é: o número ou histórias de usuários que uma equipe / projeto pode fazer em um sprint

E, por essa definição, um sprint mais longo significa mais tempo para o desenvolvimento por sprint e, portanto, um número de velocidade maior.

A velocidade relativa entre um sprint de 2 ou 3 semanas é uma questão um pouco diferente. A sobrecarga das cerimônias do projeto pode afetar o quanto você pode fazer, porque há menos tempo geral disponível. Considere esse cálculo como uma maneira de identificar as horas de desenvolvimento disponíveis em um sprint.

DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs

CeremonyOverheadgeralmente é fixo. Diminua seu DaysInSprinttamanho e veja como você terá menos tempo disponível para desenvolvimento durante esse sprint. Usando um exemplo simples de 1 dev, aqui estão os números para alguns comprimentos de sprint.

1 semana:
((8 * 5) - 4) * .8 = 28,8 horas ou 5,76 horas por dia.
2 semanas:
((8 * 10) - 4) * .8 = 60,8 horas ou 6,08 horas por dia.
3 semanas:
((8 * 15) - 4) * .8 = 92,8 horas ou 6,18 horas por dia.

A resposta "óbvia" é que os sprints mais longos são melhores. O problema com a resposta óbvia é que ela ignora o impacto benéfico dos ciclos de feedback. Tempere pensamentos sobre esse cálculo com uma perspectiva geral sobre o que o Agile deve trazer para o processo de desenvolvimento.

Suspeito que seu principal problema é que suas histórias de usuário não estão tão definidas quanto poderiam ser. Essa falta de compreensão do que é necessário é o verdadeiro impedimento para a realização do trabalho.

1

Não é esse o problema. Eu realmente tento pensar, objetivamente, em como fazer essa decisão.

— Avi

2

@Avi - minha especulação à parte, agora você pode observar os efeitos quantitativos de diferentes comprimentos de sprint. Basta conectar os números apropriados à sua equipe em relação à sobrecarga e ao fator de utilização. A partir daí, você tem um ato de equilíbrio entre a duração do sprint e o impacto no ciclo de feedback. Por esse motivo, o Agile incentiva a fazer coisas de maneira diferente para experimentar e identificar construtivamente meios de melhoria. Altere os comprimentos do sprint por um tempo e veja quais são os resultados.

3

Você disse que "CeremonyOverhead geralmente é fixo". Seus rituais de sprint não deveriam ser dimensionados com o tamanho de seus sprints? Este artigo afirma que "as reuniões do sprint são dimensionadas linearmente com a duração de um Sprint. Portanto, uma Sprint de uma semana terá duas horas de planejamento da Sprint, uma Sprint de duas semanas terá quatro horas e assim por diante". o que pode ser um pouco otimista, mas deve ser quase linear.

— precisa saber é o seguinte

7

Por outro lado, existem muitas desvantagens, como cerimônias (planejamento, retrospectiva) e assim por diante.

Esta é uma grande bandeira vermelha. Se você o vê como cerimônia, e não como veículo essencial que serve ao processo de trabalho e à sua melhoria, provavelmente trabalhar nele tem mais ganho do que mexer no comprimento do sprint.

O processo está nas suas mãos (ou seja, na equipe). Você deve perseguir as idéias mais bonitas, se precisar experimentar e se ajustar. Estávamos fazendo 2 semanas e depois mudamos para 3 semanas e funcionou melhor. Mas, às vezes, apenas defina o comprimento com base na estimativa do escopo. Sim, estou ciente da idéia de "comprimento igual", mas não é um dogma e pode não se encaixar em algum projeto da vida real. E ter um objetivo de sprint claro e evidente pode servir melhor.

O comprimento adequado não é realmente algo que possa ser deduzido de fora. Você está lá para conhecer os fatores relevantes. No planejamento, você pode começar com "ok, o que podemos fazer nas próximas X semanas". Ou então "qual seria o próximo incremento sensível". De qualquer forma, planejar o último é bom; então, observe que horas levaria. E parte disso em um ou mais sprints.

— Balog Pal
fonte

1

Eu concordo com o seu diagnóstico. As reuniões serão breves, simples e eficazes por uma equipe experiente. Reuniões longas que a equipe tenta evitar são um sinal claro de uma implementação interrompida do ágil.

— precisa saber é o seguinte

2

Você decide. Experimente os dois, veja o que funciona. Use isso.

O melhor 'sprint' ágil que já usei foi de 6 semanas. Fizemos muitas coisas - mas só precisávamos entregar ao cliente dentro desse prazo. Não usamos tarefas, preferindo trabalhar ao estilo de trabalho da história do usuário.

— gbjbaanb
fonte

Eu sei que depende de mim e cada equipe tem suas preferências. No entanto, eu queria reunir alguns prós e contras para tomar uma boa decisão já no início. Btw. Neste projeto de seis semanas de sprint - você teve mais de um sprint?

— Avi

Seis semanas parecem muito para um sprint, talvez demais. Eu acho que, na maioria das situações, se você for além de 4 semanas com um sprint, provavelmente você está fazendo errado ...

— Radu Murzea

Eu acho que o gbjbaanb teve apenas 6 semanas para o projeto. Ou em outras palavras - o projeto foi de apenas 1 sprint. Obviamente, mesmo um projeto de 6 semanas pode ser dividido em sprints de 1-2 a 3 semanas.

— Avi

tivemos cerca de 6 a 8 meses de trabalho a fazer. Aconteceu que 6 semanas foram boas para nós e para o cliente que revisamos nossas entregas, e esse é o ponto - ignore quem disser o que deve ser um sprint . É o que o torna mais produtivo. Lembre-se, o ágil diz que fornece software de trabalho regularmente, não diz 2 semanas. Eu trabalhei em sprints de duas semanas em que tivemos que fazer muita pesquisa para fazer a entrega, em cada extremidade as demos eram embaraçosas em sua brevidade, e o feedback delas era inconseqüente. Então tivemos muitas despesas gerais por pouco resultado. YMMV

— gbjbaanb

1

Depende do que você descreve uma "nova equipe".

De fato, a velocidade de uma equipe depende de muitos parâmetros entre muitos (ex .: juniores ?, seniores ?, recém-chegados ?, tensões entre os membros da equipe ?, etc.).

Portanto, o comprimento "ideal" do sprint também está vinculado a esses parâmetros.

De qualquer forma, não existe uma solução pronta para isso, a única maneira é testá-la com a própria equipe e também levar em consideração o melhor ajuste médio para todos os membros da equipe.

— Vincent
fonte

1

Eu questiono sua sugestão de um "ciclo de feedback mais curto". Sua equipe deve trabalhar com seus clientes diariamente - o feedback não deve esperar pela Revisão e Retrospectiva da Sprint. Teste, codifique, projete e obtenha feedback imediatamente .

Pessoalmente, gosto do sprint de três semanas, porque a semana do meio permite à equipe algum tempo de "fluxo". Ou seja, sempre há muito tempo acelerando a primeira semana (aprendendo o que diabos essas novas histórias significam) e alguns terminando a última (preparando a revisão). Uma semana no meio para simplesmente produzir software de trabalho é uma coisa muito boa de se ter.

Levando essa lógica adiante, as corridas de quatro semanas fariam ainda mais sentido. No entanto, o senso de urgência pode ser perdido se você começar a estender seus sprints. Além disso, existe realmente um pedaço relativamente pequeno de informação que uma pessoa ou equipe pode captar e reter em seu pensamento consciente ao mesmo tempo - quanto mais longo o sprint, mais coisas você está tentando focar, o que pode tornar as coisas mais difíceis do que Mais fácil. Além disso, é mais difícil julgar quais fatores externos surgirão se você estender as coisas muito longe.

— Matthew Flynn
fonte

1

Como você perguntou sobre uma nova equipe, gostaria de acrescentar algumas idéias. Trabalho com Scrum e outros métodos Agile há mais de 15 anos e agora sempre recomendo que as novas equipes comecem com Sprints de uma semana. Existem três razões críticas para isso:

Sprints mais curtos ajudam as equipes a alcançar um estado de alto desempenho mais rapidamente. Long Sprints geralmente significam que são necessários 18 meses a dois anos para chegar a esse estado. Sprints curtos de uma semana ajudam a equipe a atingir esse estado de alto desempenho em apenas dois ou três meses. É claro que outras coisas também precisam estar em vigor para obter alto desempenho (consulte "A sabedoria das equipes", de Katzenbach e Smith).
Como outros já mencionaram, um Sprint mais curto aumenta o ciclo de feedback. Uma Sprint de uma semana parece ser ideal para a maioria das equipes que desenvolvem software ou desenvolvimento de produtos. O feedback deve ocorrer principalmente durante a Sprint Review, que deve substituir o seu processo UAT tradicional.
Por fim, Sprints mais curtos pressionam sua equipe a lidar com obstáculos organizacionais à entrega frequente. Essa pressão é muito desconfortável no início, mas é essencial para melhorar seus processos gerais de desenvolvimento, incluindo planejamento, conformidade, lançamentos, etc.

Eu escrevi um artigo chamado 21 Dicas para escolher um comprimento de sprint que possa ser interessante.

— Mishkin Berteig - Treinador ágil
fonte

0

As cerimônias têm um objetivo - quando reconhecemos o objetivo, percebemos que elas não estão sobrecarregadas, mas agregam valor.

Planejamento - não apenas sobre o compromisso de trabalhar, mas também sobre como trabalhar com seus colegas de equipe. Quando as pessoas reclamam da falta de colaboração em sua equipe Scrum, eu gosto de ver o seu Sprint Planning como parte do problema

Revisão - colete feedback do cliente sobre o que estamos construindo e ainda é relevante etc. Também atua como uma verificação de qualidade.

Retrospectiva - melhore a maneira como trabalhamos juntos como uma equipe.

Quando nos esforçamos para honrar o objetivo mais profundo, o problema de sobrecarga geralmente desaparece. Como foi observado nos comentários originais da pergunta, as cerimônias geralmente são dimensionadas linearmente.

Se você precisar de mais informações sobre o assunto, tenho um artigo: Escolhendo um comprimento de sprint

— Mark Levison
fonte