Como o Scrum funciona quando você tem vários projetos? [fechadas]

Tenho uma boa leitura sobre os benefícios e processos do Scrum. Eu obtenho as ideias no backlog, gráficos de burndown, iterações, usando histórias de usuário e outros vários conceitos do "framework" Scrum.

Com isso dito ... Trabalho para uma empresa de desenvolvimento web que gerencia vários projetos ao mesmo tempo, com seis membros da equipe que compõem a "equipe de produção".

Como Scrum funciona com múltiplos projetos? Você ainda apenas agenda uma iteração para um único projeto em um determinado período de tempo e toda a equipe trabalha nisso e, em seguida, passa para o próximo projeto com uma nova iteração quando essa iteração for concluída? Ou existe uma maneira "ágil" de gerenciar vários projetos com suas próprias iterações com apenas uma equipe ao mesmo tempo?

O Scrum realmente não exige que você trabalhe em um produto independente. Ele simplesmente afirma que há um monte de coisas que precisam ser feitas (o product backlog), há uma certa quantidade de tempo de desenvolvimento disponível na próxima iteração (calculado a partir da velocidade do projeto) e há itens selecionados pelo cliente / business como tendo a maior prioridade neste conjunto de questões / tarefas que serão realizadas na próxima iteração (o backlog do sprint).

Não há razão para que o backlog do produto e o sprint backlog tenham que ser de um único projeto - mesmo em um único projeto, haverá unidades discretas de trabalho que são como projetos separados - a IU, a camada de negócios, o esquema de banco de dados, etc. O desenvolvimento de software corporativo em particular é assim, onde você tem uma série de bases de código que devem estar em andamento. O processo Scrum - reuniões, perguntas, gráfico queimado, etc. - todos funcionam, seja um projeto ou vários.

Dito isso, na prática, muitas vezes é bom para cada iteração ter um tema principal - "fazer o módulo de relatório" ou "interface com a API do sistema XYZ" - de modo que muitos dos problemas venham de um projeto ou área e no No final da iteração, você pode apontar para um grande corpo de trabalho e colocar uma marca nele.

Acho que a resposta depende de " quem vai priorizar os itens do backlog " (ou seja, decidir o que precisa ser feito primeiro). Se for uma única pessoa, então essa pessoa é o Product Owner de seus projetos, e você pode ter um único backlog com todos os itens de todos os projetos - ou um backlog por projeto - e você seleciona os itens do backlog de todos os projetos quando planeja um Sprint. Nesse caso, Scrum "funciona" bem.

Se cada projeto tiver seu responsável, é provável que você encontre alguns problemas em que cada responsável irá - mais ou menos conscientemente - tentar favorecer seu (s) projeto (s). IMHO, você precisará ter apenas um Product Owner com autoridade para definir as prioridades por arbitragem.

Uma regra que deve ser seguida em tal contexto é nunca alterar o conteúdo da Sprint durante a Sprint . Se necessário, você pode encurtar a iteração para duas ou três semanas para diminuir o risco de ter que adicionar um item urgente no Sprint atual.

Eu tenho que discordar. Acho que é fundamental para o processo ter uma equipe focada em um único projeto durante um sprint. Se você tiver alguns especialistas que não podem contribuir com todo o processo de desenvolvimento (autores de conteúdo, gráficos, analistas de processos de negócios etc.), eu os tiraria da equipe quando não puderem mais contribuir. Ou melhor ainda, treine-os em algumas tarefas diferentes para que possam contribuir com coisas como testes.

