Você está na página 1de 34

©Alison Rabelo | twitter.

com\alisonrabelo

Programa
I. Gerenciamento de Projetos
II. Projetos de Desenvolvimento de Software
III. Métodos Ágeis de Desenvolvimento de Software
IV. Gerenciamento Ágil de Projetos
V. Scrum
VI. Regras do Scrum

©Alison Rabelo | twitter.com\alisonrabelo

1
Parte I

©Alison Rabelo | twitter.com\alisonrabelo

Motivação
 Cenário mundial
 Concorrência global
 Maior exigência por qualidade
 Menor tempo para desenvolvimento de produtos
 Recursos limitados
 Grandes redes de informação e fornecedores atuando
globalmente

©Alison Rabelo | twitter.com\alisonrabelo

2
Projetos
“Cerca de 2 milhões de pessoas estão
trabalhando em 300 mil projetos de
software nos Estados Unidos. Entre 1/3 e
2/3 destes projetos excederão seus
prazos e orçamentos antes de serem
concluídos. Dentre os mais caros projetos
de software, cerca de 1/2 eventualmente
serão cancelados por estarem
completamente fora de controle.”
Software Project Survival Guide

©Alison Rabelo | twitter.com\alisonrabelo

Problemas Típicos dos Projetos


Gerenciamento de projetos
 Atrasos no cronograma
Tarefa complexa e difícil!
 Custos além do previsto
Organizações reconhecem
 Falta de recursos relação entre o fraco
 Mudanças de requisitos Gerenciamento de Projetos e
os impactos nos negócios!
 Qualidade abaixo da esperada
 Produtos que não funcionam
 Projetos que são cancelados
 Ruídos na comunicação entre a equipe de
projeto e as partes interessadas no projeto

©Alison Rabelo | twitter.com\alisonrabelo

3
Projetos
 Projetos
 são únicos e finitos, isto é, tem início e fim.
 “Um projeto é um esforço temporário para criar um
produto ou serviço único.”

©Alison Rabelo | twitter.com\alisonrabelo

Projetos
 Características de um projeto:
 Elaboração Progressiva:
 característica de projetos que integra o conceito da
temporariedade e particularidade;
 conceito de elaboração do projeto por etapas ou incrementos
iterativos;
 distingue as fases de um projeto.
 Temporário
 significa possuir um início e um fim definido.

©Alison Rabelo | twitter.com\alisonrabelo

4
Projetos
 Exemplos de Projetos:
 Desenvolvimento de um novo modelo de veículo;
 Construção ou reforma de um prédio;
 Uma campanha para um cargo político;
 Organização de um evento, como uma feira de negócios,
um show, entre outros;
 Desenvolvimento ou aquisição de um Sistema de
Informação.

©Alison Rabelo | twitter.com\alisonrabelo

Operações
 Operações
 são corriqueiras e repetitivas;
 possuem atividades contínuas, não sendo limitadas a
tempo
 suportam o funcionamento normal de uma organização.
 são um conjunto de ações cujos resultados, em um dado
período, contribui para o atendimento de uma
necessidade administrativa ou operacional da
organização.

©Alison Rabelo | twitter.com\alisonrabelo

5
Projetos x Operações
 Possuem características semelhantes, apesar de
serem conceitos diferentes;
 Tanto os projetos como as operações são realizadas
por pessoas, restritos em recursos e são planejados,
executados e controlados;
 São realizados com um propósito definido e
possuem atividades inter-relacionadas.
 A finalidade de um projeto é atingir o objetivo e ser
finalizado.
 O objetivo de uma operação é normalmente
sustentar o negócio.

©Alison Rabelo | twitter.com\alisonrabelo

Parte II

©Alison Rabelo | twitter.com\alisonrabelo

6
Projetos de Desenvolvimento de
Software
 Estão inseridos em ambientes de negócio bastante
dinâmicos e complexos.
 São projetos de alta complexidade devido às mudanças
constantes de requisitos (escopo)
 Muitos projetos fracassaram ou estavam fadados ao
