BT

Experimente a nova interface visual do InfoQ! Veja o novo design do InfoQ 3.0 e nos diga o que você achou.

Gerenciar Requisições de Mudanças em Scrum

| por Vikas Hazrati Seguir 0 Seguidores , traduzido por Flávia Castro de Oliveira Seguir 0 Seguidores em 09 dez 2008. Tempo estimado de leitura: 3 minutos |

Change Controle é um processo da gerência de projetos tradicional para administrar mudanças. Em um projeto tradicional o controle de mudança tipicamente consiste no preenchimento de um detalhado formulário de mudança que inclui atributos como o detalhes da mudança, o impacto no projeto, riscos, migrações etc. Também precisa da aprovação de diversas pessoas. O controle de mundanças tradicional discorda do Agile porque ele entra em conflito com o princípio de “Responder às mudanças é mais importante do que seguir um plano”. Respondendo as mudanças torna se difícil quando há enormes formulários para preencher e listar as aprovações requeridas. Em uma discussão interessante no grupo Lean Agile Scrum, os membros deste grupo discutiram a necessidade de monitorar as mudanças no Scrum e a possível maneira em que algumas mudanças poderiam ser monitoradas.

Por que um time precisa monitorar as mudanças?

Uma das razões citadas por Ashish Pathak é impedir que o product owner faça adições desnecessárias ao product backlog. Isto por sua vez reflete sobre a eficiência do product owner. O grupo concordou que as vezes os itens do backlog não são bem pensados, resultando no fato de que eles tendem a mudar com muita frequência. Mary Poppendieck sugeriu, que a princípio, dissuadir as mudanças para chegar ao backlog soa como um aroma de processo. Entretanto, ela concordou que o product backlog não deve ter alta rotatividade. Segundo ela,

a meta para qualquer backlog inicial é que ele deve ser tão curto e de alto nível que não terá que mudar. Se o backlog muda, então você deve assumir que o backlog é o culpado, e não o requisitante de mudança. Um pedido de mudança normalmente significa que o backlog foi muito longo ou muito detalhado para começar; muito tempo foi gasto tentando adivinhar o futuro.

Ela também mencionou que,

Se você medir a rotatividade (mudanças em itens do backlog a partir do tempo que eles são adicionados até que o produto entre em produção), diria que de 10-15% não é um problema. Mas de 50-200% significa que alguém está desperdiçando muito tempo colocando no backlog, coisas que vão mudar, eles não tem muito senso do que está certo e o que não está. A alta rotatividade é frequentemente um sinal de que o backlog é usado para tentar impedir as mudanças e isolar a organização, da incerteza, em vez de criar um processo que é bom em responder aos eventos conforme eles se desdobram e permitir à organização, lidar com a incerteza.

O grupo concordou que fazer uma análise baseada na rotatividade do backlog iria ajudar o product owner a aperfeiçoar o backlog para conter itens relevantes. A discussão também reconheceu que o monitoramento das mudanças seriam úteis em um par de cenários. Estes incluem quando for necessário monitorar decisões anteriores no que diz respeito a uma mudança ou quando o monitoramento é um requisito regulamentar.

Então, como um time monitora as mudanças?

A maioria dos membros do grupo concordaram que as mudanças devem ser adicionadas ao backlog. Brian Bozzuto sugeriu que o item no backlog poderia ter um atributo que identifica a origem da estória. Os valores para o atributo poderiam ser: original, novo, mudança, etc.

Em linhas semelhantes, Erik Landes sugeriu uma abordagem baseada em Kanbans Lean para administrar o pedido da mudança. Chris Woodill sugeriu um caminho genérico para implementar um processo de controle de mudança Ágil. De acordo com ele, a principal consideração deve ser para manter o processo leve e eliminar os resíduos tanto quanto possível.

Suas principais recomendações são:

  • Registrar a mudança no backlog ou monitor de mudança
  • Eliminar tantas aprovaçõe quanto for possível
  • Ter um formulário de controle de mudança leve, se necessário
  • Manter envolvidos os stakeholders e o time de operações

Assim, em certas situações específicas, talvez seja necessário monitorar as mudanças. Monitorar as mudanças usando algo como o product backlog rotativo ajudaria a erradicar os resíduos no processo e possívelmente tornar o product owner mais eficiente. Há outras razões e modos de monitorar mudanças também, mas a chave é manter o processo enxuto e detalhar somente o necessário.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Change Requests = Implementação Tradicional do Escopo Aberto by Felipe Rodrigues

Change Requests nos processos tradicionais são usados para esconder o escopo aberto. =)

Eu não ach oque devemos ter isos no Agile, pois vai contra o princípio de responder às mudanças. O processo prega a mudança, por isso, como burocratizar.
Dessa forma, acredito que o facilitador do processo (Scrum Master, coach, etc) deve orientar o cliente para que ele não peça tudo que quer no começo, impedindo que os pedidos sejam prematuros e infundados. Isso acontece devido à premissa que tínhamos no processo tradicional, onde acreditava-se que se não pedir no começo não pode mais pedir. Era a política do Fale agora ou cale-se para sempre.

Isso não é ágil.

Re: Change Requests = Implementação Tradicional do Escopo Aberto by Roni Amaro

Mudança não tem como impedir, em qualquer projeto vai ter, a questão é reduzir a mudança com impacto negativo. Projeto sem escopo não é projeto. Se vai fazer escopo em cima de história pode pedir para todos os arquitetos de software rasgar o diploma e pendura as chuteiras.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

2 Dê sua opinião
BT