• Save
Como Criar, Estimar, Priorizar e Manter o Product Backlog
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Como Criar, Estimar, Priorizar e Manter o Product Backlog

on

  • 18,429 views

Este tutorial tem como objetivo compartilhar conhecimento, sobre: Como criar, estimar, priorizar e manter o Product Backlog utilizando as melhores práticas, técnicas e ferramentas.

Este tutorial tem como objetivo compartilhar conhecimento, sobre: Como criar, estimar, priorizar e manter o Product Backlog utilizando as melhores práticas, técnicas e ferramentas.

Statistics

Views

Total Views
18,429
Views on SlideShare
18,288
Embed Views
141

Actions

Likes
42
Downloads
297
Comments
0

6 Embeds 141

http://www.rildosan.com 122
http://rildosan.blogspot.com 12
https://www.linkedin.com 3
http://www.linkedin.com 2
http://www.rildosan.blogspot.com 1
http://a0.twimg.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Como Criar, Estimar, Priorizar e Manter o Product Backlog Presentation Transcript

  • 1. Comocriar,Como criar, estimar, priorizar e manter o Product Backlogestimar,priorizar emanter oProductBacklog www.etcnologia.com.br Rildo F Santos rildo.santos@etecnologia.com.br (11) 9123-5358 twitter: @rildosan (11) 9962-4260 http://rildosan.blogspot.com Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com
  • 2. O Conteúdo do workshop: 1 2 3 4Como criar, estimar, priorizar e manter o Product Backlog Criar Estimar Priorizar Manter 1 – Como Criar o Product Backlog 2 – Como Estimar o Product Backlog 3 – Como Priorizar o Product Backlog 4 – Como Manter o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 2
  • 3. Como criar, estimar, priorizar e manter o Product Backlog Objetivo: Objetivo: Compartilhar conhecimento, trocar experiência e prover aprendizado de Como criar, estimar, priorizar e manter o Product Backlog utilizando as melhores práticas, técnicas e ferramentas. Pré-requisito: Conhecimento do Scrum. Se você não conhece o Scrum recomendamos fazer o Workshop SCRUM (http://etecnologia.ning.com/group/scrum ) primeiro e depois esse treinamento. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 3
  • 4. Como criar, estimar, priorizar e manter o Product Backlog Programa: “Menos Papel, Mais Árvores ®” Qual é o mundo que queremos ? O primeiro passo para criar um mundo melhor, é saber qual tipo de mundo que queremos ter e qual tipo que deixaremos de herança para as próximas gerações. Nossa missão: É buscar pelo equilibro do homem, da tecnologia e do meio ambiente. Para cumprir esta missão é necessário: conscientizar, comprometer e AGIR. O programa Menos Papel, Mais Árvores®, é uma ação, com objetivo de estimular o consumo sustentável de papel dentro das organizações. Quer participar ? - Reduza o uso de papel (e de madeira) o máximo possível. - Só imprima se for extremamente necessário. - Evite comprar produtos com excesso de embalagem. - Ao imprimir ou escrever, utilize os dois lados do papel. - Use papel reciclado. Este material não deve ser impresso.. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 4
  • 5. Facilitador: Rildo F. Santos (@rildosan) Coach , Instrutor, Consultor e Palestrante de Métodos Ágeis, Gestão de Negócios, Inovação , Processos e Tecnologia . Minha Experiência: Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Sou formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre emComo criar, estimar, priorizar e manter o Product Backlog Engenharia de Software pela Universidade Mackenzie. Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java (Sun MicroSystems e IBM). Conheço Métodos Ágeis (SCRUM, XP, FDD, Lean e OpenUP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias. Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA. Tenho conhecimento de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC - Governance, Risk ando Compliance), SOX, Basel II e PCI; Experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Fluência nos principais frameworks e padrões: ITIL, Cobit, ISO 20000, ISO 27001 e ISO 15999; Participei de diversos projetos nos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás. Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, 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: @rildosan Blog: http://rildosan.blogspot.com/ Comunidade: http://etecnologia.ning.com Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 5
  • 6. Conteúdo do Workshop: 1 2 3 4Como criar, estimar, priorizar e manter o Product Backlog Criar Estimar Priorizar Manter 1 – Como Criar o Product Backlog 2 – Como Estimar o Product Backlog 3 – Como Priorizar o Product Backlog 4 – Como Manter o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 6
  • 7. Como criar, estimar, priorizar e manter o Product Backlog Objetivo: Objetivo dessa parte: Apresentar e discutir como Criar o Product Backlog. Pré-requisito: Conhecimento do Scrum. Se você não conhece o Scrum recomendamos fazer o Workshop SCRUM (http://etecnologia.ning.com/group/scrum ) primeiro e depois esse treinamento. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 7
  • 8. Como criar, estimar, priorizar e manter o Product Backlog Parte 1: Como Criar o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 8
  • 9. Framework SCRUM: O Framework Scrum é composto por uma Equipe (Time) Scrum e seus papéis: Product Owner (PO), Scrum Master (SM) e Equipe de desenvolvedores, Eventos com duração fixa (Time-Boxes), Artefatos e Regras.Como criar, estimar, priorizar e manter o Product Backlog Planejamento Planejamento Reunião Revisão diária Retrospectiva da Release da Sprint da Sprint da Sprint O foco 24 horas desse workshop Product Sprint Backlog Backlog Produto Sprint (2-4 Semanas) Visão Legenda: Reuniões Artefatos Eventos (Reuniões) Papéis Artefatos  Planejamento da Release • Product Owner (PO)  Planejamento da Sprint • Product Backlog • ScrumMaster (SM)  Diária • Sprint Backlog • Equipe (time)  Revisão da Sprint • Sprint Burndown  Retrospectiva da Sprint • Release Burndown Sprint Burndown Release Burndown Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 9
  • 10. Framework Scrum: As Regras As Regras fazem o elo entre os eventos com duração fixa (time-boxes), os papéis e os artefatos 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.Como criar, estimar, priorizar e manter o Product Backlog - O Product Owner é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time. - Essa pessoa mantém o Product Backlog e garante que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 10
  • 11. Framework Scrum: Product Owner (PO) O Product Owner (PO) é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pela Equipe. O PO mantém o Product Backlog (PB) e assegura que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar.Como criar, estimar, priorizar e manter o Product Backlog O Product Owner deve ser uma pessoa, e não um comitê. Podem existir comitês que aconselhem ou influenciem , mas somente o PO poderá mudar a prioridade de um item do PB. Empresas que adotam Scrum podem perceber que isso influencia seus métodos para definir prioridades e requisitos ao longo do tempo. Para que o PO obtenha sucesso, todos na organização precisam respeitar suas decisões. Somente o PO pode definir a prioridade dos itens que a equipe irá trabalhar. As decisões do Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa visibilidade requer que o Product Owner faça 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. Somente detalhamos papel do Product Onwer, pois, é ele é responsável direto pelo Product Backlog. O ScrumMaster, que é responsável por garantir que o processo (as práticas do SCRUM) seja compreendido e seguido. É responsável ainda por: - Remover impedimentos; - Proteger a equipe; - Ajudar o PO (quando necessário); - Ser o facilitador da equipe. A equipe (ou time), é responsável pelo desenvolvimento do produto, é formada por desenvolvedores que devem ter as habilidades necessárias para transformar os itens do Product Backlog em Produto. A Equipe ainda é responsável por: - Fazer estimativa; - Definir as tarefas; - Garantir a qualidade do produto; - Apresentar o produto ao cliente Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 11
  • 12. Como criar, estimar, priorizar e manter o Product Backlog Framework Scrum: Artefatos Scrum tem quatro artefatos principais: - Product Backlog: é uma lista priorizada de tudo que pode ser necessário 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, em um incremento do produto potencialmente entregável. Um burndown é uma medida do backlog 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 primário é o Product Backlog. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 12
  • 13. Questões sobre o Product Backlog: O que é o Product Backlog ? Product Backlog: é uma lista priorizada de tudo que pode ser necessário no produto. O Product Backlog representa tudo que é necessário para desenvolver e lançar um produto de sucesso. É uma lista de todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para releases futuras. OsComo criar, estimar, priorizar e manter o Product Backlog itens do Product Backlog possuem os atributos de descrição, prioridade e estimativa. A prioridade é determinada por risco, valor e necessidade. Há diversas técnicas para dar valor a esses atributos (veremos isso mais tarde). Quem é responsável pelo Product Backlog ? O Product Owner (PO) é o responsável pelo Product Backlog , por sua criação, por seu conteúdo, por sua disponibilidade e por sua priorização. Até quando o Product Backlog existirá ? O Product Backlog nunca está completo. A seleção inicial para o seu desenvolvimento somente mostra os requisitos inicialmente conhecidos e melhor entendidos. O Product Backlog evolui à medida que o produto e o ambiente em que ele será usado evoluem. O Backlog é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil. Enquanto existir um produto, o Product Backlog também existirá. Resumo: O clico de vida do Product Backlog está ligado ao ciclo de vida do Produto Qual é a ordenação do Product Backlog ? O Product Backlog é ordenado por prioridade, os itens com as maiores prioridades devem ter o desenvolvimento imediato. Quanto mais alta sua prioridade, mais urgente ele é, mais se pensou sobre ele e há mais consenso no que diz respeito ao seu valor. Os itens do Backlog de maior prioridade, possuem mais informações e detalhes do que os itens do Backlog de menor prioridade. É mais fácil de fazer a estimativa quando existem mais informações e mais detalhes. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 13
  • 14. Questões sobre o Product Backlog: Por que o Product Backlog pode mudar ? Porque quando um produto é utilizado, e seu valor aumenta e o cliente pode fornecer feedback, o Product Backlog poderá se tornar uma lista maior e mais aprofundada. Os requisitos geralmenteComo criar, estimar, priorizar e manter o Product Backlog mudam (alguns com maior frenquência e outros com menor frequência). O Product Backlog é um documento vivo. Mudanças nos requisitos de negócios, condições do mercado, tecnologia e equipe causam mudanças no Product Backlog. Para reduzir o retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados. Os itens do Product Backlog que ocuparão a Equipe Scrum pelas várias Sprints seguintes deverão ter granularidade mais fina (mais detalhados), tendo sido decompostos de forma tal que cada um dos itens possa ser feito dentro da duração da Sprint. Quando existe diversas equipes trabalhando para construir um produto quantos Product Backlog devemos ter ? Se múltiplas 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 características, por tecnologia ou por arquitetura, e ele é frequentemente utilizado como uma forma de se organizar o trabalho por equipe. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 14
  • 15. Como criar o Product Backlog: Para definir a visão do Produto, primeiro é necessário entender qual é a real necessidade do cliente: A necessidade: Um hotel, quer incrementar um novo canal de consultas e vendas de reservas de apartamentos. A sugestão foi criar um Portal de Reservas para vender os serviços.Como criar, estimar, priorizar e manter o Product Backlog Após entender a necessidade do cliente, é hora de definir a Visão do Produto: Declaração da Visão do Produto: Para o Hotel que necessita de um Sistema o Portal de Reservas On-Line é um software baseado na web, intuitivo e fácil de usar que fornece a possibilidade fazer a consultas e reservas de apartamentos. Diferente de outros sistemas, o produto oferece um canal direto de acesso ao cliente. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 15
  • 16. Definindo a Visão do Produto: Introdução: Qualquer produto está necessariamente associada a uma visão, pois, a visão deve descrever o produto em relação a necessidade do usuário (cliente). A visão do produto somente será significativa se apresentada e compartilhada pela equipe SCRUM.Como criar, estimar, priorizar e manter o Product Backlog A definição da visão do produto é uma responsabilidade Product Owner. Mas, ele poderá desenvolver a visão do produto em colaboração com a equipe de desenvolvimento de software e o cliente final A Declaração da Visão do Produto: A declaração de Visão do Produto deve ser simples, consistente, objetiva e de fácil entendimento, e que tenha informações sobre a necessidade do cliente, o que é produto esperado e quais sãos os seus principais benefícios. A declaração ainda deve descrever a motivação e o diferencial do produto em relação aos outros concorretes. Duas técnicas que ajudam no desenvolvimento da da Visão do Produto: - A Declaração do Elevador (que também pode ser chamada de Visão Sintética) - Product Vision Box. (Visão da Caixa do Produto) Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 16
  • 17. Definindo a Visão do Produto: Declaração do Elevador ou “Visão sintética" (essencial) Segundo Moore (1991). É também chamada Elevator Pitch, mas podemos chamar "visão sintética“. A Visão Sintética é estruturada em 6 partes que resumem em menos de dois minutos a Visão do Produto. Primeira Técnica: Declaração do Elevador (Elevator Statement)Como criar, estimar, priorizar e manter o Product Backlog • For (target customer) O nome desta técnica é uma • Who (statement of the need or opportunity) alusão ao seguinte desafio: você tem que influenciar ou passar um • The (product name) is a (product category) mensagem para um pessoa em • That (key benefit, compelling reason to buy) curto espaço de tempo uma • Unlike (primary competitive alternative) viagem de elevador. • Our product (statement of primary differentiation) Com o tempo é curto a mensagem tem que ser objetiva e clara. Exemplo de Visão do Produto utilizando a Declaração do Elevador: Para empresas médias de marketing e departamento de vendas que necessitam de um sistema de CRM, o EeaseCRM é um software baseado na web, intuitivo e fácil de usar que fornece a possibilidade fazer a rastreabilidade de vendas, geração de leads e possibilita o estreitamento do relacionamento com o cliente. Diferente de outros serviços ou produtos, nosso produto oferece a melhor relação custo beneficio. Product Owner (PO), é responsável por definir, manter e comunicar a Visão do Produto para todos os stakeholders. A equipe pode colaborar com o desenvolvimento da Visão do Produto. Product Owner Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 17
  • 18. Definindo a Visão do Produto: Visão do Produto: Segunda Técnica: Product Vision Box (Visão da Caixa do Produto) Segundo Highsmith (2004). O Produto Vision Box é uma técnica altamente relevante para iniciar umComo criar, estimar, priorizar e manter o Product Backlog projeto para construir a visão e compartilhá-lo com todas as partes interessadas no produto. O resultado de um projeto de desenvolvimento de software é o “produto”. O produto pode ser representado por uma caixa (“a caixa” do produto). “Product Vision Box“ é uma técnica que ajuda no entendimento da Visão do Produto, pois, quando fazemos uma representação visual do produto (“caixa”, por exemplo) isto ajuda na redução do nível de abstração (ou seja, melhora o entendimento do que ser feito). A caixa final, é construída coletivamente, com base no que precede, no consenso e colaboração. Esta "Visão da Caixa do Produto" é a visão compartilhada, e irá incorporar os seguintes elementos: • Parte da frente da caixa: Nome - Imagem (se possível) - divisão - argumentos que ajudam a vender o produto • Parte de trás da caixa: Colocar de forma mais detalhada as principais funcionalidade, os pré-requisitos e etc... Este exercício ajuda a melhorar o entendimento, identificar possíveis conflitos e reduz a abstração. O formato desse exercício exige que os as pessoas tenham uma participação intensa e as vezes até exaustiva. Mas, a visão da caixa do produto é definida sempre em consenso. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 18
  • 19. Definindo a Visão do Produto: Visão do Produto: Exemplo: Product Vision Box Informações sobre o produto:Como criar, estimar, priorizar e manter o Product Backlog - Nome do Produto: - Logotipo ou desenho que represente o produto - Principais benefícios que ajuda a “vender” o produto - Principais características e/ou funcionalidades do produto - Principais requisitos técnicos http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/ Product Owner (PO), pode utilizar esta técnica para exercitar o Product Owner desenvolvimento da visão do produto junto com a equipe. Fonte: Agile Project Management: Creating Innovative Products - Jim Highsmith Cap. 5 - Practice: Product Vision Box and Elevator Test - Pg. 93 Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 19
  • 20. Como criar o Product Backlog Após a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog:Como criar, estimar, priorizar e manter o Product Backlog agrupamento Funcionalidades do produto O Product Backlog, inicialmente é uma lista que representa tudo que é necessário para desenvolver e lançar um produto. A lista deve conter todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para futuras releases . O Product Backlog é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 20
  • 21. Como criar, estimar, priorizar e manter o Product Backlog Estudo de Caso: Visão do Produto Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 21
  • 22. Conteúdo do Workshop: 1 2 3 4Como criar, estimar, priorizar e manter o Product Backlog Criar Estimar Priorizar Manter 1 – Como Criar o Product Backlog 2 – Como Estimar o Product Backlog 3 – Como Priorizar o Product Backlog 4 – Como Manter o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 22
  • 23. Como criar, estimar, priorizar e manter o Product Backlog Objetivo: Objetivo dessa parte: Apresentar e discutir como “Estimar” o Product Backlog. Pré-requisito: Conhecimento do Scrum. Se você não conhece o Scrum recomendamos fazer o Workshop SCRUM (http://etecnologia.ning.com/group/scrum) primeiro e depois esse treinamento. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 23
  • 24. Como criar, estimar, priorizar e manter o Product Backlog Parte 2: Como Estimar o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 24
  • 25. Framework SCRUM: O Framework Scrum é composto por uma Equipe (Time) Scrum e seus papéis: Product Owner (PO), Scrum Master (SM) e Equipe de desenvolvedores, Eventos com duração fixa (Time-Boxes), Artefatos e Regras.Como criar, estimar, priorizar e manter o Product Backlog Planejamento Planejamento Reunião Revisão diária Retrospectiva da Release da Sprint da Sprint da Sprint O foco 24 horas desse workshop Product Sprint Backlog Backlog Produto Sprint (2-4 Semanas) Visão Legenda: Reuniões Artefatos Eventos (Reuniões) Papéis Artefatos  Planejamento da Release • Product Owner (PO)  Planejamento da Sprint • Product Backlog • ScrumMaster (SM)  Diária • Sprint Backlog • Equipe (time)  Revisão da Sprint • Sprint Burndown  Retrospectiva da Sprint • Release Burndown Sprint Burndown Release Burndown Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 25
  • 26. Introdução, a Reunião de Planejamento da Release: Na reunião de Planejamento da Release o Product Backlog é estimado e priorizado. O PO é responsável por priorizar os itens do Product Backlog (isto será visto na próxima aula). A equipe é responsável por estimar os itens do Product Backlog.Como criar, estimar, priorizar e manter o Product Backlog Planejamento Planejamento Reunião Revisão diária Retrospectiva da Release da Sprint da Sprint da Sprint 24 horas Produto Sprint Backlog Backlog Produto Sprint 2-4 Semanas Visão Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 26
  • 27. Equipe (Responsável por fazer a estimativa): A equipe (ou time), é responsável pelo desenvolvimento do produto, é formada por desenvolvedores que devem ter as habilidades necessárias para transformar os itens do Product Backlog em Produto. A Equipe ainda é responsável por: - Fazer estimativa; - Definir as tarefas;Como criar, estimar, priorizar e manter o Product Backlog - Garantir a qualidade do produto; - Apresentar o produto ao cliente Destacamos: a tarefa Fazer Estimativa que é uma responsabilidade da equipe (time) O Product Owner (PO) é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pela Equipe. O PO mantém o Product Backlog (PB) e assegura que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar. O Product Owner deve ser uma pessoa, e não um comitê. Podem existir comitês que aconselhem ou influenciem , mas somente o PO poderá mudar a prioridade de um item do PB. Empresas que adotam Scrum podem perceber que isso influencia seus métodos para definir prioridades e requisitos ao longo do tempo. Para que o PO obtenha sucesso, todos na organização precisam respeitar suas decisões. Somente o PO pode definir a prioridade dos itens que a equipe irá trabalhar. As decisões do Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa visibilidade requer que o Product Owner faça 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. O ScrumMaster, que é responsável por garantir que o processo (as práticas do SCRUM) seja compreendido e seguido. É responsável ainda por: - Remover impedimentos; - Proteger a equipe; - Ajudar o PO (quando necessário); - Ser o facilitador da equipe. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 27
  • 28. Versão inicial do Product Backlog: Após a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog, note que ele não foi estimado nem priorizado.Como criar, estimar, priorizar e manter o Product Backlog agrupamento Funcionalidades do produto O Product Backlog, inicialmente é uma lista que representa tudo que é necessário para desenvolver e lançar um produto. A lista deve conter todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para futuras releases . O Product Backlog é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 28
  • 29. Reunião de Planejamento da Release: A estimativa e a priorização devem ser feitas na Reunião de Planejamento da Release. O propósito do planejamento da release é o de estabelecer um plano e metas que a Equipe Scrum e o resto da organização possam entender e comunicar.Como criar, estimar, priorizar e manter o Product Backlog O planejamento da release responde às questões: - Como podemos transformar a visão em um produto da melhor maneira possível? - Como podemos alcançar ou exceder a satisfação do cliente ? - Como podemos alcançar o ROI (retorno sobre investimento) ? O Plano da Release estabelece a meta da release, as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na release. Ele estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar. A organização pode então inspecionar o progresso e fazer mudanças nesse plano da release a cada Sprint. Contudo, O planejamento da release é inteiramente opcional. Se uma Equipe Scrum iniciar o trabalho sem essa reunião, a ausência de seus artefatos aparecerá como um impedimento que deverá ser resolvido. O trabalho para resolver o impedimento se tornará um item no Product Backlog. Ao se utilizar Scrum, os produtos são construídos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vão adicionando incrementos ao produto. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 29
  • 30. Reunião de Planejamento da Release: A estimativa e a priorização devem ser feitas na Reunião de Planejamento da Release. Cada incremento é um pedaço potencialmente entregável do produto completo. Quando já tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto éComo criar, estimar, priorizar e manter o Product Backlog entregue Muitas organizações já tem um processo de Planejamento de Release, e na maior parte desses processos o planejamento é feito no início do trabalho da release e não é modificado com o passar do tempo. No Planejamento de Release do Scrum, são definidos uma meta geral e resultados prováveis. Esse planejamento geralmente não requer mais do que 15-20% do tempo que uma organização costumava utilizar para produzir um plano de release tradicional. No entanto, uma release com Scrum realiza planejamento no momento da execução de cada reunião de Revisão de Sprint e de Planejamento de Sprint, da mesma forma que realiza um planejamento diário no momento da execução de cada Reunião Diária. De forma geral, os esforços para uma release com Scrum provavelmente consomem ligeiramente mais esforço do que os esforços para um planejamento de release tradicional. O planejamento da release requer estimar e priorizar o Product Backlog para a release. Existem diversas técnicas para fazê-lo, mas o SCRUM é um framework, não indica nenhuma técnica. Contudo, nessa aula abordaremos algumas técnicas para estimar o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 30
  • 31. Visão Geral da Reunião de Planejamento da Release: Entradas Saídas ReleaseComo criar, estimar, priorizar e manter o Product Backlog Burndown (artefato) Visão do Produto Reunião de Planejamento da Release Product Backlog (visão inicial) Product Backlog (priorizado e estimado) Os participantes: Equipe SCRUM Plano de Release Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 31
  • 32. Reunião de Planejamento da Release: Fazendo estimativas Visão inicial do Product Backlog, antes da reunião de Planejamento da 1 Release, ele tem somente as funcionalidades do produto, agrupadas por tema (este agrupamento é opcional). Uma das atividades da reunião de Planejamento da Release é definir o Plano de Release, nesse plano estabelece-se o prazo de entregaComo criar, estimar, priorizar e manter o Product Backlog (estimado) do produto e nível de prioridade dos itens do Product Backlog. Para chegarmos na data de entrega do produto esperada, o PO deve perguntar diretamente ao cliente. A equipe é responsável por fazer a estimativa dos itens do Product Backlog. 2 Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 32
  • 33. Por que estimar é difícil ? Em um projeto desenvolvimento de software quase todas as variáveis são incertas... O Cone da Incerteza: No início de um projeto, detalhes específicos sobre a natureza do software a ser construído, os detalhes dos requisitos específicos, os detalhes da solução, plano de projeto, equipe e outras variáveis do projeto são claras. A variabilidade desses fatores contribui para a variabilidade de estimativas do projeto - umaComo criar, estimar, priorizar e manter o Product Backlog estimativa exata de um fenômeno variável deve incluir a variabilidade do fenômeno em si. Como estas fontes de variabilidades são investigados e tratadas, a variabilidade no projeto diminui ao longo do tempo (no decorrer do projeto), e assim a variabilidade no projeto estimada também pode diminuir. Este fenômeno é conhecido como o "Cone da Incerteza", que é ilustrado na figura a seguir. Como a figura sugere, a redução significativa do Cone ocorrem durante os primeiros 20-30% do tempo total de calendário para o projeto. O eixo horizontal contém etapas do projeto comum, como conceito inicial, definição do produto aprovado, requisitos completos, e assim por diante. "Definição do produto" refere-se apenas ao acordado visão para o software, ou "conceito de software", e é igualmente aplicável aos serviços de web, sistemas internos de negócios, e a maioria dos outros tipos de projetos de software. O eixo vertical contém o grau de erro que foi encontrado nas estimativas criado por estimadores qualificados em vários pontos do projeto. As estimativas poderiam ser para o quanto um conjunto de características particulares vai custar e quanto esforço será necessário para entregar esse conjunto de recursos, ou poderia ser de quantos recursos podem ser entregues para uma determinada quantidade de esforço ou programação. Como você pode ver na figura, as estimativas criadas logo no início do projeto estão sujeitos a um elevado grau de erro. Estimativas iniciais são mais imprecisas do que as Cone da Incerteza outras variáveis que foram criadas ao longo do projeto. Fonte: http://www.construx.com/Page.aspx?hid=1648 Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 33
  • 34. Por que estimar é difícil ? O Cone da Incerteza: (continuação) Quando trabalhamos com Métodos ágeis, o SCRUM por exemplo, é que podemos observar este fenômeno invertido, explicando melhor, se perguntarmos a um desenvolvedor que já esta trabalhando em um projeto o que ele consegue entregar nas próximas duas semanas a estimativa com certeza será bem precisa, mas se perguntarmos o que ele consegue entregar daqui a 4 meses, dificilmente ele terá umaComo criar, estimar, priorizar e manter o Product Backlog ideia claro e vai “chutar” uma estimativa qualquer, pois, não há como ter plena certeza do que irá acontecer. A única certeza que podemos ter em qualquer projeto de software é de que as coisas vão mudar, os requisitos, o design, as funcionalidades e etc. Mas, como SCRUM faz de entregas de software funcionando em ciclos constantes e curtos e com isso se adaptar as constantes mudanças. E em projetos ágeis, não faz o Clone da Incerteza desaparecer, mas temos sempre mais certeza sobre as estórias do usuário que estão priorizadas para o próxima Sprint ou estamos trabalhando neste momento e vamos melhorando nossas estimativas e aumentando a precisão delas conforme os itens do Product Backlog vai sendo entregues, mas, com uma visão muito clara do curto prazo e menos clara para o que esta no fim do Product Backlog. Importante: As estórias do usuário que estão sendo desenvolvidas no Sprint são as de maior ROI para o projeto. Sendo assim o Cone de Incerteza aplicado a uma equipe que utiliza Scrum teria este formato: Cone da Incerteza para projetos que utilizam Scrum Fontes: http://www.implementingscrum.com/2008/02/19/vegas-hangover-enlightenment/ e http://www.acarlos.com.br/blog/category/scrum/page/3/ Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 34
  • 35. Por que estimar é difícil ? No mundo real fazer estimativa é ter uma valor aproximado, mas em desenvolvimento de software o entendimento é outro, estimativa é tida como uma valor exato, é claro que esta visão equivocada. - Estimativa (Mundo real) = Valor aproximado - Estimativa (Desenvolvimento de Software) = Valor exatoComo criar, estimar, priorizar e manter o Product Backlog Cena 1 – Sprint Review Cena 2 – Planejamento da Sprint ???? ???? Vocês erraram Preciso de uma a estimativa ... data estimada ???? exata.. ???? PO Equipe PO Equipe Pontos de Estória (Story Points): Dias ideias (Ideal Days): ◦ Valores relativos ◦ Mais fácil para iniciantes ◦ Mais abstrato ◦ Fácil de explicar Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 35
  • 36. Estimando Product Backlog: Quando trabalhamos com métodos ágeis temos pelo menos duas formas para estimar a velocidade da equipe: Ideal Days e Pontos de Estória. Recomendamos utilizar os Pontos de Estória. Ideal Days: Dias Ideais (Ideal Days) ◦ Mais fácil para iniciantes Baseado na duração de tarefas.Como criar, estimar, priorizar e manter o Product Backlog ◦ Fácil de explicar - Dias ou horas é unidade bem definida, contudo o “tempo ideal” quase nunca é igual ao “tempo real”... - É mais fácil de estimar, mas pode ser tornar difícil de estimar se consideramos todas as interrupções e variações Ideal Days foi definido por Kent Beck para referenciar um dia totalmente livre de impedimentos para o desenvolvedor. No seu livro, Extreme Programming Explained, Beck descreveu o dia ideal, como o tempo necessário para concluir uma estória do usuário “sem interrupções ou reuniões” Esta ideia ressalta que os desenvolvedores eventualmente executam outras atividades durante o dia, além de programar. Pontos de Estória: Pontos de Estória (Story Points) ◦ Valores relativos Baseia-se no tamanho da estória influenciado pela: ◦ Mais abstrato - Nível de dificuldade, complexidade e experiência (é empírico); Foco nas funcionalidades; O importante são os valores relativos; Pontos são medidas sem unidade; Equipe diferentes podem ter pontos diferentes para a mesma estórias. Principais técnicas: ◦ Opinião de especialista (alguém que está ajuda a implementar o Scrum na empresa – as vezes um Coach); ◦ Analogia; ◦ Decomposição (Dividir para conquistar) ou Desagregação. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 36
  • 37. Técnicas que ajudam a Estimar: Existem 3 técnicas que podem ajudar a fazer estimativas: Estimativa por analogia: - Comparando a estória do usuário com outra estória: "Esta estória é muito parecida com aquela de Cadastro de Cliente, nós estimamos aquela estóriaComo criar, estimar, priorizar e manter o Product Backlog com 11 pontos...” - Não utilize um único padrão (técnica). Procure utilizar pelo dois ou mais padrões. - Triangulação: “Comparar a estória que está sendo estimada em com várias outras estórias” Desagregação: - Quebrar uma estória do usuário “grande” em estória “menores” ou tarefas É mais fácil estimar com base em tarefas - Cuidado, a desagregação em excesso pode caurar problemas: Como esquecimento de algumas tarefas Triangulação: - Certifique que estimativa será feita, comparando a estória do usuário com várias outras estórias Estória A - Grupo de estória do usuário com tamanho próximos estão em uma tabela ou quadro branco, isto facilita o trabalho. Estória B Estória D Estória F Estória C Estória E Fonte: Agile Estimating and Planning – Mike Cohn Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 37
  • 38. Estimando os itens do Product Backlog: Detalhando os itens do Produto Backlog em estórias do usuário: Para facilitar o entendimento dos itens do Product Backlog ele são descritos em estórias do usuário elas auxiliam no entendimento do que deve ser feito, permite fazer aComo criar, estimar, priorizar e manter o Product Backlog estimativa de velocidade da equipe e também é, utilizada como lembrete e para as atividades de planejamento. Geralmente a estimativa é feita em pontos (pontos de estória) Como escrever uma Estória do Usuário ? Conversações sobre a estória, entre os usuários e desenvolvedores, de modo a detalhar o item do Product Backlog e esclarecer todas as dúvidas sobre do que deve ser feito. Estória do Usuário Cartão: Estória do Usuário são tradicionalmente Titulo: “Fazer Reserva de Apartamentos” escritas em um cartão. Cartão podem ter notas, estimativas, comentário observações e etc Como cliente de negócio, eu quero fazer reserva de apartamentos pela web para facilitar o meu Conversas: Detalhes que podem surgir durante as conversas com PO (Product Owner) e/ou cliente. planejamento. Confirmação: Testes de aceitação “confirmam” se a Estória do Usuário foi codificada da forma correta. Pontos: ? Prioridade: Alta Testes de aceitação são tipo Caixa Preta. Boa Prática: A Estória do Usuário deve prover o entendimento do que deve ser feito e deve facilitar a estimativa de velocidade da equipe. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 38
  • 39. Estimando os itens do Product Backlog: Estimativa* e o Planning Poker: Para fazer estimativa de velocidade da equipe ou de duração da Sprint, antes é preciso o escrever as estórias do usuário. O Planning Poker é uma “prática” que ajuda na estimativa de uma estória ou de uma tarefa e é baseadaComo criar, estimar, priorizar e manter o Product Backlog no consenso de toda a equipe. Geralmente o Planning Poker usa um conjunto de cartas com valores específicos que podem representar pontos relativos e é praticado como se fosse um jogo de cartas. Os pontos devem estar em uma escala não linear, por e exemplo a Fibonacci: (1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala. Jogando o Planning Poker: Antes de começar o jogo é necessário definir um valor de referência. Por exemplo: Identificar a estória que pode ser atribuído a menor quantidade pontos, esta estória será utilizada como referência para pontuação das demais estórias. O PO apresenta uma estória e pede para os membros da equipe fazer a estimativa de velocidade... 1ª. Rodada Quando todas as cartas Nª. Rodada 40 100 estiverem lançadas, elas 40 40 são viradas e caso não Pessoal, qual é haja consenso nos estimativa para essa estória... pontos, as diferenças são discutidas de forma breve, e uma nova 40 40 40 rodada acontece até que 40 haja concesso. Product Owner Equipe Equipe Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 39
  • 40. Estimando os itens do Product Backlog: Todos os itens do Product Backlog devem ser estimados, pois, assim PO poderá construir o Plano de Release e Release Burndown, que é um dos artefatos produzidos nessa reunião..Como criar, estimar, priorizar e manter o Product Backlog Escrevendo as Estórias do Usuário Product Backlog Planning Poker 20 20 Pessoal, qual é estimativa para essa estória... 40 20 Product Owner Equipe Estimando Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 40
  • 41. Product Backlog Estimado: Após a estimativa de todos os itens do Product Backlog, o próximo passo é fazer a priorização dos itens. Veja o Product Backlog com as estimativas.Como criar, estimar, priorizar e manter o Product Backlog Os itens do Product Backlog possuem os atributos de descrição, estimativa e prioridade. A prioridade é determinada por risco, valor e necessidade. O Product Backlog nunca está completo. A seleção inicial para o seu desenvolvimento somente mostra os requisitos inicialmente conhecidos e melhor entendidos. O Product Backlog evolui à medida que o produto e o ambiente em que ele será usado evoluem. O Backlog é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil. Enquanto existir um produto, o Product Backlog também existirá. Resumo: O clico de vida do Product Backlog está ligado ao ciclo de vida do Produto Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 41
  • 42. Reunião de Planejamento da Release: PB estimado 1 2Como criar, estimar, priorizar e manter o Product Backlog Definição da estimativa do Product Backlog Versão inicial do Product Backlog, sem estimativa e nem priorização. Após a equipe concluir a estimativa do Product Backlog é necessário fazer Plano de Release 3 a priorização dos itens. Isto é responsabilidade do PO. Relacionamento Programa de Sprints# Reserva Promoções Tour Virtual 5 Sprints ao cliente Fidelidade Nível de ? ? ? ? ? Prioridade Prazo 30 dias 15 dias 7 dias 15 dias 15 dias 82 dias (estimado) Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 42
  • 43. Como criar, estimar, priorizar e manter o Product Backlog Reunião de Planejamento da Release. Check List parcial Falta priorizar, mas isso é assunto para próxima aula Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 43
  • 44. Conteúdo do Workshop: 1 2 3 4Como criar, estimar, priorizar e manter o Product Backlog Criar Estimar Priorizar Manter 1 – Como Criar o Product Backlog 2 – Como Estimar o Product Backlog 3 – Como Priorizar o Product Backlog 4 – Como Manter o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 44
  • 45. Como criar, estimar, priorizar e manter o Product Backlog Parte 3: Como Priorizar o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 45
  • 46. Como criar, estimar, priorizar e manter o Product Backlog Objetivo: Objetivo dessa parte: Apresentar e discutir como “Priorizar” o Product Backlog. Pré-requisito: Conhecimento do Scrum. Se você não conhece o Scrum recomendamos fazer o Workshop SCRUM (http://etecnologia.ning.com/group/scrum) primeiro e depois esse treinamento. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 46
  • 47. Framework SCRUM: O Framework Scrum é composto por uma Equipe (Time) Scrum e seus papéis: Product Owner (PO), Scrum Master (SM) e Equipe de desenvolvedores, Eventos com duração fixa (Time-Boxes), Artefatos e Regras.Como criar, estimar, priorizar e manter o Product Backlog Planejamento Planejamento Reunião Revisão diária Retrospectiva da Release da Sprint da Sprint da Sprint O foco 24 horas desse workshop Product Sprint Backlog Backlog Produto Sprint (2-4 Semanas) Visão Legenda: Reuniões Artefatos Eventos (Reuniões) Papéis Artefatos  Planejamento da Release • Product Owner (PO)  Planejamento da Sprint • Product Backlog • ScrumMaster (SM)  Diária • Sprint Backlog • Equipe (time)  Revisão da Sprint • Sprint Burndown  Retrospectiva da Sprint • Release Burndown Sprint Burndown Release Burndown Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 47
  • 48. Introdução, a Reunião de Planejamento da Release: Na reunião de Planejamento da Release o Product Backlog é estimado e priorizado. A equipe é responsável por estimar os itens do Product Backlog, mais isto foi apresentado na aula anterior. Nessa aula vamos apresentar como priorizar os itens do Product Backlog , essa tarefa é de responsabilidade do PO.Como criar, estimar, priorizar e manter o Product Backlog Planejamento Planejamento Reunião Revisão diária Retrospectiva da Release da Sprint da Sprint da Sprint 24 horas Produto Sprint Backlog Backlog Produto Sprint 2-4 Semanas Visão Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 48
  • 49. Versão inicial do Product Backlog: Após a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog, note que ele não foi estimado nem priorizado.Como criar, estimar, priorizar e manter o Product Backlog agrupamento Funcionalidades do produto O Product Backlog, inicialmente é uma lista que representa tudo que é necessário para desenvolver e lançar um produto. A lista deve conter todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para futuras releases . O Product Backlog é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 49
  • 50. {Review} Reunião de Planejamento da Release: A estimativa e a priorização devem ser feitas na Reunião de Planejamento da Release. O propósito do planejamento da release é o de estabelecer um plano e metas que a Equipe Scrum e o resto da organização possam entender e comunicar.Como criar, estimar, priorizar e manter o Product Backlog O planejamento da release responde às questões: - Como podemos transformar a visão em um produto da melhor maneira possível? - Como podemos alcançar ou exceder a satisfação do cliente ? - Como podemos alcançar o ROI (retorno sobre investimento) ? O Plano da Release estabelece a meta da release, as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na release. Ele estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar. A organização pode então inspecionar o progresso e fazer mudanças nesse plano da release a cada Sprint. Contudo, O planejamento da release é inteiramente opcional. Se uma Equipe Scrum iniciar o trabalho sem essa reunião, a ausência de seus artefatos aparecerá como um impedimento que deverá ser resolvido. O trabalho para resolver o impedimento se tornará um item no Product Backlog. Ao se utilizar Scrum, os produtos são construídos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vão adicionando incrementos ao produto. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 50
  • 51. {Review} Reunião de Planejamento da Release: A estimativa e a priorização devem ser feitas na Reunião de Planejamento da Release. Cada incremento é um pedaço potencialmente entregável do produto completo. Quando já tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto éComo criar, estimar, priorizar e manter o Product Backlog entregue Muitas organizações já tem um processo de Planejamento de Release, e na maior parte desses processos o planejamento é feito no início do trabalho da release e não é modificado com o passar do tempo. No Planejamento de Release do Scrum, são definidos uma meta geral e resultados prováveis. Esse planejamento geralmente não requer mais do que 15-20% do tempo que uma organização costumava utilizar para produzir um plano de release tradicional. No entanto, uma release com Scrum realiza planejamento no momento da execução de cada reunião de Revisão de Sprint e de Planejamento de Sprint, da mesma forma que realiza um planejamento diário no momento da execução de cada Reunião Diária. De forma geral, os esforços para uma release com Scrum provavelmente consomem ligeiramente mais esforço do que os esforços para um planejamento de release tradicional. O planejamento da release requer estimar e priorizar o Product Backlog para a release. Existem diversas técnicas para fazê-lo, mas o SCRUM é um framework, não indica nenhuma técnica. Contudo, nessa aula abordaremos algumas técnicas para priorizar o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 51
  • 52. Visão Geral da Reunião de Planejamento da Release: Entradas Saídas ReleaseComo criar, estimar, priorizar e manter o Product Backlog Burndown (artefato) Visão do Produto Reunião de Planejamento da Release Product Backlog (visão inicial) Product Backlog (priorizado e estimado) Os participantes: Equipe SCRUM Plano de Release Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 52
  • 53. Reunião de Planejamento da Release: Priorizando Visão inicial do Product Backlog, antes da reunião de Planejamento da 1 Release, ele tem somente as funcionalidades do produto, agrupadas por tema (este agrupamento é opcional). Uma das atividades da reunião de Planejamento da Release é definir o Plano de Release, nesse plano estabelece-se o prazo de entregaComo criar, estimar, priorizar e manter o Product Backlog (estimado) do produto e nível de prioridade dos itens do Product Backlog. A equipe é responsável por fazer a estimativa dos itens 2 do Product Backlog. Após a estimava dos itens do Product Backlog é necessário definir 3 os níveis de prioridades dos itens Product Backlog. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 53
  • 54. Reunião de Planejamento da Release: Plano de Release {Review} O Plano da Release estabelece a meta da release, as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na release. Ele estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar.Como criar, estimar, priorizar e manter o Product Backlog A organização pode então inspecionar o progresso e fazer mudanças nesse plano da release a cada Sprint, se necessário. Plano de Release Relacionamento Programa de Sprints# Reserva Promoções Tour Virtual 5 Sprints ao cliente Fidelidade Nível de ? ? ? ? ? Prioridade 30 dias 15 dias 7 dias 15 dias 15 dias 82 dias Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 54
  • 55. Product Backlog sem priorização Questões chaves: 1 - Qual item retorna maior valor ao negócio ? 2 - Quais itens devemos entregar primeiro ? 3 - Como priorizar os itens ?Como criar, estimar, priorizar e manter o Product Backlog ? ? ? ? ? Objetivo da priorização em métodos ágeis: Entregar os itens de maior valor ao cliente ao menor custo (entregar primeiro os requisitos de maior valor fazem que eles custem menos do que os itens que serão entregues mais tarde). Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 55
  • 56. Priorização do Product Backlog: As melhores práticas recomendam que a priorização do Product Backlog deve ser por tema (ou por categoria), já que a priorizar por estória, nem sempre é possível, pois, poderá existir grau de dependências entre estórias do usuário. Fatores de Priorização: - ValorComo criar, estimar, priorizar e manter o Product Backlog - Custo - Risco Priorização Baseada em Valor, Custo e Risco: Existem diversas técnicas 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 maior fração do valor total do produto ao menor fração do custo total. Em essência, estamos tentando identificar item (ou funcionalidade) que irá maximizar o valor do produto, dentro das limitações de custo existentes. Principais Técnicas: - Kano: Composta por entrevistas com os usuários e opiniões de especialistas. - Theme Screening: Composta por opiniões de especialistas baseadas em comparação realizadas com um tema importante. -Theme Scoring: Baseado em comparações realizadas em um “tem”’ de referência - Outras: . Opinião de Especialista . Técnicas financeiras Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 56
  • 57. Técnicas que ajudam na priorização do Product Backlog: Modelo Kano: É um modelo desenvolvido por Noriaki Kano que é usado para compreender as preferências dos clientes (ou usuários).Como criar, estimar, priorizar e manter o Product Backlog O modelo Kano tem 3 tipos de funcionalidades: - Desejadas: São aquelas funcionalidades que o usuário deseja, mas não tem plena certeza - Linear: Quantas mais destas tiver melhor - Mandatório: 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 máximo 20 clientes ou usuários com perfis diferentes; - Realizar uma pergunta funcional: Se na próxima release incluir a emissão da Ordem de Serviço (OS), como você se sentira? [ X ] Eu vou gostar [ ] Eu acho que deveria incluir [ ] Indiferente [ ] Posso tolerar [ ] Eu não gostaria disto - Fazer uma pergunta disfuncional: Se na próxima release NÃO incluir a emissão da Ordem de Serviço (OS), como você se sentira? [ ] Eu vou gostar [ X ] Eu acho que deveria incluir [ ] Indiferente [ ] Posso tolerar [ ] Eu não gostaria disto Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 57
  • 58. Técnicas que ajudam na priorização do Product Backlog: Modelo Kano: Categorizando as respostas:Como criar, estimar, priorizar e manter o Product Backlog Agregando resultados: O que incluir na Sprint ? - Todas as funcionalidades Mandatórias - Algumas funcionalidades Lineares - Mas deixe um espaço para as funcionalidades desejadas Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 58
  • 59. Técnicas que ajudam na priorização do Product Backlog: Theme Screening Theme Screening é uma técnica poderosa e fácil de priorização que pode ser usada para priorizar os temas e/ou épicos. Também pode ser usado para priorizar projetos ou produtos. Passos:Como criar, estimar, priorizar e manter o Product Backlog 1 - identificar os fatores que são significantes (importantes) na priorização dos temas (ou dos épicos). 2 - Selecione um tema como "baseline" (que será utilizado como referência) 3 – Defina a tabela de pesos: + - Melhor que a referência 0 - Igual a referência - - Pior que referência 4 – Faça a avaliação (comparação): Fazer avaliação/comparação: do Critério x Tema x Tema de Referência. Perguntar: Qual é grau de importância do critério em relação ao Tema ? 5 – Faça a classificação baseado no score (quando maior for o score maior será o nível de prioridade) Temas Baseline Critério de Seleção Reserva Progr de Fidelidade Promoções Rel com Clientes Tour Virtual Reserva para próximo verão + + 0 - - Promoções para baixa temporada + - 0 0 - 0 0 0 Score 2 0 0 -1 -2 Classificação 1 2 3 4 5 Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 59
  • 60. Técnicas que ajudam na priorização do Product Backlog: Theme Scoring É uma técnica de priorização que pode ser usada para priorizar os temas (grupos de estórias do usuário) e/ou épicos (estórias do usuário grandes). Também pode ser usado para priorizar projetos ou produtos. Passos:Como criar, estimar, priorizar e manter o Product Backlog 1 - identificar os fatores que são significantes (importantes) na priorização dos temas (ou dos épicos). 2 – Defina o peso para cada critério 3 - Selecione um tema como "baseline" (que será utilizado como referência) 4 – Defina a tabela de pesos: 5 – Muito Melhor que a referência 4 – Melhor que a referência 3 – Igual a referência 2 - Pior que a referência 1 - Muito pior que a referência 5 – Faça a avaliação: Fazer avaliação de cada tema em relação ao candidato tema de referência. 6 – Faça a classificação baseado no score (quando maior for o score maior será o nível de prioridade) Reserva (referência) Progr de Fidelidade Promoções Rel com Clientes Tour Virtual Critério de Seleção Peso Pontos Score Pontos Score Pontos Score Pontos Score Pontos Score Reserva para próximo verão 5 3 15 2 10 1 5 2 10 1 5 Promoções para baixa temporada 2 3 6 1 2 3 6 2 4 1 2 Score 21 12 11 14 7 Classificação 1 3 4 2 5 Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 60
  • 61. Técnicas que ajudam na priorização do Product Backlog: Outras técnicas Opinião de Especialista: Um especialista ajuda na definição do nível de prioridade dos itens do Product Backlog..Como criar, estimar, priorizar e manter o Product Backlog Foco: Dever ser na “entrega de valor para cliente”. Considerar 4 fatores: - Entrega novas capacidades - Desenvolvimento novos conhecimentos - Mitigação do Risco - Mudanças no custo relativo Técnicas Financeiras Utilização de técnicas financeira para ajudar na priorização dos itens do Product Backlog. TIR - Taxa interna de retorno ROI – Taxa de Retorno sobre investimento Payback Valor Presente Liquido (VPL) Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 61
  • 62. Reunião de Planejamento da Release: PB estimado 1 2Como criar, estimar, priorizar e manter o Product Backlog Product Backlog estimado e priorizado Alta Médio Versão inicial do Product Backlog, sem estimativa e nem priorização. Médio Baixo Baixo Plano de Release 3 Plano de Release, como status de “Pronto” Relacionamento Programa de Sprints# Reserva Promoções Tour Virtual 5 Sprints ao cliente Fidelidade Nível de Alto Médio Médio Baixo Baixo Prioridade Prazo 30 dias 15 dias 7 dias 15 dias 15 dias 82 dias (estimado) Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 62
  • 63. Reunião de Planejamento da Release. Release Burndown: Com Product Backlog atualizado e o Plano de Release, o PO poderá construir o Release Burndown, que é um dos artefatos do SCRUM. O Release Burndown registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a organização tenham decidido usar. As unidades de tempo geralmente são Sprints.Como criar, estimar, priorizar e manter o Product Backlog Release Burndown 120 O Product Owner é responsável por manter o Product Backlog e o Release Burndown atualizados 108 e publicados todo o tempo. Uma linha de tendência pode ser 80 traçada baseada na mudança do Pontos (estimados) trabalho restante. 68 40 48 40 20 0 Release #1 Release #2 Release #3 Release #4 Release #5 Releases Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 63
  • 64. Como criar, estimar, priorizar e manter o Product Backlog Reunião de Planejamento da Release. Check List final Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 64
  • 65. Conteúdo do Workshop: 1 2 3 4Como criar, estimar, priorizar e manter o Product Backlog Criar Estimar Priorizar Manter 1 – Como Criar o Product Backlog 2 – Como Estimar o Product Backlog 3 – Como Priorizar o Product Backlog 4 – Como Manter o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 65
  • 66. Como criar, estimar, priorizar e manter o Product Backlog Objetivo: Objetivo dessa parte: Apresentar e discutir como “Manter” o Product Backlog. Pré-requisito: Conhecimento do Scrum. Se você não conhece o Scrum recomendamos fazer o Workshop SCRUM (http://etecnologia.ning.com/group/scrum) primeiro e depois esse treinamento. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 66
  • 67. Como criar, estimar, priorizar e manter o Product Backlog Parte 4: Como Manter o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 67
  • 68. Framework SCRUM: O Framework Scrum é composto por uma Equipe (Time) Scrum e seus papéis: Product Owner (PO), Scrum Master (SM) e Equipe de desenvolvedores, Eventos com duração fixa (Time-Boxes), Artefatos e Regras.Como criar, estimar, priorizar e manter o Product Backlog Planejamento Planejamento Reunião Revisão diária Retrospectiva da Release da Sprint da Sprint da Sprint O foco 24 horas desse workshop Product Sprint Backlog Backlog Produto Sprint (2-4 Semanas) Visão Legenda: Reuniões Artefatos Eventos (Reuniões) Papéis Artefatos  Planejamento da Release • Product Owner (PO)  Planejamento da Sprint • Product Backlog • ScrumMaster (SM)  Diária • Sprint Backlog • Equipe (time)  Revisão da Sprint • Sprint Burndown  Retrospectiva da Sprint • Release Burndown Sprint Burndown Release Burndown Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 68
  • 69. Review: Product Backlog: Visão do Product Backlog:Como criar, estimar, priorizar e manter o Product Backlog Alta Médio Médio Baixo Baixo O Product Backlog é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita. O Product Backlog, inicialmente é uma lista que representa tudo que é necessário para desenvolver e lançar um produto. A lista deve conter todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para futuras releases . Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 69
  • 70. Quem é Responsável por Manter o Product Backlog ? O Product Owner (PO) é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pela Equipe. O PO mantém o Product Backlog (PB) e assegura que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar. O Product Owner deve ser uma pessoa, e não um comitê. Podem existir comitês que aconselhem ou influenciem , mas somente o PO poderá mudar a prioridade de um item do PB. Empresas queComo criar, estimar, priorizar e manter o Product Backlog adotam Scrum podem perceber que isso influencia seus métodos para definir prioridades e requisitos ao longo do tempo. Para que o PO obtenha sucesso, todos na organização precisam respeitar suas decisões. Somente o PO pode definir a prioridade dos itens que a equipe irá trabalhar. As decisões do Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa visibilidade requer que o Product Owner faça 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. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 70
  • 71. Manter o Produto “Backlog” atualizado: O Product Backlog poderá sofrer atualizações no decorrer de uma reunião de Planejamento de uma Sprint. Exemplo: Quando uma estória do usuário é considerada “épico”, ele será dividida em outras estórias e isto deverá ser refletido no Product Backlog.Como criar, estimar, priorizar e manter o Product Backlog Planejamento Planejamento Reunião Revisão diária Retrospectiva da Release da Sprint da Sprint da Sprint 24 horas Produto Sprint Backlog Backlog Produto Sprint 2-4 Semanas Visão Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 71
  • 72. Manter o Produto “Backlog” atualizado: Na Reunião de Revisão da Sprint o Product Backlog poderá sofrer alterações. Exemplo: Uma Sprint onde não foi atingido a meta ou o que foi entrega não estava em conformidade coma definição de pronto, neste as estórias de usuário da Sprint devem voltar ao Product Backlog.Como criar, estimar, priorizar e manter o Product Backlog Planejamento Planejamento Reunião Revisão diária Retrospectiva da Release da Sprint da Sprint da Sprint 24 horas Produto Sprint Backlog Backlog Produto Sprint 2-4 Semanas Visão Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 72
  • 73. Manter o Produto “Backlog” atualizado: O Product Backlog também poderá ser alterado quando o cliente solicita novas funcionalidades e quando deseja retirar alguma funcionalidade do Product Backlog.Como criar, estimar, priorizar e manter o Product Backlog Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 73
  • 74. Quer mais ? Os membros da comunidade podem participar dos eventos, treinamentos e cursos gratuitos. Comunidade: http://etecnologia.ning.com/Como criar, estimar, priorizar e manter o Product Backlog Para participar da comunidade basta se cadastrar: http://bit.ly/czZlez A missão da comunidade é compartilhar conhecimento, trocar experiências e prover aprendizado. Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 74
  • 75. Como criar, estimar, priorizar e manter o Product Backlog Licença: Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 75
  • 76. Notas: Marcas Registradas: Todos os termos mencionados que são reconhecidos como Marca Registrada e/ou comercial são de responsabilidades de seus proprietários. O autor informa não estar associada a nenhum produto e/ouComo criar, estimar, priorizar e manter o Product Backlog fornecedor 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 fins educativo, não visando ao lucro, favorecimento ou desmerecimento da marca ou produto. Melhoria e Revisão: Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie um e-mail nós. Criticas e Sugestões: Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-mail para nós. Imagens: Google, Flickr e Banco de Imagem. Rildo F dos Santos (rildo.santos@etecnologia.com.br) Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 76
  • 77. Comocriar,Como criar, estimar, priorizar e manter o Product Backlogestimar,priorizar emanter oProductBacklog www.etcnologia.com.br Rildo F Santos rildo.santos@etecnologia.com.br twitter: @rildosan (11) 9123-5358 skype: rildo.f.santos (11) 9962-4260 http://rildosan.blogspot.com/ Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com