Workshop SCRUM Product Owner - Delírio de PO em dia de Verão

8/9/2019 Workshop SCRUM Product Owner - Delrio de PO em dia de Vero

1/[email protected] 4 Plus

p

Workshop

Product OwnerDelrios de um PO em dia de vero

Rildo F [email protected]

twitter: @rildosanskype: rildo.f.santos

http://rildosan.blogspot.com/

11) 9123-535811) 9962-4260

www.etecnologia.com.br



p

Rildo F. Santos, CSM, CSPO

Tem mais de 10.000 horas de experincia em Gesto de Negcios, Governana eEngenharia de Software.Formado em Administrao de Empresas, Ps-Graduado Didtica do Ensino Superior

e Mestre em Engenharia de Software pela Universidade Mackenzie.

Atua em Gesto de Negcio (Inovao, Processos e GRC) e em projetos deEngenharia de Software utilizando mtodos Agile (SCRUM, Lean, XP e FDD) AgileCoach.

Foi instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java na SunMicrosystems e da IBM.

Conhece Arquitetura de Software, SOA (Arquitetura Orientado a Servio), RUP/UP -Processo Unificado, Business Intelligence, Gesto de Risco de TI entre outrastecnologias.

Professor de curso de MBA da Fiap e foi professor de ps-graduao da Fasp e IBTA.

Tem forte conhecimentos de Gesto de Negcio (Inteligncia de Negcio, Gesto porProcesso, Inovao, Gesto de Projetos e GRC - Governance, Risk and Compliance),SOX, Basel II e PCI;

Tem vivncia na implementao de Governana de TI e Gerenciamento de Serviosde TI, Conhecimento dos principais frameworks e padres: ITIL, Cobit, ISO 27001 eISO 15999;

Desempenhou diversos papis como: Estrategista de Negcio, Gerente de Negcio,Gerente de Projeto, Arquiteto de Software, Projetista de Software e Analista deSistema em diversos projetos em empresas como: Bradesco, Editora Abril, Scopus,Porto Seguro, Certagy, Secretria da Fazenda SP, Sonagol (Angola),Honda, Dix-Amico, Bank Tokyo-Mitsubishi, Vivo, Hospital das Clinicas, Aos Villares,

Novabase do Brasil, Policia Militar do Estado de So Paulo entre outras.

Possui as certificaes: CSM - Certified SCRUM Master, CSPO - Certified SCRUMProduct Owner ,SUN Java Certified Instrutor , ITIL Foundation e Instrutor Oficial deCobit Foundation e Cobit Games;

membro: IIBA-International Institute of Business Analysis (Canada)

Twitter: @rildosan

Blog: http://rildosan.blogspot.com/
http://twitter.com/rildosanhttp://twitter.com/rildosanhttp://twitter.com/rildosan



p

Enquete 1:

Quem mais se parece com o PO ?

( ) House, MD ( ) Darth Vader

( ) Chapolin ( ) Saci-Perer



p

Enquete 2:

Qual a Viso do PO ?



p

Introduo:

Em projetos geis o Scrum Master responsvel porgarantir o processo e que as prticas Scrum sejamseguidas. J o Product Owner (PO) responsvel pelo

produto e pelo ROI do projeto, isto faz que o papel dePO seja um fator critico de sucesso.O PO deve trabalhar totalmente alinhado e integradocom o time para que o ROI seja alcanado. EsteeBook tem como objetivo fazer uma introduo sobreo tema Product Owner e apresenta uma viso prtica

e prover conhecimentos bsicos sobre o papel deProduct Owner (PO) e sua atuao nos projetos geis.

Ser demonstrado como PO pode otimizar osresultados do projeto e gerar valor para o cliente.

Tambm apresentado as principais tcnicas eferramentas que ajudam PO a criar um Plano deRelease realista. Elaborar, gerenciar e priorizar oProduct Backlog, e desenvolver o Release Burndownpara acompanhar o progresso do projeto.



p

Quais os desafios dodesenvolvimento

de Software ?



p

O cliente QUER respostas:

Quanto custar ?

O cliente quer saber quanto custar o software...

Quanto estar pronto ?O cliente quer saber quanto o software estar prontopara ele usar...

Responder sobre curso e prazo:



p

Entender o qu o cliente quer

Como melhorar a comunicao entre o cliente e

