Scrum

A verdade sobre projetos O Standish Group vem, há mais de uma década,

realizando estudos em volta dos resultados dos projetos de software ao redor do mundo. O resultado destes estudos é um relatório batizado de Chaos Report;

Chaos Report

Segundo o Standish Group o Chaos Report revela que:

Em média, os atrasos representaram 63% mais tempo do que o estimado;

Os projetos que não cumpriram o orçamento custaram em média 45% mais;

No geral, apenas 67% das funcionalidades prometidas foram efetivamente entregues;

Chaos Report Quais os principais fatores para um número ainda tão

alto de projetos que não alcançam seu objetivo?

A vasta maioria dos projetos de software falha por: Falta de clareza – sobre funções pessoais,

responsabilidades e requisitos; E também por inabilidade para acompanhar o que

ocorre em cada um dos diferentes passos do ciclo de vida da aplicação;

Telefone sem fio?

Uso de funcionalidades

Resumindo A comunicação entre as partes envolvidas nos

projetos é muito fraca; A visibilidade do andamento real e dos problemas

existentes nos projetos é muito fraca; Clientes pedem sempre mais do que realmente

precisam; Os projetos são caros e, ainda em sua maioria, não

alcançam sucesso; Os conflitos existentes entre TI e negócios durante os

projetos são muitos;

Origem do Scrum

Origem do Scrum

Um grupo composto de grandes nomes do mundo do software, tais como: Kent Beck, Jim Highsmith, Alistair Cockburn, Martin Fowler, Ken Shwaber e Jeff Sutherland.

Criaram o Manifesto Ágil.

http://agilemanifesto.org/

Manifesto Ágil

Indivíduos e interações MAIS QUE processos e ferramentas

Produto funcionando MAIS QUE documentação abrangente

Responder a mudanças MAIS QUE seguir um plano

Colaboração com o cliente MAIS QUE negociação de contratos

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

http://agilemanifesto.org

O que não é Scrum…

SCRUMbut

É uma anomalia. É fazer o Scrum de uma forma errada. Mal feito, mal

implementado. Quando o Scrum mostra os erros e as empresas

removem ou alteram o framework ao invés de tentar corrigir os erros.

O que é Scrum? Processo empírico de gerenciamento e controle;

Inspeção e adaptação em loops de feedback;

Usado para gerenciar projetos desde 1990;

Entrega freqüente de funcionalidades com valor para o

cliente;

Escalável a projetos distribuídos, grandes e largos;

Compatível com CMMI Nível 3 e ISO9001;

Extremamente simples, mas resistente;

Processo Empírico

O que é Scrum? É um processo iterativo e incremental para o

desenvolvimento de qualquer produto e gerenciamento de qualquer projeto;

É mais um framework que uma metodologia, mais atitute que um processo;

Não diz em mínimos detalhes como fazer, mas fornece boas práticas para serem seguidas com o objetivo de maximizar o sucesso nos projetos;

Incremental e Iterativo

Princípios Satisfação do cliente Mudança Entregas constantes Colaboração Motivação Ambiente adequado Comunicação face a face Software funcionando Ritmo sustentável Simplicidade Melhoria contínua

Porcos e Galinhas

Baseados nesta historinha, costumamos dizer que existem dois tipos de pessoas em projetos Scrum:

Galinhas: Apenas envolvidas com o projeto;Porcos: Totalmente comprometidos com o projeto;

Papéis no Scrum• Product Owner (MACRO Gerenciamento)

Responsável por garantir o ROI (Retorno de Investimento);

Responsável por conhecer as necessidades do(s) cliente(s);

Proxy em ambientes com mais de um cliente;

• Scrum Master (Gerenciamento do PROCESSO) Responsável por remover os impedimentos do time;

Responsável por garantir o uso de Scrum;

Protege o time de interferências externas;

• Time (MICRO Gerenciamento)Multi-disciplinar;Auto-gerenciado;Produzir produto com qualidade e valor para o cliente;

Time Scrum

Product Owner

TimeTimeTime

Time Time

Scrum Master

Fluxo do Scrum

VisãoÉ o que representa a necessidade do cliente, é o que

deve ser satisfeito ao fim de um determinado projeto. Sendo que:

O Product Owner é o responsável pela criação da visão;

Para definir essa visão o Product Owner colhe informações junto a clientes, usuários finais, membros do time, gerentes, stakeholders, executivos, etc;

Ele compartilha essa visão com o Time; Ele refina essa visão com o Time;

Product BacklogÉ a lista de necessidades que precisam ser produzidas para que a Visão do

produto seja atingida. O Product Backlog deve seguir as seguintes regras:

Deve ser apresentado no formato de uma lista com itens priorizados e ordenados de acordo com o valor que representam para o cliente e negócio.

Apenas um Product Backlog deve existir por projeto. O Product Backlog irá existir por todo o ciclo de vida do projeto (e não

da sprint); O Product Owner é o responsável pelo conteúdo do Product Backlog,

sua disponibilidade e sua priorização; O Product Backlog deve ser atualizado pelo Product Owner para refletir

as mudanças e necessidades do cliente, mudanças estratégicas ou tecnológicas, novas idéias, enfim... mudanças;

Enquanto existir um produto, o Product Backlog também existe; O Scrum Master deve auxiliar o PO na elaboração do Product Backlog;

