Workshop Como Criar, Estimar, Priorizar e Manter o Product Backlog

8/8/2019 Workshop Como Criar, Estimar, Priorizar e Manter o Product Backlog

1/77

[email protected] 1 Ago 2010 | RFS

WorkshopS

CRUM

Todos os direitos reservados e protegidos 2006 e 2010

Rildo F [email protected]

twitter: @rildosan

skype: rildo.f.santoshttp://rildosan.blogspot.com/

(11) 9123-5358(11) 9962-4260

www.etcnologia.com.br

Comocriar,

estimar,priorizar e

manter oProductBacklog


2/77


WorkshopS

CRUM

Todos os direitos reservados e protegidos 2006 e 2010 2

1 Como Criar o Product Backlog

2 Como Estimar o Product Backlog

3 Como Priorizar o Product Backlog

4 Como Manter o Product Backlog

O Contedo do workshop:

1

Criar

2

Estimar

3

Priorizar

4

Manter


3/77


WorkshopS

CRUM


Objetivo:

Objetivo:Compartilhar conhecimento, trocar experincia e prover aprendizado de Como criar,estimar, priorizar e manter o Product Backlog utilizando as melhores prticas, tcnicas eferramentas.

Pr-requisito:Conhecimento do Scrum. Se voc no conhece o Scrum recomendamos fazer o Workshop

