BT

Scrum Guide Atualizado: Foco no Framework

por David Bulkin , traduzido por Paulo Rebelo em 04 Ago 2011 |

[Esta tradução adapta o texto original]

Ken Schwaber e Jeff Sutherland, co-autores do Scrum Guide, a introdução oficial ao Scrum (que dita as "regras do jogo") lançaram a primeira atualização do guia, originalmente lançado em fevereiro de 2010. A atualização foca no framework do Scrum, nas suas regras e cerimônias. Com principal mudança, o guia deixa de incluir detalhes específicos sobre estratégias e técnicas. Os autores dizem que iniciarão um resumo de "Melhores Práticas" para apresentar suas experiências.

A nova versão está disponível no site oficial do Scrum. A última página resume as mudanças em relação à versão anterior. Um documento separado, "Scrum Update", explica o contexto adicional do que foi mudado. A seguir são apresentadas as mudanças, juntamente com o contexto do que foi alterado.

O Scrum sempre deixou claro que existem somente três papeis, o Product Owner, ScrumMaster e o Membro do Time. Esses membros do time são chamados de Desenvolvedores no guia.

O time de pessoas que realizam o trabalho de criar um incremento é o Time de Desenvolvimento. Independentemente do trabalho executado por membros do time individualmente, são mais conhecidos como Desenvolvedores.

Os planos feitos no planejamento do sprint são frequentemente compromissos a serem assumidos. O próximo esclarecimento torna isso mais evidente em sprints curtos; o plano está aberto a mudanças, na medida em que for melhor compreendido:

Os Times de Desenvolvimento não se comprometem em completar um trabalho planejado durante o Sprint Planning. O Time de Desenvolvimento tem uma previsão do trabalho que acredita que será feito, mas a previsão mudará à medida que esse trabalho venha a ser mais conhecido durante o Sprint.

Nos últimos anos, os Diagramas de Fluxo Acumulativos (CFDs, em inglês) foram muitas vezes complementados ou substituídos pelos gráficos tradicionais de burndown para monitorar o progresso. Pelo esclarecimento abaixo, CFDs, burndowns, e outras abordagens de monitoramento são igualmente válidas, desde que informem diariamente o progresso do trabalho restante.

O Scrum não obriga a criação de um gráfico de burndown para monitorar o progresso; exige somente que:
  • O restante do trabalho de um sprint seja resumido e conhecido diariamente.
  • A tendência para completar o trabalho do sprint seja mantida ao longo do sprint.

Embora a maioria dos times faz de algum modo o planejamento do release, o planejamento do release não é obrigatório no framework Scrum, o que faz especialmente sentido para esforços de vida curta:

O Planejamento de um Release é algo de grande valia para se fazer quando se usa o Scrum, mas não é exigido pelo Scrum em si.

À medida que mais times utilizam ferramentas eletrônicas e criam relacionamentos complexos por meio de diferentes níveis de backlogs (por exemplo, do nível empresarial até o nível de time), perde o sentido a distinção exata entre os backlogs do produto. Como reforça o trecho abaixo, o backlog do sprint é simplesmente um conjunto de itens do backlog do produto que compõe o sprint, juntamente com um plano para realizá-los (para se tornarem Done).

O backlog do sprint é o conjunto de itens do backlog do produto selecionados para o sprint, somado um plano para entregá-los. Não há mais o conceito requerido para "itens do backlog do sprint", embora a técnica possa ajudar a criar um bom plano. Um Time de Desenvolvimento auto-organizado sempre tem um plano.

O conceito de priorização de um backlog do produto implica que a funcionalidade foi lançada puramente na ordem do valor de negócio, ignorando os aspectos técnicos e dilemas. O esclarecimento final usa a palavra "ordenada", ao invés de "priorizada", para representar uma visão mais holística da sequência para o lançamento.

O backlog do produto é "ordenado", ao invés de "priorizado". Isso traz flexibilidade para o Product Owner otimizar valor em suas circunstâncias específicas.

O novo guia está muito mais claro, e mais fácil de ler, além de mais conciso, o que beneficia o entendimento para aqueles que pretendem adotar o Scrum em seus times e empresas. Os esclarecimentos citados mostram a simplicidade do framework, desde a quantidade de papeis presentes e também dos itens que não são mais obrigatórios, como por exemplo o gráfico de burndown. O guia continua enfatizando a importância de o time adotar uma definição de "pronto" (Done), o que ajuda muito na identificação do que pode ser considerado um entregável para o Product Owner e para o negócio.

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
Comentários da comunidade

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

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.