Especialização em Engenharia de Software e Banco de Dados

Transcrição

1 Especialização em Engenharia de Software e Banco de Dados Disciplina: Engenharia de Software Tópico: Metodologias Ágeis Prof. Rodolfo Miranda de Barros rodolfo@uel.br

2 O que é agilidade? Agilidade: Rapidez, desembaraço; Qualidade de quem é veloz; Capacidade de responder rapidamente a mudanças: Mudanças de tecnologias, de equipe, de requisitos... Entregar valor ao cliente quando se lida com imprevisibilidade e dinamismo dos projetos;

3 O que é agilidade? Linha de pensamento revolucionária: Precisamos parar de tentar evitar mudanças; Metodologias ágeis: Filosofia onde muitas metodologias se encaixam; Definem um conjunto de atitudes e não um processo prescritivo.

4 Metodologias ágeis Reação às metodologias tradicionais; Manifesto ágil (2001): Movimento iniciado por programadores experientes e consultores em desenvolvimento de software; Questiona e se opõe a uma série de mitos/práticas adotadas em abordagens tradicionais de Engenharia de Software e Gerência de Projetos.

5 Metodologias ágeis Princípios do Manifesto Ágil: Indivíduos e interações são mais importantes que processos e ferramentas; Software funcionando é mais importante que documentação completa (abrangente); Colaboração do cliente é mais importante que negociação de contratos; Adaptação às mudanças é mais importante que seguir um plano; Isto é, ainda que haja valor nos itens á direita, valorizamos mais os itens à esquerda.

6 Metodologias ágeis Segundo Pressman: A engenharia de software ágil combina uma filosofia e um conjunto de diretrizes de desenvolvimento; A filosofia encoraja a satisfação do cliente e a entrega incremental de software logo no início; Equipes de projetos pequenas e altamente motivadas; Métodos informais; Produtos de trabalho de engenharia de software mínimos e simplicidade global de desenvolvimento; As diretrizes de desenvolvimento enfatizam a entrega em contraposição à análise e ao projeto (apesar destas atividades não serem desencorajadas); Comunicação ativa e contínua entre desenvolvedores e clientes.

7 Princípios da agilidade 1. A mais alta prioridade é a satisfação do cliente, por meio da liberação mais rápida e contínua de software de valor; 2. Receba bem as mudanças de requisitos, mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente; 3. Libere software freqüentemente (em intervalos de 2 semanas até meses), dando preferência para uma escala de tempo mais curta; 4. Mantenha pessoas ligadas ao negócio (clientes) e desenvolvedores trabalhando juntos a maior parte do tempo do projeto;

8 Princípios da agilidade 5. Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado; 6. O método mais eficiente e efetivo para repassar informação entre uma equipe de desenvolvimento é pela comunicação face-a-face; 7. Software funcionando é a principal medida de progresso de um projeto de software; 8. Processos ágeis promovem desenvolvimento sustentado. Assim, patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente;

9 Princípios da agilidade 9. A atenção contínua para a excelência técnica e um bom projeto (design) aprimoram a agilidade; 10. Simplicidade - a arte de maximizar a quantidade de trabalho não feito é essencial, devendo ser assumida em todos os aspectos do projeto; 11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas; 12. Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento de acordo.

10 Características gerais Procuram minimizar riscos desenvolvendo software em pequenos espaços de tempo (iterações); Cada iteração é como um pequeno projeto: Planejamento, requisitos, projeto, codificação, testes... Propõem o desenvolvimento de software de forma mais rápida, com um grande número de ciclos, mas com qualidade; Objetivo de cada iteração: Produzir componentes de software (incrementos); Arquitetura vai sendo desenhada a partir da refatoração dos componentes;

11 Características gerais Um catalizador efetivo para o feedback do cliente é um protótipo executável ou parte de um sistema operacional ( incrementos de software); Incrementos de software devem ser entregues em curtos períodos de tempo de modo que a adaptação acerte o passo com as modificações (imprevisibilidade); Essa abordagem iterativa habilita o cliente a avaliar o incremento de software regularmente, fornecer feedback necessário à equipe de software e influenciar as adaptações do processo feitas para acomodar o feedback.

12 Características gerais Encorajamento de atitudes reflexivas e contínuo aprendizado; Lições aprendidas: as lições aprendidas de qualquer atividade de solução de problema (inclusive aquelas que resolvem o problema errado) podem ser benéficas para a equipe mais adiante no projeto ou em outros projetos;

13 Características gerais Fatores Humanos: Segundo Cockburn e Highsmith, o desenvolvimento ágil enfoca os talentos e habilidades dos indivíduos moldando o processo a pessoas e equipe específicas ; Auto-organização no contexto de desenvolvimento ágil: 1. A equipe ágil organiza-se para o trabalho a ser feito; 2. A equipe organiza o processo para melhor acomodar seu ambiente local; 3. A equipe organiza o cronograma de trabalho para conseguir melhor entrega do incremento de software; Uma equipe auto-organizada está no controle do trabalho que realiza. A equipe estabelece os seus próprios compromissos e define os planos para cumpri-los;

14 Características gerais Segundo Ken Schwaber: A equipe seleciona quanto trabalho acredita que pode realizar dentro da iteração e a equipe se compromete com o trabalho. Nada desmotiva tanto uma equipe quanto alguém de fora assumir compromissos por ela. Nada motiva tanto uma equipe quanto a aceitação da responsabilidade de cumprir seus compromissos que ela própria estabeleceu.

15 Conclusões Pró-agilidadex Pró-engenharia tradicional segundo HighSmith: Os metodologistas tradicionais são um punhado de bitolados que preferem produzir documentação perfeita a um sistema funcionando que satisfaça às necessidades do negócios. ; Os metodologistas levianos, quer dizer, ágeis, são um punhado de gloriosos hackers que terão uma grande surpresa quando tiverem de ampliar seus brinquedos para chegar a um software que abranja toda a empresa. ;

16 Conclusões Não fique limitado a uma arma ou técnica em particular; Metodologias diferentes são necessárias para diferentes tipos de projetos Fatores a serem considerados: Número de Pessoas envolvidas no Projeto; Criticidade do Sistema; Prioridades do Projeto; Construa a sua caixa de ferramentas ;

17 Conclusões Em cada modelo ágil (XP, SCRUM, Crystal, FDD) há um conjunto de idéias ( tarefas de trabalho ) que representam um afastamento significativo da engenharia de software convencional; Segundo Pressman, muitos conceitos ágeis são simples adaptações de bons conceitos de engenharia de software; Conclusão segundo Pressman: há muito a ser ganho considerando o melhor de ambas as escolas, e quase nada a ser ganho denegrindo qualquer uma dessas abordagens.

18 Conclusões Assista o vídeo; Que conclusões podemos chegar? Vamos discutir...

19 XP Extreme Programming

20 XP Extreme Programming O trabalho pioneiro sobre o assunto, escrito por Kent Beck, foi publicado em 1999; Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança Kent Beck

21 XP Extreme Programming Uma Pergunta: Como você programaria se tivesse tempo suficiente? Mais testes? Mais projeto e arquitetura? Menos pessoas? Mais qualidade? Kent Beck

22 XP Extreme Programming Levar todas as boas práticas ao Extremo Se testar é bom, vamos testar toda hora! Se projetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa! Se integrar é bom, vamos integrar a maior quantidade de vezes possível! Se executar iterações curtas é bom, vamos deixar as iterações realmente curtas!

23 XP Extreme Programming XP tem como premissa técnica a combinação de: Inserção do cliente no projeto; Liberações de pequenos incrementos ao longo das iterações no desenvolvimento; Projeto simples; Programação em pares; Refatoração; Integração contínua;

24 A base do XP está sedimentada sobre cinco valores: i. Comunicação: comunicação constante entre os membros da equipe e destes com os clientes; ii. iii. iv. XP Extreme Programming Simplicidade: desenvolvimento focado no atendimento às necessidades do cliente da maneira mais simples possível; Feedback: o feedback do sistema (por meio da utilização constante de testes de unidade), o feedback do cliente (por meio da de testes de aceitação) e o feedback da equipe de projeto (através da comunicação constante); Coragem: reforça o fato de que as tarefas não devem ser adiadas, ou seja, devem ser desempenhadas o quanto antes, colaborando para que os desenvolvedores se sintam mais confortáveis com a refatoração do código; v. Respeito: por meio do respeito mútuo entre os membros da equipe, como o objetivo de evitar a desvalorização do trabalho de qualquer membro da equipe de trabalho e almejar uma equipe mais confiante e motivada.

