Desenvolvimento Ágil de Produtos com Scrum

Engenharia de Software Desenvolvimento Ágil de Produtos com Scrum Concepção e Planejamento Professor: Régis Patrick Silva Simão

Agenda Ø Métodos Ágeis Ø SCRUM Ø Modelo de Negócio Ø Definição do Produto Ø Planejamento e Execução de uma Release Ø Documentação: Histórias

Bibliografia

Agenda Ø Métodos Ágeis Ø SCRUM Ø Modelo de Negócio Ø Definição do Produto Ø Planejamento e Execução de uma Release Ø Documentação: Histórias x Casos de Uso

Manifesto Ágil Ø Foi escrito em Fevereiro de 2001 Ø Um encontro de dezessete profissionais com ideias independentes ligados a várias metodologias de desenvolvimento Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

Manifesto Ágil Ø Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Ø Através deste trabalho, passamos a valorizar: 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 Ø Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Manifesto Ágil Manifesto Ágil

Colaboração Ø Dinâmica sobre Colaboração Ø Divida as pessoas em equipes de 5 pessoas Ø Cada equipe deve escolher duas pessoas para Ø serem clientes ou analistas de requisitos Ø Os demais participantes serão desenvolvedores Ø Primeira iteração Ø Os analistas de requisitos verão o desenho sobre a mesa do instrutor e repassarão informações, somente da forma escrita, para que a equipe de desenvolvedores replique o desenho Ø Segunda iteração Ø Os analistas de requisitos verão o desenho sobre a mesa do instrutor e, em seguida, sentarão com os desenvolvedores e os ajudarão a replicar o desenho Ø Compare os desenhos da primeira e segunda iterações

SCRUM Ø Papeis Ø Scrum Master Ø Product Owner Ø Time de Desenvolvimento

SCRUM Ø Papeis: Scrum Master Ø Garante que o time conhece o scrum e o executa corretamente Ø Garante que o time realize as práticas definidas pelo próprio time Ø Retira os impedimentos do time, resolve os problemas e faz o time continuar sempre trabalhando

SCRUM Ø Papeis: Product Owner Ø É a interface da equipe de desenvolvimento com o stakeholders e usuários finais Ø Define que funcionalidades serão feitas pelo time, definindo assim o product backlog Ø Prioriza estas funcionalidades, maximizando o ROI (Return of Investiment)

SCRUM Ø Papeis: Time de Desenvolvimento Ø Constrói e entrega um conjunto de funcionalidade do product backlog ao final de cada sprint Ø São auto-organizados e auto-gerenciados Ø Equipe multi-disciplinar Ø Profissionais T

SCRUM Ø Artefatos Ø Product Backlog Ø Sprint Backlog Ø Gráfico Burndown

SCRUM Ø Artefatos: Product Backlog Ø A lista priorizada de todas funcionalidades para o produto (Independente de Release e Sprint) Ø Pode ser uma planilha com as funcionalidades Ø Pode mudar ao final de cada sprint: incluindo ou removendo funcionalidades ou simplesmente repriorizando-as

SCRUM Ø Artefatos: Sprint Backlog Ø A lista das funcionalidades mais prioritárias e eleitas pelo time para serem construídas na sprint

SCRUM Ø Artefatos: Gráfico Burndown

SCRUM Ø Cerimônias Ø Planejamento da Sprint Ø Reunião Diária Ø Revisão/Validação da Sprint Ø Retrospectiva da Sprint

SCRUM Ø Cerimônias: Planejamento da Sprint Ø Revisão da lista de histórias, incluindo ou removendo histórias e repriorizando-as Ø Selecionam as histórias, obedecendo a ordem de prioridade, que cabem na sprint

resolvê-los SCRUM Ø Cerimônias: Reunião Diária Ø Também conhecida como Standup Meeting, pois sugere-se que os participantes fiquem em pé para que ela seja breve Ø Todo dia tem reunião diária! no mesmo horário Ø Cada participante responde a três perguntar: Ø O que você fez de ontem até hoje? Ø O que você vai fazer de hoje até amanhã? Ø Tem algum impedimento? Ø O Scrum Master deve anotar os impedimentos e procurar

SCRUM Ø Cerimônias: Revisão/Validação da Sprint Ø Realizada no último dia da sprint Ø Reunião onde os stakeholders e o time scrum interagem para discutir as entregas da sprint Ø É interessante que os usuários tenham experimentado as funcionalidades entregues Ø As funcionalidade que não forem validadas, voltam para o backlog para reavaliação no planejamento da sprint

