Douglas Xavier, Joffily Ferreira, Maria Aparecida, Marianna Veríssimo, Natanael Guedes

Quebra de paradigma

“a maior parte do desenvolvimento de software era feita usando o método em cascata, no qual um projeto era concluído em todos os estágios distintos e seguia, passo a passo, em direção ao lançamento para os consumidores, ou usuários”. (SUTHERLAND, 2014).

Metodologia Scrum

 

Flexível, adaptativa e Evolucionária

Pouca documentação

Aplicada em grupos pequenos

Detecção e correção de erros imediatos (Aprendizagem)

Hiperprodutividade (300% a 400%)

Multifuncionalidade e autogestão

Horizontalizada, particionada e distribuída 

Metodologias prescritivas

 

Rigorosas e restritivas

Excesso de documentação

Aplicadas  em grupos grandes

Sujeitas a erros continuados


Baixa produtividade e atrasos

Cargos e funções estritos

Aplicadas de cima para baixo

X

A gestação da metodologia
 

1993 – Nasce o Scrum


Os pais do Scrum...

Jeff Sutherland
Ken Schwaber


Nada se cria, tudo se copia:

Taiichi Ohno => Sistema Toyota de Produção (Toytismo)

Hirotaka Takeuchi e Ikujiro Nonaka => Melhores práticas (HP, Honda, 3M, Xerox)
W. Edwards Deming => PDCA
Rúgbi => Scrum: estrutura de desempenho em equipe

Background (Jeff Sutherland):
Experiência como piloto militar de combate
MidContinent => ATM de sistema bancário
Easel => Scrum original

Qual a filosofia do Scrum?

Pessoas em vez de processos

Produtos que realmente funcionem em vez de documentação dizendo como o produto deveria funcionar

Trabalhar com os clientes em vez de negociar com eles

Responder às mudanças em vez de seguir um plano.

“Quando eu me sentei para desenvolver o Scrum, não tinha a menor intenção de criar um novo “processo”. Meu projeto era apenas juntar toda a pesquisa que tinha sido feita durante décadas e selecionar o que havia de mais interessante e útil naquilo. Queria incorporar as melhores práticas e “roubar” qualquer uma das boas ideias com as quais eu me deparasse”

 

“O motivo por que ela funciona é simples. Eu olhei a forma como as pessoas realmente trabalham, em vez de como elas dizem que trabalham. Analisei uma pesquisa realizada por décadas e as melhores práticas de empresas em todo o mundo, analisei mais a fundo as melhores equipes nessas empresas”

 

 

(SUTHERLAND, 2014).

Características
 

Segundo Ken Schwaber, o Scrum baseia-se em 6 características:
 

1 – Flexibilidade de resultados;

2 – Flexibilidade de prazos;

3 – Times pequenos;

4 – Revisões frequentes;

5 – Colaboração;

6 – Orientação a objetos.

Podemos usar Scrum para:

1 – Desenvolvimentos complexos em que os requisitos mudam rapidamente e constantemente;

2 – Gerenciar e controlar o desenvolvimento do trabalho;

3 – Tornar a equipe auto gerenciável e funcional;

4 – Implementar o conceito iterativo e incremental no desenvolvimento de software e/ou produtos;

5 – Identificar causas de problemas e remover impedimentos;

6 – Valorizar os indivíduos.

SCRUM

Papéis

Artefatos

Cerimônias

Fundamentos básicos

Ciclo de desenvolvimento

Product Backlog

Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software.

O Sprint Backlog é uma lista de tarefas que o Scrum se compromete a fazer em um Sprint(tempo). No Scrum, o trabalho é realizado em iterações ou ciclos de até um mês de calendário chamado de Sprints. Todos os dias, de duas a quatro semanas, no mesmos horários, os membros da equipe de desenvolvimento devem realizar uma reunião com tempo definido (15 minutos ou menos).

Produto increment – produto ou funcionalidade concluída.

Sprints

É um esforço dentro de uma caixa de tempo que não pode ser alterada até sua conclusão.

É retro alimentada pelo backlog do produto.

Sempre visa a entrega de um produto com valor para o cliente.

Cada sprint é uma interação.

Papéis

O Scrum possui quatro papéis, sendo o Product Owner, o Scrum Master, o Team e o cliente

Product Owner

Representa o cliente e é responsável por garantir que a equipe Scrum agregue valor ao negócio.

Desempenha o papel de moderador entre os interesses do cliente e do Team, mantendo a equipe funcional e produtiva. 

Responsabilidades do Product Owner

1 – Definir a visão e as funcionalidades do produto;

2 – Definir as prioridades;

3 – Elaborar e manter o Product Backlog;

4 – Definir as prioridades e o ROI(Return of Investment);

5 – Decidir sobre as datas de lançamento do produto;

6 – Representar o cliente (quando não está presente);

7 – Aceitar ou rejeitar os resultados dos trabalhos.

Scrum Master

Representa o cliente no projeto e desempenha um papel importante de facilitador, responsável pela remoção de impedimentos que eventualmente surjam durante o desenrolar do desenvolvimento. 

Responsabilidades do Scrum Master

1 – Desempenhar papel de lider, representando a gerência de projeto;