Sprint Planning Meeting

É a reunião realizada para planejar a próxima Sprint, esta reunião deve ter duração de aproximadamente 5% do tamanho total da Sprint e deve ser dividida em duas partes.

Sprint Planning 1

Sprint Planning 1

O Product Owner apresenta os itens de maior prioridade do Product Backlog ao time;

Product Owner e Time trabalham em conjunto para descobrir qual funcionalidade deverá ser desenvolvida durante o próximo Sprint;

A decisão referente à quantidade de itens que o Time seleciona cabe somente ao Time, somente o Time pode saber o que ele é capaz de realizar no próximo Sprint;

O Product Owner tira dúvidas sobre os itens selecionados; O Product Owner em conjunto com o Time definem a Meta da

Sprint; A Meta da Sprint é uma descrição que fornece orientação ao

Time sobre a razão pela qual ele está produzindo o incremento; O resultado da Sprint Planning 1 é o Selected Backlog;

Sprint Planning 2

Sprint Planning 2

O Time analisa e identifica quais tarefas são necessárias para transformar os Itens do Backlog selecionados na primeira parte da reunião em software funcional;

As tarefas devem ser decompostas (quebradas) de forma que possam ser feitas em menos de um dia (8 horas);

Essa lista de tarefas é chamada de Sprint Backlog; O Product Owner deve estar presente nessa parte da reunião

para esclarecer dúvidas sobre os itens do Product Backlog e para ajudar a efetuar mudanças, caso estas sejam necessárias;

Se o Time determinar que há muito ou pouco trabalho, ele pode renegociar o Selected Backlog com o Product Owner;

Sprint Planning Meeting

Parte IIParte IIParte IParte I

Ajuste de prioridades

Determinar velocidade

Identificar a meta da

Sprint

Selecionar Itens do Backlog

Quebrar Itens em tarefas

Estimar tarefas

Sprint Backlog

Sprint Backlog é o resultado da Sprint Planning Meeting, ele é composto por:

Itens de Backlog selecionados; Tarefas definidas para cada Item de Backlog; Meta da Sprint;

Sprint

A Sprint é um Time-Box de 2 a 4 semanas no qual o time do projeto deverá produzir um incremento potencialmente entregável do produto, com alta qualidade, testado, completo e pronto. Para isso é necessário seguir as seguintes regras:

Ter uma meta clara e objetiva; Duração de 2 a 4 semanas; Nenhuma mudança no Sprint Backlog; Local e horário definido para a reunião diária; Disponibilidade de cada membro da equipe; Data definida para a apresentação da sprint;

Daily Meeting

A Daily Meeting é uma reunião diária de 15 minutos na qual cada membro deve responder:

O que fiz desde a última reunião? O que pretendo fazer até a próxima reunião? Tive (estou tento) algum obstáculo/impedimento?

Todos em pé; Sincronização do conhecimento; Atualização dos charts; Não é para a solução de problemas; Todo mundo é convidado:

– Apenas Equipe, ScrumMaster e Product Owner podem falar;

Sprint Review

É a reunião realizada ao final da Sprint, e tem como propósito apresentar o que foi feito para o Product Owner e convidados. Ela deve ter duração máxima de 2,5% do tamanho total da Sprint, e deve incluir ao menos os seguintes elementos:

O Time demonstra o trabalho que foi feito e responde a questionamentos;

A demonstração deve ser feita em formato de demo no sistema e nunca em apresentações (ppt);

O Product Owner identifica o que foi feito e o que não foi feito, e avalia se a meta da sprint foi alcançada;

O Time discute o que correu bem durante a Sprint e quais problemas foram enfrentados, e também como esses problemas foram resolvidos;

O Product Owner então discute o Product Backlog da maneira que este se encontra. Ele faz projeções de datas de conclusão com várias hipóteses de velocidade;

O grupo inteiro colabora com o que viu e o que isso significa com relação ao que fazer em seguida;

Retrospective Meeting

É a reunião realizada após a Sprint Review, e tem como propósito a reflexão e o aprendizado, ou seja a inspeção e adaptação dentro do Scrum. Ela deve ter duração máxima de 2,5% do tamanho total da Sprint, e deve seguir as seguintes regras:

O Scrum Master deve encorajar o Time a revisar o processo de trabalho, tendo como base o processo de modelo de trabalho e práticas Scrum, de forma a torna-lo mais eficaz e agradável para o próximo Sprint;

A finalidade da Reunião de Retrospectiva é inspecionar como correu a última Sprint em se tratando de pessoas, relações entre elas, processos e ferramentas;

A inspeção deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores;

Isso inclui a composição do time, preparativos para reuniões, ferramentas, definição de pronto (done), métodos de comunicação, e processos para transformar itens do Product Backlog em alguma coisa “feita”;

No final da Reunião de Retrospectiva, o Time Scrum deve ter identificado medidas de melhoria que implementará na próxima Sprint. Essas mudanças se tornam a adaptação para a inspeção empírica;

Agora vocês explicam

Hotel para CachorroUm investidor, com intenção de abrir um

hotel para cachorro precisa montar um panfleto divulgando seu novo negócio.

Sabendo disso vamos:- Entrevistar o investidor;- Levantar os itens necessários;- Quebrar os itens em tarefas;- Desenvolver o panfleto;- Apresentar o produto final;