proposta para especificação de estorias

Proposta para especificação de histórias de usuários utilizando a engenharia centrada no uso alinhada à prática IEEE 830

André Rocha [email protected]

Índice

1. Elicitando e Especificando Requisitos

2. Desmistificando User Stories

3. Como aplicar User Stories

4. User Stories no SCRUM

5. Boas práticas e sugestões

Tempo previsto:

Total: 50 minutos

Elicitando e Especificando

Requisitos

User centered design

• Atenção detalhada as necessidades, vontades e limitações do usuário final do produto durante o processo de design.

• Elicitação de requisitos do usuário através de métodos investigativos como estudo da etinografia, investigação contextual, personas, testes de usabilidade e outros métodos como generativo que pode incluir card sorting e sessões de design participativo ou cooperativo.

Elicitando e Especificando RequisitosAbordagens

User centered designer não é a bala de prata

Pontos fracos

• Estudos de usuários: Fácil confusão entre o que os usuários querem com o que eles realmente precisam

• Protótipo rápido: muitas vezes um substituto desleixado para design.

• Testes de usabilidade: Ineficiente ao encontrar problemas que muitas vezes poderiam ter sido evitados através de um projeto adequado


Usage centered design

• Processo sistemático que utiliza modelos abstratos para desenhar com simplicidade as atividades do usuário no sistema.


Destrinchando Usage Centered Design

User Role Model Task Model Content Model Bussiness Rule Model

Profiles

Actors User stories

Task case Abstract prototype

Prototype

Goals model

Critério de aceitação


Comparativo


Não apenas um, não apenas o outro....

User Centered DesignColeção de técnicas de fatores humanos unidos sobre uma

filosofia de entendimento de usuários envolvendo-os no design.

Usage Centered DesignUma alternativa de engenharia de software para

o user-centered design.

QuestionáriosConversas com o

usuárioBrainstorms Cardsorting ....

Modelos mentais

Modelos de interfaces

Modelos de especificações

Modelos de usuários

....


Desmistificando User Stories

• Nasceu na metodologia XP (Extreme Programming) mencionado pela primeira vez por Kent Beck - 1998

• Em 2001 Ron Jeffries propos um modelo (3Cs)

• Anos seguintes Mike Cohn deu continuidade e é hoje o principal especialista na área.

Desmistificando User StoriesUma breve história

Desmistificando User StoriesPor qual motivo foi criado?

1º ConviteUm convite para uma conversa, com uma linguagem simples e objetiva.

2º ConvesaUma conversa onde os envolvidos clarificam ideias e todo o entendimento écompartilhado e anotado.

3º ConfirmaçãoVerificação e confirmação se a estória atinge ou não os objetivos especificados.

Anote o meu celular

Poxa legal que você também gosta de The

Smiths.

3Cs• Card• Conversation• Confirmation

Desmistificando User StoriesAfinal o que é uma user story?

Descreve uma funcionalidade que terá valor para um usuário de um sistema.

Xaveco de BarComo galanteador, quero enviar um guardanapo para a mocinha bonita, para conseguir sexo esta noite.

Critérios de aceitação: • Ter um garçom camarada• Xaveco do guardanapo funcionar• Conquistar a mocinha• Convencer a ir pro motel

Composto por 3 aspectos:• Descrição escrita da estória a ser usada para o planejamento como um lembrete• Conversas sobre a estoria que servirão para destrinchar detalhes do

funcionamento• Testes que transmitem e documentam informações para determinar quando uma

estória esta completa

Frente Verso

Desmistificando User StoriesAfinal o que é uma user story?

Pré-requisitos

- Ter um documento de visão bem definido- Ter elicitado o mínimo necessário de requisitos do usuário - Montar um customer team

Visão do produto Requisitos do usuário Customer Team

Desmistificando User StoriesO que eu preciso para escrever?

No mundo perfeito seria uma unica pessoa que pudesse priorizar trabalho para os desenvolvedores e responder a todas as questões que envolve o funcionamento do software, escrevendo assim todas as estórias.

Escrever estórias é um trabalho que deve envolver mais pessoas e então sugere-se um time do cliente (customer team) composto por:

• Testers• Product manager• Usuarios reais • Designers de interação

Desmistificando User StoriesCustomer team

Desmistificando User StoriesO papel do analista

- A estória deve ser escrita na visão de negócio e sem nenhum termo técnico.

- A facilidade na escrita e leitura, possibilita uma grande redução do gap entre a equipe técnica, analistas e cliente.

- Os visionários do produto conhecem a melhor forma de descrever as estórias.