insucesso devido ao desconhecimento ou emprego
incorreto de práticasApenas
de gerenciamento de projetos.
34% dos projetos de
desenvolvimento de software
foram bem-sucedidos em
2002 (Standish Group)
©Alison Rabelo | twitter.com\alisonrabelo

Parte III

©Alison Rabelo | twitter.com\alisonrabelo

7
Métodos Ágeis de Desenvolvimento de
Software
 São uma resposta ao baixo desempenho dos projetos
de software.
 Visam atender às demandas crescentes por produtos e
serviços inovadores e à necessidade de mudanças
constantes de escopo nos projetos de desenvolvimento
de software.
 Uma reação aos métodos clássicos de desenvolvimento
de software, baseados no RUP, CMMi, PMBOK, etc.
 Fruto de um movimento da comunidade de analistas e
desenvolvedores

©Alison Rabelo | twitter.com\alisonrabelo

Métodos Ágeis de Desenvolvimento de


Software
 Mudança de paradigma: a aceitação das mudanças de
escopo durante o projeto.
 Agilidade: “a habilidade de criar e responder a
mudanças, buscando a obtenção de lucro num
ambiente turbulento”(HIGHSMITH).
 A ausência de estrutura pode levar ao caos, mas
estrutura em demasia pode levar a rigidez.
(HIGHSMITH).
 Os modeladores ágeis encampam a mudança nos seus
projetos (AMBLER)

©Alison Rabelo | twitter.com\alisonrabelo

8
Métodos Ágeis de
Desenvolvimento de Software
 Métodos adaptativos e não preditivos.
 O planejamento é refeito, levando em considerações as
mudanças de requisitos e no ambiente de negócios.
 Diferença entre duas abordagens:

Métodos Clássicos (PMBOK) Métodos Ágeis


Planejamento total do Planos elaborados e
escopo no inicio do projeto e adaptados ao longo do
um controle rígido de projeto, possibilitando a
mudanças. incorporação de mudanças
solicitadas pelo cliente

©Alison Rabelo | twitter.com\alisonrabelo

Métodos Ágeis de Desenvolvimento de


Software
 Exemplos desses métodos:
 XP (Extreme Programming);
 Scrum;
 DSDM (Dynamic Systems Development Method);
 ADM (Adaptative Development Method);
 Crystal Methods;
 FDD (Feature-Driven Development);
 Lean Development.

©Alison Rabelo | twitter.com\alisonrabelo

9
Métodos Ágeis de Desenvolvimento de
Software
 Em 2001, um grupo inicial de 17 metodologistas formou a Aliança Ágil
e publicou um manifesto, chamado Manifesto Ágil composto por
quatro simples declarações de valores:

“Nós estamos descobrindo melhores maneiras para desenvolver software,


praticando e auxiliando os outros a fazê-lo. Através deste trabalho, nós
acreditamos que:

Indivíduos e interações valem mais que processos e ferramentas;


Um software funcionando valem mais que documentação extensa;
A colaboração do cliente vale mais que negociação de contrato;
Resposta a mudanças vale mais que seguir um plano.

Ou seja, embora haja valor nos itens à direita, nós valorizamos mais os
itens à esquerda”.
©Alison Rabelo | twitter.com\alisonrabelo

Parte IV

©Alison Rabelo | twitter.com\alisonrabelo

10
Gerenciamento Ágil de Projetos
 Surgiu a partir dos valores e princípios do Manifesto
Ágil.
 O movimento de desenvolvimento ágil ampliou a sua
abrangência, sendo estendido ao gerenciamento de
projetos.
 O Gerenciamento Ágil de Projetos aparece, então,
como uma nova plataforma de gerenciamento de
projetos aplicável a ambientes voláteis e desafiadores,
sujeitos a freqüentes mudanças, em que o processo
prescritivo e padronizado não mais funciona.

©Alison Rabelo | twitter.com\alisonrabelo

Gerenciamento Ágil de Projetos


 Fluxo do Gerenciamento Ágil de Projetos:

Planejamento a cada iteração


Incrementos de funcionalidades
Mudanças de escopo
Aceitação da entregas ao final de cada iteração
Nível de Atividade

