Introdução ao Scrum

Alan Braz Mestre - IC-Unicamp Pesquisador em Eng. Software Ágil - IBM

Email: alanbraz@gmail.com Twitter: @alanbraz Blog: alanbraz.com.br Este arquivo: alanbraz.com.br/ic/scrum.pdf

2

Chaos report

3

Maglev Chinês (MAGnetic LEVitation)

Projeto: contrução do primeiro maglev para ligar o centro empresarial de Shanghai e imediações para o aeroporto (30km em 8m)

Orçamento: US$ 1.08bi

Prazo: Jun01 – Dez03 (2 anos e 7 meses)

Resultados técnicos: finalizado no tempo, orçamento e escopo.

Resultados de negócio: inicialmente o trem rodava praticamente vazio: ROI não foi como esperado.

4

Titanic (filme de 1997)

Orçamento inicial: US$ 200 mi

Total gasto: US$ 400 mi

Data de entrega:1 ano após o previsto

Resultado: Ganhador de 11 Oscars

Receita: mais de US$ 1.8 bi

5

6

Modelo Tradicional (Cascata)

•Por que ele é tão popular?

7

Modelo Tradicional (Cascata)

•Por que ele é tão popular?•É fácil de explicar e lembrar

•Dá a ilusão de algo ordenado, contável e mensurável com marcos orientados à documentos

•Foi altamente promovido e ensinado nos cursos de Engenharia de Software

8

Características de Projetos Ágeis

9

Características de Projetos Ágeis

•Todo ano você vai visitar seus sogros em Salvador.•Você tem:•2 filhos adolescentes (13 e 17)•1 criança de 10 anos•1 bebê de 2 meses

10

Características de Projetos Ágeis•Planejar apenas o necessário• Iterações Time-boxed (intervalos fixos)•Velocidade•Rotas alternativas•Lidar com surpresas•Motivar o time•Lidar com a diferença de objetivos dos envolvidos• Iterações repetidas e sustentáveis• Infraestrutura

11

O que não é ÁgilPRECISAMOS DE MAIS 3 PROGRA-

MADORES

USE MÉTODOS ÁGEIS DE PROGRA-MAÇÃO

DESENVOLVIMENTO ÁGIL NÃO SIGNIFICA FAZER

MAIS COISAS COM MENOS PESSOAS.

ENCONTRE OUTRAS PALAVRAS QUE

SIGNIFIQUEM ISSO E ME PERGUNTE DENOVO.

NÓS VAMOS TENTAR USAR ALGO CHAMADO DESENVOLVIMENTO

ÁGIL.

OU SEJA, NÃO HÁ MAIS PLANEJAMENTO E NEM

DOCUMENTAÇÃO. APENAS COMECEM A ESCREVER CÓDIGO E

RECLAMAR.

QUE BOM QUE ISSO TEM UM NOME.

ESTE FOIO SEU

TREINA-MENTO.

12

Ágil

•Inicialmente, métodos ágeis eram conhecidos como métodos leves. •Em 2001, membros proeminentes da comunidade se reuniram em Snowbird e adotaram o nome métodos ágeisManifesto ágil - www.manifestoagil.com.br•4 valores•12 princípios e práticas•Os métodos ágeis iniciais:•Scrum (1986)•XP (1996)•Crystal Clear•Feature Driven Development•Entre outras...

The Agile Manifesto 10th Anniversary Reunion

13

Manifesto para o desenvolvimento Ágil de software

Fonte: http://manifestoagil.com.br/

Processos e ferramentasIndivíduos e

interação entre elesmais que

Documentação abrangenteSoftware em

funcionamentomais que

Negociação de contratosColaboração com

o clientemais que

Seguir um planoResponder amudanças

mais que

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

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

14

12 Princípios (1/3)

1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.

4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

15

12 Princípios (2/3)

5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa face a face.

7. Software funcional é a medida primária de progresso.

8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

16