SCRUM Ø Cerimônias: Retrospectiva da Sprint Ø Realizada no último dia da sprint Ø Só o time scrum participa. Ø Fazer um brainstorm para cada pergunta: Ø O que foi bom e devemos repetir? Ø O que foi ruim e não devemos mais fazer? Ø O que não fizemos e seria bom fazer? Ø Elaborar um plano de ações de ações

Pilares do SCRUM

Iterativo

Ø Dinâmica do Avião Colaboração Ø Divida as pessoas em equipes de 5 pessoas

Business Model Canvas Atividades Chave Propostas de Valor Relações com Clientes Parcerias Chave Segmentos de Clientes/Mercados Recursos Chave Canais de Comunicação Estrutura de Custos Fontes de Renda

Business Model Canvas

Business Model Canvas Ø Dinâmica sobre Business Model Canvas Ø Equipes de 5 pessoas Ø Cada Equipe: Ø Criar o canvas numa cartolina conforme o modelo Ø Fixar o canvas na parede Ø Utilizar brainstorm para levantamento das informações de cada seção do canvas Ø Utilizar post-its para escrever as informações de cada seção do canvas Ø O instrutor explica o sistema que deve ser desenvolvido

Segmentos de Clientes/Mercado Ø Segmentos de clientes são divisões dos clientes de acordo com suas necessidades, costumes ou outro atributo em comum, de forma que possam melhor entender, alcançar e servir esses clientes. Ø Quem são os clientes que você pretende atender? Eles têm um perfil específico? Como eles estão agrupados? Como estão localizados? Há uma necessidade comum? Ø Exemplos Ø Casas Bahia Ø Pessoas das classes C, D e E que precisam de crédito para comprar ou pessoas buscando preços baixos e facildiade de pagamento. Ø Ferrari Ø Homens ricos e apaixonadas por carros esportivos. Ø Fonte: http://www.web2canvas.x4start.com/

Segmentos de Clientes/Mercado Ø Dinâmica sobre Business Model Canvas Ø Identificar os Segmentos de Clientes

Propostas de Valor Ø A proposta de valor é como a empresa cria valor para um determinado Segmento de Cliente e se diferencia da concorrência. Ø Qual seu pacote de produtos e serviços e o valor que ele possui para os clientes? Ø Exemplos: Ø Apple Ø Produtos inovadores com qualidade e design diferenciado e simples de serem usados. Ø Subway Ø Lanches rápidos, saudáveis e personalizados. Ø Fonte: http://www.web2canvas.x4start.com/

Propostas de Valor Ø Dinâmica sobre Business Model Canvas Ø Identificar as Propostas de Valor

Canais de Comunicação Ø São a forma como uma empresa comunica e entrega a sua Proposta de Valor para cada Segmento de Cliente. Ø Basicamente, envolve os canais de marketing e logístico das empresas. Ø Exemplos: Ø Submarino Logística Ø Correios e operadores logísticos privados. Ø Submarino Marketing Ø Site, SEO, link patrocinado e publicidade online. Ø Fonte: http://www.web2canvas.x4start.com/

Canais de Comunicação Ø Dinâmica sobre Business Model Canvas Ø Identificar os Canais de Comunicação

Relações com Clientes Ø O relacionamento com o cliente é a forma como a empresa interage com um Segmento de Cliente. Ø Tipos de relação para conquistá-los e mantê-los. Ø Exemplo: Ø Santander Ø Agências, agências Van Gogh, atendimento por telefone, SAC, ouvidoria, redes sociais e internet banking. Ø Fonte: http://www.web2canvas.x4start.com/

Relações com Clientes Ø Dinâmica sobre Business Model Canvas Ø Identificar as Relações com Clientes

Fontes de Receita Ø Descreve a forma como uma empresa gera receita através de cada Segmento de Cliente. Ø É o dinheiro que a empresa gera. Quanto e como você vai receber dos clientes. Ø Exemplos: Ø Emirates Ø Venda de passagens aéreas, transporte de carga e reserva de carros e hotéis. Ø Turma da Mônica Ø Venda de revistas, licenciamento de produtos e venda de animações. Ø Fonte: http://www.web2canvas.x4start.com/