os desenvolvedores ?



p

Identificar os pontos crticos que levam os projetosao insucesso ?

37% das falhasestorelacionadascom requisitos

Craig Larman,Agile and Iterative Development: A Managers Guide, AddisonWesley Professional (2004)

9

Informaoerrada

13%Requisitosincompletos

12%

Mudana de

Requisitos

12%Falta de

conhecimentotcnico

7%Falta de

competncia

6%

Outros

50%

Sempre

7% Freqentemente

13%

As vezes

16%

Raramente19%

Nunca

45%

Contudo, amaioria dasfuncionalidades nuncaso usadaspelosusurios

Saber quais funcionalidades principais do Software



p

Como aumentar a produtividade da equipede desenvolvimento de software ?

Satisfao dos Clientes

Aumentar a produtividade:



p

Entendendo o SCRUM



p

O que o SCRUM ?

Ken Schwaber

O que o SCRUM ?SCRUM um processo iterativo eincremental para desenvolvimento dequalquer produto ou gerenciamento

de qualquer trabalho...

SCRUM :Processo emprico de gerenciamentoe controle.- Faz a inspeo e adaptao emloops de feedback

- Faz entrega de valor ao cliente emat 30 dias;- Escalvel para suportar grandesprojetos- Compatvel com CMM3 e ISO9001- Extremamente simples, mas muitoresistente...

Valores do Scrum::- Transparncia-Integridade: assim que perceberalgo, faa algo

- Ser emprico- Auto-organizao

- Entrega de valor

As origens

SCRUM um Mtodo GIL para desenvolvimento de software

The New, NewProduct

DevelopmentGame

TimeBoxes

Iterative,Incremental

Development

SmallTalkEngineering Tools



p

A ALMA do SCRUM:

artefatos

SprintBacklog

Produto

Planejamentoda Sprint

Reuniodiria

2-4 Semanas

24 horas

Revisoda Sprint

Retrospectivada Sprint

Viso

Cerimnias

Burndown

ProdutoBacklog

Product Owner (PO) ScrumMaster (SM) Equipe Scrum

Planejamento da Sprint Reunio Diria Reviso da Sprint

Retrospectiva da Sprint

Product Backlog Sprint Backlog Burndown (grfico)

Papis Cerimnias Artefatos

Legenda:



p

Desenvolvimento Iterativo e Incremental:

Devido a complexidade, tamanho,mudanas de requisitos, urgncia enecessidade de demonstrar valor maisrpido, fica quase inconcebveldesenvolver software utilizado o modelocascata, ou seja desenvolvertodo o software de uma nica vez.

Desenvolvimento Iterativo e incremental uma estratgia de planejamento (quesegue a linha dividir para conquistar ),onde o software construdo em partes,ou seja, em ciclos (iteraes), a cadaiterao feito um novo incremento (partedo software funcional) at completar o

software.

Incremental

Entrega 1 Entrega 2 Entrega 3

Iterativo



p

Planejar ou no Planejar ?

Planejamentogil

Os 4 Nveis do Planejamento:

1 2 3 4 5 6

Plano de Release (do Produto)

Sprint #

Release #1 Release #2 Release #3

Tarefas

Verso 0.5 Verso 0.8 Verso 1.0

Sprint Burn Down

Reunio diria

Release Burn Down

Viso doPlanejamentoRelease #

Tempo

Viso doProduto



p

SCRUM: Papis e Responsabilidades:

Equipe SCRUM responsvel por:

- Fazer estimativa;- Definir as tarefas;- Desenvolver o produto;- Garantir a qualidade do produto;- Apresentar o produto ao clienteEquipe: auto-gerencivel e multifuncional

SCRUM Master responsvel por:

- Ser um lder (servidor);- Remover impedimentos;- Proteger a equipe;- Ajudar o PO (com Product Backlog);- Ser o facilitador da equipe;- Garantir as prticas SCRUM.

O SCRUM tem trs papis: Product Onwer (PO), SCRUM Master(SM) e a equipe SCRUM.

?



p

Responsabilidades do PO:

Principais responsabilidades PO:

Criar, Manter, Priorizaro Product Backlog

Representar a voz do cliente

Garantir o ROI

Criar, manter ecomunicar aviso do produto

Aceitar ou rejeitar entregas

Ajudar no entendimentodo qu deve ser feito.Definir metas e objetivodas Sprints.