Planejamento Controle contínuo


Preliminar do projeto

Tempo

Início Iteração 1 Iteração 2 Iteração 3 Iteração 4 Encerramento

©Alison Rabelo | twitter.com\alisonrabelo

11
Gerenciamento Ágil de Projetos
 Fases do Gerenciamento Ágil de Projetos:
Visão

Visão
Escopo
Comunidade do projeto Plano de
Equipe do projeto entregas
Especulação Exploração

Ações de Funcionalidades
adaptação complementares
Adaptação
Lista de
funcionalidades

Encerramento
Produto final

©Alison Rabelo | twitter.com\alisonrabelo

Gerenciamento Ágil de Projetos


 Visão:
 Determinação da visão do produto e do escopo do projeto;
 Identificação da comunidade do projeto (clientes, gerente de
projetos, equipe de projeto e outras partes interessadas);
 Especulação:
 Identificação dos requisitos iniciais para o produto;
 Definição das atividades;
 Desenvolvimento de um plano de projeto (contendo entregas,
marcos, várias iterações, cronograma de trabalho);
 Elaboração de estratégias para mitigar riscos;
 Estimativas de custo e outras informações financeiras relevantes.
 Planejamento preliminar
©Alison Rabelo | twitter.com\alisonrabelo

12
Gerenciamento Ágil de Projetos
 Exploração:
 Entrega dos produtos planejados;
 Estas entregas são feitas sob a forma de incrementos de
funcionalidades do produto e são divididas entre os ciclos do
projeto;
 Adaptação:
 Revisão dos resultados entregues;
 Análise da situação atual e avaliação do desempenho da equipe e
do projeto, para eventual adaptação;
 Esta revisão objetiva não apenas uma comparação entre o
realizado e o planejado, mas principalmente entre o realizado e
as informações e os requisitos atualizados do projeto, para
identificação de mudanças necessárias.
©Alison Rabelo | twitter.com\alisonrabelo

Gerenciamento Ágil de Projetos


 Encerramento:
 Finalização das atividades do projeto;
 Transferência de aprendizado;
 Celebração do fim do projeto.

©Alison Rabelo | twitter.com\alisonrabelo

13
Vantagens de ser ágil
 Cria um ambiente propício para definição de requisitos
e inovação durante o ciclo de desenvolvimento do
produto.
 Cria um ambiente mais colaborativo e produtivo entre
desenvolvedores e clientes, resultando em entregas
mais rápidas de produtos, melhor adaptados à
realidade do cliente e com a qualidade esperada.
 O Gerenciamento de Projetos é facilitado pela maior
integração e comprometimento da equipe com as
entregas do projeto.

©Alison Rabelo | twitter.com\alisonrabelo

Vantagens de ser ágil


 Reforça o planejamento constante do projeto,
minimizando riscos.
 Valoriza a satisfação do cliente em primeiro lugar,
através do desenvolvimento de requisitos que mais
agreguem valor a ele.

©Alison Rabelo | twitter.com\alisonrabelo

14
Parte V

©Alison Rabelo | twitter.com\alisonrabelo

Scrum
 Baseado no controle
empírico de processos
químicos industriais, usado
para controlar processos
complexos, de
comportamento
imprevisível.
Tem como objetivo lidar com a complexidade do
desenvolvimento de software, em que requisitos surgem e
mudam rapidamente.
Estabelece conjuntos específicos de regras e práticas
gerenciais que devem ser utilizadas para o sucesso de um
projeto.
©Alison Rabelo | twitter.com\alisonrabelo

15
Scrum
 Pode ser aplicado de forma variada, adaptando-se as
suas práticas.
 Recomendado para projetos de outras áreas e
principalmente para projetos de Implantação, pesquisa
e inovação.

©Alison Rabelo | twitter.com\alisonrabelo

Características do Scrum
 Simples;
 Fácil de aprender;
 Aplicável a projetos cujos requisitos são pouco estáveis
ou desconhecidos;
 Aplicável a equipes pequenas de nove pessoas, no