12 Princípios (3/3)

9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

17

Em poucas palavras...

Usar feedback contínuo dos envolvidos para desenvolver código funcional com alta-qualidade através de “Histórias de Usuários” (user stories) em uma série de iterações curtas e bem delimitadas.

18

Quem são Stakeholders (envolvidos)??

•Usuários finais (quem usa)

•Financiadores (quem paga)

•Parceiros (quem ajuda)

•Time interno (quem executa)

Usar feedback contínuo dos envolvidos para desenvolver código funcional com alta-qualidade através de “Histórias de Usuários” (user stories) em uma série de iterações curtas e bem delimitadas.

19

Histórias de usuários?! (user stories)

Usar feedback contínuo dos envolvidos para desenvolver código funcional com alta-qualidade através de “Histórias de Usuários” (user stories) em uma série de iterações curtas e bem delimitadas.

20

Iterações curtas e bem delimitadas?

SW usado em hospitais e

consultórios para manter o histórico

dos pacientes.

Jeff Southerland (CTO) disse que levaram 4 anos para chegar no

ponto de “pronto, pronto, pronto, pronto”.

60 membros no timeIterações de 1

semana

Novo Release a cada 3 meses Pronto, pronto,

pronto, pronto toda semana!!!

http://www.patientkeeper.com/

Usar feedback contínuo dos envolvidos para desenvolver código funcional com alta-qualidade através de “Histórias de Usuários” (user stories) em uma série de iterações curtas e bem delimitadas.

21

Visão Geral

Ágil é uma rede de práticas que se completam. Práticas que não adicionam valor, são excluídas.

Ágil é como uma Classe AbstrataScrum, FDD, XP, DSDM, etc são metodologias que implementam Ágil

LeanOtimizar o todo

Eliminar o desperdício

ÁgilTestes Unitários Automatizados /

TDD, Melhorias contínuas, …

Iterativo

22

Lean Software Development

•Ágil•Uma filosofia que se concentra na entrega de coisas que tem valor para o cliente•Evita tudo que não agrega valor ao cliente•Não acredita no Grande Plano (Big Plan)

•Lean• Iniciado como uma forma de gerenciamento para linha de produção•Elimina TODA forma de desperdício•Envolver o cliente o mais cedo possível

levou LEAN para

Design

23

Os princípios chave

•Eliminar Desperdício •Mapear cadeias de valor•Solução Completa

•Qualidade constante•Disciplinas Fundamentais•Validação Contínua

•Postergar Comprometimento(Defer Commitment)•Manter opções em aberto•Set-Based Design

•Entrega rápida•Teoria das Filas

•Foco no aprendizado•Produto & Processo

•Respeitar as Pessoas•Times •Parceiros

•Otimizar o todo•Systems Thinking•Roadmap

Leia mais em: http://pt.wikipedia.org/wiki/Lean

24

Se coloque no lugar do cliente

Func

. Ext

ras

Mínimo NecessárioC

usto

TempoFuncionalidades Extra elevam os custos exponencialmente

Defeitos

Complexidade

Backlog = Entregas atrasadas

Tempo em Espera = Perda de $$$$

Controle de mudançasPapelada interna

25

Mito: especificar tudo no início reduz o desperdício

26

Código custa dinheiro para ser escrito e mantido

“Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won't be needed. If they write code that ultimately is not used, I will be paying for that code for the life of the system, which is typically longer than my professional life. If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain.”

-- Jeff Sutherland, CTO PatientKeeper

27March 2009

Modelo de Negócio

Questionário de decisão

ConfirmarRequisitos

ArquiteturaAlto Nível

ConcepçãoPré-ConcepçãoUser

Stories

Planejar, Desenvolver, Qualidade

ReleaseEstimate

IterationBacklog

Produtopotencialmente

entregável

2-4 Semanas

ProductBacklog

DailyScrum

Teste

Fluxo do Processo ÁgilFluxo do Processo Ágil