- Um analista na equipe pode agregar na especificação dos requisitos de forma geral, mas é a simplicidade de uma especificação em uma linguagem clara que possibilitará a escrita de estórias.

Requisitos muitos bem detalhados e com documentação extensa podem facilmente cair em um dos principais problema: documentos viram a meta de negócio.

User stories tendem a ser simples o suficiente para transparecer o que o usuário necessita, sendo assim esta a real meta do negocio

Cliente, usuário, stakeholders e equipes técnicas, quando uma dessas partes domina a comunição, o projeto pode se perder. O engajamento entre eles é melhor forma de garantir o compartilhamento das informações dos requisitos.

1º Comunicação

2º Foco no produto

Desmistificando User StoriesPor que devo escrever?

AplicandoUser Stories

Aplicando User StoriesBaby Steps com cenário hipotético

Marcelo

- 45 anos- Empreendedor no ramo literário- Acordou um certo dia com uma ideia:

JoanaProfissional UX

Através de uma indicação conversa com uma profissional de UX

Quero construir um site de reputação de livros


• Website para avaliações de livros: Ratazana.com.br• Público alvo: Leitores diversos• Visão: Fornecer resenhas e avaliações de livros não por especialistas mas sim

por outros leitores• Perfil do usuário: homens e mulheres acima de 13 anos residindo no Brasil

VISÃO:

REQUISITOS:

• Atores: Leitor • Lista de perfis: 3 tipos • Lista de atividades: 5 atividades principais• Conteúdo: Modelo mental e categorização (Taxonomia )• Regras de negócios: Sistema de avaliações 5stars (....)


REQUISITOS:

• Lista de atividades

• Personas

Persona:Carlos Eduardo25 anosLeitor assíduo de ficção científicaLê em média 2 livros por mêsEm mesa de bar, adora compartilhar com os amigos seusúltimos livros lidos.

Atividades

Buscar livros

Visualizar livro

Fazer avaliação

Visualizar avaliações


DOR (Definitation of Ready) para escrever estórias

Visão do produto Definição do usuário Perfil do usuário Personificação do usuário Lista de atividades principais Esboço de conteúdo: modelo mental e categorização Esboço de regras de negócios: sistema de avaliações 5stars

Próximos passos Montar o customer team


“The Three Amigos” proposta de Dan North (criador do BDD)

BA PO Tester

Product Managerou PO

Designer de interação Engenheiro de SW

Propostainicial

PropostaModificada


Montagem do Customer Team

Product Manager ou PO Designers de interação Testers (recomendado) ou pessoas no time com skills de tester

(prática recomenda no desenvolvimento Lean) Analistas (opcional) Usuários reais (recomendado no livro User Stories Applied) Engenheiro de SW (recomendação própria)

JoãoPO

RicardoDesigner de interação

FábioEngenheiro de SW


Por que um Product Manager?

PO é uma recomendação da metodologia SCRUM. Necessidade de treinamento e entendimento da metodologia SCRUM Product Manager tem skills e disciplinas alinhadas a produto. A role PO do Scrum é mais voltado ao negócio do que o produto

JoãoPO


Por que um Designer de interação?

Alinhado a abordagem Usage Centered Design e User Centered Design Assim como o engenheiro de SW, deve ter diversas skills:

Protipação rápida ou detalhada Discutir e fornecer soluções de interfaces Incorporar personas para testes Escrever cenários de testes

Ponte entre User Centered Design e Usage Centered Design Ponte entre a comunicação do Customer Team e do Develloper Team (Fronts)

RicardoDesigner de interação


Por que um Engenheiro de SW?

Alinhado a abordagem Usage Centered Design Skills de engenharia de SW que deve cobrir diversas disciplinas do SWEBOK, ex:

Qualidade na especificação dos requisitos Levantamentos de requisitos não funcionais Testabilidade e qualidade

Codificação e automatização dos testes Ponte entre a comunicação do Customer Team e do Develloper Team (Backs)

FábioEngenheiro de SW


Usage Centered Design Especificação em User Stories

User Model Usuário da estória

Tasks Model Descrição da estória

Content Model Protótipos

Bussiness Model Critérios de aceitação

Mãos na massa com PO

Atividades

Buscar livros

Visualizar livro

Fazer avaliação

Visualizar avaliações

Visualizar LivroComo leitor, quero visualizar um livro, para ter conhecimento sobre suas informações.

Critérios de aceitação: • Deve apresentar informações

quando publicado• Livro deve conter imagem de capa• Livro deve estar categorizado

Frente Verso

JoãoPO


Mãos na massa com PORefatoração

