Concrete Logo
Hamburger button

Nova versão do Scrum

  • Blog
  • 10 de Agosto de 2011
Share

[fblike]

 

Scrum mudou, o que os Deuses decidiram?

 

https://www.implementingscrum.com/2007/08/06/scrum-scrum/

 

Jeff Sutherland e Ken Schwaber, criadores do Scrum, acabaram de lançar o Scrum Guide 2011. A versão anterior de Fevereiro de 2010 precisava mesmo de uma revisão.

As mudanças não foram muito radicais. Apenas esclarecer as intenções dos seus criadores. E reafirmar que Scrum é um framework.

Em vez de soluções fáceis e receitas de bolo, o praticante de Scrum deve sempre medir cada passo, e confiar na ciência. O novo guia firma posição que é um método empírico de controle e não um conjunto de boas práticas para projetos de software.

As boas práticas que foram retiradas do Guia Scrum farão parte de outros materiais na scrum.org citados explicitamente como boas práticas.

 

Eis o que mudou:

    Na versão anterior, os times formados por Scrum Master, Product Owner e Time, era chamado de Scrum Team (Time Scrum). E os Desenvolvedores efetivamente trabalhando no projeto eram chamados de Time (Team).

    Isto causava alguma confusão entre os termos Time Scrum e Time. Agora o Time é composto por Scrum Master, Product Owner e Time de Desenvolvimento (Development Team).

    Os Desenvolvedores não estão atrelados ao desenvolvimento de software, mas ao desenvolvimento de qualquer produto complexo, o alvo de Scrum. Ou seja, os Desenvolvedores são os membros daquele time capaz de transformar requisitos em produto, qualquer que seja o seu domínio de atuação.

    Não se fala mais na obrigação de priorizar o Product Backlog, mas sim de ordenar os ítens. A principal razão é que cada item terá uma função de retorno de valor com o tempo diferente pois buscamos ao usar Scrum um melhor retorno (ROI) para o projeto como um todo.

    Nisto há vários fatores que um Product Owner deve considerar. Assim, o Product Owner não tem restrições para gerenciar os ativos sendo criados ou mantidos. Independente do valor atribuído a cada item, será claro para o Time Scrum qual é o próximo item a ser entregue.

    Em 2010, a definição de Scrum incluía a necessidade de uma Plano de Entregas (Release Plan), de manter uma lista de tarefas para o Sprint e de utilizar um Gráfico BurnDown durante o Sprint. Muito embora estas sejam práticas valiosas e úteis, são apenas boas práticas. Foram retiradas da definição de Scrum.

    O Product Owner deve planejar as entregas. Como ? Dependerá dele.

    Como fazer as entregas dentro do Sprint? Também fica a cargo do Time de Desenvolvimento. Se os Desenvolvedores quiserem quebrar em tarefas, em User Stories, em Use Cases, ficará a cargo deles garantir o aceite do PO nos itens. O importante é que o Time Scrum gerencie aquilo que for necessário para o sucesso do projeto.

    O ultimo ponto que vale a pena comentar é com relação ao compromisso assumido pelo Time de Desenvolvedores a cada Sprint. Na versão nova de Scrum, o termo Commitment (Compromisso) foi alterado para Forecast (Previsão).

    O motivo para isso é a necessidade de uma mudança cultural. Se os Desenvolvedores são pressionados a apenas cumprir o compromisso assumido, acabamos de criar uma disfunção. A Engenharia do Produto é colocada de lado pela aparência de se cumprir o exigido.

    Na verdade o Débito Técnico estará lá escondido dos Stakeholders. Mas se perde muito do valor de Scrum, a Transparência.

    Na prática, a mudança é sutil, pois o time ainda se compromete com o objetivo do Sprint, e deve estar comprometido com suas estimativas (através do Forecast). Ainda assim, deve ficar claro para todos a natureza incerta de se desenvolver produtos complexos, como é o caso de se fazer software. E por isso o termo Previsão foi adotado, para fortalecer a cultura do empiricismo e o seu entendimento.

 

No geral o novo Scrum está mais simples, objetivo e claro. Não podíamos pedir mais que isso…

 

Comentários são bem-vindos.