Slide 1 - Guilherme Marques

Scrum
IT Depends on Common Sense
Motivadores
1. Temos que introduzir no processo de desenvolvimento um
grande aumento de produtividade para conseguir atender à
demanda prevista de sistemas;
2. Temos que garantir a qualidade do que é produzido.
3. Temos que caracterizar a mútua responsabilidade
construção /
testes dos sistemas – o processo
desenvolvimento é uma tarefa que exige colaboração
desenvolvedores, definidores de sistemas e usuários
funcionalidades.
na
de
de
de
Motivadores
4. Temos que migrar da atual realidade onde os sistemas são
construídos sem planejamento, para um método de trabalho
que permita planejar e controlar os trabalhos.
A transparência do processo tem de ser total, para todos os
envolvidos (dono do produto, facilitador e equipe:usuários e
informatas)
NOVOS REQUISITOS OBRIGATÓRIOS:
- Roteiro: Corrida do ouro no Egito
- Roteiro:
Olimpíadas
Pequim
Martian
Tourist
Brochure
Backlog
- Opção de viagem passando pelo Sol (descrever o valor)
Create cover art, brand, and/or logo
Define major topics for Martian tourism
Describe “Art Interests in Europe” tour
Describe a tour based on photosynthesis
Outline a “7 wonders of the world” expedition
GOAL: DELIVER A
BROSCHURE FOR THE
EARTH TOURIST BOARD
LOCATED ON MARS
Timebox: 25 min.
Set prices for the tours
Outline warning messages (gravity, oxygen,
fungi,etc.)
Suggest clothing options
Explain travel options to/from Mars
Describe a “Human Sports” tour
Outline refund policy
Suggest related services
Define advertisers
Define a 12-month campaign
Set-up how to get more information
Retrospective
"Regardless of what we discover, we understand and truly believe that
everyone did the best job they could, given
what they knew at the time, their skills and abilities,
the resources available, and the situation at hand"
(Kerth, Project Retrospectives, 2001)
O que aconteceu?
Scrum
2.1. Manifesto Ágil
O desenvolvimento ágil descreve abordagens de desenvolvimento
que seguem os seguintes princípios:
"Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse
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."
2.2. O que é o Scrum?
2.2. O que é o Scrum?
• Gerenciamento empírico e controle de processo
• Inspeção e adaptação com base em feedback
• Usado para gerenciar projetos complexos desde 1990
• Entrega de funcionalidades de negócio em 30 dias
• Escalabilidade na distribuição de projetos grandes e longos
• Compatível com CMM Level 3 e ISO 9001
• Extremamente simples mas de difícil implementação
2.3. Princípios
• Equipes auto-organizáveis
2.3. Princípios
• Time responsável e comprometido
• Honestidade
• Transparência
• Partes potencialmente entregáveis
• Timebox
2.4. SMART Objectives
• S pecific - específicos
• M easurable - mensuráveis
• A achivable - alcançáveis
• R ealistic - realísticos
• T imed - programado
www.glogerconsulting.de
Exercício: A arte do possível
Explore a diferença entre planejar uma festa iniciando todas as frases com:
“sim, mas”
www.glogerconsulting.de
“sim, e”
3. Papéis no Scrum
Atividade
Papel
Responsabilidade
Gerencia a
visão
Product
Owner
O Product Owner estabelece, mantem viva e comunica a visão do produto. Ele demonstra que o
projeto é alcançável e o financia criando a visão dos releases e do Product Backlog inicial.
Gerencia o
ROI
Gerencia as
iterações de
desenvolvimento
Gerencia o
processo
Gerencia os
releases
Product
Owner
Team
Scrum
Master
Product
Owner
O Product Owner monitora o projeto, mantém de acordo com o ROI estabelecido. Ele atualiza as
prioridade do Product Backlog para assegurar-se que as tarefas de maior valor funcional sejam
produzidas primeiro. Ele prioriza o Product Backlog and mede o sucesso para assegurar que o
projeto está no caminho certo.
Durante uma iteração o time seleciona e desenvolve os requisitos de maior prioridade do Product
Backlog. Coletivamente, o time expande os itens do Product Backlog para tarefas mais explícitas no
Sprint Backlog e gerenciam o trabalho e a sua própria organização para entregar os itens desejados
naquela iteração. O time se gerencia para cumprir o compromissos.
O Scrum Master é responsável por ajustar a equipe acima tentando assegurar o sucesso do projeto
e otimizar a cultura organizacional para encontrar os objetivos no projeto. Isto envolve organizar a
Sprint Planning Meeting, a Sprint Review Meeting, protegendo a equipe dos distúrbios externos,
realizando as Daily Scrum Meetings, e removendo impedimentos para o progresso do projeto.
O Product Owner toma decisões sobre quando criar um release oficial. Por uma série de razões não
é desejável liberar um realease a cada incremento. O Product Owner toma esta decisões de
maneira consistente com base na visão de investimento que foi estabelecida para o projeto.
3.1. Questionamento a respeito dos papéis
• O que ocorre quando o Scrum Master faz parte do time?
• O que ocorre quando o Scrum Master assume o papel de Product
Owner?
• Tempo: 5 minutos (Timebox)
3.1. Questionamento a respeito dos papéis
05 Product Owner
01 Scrum Master
O que David deve fazer?
4. Fluxo do Scrum
4.1. O que é um Backlog Item?
Como <user role> eu quero <feature>
para que <business value>
4.2. Product Backlog
•
Lista de funcionalidades, tecnologia a ser aplicada, issues
•
Issues são situações/assuntos do projeto que terão o trabalho definido mais tarde
•
Itens priorizados e estimados
•
Maior detalhamento sobre os itens de maior prioridade
•
O Product Owner é responsável pela priorização
•
Qualquer um da equipe pode contribuir
•
Mantido e fixado em local visível
•
Derivado do plano de negócio e da visão estabelecida, que tem que ser criada em conjunto com o
cliente
•
Estimation Meeting
Planning Poker
•
•
•
•
•
•
•
•
Chile
Argentina
Venezuela
Brasil
Uruguai
Paraguai
Egito
Itália
• 1, 2, 3, 5, 8, 13, 21
4.3. Sprint Planning 1
• Definir o Sprint Goal e o Selected Product Backlog
• Para cada Backlog Item do Product Backlog
– O Product Owner deve explicar a história por trás do item
– Cada membro da equipe deve mostrar a sua estimativa para o
item
– Se as estimativas da equipe forem diferentes, o menor e o
maior valor devem ser explicados até que cheguem em um
acordo
4.4. Sprint Planning 2
• Define as tarefas para realizar o Sprint Backlog e alinha ao Sprint
Goal
• Junta a estimativa com a realidade da equipe e do projeto
• Design é detalhado nesta sessão
• Vamos ao quadro!
4.6. Monitor the task board
• Sprint Burndown
• Product Burndown
• Velocity per Sprint
• Chart: business value evolution
4.5. Daily Meeting
• Objetivo: Sincronizar a equipe
– Quais as tarefas foram realizadas ontem?
– Quais as tarefas serão desempenhadas hoje?
– Quais os impedimentos encontrados durante o seu trabalho?
• Mover as tarefas dentro do quadro de acordo com a sua execução
• Resultados
– Atualização do Impediment Backlog
– Atualização do Sprint Backlog
– Atualização dos gráficos Burndown
• Novas funcionalidades que surgirem serão armazenadas para avaliação ao final
do Sprint
Done!
• Quando uma tarefa esta realmente concluída?
4.9. Impediments Backlog
• Backlog de Impedimentos (podem ser para a equipe ou para a
organização resolver)
Recursos
Skills
Prazo impossível
Infra-estrutura
Ausência de feedback pelo cliente
Escopo não definido
Escopo em constante mudança
Problemas contratuais
Falta de prioridade
Falta de unidade entre equipes
Burocracia
4.7. Sprint Abnormal Termination
• Sprints podem ser cancelados antes do final do Sprint
4.8. Sprint Review
• O team deve apresentar os resultados do Sprint e as novas
funcionalidades desenvolvidas
• Se surgirem novas funcionalidades ou alteração, os novos itens irão
para o Backlog para serem estimados e priorizados
• O team deve reportar os impedimentos durante o
desenvolvimento
• Ao final todos envolvidos no projeto devem entender a evolução
do projeto e os impedimentos
4.10. Sprint Retrospective
• O processo é aprimorado ao final de cada Sprint
• Facilitado pelo ScrumMaster
• O que aconteceu de bom que nóspodemos utilizar
como melhoria?
• ScrumMaster basea a prioridade de acordo com o team
• A equipe planeja a solução dos problemas de sua responsabilidade
4.11. Listagem de artefatos
•
•
•
•
Product Backlog
Sprint Backlog
Impediments Backlog
Bugs Backlog
• Chart: business value evolution
• Product Burndown
• Sprint Burndown
• Velocity per Sprint
Escalabilidade no SCRUM
Chickens and Pigs
Velocity Game
GO GO GO!
Retrospectiva AINFO
“Independente do que nós descubramos, nós compreendemos e
acreditamos verdadeiramente que todos fizeram o melhor trabalho
que poderiam, naquele momento deram o que sabiam, seus
conhecimentos e suas habilidades, os recursos disponíveis, e a
situação disponível.”
Timeline
Retrospectiva
• O que ocorreu bem?
• O que pode ser melhorado?
– Dividir em “Team” e “Organization”