Outra coisa a ter em mente é que a execução de projetos em paralelo mata sua programação. Considere o seguinte: para simplificar, digamos que temos 5 projetos usando a mesma equipe e começando na mesma data. Cada projeto precisa de 3 meses de esforço. Na melhor das hipóteses, executando em paralelo, você os terminará todos de uma vez e levará 15 meses. Sua velocidade será reduzida porque você só consegue ajustar 1/5 de um mês de esforço em um único sprint. Você também fará 5 reuniões de demonstração ao mesmo tempo. Então, na melhor das hipóteses, você entrega seus 5 projetos em 15 meses e sua concorrência afirma que eles poderiam fazer o mesmo trabalho em 3. Suas equipes de estimativa de maturidade sofrerão porque só poderão considerar 20% da mão de obra disponível. Você pode descobrir que, na verdade, não consegue realizar algumas tarefas em um único sprint. Se você tiver que mudar o número de projetos em execução de 5, sua equipe terá que ajustar seus hábitos de estimativa, o que prejudicará a eficiência das equipes. Além disso, sua equipe terá dificuldade em se auto-organizar quando uma simples reatribuição de tarefas pode exigir a ativação de um novo ambiente de desenvolvimento antes que o trabalho possa começar.

Se você executasse os mesmos 5 projetos em série, entregaria o 5º projeto nos mesmos 15 meses, mas teria informado ao seu cliente que sua equipe está em tal demanda que você tem um backlog de 12 meses e que pode usar esse tempo para refinar seus objetivos de projeto. Ou se você tem um backlog constante, sabe que é hora de começar a contratar outra equipe. Seu melhor projeto, no entanto, é concluído em 3 meses com um cliente que viu melhorias rápidas durante o período ativo. Você pode terminar esse projeto um ano antes e colocá-lo em seu currículo. Sua velocidade de sprint se estabilizará ao longo desse período de tempo e você pode descobrir que atinge seu ritmo após um ou dois projetos e é capaz de realizar mais em um determinado sprint.

Acho que executar projetos em série é um dos maiores obstáculos que uma organização tenta adotar faces de scrum. É uma grande mudança cultural associada à desconstrução da função de gerente de projeto, mas os benefícios para o processo scrum são enormes.

Lembre-se de que TODOS não precisam ser membros completos da equipe. Eles podem envolver seu cliente na sala de espera, preparando-se para o processo de desenvolvimento. Eu mantenho meus analistas de negócios, arquitetos de rede e pessoal de design gráfico como especialistas de domínio e apenas os incluo em uma equipe quando necessário. Deixe-os rodar com o sprint 0. Você ficaria surpreso com o quão envolvente é trabalhar na aparência e no fluxo de trabalho. Também é bom preparar seu cliente com a compreensão de que, quando o desenvolvimento começa a sério, seu nível de participação pode realmente aumentar e que é importante que ele esteja disponível. Informe-os sobre a programação para que tenham bastante tempo para lidar com coisas como férias e feriados com bastante antecedência.

Eu estive nesta situação precisa.

Se você tiver um product owner entre os projetos, Phillipe está absolutamente correto; Um sprint com uma equipe deve funcionar bem.

Se você tiver mais de um proprietário do produto, o ideal é que o lado comercial precise escolher um único "priorizador", a quem é atribuída a responsabilidade de programar o trabalho. Esta é definitivamente a melhor solução.

Se (como provavelmente é o caso) a empresa não deseja alterar a forma como deseja priorizar as coisas (isso seria muito conveniente), você pode dividir a equipe e executar dois sprints simultâneos. No entanto, com uma equipe de seis, eu não iria dividi-la em mais de 3 equipes (eu não gostaria de dividi-la, mas acho que 2-3 equipes seriam viáveis). Dividir ainda mais como Kenny sugere, e ter equipes de uma única pessoa me parece um tanto sem sentido, já que você não tem mais uma equipe, apenas programadores individuais.

Se você está dividindo a equipe, não achei muito valor em juntar os stand-ups, a menos que você tenha sprints separados trabalhando em grande parte da mesma base de código, mas então isso pode ser um argumento para amalgamar essas equipes com o propósito de o sprint.

Há outra opinião que tenho lido recentemente, a saber, que em um ambiente Ágil, o conceito de Projeto pode ser contraproducente e pode ser eliminado. De acordo com essa linha de pensamento, a organização deve se concentrar nos Releases . Isso ocorre porque Projetos são caixas artificiais de trabalho que não produzem valor até que sejam concluídas. Eles são contrários ao objetivo do Agile de entregar frequentemente valor entregável. Um Release está mais alinhado com o Agile porque é orientado para a entrega de valor e porque seu escopo pode ser reduzido ou expandido com base no que as equipes podem entregar antes do próximo Release .