máximo;
 Valoriza o envolvimento das partes interessadas no
planejamento do projeto;

©Alison Rabelo | twitter.com\alisonrabelo

16
Características do Scrum
 Iterações ou ciclos de 30 dias;
 Auto-gestão do trabalho de desenvolvimento por parte
da equipe;
 Dá prioridade aos requisitos que mais agregam valor ao
software.

©Alison Rabelo | twitter.com\alisonrabelo

Benefícios do Scrum
 Participação mais efetiva da equipe quanto à definição
das atividades, gerando maior comprometimento,
motivação e confiança.
 Maior visibilidade do desempenho da equipe e de cada
membro.
 Maior participação e satisfação do cliente.
 Estimula a colaboração e a integração entre os
membros da equipe.
 Incentiva o compartilhamento e a disseminação do
conhecimento.
 Fortalece o trabalho em equipe.
©Alison Rabelo | twitter.com\alisonrabelo

17
Práticas Gerenciais do Scrum
Prática Descrição
Product Backlog Lista de atividades do projeto
Daily Scrum Meeting Reunião diária de 15 minutos para
monitoramento do projeto
Sprint Iteração de 30 dias.
Sprint Planning Meeting Reunião de planejamento do Sprint.
Sprint Backlog Lista de funcionalidades a serem
desenvolvidas durante o Sprint
Sprint Review Meeting Reunião para apresentação, revisão
e avaliação das entregas realizadas
durante o Sprint.

©Alison Rabelo | twitter.com\alisonrabelo

Visão geral do processo


Scrum

©Alison Rabelo | twitter.com\alisonrabelo

18
Papéis do Scrum
 Product Owner
 ScrumMaster
 Equipe Scrum

©Alison Rabelo | twitter.com\alisonrabelo

Product Owner
 Representante do patrocinador no projeto.
 Define os requisitos dos produtos, decide as datas das
releases de software e o que deve conter em cada uma
delas.
 É responsável pelo retorno financeiro (ROI) do
produto.
 Prioriza os requisitos de acordo com as necessidades
de negócio ou seu valor de mercado.
 Pode mudar os requisitos e prioridades a cada Sprint
Planning Meeting.
 Aceita ou rejeita o resultado de cada Sprint
©Alison Rabelo | twitter.com\alisonrabelo

19
ScrumMaster
 Responsável pelo processo Scrum, isto é, garante que
todos sigam as regras e práticas do Scrum, conduzindo
as reuniões diárias, de planejamento e revisão do
Sprint.
 Tem um papel mais próximo ao de um facilitador do
que de um Gerente de Projetos.
 Facilita a colaboração entre as funções e áreas.
 Elimina os impedimentos da equipe.

©Alison Rabelo | twitter.com\alisonrabelo

Equipe Scrum
 Multifuncional
 Deve possuir de 5 a 9 membros.
 É responsável por selecionar, entre os itens priorizados
pelo Product Owner, os que irão ser implementados
durante o Sprint.
 Auto-organizada: o trabalho entre os membros é
organizado de forma participativa.
 Ao final de cada Sprint, a equipe realiza a apresentação
do software desenvolvido para o Product Owner na
reunião de revisão do Sprint.
©Alison Rabelo | twitter.com\alisonrabelo

20
Artefatos do Scrum
 Product Backlog
 Sprint Backlog
 Burndown Chart

©Alison Rabelo | twitter.com\alisonrabelo

Product Backlog
 Os requisitos do software estão listados no Product
Backlog.
 O Product Owner é responsável pelo conteúdo e pela
priorização dos itens do Product Backlog.
 Nunca está completo.
 É uma mera estimativa inicial dos requisitos.
 É alterado assim que as necessidades de negócios
mudam.

©Alison Rabelo | twitter.com\alisonrabelo

21
Product Backlog

©Alison Rabelo | twitter.com\alisonrabelo

Sprint Backlog
 Lista de atividades ou requisitos a serem desenvolvidos
no Sprint, ou seja, é o plano de trabalho da equipe
durante o Sprint.
 São itens selecionados do Product Backlog que a
