Papel do PO Métodos Ágeis. Fonte: Adaptworks

Transcrição

1 Papel do PO Métodos Ágeis Fonte: Adaptworks

2 Scrum - Visão Geral

3 Manifesto Ágil Indivíduos e interação entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano

4 Scrum Método ágil para gerenciamento de projetos; Times Pequenos e auto organizados;

5 Scrum Framework Diagram

6 Papel do PO

7 Papel do Product Owner Lidera o esforço de desenvolvimento para criar um produto que gere os benefícios desejados; Inclui: criar a visão de produto; definir product backlog, planejar releases; envolver stakeholders; gerenciar budget, preparar lançamento do produto; participar das reuniões do Scrum; e colaborar com o time.

8 Responsabilidades do PO Ser a voz do cliente; Definir as funcionalidades chave do produto; Descrever, priorizar e refinar requisitos continuamente; Ser responsável pelo sucesso do produto e pelo ROI; Definir plano de Release com datas; Definir de forma pró-ativa stakeholders e chickens;

9 Responsabilidades do PO Definir Metas; Dar direcionamento ao Trabalho; Comunicação frequente com o Dev Team; Participar das reuniões do Scrum; Gerenciar o Budget; Aceitar ou rejeitar entregas (resultados); Definir a visão do Produto; A agenda de um Product Owner;

10 Problemas Comuns PO sem poder de decisão; PO com baixa disponibilidade; PO distante; PO proxy; PO da sua parte.

11 Visão do Produto

12 Visão do Produto PO é o responsável pela criação da visão; PO compartilha e refina a visão com o time; Coleta informações junto a clientes, usuários final, time, stakeholders, executivos, etc.;

13 Visão do Produto Definição e objetivos do produto; Funcionalidades chave do produto; Benefícios para o cliente; Atributos de performance e qualidade; Arquitetura do produto; Dificuldades e riscos; Principais marcos do projeto.

14 Product Backlog

15 Product Backlog Derivado de um Plano de Negócios ou Visão de Produto PO é o responsável por sua criação e priorização, mas todos podem contribuir. Lista de funcionalidades, necessidades,... Pode ser descrito em: user stories, use cases, features,...

16 Product Backlog Product Backlog nunca está completo e dessa forma está em constante evolução;

17 Product Backlog Requisitos Ready se transformam em Funcionalidades Done

18 Condições de Satisfação

19 Priorização do Backlog

20 Priorização do Product Backlog A priorização deve ser por tema (categoria), já que a priorizar por estória, nem sempre é possível, pois, poderá existir grau de dependências entre estórias.

21 Planejamento de Release

22 Release Representa a entrega de conjunto de itens de grande valor para o usuário em produção; É composto pela quantidade de sprints necessários para formar esse conjunto de itens que definirão a entrega de grande valor; O MVP é o Release.

23 Planejamento de Release

24 User Stories

25 User Stories

26

27 User Stories Descrição de uma necessidade para um público específico com um valor de negócio; Identificar/conhecer público e definir personas ; PO pode escrever sozinho ou promover storywriting workshop;

28 Perfil Benefícios Funcionalidades

29 Teste de Aceitação PO, com a colaboração de quem achar necessário, é quem descreve os testes de aceitação e deve fazê-lo antes da codificação; Testes devem fazer parte do processo e devem ser automatizados sempre que possível.

30 Sprint Planning Meeting

31 Sprint Planning Meeting #1 Consiste em duas partes; Parte 1: Decisão do que será feito no Sprint; PO apresenta para o time os itens do Backlog priorizados e define a meta do Sprint; Resulta no Sprint Backlog: Itens de Backlog selecionados, suas respectivas tarefas e Meta do Sprint.

32 Sprint Planning Meeting #1 O PO deve falar ao time sobre a visão do produto; O PO e o time devem definir a meta do Sprint; O time deve realizar a estimativa dos itens do backlog que não estejam estimados; O PO e o Time, em consenso, escolhem os itens que irão fazer parte do próximo Sprint.

33 Sprint Planning Meeting #2 Parte 2: Decisão de como serão construídas as funcionalidades em um incremento de produto durante o Sprint; As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. PO está presente nessa parte para esclarecer dúvidas e ajudar a efetuar mudanças; Outras pessoas podem ser convidadas para fornecer um conselho técnico ou específico.

34 Sprint

35 Sprint Na execução do Sprint valem as práticas de engenharia definidas para o Projeto; ScrumMaster facilita o trabalho do time removendo impedimentos e garante a boa aplicação do Scrum; Time pode consultar especialistas ou mesmo o Product Owner; Duração de 2 a 4 semanas.

36 Terminar Sprint antes do Final Um sprint pode ser terminado antes da sua finalização nas seguintes situações: O time sente que não conseguirá atingir a meta; O PO percebe que mudanças em fatores externos influenciarão diretamente no valor da meta do Sprint. Caso um sprint seja cancelado deve se iniciar imediatamente o planejamento do próximo.

37 Daily Meeting

38 Daily Meeting Reunião de 15 minutos; Daily é uma reunião do DEV TIME; Cada membro deve responder: o O que fiz desde a última reunião? o O que pretendo fazer até a próxima? o Tive algum impedimento? Time ganha visibilidade; ScrumMaster é o facilitador; PO não participa.

39 Sprint Review

40 Sprint Review Ocorre no final de cada Sprint; Meta do Sprint é um compromisso do TIME; TIME demonstra o trabalho que foi feito e responde a questionamentos; TIME deve apresentar software funcionando; TIME discute o que correu bem, quais problemas foram enfrentados e como foram resolvidos; Sprint Review fornece input de valor para as Sprint Planning Meetings seguintes.

41 Sprint Review PO deve aceitar somente produtos que satisfaçam a definição de PRONTO (DONE) e que atendam aos critérios de aceite, caso estes tenham sido definidos; PO não deve aguardar até o fim do sprint para ter seu primeiro contato com as funcionalidades, faça isso de forma just-in-time.

42 Retrospective

43 Retrospective Representa o espírito de inspeção-adaptação; ScrumMaster encoraja o time a revisar processo de trabalho, tendo como base as práticas do Scrum. PO participa somente quando convidado; Finalidade é inspecionar o último Sprint em se tratando de composição do time, preparativos para reuniões, DOD, ferramentas, comunicação e processos para identificação de melhorias a serem aplicadas no próximo sprint.

44 PO e Scrum

45 Resumo Responsabilidades PO ScrumMaster Time É responsável pelo Product Backlog e por garantir o valor do trabalho realizado pelo Time. - Visão do Produto - Product Backlog - Plano de Release - Release Burndown - Sprint Planning #1 É responsável por garantir que o processo seja compreendido e seguido. - Remover Impedimentos - Proteger o Time - Ajudar o PO - Ser o facilitador do Time É responsável por transformar os itens do Product Backlog em produto. - Fazer estimativa - Definir as tarefas - Garantir a qualidade do produto - Apresentar o produto ao cliente - Sprint Planning#1 e #2, Daily, Review, Retrospectiva

46 Referências: