No Scrum, como lidar com contenção / carga de trabalho no final do sprint

Minha equipe começou a usar o Scrum alguns sprints atrás. Nosso projeto envolve a criação de software de interface com dispositivos físicos (pense em robôs e sensores) e nosso backlog típico de produtos geralmente representa a adição de dispositivos de controle a todo o sistema.

Dividimos a tarefa perto do exemplo aqui . Cada recurso de integração de dispositivos é dividido em código, testes, testes de integração, revisão por pares, etc. Obviamente, há uma sequência inerente a cada item do Backlog do produto. Normalmente, nossos sprints duram 2 semanas e a equipe tem entre 4 a 6 membros.

Encontramos dois problemas no final dos sprints:

• O primeiro é manter todos ocupados no final do sprint.
• O segundo (relacionado) é a contenção no sistema. Acabamos praticamente nos integrando nos últimos dias do sprint. Como temos apenas um sistema de integração, muitas vezes as pessoas são impedidas de continuar trabalhando em suas tarefas porque não podem acessar o sistema. Como é o fim do sprint, não há muito trabalho a fazer no backlog do sprint. No que essas pessoas devem trabalhar? A retirada de itens da parte superior da lista de pendências do produto não é bem recebida do proprietário do produto, pois os itens atuais não foram concluídos. Trabalhar com dívida técnica ajudará o projeto como um todo, mas não ajudará na conclusão do sprint.

Existem práticas recomendadas para estruturar sprints para evitar esses problemas? Dicas para negociar com os proprietários do produto?

de certa forma, é bom que você esteja lento no final de um sprint, o que significa que você estimar bem e não comprometer demais, tanto quanto se manter ocupado, nas equipes de scrum em que trabalhei, sempre adicionamos tarefas de pesquisa para o que está por vir arrancada.

Isso pode ser uma prova de conceitos para as coisas que estão por vir, ou procurar onde fatorar novamente o código existente, trabalhando para obter uma melhor cobertura de teste no seu código, etc.

Você deve consertar seu sistema de integração para que sua equipe possa integrar o trabalho deles assim que cada tarefa for concluída, em vez de esperar um grande estrondo no final do sprint.

Eu recomendo trabalhar com histórias de usuários curtas o suficiente para serem concluídas em alguns dias. Terminado aqui significa código completo, testado e integrado.

Lembrando que é responsabilidade de toda a equipe entregar, e não membros individuais, por si só , é possível que todos os quatro a seis membros trabalhem em cada tarefa JUNTOS - forme cada um deles no processo e passe para o próximo. Isso pode parecer ineficiente no começo, mas se os gargalos que você está vendo são tão ruins, pode ser uma opção válida.

Além disso, convém analisar a teoria das restrições ( The Goal , de Goldratt ), e ver como você pode analisar melhor por que e onde possui esses gargalos de integração.

Resolvemos isso adotando a abordagem Kanban.

Temos filas em nosso software de rastreamento (Jira) com mínimos e máximos.

Preparamos 'conforme necessário'. Pode ser uma vez por semana, pode ser 3 vezes, depende dos limites e do trabalho que é feito.

Isso ajudará você a manter o proprietário do produto focado em manter sua fila com muito o que fazer e pode reduzir o microgerenciamento de tickets individuais. Lembre-se de que, como sempre, a mudança levará tempo.

Ainda demo a cada duas semanas e lançamos semanalmente.

Uau, se você não dissesse robôs, eu diria que você está no meu time agora. Nós temos exatamentemesmo conjunto de problemas. Tendo trabalhado em vários projetos ágeis com graus variados de fidelidade ao manifesto e graus variados de sucesso, minha análise é que nosso problema é que os sprints são muito curtos. Estamos fazendo sprints de duas semanas, o que causa alguns problemas. Uma é que acabamos sendo cautelosos no planejamento e frequentemente acabamos com dias mortos no final. O segundo é a enorme audição de revisão, retrospectiva e planejamento, que leva de um a dois dias a cada duas semanas. Outra é, como você disse, ter que se integrar no último minuto e frequentemente falhar horas antes da revisão. Meu primeiro e mais bem-sucedido projeto ágil teve sprints de quatro semanas, o que considero bastante grande para os padrões da indústria, mas funcionou muito bem para nós.

Edição: Lembrou mais uma coisa do primeiro projeto que foi uma benção. Sempre tínhamos uma lista de pendências de produtos totalmente priorizada e demos aos desenvolvedores a liberdade de extrair tarefas dela se suas tarefas de sprint estivessem completas e nenhuma outra tarefa de sprint estivesse disponível.

O segundo problema é provavelmente uma consequência da tentativa de corrigir o não-problema nº 1. Você deve levar pessoas que não estão ocupadas para ajudar seus pares; em vez de trabalhar em tarefas que não são de sprint, o que causa contenção na integração limitada.

Além disso, você não deve integrar no final do sprint, mas continuamente.

Você está apenas começando. Dê às equipes a chance de resolver esse problema por meio de seu processo retrospectivo.

Em segundo lugar, o proprietário do produto deve confiar na equipe para saber melhor como se organizar e otimizar. Em troca, a equipe confia no OP para saber melhor o que o cliente precisa.

Esses são desafios muito comuns com as novas equipes ágeis. É ótimo ver quando uma equipe começa a quebrar seu próprio silo e crescer.