equipe acredita e se compromete que pode realizar
durante o Sprint.
 A equipe escolhe e estima as tarefas durante a reunião
de Planejamento (Sprint Planning Meeting).
 Apenas a equipe pode alterar o Sprint Backlog.

©Alison Rabelo | twitter.com\alisonrabelo

22
Sprint Backlog

©Alison Rabelo | twitter.com\alisonrabelo

Sprint Burndown Chart


 Gráfico que exibe o progresso diário do time em função
do total de horas estabelecido pela soma de horas das
tarefas do Sprint Backlog:

©Alison Rabelo | twitter.com\alisonrabelo

23
Burndown Chart
 O Burndown Chart também pode ser usado para medir o
progresso do projeto.

©Alison Rabelo | twitter.com\alisonrabelo

Parte V - Final

©Alison Rabelo | twitter.com\alisonrabelo

24
Regras do Scrum
 O Scrum pode ser considerado um jogo com regras
claras e definidas.
 O ScrumMaster é responsável por assegurar que todos
os participantes do projetos, sigam as regras do Scrum.
 A experiência mostra que estas regras têm funcionado
com sucesso em muitos projetos de diversas
organizações.
 É importante que todos que participam de um projeto
gerenciado com Scrum conheçam e sigam as regras de
modo a evitar mal-entendidos, perda de tempo e baixo
comprometimento com metas.

©Alison Rabelo | twitter.com\alisonrabelo

Sprint Planning Meeting

1) Possui tempo fixo de 8 horas, divididos em duas partes:


 A primeira parte é dedicada à seleção do itens do Product
Backlog;
 A segunda, é dedicada à preparar o Sprint Backlog.
2) Participantes:
 ScrumMaster
 Product Owner
 Equipe Scrum
3) Outras pessoas podem participar apenas para fornecer
informações sobre aspectos técnicos do projeto. Assim
que estas informações forem fornecidas, elas serão
dispensadas da reunião.
4)©AlisonNão
Rabelo | deve haver algum chicken como observador.
twitter.com\alisonrabelo

25
Sprint Planning Meeting

5) O Product Owner deverá preparar o Product Backlog


antes da reunião.
6) Na ausência de ambos o Product Owner e Product
Backlog, o ScrumMaster deverá elaborar o Product
Backlog antes da reunião e fazer o trabalho do Product
Owner.
7) O objetivo da primeira parte (4 horas) é que a equipe do
projeto selecione os itens do Product Backlog que eles
acreditam que possam desenvolver no Sprint
8) A equipe pode fazer sugestões, mas a decisão de quais
itens do Product Backlog vão constituir o Sprint é de
responsabilidade do Product Owner.
©Alison Rabelo | twitter.com\alisonrabelo

Sprint Planning Meeting

9) A equipe é responsável por determinar a porção do


Product Backlog, escolhido pelo Product Owner, que
ela tentará desenvolver durante o Sprint.
10) A segunda parte da reunião é deve acontecer
imediatamente após a primeira parte e também
possui um tempo fixo de 4 horas.
11) O Product Owner deve ficar disponível para
responder questionamentos da equipe sobre o
Product Backlog durante a segunda parte.

©Alison Rabelo | twitter.com\alisonrabelo

26
Sprint Planning Meeting

12) A equipe é responsável por determinar como trabalhará


para desenvolver os requisitos selecionados do Product
Backlog em incrementos de funcionalidade de software.
Nesta atividade, a equipe não deverá sofrer interferências
de pessoas de fora da equipe.
13) O resultado da segunda parte da reunião é uma lista
chamada Sprint Backlog, que contém tarefas com suas
estimativas e atribuições.
14) A lista poderá não estar completa, mas deve estar pronta
o suficiente para refletir o comprometimento de todos os
membros da equipe com os requisitos selecionados pelo
Product Owner.
©Alison Rabelo | twitter.com\alisonrabelo

