Gesto gil de Produtos Clique para editar o




















































































































- Slides: 116
Gestão Ágil de Produtos Clique para editar o título mestre SMEs – Subject Matter Experts 1 André Vidal Gino Terentim vidal@agilethink. com. br gino@ginoterentim. com Lean Canvas, Canvas de Produto, 7 dimensões de produto e Story Mapping foram desenvolvidos por: © 2017 – AGILE THINK®. Todos os direitos reservados
Sumário 2 3 2 • Lean Canvas • Visão do Produto • User Story Mapping • Requisitos Ágeis • User Stories • 7 Dimensões do Produto
REQUISITOS ÁGEIS “Nada é permanente nesse mundo cruel. Nem mesmo os nossos problemas. ” Charles Chaplin 3
Gestão Ágil de Produtos – Bloco 3 3. 1 Requisitos Ágeis 4 • Para quebramos Requisitos em User Stories? • Mapeamento de User Stories • INVEST
3. 1 Requisitos Ágeis 3. 1. 1 5 Para quebramos Requisitos em User Stories?
Para quebramos Requisitos em User Stories? Como Administrador, Preciso manter o Cadastro de Clientes Como r, o d a r t s i Admin vo o n m ir u u l c n i e o Consig o Cadastro d n e t n e i l C s Cliente 6 Como Admin i strado r, Consig o Client excluir um e no C adast novo Client ro de es
Para quebramos Requisitos em User Stories? Como Administrador, Preciso manter o Cadastro e de Clientes d l i c á s f i a m a Fic r! e d n e e Como compr Admin r, o d a r t s istrad i n i m d or, A Consig Como o excl vo C o n uir um m u l i r e i n u l t c e novo no Ca e C o in d g i s o r n t o s d liente C astro da a C o s n de e t n e i l C s Cliente 7
Para quebramos Requisitos em User Stories? Como Administrador, Histór Preciso manter o Cadastro ias me nores fornec de de Clientes l i c á f s i e a m m F a e edbac Fic ! r e d m n k e a e i r s C p r o á m mo Ad pido! co , r o m d inistra s i n i m dor, Ad o m C o onsigo C o v exclui o n m C u l r um n i r e i n u l t c e n i n e C o o liente o Cadastro vo Consig o Cadastro d s n de e t n e i l C s Cliente 8
Para quebramos Requisitos em User Stories? Como Administrador, Histór Preciso manter o Cadastro ias me nores fornec de de Clientes l i c á f s i e a m m F a e edbac Fic ! r e d m n k e a e i r s C p r o á m mo Ad pido! co , r o m d inistra s i n i m dor, Ad o m C o onsigo C o v exclui o n m C u l r um n i r e i n u l t c e n i n e C o o liente o Cadastro vo Consig o Cadastro d s n de e t n e i l C s Cliente Pequenas histórias aumentam o progresso! 9
3. 1 Requisitos Ágeis 3. 1. 2 10 Mapeamento de User Stories
Mapeamento de User Stories § A documentação ágil é um processo colaborativo, iterativo e pragmático, que tem os seguintes objetivos: o Definir User Stories o Obter conhecimento sobre o processo de negócio o Gerar alinhamento para aquilo que será feito 11
Mapeamento de User Stories 12
Mapeamento de User Stories 13
Mapeamento de User Stories 14
Mapeamento de User Stories 15
Mapeamento de User Stories 16
Mapeamento de User Stories 17
Mapeamento de User Stories CARTÃO § Escrita em cartões de papel § Pode conter estimativas, notas, referências diversas § Escrita numa linguagem direta e simplificada 18
Mapeamento de User Stories 19 CONVERSAÇÃO § Detalhes são escritos no verso do cartão, para não se perder nenhuma informação relevante § Originada a partir das informações discutidas entre o Product Owner com o Time e o Cliente
Mapeamento de User Stories CONFIRMAÇÃO § Definição dos critérios de aceitação do cliente § Confirmação do atendimento às necessidades durante sessões de refinamento 20
3. 1 Requisitos Ágeis 3. 1. 3 21 INVEST
INVEST INDEPENDENTE (I) § Toda história pode ser executada independentemente de outra história 22
INVEST NEGOCIÁVEL (N) § Toda história pode ser negociada no momento da sua viabilidade em separado, por ter um grau de importância dentro do Backlog do Produto. 23
INVEST VÁLIDA (V) § Toda história deve ter um valor visível ao usuário § Caso contrário o mesmo não tem utilidade e pode ser descartado. 24
INVEST ESTIMÁVEL (E) § Toda história deve ter a estimativa de esforço da equipe. § Caso a estimativa seja muito grande o Product Owner necessita analisar e desmembrar a história. 25
INVEST PEQUENA (S – SMALL) § Toda história deve ser clara e de fácil negociação, estimativa, entendimento e teste. 26
INVEST TESTÁVEL (T) § Toda história deve ser testada antes de passar para a fase de construção 27
Gestão Ágil de Produtos – Bloco 3 3. 2 User Stories 28 • Escrevendo User Stories Eficazes • 10 Maneiras de quebrar User Stories
3. 2 User Stories 3. 2. 1 29 Escrevendo User Stories Eficazes
Escrevendo User Stories Eficazes OBJETIVO: § User Story é essencial para o diálogo entre o PO, clientes e time. User Stories devem descrever: o Funcionalidade o Critérios de Aceite o Referências do Produto o Informações Complementares 30
Escrevendo User Stories Eficazes Mas como escrever User Stories eficazes? 31
Escrevendo User Stories Eficazes § Descrever funcionalidades de forma clara e curta § Elaborada durante reuniões colaborativas entre Product Owner, cliente e time § Geralmente aplicada em sessões de brainstorming e prototipação 32
Escrevendo User Stories Eficazes FUNCIONALIDADE CRITÉRIOS DE ACEITE REFERÊNCIAS DO PRODUTO 33
Escrevendo User Stories Eficazes FUNCIONALIDADE § Toda história deve ser simples e de fácil compreensão, escrita numa linguagem acessível ao cliente ao time 34
Escrevendo User Stories Eficazes CRITÉRIO DE ACEITE § Toda história deve ser testada antes de passar para a fase de construção § Os cenários devem estar claros 35
Escrevendo User Stories Eficazes REFERÊNCIAS DO PRODUTO § Toda história deve ser: o Negociada o Estimada o Validada 36
Escrevendo User Stories Eficazes INFOMAÇÕES COMPLEMENTARES § Wireframe ou Protótipo § Regras de Negócio § Fluxogramas § Enable Features (Spikes) 37
3. 2 User Stories 3. 2. 2 38 10 Maneiras de quebrar User Stories
10 Maneiras de Quebrar User Stories TIPOS DE USER STORIES QUE DEVEM SER FRAGMENTADAS § Múltiplos Passos § Workflow § Maior e Menor Esforço § Diminuir a Complexidade § Definição de Filtros § Tamanho x Esforço § Requisitos Não-Funcionais § CRUD (Create, Retrive, Update, Delete) § Caso de Uso § Prova de Conceito (POC) 39
Múltiplos Passos MÚLTIPLOS PASSOS § É uma história que POSSUI um conjunto de passos a serem realizados para que a mesma seja concluída.
Múltiplos Passos COMO IDENTIFICAR? § A história só é realizada se todos os passos incluídos na história forem realizados. § A história de múltiplos passos deve ser quebrada nos vários passos.
Múltiplos Passos PERGUNTAS ÚTEIS § Todos esses passos são realmente necessários? § A sequência de passos é dependente da história principal?
Múltiplos Passos COMO FICA?
Múltiplos Passos COMO FICA?
Workflow WORKFLOW § A história DEPENDE que um conjunto de regras sejam realizadas para que a mesma seja concluída.
Workflow COMO IDENTIFICAR? § O objetivo da história só acontece se todas as demais histórias forem realizadas. § Uma história de workflow pode ser quebrada em outros pequenos fluxos de trabalho.
Workflow PERGUNTAS ÚTEIS § Quantos passos são necessários para a realização da história? § É preciso realizar todas as operações para se chegar ao objetivo da história original?
Workflow COMO FICA?
Workflow COMO FICA?
Workflow COMO FICA?
Maior e Menor Esforço MAIOR E MENOR ESFORÇO § Possui diferentes níveis de esforço § Pode exigir grande esforço para realizar uma história e um menor nível para as subsequentes.
Maior e Menor Esforço COMO IDENTIFICAR? § O objetivo da história demanda um grande esforço para a ação. § Essa ação pode ser quebrada em duas ou mais, diminuindo o esforço total. § Esse tipo de história é facilmente percebida pelos times, pois eles entendem que o maior esforço deve ser feito primeiro.
Maior e Menor Esforço PERGUNTAS ÚTEIS § Preciso definir critérios de aceitação específicos para a história? § É preciso infraestrutura específica para garantir a entrega da história? § Qual a diferença de executarmos uma ou outra história primeiro?
Maior e Menor Esforço COMO FICA?
Maior e Menor Esforço COMO FICA?
Diminuir Complexidade DIMINUIR COMPLEXIDADE § São histórias que quando discutidas pela equipe, ao invés de reduzir, aumenta sua complexidade. § Nesses casos, a história deverá ser quebrada em versões mais simplificadas.
Diminuir Complexidade COMO IDENTIFICAR? § Possui diversas condições para ser realizada em sua totalidade. § Precisa ser quebrada em funcionalidades de complexidade menor.
Diminuir Complexidade PERGUNTAS ÚTEIS § Qual é a versão mais simples desta história? § Será necessário trabalhar com todas as histórias ao mesmo tempo para gerar o resultado esperado?
Diminuir Complexidade COMO FICA?
Diminuir Complexidade COMO FICA?
Diminuir Complexidade COMO FICA?
Definição de Filtros DEFINIÇÃO DE FILTROS § São histórias que ocorrem geralmente quando temos a necessidade de criar relatórios ou determinadas buscas com múltiplos filtros.
Definição de Filtros COMO IDENTIFICAR? § A história diz respeito à criação de um relatório e/ou consulta. § Possui diversas formas de gerar a mesma informação, o que precisa ser separado em histórias menores.
Definição de Filtros PERGUNTAS ÚTEIS § É possível exibir as informações com quais recursos para filtragem? Quais campos serão exibidos como resultado? § Quais as consultas deverão ser realizadas e quais os critérios que devem ser aplicados?
Definição de Filtros COMO FICA?
Definição de Filtros COMO FICA?
Definição de Filtros COMO FICA?
Tamanho x Esforço TAMANHO X ESFORÇO § São histórias que possuem uma pontuação alta durante a estimativa do time § Denotando que o tamanho da história pode estar inadequado para identificar o esforço.
Tamanho x Esforço COMO IDENTIFICAR? § O time durante a estimativa sente desconforto em estabelecer um tamanho para a história. § Nesse momento o Product Owner avalia se é possível fragmentar em outras histórias.
Tamanho x Esforço PERGUNTAS ÚTEIS § É possível quebra a história em duas ou mais? § Quais as possíveis histórias resultantes dessa quebra? São histórias ou tarefas?
Tamanho x Esforço COMO FICA?
Tamanho x Esforço COMO FICA?
Tamanho x Esforço COMO FICA?
Requisitos Não Funcionais REQUISITOS NÃO FUNCIONAIS § Divisão de uma história para lidar com as condições relacionadas às qualidades que funcionalidades específicas devem ter.
COMO IDENTIFICAR? § Geralmente essas histórias são relacionadas à especificidades requeridas pela funcionalidade. § Essa deve ser dividida em histórias de usuários adicionais para uma melhor gestão dos critérios de aceitação da história principal. Requisitos Não Funcionais
Requisitos Não Funcionais PERGUNTAS ÚTEIS § Qual é a versão mais simples que pode ser aceita? Segurança, Usabilidade, Log, Performance são importantes? § Quais tipos de dados são suportados? São feitas parametrizações? Quais parâmetros são relevantes?
Requisitos Não Funcionais COMO FICA?
Requisitos Não Funcionais COMO FICA?
CRUD (Create, Retrieve, Update, Delete) § Divisão de uma história em outras mais para lidar com as operações fundamentais de um cadastro, por exemplo.
CRUD (Create, Retrieve, Update, Delete) COMO IDENTIFICAR? § Geralmente essas histórias são referenciadas com o desejo do usuário de “Manter” algo. § Por exemplo, “manter” no contexto da história pode ser o desejo do usuário de “Inserir” alguma informação e, também poder “Consultar” o que foi inserido.
CRUD (Create, Retrieve, Update, Delete) PERGUNTAS ÚTEIS § Será preciso Inserir? § Será preciso Consultar? § É possível Excluir? Quais as condições para excluir? § É possível atualizar informações?
CRUD (Create, Retrieve, Update, Delete) COMO FICA?
CRUD (Create, Retrieve, Update, Delete) COMO FICA?
Caso de Uso CASO DE USO § Documento para descrição de requisitos. § Definido pela interação dos atores durante a execução dos cenários dos fluxos principal e alternativos
Caso de Uso DESCRIÇÃO FLUXO PRINCIPAL FLUXOS ALTERNATIVOS
Caso de Uso COMO FICA?
Caso de Uso COMO FICA?
Caso de Uso COMO FICA?
Prova de Conceito (POC) PROVA DE CONCEITO (POC) § Forma de diminuir o grau de incerteza sobre a construção de uma determinada funcionalidade. § São utilizadas para testar alternativas ao desenvolvimento.
Prova de Conceito (POC) COMO FICA?
Prova de Conceito (POC) COMO FICA?
10 Maneiras de Quebrar User Stories TIPOS DE USER STORIES QUE DEVEM SER FRAGMENTADAS § Múltiplos Passos § Workflow § Maior e Menor Esforço § Diminuir a Complexidade § Definição de Filtros § Tamanho x Esforço § Requisitos Não-Funcionais § CRUD (Create, Retrive, Update, Delete) § Caso de Uso § Prova de Conceito (POC) 92
Gestão Ágil de Produtos – Bloco 3 3. 3 7 Dimensões do Produto 93
7 Dimensões do Produto 94
7 Dimensões do Produto 95
7 Dimensões do Produto § Dinâmica voltada ao levantamento de requisitos de produto e criação de User Stories de forma visual e estruturada. 96
7 Dimensões do Produto 97
7 Dimensões do Produto § Entender o contexto de atores, interfaces e ações possíveis § Definir tipos de dados e regras de negócio § Estabelecer ambiente e requisitos nãofuncionais 98
7 Dimensões do Produto TEMA § Selecionar um tema ou épico a ser decomposto no Canvas 7 Dimensões do Produto 99
7 Dimensões do Produto TEMA Listar Produtos 100
7 Dimensões do Produto TEMA ATOR § Qual(is) ator(es) interagem com o produto? § Quem interage no sistema? § Quem são os usuários do produto? 101
7 Dimensões do Produto TEMA ATOR CLIENTE 102
7 Dimensões do Produto TEMA 103 INTERFACE § O que é necessário para a interação do ator? § É preciso uma tela? Ela envia dados? Recebe dados? § É preciso um serviço? É externo à aplicação?
7 Dimensões do Produto TEMA INTERFACE TELA LISTA DE PRODUTOS 104
7 Dimensões do Produto TEMA AÇÃO § O que é possível fazer via a interface? Quais eventos são executados? § Quais as ações previstas durante a utilização da tela ou serviço? § É possível Incluir, Consultar, Excluir. . . 105
7 Dimensões do Produto TEMA AÇÃO Carregar Produtos Selecionados 106 Clicar no produto para ver descrição
7 Dimensões do Produto TEMA INFORMAÇÃO § Quais as informação que podem ser manipuladas? § Qual o domínio da informação? § Quais as entidades? Quais os atributos? 107
7 Dimensões do Produto TEMA INFORMAÇÃO Dados do Produtos 108 Preço de Catálogo
7 Dimensões do Produto TEMA REGRAS DE NEGÓCIO § Existe alguma regra que deve ser observada? § Há alguma restrição que deve ser levada em consideração? § Existem leis a serem aplicadas? 109
7 Dimensões do Produto TEMA REGRAS DE NEGÓCIO Produto em Estoque 110 Quantidade do Produto Valor de Desconto
7 Dimensões do Produto TEMA 111 AMBIENTE § Qual a plataforma que o sistema irá funcionar? § Qual o local de trabalho? § Existem equipamentos ou gadgets especiais? Qual o sistema operacional?
7 Dimensões do Produto TEMA AMBIENTE Todos os browsers 112 Responsive Mobile
7 Dimensões do Produto TEMA REQUISITOS NÃO FUNCIONAIS § Existem requisitos não funcionais que impactam a funcionalidade? § Quais os parâmetros de comparação para validar a realização do requisito? 113
7 Dimensões do Produto TEMA REQUISITOS NÃO FUNCIONAIS Carregar consulta em 2 segundos 114
Revisão 3 115 • Requisitos Ágeis • User Stories • 7 Dimensões do Produto
Exercício Bloco 3 • 5 User Stories o Especifique 5 histórias do seu Story Mapping do exercício anterior • Use o PPT modelo a sua disposição o Tem 5 cartões frente e verso para você usar 116