Como coordenar o tempo dos desenvolvedores entre dois projetos diferentes no Scrum?

Tornei-me o scrum master de uma equipe recém-criada, responsável por criar um software E manter outro aplicativo implantado. Então, basicamente, cada membro da equipe tem tarefas de desenvolvimento e operações.

Eu tenho observado como eles funcionam nas últimas duas semanas e notei que a equipe está tendo problemas para coordenar essas tarefas. quando um desenvolvedor está concentrado na codificação, ele é interrompido para corrigir um problema levantado na produção, e é difícil para ele se concentrar novamente na tarefa anterior.

Tentei alocar% do tempo do desenvolvedor para o funcionamento das operações, mas aparentemente isso não está resolvendo o problema. Estou interessado em ouvir os mestres do scrum que já se depararam com essa situação antes, como você a gerenciou e quais são suas recomendações?

Esse problema é tão antigo quanto o scrum. Existe uma solução, mas você não vai gostar.

• Coloque novas tarefas na lista de pendências.
• Não interrompa os desenvolvedores.
• Aguarde o próximo sprint.

Colocar seus desenvolvedores em mais de um scrum, ter dois registros em atraso separados ou atribuir apenas uma porcentagem de seu tempo ao sprint funciona contra o que o scrum está tentando alcançar, ou seja, um fluxo consistente de tarefas concluídas.

Se você tenta esse tipo de coisa, basicamente volta para as metodologias de desenvolvimento 'caos' ou 'JFDI' com todos os problemas correspondentes, por exemplo

• O desenvolvedor tem dez tarefas em movimento a qualquer momento. Ninguém sabe no que está trabalhando ou quando será concluído.
• Hora desconhecida para finalizar o projeto, porque depende do que outros projetos estão acontecendo ao mesmo tempo.
• Nenhuma visão consistente da prioridade do projeto. Outros gerentes desviam os desenvolvedores para seus projetos de estimação.

É claro que a resposta usual a esse conselho é "Mas não posso fazer isso! A empresa precisa que esses erros de produção sejam corrigidos o mais rápido possível!"

Mas isso não é verdade.

Se você realmente tem muitos erros reais que estão afetando os negócios nessa extensão, precisa ser profissional e aprimorar seus testes. Apenas trabalhe em bugs e testes automatizados até que você os tenha corrigido. Contrate uma equipe de controle de qualidade e teste todos os novos lançamentos.

O que é mais provável é um dos seguintes:

• Os erros são problemas operacionais, falta de espaço em disco, sem DR, sem backups, sem failover, etc. Obtenha uma equipe de OPS.

• Os erros são os usuários que não entendem como o sistema deve funcionar "Isso aconteceu! É um erro?". Obtenha um suporte técnico e treine seus usuários, escreva documentação.

• Medo de reversão. Você lançou um novo recurso e ele quebrou algo, não tente apressar uma correção. Volte para a versão anterior e coloque os erros na lista de pendências.

Apenas tentando pensar fora da caixa aqui.

Como talvez não seja possível fazer com que o proprietário do produto veja as coisas do seu jeito. Ainda pode haver erros críticos que simplesmente não podem esperar, encontrando-se com clientes onde a assistência ao desenvolvedor é necessária etc. onde você precisa tirar um desenvolvedor do sprint por um tempo.

Por que não tentar antecipar isso e usá-lo para sua vantagem?

Você precisará de uma equipe de mais de 5 anos para que seja realista, talvez.

Mas por que não levar um desenvolvedor a cada sprint (alternando entre os desenvolvedores, cada um recebe a sua vez).

Como provavelmente não há erros suficientes para usar um desenvolvedor completo para correções, existem outros problemas ou tarefas que podem ser executados.

• Executando testes para identificar gargalos de desempenho ou problemas de escalabilidade
• Mantendo o sistema de construção
• Reuniões com clientes
• Pesquisando novas estruturas / bibliotecas
• Explorando os recursos de idioma que você deseja usar
• Lendo sobre questões de segurança
• Manutenção de banco de dados
• Manutenção do servidor

A velocidade da equipe pode aumentar, o estresse pode diminuir, os conflitos com a gerência podem diminuir, na verdade você tem tempo para melhorar seu conhecimento.

Uma solução eficaz para gerenciar o esforço do desenvolvedor para problemas de produção realmente essenciais que usei é a "abordagem do Batman".

O aspecto oneroso da responsabilidade do suporte de produção ao desenvolver novas funcionalidades é a alternância de contexto; portanto, você deve limitar isso.

Com a adesão da equipe, crie uma lista dos membros da equipe e percorra-a de forma que, a cada dia, uma nova pessoa seja declarada "Batman" na reunião de pé e responderá a questões essenciais de produção nesse dia. O restante da equipe pode manter o foco no desenvolvimento sem precisar alternar o contexto e todos têm uma parte justa da dor do suporte. Com uma equipe de 5 pessoas, é um dia por semana em que um desenvolvedor pode ser interrompido e 4 dias de tempo de desenvolvimento previsível e ininterrupto.

Isso tem o benefício do conhecimento / experiência sendo compartilhado entre a equipe; portanto, você não tem uma pessoa responsável por resolver problemas específicos e se tornar um ponto único de falha e uma divisão justa de problemas de suporte.