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

Transcrição

1 Introdução ao Scrum Alan Braz Mestre - IC-Unicamp Pesquisador em Eng. Software Ágil - IBM alanbraz@gmail.com Blog: alanbraz.com.br Este arquivo: alanbraz.com.br/ic/scrum.pdf

2 Chaos report 2

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. 3

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 4

5 5

6 Modelo Tradicional (Cascata) Por que ele é tão popular? 6

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 7

8 Características de Projetos Ágeis 8

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 9

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 10

11 O que não é Ágil PRECISAMOS DE MAIS 3 PROGRAMADORES USE MÉTODOS ÁGEIS DE PROGRAMAÇÃO DESENVOLVIMENTO ÁGIL NÃO SIGNIFICA FAZER MAIS COISAS COM MENOS PESSOAS. NÓS VAMOS TENTAR USAR ALGO CHAMADO DESENVOLVIMENTO ÁGIL. ENCONTRE OUTRAS PALAVRAS QUE SIGNIFIQUEM ISSO E ME PERGUNTE DENOVO. 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 FOI O SEU TREINAMENTO. 11

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 ágeis Manifesto ágil 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 12

13 Manifesto para o desenvolvimento Ágil de software 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: Indivíduos e interação entre eles mais que Processos e ferramentas Software em funcionamento mais que Documentação abrangente Colaboração com o cliente mais que Negociação de contratos Responder a mudanças mais que Seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. Fonte: 13

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. 14

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. 15

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. 16

17 Em poucas palavras... Usar feedback contínuo dos envolvidos para desenvolver código funcional com altaqualidade através de Histórias de Usuários (user stories) em uma série de iterações curtas e bem delimitadas. 17

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 altaqualidade através de Histórias de Usuários (user stories) em uma série de iterações curtas e bem delimitadas. 18

19 Histórias de usuários?! (user stories) Usar feedback contínuo dos envolvidos para desenvolver código funcional com altaqualidade através de Histórias de Usuários (user stories) em uma série de iterações curtas e bem delimitadas. 19

20 Iterações curtas e bem delimitadas? SW usado em hospitais e consultórios para manter o histórico dos pacientes. Novo Release a cada 3 meses Jeff Southerland (CTO) disse que levaram 4 anos para chegar no ponto de pronto, pronto, pronto, pronto. Iterações de 1 semana Pronto, pronto, pronto, pronto toda semana!!! 60 membros no time Usar feedback contínuo dos envolvidos para desenvolver código funcional com altaqualidade através de Histórias de Usuários (user stories) em uma série de iterações curtas e bem delimitadas. 20

21 Visão Geral Lean Otimizar o todo Eliminar o desperdício Ágil Testes Unitários Automatizados / TDD, Melhorias contínuas, Iterativo Ágil é uma rede de práticas que se completam. Práticas que não adicionam valor, são excluídas. Ágil é como uma Classe Abstrata Scrum, FDD, XP, DSDM, etc são metodologias que implementam Ágil 21

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 levou LEAN para Design 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 22

23 Os princípios chave Eliminar Desperdício Mapear cadeias de valor Solução Completa Entrega rápida Teoria das Filas Foco no aprendizado Qualidade constante Disciplinas Fundamentais Validação Contínua Postergar Comprometimento (Defer Commitment) Manter opções em aberto Set-Based Design Produto & Processo Respeitar as Pessoas Times Parceiros Otimizar o todo Systems Thinking Roadmap Leia mais em: 23

24 Se coloque no lugar do cliente Papelada interna Controle de mudanças Fu nc.e xt r Custo Backlog = Entregas atrasadas as Tempo em Espera = Perda de $$$$ Mínimo rio Necessá Tempo Complexidade Defeitos Funcionalidades Extra elevam os custos exponencialmente 24

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

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 26

27 Fluxo do Processo Ágil Concepção Pré-Concepção Product Backlog Modelo de Negócio Questionário de decisão Arquitetura Alto Nível User Stories Confirmar Requisitos Release Estimate Planejar, Desenvolver, Qualidade 2-4 Semanas Teste Iteration Backlog March 2009 Produto potencialmente entregável Daily Scrum 27