25 XP Extreme Programming O XP inclui um conjunto de regras e práticas que ocorrem no contexto de quatro atividades: planejamento, projeto, codificação e teste.

26 XP Extreme Programming Planejamento: Começa com a criação de um conjunto de histórias (histórias de usuários) que descrevem as características e funcionalidades requeridas para o software; Cada história é escrita pelo cliente e é colocada em um cartão de indexação; O cliente atribui um valor (prioridade) para a história, com base no valor de negócio global da característica ou da função;

27 XP Extreme Programming Planejamento (continuação): As histórias de usuário descrevem cenários com situações de utilização que os envolvidos gostariam que o sistema em desenvolvimento viesse a oferecer; As histórias de usuário são a base para a criação de estimativas de tempo que serão utilizadas nas reuniões de planejamento de entregas (releases); O plano de entregas direciona todo o planejamento do desenvolvimento e do plano de iterações para cada iteração individual;

28 XP Extreme Programming Planejamento (continuação): Membros da equipe XP avaliam cada história e lhe atribuem um custo medido em semanas de desenvolvimento; Se a história precisar mais do que três semanas, pede-se para o cliente para dividir a história em histórias menores e a atribuição de custo ocorre novamente; É importante notar que novas histórias podem ser escritas a qualquer momento;

29 XP Extreme Programming Planejamento (continuação): Depois do primeiro incremento de software tiver sido entregue, a equipe XP calcula a velocidade do projeto; Velocidade é a quantidade de histórias do cliente implementadas durante a iteração; A velocidade pode ser usada para: Ajudar a estimar as datas de entrega e o cronograma para as versões subseqüentes; Determinar se um comprometimento excessivo foi feito para todas as histórias ao longo de todo o projeto de desenvolvimento. Se o comprometimento excessivo ocorrer, o conteúdo das versões (incrementos) será modificado ou as datas de entrega finais são alteradas.

30 XP Extreme Programming

31 XP Extreme Programming

32 Projeto: XP Extreme Programming O projeto XP segue rigorosamente o princípio KIS (Keep it simple mantenha a simplicidade); O XP encoraja o uso de cartões CRC (Class Responsability - Colaborator) como um mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos; Os cartões CRC identificam e organizam as classes orientadas a objetos que são relevantes para o incremento de software atual; Os cartões CRC são o único produto de trabalho do projeto que é realizado como parte do processo XP;

33 XP Extreme Programming Projeto (Continuação): O uso de cartões CRC (Classes, Responsabilidades e Colaborações) é recomendado de forma a permitir o design em equipe; Responsabilidades são identificadas para cada classe. As colaborações determinam as interações entre classes. Os cartões permitem que o todo o time possa colaborar com o design;

34 XP Extreme Programming Cartão CRC no campo Classe, pode-se colocar opcionalmente, sob o nome da classe, o nome da sua superclasse e de suas subclasses; Responsabilidades podem ser: conhecimento (saber algo, guardar algum valor); comportamental (fazer algo); Colaboradores são outras classes com as quais essa classe interage diretamente para atingir o objetivo maior do sistema como um todo.

35 XP Extreme Programming Projeto (Continuação): Se um problema de projeto difícil é encontrado como parte do projeto de uma história, o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto; A idéia do protótipo é diminuir o risco quando a implementação verdadeira começa e validar as estimativas originais correspondentes à história que contém o problema de projeto.

36 XP Extreme Programming Codificação: O XP recomenda que depois que as histórias forem desenvolvidas e o trabalho preliminar do design for feito, a equipe não avance para o código, mas, em vez disso, desenvolva uma série de testes unitários que exercitarão cada uma das histórias que devem ser incluídas na versão atual (incremento); Programação em pares: O XP recomenda que duas pessoas trabalhem juntas em uma estação de trabalho de computador para criar o código correspondente a uma história; Idéia: fornecer um mecanismo de solução de problemas em tempo real e de garantia de qualidade em tempo real;

37 XP Extreme Programming Codificação (Continuação): O XP encoraja a refatoração: processo pelo que os programadores reestruturam o sistema sem mudar suas funcionalidades para remover duplicidades, melhorar a comunicação, simplificar ou adicionar flexibilidade, preservando sua funcionalidade.