Existe um meio termo em potencial, no qual o que antes era chamado de Projeto em sua empresa agora é reformulado como o Tema ou Recurso Agile comum . O benefício dessa abordagem é que o Tema ou Recurso agora pode ser implementado em partes de valor, conforme o proprietário do produto achar adequado.

Ainda há a questão de uma equipe trabalhando em vários Produtos , e é uma questão por causa de preocupações legítimas sobre o conhecimento do domínio e possíveis habilidades técnicas. Mas os produtos construídos com Agile, até mesmo vários produtos construídos por uma única equipe, estão constantemente acumulando lançamento valor -able. Em contraste, os projetos não valem nada até serem concluídos (e muitos não).

Algo para pensar sobre...

Acho que anopres estava certo: a melhor maneira é evitar vários projetos ao mesmo tempo com o scrum. Faça de tudo para ter certeza de que executar muito em paralelo não é eficiente.

Vamos supor 5 projetos cada um com cerca de 3 meses para equipe com 5 pessoas.

Abordagem 1: cada pessoa trabalha em um único projeto na equipe

• 1/5 da velocidade de entrega por projeto dá 15 meses de entrega para todos os projetos
• Cada pessoa é especialista, mas apenas em seu próprio projeto
• Sem espírito de equipe

Abordagem 2: 1 sprint por projeto, troca de projetos

• A cada 6 sprint trabalhe no projeto
• Tempo muito longo entre o trabalho do projeto - valor incremental não regular para o projeto (para o backlog do produto sim), fácil de esquecer, esforço necessário para restaurar o contexto,
• Primeiro projeto entregue após cerca de 12-13 meses (assumindo 2 semanas de sprint)

Abordagem 3: 5 projetos em sprint único

• Requer muita divisão detalhada de tarefas apenas para caber no sprint
• Muito pouca construção incremental por projeto
• Entrega do primeiro projeto após cerca de 12-15 meses

Abordagem 4: recomendado - trabalho serializado

• A equipe trabalha em um único projeto após projeto
• Primeiro projeto iniciado e entregue após 3 meses
• Segundo projeto iniciado após o 3º mês, entregue após 6º mês
• ...
• 5º projeto iniciado após 12º mês, entregue após 15º mês
• Equipe altamente focada em projeto, pesquisa intensiva e colaboração com o cliente
• Toda a equipe tem um bom conhecimento geral sobre todos os projetos
• Não perca tempo trocando de contexto
• Exigir boa cooperação da equipe (conflitos podem retardar a entrega).

Como você pode ver, a solução 4 geralmente é melhor porque os projetos são entregues muito mais rápido, a equipe trabalha em conjunto e é eficiente. Outras abordagens incluem perda de tempo com a troca de contexto, nenhuma colaboração de equipe completa, tempo total de entrega muito longo de todos os projetos, etc.

E quanto à preparação do backlog? Se a equipe trabalhar em um único projeto ao mesmo tempo, isso é simples - todos irão aderir. Se houver vários projetos, podemos precisar delegar pessoas solteiras para sessões de preparação separadas (nem a equipe completa está envolvida).

É importante convencer os clientes de que iniciar o segundo projeto após 3 meses ainda resultará em uma entrega mais rápida (após o 6º mês), em vez de iniciá-lo imediatamente com todos os outros. É uma ilusão que os gerentes veem - começamos 5 projetos de uma vez, trabalhamos muito e entregamos aos poucos. No final, isso não é eficiente.

É por isso que não acredito que o scrum seja eficiente para vários projetos em paralelo, é muito complicado combiná-lo com a estrutura e trabalhar de acordo com as regras do scrum. Às vezes pode ser bom ter 2 projetos para manter todas as pessoas ocupadas, mas quanto mais projetos adicionarmos, menos eficiente será o scrum. Talvez o kanban seja uma alternativa apenas para ver o progresso e o trabalho em equipe (não tão forte como no time Scrum)?

