Ricardo Fernandes Luiz

Scrum é um framework ágil voltado para gerenciamento de projetos de forma iterativa e incremental. Focado em entregas de valor para o cliente, com forte visibilidade e rápida adaptação.

1. História

O Scrum foi concebido inicialmente como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo “The New New Product Development Game” (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby, conforme figura abaixo.

Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de Scrum, apresentou oficialmente na OOPLSA (Object-Oriented Programming, Systems, Languages and Applications)  e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo.

Scrum é um framework simples. Apresentaremos abaixo os papéis, cerimônias e artefatos que compõe o fluxo do scrum, e logo após detalharemos seu fluxo:

2. Os papéis no SCRUM

Product Owner (PO): Possui a visão do produto e do retorno que o projeto trará para a empresa e para os envolvidos, logo sua missão é cuidar do Product Backlog, planejar releases, priorizar requisitos e passar ao time uma visão clara sobre os objetivos do projeto.

ScrumMaster (SM) : Exerce um papel de liderança no processo, mas ele não centraliza decisões, seu papel é guiar o time e a empresa para a auto-gestão, combatendo o comando-controle. O papel de S.M não possui autoridade alguma perante o P.O ou o Time. A responsabilidade do Scrum Master é manter o foco no processo, remover impedimentos da equipe e auxiliar na comunicação entre equipe e P.O.

Time: O time é uma equipe multidisciplinar que realizará a implementação do produto / projeto. O time deve manter a auto-gestão de suas atividades. Devem ser comprometidos e responsáveis em realizar o trabalho necessário para atingir a meta da sprint.

3. As cerimônias do SCRUM

a. Sprint Planning Meeting

É  a reunião onde se planejam os itens que serão entregues na próxima sprint. Sprint é um período de tempo definida idealmente entre duas e quatro semanas. Há um indicador chamado velocidade do time, que guia o número de funcionalidades que poderão ser entregues na sprint atual, com base no que foi entregue anteriormente, por isso  é importante que não se mexa neste período de tempo durante todo o projeto.

A reunião é dividida em duas partes a primeira é a do comprometimento, onde o time se compromete a entregar um certo número de funcionalidades, definindo estes itens como a meta da sprint, juntamente com o PO.

Um dos pontos interessantes é que depois que a sprint é definida não se podem incluir itens no meio da sprint, os itens devem ser incluídos na próxima sprint. Isso faz com que haja uma preocupação maior em priorizar os itens que serão atendidos na sprint por parte do PO, e também com que os desenvolvedores se responsabilizem pela entrega da meta. Na segunda parte o time detalha os itens do  product backlog em tarefas, gerando o sprint backlog, ou seja as tarefas que devem ser realizadas para que a meta seja alcançada.

b. Daily Meeting

Diariamente o time realiza uma reunião de 15 minutos na qual cada um deve responder: O que fiz desde a última reunião? O que pretendo fazer até a próxima? Tive algum impedimento?

Através desta reunião o time ganha visibilidade de como está o caminho para a meta e planeja o dia seguinte de trabalho. O Scrum Maste é o facilitador, porém a reunião é para o time e não para ele, cabendo a ele apenas auxiliar na retirada de impedimentos apresentados pelo time.

c. Review Meeting

É a reunião de apresentação do resultado da sprint para o PO e interessados. O time realiza a apresentação, e o PO avalia se a meta foi atingida e dá feedbacks para o time.

d. Retrospectiva

É a reunião de lições aprendidas, facilitada pelo Scrum Master, na qual o time deve avaliar: o que foi bom na útlima sprint? O que deve ser melhorado? Quem está no controle (empresa ou time). É a reunião que representa o fechamento do ciclo PDCA (inspeção e adaptação) dentro do scrum.

4. Artefatos  do SCRUM

a. Product Backlog

É lista que contém os requisitos do projeto. Aqui temos todas as necessidades e/ou vontades do Product Owner para o projeto. Este é um artefato “vivo”, pois será priorizado e re-priorizado ao longo do projeto de acordo com a visão do P.O. Uma forma ágil de gerenciar e manter seu Product Backlog é por meio das user stories, que são cartões com a descrição do que é necessário, para quem e porque. Mas você pode utilizar outros tipos de itens pra manter seu Product Backlog (Casos de Uso, Requisitos, Especificação, etc), desde é claro que o P.O reconheça valor nesses documentos e que eles sejam claros para o time.

b. Impediment List

É a lista com os impedimentos do Time, na qual o S.M deverá trabalhar.

c. Sprint Backlog

Possui as atividades nas quais o Time vai atuar dentro de uma Sprint. Essas atividades são planejadas pelo Time durante a reunião de planejamento da Sprint. Este também é conhecido por ser representado pela Kanban, provavelmente um dos símbolos mais associados ao Scrum.

Exemplo de Kanban

d. Product e Sprint Burndown

São gráficos que mostram a tendência planejada para atendimento da Sprint / Product Backlog e como o time está evoluindo diariamente no caso da Sprint e a cada Sprint no caso do projeto.

Fluxo do Scrum

O Product Owner (PO) define a Visão do Produto, ou seja, a necessidade que deve ser atendida ao fim do projeto. O PO representa aqui os desejos do cliente, colhendo informações junto a clientes, usuário final, time, gerentes, steakeholders, etc.

O PO quebra o produto em uma lista de necessidades que precisam ser produzidas para que a visão do produto seja atingida. Essa lista é chamada de Product Backlog. O ScrumMaster pode auxiliar o PO na elaboração desta lista. O ponto mais importante é que esta lista deve ser priorizada de acordo com o ROI, ou seja os itens que geram o maior retorno de investimento para o cliente devem estar no topo, com uma granularidade pequena, para que seja possível entrar no desenvolvimento. O Scrum Maste pode auxiliar o PO neste processo.

No início de cada iteração (Sprint), o time realiza o Planning Meeting. Nessa reunião planeja-se e defini-se o que será entregue ao final da Sprint, de acordo com a priorização do Product Backlog, o Product Owner indica quais itens do PB devem ser atendidos.

O time decompõe cada item selecionado do Product Backlog em tarefas técnicas, gerando assim o Sprint Backlog.

Cada membro seleciona suas tarefas do Sprint Backlog e as estima em horas.

Durante a execução de uma Sprint, vale a Engenharia definida para o projeto.

O ScrumMaster remove impedimentos e garante a utilização do SCRUM.

O time executa as tarefas do Sprint Backlog e, caso tenha necessidade, consulta agentes externos e também o Product Owner.

Diariamente o time realiza o Daily Meeting (15 minutos), uma reunião onde cada membro deve responder:

-O que eu fiz desde a última reunião?

-O que eu pretendo fazer até a próxima reunião?

-Tive algum impedimento?

O ScrumMaster deve facilitar essa reunião e auxiliar o time, porém a reunião não é para ele, e sim para o time

Após se completar as tarefas de uma Sprint, é realizada a Review Meeting, onde o time apresenta ao Product Owner e convidados, o que foi feito.

O Product Owner vê a demonstração do produto criado e verifica se a meta da Sprint foi atingida.

Finalmente, realiza-se a reunião de Retrospectiva, facilitada pelo ScrumMaster, onde o time deve avaliar:

-          O que foi bom?

-          O que pode ser melhorado?

-          Quem está no controle?

O Product Owner pode participar, caso o time ache necessário.

Referências:

Scrum Guide: http://www.scrum.org/scrumguides/

The Zen of Scrum: Certified Scrum Master Training book, Alexando Magno

André Nascimento blog

Cantinho do Agile

Wikipedia