Como você inclui o suporte no seu Sprint?

Nossa empresa mudou-se para o Scrum recentemente em um produto quase codificado por uma única pessoa (Joe). Temos suporte para os clientes existentes que tentamos integrar em nosso processo.

Por enquanto, tentamos a seguinte abordagem:

• Fazemos uma rotação em uma pessoa responsável a cada semana.
• O responsável pela semana pode gastar até 8 horas em suporte.

Mas não conseguimos fazer funcionar:

• Joe sempre dá suporte porque conhece melhor o código e é sempre mais rápido fazê-lo do que explicá-lo.
• Nós (o resto de nós) costumamos nos concentrar no que está no quadro da Sprint, também conhecido como novas histórias, em vez de tarefas de suporte.
• Joe tem muito trabalho, ele não pode lidar com todo o apoio sozinho, porque ele também tem que fazer coisas fora do Sprint.

Você já enfrentou situação semelhante? Como você conseguiu sair disso?

Nota: Não podemos dedicar uma única pessoa ao suporte no momento. Esperamos que no futuro.

Adotamos uma abordagem muito semelhante ao designar um "Programador de suporte" que alternava entre os desenvolvedores mais jovens (ou mais novos) da equipe. Eles foram incentivados a tentar realmente descobrir o problema antes de perguntar aos outros desenvolvedores, mesmo que fosse mais rápido enviá-lo ao desenvolvedor que conhecia melhor o código. Dessa forma, eles foram forçados a aprender a base de código e você evitou tirar as pessoas da "zona" e destruir a produtividade. Além disso, você deve criar algum mecanismo para impedir que as pessoas façam uma abordagem final aos programadores que não são de suporte para fazer isso funcionar.

Um ponto importante é que a equipe precisa entender que a maneira mais rápida de fechar problemas de suporte nem sempre é o uso mais eficiente do tempo da equipe. Verifique se toda a equipe sabe que o objetivo dessa estrutura é minimizar as interrupções para as pessoas que estão nesse modo produtivo a todo custo.

Dito isto, o programador de suporte não era 100% dedicado ao suporte a chamadas. Eles trabalharam em casos no sprint, mas deveriam trabalhar nos itens de prioridade mais baixa, para que, se eles se pendurassem em muitos problemas de suporte, o fato de não terminarem seus casos não fosse uma grande preocupação. .

Como você inclui ir ao banheiro no seu Sprint? Como você inclui o tempo que os desenvolvedores passam em casa brincando com seus filhos? Que tal incluir tempo para dormir?

Estou sendo sarcástico, é claro, a resposta é que IMHO você não deve incluir o tempo de suporte no seu planejamento de sprint. O único momento que deve ser incluído no seu planejamento de sprint são as tarefas diretamente associadas aos produtos a serem entregues.

Se um recurso dedicar tanto tempo ao suporte, você terá menos horas de recursos disponíveis desse desenvolvedor, do sprint. O conjunto de recursos incluídos nesse sprint deve refletir esse fato.

Acho que a coisa mais simples a fazer é adicionar suas atividades de suporte diretamente à lista de itens incluídos no seu sprint. Se essas atividades de suporte forem correções de bugs, elas serão priorizadas no seu backlog da mesma maneira que você faz para aprimoramentos. Se eles são baseados no tempo (como a geração de relatórios no final do mês), eles também são agendados com facilidade. É isso que fazemos e funciona bem.

Na minha opinião, existem dois tipos diferentes de trabalho de "suporte". O primeiro tipo é uma emergência que precisa ser corrigida AGORA. É realmente mais trabalho do tipo operações, material de combate a incêndio que não pode realmente ser planejado e estimado como parte de um sprint. O segundo tipo é um relatório de bug, que é estimado, priorizado e planejado em um sprint. É tratado como qualquer outra história. Freqüentemente, o primeiro tipo resultará no segundo tipo; você apagará o fogo e criará um relatório de bug para fazer uma correção real, para que isso não aconteça novamente. No restante deste post, estou falando sobre o primeiro: trabalho de emergência não planejado que precisa ser feito AGORA.

Tirar um tempo da equipe para fazer o trabalho de suporte reduz a velocidade da equipe. Você deve usar sua velocidade histórica para determinar sua capacidade para o próximo sprint. A alternância de contexto necessária para passar do trabalho de liberação para dar suporte ao trabalho significa que há alguma sobrecarga, mas como o trabalho que você faz para um sprint deve levar em conta quanto trabalho você realiza historicamente em um sprint, a quantidade típica de tempo você coloca em suporte, e a sobrecarga de alternância de contexto deve ser contabilizada automaticamente.

Não considero que seja um trabalho de corrida. É separado e deve ser priorizado acima do trabalho de sprint. Assim, ele consome a velocidade da equipe e é "planejado" usando essa velocidade reduzida ao decidir quanto trabalho pode ser feito durante o próximo sprint.