Sprint
1) Tempo fixo de 30 dias consecutivos.
2) O time pode procurar orientação, ajuda, informação e
suporte de pessoas externas durante o Sprint.
3) Ninguém pode dar conselhos, instruções ou direções
sobre as atividades da equipe durante o Sprint. A equipe
deve fazer a auto-gestão das suas atividades.
4) A equipe se compromete com o Product Backlog durante
a Sprint Planning Meeting. Ninguém possui permissão
para mudar o Sprint Backlog durante o Sprint. O escopo
estará “congelado” até o final do Sprint.

©Alison Rabelo | twitter.com\alisonrabelo

27
Sprint
5) Se provar-se que o Sprint não é viável, o ScrumMaster
pode encerrar o Sprint e iniciar uma nova Sprint Planning
Meeting de modo a iniciar um novo Sprint.
6) O ScrumMaster pode interromper o Sprint sem
consentimento das equipe ou do Product Owner ou à
pedido destes.
7) O Sprint pode se tornar inviável quando:
 A tecnologia utilizada no desenvolvimento provar-se não ser
capaz de atender os requisitos.
 As necessidades de negócio mudarem de maneira que o
requisitos desenvolvidos no Sprint não possuem mais valor para a
organização.
 O time recebe interferência externa durante o Sprint.
©Alison Rabelo | twitter.com\alisonrabelo

Sprint
8) Se a equipe se sentir impossibilitada de completar
todo o Sprint Backlog durante o Sprint, pode
consultar o Product Owner sobre quais itens remover
do Sprint em curso.
9) Se houver muitos itens a serem removidos de
maneira que o Sprint perca seu valor e significado no
projeto, o ScrumMaster pode terminar o Sprint.
10) Se a equipe identificar que pode desenvolver mais
requisitos do que os relacionados no Sprint Backlog,
ela poderá consultar o Product Owner para incluir
itens adicionais para o Sprint em curso.

©Alison Rabelo | twitter.com\alisonrabelo

28
Sprint
11) Os membros da equipe têm duas responsabilidades
administrativas durante o Sprint:
 Comparecer ao Daily Scrum Meeting.
 Manter o Sprint Backlog atualizado e visível para
todos.

©Alison Rabelo | twitter.com\alisonrabelo

Daily Scrum Meeting


1) Tempo fixo de 15 minutos.
2) Participantes: todos podem participar, mas os
chickens não podem interferir na reunião. Estes
devem participar apenas como ouvintes.
3) Deve ser feito no mesmo no horário e local, todos os
dias.
4) Recomenda-se realizar no inicio do dia de maneira
que a primeira coisa que os membros da equipe
façam é pensar no que fizeram no último dia de
trabalho e no que vão fazer hoje, ou seja, planejar as
atividades do dia.

©Alison Rabelo | twitter.com\alisonrabelo

29
Daily Scrum Meeting
5) Todos o membros da equipe devem participar.
6) Se alguém não puder comparecer pessoalmente, deve
participar por telefone ou pedir que alguém relate o
status da suas atividades no seu lugar.
7) O ScrumMaster deverá começar a reunião na hora
marcada, sem levar em conta que está presente.
8) Quem chegar atrasado na reunião deverá pagar um
dinheiro pra caixinha de fim de ano ao ScrumMaster
imediatamente.

©Alison Rabelo | twitter.com\alisonrabelo

Daily Scrum Meeting


9) O ScrumMaster começa a reunião conversando com
a pessoa posicionada à sua esquerda e depois
prossegue conversando com os outros membros
numa seqüência horária.
10) Cada membro deverá responder apenas a três
questões:
 O que você fez no projeto desde a última reunião
diária?
 O que você vai fazer no projeto até a próxima reunião
diária?
 O que impede você de realizar seu trabalho da
maneira mais eficiente possível?
©Alison Rabelo | twitter.com\alisonrabelo

30
Daily Scrum Meeting
11) Os membros da equipe devem manter o foco nas
respostas à aquelas três questões.
12) Devem ser evitados outros assuntos, como questões
técnicas, discussões sobre problemas, fofocas, etc.
13) Uma pessoa deve falar pode vez e relatar o status das
suas tarefas. Todos devem ouvi-lo. Não é permitido
conversas paralelas.
14) Se um membro de equipe relata algo de interesse de
outros ou alguns membros necessitam ajuda de
outros membros, estas questões deverão ser tratadas
após o final da reunião.