(Reunio de Planejamen



p

Ferramentas do PO:

Principais responsabilidades PO:

Product Backlog

Release Burn down

Plano de Release



p

Caractersticas do PO:

Principais caractersticas desejveis e as indesejveis:

Desejveis (obrigatrias)

- Saber entender a necessidade do cliente e

usurios;

- Ter habilidade para criar, manter ecomunicar a viso do produto;

- Entender o que valor para o cliente;

- Ser Lder e Facilitador;

- Ter poder deciso sobre o projeto;

- Ser comprometimento com cliente, projetoe com a equipe;

- Manter um bom relacionamento comstakeholder

Indesejveis:

- Ser uma pessoa sem tempo;

- Ser adepto do micro-gerenciamento(comando controle);

- No conhecer o produto ou negcio;

- Falta de coragem para tomar decisosobre o projeto;

- Ser (ou agir como) o Dart Vader;

- Inabilidade tcnica:- Falta de conhecimento do SCRUM- Viso mal definida ou incompleta

- Product Backlog mal priorizado



p

A Equipe e Comprometimento:

Product Onwer

Equipe SCRUM Master

ComprometidosEnvolvidos

Stakeholders(clientes e usuriosfinais)



p

Cerimnias que o PO deve participar:

Reunio de Planejamento da Sprint (8 horas)

Reunio Diria (15 minutos)

Reviso da Sprint (4 horas*)

Retrospectiva da Sprint (3 horas*)

Participantes: PO, Equipe e SCRUM MASTER

Participantes: Equipe e SCRUM MASTER

Participantes: PO, Equipe e SCRUM MASTER

Participantes: Equipe e SCRUM MASTER

Nesta reunio somente membros da equipe devem

participar. A durao dela de 15 minutos. As pessoasfazem a reunio de p. O objetivo desta reunio fazerque as pessoas respondam 3 questes:- O que eu fiz ontem ?- O que vou fazer hoje ?- Encontrei algum impedimento ?

Esta reunio acontece no final da Sprint, opcionalmente outraspessoas podem ser convidadas (se necessrio).O objetivo da reunio apresentar o que a equipe fez durante aSprint e fazer a entrega do produto (software funcionando) para oPO. (Normalmente apresentado uma demo do software).Geralmente ela feita em um auditrio ou em uma sala de reunio

Esta reunio acontece logo aps a Reviso da Sprint.O objetivo dela avaliar o que deu certo e que deu erradodurante a Sprint, e fazer os ajustes possveis para a prximaSprint, ou seja, o ciclo de melhoria contnua.

Esta reunio primeira reunio, seu objetivo fazero planejamento da Sprint. Ela dividida em duas partes.Na

primeira parte o PO definir prioridade, seleo dos itens dobacklog e meta da Sprint.Na segunda parte a equipe definir a Sprint Backlog (que soas tarefas necessrias para cumprir a meta).

Nota: * A quantidade de horas pode variar de acordo com a necessidade (por exemplo, apresentao do que serentregue ao cliente) ou aquilo que ser discutido/debatido, neste caso a Retrospectiva ela poder variar entre 1 a 3 hora



p

Definido a Viso do Produto:

Viso do Produto:

Product Owner

Product Owner (PO), responsvel por definir, mantere comunicar a Viso do Produto para todos osstakeholders.

PO deve compartilhar e refinar a viso com a equipe.

Declarao do Elevador (Elevator Statement) uma tcnica queajuda o PO a escrever a Viso do Produto.

Tcnica: Declarao do Elevador (Elevator Statement)

Exemplo de Viso do Produto:Para empresas mdias de marketing e departamento de vendasque necessitam de um sistema de CRM, o EeaseCRM umsoftware baseado na web, intuitivo e fcil de usar que fornece apossibilidade fazer a rastreabilidade de vendas, gerao de leadse possibilita o estreitamento do relacionamento com o cliente.Diferente de outros servios ou produtos, nosso produto oferecea melhor relao custo beneficio.

For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category)

That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation)

A declarao de Viso do Produto deve ser simples, consistente,objetiva e fcil entendimento, que tem informaes sobre a

necessidade do cliente, o que produto esperado e quais sos osseus principais benefcios.A declarao ainda deve descrever a motivao e o diferencial doproduto em relao aos outros.



p