28 Agile Framework 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) SCRUM: Crystal: 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 Entregas frequêntes Melhorias reflectivas (Reflective improvement) Unified Process: Versão simplificada do Rational Unified Process redução no número de disciplinas Adaptive: Repetição dos ciclos de Especular, Colaborar e Aprender Aprendizagem contínua e adaptações para alterar o estado do projeto Dynamic Systems Development Method (DSDM): 3 fases primárias: Pré-Projeto, Ciclo de vida do Projeto, PósProjeto Feature Driven Dev.: Listar funcionalidades Planejamento, Design, Construção por Funcionalidade Técnicas ágeis: os métodos acima envolvem diferentes técnicas, entre elas: Test-driven development Planning game Pair Programming Refactoring Continuous integration Design improvement Small releases Simple design Static Analysis Coding standard Sustainable pace Whole team 28

29 Scrum Image owned by Teivovo, Fiji Rugby,

30 Origem do Scrum 30

31 Origem do Scrum 31

32 The New New Product Development Game 32

33 Rugby?! 33

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 34

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 35

36 Pilares Tranparência Inspeção qualquer tipo de informação pertinente ao negócio, tecnologia, ou andamento do projeto deve estar visível 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 36

37 Scrum framework Nota: se tornou a metodologia Ágil mais utilizada pelo mercado Sprint = Iteração 37

38 Personagens 38

39 39

40 Scrum Entradas dos Executivos, Equipe, Clientes, Usuários e outros Envolvidos Gráfico Burndown2 Scrum Master1 Dono do Produto1 (Product Owner) Hitórias de Usuários ou Casos de Uso Backlog do Produto2 Lista ordenada dos requisistos Cada 24 horas Sprint 2-4 Semanas Equipe de Desenvolvimento1 Time seleciona as de maior prioridade que podem se comprometer a entregar no final do Sprint Scrum Diário3 Revisão do Sprint3 Tarefas Backlog do Sprint2 Data de Entrega e Backlog do Sprint não sofrem alterações após o início do Sprint Incremento Pronto2 Reunião de Planejamento do Sprint3 1 Papel, 2Artefato, 3Evento Retrospectiva do Sprint3 40

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 41

42 Artefatos 42

43 Reuniões Planejamento da Iteração Daily Scrum Revisão da Iteração Coordenada pelo ScrumMaster Coordenada pelo ScrumMaster Coordenada pelo ScrumMaster Todos participam (Porcos e Frangos) O time participa (frangos são opcionais) Todos participam (Porcos e Frangos) Entradas: Product backlog, produto atual, condições técnicas e de negócio Mesmo lugar e horário, todos os dias, 15 mins max Informal, 4 horas, informativa 1. Seleciona-se os itens de maior prioridade do Backlog; declara-se o Objetivo da Iteração Responder 2.Time transformas os itens selecionados no Iteration Backlog Saída: Objetivo da Iteração, Iteration Backlog 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 Time demonstra o incremento Todos discutem Considera-se candidatos à componentes Realiza-se a reflexão Anuncia-se a próxima reunião de planejamento Reflexão Perguntar a cada iteração: o que devemos 1. PARAR? 2. COMEÇAR? 3. CONTINUAR? Não se passa status para o ScrumMaster Mas se compromete com seus colegas 43

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 44

45 Done, done, done, done! 45

46 Você está Pronto, Pronto, Pronto, Pronto? TOM Gerente de Projetos FRANK Desenvolvedor 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 nova build 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. 46

47 B u g B a c k lo g Dívida Técnico (Technical Debit) Time 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. Copyright , ADM, All Rights Reserved v8.0 47

48 Scrum Entradas dos Executivos, Equipe, Clientes, Usuários e outros Envolvidos Gráfico Burndown2 Scrum Master1 Dono do Produto1 (Product Owner) Hitórias de Usuários ou Casos de Uso Backlog do Produto2 Lista ordenada dos requisistos Cada 24 horas Sprint 2-4 Semanas Equipe de Desenvolvimento1 Time seleciona as de maior prioridade que podem se comprometer a entregar no final do Sprint Scrum Diário3 Revisão do Sprint3 Tarefas Backlog do Sprint2 Data de Entrega e Backlog do Sprint não sofrem alterações após o início do Sprint Incremento Pronto2 Reunião de Planejamento do Sprint3 1 Papel, 2Artefato, 3Evento Retrospectiva do Sprint3 48