38 Testes: XP Extreme Programming Os testes unitários que são criados devem ser implementados usando um arcabouço que lhes permita ser automatizados; Isto encoraja uma estratégia de regressão sempre que o código é modificado (lembre-se, considerando a filosofia de refatoração); Testes de aceitação ou testes do cliente: São derivados das histórias dos usuários que foram implementadas como parte de um incremento. Estes testes são especificados pelos clientes e focalizam as características e funcionalidades do sistema global que são visíveis e passíveis de revisão pelo cliente.

39 Exercícios Fazer um algoritmo para calcular quantos dias você já viveu Programação em pares e Refatoração; Cartões CRC.

40 SCRUM

41 SCRUM O Scrum (o nome é derivado de uma atividade que ocorre durante um jogo de rugby) é um modelo ágil de processo que foi desenvolvido por Jeff Sutherland e por sua equipe no início da década de 90;

42 SCRUM O Scrum é um framework de processo ágil utilizado para gerenciar e controlar o desenvolvimento de um produto de software através de práticas iterativas e incrementais. Incremental Iterativo É composto por um conjunto de boas práticas de gestão que admite ajustes rápidos, acompanhamento e visibilidade constantes e planos realísticos;

43 SCRUM Uma alternativa de utilizar métodos ágeis na gerência de projetos; Pode ser aplicável a qualquer tipo de projeto; É simples: Processo, artefatos e regras são poucos e fáceis de entender ; A simplicidade pode ser decepcionante aos acostumados com metodologias clássicas.

44 SCRUM Não é um método prescritivo: Não define previamente o que deve ser feito em cada situação; Projetos complexos não permitem prever todos os eventos; Aplica o senso comum: Combinação de experiência, treinamento, confiança e inteligência de toda a equipe; Senso comum em vez do senso de uma única pessoa é uma das razões do sucesso do Scrum;

45 SCRUM Os princípios Scrum são consistentes com o manifesto ágil: Pequenas equipes de trabalho são organizadas de modo a maximizar a comunicação, minimizar a supervisão e maximizar o compartilhamento de conhecimento tácito informal ; O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios para garantir que o melhor produto possível seja produzido ; O processo produz freqüentes incrementos de software que podem ser inspecionados, ajustados, testados, documentados e expandidos O trabalho de desenvolvimento e o pessoal que realiza é dividido em partições claras, de baixo acoplamento, ou em pacotes ; Testes e documentação constantes são realizados à medida que o produto é construído.

46 Papéis no Scrum Todas as responsabilidades de gerenciamento são divididas entre três papéis: Product Owner; Scrum Master; Equipe; Para o bom funcionamento do Scrum as pessoas responsáveis pelo projeto devem ter autoridade para fazer o que for necessário pelo seu sucesso; Pessoas não responsáveis não podem interferir no projeto: Tal fato gera aumento de produtividade; Evita situações constrangedoras para os envolvidos; Cada um conhece sua participação frente ao projeto e trabalha em conjunto para conseguir alcançar o objetivo definido.

47 Papéis Product Owner (PO) Responsável por apresentar os interesses de todos os stakeholders; Define fundamentos iniciais do projeto, objetivos e planos de release; Responsável pela lista de requisitos (Product Backlog); Certifica se as atividades com maior valor para o negócio são desenvolvidas primeiro: Priorização freqüente das funcionalidades antes de cada iteração; É um facilitador. Tira obstáculos para que a equipe entregue valor agregado ao cliente;

48 Papéis Scrum Master (SM) Responsável pelo sucesso do Scrum; Garantir que a equipe conheça e saiba trabalhar com Scrum; Implementa o Scrum na empresa de forma adaptada a sua cultura, para continuamente gerar benefícios; Certifica se cada pessoa envolvida está seguindo seus papéis e as regras do Scrum; Certifica que pessoas não responsáveis não interfiram no processo; Conduz reuniões e apresentações;

49 Papéis Equipe Responsável por escolher as funcionalidades a serem desenvolvidas em cada interação e desenvolvê-las; O time se auto-gerencia, se auto-organiza; Todos os membros do time são coletivamente responsáveis pelo sucesso de cada iteração;

50 PO SCRUM