28

Agile Framework

SCRUM:•Equipes pequenas entre 6 e 8 pessoas

•“Backlog” define os requisitos que serão enderessados em cada Sprint

•Reunião diária de 15min. (Scrum) para discutir o trabalho do dia

Extreme Programming (XP):

•Baseado nos valores de simplicidade, comunicação, feedback, coragem e respeito

•Comece com uma solução simples e adicione complexidade através de “refatoração” (refactoring)

Unified Process:•Versão simplificada do Rational Unified Process – redução no número de disciplinas

Crystal:•Entregas frequêntes•Melhorias reflectivas (Reflective improvement)

Adaptive: •Repetição dos ciclos de Especular, Colaborar e Aprender

•Aprendizagem contínua e adaptações para alterar o estado do projeto

Feature Driven Dev.:•Listar funcionalidades•Planejamento, Design, Construção por Funcionalidade

Dynamic Systems Development Method (DSDM):•3 fases primárias: Pré-Projeto, Ciclo de vida do Projeto, Pós-Projeto

Técnicas ágeis: os métodos acima envolvem diferentes técnicas, entre elas:

Continuous integrationDesign improvement Small releasesSimple design

Static AnalysisCoding standardSustainable paceWhole team

Test-driven developmentPlanning gamePair ProgrammingRefactoring

29

Scrum

Image owned by Teivovo, Fiji Rugby, 2007

30

Origem do Scrum

31

Origem do Scrum

http://www.infoq.com/presentations/The-Roots-of-Scrum

32

The New New Product Development Game

33

Rugby?!

34

Scrum

•Foi criado também nos anos 80 e 90, primeiramente em círculos de desenvolvimento OO como uma metodologia altamente iterativa de desenvolvimento. •Os colaboradores mais conhecidos são Ken Schwaber, Jeff Sutherland, e Mike Beedle

•Concentra mais os aspectos da gerência de desenvolvimento de software, dividindo o desenvolvimento em iterações de 2 a 4 semanas (chamadas “sprints”) e aplicando uma monitoração mais próxima e um controle baseado em reuniões diárias

•Coloca muito menos ênfase em práticas de engenharia e muitos combinam suas práticas de gerência de projeto com as práticas de XP

35

Resumindo

Processo empírico de gerenciamento e controle

Inspeção e adaptação em loops de feedback Usado para gerenciar projetos desde 1990 Entrega frequente 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

36

Pilares

Tranparência qualquer tipo de informação pertinente ao negócio,

tecnologia, ou andamento do projeto deve estar visível

Inspeção monitorar o progresso dos artefatos para detectar

possíveis variações frequência não deve ser alta a ponto de burocratizar o

fluxo de trabalho

Adaptação detectado desvios inaceitáveis, ajustes devem ser feitos

para se retomar o fluxo planejado

37

Scrum framework

Sprint = Iteração

Nota: se tornou a metodologia Ágil mais utilizada pelo mercado

38

Personagens

39

40

Scrum

Entradas dos Executivos, Equipe, Clientes, Usuários

e outros Envolvidos

Dono do Produto1

(Product Owner)

Backlog doProduto2

Reunião de Planejamento

do Sprint3

Equipe de Desenvolvimento1

Backlog do Sprint2

ScrumMaster1

Retrospectivado Sprint3

Incremento Pronto2

Revisão do Sprint3

Gráfico Burndown2

Scrum Diário3

Cada24 horas

Sprint2-4

Semanas

Data de Entrega e Backlog do Sprint não sofrem alterações

após o início do Sprint

Time seleciona as de maior

prioridade que podem se

comprometer a entregar no final

do Sprint

TarefasHitórias deUsuários

ouCasos de

Uso

Lista ordenada dos requisistos 1Papel, 2Artefato, 3Evento

41

