papel do po métodos Ágeis€¦ · lidera o esforço de desenvolvimento para criar um produto que...

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