51 SCRUM Visão do Produto Monta a visão do Produto; Pode usar printscreen, folder do concorrente, artefatos, documentos, etc. Pode ter n páginas; Para <público alvo> que <oportunidade ou necessidade>, o <nome do produto> é um <categoria do produto> que <benefícios do usuário>. Ao contrário <produtos concorrentes>, nosso produto <diferenciais>. 5W2H pode ser útil.

52 SCRUM Product Backlog Lista de todas as funcionalidades desejadas; É gerada incrementalmente: Começa pelo básico, o extra aparece com o tempo; Novos requisitos aparecem quando o cliente vê o produto; Pode conter: Tarefas diretas, casos de uso e histórias (como no XP); A lista é priorizada pelo Producto Owner, que deve entender cada item da lista (história); Deve conter características que agreguem algum valor de negócio ao produto.

53 SCRUM Product Backlog Uma reunião de validação do Product Backlog pode durar 4h (conversa, sugestões, reflexões). Participam: Equipe + PO + SM Exemplo Negativo: Para facilitar a busca pro livros, como um cliente eu gostaria de ter vários tipos de buscas; Exemplo Positivo: Para facilitar a busca por livros, como um cliente eu gostaria de ter uma busca por títulos; Trazer uma idéia: Boleto bancário;

54 Tamanho-Story Points Story points: Medida relativa do tamanho de uma história; Não existe fórmula; É resultado do agrupamento de fatores: esforço É resultado do agrupamento de fatores: esforço envolvido no desenvolvimento da funcionalidade, a complexidade, riscos, etc.

55 Tamanho-Story Points Usualmente, para cada story do backlog deverá ser atribuído um valor da série aproximada de Fibonacci (1,2,3,5,8,13,21,...) (Planning Poker); O significado dos valores é relativo, onde uma story de pontuação 8 demanda aproximadamente quatro vezes mais esforço que uma story de pontuação 2; Essa atribuição deve ser feita pelo time e não por uma única pessoa; Para começar a pontuar as stories de um product backlog, pega-se a story que o time julga ser a de menor esforço e atribui pontuação 2. As demais stories deverão seguir uma pontuação relativa a essa primeira.

56 Velocidade É o total de story points (sp) entregues em uma iteração pela equipe; Exemplo: Se uma equipe completa em uma interação 3 histórias, uma estimada em 5 sp, uma outra em 3 sp e a terceira em 5 sp, a velocidade do time é de 13;

57 Velocidade Velocidade da equipe = 20 Total de Story Points = 100 Total de iterações do projeto = 100/20 = 5 iterações Duração da iteração = 3 semanas Estimativa de entrega do produto = 15 semanas

58 SCRUM -Fases

59 SCRUM -Fases Planejamento Sprints Reuniões Diárias Revisão Retrospectivas Encerramento

60 SCRUM-Planejamento Relativamente curto; Projeto da arquitetura do sistema; Estimativas de datas e custos; Criação do backlog: Participação de clientes: Levantamento dos requisitos e atribuição de prioridades; Definição de equipes e seus líderes; Definição de pacotes a serem desenvolvidos; Backlog

61 SCRUM -Sprint O time recebe uma parte do backlogpara desenvolvimento; O backlog não sofrerá modificações durante o Sprint Duração de 1 a 4 semanas; Sempre apresentam um executável ao final;

62 Sprint-Reuniões Diárias Cerca de 15 minutos de duração; Todos respondem às perguntas: O que você realizou desde a última reunião? Quais problemas você enfrentou? Em que você trabalhará até a próxima reunião? Benefícios: Maior integração entre os membros da equipe; Rápida solução de problemas: Promove o compartilhamento de conhecimento; Progresso medido continuamente: Minimização de riscos;

63 Sprint-Revisão Deve obedecer à data de entrega: Permitida a diminuição de funcionalidades; Apresentação do produto ao cliente: Sugestões de mudanças são incorporadas ao backlog; Benefícios: Apresentar resultados concretos ao cliente; Integrar e testar uma boa parte do software; Motivação da equipe;

64 Encerramento Finalização do projeto Atividades: Testes de integração; Testes de sistema; Documentação do usuário; Preparação de material de treinamento; Preparação de material de marketing.