Fontes de Receita Ø Dinâmica sobre Business Model Canvas Ø Identificar as Fontes de Receitas

Parcerias Chave Ø É a rede de fornecedores e parceiros que ajudam a sua empresa a funcionar. Ø São empresas, instituições e/ou pessoas que são importante para o funcionamento do modelo de negócios. Ø Exemplos: Ø Mc Donalds Ø Fornecedores e franqueados. Ø Zynga Ø Facebook, appstores, comunidade dos jogos e lojas que vendem cartão pré-pago Zynga. Ø Fonte: http://www.web2canvas.x4start.com/

Parcerias Chave Ø Dinâmica sobre Business Model Canvas Ø Identificar as Parcerias Chaves

Atividades Chave Ø São todas as atividades sem as quais não seria possível atender a Proposta de Valor, construir os canais necessários e manter os relacionamentos. Ø Podem ser atividades-chave desde acompanhar redes sociais (uma atividade interessante para contribuir com o relacionamento com os clientes) até construir uma loja (que pode se relacionar com as propostas de valor e canais específicos). Ø Exemplos: Ø Globo Ø Elaborar programas, produzir programas, vender propaganda e buscar novos talentos. Ø Cacau Show Ø Desenvolver novos chocolates, produzir chocolates, gestão das franquias, distribuição e venda. Ø Fonte: http://www.web2canvas.x4start.com/

Atividades Chave Ø Dinâmica sobre Business Model Canvas Ø Identificar as Atividades Chaves

Recursos Chave Ø São os principais recursos necessários para que uma empresa faça seu Modelo de Negócios funcionar. Ø Podem ser equipes, máquinas, investimentos e plataformas de tecnologia, por exemplo. Ø Exemplo: Ø Facebook Ø Base de usuários, equipe, servidores e plataforma. Ø Vale Ø Minas, equipamentos e know-how técnico. Ø Fonte: http://www.web2canvas.x4start.com/

Recursos Chave Ø Dinâmica sobre Business Model Canvas Ø Identificar os Recursos Chaves

Estrutura de Custos Ø A estrutura de todos os custos envolvidos nos principais custos decorrente da operação do Modelo de Negócios. Ø Indica, por exemplo, a necessidade de se pagar a manutenção das máquinas previstas, os pagamentos dos parceiros contratados, o custo recorrente de infraestrutura, o custo das equipes envolvidas, e assim por diante. Ø Exemplos: Ø Claro Ø Infraestrutura da rede, lojas, funcionários, marketing e call center. Ø TAM Ø Aviões, manutenção dos aviões, combustível, marketing, funcionários, call center e sistemas de TI. Ø Fonte: http://www.web2canvas.x4start.com/

Estrutura de Custos Ø Dinâmica sobre Business Model Canvas Ø Identificar a Estrutura de Custos

Definição do Produto Ø Técnica Inception Ø Técnica desenvolvida pelo Thoughtworks Ø Dean Leffingwell chama esta reunião de definição do produto de Workshop de Histórias de Usuário, mas não entra em detalhes de como executá-la em seu livro Requisitos de Software Ágil Ø Usa-se bastante a técnica de Brainstorm

Inception (Concepção) Ø Kickoff Ø Início da Definição da Visão Ø Personas Ø Objetivos Ø Visão Ø Risco, Pendências e Requisitos Não Funcionais Ø Histórias

Agenda de uma Inception Seg Ter Qua Qui Sex Introdução Kick-off Manhã O Produto É Personas Objetivos Lista de Histórias Detalhamento das Histórias Detalhamento das Histórias Pontuação das Histórias Visão Tarde Lista de Histórias Roadmap MVPs Detalhamento das Histórias Detalhamento das Histórias Planejamento da Release Definições de Pronto e de Feito Retrospectiva

Kickoff Ø Reunião inicial onde o projeto é aberto oficialmente, onde são apresentados em linhas gerais os stakeholders e suas as necessidades. Ø Todos os stakeholders devem estar presentes, pelo menos, os mais importantes. Ø É interessante definir as hipóteses que o projeto tem que validar durante as fases iniciais. Isto guiará os Minimum Viable Products (MVP). Ø Se fizerem o Business Model Canvas, esta reunião deve ser antes.

Kickoff Ø Dinâmica sobre Kickoff Ø O principal stakeholder irá apresentar sistema a ser desenvolvido Ø Já realizado no Business Model Canvas