SCRUM (http://etecnologia.ning.com/group/scrum ) primeiro e depois esse treinamento.


4/77


WorkshopS

CRUM


Programa: Menos Papel, Mais rvores

Qual o mundo que queremos ?O primeiro passo para criar um mundo melhor, saber qual tipo de mundo que queremoster e qual tipo que deixaremos de herana para as prximas geraes.

Nossa misso: buscar pelo equilibro do homem, da tecnologia e do meio ambiente.

Para cumprir esta misso necessrio: conscientizar, comprometer e AGIR.

O programa Menos Papel, Mais rvores, uma ao, com objetivo deestimular o consumo sustentvel de papel dentro das organizaes.

Quer participar ?- Reduza o uso de papel (e de madeira) o mximo possvel.- S imprima se for extremamente necessrio.- Evite comprar produtos com excesso de embalagem.- Ao imprimir ou escrever, utilize os dois lados do papel.- Use papel reciclado.

Este material no deve ser impresso..


5/77


WorkshopS

CRUM


Facilitador: Rildo F. Santos (@rildosan)Coach , Instrutor, Consultor e Palestrante de Mtodos geis, Gesto de Negcios, Inovao , Processos eTecnologia .

Minha Experincia:Tenho mais de 10.000 horas de experincia em Gesto de Negcios, Gesto de Inovao, Governana e Engenharia deSoftware. Sou formado em Administrao de Empresas, Ps-Graduado em Didtica do Ensino Superior e Mestre em

Engenharia de Software pela Universidade Mackenzie.Fui instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java (Sun MicroSystems e IBM).

Conheo Mtodos geis (SCRUM, XP, FDD, Lean e OpenUP), Arquitetura de Software, SOA (Arquitetura Orientado aServio), Processo Unificado, Business Intelligence, Gesto de Risco de TI entre outras tecnologias.

Sou professor de curso de MBA da Fiap e fui professor de ps-graduao da Fasp e IBTA.

Tenho conhecimento de Gesto de Negcio (Inteligncia de Negcio, Gesto por Processo, Inovao, Gesto de Projetos e

GRC - Governance, Risk ando Compliance), SOX, Basel II e PCI;Experincia na implementao de Governana de TI e Gerenciamento de Servios de TI. Fluncia nos principais frameworkse padres: ITIL, Cobit, ISO 20000, ISO 27001 e ISO 15999;

Participei de diversos projetos nos segmentos: Financeiro, Telecomunicaes, Seguro, Sade, Comunicao, SeguranaPblica, Fazenda, Tecnologia, Varejo, Distribuio, Energia e Petrleo e Gs.

Possuo as certificaes: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java CertifiedInstrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;

Sou membro do IIBA-International Institute of Business Analysis (Canada)

Onde estou:Twitter: @rildosanBlog: http://rildosan.blogspot.com/Comunidade: http://etecnologia.ning.com
http://twitter.com/rildosanhttp://twitter.com/rildosan


6/77


WorkshopS

CRUM






Contedo do Workshop:

1

Criar

2

Estimar

3

Priorizar

4

Manter


7/[email protected] 1 Ago 2010 | RFS

WorkshopS

CRUM


Objetivo:

Objetivo dessa parte:Apresentar e discutir como Criar o Product Backlog.


SCRUM (http://etecnologia.ning.com/group/scrum ) primeiro e depois esse treinamento.


8/77



WorkshopSCRUM


Framework SCRUM:

Artefatos

SprintBacklog

Produto

Planejamentoda Sprint Reuniodiria

Sprint(2-4 Semanas)

24 horas

Revisoda Sprint Retrospectivada Sprint

Reunies

Sprint BurndownRelease Burndown

ProductBacklog

Legenda:

Product Owner (PO) ScrumMaster (SM) Equipe (time)

Product Backlog Sprint Backlog Sprint Burndown Release Burndown

PapisEventos (Reunies)

Artefatos Planejamento da Release Planejamento da Sprint Diria Reviso da Sprint

Retrospectiva da Sprint

Viso

Planejamentoda Release

O focodesse

workshop

O Framework Scrum composto por uma Equipe (Time) Scrum e seus papis: Product Owner(PO), Scrum Master (SM) e Equipe de desenvolvedores, Eventos com durao fixa (Time-Boxes),Artefatos e Regras.



WorkshopSCRUM


As Regras fazem o elo entre os eventos com durao fixa (time-boxes), os papis e osartefatos do Scrum. Veja as regras aplicadas ao Product Backlog e ao Product Owner:

Regras:- Somente o PO (Product Owner) definir e alterar a prioridade dos itens do Product Backlog.

- O Product Owner a nica pessoa responsvel pelo gerenciamento do Product Backlog epor garantir o valor do trabalho realizado pelo Time.

- Essa pessoa mantm o Product Backlog e garante que ele est visvel para todos. Todossabem quais itens tm a maior prioridade, de forma que todos sabem em que se ir trabalhar.

Framework Scrum: As Regras



WorkshopSCRUM


Framework Scrum: Product Owner (PO)O Product Owner (PO) a nica pessoa responsvel pelo gerenciamento doProduct Backlog e por garantir o valor do trabalho realizado pela Equipe.O PO mantm o Product Backlog (PB) e assegura que ele est visvel para todos.Todos sabem quais itens tm a maior prioridade, de forma que todos sabem em quese ir trabalhar.

O Product Owner deve ser uma pessoa, e no um comit. Podem existir comitsque aconselhem ou influenciem , mas somente o PO poder mudar a prioridade deum item do PB. Empresas que adotam Scrum podem perceber que isso influenciaseus mtodos para definir prioridades e requisitos ao longo do tempo.Para que o PO obtenha sucesso, todos na organizao precisam respeitar suasdecises. Somente o PO pode definir a prioridade dos itens que a equipe ir trabalhar.As decises do Product Owner so visveis no contedo e na priorizao do Product

Backlog. Essa visibilidade requer que o Product Owner faa seu melhor, o que faz opapel de Product Owner exigente e recompensador ao mesmo tempo.Product Backlog e as responsabilidades do PO: Criar , Priorizar e Manter o ProductBacklog.

Somente detalhamos papel do Product Onwer, pois, ele responsvel direto peloProduct Backlog.

A equipe (ou time), responsvel pelo desenvolvimento do produto, formada por desenvolvedores que devem ter ashabilidades necessrias para transformar os itens do Product Backlog em Produto. A Equipe ainda responsvel por:- Fazer estimativa;- Definir as tarefas;- Garantir a qualidade do produto;

- Apresentar o produto ao cliente

O ScrumMaster, que responsvel por garantir que o processo (as prticas do SCRUM) seja compreendido e

seguido. responsvel ainda por:- Remover impedimentos;- Proteger a equipe;- Ajudar o PO (quando necessrio);- Ser o facilitador da equipe.



WorkshopSCRUM


Framework Scrum: Artefatos

Scrum tem quatro artefatos principais:

- Product Backlog: uma lista priorizada de tudo que pode ser necessrio no produto.- Release Burndown: Mede o Product Backlog restante ao longo do tempo de um Plano de

Release do Produto.- Sprint Backlog: uma lista de tarefas para transformar o Product Backlog , por uma Sprint, emum incremento do produto potencialmente entregvel. Um burndown uma medida dobacklog restante pelo tempo.

- Sprint Burndown: Mede os itens da Sprint Backlog restantes ao longo do tempo de uma Sprint.

Nessa aula ser discutido os artefatos: Product Backlog (PB) e Release Burndown. Mas, nosso foco

primrio o Product Backlog.



WorkshopSCRUM


O que o Product Backlog ?Product Backlog: uma lista priorizada de tudo que pode ser necessrio no produto.O Product Backlog representa tudo que necessrio para desenvolver e lanar um produto desucesso. uma lista de todas as caractersticas, funes, tecnologias, melhorias e correes dedefeitos que constituem as mudanas que sero efetuadas no produto para releases futuras. Os

itens do Product Backlog possuem os atributos de descrio, prioridade e estimativa. A prioridade determinada por risco, valor e necessidade. H diversas tcnicas para dar valor a esses atributos(veremos isso mais tarde).

Quem responsvel pelo Product Backlog ?O Product Owner (PO) o responsvel pelo Product Backlog , por sua criao, por seu contedo, porsua disponibilidade e por sua priorizao.

At quando o Product Backlog existir ?O Product Backlog nunca est completo. A seleo inicial para o seu desenvolvimento somentemostra os requisitos inicialmente conhecidos e melhor entendidos. O Product Backlog evolui medidaque o produto e o ambiente em que ele ser usado evoluem. O Backlog dinmico, no sentido deque ele est constantemente mudando para identificar o que o produto necessita para serapropriado, competitivo e til. Enquanto existir um produto, o Product Backlog tambm existir.Resumo: O clico de vida do Product Backlog est ligado ao ciclo de vida do Produto

Qual a ordenao do Product Backlog ?O Product Backlog ordenado por prioridade, os itens com as maiores prioridades devem ter odesenvolvimento imediato.Quanto mais alta sua prioridade, mais urgente ele , mais se pensou sobre ele e h maisconsenso no que diz respeito ao seu valor. Os itens do Backlog de maior prioridade, possuem maisinformaes e detalhes do que os itens do Backlog de menor prioridade. mais fcil de fazer a

estimativa quando existem mais informaes e mais detalhes.

Questes sobre o Product Backlog:



WorkshopSCRUM


Por que o Product Backlog pode mudar ?

Porque quando um produto utilizado, e seu valor aumenta e o cliente pode fornecer feedback, oProduct Backlog poder se tornar uma lista maior e mais aprofundada. Os requisitos geralmente

mudam (alguns com maior frenquncia e outros com menor frequncia). O Product Backlog umdocumento vivo. Mudanas nos requisitos de negcios, condies do mercado, tecnologia eequipe causam mudanas no Product Backlog. Para reduzir o retrabalho, apenas os itens demaior prioridade precisam ser mais detalhados. Os itens do Product Backlog que ocuparo aEquipe Scrum pelas vrias Sprints seguintes devero ter granularidade mais fina (mais detalhados),tendo sido decompostos de forma tal que cada um dos itens possa ser feito dentro da durao daSprint.

Quando existe diversas equipes trabalhando para construir um produto quantos ProductBacklog devemos ter ?Se mltiplas equipes trabalham juntas no mesmo produto, devemos ter um nico Product Backlog usado para descrever o trabalho a ser realizado no produto.

Como agrupar os itens do Product Backlog ?O agrupamento pode ocorrer por conjuntos de caractersticas, por tecnologia ou por arquitetura,

e ele frequentemente utilizado como uma forma de se organizar o trabalho por equipe.

Questes sobre o Product Backlog:

C B



WorkshopSCRUM


A necessidade:Um hotel, quer incrementar um novo canal de consultas e vendas de reservas deapartamentos. A sugesto foi criar um Portal de Reservas para vender os servios.

Como criar o Product Backlog:

Declarao da Viso do Produto:

Para o Hotel que necessita de um Sistema o Portal de Reservas On-Line umsoftware baseado na web, intuitivo e fcil de usar que fornece a possibilidade fazer aconsultas e reservas de apartamentos.Diferente de outros sistemas, o produto oferece um canal direto de acesso ao cliente.

Para definir a viso do Produto, primeiro necessrio entender qual a real necessidade do cliente:

Aps entender a necessidade do cliente, hora de definir a Viso do Produto:

D fi i d Vi d P d



WorkshopSCRUM


Definindo a Viso do Produto:Introduo:

Apresentaremos duas tcnicas:- A Declarao do Elevador (que tambm pode serchamada de Viso Sinttica)

- Product Vision Box.

A declarao de Viso do Produto deve ser simples,

consistente, objetiva e fcil entendimento, que teminformaes sobre a necessidade do cliente, o que produto esperado e quais sos os seus principaisbenefcios.A declarao ainda deve descrever a motivao e odiferencial do produto em relao aos outros.

A Declarao da Viso do Produto:

Qualquer produto est necessariamente associada a uma viso, pois, a viso deve descrever o oproduto em relao a necessidade do usurio (cliente).A viso do produto somente ser significativa se apresentada e compartilhada pela equipe SCRUM.

A definio da viso do produto uma responsabilidade Product Owner. Mas, ele poderdesenvolver a viso do produto em colaborao com a equipe de desenvolvimento de software e ocliente final

D fi i d Vi d P d t



WorkshopSCRUM


Definindo a Viso do Produto:

Product Owner

Product Owner (PO), responsvel por definir, manter e comunicar aViso do Produto para todos os stakeholders.

A equipe pode colaborar com o desenvolvimento da Viso do Produto.

Primeira Tcnica: Declarao do Elevador (Elevator Statement)

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)

O nome desta tcnica umaaluso ao seguinte desafio: voctem que influenciar ou passar ummensagem para um pessoa emcurto espao de tempo umaviagem de elevador.Com o tempo curto a mensagemtem que ser objetiva e clara.

Declarao do Elevador ou Viso sinttica" (essencial)Segundo Moore (1991). tambm chamada Elevator Pitch, mas podemos chamar "viso sinttica.A viso sinttica estruturado em 6 partes que resumem em menos de dois minutos a Viso do Produto.

Exemplo de Viso do Produto utilizando a Declarao do Elevador:

Para empresas mdias de marketing e departamento de vendas que necessitam de um sistema deCRM, o EeaseCRM um software baseado na web, intuitivo e fcil de usar que fornece apossibilidade fazer a rastreabilidade de vendas, gerao de leads e possibilita o estreitamento dorelacionamento com o cliente.Diferente de outros servios ou produtos, nosso produto oferece a melhor relao custo beneficio.

D fi i d Vi d P d t



WorkshopSCRUM



Viso do Produto:

Segunda Tcnica: Product Vision Box

Product Vision Box uma tcnica que ajuda no entendimento da Viso do Produto, pois, quandofazemos uma representao visual do produto (embalagem, por exemplo) isto auxilia na reduo donvel de abstrao (ou seja, melhora o entendimento do que ser feito).

Segundo Highsmith (2004). O Produto Vision Box uma tcnica altamente relevantes para iniciar umprojeto para construir a viso e compartilh-lo com a equipe responsvel pelo desenvolvimento doproduto.O resultado de um projeto de desenvolvimento de software produto. O produto pode ser representadopor uma caixa (a caixa do produto).

A caixa final, construda coletivamente, com base no que precede, noconsenso e colaborao. Esta "Viso da Caixa do produto" a visocompartilhada, e ir incorporar os seguintes elementos: Parte da frente da caixa: Nome - Imagem (se possvel) - diviso -argumentos que ajudam a vender o produto Parte de trs da caixa: Colocar de forma mais detalhada as principaisfuncionalidade, os pr-requisitos e etc...

Este exerccio ajuda a melhorar o entendimento, identificar possveisconflitos e reduz a abstrao. O formato desse exerccio exige que osas pessoas tenham uma participao intensa e as vezes at exaustiva.

Mas, a viso da caixa do produto definida sempre em consenso.

D fi i d Vi d P d t



WorkshopSCRUM



Viso do Produto:

Product Owner

Product Owner (PO), pode utilizar esta tcnica para exercitar odesenvolvimento da viso do produto junto com a equipe.

Exemplo: Product Vision Box

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

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

http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/

C i P d t B kl



WorkshopSCRUM


O Product Backlog, inicialmente uma lista que representa tudo que necessrio para desenvolver elanar um produto. A lista deve conter todas as caractersticas, funes, tecnologias, melhorias ecorrees de defeitos que constituem as mudanas que sero efetuadas no produto para futurasreleases . O Product Backlog dinmico, no sentido de que ele est constantemente mudando

para identificar o que o produto necessita.

Aps a definio da Viso do Produto, devemos definir a primeira verso do Product Backlog:

Funcionalidades do produto

Como criar o Product Backlog

agrupamento

Estudo de Caso Viso do Produto



WorkshopSCRUM


Estudo de Caso: Viso do Produto



22/77


WorkshopSCRUM







1

Criar

2

Estimar

3

Priorizar

4

Manter

Objetivo:


23/77


WorkshopSCRUM


Objetivo:

Objetivo dessa parte:Apresentar e discutir como Estimar o Product Backlog.


SCRUM (http://etecnologia.ning.com/group/scrum) primeiro e depois esse treinamento.

Parte 2:


24/77


WorkshopSCRUM

Todos os direitos reservados e protegidos 2006 e 2010 24Como Estimar o Product Backlog

Parte 2:

Framework SCRUM:


25/77


WorkshopSCRUM


Framework SCRUM:

Artefatos

SprintBacklog

Produto

Planejamentoda Sprint

Reuniodiria

Sprint(2-4 Semanas)

24 horas


Reunies

Sprint Burndown

Release Burndown

ProductBacklog

Legenda:




Artefatos Planejamento da Release Planejamento da Sprint Diria Reviso da Sprint

Retrospectiva da Sprint

Viso


O focodesse

workshop


Introduo a Reunio de Planejamento da Release:


26/77


WorkshopSCRUM


Introduo, a Reunio de Planejamento da Release:

Sprint

BacklogProduto


Reuniodiria

24 horas

Revisoda Sprint

Retrospectivada Sprint

Viso

ProdutoBacklog

Sprint2-4 Semanas

Na reunio de Planejamento da Release o Product Backlog estimado e priorizado.O PO responsvel por priorizar os itens do Product Backlog (isto ser visto na prxima aula). A equipe responsvel por estimar os itens do Product Backlog.


Equipe (Responsvel por fazer a estimativa):


27/77


WorkshopSCRUM


Equipe (Responsvel por fazer a estimativa):

O Product Owner (PO) a nica pessoa responsvel pelo gerenciamento do Product Backlog epor garantir o valor do trabalho realizado pela Equipe.O PO mantm o Product Backlog (PB) e assegura que ele est visvel para todos. Todos sabemquais itens tm a maior prioridade, de forma que todos sabem em que se ir trabalhar.O Product Owner deve ser uma pessoa, e no um comit. Podem existir comits que aconselhemou influenciem , mas somente o PO poder mudar a prioridade de um item do PB. Empresas queadotam Scrum podem perceber que isso influencia seus mtodos para definir prioridades e requisitosao longo do tempo.Para que o PO obtenha sucesso, todos na organizao precisam respeitar suas decises.Somente o PO pode definir a prioridade dos itens que a equipe ir trabalhar.As decises do Product Owner so visveis no contedo e na priorizao do Product Backlog. Essavisibilidade requer que o Product Owner faa seu melhor, o que faz o papel de Product Owner

exigente e recompensador ao mesmo tempo.Product Backlog e as responsabilidades do PO: Criar , Priorizar e Manter o Product Backlog.

Destacamos: a tarefa Fazer Estimativa que uma responsabilidade da equipe (time)

A equipe (ou time), responsvel pelo desenvolvimento do produto, formada pordesenvolvedores que devem ter as habilidades necessrias para transformar os itensdo Product Backlog em Produto. A Equipe ainda responsvel por:- Fazer estimativa;- Definir as tarefas;

- Garantir a qualidade do produto;- Apresentar o produto ao cliente

O ScrumMaster, que responsvel por garantir que o processo (as prticas do SCRUM) seja compreendido eseguido. responsvel ainda por:- Remover impedimentos;- Proteger a equipe;- Ajudar o PO (quando necessrio);- Ser o facilitador da equipe.

Verso inicial do Product Backlog:


28/77


WorkshopSCRUM


O Product Backlog, inicialmente uma lista que representa tudo que necessrio para desenvolver elanar um produto. A lista deve conter todas as caractersticas, funes, tecnologias, melhorias ecorrees de defeitos que constituem as mudanas que sero efetuadas no produto para futurasreleases . O Product Backlog dinmico, no sentido de que ele est constantemente mudando

para identificar o que o produto necessita.

Aps a definio da Viso do Produto, devemos definir a primeira verso do Product Backlog,note que ele no foi estimado nem priorizado.

Funcionalidades do produto


agrupamento

Reunio de Planejamento da Release:


29/77


WorkshopSCRUM



O propsito do planejamento da release o de estabelecer um plano emetas que a Equipe Scrum e o resto da organizao possam entender ecomunicar.

O planejamento da release responde s questes:- Como podemos transformar a viso em um produto da melhor maneirapossvel?- Como podemos alcanar ou exceder a satisfao do cliente ?- Como podemos alcanar o ROI (retorno sobre investimento) ?

O Plano da Release estabelece a meta da release, as maioresprioridades do Product Backlog, os principais riscos e as caractersticasgerais e funcionalidades que estaro contidas na release.Ele estabelece tambm uma data de entrega e custo provveis quedevem se manter se nada mudar. A organizao pode ento inspecionaro progresso e fazer mudanas nesse plano da release a cada Sprint.

Contudo, O planejamento da release inteiramente opcional. Se umaEquipe Scrum iniciar o trabalho sem essa reunio, a ausncia de seus

artefatosaparecer como um impedimento que dever ser resolvido.O trabalho para resolver o impedimento se tornar um item no ProductBacklog.Ao se utilizar Scrum, os produtos so construdos iterativamente, demodo que cada Sprint cria um incremento do produto, iniciando pelo demaior valor e maior risco. Mais e mais Sprints vo adicionandoincrementos ao produto.

A estimativa e a priorizao devem ser feitas na Reunio de Planejamento da Release.



30/77


WorkshopSCRUM


Cada incremento um pedao potencialmente entregvel do produtocompleto. Quando j tiverem sido criados incrementos suficientespara que o produto tenha valor e uso para seus investidores, o produto

entregue

Muitas organizaes j tem um processo de Planejamento deRelease, e na maior parte desses processos o planejamento feito noincio do trabalho da release e no modificado com o passar dotempo.No Planejamento de Release do Scrum, so definidos uma meta geral eresultados provveis. Esse planejamento geralmente no requer mais do que15-20% do tempo que uma organizao costumava utilizar para produzir umplano de release tradicional. No entanto, uma release com Scrum realizaplanejamento no momento da execuo de cada reunio de Reviso deSprint e de Planejamento de Sprint, da mesma forma que realiza umplanejamento dirio no momento da execuo de cada Reunio Diria.

De forma geral, os esforos para uma release com Scrum provavelmente

consomem ligeiramente mais esforo do que os esforos para umplanejamento de release tradicional.

O planejamento da release requer estimar e priorizar o Product Backlogpara a release. Existem diversas tcnicas para faz-lo, mas o SCRUM umframework, no indica nenhuma tcnica.Contudo, nessa aula abordaremos algumas tcnicas para estimar o ProductBacklog

Reunio de Planejamento da Release:A estimativa e a priorizao devem ser feitas na Reunio de Planejamento da Release.

Viso Geral da Reunio de Planejamento da Release:


31/77


WorkshopSCRUM



Reunio dePlanejamentoda Release

Product Backlog (viso inicial)Product Backlog (priorizado e estimado)

Viso do Produto

Plano de Release

Entradas Sadas

Release

Burndown(artefato)

Os participantes:Equipe SCRUM

Reunio de Planejamento da Release: Fazendo estimativas


32/77


WorkshopSCRUM


Reunio de Planejamento da Release: Fazendo estimativas

1Viso inicial do Product Backlog, antes da reunio de Planejamento daRelease, ele tem somente as funcionalidades do produto, agrupadaspor tema (este agrupamento opcional).Uma das atividades da reunio de Planejamento da Release definiro Plano de Release, nesse plano estabelece-se o prazo de entrega

(estimado) do produto e nvel de prioridade dos itens do ProductBacklog.Para chegarmos na data de entrega do produto esperada, o PO deveperguntar diretamente ao cliente.A equipe responsvel por fazer a estimativa dos itens do ProductBacklog.

2

Por que estimar difcil ?


33/77


WorkshopSCRUM



O eixo horizontal contm etapas do projeto comum, comoconceito inicial, definio do produto aprovado, requisitoscompletos, e assim por diante. "Definio do produto"refere-se apenas ao acordado viso para o software, ou"conceito de software", e igualmente aplicvel aosservios de web, sistemas internos de negcios, e amaioria dos outros tipos de projetos de software.O eixo vertical contm o grau de erro que foi encontradonas estimativas criado por estimadores qualificados em

vrios pontos do projeto. As estimativas poderiam ser parao quanto um conjunto de caractersticas particulares vaicustar e quanto esforo ser necessrio para entregar esseconjunto de recursos, ou poderia ser de quantos recursospodem ser entregues para uma determinada quantidade deesforo ou programao.Como voc pode ver na figura, as estimativas criadas logono incio do projeto esto sujeitos a um elevado grau deerro. Estimativas iniciais so mais imprecisas do que asoutras variveis que foram criadas ao longo do projeto.

Em um projeto desenvolvimento de software quase todas as variveis so incertas...O Cone da Incerteza:No incio de um projeto, detalhes especficos sobre a natureza do software a ser construdo, os detalhesdos requisitos especficos, os detalhes da soluo, plano de projeto, equipe e outras variveis do projetoso claras. A variabilidade desses fatores contribui para a variabilidade de estimativas do projeto - uma

estimativa exata de um fenmeno varivel deve incluir a variabilidade do fenmeno em si. Como estasfontes de variabilidades so investigados e tratadas, a variabilidade no projeto diminui ao longo do tempo(no decorrer do projeto), e assim a variabilidade no projeto estimada tambm pode diminuir. Estefenmeno conhecido como o "Cone da Incerteza", que ilustrado na figura a seguir. Como a figurasugere, a reduo significativa do Cone ocorrem durante os primeiros 20-30% do tempo total decalendrio para o projeto.

Fonte: http://www.construx.com/Page.aspx?hid=1648

Cone da Incerteza


34/77



35/77


WorkshopSCRUM


No mundo real fazer estimativa ter uma valor aproximado, mas em desenvolvimento de software oentendimento outro, estimativa tida como uma valor exato, claro que esta viso equivocada.- Estimativa (Mundo real) = Valor aproximado- Estimativa (Desenvolvimento de Software) = Valor exato

Dias ideias (Ideal Days): Mais fcil para iniciantes

Fcil de explicar

Pontos de Estria (Story Points): Valores relativos

Mais abstrato

Vocs errarama estimativa ...

PO

????

Equipe

Preciso de umadata estimada

exata..

PO

????

Equipe

Cena 1 Sprint Review Cena 2 Planejamento da Sprint

????????


Estimando Product Backlog:


36/77


WorkshopSCRUM


Baseado na durao de tarefas.

- Dias ou horas unidade bem definida, contudo o tempo idealquase nunca igual ao tempo real...- mais fcil de estimar, mas pode ser tornar difcil de estimar seconsideramos todas as interrupes e variaes

Baseia-se no tamanho da estria influenciado pela:- Nvel de dificuldade, complexidade e experincia ( emprico);Foco nas funcionalidades;O importante so os valores relativos;

Pontos so medidas sem unidade;Equipe diferentes podem ter pontos diferentes para a mesmaestrias.

Pontos de Estria (Story Points)

Principais tcnicas: Opinio de especialista (algum que est ajuda a implementar oScrum na empresa as vezes um Coach); Analogia;

Decomposio (Dividir para conquistar) ou Desagregao.

Dias Ideais (Ideal Days)

Pontos de Estria: Valores relativos Mais abstrato

Ideal Days: Mais fcil para iniciantes Fcil de explicar

Quando trabalhamos com mtodos geis temos pelo menos duas formas para estimar a velocidade daequipe: Ideal Days e Pontos de Estria. Recomendamos utilizar os Pontos de Estria.

Estimando Product Backlog:

Ideal Days foi definido por Kent Beck para referenciar um dia totalmente livre deimpedimentos para o desenvolvedor. No seu livro, Extreme Programming Explained,Beck descreveu o dia ideal, como o tempo necessrio para concluir uma estria do usuriosem interrupes ou reunies Esta ideia ressalta que os desenvolvedores

eventualmente executam outras atividades durante o dia, alm de programar.

Tcnicas que ajudam a Estimar:


37/77


WorkshopSCRUM


Existem 3 tcnicas que podem ajudar a fazer estimativas:

Tcnicas que ajudam a Estimar:

Estimativa por analogia:- Comparando a estria do usurio com outra estria:

"Esta estria muito parecida com aquela de Cadastro de Cliente, ns estimamos aquela estriacom 11 pontos...

- No utilize um nico padro (tcnica). Procure utilizar pelo dois ou mais padres.- Triangulao:Comparar a estria que est sendo estimada em com vrias outras estrias

Desagregao:- Quebrar uma estria do usurio grande em estria menores ou tarefas mais fcil estimar com base em tarefas

- Cuidado, a desagregao em excesso pode caurar problemas:Como esquecimento de algumas tarefas

Triangulao:- Certifique que estimativa ser feita, comparandoa estria do usurio com vrias outras estrias- Grupo de estria do usurio com tamanho

prximos esto em uma tabela ou quadro branco,isto facilita o trabalho.

Fonte: Agile Estimating and Planning Mike Cohn

Estria A

Estria C

Estria DEstria B

Estria E

Estria F

Estimando os itens do Product Backlog:


38/77


WorkshopSCRUM


Como cliente de negcio, eu quero fazer reserva de

apartamentos pela web para facilitar o meu

planejamento.

Pontos: ?

Titulo: Fazer Reserva de Apartamentos

Prioridade: Alta

Estria do Usurio

Para facilitar o entendimento dositens do Product Backlog ele sodescritos em estrias do usurioelas auxiliam no entendimento doque deve ser feito, permite fazer aestimativa de velocidade da equipee tambm , utilizada comolembrete e para as atividades deplanejamento. Geralmente aestimativa feita em pontos(pontos de estria)

Estimando os itens do Product Backlog:Detalhando os itens do Produto Backlog em estrias do usurio:

Como escrever uma Estria do Usurio ?Conversaes sobre a estria, entre os usurios e desenvolvedores, de modo a detalhar o item doProduct Backlog e esclarecer todas as dvidas sobre do que deve ser feito.

Boa Prtica: A Estria do Usurio deve prover o entendimento do que deve ser feito e deve facilitar a estimativa

de velocidade da equipe.

Carto: Estria do Usurio so tradicionalmenteescritas em um carto. Carto podem ter notas,estimativas, comentrio observaes e etc

Conversas: Detalhes que podem surgir durante asconversas com PO (Product Owner) e/ou cliente.

Confirmao: Testes de aceitao confirmam sea Estria do Usurio foi codificada da forma correta.Testes de aceitao so tipo Caixa Preta.

http://egemsource.com/images/pic/main_column/check_mark.jpg


39/77


Workshop

SCRUM


Estimativa* e o Planning Poker:

Geralmente o Planning Poker usa um conjunto de cartas com valores especficos quepodem representar pontos relativos e praticado como se fosse um jogo de cartas. Ospontos devem estar em uma escala no linear, por e exemplo a Fibonacci:(1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala.

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

no consenso de toda a equipe.

Pessoal, qual estimativa paraessa estria...

Product Owner Equipe

40

40 40

100

Jogando o Planning Poker:Antes de comear o jogo necessrio definir um valor de referncia. Por exemplo: Identificar a estriaque pode ser atribudo a menor quantidade pontos, esta estria ser utilizada como referncia parapontuao das demais estrias.O PO apresenta uma estria e pede para os membros da equipe fazer a estimativa de velocidade...

40

40 40

40

1. Rodada Quando todas as cartasestiverem lanadas, elasso viradas e caso no

haja consenso nospontos, as diferenas sodiscutidas de formabreve, e uma novarodada acontece at quehaja concesso.

N. Rodada

Equipe

st a do os te s do oduct ac og



40/77


Workshop

SCRUM


Pessoal, qual estimativa paraessa estria...

Product Owner Equipe

20

20 40

20

Planning Poker

Product Backlog

Escrevendo as Estrias do Usurio

Estimando

gTodos os itens do Product Backlog devem ser estimados, pois, assim PO poder construir o Plano deRelease e Release Burndown, que um dos artefatos produzidos nessa reunio..


41/77

Reunio de Planejamento da Release: PB estimado


42/77


Workshop

SCRUM


j

Plano de Release

Reserva PromoesPrograma de

FidelidadeTour VirtualSprints#

Nvel dePrioridade

Relacionamentoao cliente

Prazo

(estimado)

? ? ? ? ?

30 dias 15 dias 7 dias 15 dias 15 dias

5 Sprints

82 dias

1

2Definio da estimativa do Product Backlog

Aps a equipe concluir a estimativa do Product Backlog necessrio fazera priorizao dos itens. Isto responsabilidade do PO.3

Verso inicial do Product Backlog,sem estimativa e nem priorizao.

Reunio de Planejamento da Release. Check List parcial


43/77


Workshop

SCRUM


j p

Falta priorizar, mas isso assunto para prxima aula



44/77


Workshop

SCRUM






p

1Criar

2Estimar

3Priorizar

4Manter

Parte 3:


45/77


Workshop

SCRUM

Todos os direitos reservados e protegidos 2006 e 2010 45Como Priorizar o Product Backlog


46/77

Framework SCRUM:


47/77


Workshop

SCRUM


Artefatos

SprintBacklog

Produto


Reunio

diria

Sprint(2-4 Semanas)

24 horas


Reunies

Sprint Burndown

Release Burndown

ProductBacklog

Legenda:




Artefatos Planejamento da Release Planejamento da Sprint Diria Reviso da Sprint Retrospectiva da Sprint

Viso


O focodesse

workshop


Introduo, a Reunio de Planejamento da Release:


48/77


Workshop

SCRUM


Sprint

BacklogProduto


Reuniodiria

24 horas

Revisoda Sprint


Viso

Produto

BacklogSprint

2-4 Semanas

Na reunio de Planejamento da Release o Product Backlog estimado e priorizado.A equipe responsvel por estimar os itens do Product Backlog, mais isto foi apresentado na aulaanterior. Nessa aula vamos apresentar como priorizar os itens do Product Backlog , essa tarefa deresponsabilidade do PO.




49/77


Workshop

SCRUM


O Product Backlog, inicialmente uma lista que representa tudo que necessrio para desenvolver elanar um produto. A lista deve conter todas as caractersticas, funes, tecnologias, melhorias ecorrees de defeitos que constituem as mudanas que sero efetuadas no produto para futurasreleases . O Product Backlog dinmico, no sentido de que ele est constantemente mudandopara identificar o que o produto necessita.

Aps a definio da Viso do Produto, devemos definir a primeira verso do Product Backlog,note que ele no foi estimado nem priorizado.

Funcionalidades do produtoagrupamento

{Review} Reunio de Planejamento da Release:


50/77


Workshop

SCRUM


O propsito do planejamento da release o de estabelecer um plano emetas que a Equipe Scrum e o resto da organizao possam entender ecomunicar.

O planejamento da release responde s questes:- Como podemos transformar a viso em um produto da melhor maneirapossvel?- Como podemos alcanar ou exceder a satisfao do cliente ?- Como podemos alcanar o ROI (retorno sobre investimento) ?

O Plano da Release estabelece a meta da release, as maioresprioridades do Product Backlog, os principais riscos e as caractersticas

gerais e funcionalidades que estaro contidas na release.Ele estabelece tambm uma data de entrega e custo provveis quedevem se manter se nada mudar. A organizao pode ento inspecionaro progresso e fazer mudanas nesse plano da release a cada Sprint.

Contudo, O planejamento da release inteiramente opcional. Se umaEquipe Scrum iniciar o trabalho sem essa reunio, a ausncia de seus

artefatos aparecer como um impedimento que dever ser resolvido.O trabalho para resolver o impedimento se tornar um item no ProductBacklog.Ao se utilizar Scrum, os produtos so construdos iterativamente, demodo que cada Sprint cria um incremento do produto, iniciando pelo demaior valor e maior risco. Mais e mais Sprints vo adicionandoincrementos ao produto.


{Review} Reunio de Planejamento da Release:


51/77


Workshop

SCRUM


Cada incremento um pedao potencialmente entregvel do produtocompleto. Quando j tiverem sido criados incrementos suficientespara que o produto tenha valor e uso para seus investidores, o produto

entregue

Muitas organizaes j tem um processo de Planejamento deRelease, e na maior parte desses processos o planejamento feito noincio do trabalho da release e no modificado com o passar dotempo.No Planejamento de Release do Scrum, so definidos uma meta geral eresultados provveis. Esse planejamento geralmente no requer mais do que

15-20% do tempo que uma organizao costumava utilizar para produzir umplano de release tradicional. No entanto, uma release com Scrum realizaplanejamento no momento da execuo de cada reunio de Reviso deSprint e de Planejamento de Sprint, da mesma forma que realiza umplanejamento dirio no momento da execuo de cada Reunio Diria.

De forma geral, os esforos para uma release com Scrum provavelmente

consomem ligeiramente mais esforo do que os esforos para umplanejamento de release tradicional.

O planejamento da release requer estimar e priorizar o Product Backlogpara a release. Existem diversas tcnicas para faz-lo, mas o SCRUM umframework, no indica nenhuma tcnica.Contudo, nessa aula abordaremos algumas tcnicas para priorizar oProduct Backlog




52/77


Workshop

SCRUM


Reunio dePlanejamento

da Release

Product Backlog (viso inicial)Product Backlog (priorizado e estimado)

Viso do Produto

Plano de Release

Entradas Sadas

ReleaseBurndown(artefato)

Os participantes:Equipe SCRUM

Reunio de Planejamento da Release: Priorizando


53/77


Workshop

SCRUM


1Viso inicial do Product Backlog, antes da reunio de Planejamento daRelease, ele tem somente as funcionalidades do produto, agrupadaspor tema (este agrupamento opcional).Uma das atividades da reunio de Planejamento da Release definiro Plano de Release, nesse plano estabelece-se o prazo de entrega

(estimado) do produto e nvel de prioridade dos itens do ProductBacklog.

3 Aps a estimava dos itens do Product Backlog necessrio definiros nveis de prioridades dos itens Product Backlog.

2 A equipe responsvel por fazer a estimativa dos itensdo Product Backlog.

Reunio de Planejamento da Release: Plano de Release


54/77


Workshop

SCRUM


{Review}O Plano da Release estabelece a meta da release, as maiores prioridades do Product Backlog, osprincipais riscos e as caractersticas gerais e funcionalidades que estaro contidas na release.

Ele estabelece tambm uma data de entrega e custo provveis que devem se manter se nada mudar.

A organizao pode ento inspecionar o progresso e fazer mudanas nesse plano da release a cadaSprint, se necessrio.

Plano de Release

Reserva PromoesPrograma deFidelidade

Tour VirtualSprints#

Nvel dePrioridade


? ? ? ? ?


5 Sprints

82 dias

Product Backlog sem priorizao


55/77


Workshop

SCRUM


?

?

?

?

?

Questes chaves:1 - Qual item retorna maior valor ao negcio ?2 - Quais itens devemos entregar primeiro ?3 - Como priorizar os itens ?

Objetivo da priorizao em mtodos geis:

Entregar os itens de maior valor ao cliente ao menor custo (entregar primeiro os requisitos de maiorvalor fazem que eles custem menos do que os itens que sero entregues mais tarde).

Priorizao do Product Backlog:


56/77


Workshop

SCRUM


As melhores prticas recomendam que a priorizao do Product Backlog deve ser por tema (ou porcategoria), j que a priorizar por estria, nem sempre possvel, pois, poder existir grau dedependncias entre estrias do usurio.Fatores de Priorizao:- Valor

- Custo- Risco

Priorizao Baseada em Valor, Custo e Risco:Existem diversas tcnicas que envolvem a estimativa do valor relativo e custo relativo de cada item(funcionalidade) do Product Backlog, de tal forma que os itens de alta prioridade deve fornecer a maiorfrao do valor total do produto ao menor frao do custo total. Em essncia, estamos tentando identificaritem (ou funcionalidade) que ir maximizar o valor do produto, dentro das limitaes de custo existentes.

Principais Tcnicas:

- Kano: Composta por entrevistas com os usurios e opinies de especialistas.

- Theme Screening: Composta por opinies de especialistas baseadas em comparao realizadascom um tema importante.

-Theme Scoring: Baseado em comparaes realizadas em um tem de referncia

- Outras:. Opinio de Especialista. Tcnicas financeiras

Tcnicas que ajudam na priorizao do Product Backlog:


57/77


Workshop

SCRUM


um modelo desenvolvido por Noriaki Kano que usado para compreender as preferncias dosclientes (ou usurios).

O modelo Kano tem 3 tipos de funcionalidades:

- Desejadas: So aquelas funcionalidades que o usurio deseja, mas no 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 o seguinte:- Fazer as perguntas direcionadas para um grupo de no mximo 20 clientes ou usurios com perfisdiferentes;

- 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

Modelo Kano:



58/77


Workshop

SCRUM


O que incluir na Sprint ?

- Todas as funcionalidades

Mandatrias- Algumas funcionalidadesLineares

- Mas deixe um espao para asfuncionalidades desejadas

Categorizando as respostas:

Agregando resultados:

Modelo Kano:



59/77


Workshop

SCRUM


Theme Screening uma tcnica poderosa e fcil de priorizao que pode ser usada para priorizar ostemas e/ou picos. Tambm pode ser usado para priorizar projetos ou produtos.

Theme Screening

Passos:1 - identificar os fatores que so significantes (importantes) na priorizao dos temas (ou dos picos).

2 - Selecione um tema como "baseline" (que ser utilizado como referncia)

3 Defina a tabela de pesos:+ - Melhor que a referncia0 - Igual a referncia- - Pior que referncia

4 Faa a avaliao (comparao):Fazer avaliao/comparao: do Critrio x Tema x Tema de Referncia. Perguntar: Qual grau de importncia do critrio em

relao ao Tema ?

5 Faa a classificao baseado no score (quando maior for o score maior ser o nvel de prioridade)

Temas

Baseline

Critrio de Seleo Reserva Progr de Fidelidade Promoes Rel com Clientes Tour Virtual

Reserva para prximo vero + + 0 - -

Promoes para baixa temporada + - 0 0 -

0

0

0

Score 2 0 0 -1 -2

Classificao 1 2 3 4 5



60/77


Workshop

SCRUM


Theme Scoring

Reserva (referncia) Progr de Fidelidade Promoes Rel com Clientes Tour Virtual

Critrio de Seleo Peso Pontos Score Pontos Score Pontos Score Pontos Score Pontos S core

Reserva para prximo vero 5 3 15 2 10 1 5 2 10 1 5Promoes para baixa temporada 2 3 6 1 2 3 6 2 4 1 2

Score 21 12 11 14 7

Classificao 1 3 4 2 5

Passos:1 - identificar os fatores que so significantes (importantes) na priorizao dos temas (ou dos picos).

2 Defina o peso para cada critrio

3 - Selecione um tema como "baseline" (que ser utilizado como referncia)

4 Defina a tabela de pesos:5 Muito Melhor que a referncia4 Melhor que a referncia3 Igual a referncia2 - Pior que a referncia

1 - Muito pior que a referncia

5 Faa a avaliao:Fazer avaliao de cada tema em relao ao candidato tema de referncia.

6 Faa a classificao baseado no score (quando maior for o score maior ser o nvel de prioridade)

uma tcnica de priorizao que pode ser usada para priorizar os temas (grupos de estrias do usurio)e/ou picos (estrias do usurio grandes). Tambm pode ser usado para priorizar projetos ou produtos.

Tcnicas que ajudam na priorizao do Product Backlog:O i


61/77


Workshop

SCRUM


Um especialista ajuda na definio do nvel de prioridade dos itens do Product Backlog..

Foco: Dever ser na entrega de valor para cliente.

Considerar 4 fatores:- Entrega novas capacidades- Desenvolvimento novos conhecimentos- Mitigao do Risco- Mudanas no custo relativo

Opinio de Especialista:

Utilizao de tcnicas financeira para ajudar na priorizao dos itens do Product Backlog.

TIR - Taxa interna de retorno

ROI Taxa de Retorno sobre investimento

Payback

Valor Presente Liquido (VPL)

Tcnicas Financeiras

Outras tcnicas

Reunio de Planejamento da Release: PB estimado


62/77


Workshop

SCRUM


Plano de ReleaseReserva Promoes

Programa deFidelidade

Tour VirtualSprints#

Nvel dePrioridade


Prazo

(estimado)

Alto Mdio Mdio Baixo Baixo


5 Sprints

82 dias

1

2Product Backlog estimado e priorizado

3

Verso inicial do Product Backlog,sem estimativa e nem priorizao.

Alta

Mdio

Mdio

Baixo

Baixo

Plano de Release, como status de Pronto

Reunio de Planejamento da Release. Release Burndown:


63/77


Workshop

SCRUM


Releases

Pontos(estimados)

120

80

40

0

Release #1 Release #2 Release #3 Release #5

108

Release Burndown

68

48

20

40

Release #4

Com Product Backlog atualizado e o Plano de Release, o PO poder construir o Release Burndown, que umdos artefatos do SCRUM.O Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog ao longo dotempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a equipe e aorganizao tenham decidido usar. As unidades de tempo geralmente so Sprints.

O Product Owner responsvelpormanter o Product Backlog eo Release Burndown atualizadose publicados todo o tempo.

Uma linha de tendncia pode sertraada baseada na mudana dotrabalho restante.

Reunio de Planejamento da Release. Check List final


64/77


Workshop

SCRUM




65/77


Workshop

SCRUM






1Criar

2Estimar

3Priorizar

4Manter

Objetivo:


66/77


Workshop

SCRUM


Objetivo dessa parte:Apresentar e discutir como Manter o Product Backlog.

Pr-requisito:Conhecimento do Scrum. Se voc no conhece o Scrum recomendamos fazer o WorkshopSCRUM (http://etecnologia.ning.com/group/scrum) primeiro e depois esse treinamento.

Parte 4:


67/77


Workshop

SCRUM


Como Manter o Product Backlog

Framework SCRUM:O Framework Scrum composto por uma Equipe (Time) Scrum e seus papis: Product Owner


68/77


Workshop

SCRUM


Artefatos

SprintBacklog

Produto


Reunio

diria

Sprint(2-4 Semanas)

24 horas

Reviso

da SprintRetrospectiva

da Sprint

Reunies

Sprint Burndown

Release Burndown

ProductBacklog

Legenda:




Artefatos Planejamento da Release Planejamento da Sprint Diria Reviso da Sprint Retrospectiva da Sprint

Viso


O focodesse

workshop


Viso do Product Backlog:

Review: Product Backlog:


69/77


Workshop

SCRUM


O Product Backlog, inicialmente uma lista que representa tudo que necessrio para desenvolver e lanar um produto. A lista deveconter todas as caractersticas, funes, tecnologias, melhorias ecorrees de defeitos que constituem as mudanas que seroefetuadas no produto para futuras releases .

Viso do Product Backlog:

Alta

Mdio

Mdio

Baixo

Baixo

O Product Backlog dinmico, no sentido de que ele estconstantemente mudando para identificar o que o produto

necessita.

O Product Owner (PO) a nica pessoa responsvel pelo gerenciamento do Product Backlog e

Quem Responsvel por Manter o Product Backlog ?


70/77


Workshop

SCRUM


O Product Owner (PO) a nica pessoa responsvel pelo gerenciamento do Product Backlog epor garantir o valor do trabalho realizado pela Equipe.O PO mantm o Product Backlog (PB) e assegura que ele est visvel para todos. Todos sabemquais itens tm a maior prioridade, de forma que todos sabem em que se ir trabalhar.O Product Owner deve ser uma pessoa, e no um comit. Podem existir comits que aconselhemou influenciem , mas somente o PO poder mudar a prioridade de um item do PB. Empresas que

adotam Scrum podem perceber que isso influencia seus mtodos para definir prioridades e requisitosao longo do tempo.Para que o PO obtenha sucesso, todos na organizao precisam respeitar suas decises.Somente o PO pode definir a prioridade dos itens que a equipe ir trabalhar.As decises do Product Owner so visveis no contedo e na priorizao do Product Backlog. Essavisibilidade requer que o Product Owner faa seu melhor, o que faz o papel de Product Owner

exigente e recompensador ao mesmo tempo.

70

Product Backlog e as responsabilidades do PO: Criar ,Priorizar e Manter o Product Backlog.

Manter o Produto Backlog atualizado:


71/77


Workshop

SCRUM


SprintBacklog

Produto


Reuniodiria

24 horas

Revisoda Sprint


Viso

Produto

BacklogSprint

2-4 Semanas

O Product Backlog poder sofrer atualizaes no decorrer de uma reunio de Planejamento deuma Sprint.Exemplo: Quando uma estria do usurio considerada pico, ele ser dividida em outras estrias eisto dever ser refletido no Product Backlog.



72/77


73/77

Quer mais ?Os membros da comunidade podem participar dos eventos treinamentos e cursos gratuitos


74/77


Workshop

SCRUM


Os membros da comunidade podem participar dos eventos, treinamentos e cursos gratuitos.Comunidade: http://etecnologia.ning.com/

Para participar da comunidade basta se cadastrar: http://bit.ly/czZlezA misso da comunidade compartilhar conhecimento, trocar experincias e proveraprendizado.

74

Licena:


75/77


Workshop

SCRUM


Notas:Marcas Registradas:


76/77


Workshop

SCRUM


Marcas Registradas:

Todos os termos mencionados que so reconhecidos como Marca Registrada e/ou comercial so deresponsabilidades de seus proprietrios. O autor informa no estar associada a nenhum produto e/oufornecedor que 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 para finseducativo, no visando ao lucro, favorecimento ou desmerecimento da marca ou produto.

Melhoria e Reviso:

Este material esta em processo constante de reviso e melhoria, se voc encontrou algum problemaou erro envie um e-mail ns.

Criticas e Sugestes:

Ns estamos abertos para receber criticas e sugestes que possam melhorar o material, por favorenvie um e-mail para ns.

Rildo F dos Santos ([email protected])

Imagens:

Google, Flickr e Banco de Imagem.

Como


77/77

Workshop

SCRUM

Rildo F Santosrildo santos@etecnologia com br

www.etcnologia.com.br

Comocriar,

estimar,priorizar e

manter oProductBacklog

Workshop Como Criar, Estimar, Priorizar e Manter o Product Backlog

Documents

Transcript of Workshop Como Criar, Estimar, Priorizar e Manter o Product Backlog