Definido a Viso do Produto:

Viso do Produto:

Product Owner

Product Owner (PO), pode utilizar fazer este exercciopara compartilhar a viso com a equipe.

Product Vision Box

Informaes sobre o produto:

- Nome do Produto:

- Logotipo ou desenho querepresente o produto

- Principais benefcios que ajuda avender o produto

- Principais caractersticas e/oufuncionalidades do produto

- Principais requisitos tcnicos

Product Vision Box uma tcnica que ajuda no entendimentoda Viso do Produto, pois, quando fazemos uma representaovisual do produto (embalagem, por exemplo) isto auxilia na reduodo nvel de abstrao.

Fonte:

Agile Project Management: Creating Innovative Products -Jim HighsmithCap. 5 - Practice: Product Vision Box and Elevator Test - Pg. 93



p

Elaborar o Plano de Release:

Plano de Release um viso do produto em relao a linha dotempo. Inicialmente este plano divido em releases, sendo que nofinal de cada release dever ser entregue um produto (softwarefuncionando) e na ltima release dever ser entregue o produto

completo com todas as funcionalidades. As releases so dividasem iteraes (Sprints)

Product Owner

Product Owner (PO), responsvel por criar, manter oPlano de Release

1 2 3 4 5 6

Plano de Release (do Produto)

Sprint #

Release #1 Release #2 Release #3

Verso 0.5 Verso 0.8 Verso 1.0

Sprint Burn Down

Release Burn Down

Viso doPlanejamentoRelease #

Tempo

Viso do Produto

ProductBacklog

TaskBoard



p

Criando: Product Backlog

O que Product Backlog ? uma lista contendo todas as funcionalidades desejadas para umproduto.O produto deve ter somente um Product Backlog (PB)

independente nmero de equipes que est trabalhando no projeto.PB poder ser criado de diversas maneiras:- Com Estrias de usurio- Com Casos de Uso- Com features (funcionalidades de produto)

Product Owner

Product Owner (PO), responsvel por elaborar e manterProduct Backlog atualizado, bem como priorizar seus itens.

Exemplo de Product Backlog: Sistema de Reserva On-Line

release



p

A priorizao do Product Backlog deve ser por tema (categoria), jque a priorizar por estria, nem sempre possvel, pois, poder existirgrau de dependncias entre estrias.Fatores de Priorizao:- Valor- Custo- Risco

Tcnicas:- Kano: Composta por entrevistas com os usurios e opinies deespecialistas.- Theme Screening: Composta por opinies de especialistas baseadas

em comparao realizadas com um tema importante.

Product Owner

Product Owner (PO), responsvel por priorizar seus

itens do Product Backlog

Exemplo de Product Backlog: Sistema de Reserva On-Line

Product Backlog. Priorizao:



p

Modelo Kano: um modelo desenvolvido por Noriaki Kano que usado paracompreender as preferncias do cliente (ou usurio).

O modelo Kano tem 3 tipos de funcionalidades:- Desejadas: So aquelas funcionalidades que o usurio deseja, masno tem plena certeza;

- Linear: Quantas mais destas tiver melhor

- Mandatrio: Deve estar presente para que o cliente esteja satisfeito.

Para saber qual o tipo de cada funcionalidade, podemos fazer oseguinte:- Fazer as perguntas direcionadas para um grupo de no mximo 20usurios com perfis diferentes;

- Realizar uma pergunta funcional:

Se na prxima release incluir a emisso da Ordem de Servio (OS),como voc se sentira?[ X ] Eu vou gostar[ ] Eu acho que deveria incluir[ ] Indiferente[ ] Posso tolerar[ ] Eu no gostaria disto

- Fazer uma pergunta disfuncional:Se na prxima release NO incluir a emisso da Ordem de Servio(OS), como voc se sentira?[ ] Eu vou gostar[ X ] Eu acho que deveria incluir[ ] Indiferente[ ] Posso tolerar

[ ] Eu no gostaria disto




p

Modelo Kano: Como Priorizar


Funcio

nal

Disfuncional

M MandatrioL LinearD DesejadoQ QuestionvelR ReversoI IndiferenteNo gostaria

indiferente

Gostaria

Posso tolerar

(acho ) deveria

Gostaria

(acho)

deveria

indiferente

Possotole

rar

Nogosta

ria

Q

R

R

R

R R R R