Papel dos Personagens Define os requisitos, datas e conteúdo das releases Responsável pelo ROI do produto Responsável pela manutenção e priorização do Backlog Aceita ou rejeita os resultados das Sprints

Garante que o time está funcional e produzindo Remove os impedimentos e promove a comunicação Protege time de interferências externas Garante que todos os envolvidos estão aplicando as práticas Scrum Participa das reuniões diárias, revisão e planejamento

Configuração multi-funcional Equipe de 5 a 10 participantes Seleciona os itens prioritários para o sprint backlog Tem o direito de fazer o que for preciso, dentro dos limites do projeto, para atingir os

objetivos comprometidos Participa das reuniões diárias, revisão e planejamento

42

Artefatos

43

Planejamento da IteraçãoCoordenada pelo ScrumMaster

Todos participam (Porcos e Frangos)

Entradas: Product backlog, produto atual, condições técnicas e de negócio

1. Seleciona-se os itens de maior prioridade do Backlog; declara-se o Objetivo da Iteração

2.Time transformas os itens selecionados no Iteration Backlog

Saída: Objetivo da Iteração, Iteration Backlog

Daily ScrumCoordenada pelo ScrumMaster

O time participa (frangos são opcionais)

Mesmo lugar e horário, todos os dias, 15 mins max

Responder

1. O que você fez ontem?

2. O que vai fazer hoje?

3. Tem algum impedimento?

Time atualiza o Iteration Backlog

Scrum Master atualiza Blocks List

Revisão da IteraçãoCoordenada pelo ScrumMaster

Todos participam (Porcos e Frangos)

Informal, 4 horas, informativa

Time demonstra o incremento

Todos discutem

Considera-se candidatos à componentes

Realiza-se a reflexão

Anuncia-se a próxima reunião de planejamento

Não se passa status para o ScrumMasterMas se compromete com seus colegas

Reflexão Perguntar a

cada iteração: o que devemos…

1. PARAR ?2. COMEÇAR ?3. CONTINUAR ?

Reuniões

44

Scrum Development Process

•Começa quando:•A fase de Concepção está concluída

•As histórias de alta prioridade estão quebradas ao ponto de serem possíveis de implementar em uma iteração

45

Done, done, done, done!

46

Você está Pronto, Pronto, Pronto, Pronto?

FRANKDesenvolvedor

TOMGerente de Projetos

Tom “Oi, Frank! – Você já terminou aquela funcionalidade nova?”

Frank“Humm um segundo …… Pronto. E eu só levei meio dia para terminar”

Tom“Wow, impressionante! Nós estimamos que levaria no mínimo 1 dia, 2 provavelmente. Posso dar uma olhada??”

Frank “Bem, ainda não. Eu não integrei o novo código ainda.”

Tom

“OK – Mas quando você tiver feito isso, eu poderei dar uma olhada certo? Estou ansioso para mostrar aos clientes. Eles nos contrataram especialmente por causa desta funcionalidade. Eu vou instalar a novabuild no ambiente de testes deles assim eles podem dar uma brincada.”

Frank“Bem, eu não mostraria isso a ninguém. Eu não testei ainda e você não conseguirá instalar em lugar algum. Eu não atualizei o instalador e nem os scripts de atualização do banco de dados.”

Tom“Não estou entendendo. Pensei ter ouvido você dizer que estava pronto!”

Frank“E esta! ….Eu terminei de codificar no exato momento que você ligou. Veja, eu vou te mostrar.”

Tom“Não, não, eu não quero ver código... Eu preciso ter a capacidade de mostrar isso pro cliente. Eu preciso dela terminada, realmente terminada!”

Frank“Ahhh bom, por que você não disse logo? O código está pronto, mas não está pronto, pronto, pronto, pronto! Me dê mais alguns dias que eu finalizo isso.”

47

Dívida Técnico (Technical Debit)

Copyright 1996-2007, ADM, All Rights Reserved v8.0

Time

Bug

Bac

klog

Iterative Waterfall