Início da Visão do Produto Ø Antes da definição da visão, pode-se fazer uso da técnica: Atividade É / Não é / Faz / Não faz Ø Modelo da Atividade É / Não é / Faz / Não Faz <Nome do Produto> É Não é Faz Não faz Fonte: Livro Direto ao Ponto, Paulo Caroli, Editora Casa do Código, 2015

Início da Visão do Produto Ø Exemplo da Atividade É / Não é / Faz / Não Faz App Food Follower É Ø Uma aplicação móvel Ø Uma rede social Não é Ø Uma aplicação Web Faz Ø Cadastrar Food Parks Ø Cadastrar Food Trucks Ø Seguir Food Trucks e Food Parks Não faz Ø Ensinar a fazer as comidas

Início da Visão do Produto Ø Dinâmica sobre o início da definição da Visão do Produto Ø Fazer a Atividade É / Não é / Faz / Não Faz Ø Pregar uma cartolina na parede, colocar o nome do produto como título e fazer quatro quadrantes com: É / Não é / Faz / Não faz Ø Fazer um brainstorm para preenchimento dos quadro quadrantes

Personas Ø São as pessoas que usarão o sistema, que representam os Segmentos de Clientes Ø O objetivo principal é identificar características e necessidades específicas de cada pessoa ou segmento de clientes Ø Procura-se identificar nome, idade, necessidades, limitações, culturas, etc. Ø Exemplo: Ø João, 26 anos, graduando Ø Maria, 65 anos, usa óculos, tem superior completo

Personas Ø Modelo para identificação de Personas Nome e Desenho Perfil Comportamento Necessidades Fonte: Livro Direto ao Ponto, Paulo Caroli, Editora Casa do Código, 2015

Personas Ø Modelo para identificação de Personas João Perfil Ø 26 anos Ø casado Ø graduando em Administração Comportamento Ø Curioso Ø Apreciador de boa comida Ø Questionador Necessidades Ø Ter acesso rápido à informações sobre Food Parks Ø Saber onde o seu Food Truck preferido estará este fim de semana

Personas Ø Modelo para identificação de Personas Dados Pessoais e Demográficos Ø 26 anos Ø Casado Ø Graduando em Administração João Necessidades Ø Espaço para comer boa comida e estar com os amigos Hobbies Ø Conversar com os amigos Ø Estar com a família Ø Apreciador de boa comida Objetivos Ø Conhecer e experimentar novas comidas Ø Saber onde estão os seus food trucks preferidos Barreiras Ø Muitos food parks e food trucks Ø Não conhece muitos food parks no seu bairo

Personas Ø Dean Leffingwell diferencia: Ø Personas x Papeis desempenhados pelas personas Ø As Personas são exemplos reais dos Papeis (Segmentos de Clientes) Ø Os Papeis são os Atores dos Casos de Uso do RUP Ø Na escrita das histórias, normalmente utilizam-se os Papeis Ø Exemplos de Papéis: Ø Consumidor em geral Ø Estudantes de culinária Ø Donos de Food Truckers Ø Organizadores de Food Parks

Personas Ø Dinâmica sobre Personas Ø Criar uma cartolina com os papeis das Personas Ø Fazer o brainstorm para levantamento das personas Ø Identificar os papeis que as pessoas devem desempenhar no uso do produto

Objetivos Ø São necessidades dos clientes e usuários, stakeholders, são o quê eles realmente querem com aplicativo. Ø São as metas do produto do ponto de vista do cliente. Ø Se for desenvolvimento o Business Model Canvas anteriormente, as propostas de valor são fortes candidatas a serem objetivos do produto. Ø Devem ser identificados em uma cartolina a parte. Ø Utilizar a técnica de brainstorm com os stakeholders. Ao final, os objetivos devem ser priorizados. Ø Se muitos objetivos forem levantados, considerar os três ou quatro mais importantes para tratamentos nas primeiras releases, ou seja, identificação de histórias.

Objetivos Ø Como encontrar objetivos: Ø Fazer brainstorm, pedindo que cada participante informe três objetivos do produto Ø Agrupá-los em grupos de afinidades Ø Identificar os principais objetivos do produto Ø Exemplos: Ø Comer as comidas preferidas Ø Descobrir novas comidas Ø Seguir os Food Truckers preferidos Ø Descobrir quais os Food Parks da cidade

