papel do po métodos Ágeis€¦ · lidera o esforço de desenvolvimento para criar um produto que...
TRANSCRIPT
Papel do PO
Métodos Ágeis
Fonte: Adaptworks
Scrum - Visão Geral
● 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
Manifesto Ágil
● Método ágil para gerenciamento de projetos;
● Times Pequenos e auto organizados;
Scrum
Scrum Framework Diagram
Papel do PO
● Lidera o esforço de desenvolvimento para criar um
produto que gere os benefícios desejados;
● Inclui: criar a visão de produto; definir product
backlog, planejar releases; envolver stakeholders;
gerenciar budget, preparar lançamento do
produto; participar das reuniões do Scrum; e
colaborar com o time.
Papel do Product Owner
● Ser a voz do cliente;
● Definir as funcionalidades chave do produto;
● Descrever, priorizar e refinar requisitos
continuamente;
● Ser responsável pelo sucesso do produto e pelo
ROI;
● Definir plano de Release com datas;
● Definir de forma pró-ativa stakeholders e
chickens;
Responsabilidades do PO
● Definir Metas;
● Dar direcionamento ao Trabalho;
● Comunicação frequente com o Dev Team;
● Participar das reuniões do Scrum;
● Gerenciar o Budget;
● Aceitar ou rejeitar entregas (resultados);
● Definir a visão do Produto;
● A agenda de um Product Owner;
Responsabilidades do PO
● PO sem poder de decisão;
● PO com baixa disponibilidade;
● PO distante;
● PO proxy;
● PO da “sua parte”.
Problemas Comuns
Visão do Produto
● PO é o responsável pela criação da visão;
● PO compartilha e refina a visão com o time;
● Coleta informações junto a clientes, usuários
final, time, stakeholders, executivos, etc.;
Visão do Produto
● Definição e objetivos do produto;
● Funcionalidades chave do produto;
● Benefícios para o cliente;
● Atributos de performance e qualidade;
● Arquitetura do produto;
● Dificuldades e riscos;
● Principais marcos do projeto.
Visão do Produto
Product Backlog
Product Backlog
● Derivado de um Plano de Negócios ou Visão de
Produto
● PO é o responsável por sua criação e priorização,
mas todos podem contribuir.
● Lista de funcionalidades, necessidades,...
● Pode ser descrito em: user stories, use cases,
features,...
Product Backlog nunca está completo e dessa
forma está em constante evolução;
Product Backlog
Product Backlog
Requisitos Ready
… se transformam em …
Funcionalidades Done
Condições de Satisfação
Priorização do Backlog
A priorização deve ser por tema (categoria), já que a
priorizar por estória, nem sempre é possível, pois,
poderá existir grau de dependências entre estórias.
Priorização do Product Backlog
Planejamento de Release
● Representa a entrega de conjunto de itens de
grande valor para o usuário em produção;
● É composto pela quantidade de sprints necessários
para formar esse conjunto de itens que definirão a
entrega de grande valor;
● O MVP é o Release.
Release
Planejamento de Release
User Stories
User Stories
User Stories
● Descrição de uma necessidade para um público
específico com um valor de negócio;
● Identificar/conhecer público e definir “personas”;
● PO pode escrever sozinho ou promover story-
writing workshop;
Perfil
Benefícios
Funcionalidades
● PO, com a colaboração de quem achar necessário,
é quem descreve os testes de aceitação e deve
fazê-lo antes da codificação;
● Testes devem fazer parte do processo e devem ser
automatizados sempre que possível.
Teste de Aceitação
Sprint Planning Meeting
● Consiste em duas partes;
● Parte 1: Decisão do que será feito no Sprint;
● PO apresenta para o time os itens do Backlog
priorizados e define a meta do Sprint;
● Resulta no Sprint Backlog: Itens de Backlog
selecionados, suas respectivas tarefas e Meta do
Sprint.
Sprint Planning Meeting #1
● O PO deve falar ao time sobre a visão do produto;
● O PO e o time devem definir a meta do Sprint;
● O time deve realizar a estimativa dos itens do backlog
que não estejam estimados;
● O PO e o Time, em consenso, escolhem os itens que
irão fazer parte do próximo Sprint.
Sprint Planning Meeting #1
● Parte 2: Decisão de como serão construídas as
funcionalidades em um incremento de produto
durante o Sprint;
● As tarefas devem ser decompostas para que
possam ser feitas em menos de um dia.
● PO está presente nessa parte para esclarecer
dúvidas e ajudar a efetuar mudanças;
● Outras pessoas podem ser convidadas para
fornecer um conselho técnico ou específico.
Sprint Planning Meeting #2
Sprint
● Na execução do Sprint valem as práticas de
engenharia definidas para o Projeto;
● ScrumMaster facilita o trabalho do time
removendo impedimentos e garante a boa
aplicação do Scrum;
● Time pode consultar especialistas ou mesmo o
Product Owner;
● Duração de 2 a 4 semanas.
Sprint
Um sprint pode ser terminado antes da sua finalização nas
seguintes situações:
● O time sente que não conseguirá atingir a meta;
● O PO percebe que mudanças em fatores externos
influenciarão diretamente no valor da meta do Sprint.
Caso um sprint seja cancelado deve se iniciar
imediatamente o planejamento do próximo.
Terminar Sprint antes do Final
Daily Meeting
● Reunião de 15 minutos;● Daily é uma reunião do DEV TIME;
● Cada membro deve responder:
o O que fiz desde a última reunião?
o O que pretendo fazer até a próxima?
o Tive algum impedimento?
● Time ganha visibilidade;
● ScrumMaster é o facilitador;
● PO não participa.
Daily Meeting
Sprint Review
● Ocorre no final de cada Sprint;
● Meta do Sprint é um compromisso do TIME;
● TIME demonstra o trabalho que foi feito e responde a
questionamentos;
● TIME deve apresentar software funcionando;
● TIME discute o que correu bem, quais problemas foram
enfrentados e como foram resolvidos;
● Sprint Review fornece input de valor para as Sprint
Planning Meetings seguintes.
Sprint Review
● PO deve aceitar somente produtos que satisfaçam a
definição de PRONTO (DONE) e que atendam aos
critérios de aceite, caso estes tenham sido definidos;
● PO não deve aguardar até o fim do sprint para ter seu
primeiro contato com as funcionalidades, faça isso de
forma just-in-time.
Sprint Review
Retrospective
● Representa o espírito de inspeção-adaptação;
● ScrumMaster encoraja o time a revisar processo de
trabalho, tendo como base as práticas do Scrum.
● PO participa somente quando convidado;
● Finalidade é inspecionar o último Sprint em se
tratando de composição do time, preparativos para
reuniões, DOD, ferramentas, comunicação e processos
para identificação de melhorias a serem aplicadas no
próximo sprint.
Retrospective
PO e Scrum
Resumo Responsabilidades
PO ScrumMaster Time
É responsável pelo
Product Backlog e por
garantir o valor do
trabalho realizado pelo
Time.
É responsável por garantir
que o processo seja
compreendido e seguido.
É responsável por transformar
os itens do Product Backlog em
produto.
- Visão do Produto
- Product Backlog
- Plano de Release
- Release Burndown
- Sprint Planning #1
- Remover Impedimentos
- Proteger o Time
- Ajudar o PO
- Ser o facilitador do Time
- Fazer estimativa
- Definir as tarefas
- Garantir a qualidade do
produto
- Apresentar o produto ao
cliente
- Sprint Planning#1 e #2, Daily,
Review, Retrospectiva
Referências:
● http://www.gettingagile.com/2009/05/01/scrum-is-the-vehicle-not-the-
destination/
● http://pt.slideshare.net/marciamaia/o-papel-do-product-owner
● http://www.agileway.com.br/2010/07/20/story-writing-workshop/
● http://www.euax.com.br/2011/10/priorizando-requisitos-modelo-de-
kano/
● http://pt.slideshare.net/Ridlo/workshop-como-criar-estimar-priorizar-e-
manter-o-product-backlog
● http://www.baguete.com.br/colunistas/colunas/1173/jorge-horacio-
audy/12/02/2013/entendendo-o-papel-do-product-owner-po