Foi lançada uma versão revisada do Scrum Guide, o guia oficial do Scrum escrito pelos seus criadores Ken Schwaber e Jeff Sutherland.
Ken Schwaber e Jeff Sutherland resolveram simplificar o Scrum Guide para conter apenas o que eles consideram as regras do Scrum. Ou seja, foram retiradas do documento todas as coisas que não são obrigatórias à prática do Scrum, como dicas, práticas e técnicas opcionais. Essa mudança foi justificada como uma tentativa de diminuir os erros de interpretação acerca do que é ou não Scrum.
Como essa versão 2011 está disponível apenas em inglês, até que sejam feitas traduções para as outras línguas, explicaremos neste artigo as principais mudanças feitas e quais os possíveis impactos para a sua equipe.
- O termo time definido até então no Scrum para referir-se à equipe de desenvolvedores, aqueles que executam o trabalho de criação do incremento de produto, gerava confusão com o time de scrum, usado para referenciar todos os comprometidos de um projeto. Para solucionar tal confusão, definiu-se que a partir de agora os desenvolvedores serão chamados de equipe de desenvolvimento (do inglês, development team), independente das atividades executadas por cada um deles.
- Nessa nova versão do guia foi dada mais atenção ao papel do Scrum Master, detalhando melhor as atividades desempenhadas por ele e em especial a sua influência no ambiente da organização.
- O acompanhamento diário do andamento da sprint deve ser feito, mas não é obrigatório o uso do gráfico de burndown. O importante é ter conhecimento diário do trabalho que ainda resta ser feito e acompanhá-lo ao longo da sprint.
- Apesar do planejamento de releases ser uma prática aconselhada, também não é obrigatório no Scrum.
- As equipes de desenvolvimento não se comprometem com a conclusão do trabalho planejado durante a reunião de planejamento da Sprint. A equipe de desenvolvimento cria uma previsão de trabalho que acredita que será feito, mas essa previsão pode mudar à medida que o conhecimento relacionado às histórias aumenta ao longo da Sprint.
- O Product Backlog é “ordenado” ao invés de “priorizado” provendo flexibilidade ao Product Owner para otimizar valor de acordo com as circunstâncias existentes. Ou seja, o P.O. indica a sequência em que deseja que as histórias sejam tratadas.
Futuramente discutiremos aqui essas mudanças com mais detalhes. Enquanto isso, dê a sua opinião. O que você achou das modificações? Vamos por em discussão?
