A questão de gerenciar bugs na produção tem sido uma característica importante em minha mente ultimamente. Os Sprint's não devem ter itens adicionados a eles, mas para erros críticos , isso é inevitável.
Como lidar com essa interrupção no sprint? Você simplesmente dá a um sprint uma porcentagem de "permissão" de tempo, preenchendo apenas 80% da programação com itens de sprint "apenas por precaução"?
Respostas:
Se isso for crítico , você deve lidar com isso.
Para medir seu impacto no sprint, você deve registrá-lo.
Veja este radiador de informações:
Há uma parte chamada " Itens não planejados ". Coloque seu bug crítico lá. Como você vê, há a parte inversa da seção " Avançar ", na qual você coloca mais histórias do usuário do que o planejado, caso conclua o sprint mais rapidamente.
Você falará sobre isso na revisão do sprint e / ou na retrospectiva . O objetivo é descobrir como limitá-los e também ajustar sua velocidade de acordo.
Se você usar a velocidade como um indicador de 'permissão' com base no clima de ontem, ele será ajustado automaticamente para uma quantidade média de trabalho extra cortando em sprints.
Se o problema de produção for causado por bugs criados em sprints anteriores, não há problema em corrigir o trabalho de fixação na velocidade do sprint atual. Dessa forma, a velocidade da equipe é 'compensada' pelos pontos que não deveriam ter ganhado anteriormente.
Às vezes você não faz todos os seus objetivos de sprint, supere-os ;-) O Velocity terá uma média de um número menor se isso acontecer muito.
Qualquer outro material não crítico pode ser incluído na lista de pendências para inclusão normal em um sprint. Eu prefiro dar prioridade aos bugs e não tê-los contados em termos de velocidade.
Todo o tempo necessário para corrigir e solucionar problemas de produção é automaticamente considerado na velocidade da equipe. Leva apenas tempo para calcular a média, realmente não precisa de um subsídio separado.
Trabalho em uma equipe que trabalha principalmente no desenvolvimento, mas também é responsável pelos sistemas complexos existentes. Também tivemos esse problema.
Basicamente, estimamos nossos pontos com base no último sprint (s) e, em seguida, reservamos vários pontos para o trabalho de manutenção esperado. Caso ocorra uma tarefa de manutenção que exceda significativamente isso, como uma grande interrupção, nós a adicionamos como uma história de usuário e removemos uma história existente que ainda não foi iniciada, para manter o sprint do mesmo tamanho. Se surgir um problema importante que é menos urgente, passamos para o próximo sprint.
Sim, tecnicamente isso não está seguindo o scrum. Mas a flexibilidade funcionou bem para nós.
Refinamos esse tempo reservado, perguntando à equipe em todas as reuniões de planejamento se eles veem motivos para se desviar da reserva padrão. Introduzimos isso depois de fazer uma mudança no escritório que nos levou muito mais tempo do que prevíamos, levando a muitas histórias não sendo concluídas.
No entanto, não se prenda apenas à maneira como minha equipe ou qualquer outra equipe faz isso. Escolha algo e apenas faça. Não há como garantir que funcione bem para sua equipe. Tente e avalie na retrospectiva. Se a equipe estiver insatisfeita, tente algo diferente e avalie novamente. Todas as equipes são diferentes, e suas necessidades e limitações também são diferentes.
Se for um problema crítico de produção, você poderá lidar com isso diretamente, a metodologia de desenvolvimento escolhida é irrelevante. Um hotfix não está relacionado a um ciclo de lançamento regular (spints ou outros).
Sugiro corrigi-lo em uma ramificação de 'correção', com base no código atualmente em produção.