Quantas vezes liberar no Scrum sprint

Com que frequência você libera durante um sprint. Somente no final do sprint ou sempre que um recurso estiver pronto. E como você lida com lançamentos de correções de bugs?

TL; DR: Libere sempre que apropriado

Fazemos lançamentos sempre que houver valor em fazer um lançamento. Às vezes, isso significa fazer um lançamento após a conclusão de um único recurso ou correção de bug. Às vezes, isso significa liberar uma coleção de recursos e / ou correções.

Isso não significa que geralmente temos "emergências" que exigem lançamentos rápidos. Isso significa que trabalhamos duro para facilitar os lançamentos. Nosso código é testado, marcado e empacotado a cada compilação. Utilizamos testes de aceitação automatizados e, como resultado, desenvolvemos uma alta confiança no código que passa nos testes. Como nossos pacotes estão imediatamente disponíveis por meio de um repositório yum local, implantar um release é trivial.

Nunca durante. Isso viola a premissa básica de um "sprint". Você corre até terminar o que se comprometeu a terminar. Depois de terminar, está realmente pronto e realmente funciona. Você pode liberá-lo.

A liberação pode ser um tipo separado de sprint, onde as coisas são empacotadas para liberação.

Os lançamentos de correções de bugs podem ser apenas breves sprints. Não ter uma programação regular de sprints do mesmo comprimento é considerado por muitos uma má ideia. Portanto, a regra usual é que as correções de bugs são simplesmente trabalhos de alta prioridade que acontecem durante o próximo sprint.

Se for uma emergência, você tem muitas coisas acontecendo - suporte e desenvolvimento - e deve considerar mudar a organização para ter menos coisas acontecendo.

Se o trabalho com o qual a equipe se comprometer for propício a fazer várias liberações dentro do sprint, libere-o quantas vezes quiser.

O mesmo vale para lançamentos de correção de defeitos - se fizer sentido lançá-los, faça-o.

O último trabalho do Agile em que trabalhei tinha lançamentos a cada sprint; o código era congelado toda quinta-feira (sprints de duas semanas) e, em seguida, o produto era empacotado e publicado em um servidor UAT para que nossos clientes trabalhassem. Isso foi durante o desenvolvimento inicial do produto; para um produto maduro, especialmente um programa distribuível e não um aplicativo Web, você provavelmente não desejaria sobrecarregar seus usuários com a atualização a cada duas a três semanas.

Praticamente todos os nossos lançamentos incluíam uma mistura de histórias e defeitos (bugs). Defeitos contados como "horas não ideais"; há 5 horas ideais em uma jornada de trabalho, o que significa uma codificação inédita de novos trabalhos pontuais. As outras três a quatro horas por dia são reuniões, discussões, design, algumas vezes "picos" (pesquisa focada / desenvolvimento de prova de conceito) e trabalho com defeitos; coisas que contribuem para um produto melhor e são uma parte necessária do processo, mas simplesmente não podem assumir todo o sprint de toda a equipe. A única vez em que lançamos somente com defeito foi quando não havia trabalho de storypoint disponível no backlog a partir de um IPM; simplesmente agendamos um sprint de controle de qualidade no qual fomos instruídos a "eliminar o máximo de defeitos possível". Como não ter requisitos prontos é SEMPRE culpa do OP (e o OP funcionou para os clientes), poderíamos simplesmente emitir um aviso de alteração de contrato e trabalhar com o que tínhamos. Obviamente, quando o trabalho real da história terminava e estávamos no desenvolvimento da "garantia", havia todos os defeitos.

Em um projeto Agile bem gerenciado, a falta de requisitos nunca deve acontecer; a lista de pendências sempre deve ter um trabalho de sprint pronto para ser utilizado. Mas, às vezes, a OP é inundada produzindo requisitos; às vezes, os BAs / testadores atrasam a liberação de matérias para o backlog do desenvolvimento, por motivos relacionados à qualidade dos requisitos ou conflitos de matérias; às vezes, uma equipe decide que deve "contar" uma história que não foi bem definida ou bem estimada, e não há algo que possa facilmente levar os ciclos restantes. Em resumo, mesmo no Agile, a merda acontece.

O que você quer dizer com liberação? Se você quer dizer PSP - produto provavelmente entregável, você tem duas opções:

• Scrum por livro (ou Scrum nível 2), você tem PSP no final do sprint e é isso que você mostra em uma reunião retrospectiva
• Também conheci o termo Scrum nível 3, onde a equipe dominou suas ferramentas como controle de origem e integração contínua e passou para a entrega contínua. Essa equipe é capaz de ter o PSP após cada compilação noturna (ou cada compilação no melhor caso). Ter o PSP após cada build não significa que você o mostra ao cliente após cada build - ainda é apenas uma versão interna.

A principal diferença entre o nível 2 e o nível 3 é que no nível 2 você deve fazer algum esforço para fazer o PSP final no final do sprint, mas no nível 3 você dedica algum dinheiro e esforço inicialmente às suas ferramentas e configurações e prepara o PSP automaticamente o tempo todo = não há esforço manual envolvido. Atingir totalmente o nível 3 é raro.

Não há absolutamente nenhuma regra no Scrum sobre quando novos recursos podem ser implantados. Toda equipe precisa ter uma "definição de concluído", que sempre deve incluir alguns critérios sobre o teste. Depois que um recurso é "pronto", ele está pronto para o mundo real e, se não houver outras dependências ou condições que precisam ser atendidas antes de poder ser implantado, não há razão para esperar o final do Sprint. implantá-lo.

Nada disso significa que não foi apresentado na reunião de Revisão / Planejamento da Sprint. O conceito é que tudo o que a equipe concluiu é mostrado ao OP (e a outras PME do cliente), para que eles possam incorporá-lo à sua crescente compreensão do sistema à medida que ele evolui.

Depois de algumas semanas, encontramos uma boa solução que atende às nossas necessidades. Decidimos liberar quando quisermos. Como fazemos isso:

1. sempre que alguém decide liberar o ramo de desenvolvimento real, ele mescla todas as alterações no ramo mestre que o identificam com um novo número de lançamento e são enviadas para o nosso sistema de preparação.
2. do que nosso controle de qualidade e todas as outras equipes recebem um email com um registro de alterações real e testam o sistema de preparação
3. se eles encontravam bugs, nós os corrigíamos no mestre, empurravamos para o estadiamento e, em seguida, mesclamos o mestre de volta ao ramo
4. quando o sistema de preparação passou no controle de qualidade, o mestre entra em operação

É isso aí. Usamos git e maven como sistema de CI e temos uma boa cobertura de teste. Qual é uma das razões pelas quais podemos fazer isso assim.

Responder a uma pergunta com quase 2 anos de idade pode ser um pouco redundante, mas espero que agregue valor a outras pessoas que vêm a essa pergunta, gostaria de acrescentar mais ou menos 2 centavos. :)

Para responder à pergunta: você deve preferencialmente liberar o que foi comprometido no sprint, no final desse sprint. Fazer isso se vincula a todas as outras partes / processos / diretrizes do scrum, que são voltadas para obter o melhor valor comercial no momento certo.

MAS emergências, bugs, eventos inesperados etc. podem forçar sua mão, e é aí que o conceito se "Release Planning" pode ser útil. Com o "Planejamento de Liberação", não quero dizer o planejamento do tipo cascata, mas o planejamento de expectativas que podem ajudar a gerenciar o backlog do produto e a prioridade das histórias nos sprints etc.

Mas talvez o comentário de David sobre a questão seja algo a ser melhor considerado. Scrum nem sempre é a resposta certa.