Introdução ao Scrum - ic.unicamp.brariadne/mc436/1s2014/Scrum-Alan.pdf · Introdução ao Scrum...
Transcript of Introdução ao Scrum - ic.unicamp.brariadne/mc436/1s2014/Scrum-Alan.pdf · Introdução ao Scrum...
Introdução ao Scrum
Alan Braz Mestre - IC-Unicamp Pesquisador em Eng. Software Ágil - IBM
Email: [email protected] Twitter: @alanbraz Blog: alanbraz.com.br Este arquivo: alanbraz.com.br/ic/scrum.pdf
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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