Visualizar LivroComo leitor, quero visualizar um livro, para ter conhecimento sobre suas informações.Notas: conversar com o Ricardo como podemos fazer uma interface simplesVamos usar o Google Books! Cadastramos na mão!

Critérios de aceitação: • Deve apresentar informações

quando publicado• Livro deve conter imagem de capa• Livro deve estar categorizado• Livro deve ter informações ISBN

JoãoPO


User Stories Workshop Visualizar LivroComo leitor, quero visualizar um livro, para ter conhecimento sobre suas informações.

Notas: conversar com o Ricardo como podemos fazer uma interface simplesVamos usar o Google Books! Cadastramos na mão!


User Stories Workshop Critérios de aceitação: • Deve apresentar informações

quando publicado• Livro deve estar disponível • Livro deve conter imagem de capa• Livro deve estar categorizado• Livro deve ter informações ISBN

Given que o livro está publicado When eu acessar Then mostrar informações do livro

Especificação de cenário simples

Especificação de cenário personificado Given que o livro está publicado When eu acessar And eu tiver um perfil de “leitor Ratão”Then mostrar informações do livroAnd priorizar informações da sinopse

• Deve priorizar informações de sinopse para o perfil “Ratão”


User Stories WorkshopCompilando informações

Critérios de aceitação: • Deve apresentar informações• Livro deve estar disponível • Livro deve conter imagem de capa• Livro deve estar categorizado• Livro deve ter informações ISBN• Deve priorizar informações de sinopse para

o perfil “Ratão”

Deve apresentar informaçõesGiven que o livro está publicadoWhen eu acessar Then mostrar informações do livro

Visualizar LivroComo leitor, quero visualizar um livro, para ter conhecimento sobre suas informações.

Protótipo:

Notas: Interface simples. Usar o Google Books!

Deve priorizar informações de sinopse para o perfil “Ratão”Given que o livro está publicado When eu acessar e tiver perfil “Ratão”Then mostrar informações do livroAnd priorizar informações de sinopse


Agil com tanta documentação?Show me the code

Critérios de aceitação: • Deve apresentar informações• Livro deve estar disponível • Livro deve conter imagem de capa• Livro deve estar categorizado• Livro deve ter informações ISBN• Deve priorizar informações de sinopse para

o perfil “Ratão”

Deve apresentar informaçõesGiven que o livro está publicado When eu acessar Then mostrar informações do livro

Scenario: Deve apresentar informaçõesGiven que o <livro> está <livroPublicado>When <leitor> acessar Then mostrar informações do <livro>

Examples:livro | livroPublicado | leitor | saida Gerente Minuto | false | Carlos | falseMundo de Sofia | true | Maria | trueAdmirável Mundo Novo | false | João | false

Codificação + Testes + Living documentation

BDD – Behavior Driven Development


Revisão do processo para criação de user storiesNão precisa ser dificil

1. PO esboça algumas estórias de acordo com a prioridade do backlog

2. As estórias precisam ser simples mas alinhadas ao 3Cs

3. PO não precisa se preocupar em estourar todas estórias. Estórias não descritas podem ser mantidas como Épicos e serem trabalhadas mais pra frente.

4. PO prioriza estórias que irão ser trabalhas no workshop

5. PO convoca workshop com o Customer Team

6. Customer Team trabalha revisando estórias. Cada um faz o seu papel e o objetivo é sair com estória compilada com informações para desenvolvimento (Scrum, Kanban...)

7. Workshops para escrita de estórias NÃO FAZEM parte do planning.

8. No planning as estórias já devem estar bem contadas o suficiente para:- Develloper Team poder estimar o esforço necessário- Customer Team poder objetivar as entregas- Ambos os times chegarem a um acordo do que realmente precisa ser entregue.

Ex: Objetivo da Sprint

User Stories no SCRUM

User Stories no SCRUMOrganizando iterações

Para o planejamento de realeases, o Customer Team ordena as estorias em varias pilhas cada pilha representando uma iteracao.

Sprint 1 Sprint 3Sprint 2

User story 1

User story 4

User story 3

User story 8

User story 5

User story 7

User story 6

User story 2

User story 5

Backlog

User story 9

User story 10

Epic 1 Epic 2

Customer Team: Vai priorizar estórias com maior valor de negócio aos usuários do sistema.

Developer Team: pode sugerir mudanças na priorização das estórias por motivos técnicos (Ex: dependências), mas no geral deve-se ter o consentimento em entender que as entregas devem gerar valor aos usuários.

User Stories no SCRUMPriorizando

Story points e a unidade utilizada para cada estória. Esta unidade representa o quanto de esforço necessário o Dev Team necessita para completar a estória. É comum o uso de Ideal Days ao invés de Story Points.