49 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 User Story Product Backlog 50

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 51

52 User Story os 3 Cs 52

53 User Stories: Cartão: Descrição breve Como um <Papel>, eu quero <Objetivo> para que eu <valor de negócio>. 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. 53

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 54

55 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... 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 Lembre-se: isso não é uma história interna do time 55

56 Quebrando histórias em outras menores 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, 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 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 56

57 O que faz uma boa história? Independente Negociável Com Valor Estimável Tamanho apropriado Testável 57

58 User Stories em tarefas Durante o planejamento da iteração as histórias devem ser quebradas em tarefas User Story Tarefa #1 (X horas) Tarefa #2 (Y horas) Tarefa #3 (Z horas) Máximo de 16 horas ideais por tarefa 58

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 59

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 60

61 Priorizar de 1 a N N 61

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 62

63 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ícito e é necessário 6363

64 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 6464

65 2. Atrasos impactam o cronograma Tarefa 3 inicia: ATRASADO se 1, 2 ou 4 estiver atrasada ANTES apenas se 2 e 4 terminar antes e tiver recurso disponível 6565

66 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 6666

67 O que ocorre? Fonte:

68 6868

69 4. Multitasking Multi-tarefas Multi-tarefas causam atrasos Ao invés de multi-tarefar, use unidades de trabalho menores Deixar o fluxo de trabalho acontecer o mais rápido possível Transferências mais eficientes para outra pessoa 6969

70 O efeito das multi-tarefas 7070

71 A cebola do planejamento 7171

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

73 Medidas 7373

74 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 7474

75 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 7575

76 3 níveis de planejamento

77 ...com 3 níveis de precisão Story Points Horas Ideais Comprometimento diário 7777

78 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 7878

79 Triangulação Confirmar as estimativas comparando com múltiplas histórias Agrupar histórias parecidas em uma tabela ou quadro

80 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) 8080

81 Investigar quanto esforço? Um pouco de esforço ajuda muito Muito esforço apenas ajuda um pouco mais Precisão Esforço 8181

82 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 Incluir o 0 e ½ se desejar 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:? 8282

83 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 tempo 5. 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 8383

84 Quadro de Tarefas 8484

85 Kanban 8585

86 8686

87 kunagi.org

88 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 8888

89 Iteration/Sprint burndown chart 8989

90 Apenas o que falta para trabalhar Nota: no máximo 16 horas ideias por tarefa 9090

91 Quando o projeto será entregue? Story Points 4 lições: 1. Mostra progresso 2. Levanta questões, e não as responde 3. Antecipa discussões 4. Impossibilita a mentira Iteration = Sprint 9191

92 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 9292

93 Scrum Entradas dos Executivos, Equipe, Clientes, Usuários e outros Envolvidos Gráfico Burndown2 Scrum Master1 Dono do Produto1 (Product Owner) Hitórias de Usuários ou Casos de Uso Backlog do Produto2 Lista ordenada dos requisistos Cada 24 horas Sprint 2-4 Semanas Equipe de Desenvolvimento1 Time seleciona as de maior prioridade que podem se comprometer a entregar no final do Sprint Scrum Diário3 Revisão do Sprint3 Tarefas Backlog do Sprint2 Data de Entrega e Backlog do Sprint não sofrem alterações após o início do Sprint Incremento Pronto2 Reunião de Planejamento do Sprint3 1 Papel, 2Artefato, 3Evento Retrospectiva do Sprint3 93

94 Referências Takeuchi, Hirotaka; Nonaka, Ikujiro. "The New New Product Development Game". Harvard Business Review Ken Schwaber and Mike Beedle. Agile Software Development with Scrum. Prentice Hall, Upper Saddle River, New Jersey, Ken Schwaber. SCRUM Development Process. OOPSLA 95 Workshop on Business Object Design and Implementation, Mary Poppendieck and Tom Poppendieck. Lean Software Development: An Agile Toolkit. Addison-Wesley, Agile Manifesto Scrum Guide - versão de 2011 em português Video: Scrum Master in Under 10 Minutes NEW Scrum Master in Under 10 Minutes video 94

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 Sutherl 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 95