Objetivos Ø Dinâmica sobre Objetivos Ø Criar uma cartolina com título Objetivos Ø Fazer o brainstorm para levantamento dos objetivos, colando post-its com os objetivos na cartolina Ø Se o Business Model Canvas tiver sido feito, considerar as Propostas de Valor como objetivos

Visão do Produto Ø O Elevator Pitch é uma técnica para criar uma visão do produto Ø Modelo: Ø Para as <Personas> Ø Que tem <Objetivos> Ø O produto <Nome do Produto> Ø Que tem <Características mais importantes> Ø É como um <Categoria de Produtos> Ø Ao contrário <Produtos Concorrentes/ Funcionalidades diferentes> Ø Nosso produto tem <Vantagens>

Visão do Produto Ø Visão do App Food Follower Ø Para os Consumidores, Donos de Food Truckers e Ornanizadores de Food Parks Ø Que desejam comer as suas comidas favoritas, seguir seus food truckers favoritos, divulgar seus food truckers e food parks Ø O produto Food Follower Ø Que tem como função principal divulgar os food truckers e food parks da cidade Ø É como um uma rede social para divulgação de food trucker e food parks Ø Ao contrário dos sites de um único food trucker ou de um único food park Ø Nosso produto tem a vantagem de permitir seguir os food trucker preferidos

Visão do Produto Ø Dinâmica sobre Visão do Produto Ø Fazer a visão do produto Ø Pregar uma cartolina na parede, colocar o título Visão Ø Preencher conforme o Elevator Pitch

Riscos, Pendências e Requisitos Não Funcionais Ø Ficam em cartolinas separadas Ø Tanto Riscos como Pendências podem ter nominados responsáveis pela mitigação e providência.

Riscos, Pendências e Requisitos Não Funcionais Ø Dinâmica sobre Riscos, Pendências e Requisitos Não Funcionais Ø Pregar três folhas A4 na parede, cada uma com um título Riscos, Pendências e Requisitos Não Funcionais Ø A medida que os riscos, pendências e requisitos não funcionais forem aparecendo, eles devem ser colocados em cada folha A4 correspondente

Histórias Ø Funcionalidades ou porções de funcionalidade Ø Épico x História Ø Os três C's: Ø Escrita em um Cartão Ø É um convite a Conversação Ø Precisa de Confirmação: critérios de aceite Ø Como descobrir Histórias (Features): Ø Matriz Personas x Objetivos Ø Que funcionalidades o sistema precisa ter para a persona alcançar o objetivo?

Histórias Ø Formato BDD - Behavior-Driven Development ou Desenvolvimento orientado por comportamento Ø Narrativa Ø Como <ator/persona> Ø Quero/posso/desejo/preciso <funcionalidade> Ø Para <objetivo de negócio> Ø Critérios de aceitação Ø Dado que <pré-condição> Ø Quando <ação> Ø Então <resultado esperado>

Ø Formato BDD: Ø Narrativa Ø Como Consumidor Histórias Ø Quero pesquisar onde o Food Trucker A Melhor Comida estará este fim de semana Ø Para poder comer a minha comida preferida Ø Critérios de aceitação Ø Dado que estou na tela de Pesquisar Eventos do Food Trucker E existem Food Parks onde o Food Trucker A Melhor Comida irá participar no período de 25/09/2015 à 27/09/2015 Ø Quando eu informo o Food Trucker A Melhor Comida e o período de 25/09/2015 à 27/09/2015 E solicito a pesquisa Ø Então são apresentados os Food Parks onde o Food Trucker estará presente no período de 25/09/2015 à 27/09/2015

Ø Formato BDD: Ø Critérios de aceitação Histórias Ø Dado que estou na tela de Pesquisar Eventos do Food Trucker e NÃO existem Food Parks onde o Food Trucker A Melhor Comida irá participar no período de 02/10/2015 à 04/10/2015 Ø Quando eu informo o Food Trucker A Melhor Comida e o período de 02/10/2015 à 04/10/2015 E solicito a pesquisa Ø Então o sistema apresenta a mensagem O Food Trucker A Melhor Comida não participará de nenhum Food Trucker no período de 02/10/2015 à 04/10/2015