Dívida Técnico é uma metáfora para nos ajudar

a pensar sobre o problema de empurrar

código não terminado de uma iteração para a

próxima.

48

Scrum

Entradas dos Executivos, Equipe, Clientes, Usuários

e outros Envolvidos

Dono do Produto1

(Product Owner)

Backlog doProduto2

Reunião de Planejamento

do Sprint3

Equipe de Desenvolvimento1

Backlog do Sprint2

ScrumMaster1

Retrospectivado Sprint3

Incremento Pronto2

Revisão do Sprint3

Gráfico Burndown2

Scrum Diário3

Cada24 horas

Sprint2-4

Semanas

Data de Entrega e Backlog do Sprint não sofrem alterações

após o início do Sprint

Time seleciona as de maior

prioridade que podem se

comprometer a entregar no final

do Sprint

TarefasHitórias deUsuários

ouCasos de

Uso

Lista ordenada dos requisistos 1Papel, 2Artefato, 3Evento

49

50

Product Backlog

•O Backlog do Produto é um repositório das Histórias de Usuários que estão prontas para ser implementadas em uma iteração

Product Backlog

User Story

51

User Stories

•Uma User Story descreve uma funcionalidade que tem alguma utilidade para um stakeholder do sistema.

•User Stories são compostas por:•Uma breve descrição•Conversação sobre a história•Testes de aceitação e alguns detalhes

52

User Story – os 3 Cs

53

Como um <Papel>, eu quero <Objetivo> para que eu <valor de negócio>.

User Stories: Cartão: Descrição breve

•Com um DBA do Wal*Mart, eu quero reduzir o consumo de armazenamento para que eu gerencie um menor número de dispositivos.

•Como um administrador, eu quero que provar que apenas os clientes pré-cadastrados possam usar um determinado serviço para que eu possa controlar a segurança dos dados.

54

User Stories: Conversação

•Atenção: é aqui que o real valor da história aparecerá

•Inclua o máximo de pessoas possíveis.•Garanta que representantes de todas as disciplinas estejam presentes: desenvolvedores, analistas, testes, gerentes de projetos, arquitetos, DBAs, etc

55

Com um DBA do Wal*Mart, eu quero reduzir o consumo de armazenamento para que eu gerencie um menor número de dispositivos.

•Taxa de compressão > 50%

•Compressão de todos os tipos de tabelas

•Compressão online

User Stories: Confirmação

•As condições de satisfação do Product Owner devem ser adicionadas na história.•Devem ser facilmente testadas e de resultado binário Sim ou Não.•Vão determinar se a história foi concluída com sucesso.•Não existe parcialmente finalizado ou terminado mas...

Lembre-se: isso não é uma história interna do time

56

Quebrando histórias em outras menores

Como um usuário, eu quero poder cancelar uma reserva, para que eu não seja penalizado com multa em uma viagem não mais necessária.

Como um usuário gold, eu quero poder cancelar uma reserva no último minuto sem pagamento de multa para que eu não seja penalizado por uma viagem não mais necessária.

Como um usuário cadastrado, eu quero poder cancelar uma reserva com 24h de antecedência para que eu não seja penalizado por uma viagem não mais necessária.

Como um visitante, eu quero receber a confirmação de qualquer cancelamento para que eu possa guardar um comprovante

57

O que faz uma boa história?

•Independente

•Negociável

•Com Valor

•Estimável

•Tamanho apropriado

•Testável

58

• Tarefa #1 (X horas)

• Tarefa #2 (Y horas)

• Tarefa #3 (Z horas)

User Story Máximo de 16 horas ideais por

tarefa

User Stories em tarefas

•Durante o planejamento da iteração as histórias devem ser quebradas em tarefas

59

Product Backlog é do Product Owner

•Lista a histórias a serem implementadas•Priorizadas de Alta para Baixa•Utiliza conhecimento técnico para ajudar na priorização•Esta sempre uma iteração à frente dos desenvolvedores