Atenciosamente Adam

Como disse @Chris, um projeto normal tem subprojetos dentro. No entanto, você só tem um backlog.

Pense em um backlog com todos os seus projetos. Primeiro problema: você está atribuindo prioridades a tarefas ou projetos? Eu prefiro um backlog por projeto. Pelo menos para ter claro as prioridades que o product owner tem.

Ter proprietários de produtos diferentes, e pelo fato de esses donos de produtos não concordarem sobre quanto tempo devem dedicar a cada projeto. "Alguém" terá que absorver a decisão sobre como gerenciar as prioridades entre os projetos. Nota: os desenvolvedores não devem fazer isso.

Aí vem nosso gerente de projeto "S", que vai equilibrar os recursos de que os donos de produtos precisam e o tempo que os membros da equipe podem dar. O product owner A pagou por um mês de trabalho, mas o product owner B está sempre atualizando seu projeto (e pagando bem a você). Há alguma forma de equilibrar sua equipe para que A tenha seu um mês (tempo de desenvolvedor), e não impedirá B de encher seus bolsos.

No caso de software interno (uma empresa, mil projetos). Os diferentes proprietários do produto devem concordar com o tempo que lhes é concedido. Eles não vivem isolados, mas no mesmo barco que você (gerente do projeto "S"). Facilitarão sua vida podendo adiar algumas tarefas, mas ao mesmo tempo você nunca deve esquecer suas necessidades.

Bem, ainda estou tentando descobrir a melhor maneira de fazer isso. Mas é isso que estamos pressionando agora. Espero que ajude.

Os membros da equipe podem dividir seu tempo entre os projetos scrum, mas é muito mais produtivo ter membros da equipe totalmente dedicados. Os membros da equipe também podem mudar de um sprint para o outro, mas isso também reduz a produtividade da equipe. Projetos com equipes maiores são organizados como vários scrums, cada um focado em um aspecto diferente do desenvolvimento do produto, com estreita coordenação de seus esforços.

Eu sugeriria executar um Sprint para cada projeto e ter 1 reunião diária para lidar com todas as fontes / projetos ativos.

Eu gostaria de contribuir. É assim que eu faço:

• Há um product owner e um product backlog por equipe. O product owner não precisa ser uma única pessoa, mas esta "entidade" product owner é responsável pelo product backlog.
• O backlog do produto contém as histórias de usuário de cada projeto (todos os projetos aqui). Cada história de usuário tem um esforço / pontos de história (responsabilidade da equipe) e um valor de negócio (responsabilidade do proprietário do produto).
• Temos uma "preparação do backlog do produto" atendendo a cada sprint. Antes desta reunião, o product owner atualizou os valores de negócios das histórias (se eles precisarem de alguma mudança por qualquer motivo de negócios - que não devemos e não devemos nos importar -) e incluir algumas novas histórias. Nesta reunião, as novas histórias são explicadas e os esforços são atualizados também. Esta reunião dura cerca de uma hora (exceto a primeira vez, cerca de 4 horas).
• Quando vamos planejar um novo sprint, abrimos o product backlog, ordenamos as histórias por ROI (este é o valor / esforço do negócio) e planejamos as histórias até o tempo acabar.

E é isso. Posso dizer que isso funciona muito bem. Usamos algumas planilhas do Google (o product backlog e o sprint backlog, ambos com gráficos e outras coisas) para fazer isso, e redmine (com uma semântica específica) para uma organização online todos os dias: tempo, progresso da tarefa, etc.

O problema com essa abordagem é que dupliquei as tarefas na planilha do sprint backlog e no redmine. Mas não encontro nenhuma ferramenta online para fazer isso totalmente online. Sinto falta de um product backlog no redmine (nenhuma outra semântica funciona para mim), uma única placa no jira, mais histórias na taiga, etc.