User Stories no SCRUMEstimando

Cada pilha ira conter algumas estorias e a soma das estimativas deve representar a velocidade do time de desenvolvimento. A velocidade do time de desenvolvido e criado após rodar algumas iterações e falhar nas estimativas iniciais.

User Stories no SCRUMVelocidade do Dev. Team

Sprint 1

User story 1 – 5pts



TOTAL: 22 story points

Velocidade do Time

20 story points/ sprint

Negociação na priorização e particionamento das estórias devem ocorrer em situações onde o total de pontos é maior que a velocidade do time.

Boas práticas e

sugestões

Fraquezas de uma user story

• Linguagem informal• Especificação incompleta• Não contempla requisitos

não funcionais

Boas práticas e sugestõesNem tudo é tão bonito

• Linguagem informal• Aplicar a técnica 5Ws para escrita estória

5ws Especificação

Who Leitor

What Avaliar um livro

Why Expressar sua opinião

Where Na interface de visualização do livro

When Quando estiver autenticado

Boas práticas e sugestõesSugestões

• Especificação incompleta• Contemplar especificações quando achar necessário• Criar rastreabilidade com a estória

5ws Especificação

Who Leitor

What Avaliar um livro

Why Expressar sua opinião

Where Na interface de visualização do livro

When Quando estiver autenticado

Use case “Avaliar livro”1. O sistema deve...2. O sistema deve...

Boas práticas e sugestõesNem tudo é tão bonito

• Requisitos Não Funcionais• Especificar critérios de aceitação não funcionais

Critérios de aceitação: Não funcionais• Sistema deve carregar informações em até

2 segundosFuncionais• Deve apresentar informações• Livro deve estar disponível • Livro deve conter imagem de capa

Sistema deve carregar informações em até 2 segundosGiven que o sistema está efetuando uma requisiçãoWhen eu acessar Then apresentar informações em até 2 segundos

Scenario: Sistema deve carregar informações em até 2 segundosGiven que o sistema está efetuando uma <requisição>When <leitor> acessar Then apresentar <informações> em até 2 segundos

Examples:requisição | leitor | informações | saida http get | Carlos | titulo,sinopse,ISBN | 0.80shttp rest | João | titulo,sinopse,ISBN | 1.80s



• O que é um requisito bem especificado?

IEEE 830

Caractéristicas User Stories

Correto Sempre ser direcionado ao uso do software

Não ambíguo Não devem existir estórias que descrevem as mesmas coisas

Completo Completar com informações até onde a equipe achar válido

Consistente Deve ser consistentes a documentos de alto nível (Ex: requisitos produzios no User Centered Design)

Classificável Capacidade de priorizar por importância

Verificável Critérios de aceitações e testes

Modificável Totalmente leve e passível de refatoração

Rastreável Permite rastreabilidade com épicos e demais especificações complementares

Referências

1. User Stories Applied – Mike Cohn

2. Usage centered engineering for Web Application – Constantine Lockwood

3. http://www.urisan.tche.br/~pbetencourt/engsoftI/IEEE830/caracteristicas.html

4. http://pt.slideshare.net/wakaleo/bdd-the-unit-test-of-the-product-owner

5. http://pt.slideshare.net/skillsmatter/bdd-introduction

6. http://dannorth.net/introducing-bdd/

7. http://www.agileforall.com/2010/05/new-to-agile-remember-a-user-story-is-more-than-a-card/

8. http://gojko.net/category/presentations/BDD

9. http://www.urisan.tche.br/~pbetencourt/engsoftI/IEEE830/

10. A proposal to combine requirements elicitation techniques to build a Vision and Use Cases in Scrum Methodology. Agostinho A., Kattan H. , Sigonirini N.http://pt.slideshare.net/AndreRocha1/2013-0520-artigo-prof-muniz-neryandrherez-v18-revhmk

http://www.urisan.tche.br/~pbetencourt/engsoftI/IEEE830/caracteristicas.html

http://pt.slideshare.net/wakaleo/bdd-the-unit-test-of-the-product-owner

http://pt.slideshare.net/skillsmatter/bdd-introduction

http://dannorth.net/introducing-bdd/

http://www.agileforall.com/2010/05/new-to-agile-remember-a-user-story-is-more-than-a-card/

http://gojko.net/category/presentations/BDD

http://www.urisan.tche.br/~pbetencourt/engsoftI/IEEE830/

http://pt.slideshare.net/AndreRocha1/2013-0520-artigo-prof-muniz-neryandrherez-v18-revhmk

proposta para especificação de estorias

Technology