Gerenciamento de Mudanças: Tradicional vs Scrum

A mudança é inevitável em todos os projetos. No mundo competitivo de hoje, onde tecnologia, condições de mercado e padrões de negócios estão mudando continuamente, a mudança é a única constante. No entanto, a abordagem para gerenciar mudanças difere nos métodos tradicionais de gerenciamento de projetos e Scrum.

Neste artigo, entenderemos como.

O gerenciamento de mudanças em projetos gerenciados tradicionalmente está intimamente relacionado ao Gerenciamento da Configuração. Todas as mudanças são consideradas com base em sua magnitude de variação em relação a linha de base. O Gerente de Projetos recebe tolerâncias dentro das quais ele pode gerenciar as atividades e decisões do dia-a-dia do projeto. Quando uma solicitação de mudança excede as tolerâncias definidas, o Gerente de Projetos deve escalar a mudança proposta para níveis mais altos de gerenciamento e aguardar sua decisão antes de implementar a mudança. O Gerente de Projetos primeiro registra a solicitação de mudança em um Registro de Questões ou Registro de Mudanças e, em seguida, encaminha a mudança para autoridades superiores. Isso pode incluir o patrocinador do projeto, bem como outras partes interessadas e tomadores de decisão relevantes. Em algum momento, uma avaliação de impacto será realizada. Com base no impacto estimado da mudança, será tomada uma decisão sobre se a mudança deve ser implementada ou não. O Gerente de Projetos também pode propor possíveis soluções para quaisquer problemas apresentados pela mudança. Se as autoridades superiores decidirem prosseguir com a mudança, o Gerente de Projetos é responsável por garantir que a mudança seja implementada corretamente.

A mudança no Scrum funciona de maneira muito diferente em comparação com o gerenciamento de projetos tradicional. O framework Scrum é altamente ajustado para gerenciar mudanças de forma eficaz e eficiente. Sempre que o Dono do Produto ou o Time Scrum reconhece um problema ou defeito ou identifica um Item do Backlog Priorizado do Produto que precisa ser corrigido, substituído ou adicionado, a mudança é feita no Backlog Priorizado do Produto. Da mesma forma, o Dono do Produto ou as partes interessadas podem adicionar Solicitações de Mudança ao Backlog Priorizado do Produto. O Dono do Produto ou as partes interessadas aprovam as Solicitações de Mudança e priorizam novamente o Backlog. Sempre que há um problema ou novo requisito que precisa ser tratado imediatamente e exige uma mudança que afete o Sprint atual, o Dono do Produto encerra o Sprint, com a aprovação das partes interessadas relevantes. Uma vez encerrado, o Sprint será reprojetado e reiniciado para incorporar os novos requisitos.

No entanto, se o problema ou mudança não for grande e não garantir uma mudança no Sprint atual, a mudança será adicionada ao Backlog Priorizado do Produto e incorporada ao planejamento de um Sprint subsequente. Isso dá às partes interessadas a capacidade de responder às mudanças no ambiente externo, enquanto ainda mantém um certo grau de controle sobre as atividades em andamento dentro do projeto. Além disso, no final de cada Sprint, os resultados concluídos são demonstrados pelo Time Scrum. Essas entregas são potencialmente entregáveis e podem ser revisadas pelo Dono do Produto e outras partes interessadas.