D D D

Mandatrio

Linear

Desejada

Indiferente

Reserva

Questionvel

Temas

Emisso de Ordem de Servio

Cadastro de Cliente

Cadastro de Produto

13 11 41 3 2

422 9 14 5 1 3

2120

1 06

Legenda:

O que incluir na Sprint ?

- Todas as funcionalidades Mandatrias- Algumas funcionalidades Lineares

- Mas deixe um espao para as funcionalidades desejadas



p

Estimar Difcil ?

Agile Story points Ideal days

SeqencialLinhas de Cdigo Pontos de Funo

Story Points: Valores relativos Mais abstrato

Ideal Days Mais fcil para iniciantes Fcil de explicar

Estimativa (Mundo real) = Valor aproximado

Estimativa (TI) = Valor exato

Tamanho Durao



p

3

Estria do Usurio (User Story):

O que uma estria (user story) ? uma pequena descrio, que detalha um itemdo Product Backlog.

Para que serve a Estria:

Uma estria ajuda no entendimento e tambm ,utilizada como lembrete e para as atividades deplanejamento. Ele tambm permite fazer a estimativade velocidade da equipe e a durao da Sprint.Geralmente a estimativa feita em pontos (storypoints) ou horas/dias (dias ideais).

Como escrever uma estria:

Conversaes sobre a estria, entre os usurios edesenvolvedores, de modo a detalhar o item eesclarecer todas as dvidas sobre o que deve ser feito.

Exemplos de Estrias do Usurio:

Titulo: Pagamento com Carto de Crdito Prioridade: 1-Alta

Por que ?Com objetivo de facilitar o pagamento das despesas dos clientes,

Quem ?

como um desenvolvedor

O que ?

devo implementar uma interface para pagamentos por carto de

crdito que seja intuitiva e fcil de usar.

Obs: Os carto aceitos so: Visa, Master e Amex.

Titulo: Ver preo do produto Prioridade: 3-Baixa

Como cliente quero ver o preo do produto quando eu passar

o cdigo do produto pelo leitor de cdigo de barras.

Seguindoum padro

Estilo MikeCohn

Pontos: 7

Pontos: 5



p

Escrevendo estrias:

INVEST significa:

Indepent (Independente): Mesmo sendo impossvel para alguns sistemas,

tenha em mente que uma User Story deve ser Independente

Negotiable (Negocivel): Uma User Story no um contrato. No umaespecificao detalhada. apenas uma introduo s funcionalidades paraque a equipe possa discutir e colaborar para esclarecer os detalhes prximoao momento de desenvolver a funcionalidade.

Valuable (Valiosa): Uma User Story deve ser valiosa para o cliente. Deve

ser escrita em linguagemde negcio. Deve ser descrio de uma funcionalidade, no uma tarefa.

Estimatable (Estimvel): User stories devem ser passveis de seremestimadas. Devem prover informao suficiente para serem estimadas, semserem muito detalhadas.

Small (Pequena): Nem pequena demais, nem grande demais. User Stories

devem ser do tamanho suficiente para entendimento do a funcionalidade;

Testable (Testvel): User Stories devem ser claras o suficiente para seremtestveis.

Kelly Waters tem escrito h muito tempo sobre User Stories, introduzindo oconceito deINVESTcomo uma definio clara sobre como trabalhar com esta ferramenta.Segundo ele uma boa estria deve ter seis atributos (INVEST*):



p

Estimativa* e o Planning Poker:

Geralmente o Planning Poker usa uma escala depontos, que pode ser baseada no Fibonacci:(1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala.Jogando o Planning Poker:Antes de comear o jogo, ou seja, definir os pontos paraas estrias, importante definir um valor dereferncia. Exemplo: Identificar a estria que pode seratribudo dois pontos, ento ela ser utilizada comoreferncia para pontuao das demais estrias.

Para fazer estimativa de velocidade da equipe ou de durao da Sprint, antes preciso o escrever as estrias do usurio.O Planning Poker a prtica que ajuda na estimativa de uma estria oude uma tarefa.

Pessoal, qualestimativa paraessa estria...

Product Owner Equipe

85

8

Equipe

8 5 ?

8 8

Na reunio de Planejamento da Sprint, a equipe joga o Planning Poker edefine a estimava de velocidade da equipe e a durao da Sprint.

Nota 1 Estimativa*Para fazer as estimativa, voc deve levar em considerao outros aspectos alm da codificao, como por exemplo: test

de aceitao, teste unitrios preparao do ambiente de teste e outras coisas que so necessrio e importantes (mesmoque de baixo valor) para que voc entregue o software funcionando.



p

Definio de Feito (DoD):

Definir claramente quando o produtoestar Feito:

Feito, para desenvolvedor:- Encerrou a codificao...

Feito, para Analista de Teste (Q&A):- Quando ele encerrou o teste e noencontrou nenhum bug...

Feito, para PO:- Quando foi entregue...

Feito, para os usurios finais e/ouclientes:- Quando o software comeou afuncionar em ambiente de produo...

Ao final de cada Sprint a equipe dever fazer uma entrega de valor para ocliente (PO e demais Stakeholders).Segundo Manifesto gil, valor para o cliente igual a Softwarefuncionando.Logo para fazer tal entrega, na reunio de Planejamento da Sprint, ser

imprescindvel definir a Definio de Feito.Isto evitar problemas e frustraes futuras nas reunies de Reviso eRetrospectiva da Sprint.

Evite: A sndrome dos 90% feito (pronto).

Na reunio de Planejamento da Sprint, o PO e a equipe devemdefinir a definio de pronto para Sprint



p

Artefato: Sprint Backlog

Dicas para montar um bom Sprint Backlog:

1 Toda a equipe deve participar da elaborao da Sprint Backlog;2 Faa uma definio de feito (DoD), veja o prximo slide;3Tente identificar todas as tarefas, lembre-se que algumas tarefas so puramente tcnicas, porexemplo: realizao de Teste Unitrio.

4 Respeite o tempo para realizao desta atividade, pois a Reunio de Planejamento um timebox.

O Sprint Backlog uma lista de tarefas que equipe se compromete a fazerem uma Sprint. A Sprint Backlog elaborada na segunda parte dareunio de Planejamento da Sprint.

Para atingir a meta da Sprint a equipe dever fazer as tarefas da Sprint

Backlog.

Tarefa:

Cadastrode Cliente

Incluir novocliente

alterarcliente

consultarcliente

Titulo: Precisamos registrar os dados dos clientes Prioridade: 1-Alta

Todos os dados do cliente dever ser registrado. A busca de clientedever ser fcil e intuitiva.

EstriadoUsurio:

Quando os clientes esto registrado, ser possvel alterar os dadosse necessrio.

O cliente dever ter um status para que se possa definir quaisso os clientes ativos e os inativos

Pontos: 8

Sprint Backlog

Selected Product Backlog (itens selecionados do Product Backlog)

tarefas



p

Quebrando estria em tarefas:

Na reunio de Planejamento da Sprint, a equipequebra as estrias em tarefas, o foco deve sernaquilo que precisa ser feito.

Cadastrode Cliente

Incluir novo

cliente

alterarcliente

consultarcliente

Fazer TestesUnitrios

Exemplos de tarefas necessrias concluir a Sprint, mas que no soprogramao:

- Preparar um ambiente de teste;- Realizar testes;- Esclarecimento de dvidas;- Discutir detalhes de como ser feito odeploy com a equipe de rollout;

- Escrever documentos de deploy (Requisio de Mudana);- Melhorar os scripts de build.

Para fazer as estimativa, voc deve levar em considerao outros aspectosalm da codificao, como por exemplo: testes de aceitao, testeunitrios, preparao do ambiente de teste e outras coisas que sonecessrio e importantes (mesmo que de baixo valor) para que vocentregue o software funcionando.

Sprint Backlo

tarefas



p

Artefato: Burndown

Pontos

Tempo (dias)

Exemplos de Sprint Burndown

O grfico Burndown a principalferramenta de gerenciamento doprocesso de desenvolvimento desoftware.

Sprint Burndown:

uma ferramenta para equipegerenciar trabalho restante versustempo, ou seja, ele permite visualizar oprogresso e/ou a evoluo do trabalhoexecutado pela a equipe, o trabalho e

tempo (pontos) que ainda faltam paracompletar a Sprint.Atualizao da Sprint Burndown diria, isto facilita a tomada de deciso,podemos decidir como melhorar aprodutividade da equipe e/ou paramitigar o risco da Sprint.

Release Burndown:

uma ferramenta para POgerenciar trabalho restante versustempo restante.PO acompanha o progresso do projetoatravs da entregas feitas (no final decada Sprint).PO deve comparar as entregas feitas como planejamento, Plano de Release e fazerajustar os necessrios para que o Planode Release seja seguido.

Exemplos de Release Burndown



p Task Board (Quadro de Tarefas) quadro que exibe o statusatual da Sprint.

Gesto Vista e Task Board

Burn DownEstrias Para Fazer Em Execuo Feitas (Prontas)

TaskBoard:O Taskboard (tambm chamada do Kanban) d visibilidade e comunica o o

progresso da Sprint.

uma sistema de gesto que uma forte ferramentade comunicao organizacional, pois transmite amensagem muitas vezes sem a necessidade depalavras, somente com a utilizao de smbolos e cores,de modo que todos conseguem receber a mensagem,muitas vezes de uma forma ldica.

A Gesto Vista tem como objetivo disponibilizar asinformaes necessrias de uma forma simples e de

fcil assimilao, buscando tornar mais fcil o trabalhodirio e tambm a busca pela melhoria da qualidade.

Ela torna possvel a divulgao de informaes paraum maior nmero de pessoas simultaneamente eajuda a estabelecer a prtica de compartilhamento doconhecimento como parte da cultura organizacional.

Gesto Vista: D visibilidade e transparncia ao projeto dedesenvolvimento de software.



p

Delrios de um PO em dia de vero:

Os Delrios



p


Delrio 1: Quando o PO insiste em fazer ogerenciamento olhando para Sprint Burndown

isto leva ao micro gerenciamento e aocomando-controle.Sinal: Sndrome da criana viajando de carro...



p

Delrio 2: Quando PO assume ser o dono daverdade. Sndrome de Deus, no aceita

opinio dos outros membros da equipe.

Sinal: PO diz que ele no comete erros...




p

Delrio 3: Quando o PO tenta participar e darpalpite na reunio diria..

Sinal: Aparece sempre no inicio da reunio diria




p

Delrio 4: Quando o PO se auto convida paraparticipar da Retrospectiva.

Sinal: Aparece na Retrospectiva com discursoestou aqui para ajudar...




p

Delrio 5: Quando o PO interrompe rotineiramenteos membros da equipe que esto engajados ementregar o objetivo da Sprint.

Sinal: Interpela com a seguinte pergunta Pessoal

gostaria de saber o que vocs esto fazendo..




p

Delrio 6: Quando o PO quer organizar e distribuiras tarefas, controlar o horrio e dar esporrosnos membros da equipe.Sinal: Quer de qualquer jeito o cronograma deatividades com o nome de quem est fazendo as

tarefas...




p

Delrio 7: Achar que o Gerente de Projeto e quePMBok guia deve ser seguido by the book

Sinal: Comprar o PMBok e deixar encima damesa para que todos vejam...

Pura provocao




p Delrio 8: Quando o PO se acha superior aosoutros membros da equipe

Sinal: Adota o bordo do Roberto Justos:

- Voc est demitido!

Comea a fazer ameaas de demitir os membrosda Equipe ou SM se projeto falhar...




p

Notas:

Marcas Registradas:

Todos os termos mencionados e reconhecidos como MarcaRegistrada e/ou comercial so de responsabilidade de seus

proprietrios. O autor informa no estar associada a nenhum produtoe/ou fornecedor apresentado neste material. No decorrer deste,imagens, nomes de produtos e fabricantes podem ter sido utilizados,e desde j o autor informa que o uso apenas ilustrativo e/oueducativo, no visando ao lucro, favorecimento ou desmerecimentodo produto/fabricante.

Melhoria e Reviso:

Este material esta em processo constante de reviso e melhoria, sevoc encontrou algum problema ou erro envie um e-mail ns.

Criticas e Sugestes:

Ns estamos abertos para receber criticas e sugestes que possammelhorar o material, por favor envie um e-mail para ns.

Rildo F dos Santos ([email protected])

Imagens:

Google, Flickr e Banco de Imagem.



p

Licena:


49/49

p

Workshop

Product OwnerDelrios de um PO em dia de vero

Workshop SCRUM Product Owner - Delírio de PO em dia de Verão

Documents

Transcript of Workshop SCRUM Product Owner - Delírio de PO em dia de Verão