Encerramentos de Projetos em Scrum

Em um ambiente típico de desenvolvimento de software, os fechamentos de projetos marcam o fim de um projeto.

1. Os registros do projeto são concluídos e arquivados,
2. recursos liberados,
3. questões e lições estão documentadas e
4. um jantar formal / festa realizada para comemoração.

O último passo é opcional, embora seja muito motivador para os participantes. :-)

Compare isso com o Scrum. Eu sei que o scrum é executado em histórias de backlogs . Portanto, tecnicamente, toda iteração fecha determinadas histórias. Então, existem duas perguntas aqui.

1. Para um grupo que trabalha em vários projetos simultâneos , como se encaixam os fechamentos de projetos?
2. Para um projeto que envolve vários grupos , como esse conceito se aplica?

Ou o termo de encerramento do projeto não se aplica a projetos de T&M ?

Para um grupo que trabalha em vários projetos simultâneos, como se encaixam os fechamentos de projetos?

Primeiro, "múltiplos projetos simultâneos" é considerado uma péssima idéia. O objetivo do scrum é correr e terminar. A mudança de projetos para iniciar outro sprint é perturbadora. Fazer dois projetos ao mesmo tempo não é um sprint. É uma bagunça.

No entanto, o Scrum não é diferente de um método não ágil (em cascata). Quando o backlog é reduzido para aproximadamente zero, você ainda está pronto. Assim como se você tivesse uma abordagem em cascata em vez de uma abordagem ágil.

Às vezes, a lista de pendências é diferente de zero, mas o cliente está satisfeito e não quer mais. Então você está pronto. Geralmente feito mais cedo e mais barato que uma cachoeira (que precisa construir tudo, até as idéias que acabaram sendo inúteis).

Para um projeto que envolve vários grupos, como esse conceito se aplica?

O mesmo que um projeto não scrum com vários grupos. Nada muda nas pessoas. Eles ainda gostam de uma boa festa.

Ou o termo de encerramento do projeto não se aplica a projetos de T&M?

Por que a cobrança mudaria alguma coisa sobre a natureza do trabalho ou a cerimônia no final?

Normalmente, vejo métodos ágeis como práticas de scrum em uma estrutura de gerenciamento de projetos mais estruturada. Isso não é uma contradição. O Agile trabalha para entrega, seu objetivo é entregar o software certo mais rapidamente. Ajuda nas interações entre os desenvolvedores e as partes interessadas. Ele pode ser usado como parte de um programa de período fixo ou para aprimoramentos abertos.

Portanto, com isso em mente, não há razão para que o restante do gerenciamento de projetos não possa ser gerenciado de maneira tradicional, com um PM gerenciando a linha do tempo, os custos e outras dependências. Na conclusão, você terá seus eventos de encerramento, como de costume.

Trabalho em finanças, às vezes novas regulamentações acontecem ou uma nova troca aparece e temos uma data de entrada em funcionamento para o que está definido. Ainda usamos um método Agile para entrega, mas dentro de uma estrutura de gerenciamento de projeto mais tradicional, para que seja entregue dentro do prazo.

A estimativa de unidades de trabalho e a seleção de uma solução possível no prazo disponível é o que nos torna bons desenvolvedores (uma das coisas que devo dizer).

No Scrum, como em todas as técnicas Agile, os projetos são coisas menores que vão e vêm, enquanto a equipe permanece unida. Portanto, não há ritual de "projeto-clojure" como tal. Em vez disso, o projeto diminui enquanto outro cresce. O fluxo de itens da lista de pendências muda gradualmente de um para o outro. A equipe mal sabe a diferença.

De fato, a equipe pode estar trabalhando em dois ou três projetos diferentes ao mesmo tempo. Mais uma vez, eles mal sabem a diferença. Os itens da lista de pendências entram na equipe no início de cada sprint e a equipe os implementa. Todos eles podem pertencer a um projeto ou podem ser divididos igualmente entre vários. A equipe não se importa. A equipe apenas implementa os itens de lista de pendências que recebem.

Se a empresa precisa alterar a prioridade dos projetos, simplesmente altera o fluxo de itens da lista de pendências nas equipes.

Algumas das coisas que você está discutindo aqui serão incluídas nos processos mais ágeis, com documentação e versões frequentemente ocorrendo como uma questão de curso, em vez de esperar por algum gatilho externo. Isso nem sempre será o caso, é claro, dependendo de quais tipos de clientes você tem e em que tipo de negócio você atua. Por exemplo, se você estiver criando uma única parte de um sistema maior de propriedade de uma entidade externa, geralmente há uma data que conduz o processo, e essa data seria um momento apropriado para realizar tarefas adicionais de limpeza e, claro, festa. Outras vezes, mesmo quando o cliente é interno, a empresa ainda pode reconhecer a conclusão de um marco comercial / principal produto final / outro que exige novamente o fim da contabilidade / festa do projeto. Se sua empresa se engajar no planejamento de lançamentos, isso lhe dará pontos de interrupção naturais, mas mesmo se você não o fizer, é perfeitamente apropriado ter medidas de sucesso direcionadas aos negócios. Ou seja, os projetos podem não ser mais um recurso do seu processo de engenharia, mas certamente podem fazer parte do seu negócio, e celebrar / lidar com eles pode e ainda deve fazer parte da cultura da sua empresa.