Histórias Ø Formato BDD: Ø Narrativa Ø Como Consumidor Ø Quero me cadastrar no aplicativo Ø Para poder seguir o meu food trucker preferido Ø Critérios de aceitação Ø Dado que estou na tela de cadastrado de consumidor Ø Quando eu informo os meus dados E solicito o cadastro Ø Então o sistema valida os meus dados, me cadastra como consumidor E apresenta a tela principal do app como consumidor logado

Histórias Ø Atributos de uma boa história (INVEST) Ø I Independente (pode ser implementada sozinha) Ø N Negociável (histórias não são contratos rígidos, são um convite a conversação) Ø V - Valiosa para o cliente Ø E Estimável (complexidade, tamanho, esforço, tempo, por exemplo) Ø S Small (Pequena para caber em uma sprint) Ø T - Testável

Histórias Ø Caso de uso Manter Cliente Ø FP: Incluir cliente Ø FA1: Consultar cliente Ø FA2: Alterar cliente Ø FA3: Excluir cliente Ø FE1: Campos obrigatórios Ø FE2: Exclusão não permitida Ø Como gestor Quero incluir cliente Ø Dado que o gestor está ativo Quando informo dados do cliente Então o sistema inclui registro Ø Dado que o gestor está ativo Quando informo campos em branco Então sistema apresenta mensagem de erro ERR-31 Ø Como um colaborador Quero consultar cliente Ø Dado que Ø Como um gestor Quero alterar cliente Ø Dado que Fonte: Curso de Gerenciamento Ágil de Requisitos, autor Junilson Pereira Souza Ø Como um gestor Quero excluir cliente Ø Dado que acesso um cliente com pendências Quando solicito exclusão do registro Então sistema apresenta mensagem de erro ERR-32

Histórias Ø Histórias x Casos de Uso Parâmetro História Caso de Uso Tamanho Pequeno Não definido Abrangência Funcionalidade mínima Funcionalidade completa Tempo de Implementação Iteração Não definido Base para es@ma@va Fácil (devido ao tamanho) Variável (devido ao tamanho) Rigor Intenção Contrato Organização Listas Documento de requisitos Elaboração Just-in-@me Prévia Colaboração Prevista Não definido Fonte: Curso de Gerenciamento Ágil de Requisitos, autor Junilson Pereira Souza

Histórias Ø Histórias x Casos de Uso Ø Não é uma regra, mas tipicamente pode ocorrer o mapeamento de uma história para cada fluxo de um caso de uso, considerando os fluxos principais e alternativos Ø O aspecto principal é respeitar os princípios de timebox e de valor agregado de uma história Ø Com isto, pode haver mais de uma história para um fluxo ou vice-versa Ø Além disso, os fluxos de exceção não seriam em geral modelados como histórias, visto que não agregam valor. Neste caso, poderiam ser tratados como critérios de aceite. Fonte: Curso de Gerenciamento Ágil de Requisitos, autor Junilson Pereira Souza

Histórias Ø Dicas para boas histórias Ø Uma boa história deve passar por todas as camadas da aplicação: Ø Errado: Fazer só o formulário, depois fazer a gravação no banco. Ø Faça uma funcionalidade que tenha valor para o usuário, mesmo que pequena. Ø Coloque as restrições (requisitos não funcionais) como histórias. Ø Detalhe ou quebre em histórias menores as histórias mais próximas de serem feitas. As que estão longe de serem implementadas podem ser maiores e menos precisas. Ø Deixe os detalhes da interface com o usuário fora das histórias sempre que possível. Crie protótipos e documentos específicos.

Histórias Ø Dicas para boas histórias Ø Se algum aspecto do sistema precisar ser documentado em um formato diferente, não exite, use o formato desejado. Ø Use os atores específicos nas histórias, evite usar atores genéricos, como usuário. Ø Escreva a história para um único usuário, na terceira pessoa do singular Ø Escreva as histórias na voz ativa Ø O usuário/cliente deve escrever as histórias Ø Não numere as histórias (a razão para isto seria rastreabilidade), no máximo dê um título Ø Lembre que a história é um convite a conversação. Não coloque muitos detalhes nelas.

Histórias Ø Lista exemplo e parcial de Histórias do Food Follower Ø Cadastrar-se como Consumidor Ø Cadastrar-se como Dono de Food Trucker Ø Cadastrar-se como Organizador de Food Park Ø Pesquisar Participação de Food Trucker Ø Seguir Food Trucker Ø Divulgar Food Park Ø Divulgar Food Trucker Ø Logar-se como Consumidor Ø Logar-se como Dono de Food Trucker Ø Logar-se como Organizador de Food Park Ø Logout