•Foca no top 20%, apesar que deve ser revista inteiramente de tempos em tempos•Itens de baixa prioridade devem ser consolidados•Itens de muito baixa prioridade devem ser descartados•Se for importante, elas voltam naturalmente

60

Aprender a priorizar - MoSCoW

•M – MUST HAVE•Highest priority

•S – SHOULD HAVE •Desirable to have

•C – COULD HAVE•Nice-to-have

•W – WON’T HAVE•Out of scope for this release

61

1

2

3

4

5

6

7

8

9

…

N

Priorizar de 1 a N

62

Resumindo

•O Product backlog é a lista de trabalho a ser implementado•Pertence e é priorizado pelo Product Owner•Priorização na forma MoSCoW seguindo ordem numérica

6363

Por que os planos dão errado?

Assume-se que tarefas são independentes

Atrasos impactam o cronograma, adiantamentos não

A síndrome do estudante

Multi-tarefas está implícitoe é necessário

6464

1. Assumimos que as tarefas são independentes

Muitas tarefas tem dependências entre si. •Estimativas erradas geram uma cadeia de atrasos em outras tarefas

Conforme temos mais conhecimento sobre os requisitos, voltamos e atualizamos nossas estimativas

Estimativas de Software não seguem uma distribuição normal

6565

2. Atrasos impactam o cronograma

Tarefa 3 inicia:ATRASADO se 1, 2 ou 4 estiver atrasadaANTES apenas se 2 e 4 terminar antes e tiver recurso disponível

6666

3. Síndrome do Estudante

Definição Iniciar uma tarefa no

último momento possível que não prejudicará a data de entrega

Exemplo: Começar a fazer o

trabalho da pós na sexta à noite :D

6767

O que ocorre?

Fonte: http://www.heptagon.com.br/5dgp-3

6868

6969

4. Multitasking – Multi-tarefas

Multi-tarefas causam atrasos

Ao invés de multi-tarefar, use unidades de trabalho menoresDeixar o fluxo de trabalho acontecer o mais rápido possívelTransferências mais eficientes para outra pessoa

7070

O efeito das multi-tarefas

7171

A cebola do planejamento

7272

Planejando o Produto, as releases, e as iterações

7373

Medidas

7474

Story Points

É a “grandeza” de uma tarefa Influenciada por

•Quão difícil ela é•O quanto dela já temos

Valores são relativos•Tela de login é 2•Funcionalidade de busca é 8

Isentos de unidade

7575

Tempo Ideal

Quanto tempo demoraria se...•Você trabalhasse exclusivamente nisto•Não houvessem interrupções•E tudo que você precisa estiver disponível

O Tempo Ideal de uma partida de Basquete é 48 minutos•12 minutos por quarto

Mas o tempo corrido é muito maior•Normalmente 3 horas

7676

3 níveis de planejamento...

7777

...com 3 níveis de precisãoStory Points

Horas Ideais

Comprometimento diário

7878

Estimar por analogia

•Comparando uma User Story com outras•“Esta história é parecida com aquela outra, então suas estimativas serão as mesmas.”

•Não use um único padrão•Usar Triangulação •Comparar a história a ser estimada com todas as outras, já estimadas, três a três

7979

Triangulação

13

5

•Confirmar as estimativas comparando com múltiplas histórias•Agrupar histórias parecidas em uma tabela ou quadro

8080

Desagregações

•Quebrar um história grande em menores•Como saber se uma história está pequena o suficiente?•É mais fácil de estimar coisas menores

•Mas quebrar muito pode gerar problemas•Histórias se perdem no caminho (muitas histórias para gerenciar)

8181

Esforço

Pre

cisão

Investigar quanto esforço?

•Um pouco de esforço ajuda muito•Muito esforço apenas ajuda um pouco mais

8282

Usar as unidades corretas

