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

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

• Coloque novas tarefas no backlog.
• Não interrompa os desenvolvedores.
• Aguarde o próximo sprint.

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

Se você tentar esse tipo de coisa, basicamente voltará às metodologias de desenvolvimento do 'caos' ou 'JFDI' com todos os problemas associados, por exemplo

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

É claro que a resposta usual a este conselho é "Mas eu 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 bugs reais que estão afetando os negócios, você precisa se profissionalizar e melhorar seus testes. Apenas trabalhe com bugs e testes automatizados até ter corrigido todos eles. Contrate uma equipe de controle de qualidade e teste todos os novos lançamentos.

O que é mais provável, porém, é um dos seguintes:

• Os bugs são problemas operacionais, com pouco espaço em disco, sem DR, sem Backups, sem failover, etc. Obtenha uma equipe de OPS.

• Os bugs são usuários que não entendem como o sistema deve funcionar "Isso aconteceu! é um bug?". Obtenha um helpdesk e treine seus usuários, escreva a documentação.

• Medo de reversão. Você lançou um novo recurso e quebrou alguma coisa, não tente apressar uma correção. Reverter para a versão anterior e colocar os bugs no backlog.

Apenas tentando pensar fora da caixa aqui.

Como pode não ser 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, encontrar clientes onde a ajuda do 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 5 ou mais para que seja realista, talvez.

Mas por que não levar um desenvolvedor a todos os sprints (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, há outros problemas ou tarefas que podem ser executados.

• Execução de testes para identificar gargalos de desempenho ou problemas de escalabilidade
• Mantendo o sistema de construção
• Reuniões com clientes
• Pesquisando novas estruturas / bibliotecas
• Explorar os recursos de idioma que você gostaria de usar
• Como ler os problemas de segurança
• Manutenção do banco de dados
• Manutenção do servidor

A velocidade da equipe pode subir, o estresse pode diminuir, os conflitos com o gerenciamento podem cair, você realmente ganha 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 Batman".

O aspecto caro da responsabilidade de suporte à produção ao desenvolver novas funcionalidades é a troca de contexto, então você deve tentar limitar isso.

Com o buy-in da equipe, crie uma lista dos membros da equipe e percorra-a, para que, a cada dia, uma nova pessoa seja declarada "Batman" na reunião de stand up e responda a questões essenciais de produção naquele dia. O restante da equipe pode ficar focado no desenvolvimento sem ter que mudar de contexto e todo mundo tem uma parcela justa da dor do suporte. Com uma equipe de 5 pessoas, isso é um dia por semana em que um desenvolvedor pode ser interrompido e 4 dias de tempo de desenvolvimento ininterrupto e previsível.

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