Como o SCRUM gerencia um ambiente em que os membros da equipe são compartilhados?

Bem, as perguntas se diziam. No meu local de trabalho, esses casos acontecem, mas também muitos livros do Agile promovem o trabalho no mesmo local de trabalho e concentram-se no projeto atual para se tornarem mais rápidos no ritmo do trabalho.

Talvez eu não esteja tão informado sobre o assunto, talvez não seja tão rigoroso, mas é por isso que eu queria saber o que o Agile propõe em casos como esses.

Qualquer pessoa?

Na metodologia Scrum, isso afeta apenas a estimativa.

Você atribuiria o fator de foco para essa pessoa com base na alocação de seu tempo para cada projeto.

Portanto, se eu estiver trabalhando no Projeto A e no Projeto B igualmente, o Projeto A calculará recursos da seguinte forma:

Projeto A - Fator de foco da equipe de 70%
Sam - 10 dias, alocação de 100% (7 após o fator de foco)
Joe - 10 dias, alocação de 100% (7 após o fator de foco)
Me - 10 dias, alocação de 50% (3,5 após o fator de foco )
Total: 25 dias * fator de foco de 70% = velocidade projetada em 17,5

Você também pode calcular o fator de foco separadamente para os membros da equipe em período integral e para os que trabalham em meio período, em vez de uma vez para toda a equipe, devido à eficiência reduzida da divisão de projetos. Nesse caso, você usaria o fator de foco do meu projeto de 50% e o multiplicaria por uma alocação pessoal de 50% por 25% ou velocidade projetada de 2,5 dias .

O quão bem isso funciona na prática será um fator de quão bem você sabe com antecedência quanto tempo um recurso compartilhado vai gastar em cada projeto e quão bem o Scrum está trabalhando para você de outras maneiras.

Na minha experiência em Scrum, a velocidade só pode ser prevista se o projeto e a equipe permanecerem iguais e dedicados. Se alguma dessas coisas mudar, não será possível usar cálculos de velocidade de sprints anteriores para fazer sua estimativa. Você pode tentar, mas terá muito mais do que normalmente faria.

Em geral, você definitivamente deve tentar manter a equipe igual e dedicada pelo menos durante um sprint, mais se puder.

Na minha opinião, isso afetará muito todos os projetos. Não se trata apenas de estimar ou planejar. Sim, você pode dizer que, se os membros da equipe estiverem alocados em três projetos e eles tiverem 33% de alocação em cada projeto, você saberá tudo o que precisa e estará pronto, mas isso não é verdade.

A troca de contexto é muito cara. Também é impossível manter o comprometimento total com vários projetos paralelos, de modo que 33% do tempo do desenvolvedor fica longe de 33% quando o desenvolvedor é atribuído a apenas um único projeto.

Outro lugar onde isso falha totalmente é a comunicação. O que acontece se um membro da equipe que trabalha atualmente no projeto A deve comunicar algo com um membro da equipe que trabalhou no projeto A ontem, mas atualmente trabalha no projeto B? Isso é um impedimento para os dois, porque o primeiro precisa de informações, mas o segundo está concentrado em um projeto completamente diferente e qualquer pergunta para o projeto A o perturba. O Scrum Master do projeto A deseja que seu desenvolvedor obtenha informações o mais rápido possível e o Scrum Master do projeto B não deseja que o membro da equipe seja perturbado por algo não relacionado ao projeto B. Se você quiser evitar isso, planeje tudo desenvolvedores da equipe para trabalhar no mesmo projeto nos mesmos dias - isso é uma grande complicação para todo o processo de planejamento e algo que deve ser completamente evitado.

Você também deve planejar todas as reuniões para não colidir. Você também deve entender que a reunião é realmente um desperdício e, por isso, deve haver um número mínimo mínimo necessário de reuniões para manter o controle sobre o processo. Mas se você tem um membro da equipe trabalhando em três projetos, ele deve participar de todas as reuniões para esses três projetos => três vezes mais reuniões em que o desenvolvedor não produz nenhum valor comercial.

Como conclusão, o agile também é sobre reduzir o desperdício (sim, é da abordagem Lean) e compartilhar os membros da equipe entre as equipes é uma das piores falhas em termos de introdução de desperdício e redução da produtividade. Acho que o valor comercial entregue para alocação de 33% em um único projeto será igual ao valor comercial entregue de 10 a 16% da alocação em tempo integral. Isso significa que o desenvolvedor não participará apenas 1/3 do tempo no projeto, mas durante esse período sua produtividade estará entre 1/3 e 1/2.

O SCRUM é baseado em ter uma equipe comprometida sem membros compartilhados; portanto, você também deve estar se perguntando:

Dado que nos disseram que devemos tornar verdadeiro == falso, como fazemos x

Se não for SCRUM, não chame SCRUM!

A questão principal é sobre o compromisso do membro da equipe com o projeto. Idealmente, um membro da equipe deve estar totalmente comprometido com o sucesso do projeto. Isso não significa que seu tempo é totalmente dedicado ao projeto, mas que ele está disponível para executar as tarefas necessárias para o projeto quando estiver trabalhando no projeto.

Freqüentemente, com o pessoal que trabalha apenas meio período em um projeto, eles estão envolvidos apenas por um escopo limitado de comprometimento. Por exemplo, você pode ter uma pessoa que apenas otimiza o banco de dados.

Nesse caso, geralmente é melhor tratar essa pessoa como um "recurso" em vez de como um membro da equipe. A equipe decide quanto desse recurso deseja em um determinado Sprint e fornece a eles um conjunto muito específico de tarefas a serem concluídas para o Sprint. Às vezes, é melhor que a equipe tenha um membro da equipe específico responsável por esse recurso, e eles farão as atualizações de status e os relatórios de impedimentos para esse recurso no Scrum diário.

Acredito que um dos aspectos centrais do Scrum é manter a equipe focada em uma coisa de cada vez (um projeto, uma história, uma tarefa ...)

Você perguntou "o que o Agile propõe" na situação em que não é possível alocar os recursos para um projeto ... Você pode tentar uma das seguintes opções:

• Mantenha um grande quadro Kanban que abrange os vários projetos. Como um projeto tem uma necessidade, ele é adicionado ao conselho, à medida que as pessoas têm capacidade, elas puxam as principais histórias. O problema é que todos os projetos são gerenciados juntos, o que diminui a previsibilidade geral de qualquer projeto. Dito isto, os elementos individuais da história / Kanban serão atraídos e desenvolvidos por uma pessoa ou equipe focada. (Você pode tentar criar equipes menores de 4 a 5 pessoas para retirar do quadro Kanban
• Atribua apenas recursos comprometidos. Mantenha um pool de recursos dedicados para um projeto. Eles são protegidos como uma equipe e as interrupções são mantidas próximas a zero. Além disso, mantenha uma "equipe de resposta rápida" que não tenha uma lista de pendências e que não tenha foco no projeto / produto. À medida que surgem interrupções, a equipe de resposta rápida lida com as interrupções. Quando eles não têm interrupções, eles podem se concentrar em melhorar o sistema de compilação, adicionar à estrutura de teste de automação, etc. Além disso, eles podem ajudar com revisões de código / revisões de projeto e solução de problemas que possam surgir. Gerencie o desenvolvimento como se essa equipe não existisse. Tudo o que eles podem fazer é receber a entrega. Gire as pessoas através dessa equipe para "mantê-la atual" (as pessoas parecem gostar / odeiam estar na equipe de resposta rápida ...)

espero que isto ajude!