Histórias Ø Lista exemplo e parcial de Histórias do Food Follower Ø Editar dados como Consumidor Ø Editar dados como Dono de Food Trucker Ø Editar dados como Organizador de Food Park Ø Exclui-se como Consumidor Ø Exclui-se como Dono de Food Trucker Ø Exclui-se como Organizador de Food Park Ø Pesquisar Participação de Food Trucker Ø Recomendar Food Trucker Ø Recomendar Food Park

Histórias Ø Dinâmica sobre Histórias Ø Fazer uma matriz na parede: Ø Na Horizontal, colocar os objetivos, os mais prioritários ficam a esquerda Ø Na vertical, colocar as personas (papeis) Ø Realizar um brainstorm para identificar as histórias Ø Colocar somente um título para cada história

Jornadas Ø São sequências de ações (um cenário) de uma persona que descrevem o passo a passo para alcançar um objetivo. Ø O livro do Paulo Carolli mostra contextos do dia a dia dos usuários. Ø Depois puxe as histórias para os passos da jornada para entender como elas se encacharão no dia a dia da persona Ø Outro uso: Ø Forma de sistematizar a descoberta de histórias

Jornadas Ø Exemplo: Ø Persona: Consumidor em geral Ø Objetivo: Comer as comidas preferidas Ø Jornada: Ø Acessar o app Ø Pesquisar Comidas Ø Detalhar Comida Ø Visualizar calendário do Food Trucker

Jornadas Ø Dinâmica sobre Jornadas Ø Pegar três intercessões entre Personas e Objetivos que já possuem histórias e criar cenários Ø As novas histórias devem ser colocadas na matriz Persona X Objetivo

Planejamento e Execução da Release Ø Roadmap do Produto Ø Priorização das Histórias: Valor x Risco Ø Detalhamento das Histórias Ø Pontuação das Histórias (Planning Poker) Ø Distribuição das Histórias em Sprints Ø Sprints Ø Kanban Ø Cerimônias

Roadmap do Produto

Priorização das Histórias: Valor x Risco Risco Alto Evite (1) Faça primeiro (4) Baixo Faça em terceiro (2) Faça em segundo (3) Baixo Alto Valor de Negócio

Priorização e Roadmap do Produto Ø Dinâmica sobre Priorização e Roadmap do Produto Ø Pegue a planilha de priorização com o professor Ø Insira todas as histórias Ø Avalie as histórias quanto ao valor de negócio e risco Ø Ordene as histórias pelo quadrante Ø Refine a priorização Ø Reordene as histórias pela nova priorização

Priorização e Roadmap do Produto Ø Dinâmica sobre Priorização e Roadmap do Produto Ø Criar quadro na parede, colocando os objetivos na parte superior Ø Depois distribua as histórias em baixo de cada objetivo Ø Procure identificar as histórias mais simples e que juntas podem ser entregues aos stakeholders, de forma que eles possam validar suas hipóteses o mais cedo possível, esta será a Release 1. Lembre de considerar a avaliação das prioridades Ø Continue fazendo o mesmo processo e descobrindo novas Releases

Priorização e Roadmap do Produto Ø Dinâmica sobre Priorização e Roadmap do Produto Ø Volte para a planilha e reordene as histórias conforme as Releases

Detalhamento das Histórias Ø Detalhamento das Histórias Ø Narrativa Ø Telas Ø Regras de Negócio Ø Critérios de Aceite Ø Tarefas

Detalhamento das Histórias Ø Narrativa Ø Como Persona Ø Eu quero fazer a História Ø Para Objetivo Ø Exemplo Ø Como Consumidor em Geral Ø Eu quero me cadastrar Ø Para poder serguir meus Food Truckers prefereridos

Detalhamento das Histórias Ø Telas Ø Wireframes

Detalhamento das Histórias Ø Telas - Exemplo Ø Wireframes

Detalhamento das Histórias Ø Regras de Negócio Ø Dados do Cliente Campo Tipo Tam Regra Mensagem Observações Código Inteiro 5 Obrigatório Código do cliente deve ser informado Numérico Único Não permite alteração Código do cliente deve ser numérico Código do cliente já existe Código do cliente não pode ser alterado Nome Texto 50 Obrigatório Nome do cliente deve ser informado Número de caracteres <= 50 Nome do cliente só pode ter 50 caracteres Deve fornecer lista de auxílio

