Quais são as possíveis / prováveis armadilhas de ter equipes scrum assíncronas?

Question

Quais são as possíveis / prováveis armadilhas de ter equipes scrum assíncronas?

#1 resposta do (8 votos)

5

Em nosso projeto de jogo, atualmente temos duas equipes que trabalham em iterações de duas semanas. No passado, repetidamente, tivemos problemas com recursos maiores (planejamento / estimativas ruins, problemas imprevistos antes do congelamento de código, fazendo com que as matérias não fossem fechadas, etc.) e discutimos esses problemas em muitas retrospectivas.

Como os recursos que devemos implementar não estão ficando menores ou mais fáceis (na verdade, exatamente o oposto), estamos pensando em maneiras de nos ajudar a reduzir o risco de cada iteração. Uma dessas idéias que eu tive, foi com uma configuração semelhante ao que ArenaNet faz com Guild Wars 2 :

[...] “And they’re all staggered, so even though we ship every two weeks, the development time for any one of these releases is around four months, it’s just that it’s a smaller team working for an extended period of time which allows them to give it the level of polish that players have come to expect. But it is intense!” [...]

A idéia básica era manter o ciclo de lançamento de duas semanas, mas deixar as equipes fora de fase, de modo que cada equipe tivesse um total de quatro semanas para trabalhar no conteúdo. Então, basicamente, a configuração mudaria disso:
paraisso:

É claro que os lançamentos seriam maiores do que antes, mas à primeira vista parece pelo menos um pouco benéfico:

Mais tempo para reagir a problemas imprevistos (bugs, falhas do sistema, fator de barramento, alterações de design ad-hoc, etc.) sem colocar em risco todo o sprint
O controle de qualidade pode se concentrar em um time / recurso / release de cada vez, em vez de ter que verificar tudo das duas equipes ao mesmo tempo
Capacidade de trabalhar em recursos maiores sem precisar dividi-los em segmentos artificiais para se ajustar aos sprints

Agora eu me pergunto se isso foi realmente uma boa idéia, ou se estou perdendo algo óbvio e isso estragaria tudo. Existem outros recursos sobre este tópico? As equipes de scrum assíncrono são viáveis ou geralmente é uma má idéia?

teamwork scrum

por arotter 01.11.2015 / 10:51

fonte

1 resposta

Tags teamwork scrum

Thread.State BLOCKED vs WAITING O que é uma estrutura de dados eficiente para destacar a sintaxe em editores de texto?

score 8 · Accepted Answer

In the past we've repeatedly had issues with larger features (bad planning/estimates)

Se você encontrar problemas de planejamento / estimativa apenas para sprints de duas semanas de antecedência, você realmente acredita que isso vai melhorar se você tiver que estimar o trabalho de sua equipe por quatro semanas ao invés de dois? Honestamente, acho que isso tornará as coisas piores, não melhores (e não fará diferença se suas equipes trabalharem em sincronia ou não).

Ability to work on larger features without having to chunk/split them into artificial segments

A necessidade de dividir grandes recursos em fatias menores é uma força para o IMHO - se você sacrificar isso, seu planejamento / estimativa ficará pior, seus ciclos de testes serão mais longos e sua capacidade de controlar o processo diminuirá. Assim, eu recomendaria strongmente contra isso. É melhor tentar dividir os recursos não tão artificiais.

Se você tem recursos maiores para trabalhar no que não pode ser concluído em um sprint, divida-os em outros menores, mas não disponibilize esses recursos parcialmente concluídos para seus usuários imediatamente no final de cada sprint. Melhor, aprenda a utilizar "filiais de recursos" e "alternar recursos" para suas necessidades.

Uma melhor estratégia de ramificação / fusão também pode ser uma abordagem para desvincular suas equipes do ciclo fixo de "duas semanas" - se a próxima feature feature se encaixar melhor em 9 dias ao invés de 14, enquanto a outra equipe precisa de 16 dias, isso deveria ser perfeitamente possível. E sua equipe de controle de qualidade ainda pode obter uma nova versão a cada 14 dias. Você precisa estabelecer uma estratégia para isso que permita proibir a entrega de recursos incompletos da ramificação de desenvolvimento para "teste" no meio de uma sprint, sem interromper suas equipes do trabalho. Existem diferentes abordagens de como fazer isso com o Git, e, claro, o seu esforço de gerenciamento de configuração provavelmente aumentará, mas isso provavelmente está fora do peso pelos benefícios que você obtém com isso.