Gerenciamento ágil de estabilização e liberação

Você não deve ter sprints de estabilização. Seu software deve ser liberado a cada sprint. Isto significa que se você precisar de estabilização, isso tem que acontecer dentro de cada sprint e não apenas antes de um lançamento. Depois de conseguir isso, o planejamento de liberação se torna uma preocupação do proprietário do produto ("Quais recursos eu preciso para liberar?") E estabilização de uma preocupação da equipe (definição de feito).

O mesmo se aplica a bugs e débitos técnicos: coisas que são sempre fixas, conforme necessário e não requerem histórias - na verdade, normalmente fazem parte de cada história: não pode ser "concluído", a menos que seja estável e devidamente refatorado.

Eu percebo que isso não responde à sua pergunta diretamente, mas estabilização não é um conceito ágil , então não faz sentido perguntar como fazer isso com o Scrum.

Editado para comentar o comentário:

De acordo com o Scrum, os erros encontrados no pré-lançamento devem ser tratados dentro da iteração. Uma história não é normalmente considerada "concluída" se tiver erros. Se você não pode enviá-lo, não tem valor. Além disso, de acordo com os princípios básicos do Agile, as equipes devem trabalhar em um ritmo sustentável. Se você precisa basicamente interromper o desenvolvimento para lidar com dívidas ou bugs, então você não está trabalhando em um ritmo sustentável. Diminua a velocidade, envie menos recursos, mas sem erros.

Geralmente, a estabilização acontece em equipes que têm uma equipe de verificação de qualidade separada, verificando os recursos post hoc . Isso não se encaixa no modelo Agile ou Scrum. As equipes devem ser multifuncionais e capazes de enviar um recurso de maneira independente.

Não importa se você dá o nome de 'estabilização' ou apenas 'Sprint 12', em algum momento sua equipe terá interrompido o desenvolvimento inicial de matérias e estará fazendo sprints de dívida técnica ou fechando histórias que não foram divulgadas. Não foi feito porque os problemas foram encontrados e você não pode fechá-los. Estes são apenas sprints ágeis normais, meu palpite é que sua equipe é como a nossa e sabe que precisaremos desse tempo de calendário para lidar com o "Eu não pensei nisso".

Em nossa loja, se inicialmente prevíamos um backlog de lançamento de 400 pontos, e inicialmente pensamos que podemos fazer 100 pontos de velocidade com base na história, isso deveria teoricamente significar que podemos fazer isso em 4 sprints. No entanto, também temos experiência suficiente em projetos para saber que nossas estimativas de velocidade e o total de backlog nem sempre estão corretos. Nova funcionalidade pode ser necessária para o MVP, um atraso imprevisto pode nos impedir de concluir alguma coisa, por isso planejamos um 'sprint' similar para lidar com isso. Então, podemos colocar 5 ou 6 sprints em nosso plano de calendário para explicar o nível de desconhecido.

Agora, a quantidade de tempo que você está prevendo para 'estabilização' indica um problema organizacional com a entrega se você precisar de quase tanto tempo para estabilizar quanto para criar inicialmente. Como outros já mencionaram, é provável que você precise incorporar seus testes mais cedo na fase, para que você receba seu feedback mais cedo. Usando técnicas de Teste Contínuo, você terá sua equipe limpando as histórias. Dessa forma, quando seu time estiver realmente 'pronto', o lançamento está pronto.

ASSUMINDO QUE VOCÊ FAÇA ESTE AJUSTAMENTO: Agora chegamos à parte de gerenciamento de versões da nossa pergunta: como você lida com a tentativa de finalizar o lançamento enquanto também inicia um novo lançamento em paralelo? Normalmente, o último sprint ou dois pode não ter trabalho suficiente para liberar toda a equipe. É quando você pode começar a trazer suas próximas histórias de lançamento para manter a equipe em capacidade. Do ponto de vista do gerenciamento de código, usar sua estratégia de ramificação favorita ajudará a manter as bases de código isoladas e sua equipe poderá alternar entre as ramificações com base na tarefa em que estão trabalhando. De uma perspectiva de gerenciamento de tarefas, você precisa ser capaz de delinear claramente para a equipe que libera um recurso, para que eles saibam onde colocá-lo.