Detalhamento das Histórias Ø Regras de Negócio Ø Regras para Inclusão de Cliente Ø O código do cliente deve ser gerado pelo sistema. Deve ser um sequencial. Ø Regras para Exclusão de Cliente Ø Cliente não pode ser excluído quando possui pedidos de compra registrados. Apresentar mensagem Cliente com pedidos registrados não pode ser excluído.

Detalhamento das Histórias Ø Critérios de Aceite Ø Dado que <Contexto> Ø Quando eu <Ação> Ø Então <Resultado> Ø Exemplos: Ø Cenário 1: Cadastro com sucesso Ø Dado que estou na tela de cadastro Ø Quando eu informo 1 no código e Régis Simão no nome Ø E solicito o cadastro Ø Então o sistema apresenta Cliente cadastrado com sucesso"

Detalhamento das Histórias Ø Tarefas Ø Criar tela de cadastro Ø Criar tabela Cliente no banco Ø Criar classes DAO, Entidade, Managed Beans

Detalhamento das Histórias

Detalhamento das Histórias Ø Dinâmica sobre Detalhamento das Histórias Ø Escolher três histórias e detalhá-las.

Pontuação das Histórias (Planning Poker)

Pontuação das Histórias Ø Dinâmica sobre Pontuação das Histórias Ø Chegou a hora de detalhar as histórias Ø Para as histórias da Release 1, rabisque os protótipos de tela com os stakeholders, defina as regras que devem ser implemetadas e os critérios de aceite Ø Nesta hora, pode-se fazer a documentação dos requisitos, que discutiremos mais adiante

Pontuação das Histórias Ø Dinâmica sobre Pontuação das Histórias Ø Utilize a técnica de Planning Poker para estimar a complexidade das histórias Ø Escolha a mais simples e atribua a pontuação 1 Ø Avalie as demais histórias comparando a primeira, identificando quanto a história em análise é mais complexa que a primeira Ø Vá lançando na planilha

Distribuição das Histórias em Sprints Ø Velocidade Ø Histórico Ø Arbitrar Ø Coletar

Distribuição das Histórias em Sprints Ø Dinâmica sobre Distribuição das Histórias em Sprints Ø Defina o tamanho da sprint, quantos dias ou semanas terá a sprint Ø Para estimar a primeira, utilize a técnica da Arbitragem Ø Pergunte a equipe de desenvolvimento quantas histórias a equipe consegue fazer na primeira sprint, identifique estas histórias como participantes da sprint 1, na planilha Ø Some a pontuação das histórias da sprint 1 Ø Separe o restante das histórias em sprints, identificando cada uma sprint Ø Mutiplique o número de sprints pelo tamanho da sprint e você terá a duração da primeira Release

Sprints

Sprints Ø Exemplo de Definição de Pronto Ø História pontuada Ø História escrita no padrão BDD Ø Critérios de aceitação escritos e no formato BDD Ø Documentação complementar produzida: Protótipos de telas, por exemplo

Sprints Ø Exemplo de Definição de Feito Ø Documentação da especificação atualizada Ø Implementação de código fonte terminada Ø Implementação e sucesso nos testes unitários Ø Sucesso nos testes funcionais Ø Alcance das metas das métricas definidas

Sprints Ø Dinâmica sobre Definição de Pronto e de Feito Ø Junto com os stakeholders, faça as Ø definições de pronto e de feito Ø Escreva-as cada uma em uma folha A4 e fixe-as na parede

kanban

Cerimônias

Agenda Ø Métodos Ágeis Ø SCRUM Ø Modelo de Negócio Ø Definição do Produto Ø Planejamento e Execução de uma Release Ø Documentação: Histórias

Documentação de Histórias Ø Especificação de Histórias de Usuários Ø Histórias de Usuários Ø Especificação de Regras de Negócio Ø Regras de Negócio Ø Especificação Complementar

Documentação de Histórias Especificação de Histórias de Usuários História 1 Especificação de Regras de Negócio Regra de Negócio História 2 Regra de Negócio História 3 Regra de Negócio Especificação Complementar História 1 Protótipos de Telas História 2 Protótipos de Telas História 3 Protótipos de Telas