O que acontece entre os sprints?

Estou trabalhando em um projeto seguindo fracamente o modelo scrum. Estamos fazendo duas semanas de corrida. Algo que não estou claro (e não tenho um livro para consultar) é exatamente o que deveria acontecer entre os sprints: deve haver algum processo de "empacotamento", no qual o produto é construído e entregue, mas:

• quanto tempo isso normalmente leva?
• toda a equipe deve estar envolvida?
• ele precisa terminar estritamente antes que os desenvolvedores comecem a trabalhar nos próximos itens do sprint?
• é quando ocorrem a revisão e o teste de código?

Existem três desenvolvedores, totalizando cerca de 1 ETI. Portanto, os sprints são realmente muito curtos.

Estou trabalhando em um projeto seguindo fracamente o modelo scrum.

Para deixar claro: seus gerentes provavelmente lhe falaram sobre o Scrum, mas o que você executa não é o Scrum.

Quanto tempo isso normalmente leva?

Reunião de revisão do Sprint + A reunião retrospectiva do Sprint termina o sprint atual. Em sprints curtos, eles devem levar algo entre 30 minutos - 1 hora juntos. O próximo dia útil inicia um novo sprint executando as reuniões 1 e 2. do planejamento da Sprint. Com base no tamanho da equipe e na duração do sprint, essa reunião pode levar de 2 a 4 horas.

Toda a equipe deve estar envolvida?

Toda a equipe deve estar envolvida nas reuniões mencionadas na resposta anterior.

É necessário terminar estritamente antes que os desenvolvedores comecem a trabalhar nos próximos itens do sprint?

Sim, até que a reunião de revisão seja concluída, você não sabe se o cliente aceita o resultado do sprint anterior e não sabe quais histórias de usuários serão confirmadas no planejamento de reuniões.

É quando a revisão e o teste de código ocorrem?

Não. A revisão e o teste de código fazem parte do sprint. Os desenvolvedores devem fazer tudo o que for necessário para fornecer código de trabalho que satisfaça os requisitos. Isso pode incluir revisões de código e sempre deve incluir algum tipo de teste automatizado para validar que o código funciona e faz o que é suposto fazer; caso contrário, a história do usuário não pode ser considerada como concluída.

A principal mudança mental é com o controle de qualidade. Muitos desenvolvedores pensam que o controle de qualidade existe para validar que o código funciona e faz o que deve fazer. Definitivamente não. Esse é o trabalho do desenvolvedor.

O controle de qualidade deve participar do desenvolvimento do produto. Sua principal responsabilidade no sprint deve ser a comunicação com o proprietário do produto e a criação de testes de aceitação automatizados para critérios de aceitação (definição de concluído) que validarão que a história do usuário está realmente concluída e o aplicativo passa todos os novos requisitos. Em equipes pequenas, isso também pode ser responsabilidade dos desenvolvedores.

O controle de qualidade também deve fazer alguns testes manuais para manter o produto consistente e descobrir os recursos ausentes, validar a experiência do usuário com a interface do usuário etc. O controle de qualidade não existe para procurar bugs e testes de regressão - o teste de regressão deve ser altamente automatizado.

Na minha experiência, é aqui que a maioria das empresas que se deslocam para o ágil falha.

Pela minha experiência, não há tempo entre os sprints, além do fim de semana. No meio do sprint, as equipes das quais eu sou membro do trabalho com o proprietário do produto realizam algumas tarefas de preparação de histórias ou dimensionamentos preliminares com base nos requisitos. É responsabilidade do proprietário do produto manter a lista de pendências cheia - é nessas histórias que a equipe estará trabalhando, com algumas informações do proprietário do produto em relação às prioridades. Depois que o sprint atual for concluído, o próximo sprint será iniciado, utilizando o trabalho que colocamos para preparar histórias e tarefas para o próximo sprint.

Existe alguma sobrecarga (muitas reuniões, perguntas e respostas e avaliações de requisitos), mas no geral funciona - fazemos progressos constantes com pouco tempo de inatividade. Os sprints geralmente duram duas ou três semanas. O controle de qualidade geralmente ocorre quando as histórias são concluídas. No entanto, a equipe de controle de qualidade pode ter outras tarefas que eles podem executar. Em relação à preparação da história, as tarefas podem recair sobre os membros seniores da equipe ou toda a equipe. Pode variar de acordo com o tamanho da equipe e o processo acordado. As revisões de código geralmente ocorrem enquanto o controle de qualidade ocorre ou no final do sprint, se o tempo estiver compactado. E se não houver tempo suficiente para terminar as histórias, na prática essas histórias serão levadas para o próximo sprint. O dimensionamento e a estimativa adequados são muito importantes aqui.

... e quando é a estimativa? planejamento?

As histórias devem ser muito fáceis de não ter tempo entre os sprints.

E não sei que tipo de teste você está falando, mas os desenvolvedores farão testes de unidade e integrações, nada mais.

Eu estava trabalhando em um projeto com, às vezes, 2 ou 3 dias entre os sprints e parece certo. Agora, estou trabalhando em um projeto em que não há tempo e tudo fica confuso. A última vez do sprint, temos implantação de produção e isso leva algum tempo do meu último dia de sprint.