Engenharia de Software Engenharia de Software

Behavior-Driven Development

Professor: Régis Patrick Silva Simão

Agenda

Ø  Introdução

Ø Behavior-Driven Development

Ø Personas

Ø Objetivos

Ø Histórias de Usuários

Ø Detalhamento das Histórias do Usuário

Bibliografia

Introdução Ø Processos Tradicionais

Ø Processos Ágeis

Introdução

Ø  Test-Driven Development (TDD)

Introdução

Behavior-Driven Development

Ø Histórias de Usuários e BDD

Behavior-Driven Development

Ø BDD e Testes Automatizados

Behavior-Driven Development

Ø BDD e Testes Automatizados

Behavior-Driven Development

Ø Histórias de Usuário

Behavior-Driven Development

Ø  Implementação de Histórias de Usuário

Behavior-Driven Development

Ø  Teste Automatizado e Documentação

Behavior-Driven Development

Ø Documentação

Behavior-Driven Development

Personas

Ø São as pessoas que usarão o sistema Ø Procura-se identificar nome, idade, necessidades,

limitações, culturas, etc. Ø Exemplo:

Ø  João, 26 anos, graduando Ø Maria, 65 anos, usa óculos, tem superior

completo Ø O objetivo principal é identificar características e

necessidades específicas de cada pessoa

Personas

Ø Modelo para identificação de Personas

Nome e

Desenho

Perfil

Comportamento Comportamento 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

Ø  Dean Leffingwell diferencia: Ø  Personas x Papeis desempenhados pelas personas

Ø  As Personas são exemplos reais dos Papeis Ø  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

Objetivos

Ø  São necessidades dos clientes e usuários, stakeholders.

Ø  São as metas do produto. Ø  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

Ø Exemplos: Ø  Comer as comidas preferidas

Ø  Descobrir novas comidas

Ø  Seguir os Food Truckers preferidos

Ø  Descobrir quais os Food Parks da cidade

Histórias

Ø Matriz Personas x Objetivos Ø  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

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>

Histórias

Ø Formato BDD: Ø Narrativa

Ø  Como Consumidor Ø  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

Histórias

Ø Formato BDD: Ø Critérios de aceitação

Ø 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…

Ø  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

Fonte: Curso de Gerenciamento Ágil de Requisitos, autor Junilson Pereira Souza

Ø 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

Histórias

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

Ø 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

Detalhamento das Histórias

Detalhamento das Histórias

FIM