Como criar, priorizar e manter o Product Backlog

Transcrição

2 Objetivo: Objetivo do Workshop: Compartilhar conhecimento, trocar experiência e prover aprendizado de Como criar, priorizar e manter o Product Backlog utilizando as melhores práticas, técnicas e ferramentas. Objetivo dessa aula #2: 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 ( primeiro e depois esse treinamento. Todos os direitos reservados e protegidos 2006 e

3 Conteúdo do Workshop: 1 Criar 2 Estimar 3 Priorizar 4 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 5 Exercícios e Estudo de Caso Todos os direitos reservados e protegidos 2006 e

5 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. Planejamento da Release Planejamento da Sprint Reunião diária Revisão da Sprint Retrospectiva da Sprint O foco desse workshop Visão Product Backlog Sprint Backlog 24 horas Sprint (2-4 Semanas) Produto Legenda: Reuniões Artefatos Papéis Product Owner (PO) ScrumMaster (SM) Equipe (time) Eventos (Reuniões) Planejamento da Release Planejamento da Sprint Diária Revisão da Sprint Retrospectiva da Sprint Artefatos Product Backlog Sprint Backlog Sprint Burndown Release Burndown Sprint Burndown Release Burndown Todos os direitos reservados e protegidos 2006 e

6 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. Planejamento da Release Planejamento da Sprint Reunião diária Revisão da Sprint Retrospectiva da Sprint 24 horas Visão Produto Backlog Sprint Backlog Sprint 2-4 Semanas Produto Todos os direitos reservados e protegidos 2006 e

7 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. 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. Todos os direitos reservados e protegidos 2006 e

8 {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. 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. Todos os direitos reservados e protegidos 2006 e

9 {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 é 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 Todos os direitos reservados e protegidos 2006 e

10 Visão Geral da Reunião de Planejamento da Release: Entradas Saídas Release 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 Todos os direitos reservados e protegidos 2006 e

11 Reunião de Planejamento da Release: Priorizando 1 Visão inicial do Product Backlog, antes da reunião de Planejamento da 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 entrega (estimado) do produto e nível de prioridade dos itens do Product Backlog. 2 A equipe é responsável por fazer a estimativa dos itens do Product Backlog. 3 Após a estimava dos itens do Product Backlog é necessário definir os níveis de prioridades dos itens Product Backlog. Todos os direitos reservados e protegidos 2006 e

12 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. 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 Sprints# Reserva Promoções Relacionamento ao cliente Programa de Fidelidade Tour Virtual 5 Sprints Nível de Prioridade????? 30 dias 15 dias 7 dias 15 dias 15 dias 82 dias Todos os direitos reservados e protegidos 2006 e

13 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?????? 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). Todos os direitos reservados e protegidos 2006 e

14 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: - Valor - 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 Todos os direitos reservados e protegidos 2006 e

15 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). 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 Todos os direitos reservados e protegidos 2006 e

16 Técnicas que ajudam na priorização do Product Backlog: Modelo Kano: Categorizando as respostas: Agregando resultados: O que incluir na Sprint? - Todas as funcionalidades Mandatórias - Algumas funcionalidades Lineares - Mas deixe um espaço para as funcionalidades desejadas Todos os direitos reservados e protegidos 2006 e

17 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: 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 Promoções para baixa temporada Score Classificação Todos os direitos reservados e protegidos 2006 e

18 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: 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 Promoções para baixa temporada Score Classificação Todos os direitos reservados e protegidos 2006 e

19 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.. 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) Todos os direitos reservados e protegidos 2006 e

20 Reunião de Planejamento da Release: PB estimado 1 Product Backlog estimado e priorizado 2 Alta Versão inicial do Product Backlog, sem estimativa e nem priorização. Médio Médio Baixo Baixo Plano de Release 3 Plano de Release, como status de Pronto Sprints# Reserva Promoções Relacionamento ao cliente Programa de Fidelidade Tour Virtual 5 Sprints Nível de Prioridade Prazo (estimado) Alto Médio Médio Baixo Baixo 30 dias 15 dias 7 dias 15 dias 15 dias 82 dias Todos os direitos reservados e protegidos 2006 e

21 Reunião de Planejamento da Release. Release Burndown: Pontos (estimados) 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. Release Burndown O Product Owner é responsável por manter o Product Backlog e o Release Burndown atualizados e publicados todo o tempo. Uma linha de tendência pode ser traçada baseada na mudança do trabalho restante Release #1 Release #2 Release #3 Release #4 Release #5 Releases Todos os direitos reservados e protegidos 2006 e

24 Exercícios: Por que a priorização é importante no processo desenvolvimento de software? Quais são os artefato que resultam da Reunião de Planejamento da Release? Todos os direitos reservados e protegidos 2006 e

26 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/ou 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 para 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 para nós. Imagens: Google, Flickr e Banco de Imagem. Rildo F dos Santos () Todos os direitos reservados e protegidos 2006 e