•Conseguimos distinguir 1 story point de um 2?•Conseguimos distinguir um 17 de um 18?•Use unidade que façam sentido, como:•1, 2, 3, 5, 8, 13 - Fibonacci•1, 2, 4, 8, 16, 32 - potência de 2

•Se a história cabe em uma iteração ela “pesa” de 1 a 13•Maiores que uma iteração: 20, 40, 100 or ∞•Preciso de mais informações: ?

Incluir o 0 e ½ se desejar

8383

Planning Poker

• Processo Iterativos de Estimativas• Passos:

1. Cada estimador tem um conjunto de cartas, cada carta tem um valor de estimativa válido

2. Cliente/Product Owner lê a História e ocorre uma breve discussão

3. Cada estimador seleciona uma carta que será a sua estimativa particular

4. Todos viram as cartas ao mesmo tempo5. Estimadores com valores no extremos

(mais baixo e mais alto) apresentam brevemente seus pontos de vista

6. Repete-se os passos até convergir a um único valor

8484

Quadro de Tarefas

8585

Kanban

8686

http://taskboard.agilar.org

kunagi.org

8888

Burndown charts

•Método primário de monitorar o progresso•Um Burndown chart mostra o quanto de trabalho falta ser realizado•Dois tipos•Release burndown•Sprint burndown

Lembre-se: Iteration = Sprint

8989

Iteration/Sprint burndown chart

9090

Apenas o que falta para trabalhar

Nota: no máximo 16 horas ideias por tarefa

9191

Quando o projeto será entregue?

Iteration = Sprint

4 lições:

1. Mostra progresso

2. Levanta questões, e não as responde

3. Antecipa discussões

4. Impossibilita a mentira

Sto

ry P

oin

ts

9292

Resumindo

•Velocidade e burndown charts são pontos cruciais para monitorar as releases e iterações

•Monitorar iterações com um quadro de tarefas (real ou virtual)

•Manter a monitoração simples e acessível ao time, para que cada um possa fazer as atualizações

93

Scrum

Entradas dos Executivos, Equipe, Clientes, Usuários

e outros Envolvidos

Dono do Produto1

(Product Owner)

Backlog doProduto2

Reunião de Planejamento

do Sprint3

Equipe de Desenvolvimento1

Backlog do Sprint2

ScrumMaster1

Retrospectivado Sprint3

Incremento Pronto2

Revisão do Sprint3

Gráfico Burndown2

Scrum Diário3

Cada24 horas

Sprint2-4

Semanas

Data de Entrega e Backlog do Sprint não sofrem alterações

após o início do Sprint

Time seleciona as de maior

prioridade que podem se

comprometer a entregar no final

do Sprint

TarefasHitórias deUsuários

ouCasos de

Uso

Lista ordenada dos requisistos 1Papel, 2Artefato, 3Evento

94

Referências

Takeuchi, Hirotaka; Nonaka, Ikujiro. "The New New Product Development Game". Harvard Business Review. 1986

Ken Schwaber and Mike Beedle. Agile Software Development with Scrum. Prentice Hall, Upper Saddle River, New Jersey, 2002.

Ken Schwaber. SCRUM Development Process. OOPSLA’95 Workshop on Business Object Design and Implementation, 1995.

Mary Poppendieck and Tom Poppendieck. Lean Software Development: An Agile Toolkit. Addison-Wesley, 2003.

Agile Manifesto – http://agilemanifesto.org/iso/ptbr/ Scrum Guide - versão de 2011 em português Video: Scrum Master in Under 10 Minutes NEW Scrum Master in Under 10 Minutes video

95

Referências

Scrum from the Trenches – livro com exemplo de implantação de Scrum (Português – Inglês)

Coletânea de Papers acadêmicos de Jeff Sutherland State of Agile Development Survey Results Disciplined Agile Delivery Ferramenta para gerenciamento usando

Scrum – Rational Team Concert, grátis para 10 usuários no jazz.net