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

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

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;

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.

Metodologias ágeis Reação às metodologias tradicionais; Manifesto ágil (2001): http://www.agilemanifesto.org/ 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.

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.

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.

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;

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;

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.

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;

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.

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;

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;

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.

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

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 ;

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.

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

XP Extreme Programming

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

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

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!

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;

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.

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.

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;

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;

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;

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.

XP Extreme Programming

XP Extreme Programming

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;

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;

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.

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.

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;

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.

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.

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

SCRUM

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;

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;

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.

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;

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.

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.

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;

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;

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;

PO SCRUM

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.

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.

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;

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.

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.

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;

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

SCRUM -Fases

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

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

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;

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;

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;

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.

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;

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;

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;

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

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

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

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;

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;

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;

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;

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;

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;

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

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