65 Regras no Scrum O ScrumMaster deve se certificar de que cada envolvido no projeto siga suas regras; As regras permitem a execução correta do Scrum; Mudanças das regras devem se originar do time: O ScrumMaster deve ser convencido de que todos envolvidos entenderam suficientemente as regras do Scrum para o correto discernimento; Discussões desnecessárias são perda de tempo de produção da equipe;

66 Sprint Planning Meeting #1 A reunião de planejamento do Sprint deve ocorrer dentro de 8 horas com duas partes de 4 horas; Primeiro seguimento: Product Owner deve preparar o Product Backlog antes da reunião; Seleção dos itens do Product Backlog que o time se compromete em torná-los incrementos potencialmente implementáveis (Selected Backlog); Decisão final é do Product Owner; Não esquecer da velocidade da equipe;

67 Sprint Planning Meeting #2 Ocorre imediatamente após o primeiro; Product Owner deve estar disponível para que o time faça perguntas; O time deve decidir como os itens selecionados serão implementados (item backlog tarefas); Tarefas identificadas e estimadas (1 a 8 horas); De forma colaborativa, não é feito pelo Scrum Master; Equipe compromete-se a concluir as tarefas; Resultado deste seguimento é o Sprint Backlog; Construção do Sprint burndown;

68 Sprint Planning Meeting #2 Layout Boleto Bancário Código de Barras Arquivo de Remessas Gerar PDF tarefas História Gerar HTML

69 Sprint Planning Meeting #2 Exemplo genérico de Taskboard:

70 Sprint Planning Meeting #2 Exemplo genérico de Sprint Burndown:

71 Scrum Daily Meeting Reunião de no máximo 15 minutos, a menos que o time seja grande o suficiente para precisar de mais tempo; Deve ser feita no mesmo lugar onde o time trabalha; Resulta em melhores resultados se realizada no inicio do dia de trabalho; Todos os membros do time devem participar desta reunião;

72 Scrum Daily Meeting ScrumMaster faz as seguintes perguntas para cada membro do time: O que você fez desde a última reunião diária do Scrum relacionada a este projeto? O que você irá fazer desde agora até a próxima reunião diária do Scrum relacionada a este projeto? O que está impedindo você de realizar o seu trabalho o mais efetivamente possível? Os membros devem responder apenas a estas perguntas para não estender a reunião;

73 Sprint Não deve ser maior do que 30 dias consecutivos; Sem considerar outros fatores, este é o tempo necessário para produzir algo de interesse para o Product Owner e os stakeholders; O time se compromete com o Product Backlog: Não são permitidas modificações nele durante o Sprint;

74 Sprint Responsabilidades do time durante o Sprint: Participar das reuniões diárias do Scrum; Manter o Sprint Backlog atualizado; Disponibilizar o Sprint Backlog publicamente; O time tem o compromisso de implementar todos os itens selecionados;

75 Reunião de Revisão do Sprint Reunião de no máximo 4 horas sob responsabilidade do ScrumMaster; O time não deve gastar mais de 1 hora na preparação desta reunião; Objetivo: Mostrar ao Product Owner e stakeholders as funcionalidades que foram feitas Artefatos não devem ser apresentados, pois não são funcionalidades; No final da reunião: Cada stakeholder fala suas impressões e sugere mudanças com suas respectivas prioridades; Possíveis modificações no Product Backlog são discutidas entre o Product Owner e o time; ScrumMaster anuncia a data e o local da próxima reunião de revisão do Sprint ao Product Owner e a todos stakeholders;

76 Reunião de Retrospectiva do Sprint Não deve ser maior do que 3 horas; Participam desta reunião: Time, ScrumMaster e, opcionalmente, Product Owner; Os membros do time devem responder a duas questões: O que aconteceu de bom durante o último Sprint? O que pode ser melhorado para o próximo Sprint? ScrumMaster escreve as respostas e prioriza na ordem que deseja discutir as potenciais melhorias; ScrumMaster nesta reunião tem o papel de fazer com que o time encontre melhores formas de aplicar o Scrum;

77 Exercícios Leia o estudo de caso, identifique as histórias e crie as respectivas tarefas; Vamos simular algumas iterações...

78 Algumas Referências Agile Software Development with SCRUM by Ken Schwaber Scrum and XP from the Trenches by Henrik Kniberg The Enterprise and Scrum by Ken Schwaber