Em Programa

1. Não é recomendado fazer mudanças em entre o período de duas Reuniões do Backlog do Programa.

2. Se a modificação for mínima, o Dono do Produto do Programa deve garantir a aprovação dos stakeholders (patrocinador, cliente e usuário final) e em seguida, adicionar os requisitos no Backlog do Programa. O Dono do Produto do projeto irá considerar estes requisitos para inclusão em Sprints futuros.

3. Se a mudança é grande, os esforços do programa, juntamente com os programas, projetos e Sprints associados, precisam parar, e uma Reunião do Backlog Priorizado do Produto do Programa deve ser realizada para determinar os próximos passos.

4. As Reuniões Backlog Priorizado do Produto do Programa (também conhecidas como Reuniões do Backlog do Programa), devem ser realizada em intervalos de 2 a 6 meses. Em grande parte, a

frequência e o impacto de modificações em um programa determinam a duração de tempo entre duas Reuniões do Backlog do Programa. Se existem várias modificações esperadas no programa, é preferível a realização de Reuniões do Backlog do Programa em intervalos mais regulares (por exemplo, de 2 a 3 meses), mas se existem poucas mudanças esperadas e se os requisitos são estáveis, a duração entre duas Reuniões do Backlog do Programa poder ser maior (por exemplo, de 5 a 6 meses).

A figura 6-8 demonstra como as mudanças podem ser gerenciadas dentro do fluxo do Scrum para ambos, portfólios e programas.

6

6.7 Resumo das Responsabilidades

Papel Responsabilidade

Scrum Guidance

Body • Fornecer a orientação geral para os procedimentos de gerenciamento de mudanças a serem seguidos durante o projeto Dono do Produto do

Portfólio

• Fornecer as Solicitações de Mudança para o portfólio

• Aprovar os produtos que serão alterados, removidos ou adicionados, de acordo com os requisitos do portfólio

Scrum Master do Portfólio

• Facilitar a identificação, avaliação e gerenciamento de Solicitações de Mudança para os portfólios

Dono do Produto do Programa

• Fornecer as Solicitações de Mudança para o programa

• Aprovar os produtos que são alterados, removidos ou adicionados, de acordo com os requisitos do programa

Scrum Master do Programa

• Facilitar a identificação, avaliação e gerenciamento de Solicitações de Mudança para os programas

Stakeholder(s) • _• Fornecer a solicitação de mudança _{Envolvido com a aprovação e priorização das Solicitações de Mudança}

Dono do Produto

• Fornecer a solicitação de mudança de um projeto

• Avaliar o impacto das solicitações de mudança consideradas para o portfólio, programa ou projeto

• Priorizar as Estórias de Usuário no Backlog Priorizado do Produto do projeto • Avaliar o impacto dos problemas nos objetivos do projeto identificados pelo

Time Scrum

• Fornecer uma comunicação clara para os stakeholders sobre Itens Repriorizados do Backlog do Produto

Scrum Master • Facilitar a identificação, avaliação e escalabilidade dos problemas e das _{Solicitações de Mudança pelo Time Scrum} Time Scrum • Sugerir melhorias ou mudanças durante os processos de Criar as Entregas e _{Reunião Diária}

6.8 Scrum x O Modelo Tradicional de Gerenciamento de Projetos

O gerenciamento de mudança em modelos tradicionais de projeto está relacionado ao Gerenciamento de Configuração. Todas as modificações são consideradas com base em sua magnitude de variação, a partir de um valor base. É dado ao Gerente de Projeto as tolerâncias dentro das quais, ele ou ela pode gerenciar as atividades do dia-a-dia e as decisões do projeto. Quando uma Solicitação de Mudança excede os limites definidos, o Gerente de Projeto deve escalar a mudança proposta, para níveis mais elevados de gerência e aguardar pela decisão antes de iniciar a implementação. O Gerente de Projeto primeiro registra a solicitação de mudança no Registro de incidente ou no Registro de Mudança, em seguida, transfere a mudança para as autoridades superiores. Podendo incluir o patrocinador do projeto, bem como, os stakeholders relevantes e os tomadores de decisão. Em algum momento, uma avaliação de impacto será realizada. Com base no impacto estimado da mudança, uma decisão será tomada para determinar se a mudança deve ser implementada ou não. O Gerente de Projeto também pode propor possíveis soluções para os problemas causados pela mudança. Se a decisão é tomada pelas autoridades superiores, para prosseguir com a mudança, o Gerente de Projeto é responsável em garantir que a mudança será implementada corretamente.

A Mudança em Scrum funciona de uma forma muito diferente se comparada ao Modelo Tradicional de Gerenciamento de Projeto. O framework Scrum é altamente sintonizado para gerenciar mudanças com eficácia e eficiência. Sempre que o Dono do Produto ou o Time Scrum encontram um problema ou defeito, ou identificam um Item do Backlog Priorizado do Produto que precisa ser alterado, substituído ou adicionado, a modificação é feita no Backlog Priorizado do Produto. Da mesma forma, a alta administração, o Dono do Produto, ou o(s) stakeholder(s) podem adicionar Solicitações de Mudança para o Backlog Priorizado do Produto. O Dono do Produto e o(s) Stakeholder(s) aprovam as Solicitações de Mudança, e o Backlog é priorizado de acordo. Sempre que há um problema ou um novo requisito que precisa ser tratado imediatamente e exige uma mudança que afeta o Sprint atual, o Dono do Produto encerra o Sprint com a aprovação dos stakeholders relevantes. Uma vez encerrado, o Sprint vai ser replanejado e reiniciado para incorporar os novos requisitos.

No entanto, se o problema ou a mudança não é grande e não garante uma mudança no atual Sprint, a modificação será adicionada ao Backlog Priorizado do Produto e incorporada no planejamento de um Sprint subsequente. Isto dá aos stakeholders a habilidade de responder a mudanças no ambiente externo, enquanto ainda é mantido um certo grau de controle sobre as atividades do projeto em andamento. Além disso, no final de cada Sprint, os Entregáveis Prontos são demonstrados pelo time Scrum. Estes entregáveis são potencialmente utilizáveis e podem ser revisados pelo Dono do Produto e por outros stakeholders.

7