©Alison Rabelo | twitter.com\alisonrabelo

Sprint Review Meeting


1) Possui tempo fixo proposto de 4 horas.
2) O time não deve gastar mais que 1 hora se preparando
para a reunião.
3) O objetivo da revisão do Sprint é que a equipe apresente
ao Product Owner e às partes interessadas as
funcionalidades dos software que foram concluídas.
4) Embora o significado de “concluída” possa variar de uma
organização para outra, para o Scrum significa que a
funcionalidade foi completamente desenvolvida e poder
ser colocada em produção.
5) Funcionalidade que não foi concluída não poderá ser
apresentada.
©Alison Rabelo | twitter.com\alisonrabelo

31
Sprint Review Meeting
6) Artefatos e documentação não devem ser apresentados, a
menos que sirvam para esclarecer o entendimento das
funcionalidades apresentadas.
7) Artefatos não devem ser mostrados como produtos de
trabalho e seu uso deve ser minimizado de forma a evitar
deixar confusas as partes interessadas ou a requerer que
eles entendam como o desenvolvimento de sistemas
funciona.
8) Funcionalidades devem ser apresentadas nos
computadores dos membros da equipe a partir do
servidor mais próximo da produção, usualmente um
servidor de QA (Quality Assurance)
©Alison Rabelo | twitter.com\alisonrabelo

Sprint Review Meeting


9) A revisão do Sprint começa com a equipe
apresentando os objetivos do Sprint, todos os itens
do Sprint Backlog e os itens que foram concluídos.
10) Os membros da equipe podem então discutir o que
foi bem e que não foi bem no Sprint.
11) A maior parte da reunião é gasta com a equipe
apresentando as funcionalidades, respondendo
questões das partes interessadas relativas a
apresentação e anotando as mudanças desejadas.

©Alison Rabelo | twitter.com\alisonrabelo

32
Sprint Review Meeting
12) No fim da apresentação, as partes interessadas são
consultadas, uma por uma, para dar as suas
impressões, seus desejos de mudança e a prioridade
dessas mudanças.
13) O Product Owner discute com as partes interessadas
e a equipe a reordenação do Product Backlog a partir
do feedback dado.
14) As partes interessadas são livres pra fazer quaisquer
comentários, observações e críticas a respeito dos
incrementos de funcionalidade do produto.

©Alison Rabelo | twitter.com\alisonrabelo

Sprint Review Meeting


15) As partes interessadas podem identificar o que não
foi entregue ou que não foi entregue como esperado
e solicitar que tal funcionalidade seja colocada no
Product Backlog para priorização.
16) As partes interessadas podem identificar qualquer
nova funcionalidade não prevista e solicitar que esta
seja incluída no Product Backlog para receber uma
prioridade.
17) Ao final da reunião, o ScrumMaster anuncia o lugar e
a data da próxima revisão ao Product Owner e às
partes interessadas.

©Alison Rabelo | twitter.com\alisonrabelo

33
Sprint Retrospective Meeting
 Tem tempo fixo de 3 horas.
 Participantes:
 Equipe Scrum
 ScrumMaster
 Product Owner (opcional)
 A reunião começa com os participantes respondendo a
duas questões:
 O que foi bem no último Sprint?
 O que pode ser melhorado no próximo Sprint?
 O ScrumMaster anota as respostas dadas pelos
participantes em um formulário.

©Alison Rabelo | twitter.com\alisonrabelo

Sprint Retrospective Meeting


 O time realiza comentários sobre as respostas.
 O ScrumMaster não tem permissão para responder as
duas perguntas. Ele deve apenas ajudar o time na
busca por melhorias no trabalho com o processo
Scrum.
 Itens que podem ser adicionados no próximo Sprint
devem ser listados como requisitos não-funcionais de
alta prioridade no Product Backlog.

©Alison Rabelo | twitter.com\alisonrabelo

34