Se você dividir a equipe? Pessoalmente, achei útil manter os membros da equipe concentrados, mas isso realmente só funciona se sua equipe puder realmente trabalhar em quase tudo. Se você tiver especialistas em tudo, eles terão habilidades que todo mundo precisa e eles precisarão da flexibilidade para pular entre os lançamentos. Se você pode definir um grupo principal para lidar com os dois lançamentos e, em seguida, outros membros da equipe que podem flutuar isso podem permitir um ataque mais equilibrado.

E SE VOCÊ NÃO É UM TESTE CONTÍNUO? Se você está construindo um monte de código, jogando-o para outra equipe e, em seguida, passando para a nova versão e aguardando o feedback, você precisa gerenciar sua equipe de forma diferente. Essa é uma forma de entrega mais "cascata" e significa que a equipe de lançamento inicial não pode prever quando o feedback chegará ou quanto haverá. Isso torna o planejamento de sprint mais difícil para a próxima versão, já que você não pode ter certeza de quanto trabalho da versão inicial estará lá. Nesse cenário, você pode precisar planejar seus novos sprints de lançamento para ter um 'buffer' na capacidade de levar em conta o feedback da equipe de teste. Você provavelmente usará toda a sua equipe para o novo lançamento no começo, e assim que tiver algum débito técnico para resolver, você pode começar a formar um grupo para lidar com isso e eliminá-lo.

Peço desculpas porque isso pode parecer um pouco militante e duro, mas se você quiser jogar o jogo ágil de nível superior, é melhor estar preparado para trazer as armas grandes, trabalhar como um louco e nunca comprometer.

Eu consideraria reduzir seus sprints e fazer qualidade e testar uma prioridade máxima. Eu trabalhei com equipes ágeis lançando semanalmente e bi-semanalmente e encontrar algo mais do que isso pode ser problemático. Um bom conjunto sólido de testes (100% de cobertura junto com testes automatizados de navegador) e revisões obrigatórias de todo o código farão muito para reduzir bugs. A vantagem do ciclo de lançamento semanal é que os erros são corrigidos quase que imediatamente e os sprints de estabilidade se tornam um problema. Esse tipo de desenvolvimento requer uma enorme quantidade de disciplina e deve ser conduzido militantemente pelo proprietário. Se a sua empresa não estiver disposta a assumir esse nível de comprometimento, você será apenas mais um medíocre aspirante ágil, por isso não perca seu tempo.

Para comentar suas perguntas:

1. Você só precisa de uma equipe. As pessoas consertam seus próprios bugs, já que têm mais conhecimento deles e, com um cronograma de lançamento semanal, as coisas devem ser novas.

2. O dimensionamento e os debates são inúteis. Os desenvolvedores têm tarefas e são responsáveis por estimativas e agendamento. A administração pode anular isso, obviamente, mas os bugs sempre devem ser resolvidos primeiro, a menos que haja motivos comerciais críticos que não devem ser resolvidos. Trate a dívida técnica como bugs. Não deve haver nenhum a menos que outra vez uma razão comercial crítica o crie. Idealmente, a dívida técnica não deve passar pela revisão do código. Em caso afirmativo, como um bug, conserte-o na próxima versão.

3. Bug e novos recursos são os mesmos. Não há razão para diferenciar, pois é a sua prioridade que importa.

Finalmente, automatize, automatize, automatize e encontre uma maneira de automatizar mais. Não há como realizar esse nível de esforço sem automação.

O ajuste de estabilização é muito ágil. Simplesmente não é um recurso.

Isso é dívida técnica. Onde isso se encaixa na agilidade é a quantidade de recursos que você aceita a responsabilidade de entregar. O Agile diz que você não promete ao dono do produto que esse sprint "estabilizará" qualquer coisa. Isso não significa nada para eles. Você diz: "Nós antecipamos que nossa velocidade vai cair porque percebemos a necessidade de limpar. Vamos nos comprometer apenas com essas 3 coisas". Certifique-se de que essas 3 coisas sejam pequenas o suficiente para que você tenha tempo de limpar.

Claro, você deve estar estável e limpar todos os sprints. Mas às vezes o código precisa de uma grande refatoração. Ágil não diz que você não pode fazer isso. Diz que você não recebe crédito por isso.

Só porque você é pago para derrubar árvores não significa que você não deve afiar seu machado. Só não espere ser pago para afiar o seu machado. Seu machado é sua responsabilidade.