2 – Remover impedimentos;

3 – Proteger a equipe Scrum;

4 – Ajudar o Product Owner com o Product Backlog;

5 – Ser facilitador da equipe Scrum, garantindo sua plena produtividade;

6 – Garantir a colaboração entre os diversos papéis e funções;

7 – Atuar como escudo para interferências externas;

8 - Aplicar os valores e práticas Scrum.

Team

Time responsável pelo desenvolvimento do projeto, composto geralmente de um grupo de 5 a 9 integrantes, que deve possuir uma característica multifuncional. 

Preferencialmente não devem possuir títulos e os integrantes só devem ser trocados ao fim da sprint

Responsabilidades do Team

1 – Desenvolver o produto;

2 – Garantir a qualidade do produto;

3 – Apresentar o produto ao cliente.

Cliente

O cliente deve participar de tarefas relacionadas à implementação da lista de funcionalidades e atuar ao longo de desenvolvimento do projeto por meio de análises periódicas dos subprodutos gerados.

Cerimônias

São reuniões que ocorrem em momentos diferentes de uma determinada sprint. 

1 - Planejamento da Sprint (Sprint Planning Meeting);

2 - Reunião diária (Daily Meeting ou Daily Scrum);

3 - Revisão da Sprint (Sprint Review);

4 - Retrospectiva da Sprint (Sprint Retrospective);

Planejamento da Sprint ou Sprint Planning Meeting

É a primeira reunião do projeto e todos precisam participar, deve possuir uma duração máxima de 8 horas. Nesta reunião o Product Owner planeja e elabora a lista de prioridades que devem ser cumpridas no projeto, dividindo a reunião em duas partes:

 

Parte 1: O Product Owner define as prioridades, seleciona os itens do backlog e a meta do sprint.

Parte 2: A equipe define a sprint backlog, que é o documento que contém as tarefas necessárias para cumprir a meta.

Reunião diária ou Daily Scrum

Reunião diária de tempo fixo de 15 minutos, onde a equipe de desenvolvimento atualiza os outros sobre o andamento e planos relativos ao projeto.

Cada membro do time deve responder três perguntas: 

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

2 - O que eu vou fazer até a próxima;

3 - Tive ou estou tendo algum impedimento? Quais?

Revisão da sprint ou Sprint Review

Reunião de balanço sobre tudo o que foi feito durante uma sprint. Nessa reunião, o time apresenta o resultado da sprint para o Product Owner e seus convidados. Apenas o itens 100% prontos são apresentados. 

 

Após a reunião o Product Owner tem o direito de aceitar ou não a sprint com base no que foi apresentado. 

Retrospectiva da sprint ou Sprint Retrospective

Reunião que dura aproximadamente 3 horas, acontecendo sempre ao final de cada sprint.

Esta é uma reunião onde o Team Scrum deve responder basicamente duas perguntas:

O que foi bom durante a sprint e o que pode ser melhorado na próxima sprint. 

Artefatos

Tudo aquilo é produzido durante a fase de desenvolvimento do projeto, como: especificação de requisitos, documentos de projeto, planos de teste, revisão do código, e outros

De maneira geral, têm objetivo de representar uma visão do produto.

 

Tipos de artefatos no SCRUM

1 –  Backlog de produto;

2 – Backlog de sprint;

3 – Burndown chart.

Backlog de produto

Representa a visão do produto de forma modular, contendo todos os itens a serem desenvolvidos durante o projeto.

Lista de prioridades feitas no inicio do projeto.

 

Objetivo: elencar o que deve ser entregue para o cliente

 

Deve ser criado e mantido pelo Product Owner que pode alterar esse documento quando quiser exceto se a sprint já está sendo desenvolvida no momento.

Os itens são priorizados em função ROI (Return of Investment) – os que apresentam maior valor para o negócio devem ser desenvolvidos primeiro.

Figura X – Exemplo de conteúdo de um Product Backlog

Backlog de sprint

Representa todas as tarefas que devem ser desenvolvidas durante a sprint ou iteração.

Cada item deve ser detalhado em tarefas e cada uma dessas tarefas deve ter uma estimativa de esforço, neste caso, em horas.

Objetivo de dar visibilidade
ao andamento das tarefas.

Representado em função ROI.

Task Board

Utilizado para acompanhamento das sprints, principalmente durante as reuniões diárias.

Observar o andamento
do projeto de maneira clara e intuitiva.

 

Gráfico Burndown

Tem como objetivo mostrar o esforço restante para a conclusão da iteração bem como mostrar quão próximo ou distante o time está de atingir a meta

A linha azul indica o fluxo ideal de trabalho.

A metodologia prega que esse gráfico deve ser atualizado diariamente.

Referências

Metodologia ágeis: engenharia de software sob medida/ José Henrique Teixeira de Carvalho Sbrocco, Paulo Cesar de Macedo. --1. ed. -- São Paulo: Érica,2012.

SUTHERLAND, Jeff. Scrum - A arte de fazer o dobro do trabalho na metade do tempo. São Paulo: Leya, 2014.

Scrum

By Marianna Veríssimo

Scrum

We will present how the agile method works in concept.

  • 577