SlideShare uma empresa Scribd logo
ALAN VASCONCELOS




DESIGN DE INTERAÇÃO
/ USABILIDADE
Processos /
User Stories
RECORDAR É VIVER!

Quando?
As avaliações podem ser aplicadas em diversos momentos do ciclo de vida de um produto.




  Avaliações formativas
  (ocorrem em cada ciclo de sprint)


                          Avaliações somativas
                          (ocorrem no final do ciclo, ou mesmo depois)
RECORDAR É VIVER!

Como?
No que diz respeito à aplicação, os métodos de avaliação de usabilidade podem ser
empíricos ou analíticos



Empíricos:

•   Requer a participação de usuários durante a coleta de dados,
    que, posteriormente, serão analisados pelo especialista, a fim
    de identificar os problemas da interface.
•   É realizado em ambientes controlados, no qual os avaliadores
    gravam toda a interação em vídeo para posterior análise.
    Durante a realização do teste, um dos avaliadores vai
    anotando os incidentes ocorridos durante a interação, além
    dos comentários do usuário em relação à interface.
•   Logo após o teste, os usuários respondem a um questionário
    com perguntas relacionadas à satisfação em relação ao
    produto e, também, perguntas com sugestões de melhorias.
RECORDAR É VIVER!

Como?
No que diz respeito à aplicação, os métodos de avaliação de usabilidade podem ser
empíricos ou analíticos


Analíticos:

•   Também conhecidos como métodos de inspeção, ou de prognóstico,
    caracterizam-se pelo fato do usuário não participar diretamente das avaliações.
•   Requer a presença de um especialista, que explorará a interface, a fim de encontrar
    problemas de usabilidade.
•   Além da identificação dos problemas, os avaliadores fazem sugestões de correção.
•   Tem como resultado um relatório formal dos problemas identificados
    e as sugestões de melhorias.
RECORDAR É VIVER!

Jakob Nielsen (1993), em seu livro Usability engineering, propõe um conjunto de dez
heurísticas de usabilidade:

1. visibilidade e reconhecimento do estado ou contexto atual do sistema;
2. compatibilidade com o mundo real;
3. controle e liberdade do usuário;
4. consistência e padrões;
5. prevenção de erros;
6. reconhecimento ao invés de memorização;
7. flexibilidade e eficiência de uso;
8. projeto estético minimalista;
9. diagnóstico e correção de erros; e
10. ajuda e documentação.

As heurísticas, neste caso, são um conjunto de regras e métodos
que levam à descoberta e à resolução* de problemas (NIELSEN, 1993).

*Leva à resolução, mas não aplica/implementa a resolução dos problemas encontrados.
USER STORIES
USER STORIES
Uma história...
Uma estória não é mais do que a descrição de uma pequena
funcionalidade que o cliente pretende ver desenvolvida no
sistema.

O termo em inglês é story (história – conto) e não history
(história - relato de fatos);
USER STORIES
O que são:
• Uma breve descrição de uma funcionalidade que foi
  discutida;
• São tradicionalmente escritas em cartões ou post-its;



O que não são:
• Documentos de implementação (classes, modelagem...);
• Imutáveis: Podem sofrer alterações e negociações ao
  longo do projeto;
• Casos de uso: Este último se refere à narrativa de
  funções de forma impessoal, ou seja, independente do
  usuário.
USER STORIES
Características
•   User Stories focam nos objetivos do usuário e como o sistema alcança
    esses objetivos.

•   User Stories fracionam os requisitos para que seja possível (e mais
    fácil) estimar o esforço para realizar aquele objetivo. Resumindo, User
    Stories são descrições simples que descrevem uma funcionalidade e é
    recomendável que sejam escritas segundo o ponto de vista do
    usuário.

•   User Stories devem ser curtas, simples e claras. Devemos conseguir
    escrevê-las em um simples e pequeno cartão (conhecidos como User
    Index Cards). Se não há espaço para escrevê-la em um cartão é
    porquê devemos refiná-la mais, e as dividir em outras User Stories.

•   Stakeholders escrevem User Stories, não os desenvolvedores. User
    Stories são simples o suficiente para que as pessoas possam aprender
    a escrevê-las em alguns minutos.


© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES




  User Stories Aqui
USER STORIES
Formato
•   Os cartões seguem um formato como o descrito abaixo:




© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES
Formato
•   Os cartões seguem um formato como o descrito abaixo:




© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES
Formato

• Ator – O proprietário da User Story. De forma
    simplista é o usuário, o interessado naquela
    funcionalidade. Mas é recomendado descrever
    de forma específica quem é o ator para ser mais
    fácil identificar o contexto da história dentro do
    sistema.

• Ação – É o que o ator quer fazer. Utilizando
    aquela ação ele espera alcançar seu objetivo
    dentro do sistema.

• Objetivo/Funcionalidade – É o que o ator
    espera que aconteça ao realizar a ação. Ou seja,
    é o resultado de executar a ação segundo a ótica
    do ator. Também pode ser visto como
    justificativa.

© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES
Escrevendo boas histórias

Independentes: Histórias devem ser independentes uma das outras;
(exemplo: usuário pode entrar com o nome do meio, primeiro nome e último nome.)

Negociáveis: Histórias não são contratos, mas lembretes para discussões;
(por questões de escopo, orçamento ou complexidade, as histórias podem ser removidas ou alteradas.)

De valor agregado: Histórias devem agregar valor para o usuário/cliente;
(exemplo: dizer que o sistema será feito em PHP e MySQL não é relevante para o usuário/cliente).




© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES
Escrevendo boas histórias

Estimáveis: Os desenvolvedores devem ser capazes de estimar o tamanhos das história;
(se não puder ser estimada, não será usada no sprint. Se for muito complexa, dividir em histórias
menores.)

Curtas: histórias grandes dificultam as estimativas. Bem como histórias muito pequenas.
Quebre ou agrupe dependendo do caso.
(Grandes histórias (épicas) são difíceis de estimar e difíceis de planejar, elas não se encaixam bem em
uma única iteração)

Testáveis: Histórias devem ser possíveis de serem testadas.
(Em vez de: “Não fazer o usuário esperar muito em cada tela”,
use: “As telas não deverão demorar mais que 2 segundos para abrir”.)




© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES
Processo: cada cartão uma história

1. Em cada cartão, listar todas as AÇÕES factíveis do usuário no
   produto
     Comece sempre com um verbo. Este será o “título” da história.

2. Escreva a história.
     Seguindo os critérios mostrados anteriormente. Ex.: Eu como
     JARDINEIRO preciso CAVAR UM BURACO para que eu possa PLANTAR
     UMA SEMENTE. (Deixe espaço para mais detalhes)

3. Atribua um valor de negócio (ROI) para cada cartão
     Pode ser: BAIXO, MÉDIO ou ALTO




© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES
Processo: o mapa

1- Organize os cartões horizontalmente em uma sequência lógica de operação




                                                     tempo




© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES
Processo: o mapa

2- Empilhe os cartões que possuem atividades simultâneas




                                                     tempo




© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES
Processo: o mapa
3- Ordene verticalmente os cartões em ordem de importância ou criticidade
(frequência de uso, ROI, valor do negócio, etc...)



                                                       Tempo
importância




© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES
Processo: o mapa
4- Observe os agrupamentos que se formam e discuta com a equipe.
Um conjunto de tarefas, forma uma atividade




                                                       Tempo
importância




© Jeff Patton, all rights reserved, www.AgileProductDesign.com
USER STORIES
Processo: o primeiro release
4- Discuta e escolha uma das atividades que será implementada primeiro.
Peça para a equipe de desenvolvimento estimar a implementação de cada cartão.
Essa é uma decisão estratégica!



                                                                  tempo
necessário
                                            Primeiro release

  opcional                                  Segundo release
                importância




     mais                                    Terceiro release
  opcional

 © Jeff Patton, all rights reserved, www.AgileProductDesign.com
HEIN?!?!

           ?
VALEU!




ALAN VASCONCELOS – www.alanvasconcelos.com

Mais conteúdo relacionado

Mais procurados

Prototipos de Baixa e Alta Fidelidade
Prototipos de Baixa e Alta FidelidadePrototipos de Baixa e Alta Fidelidade
Prototipos de Baixa e Alta Fidelidade
Erico Fileno
 
Usabilidade aula-02. Metas e princípios
Usabilidade aula-02. Metas e princípiosUsabilidade aula-02. Metas e princípios
Usabilidade aula-02. Metas e princípios
Alan Vasconcelos
 
MTA1 Aula-01. Introdução
MTA1 Aula-01. IntroduçãoMTA1 Aula-01. Introdução
MTA1 Aula-01. Introdução
Alan Vasconcelos
 
Mta1 aula-05 Avaliação Heurística
Mta1 aula-05 Avaliação HeurísticaMta1 aula-05 Avaliação Heurística
Mta1 aula-05 Avaliação Heurística
Alan Vasconcelos
 
Retorno do Investimento em Usabilidade
Retorno do Investimento em UsabilidadeRetorno do Investimento em Usabilidade
Retorno do Investimento em Usabilidade
Bernardo Mattos
 

Mais procurados (19)

Prototipos de Baixa e Alta Fidelidade
Prototipos de Baixa e Alta FidelidadePrototipos de Baixa e Alta Fidelidade
Prototipos de Baixa e Alta Fidelidade
 
Usabilidade aula-02. Metas e princípios
Usabilidade aula-02. Metas e princípiosUsabilidade aula-02. Metas e princípios
Usabilidade aula-02. Metas e princípios
 
Métodos ágeis
Métodos ágeisMétodos ágeis
Métodos ágeis
 
MTA1 Aula-01. Introdução
MTA1 Aula-01. IntroduçãoMTA1 Aula-01. Introdução
MTA1 Aula-01. Introdução
 
Aula 4 - Avaliação de Interface - Parte 1
Aula 4 -  Avaliação de Interface - Parte 1Aula 4 -  Avaliação de Interface - Parte 1
Aula 4 - Avaliação de Interface - Parte 1
 
Palestra - Princípios de Usabilidade
Palestra - Princípios de UsabilidadePalestra - Princípios de Usabilidade
Palestra - Princípios de Usabilidade
 
Usabilidade Aula-05. Processos: heuristicas
Usabilidade Aula-05. Processos: heuristicasUsabilidade Aula-05. Processos: heuristicas
Usabilidade Aula-05. Processos: heuristicas
 
Usabilidade aula-01 Introdução
Usabilidade aula-01 IntroduçãoUsabilidade aula-01 Introdução
Usabilidade aula-01 Introdução
 
Aula 5 -Avaliação de interfaces de usuário - testes com usuários
Aula 5 -Avaliação de interfaces de usuário - testes com usuáriosAula 5 -Avaliação de interfaces de usuário - testes com usuários
Aula 5 -Avaliação de interfaces de usuário - testes com usuários
 
Prototipação
PrototipaçãoPrototipação
Prototipação
 
Teoria do Processamento da Informação no Design
Teoria do Processamento da Informação no DesignTeoria do Processamento da Informação no Design
Teoria do Processamento da Informação no Design
 
Design De Interfaces
Design De InterfacesDesign De Interfaces
Design De Interfaces
 
Mta1 aula-05 Avaliação Heurística
Mta1 aula-05 Avaliação HeurísticaMta1 aula-05 Avaliação Heurística
Mta1 aula-05 Avaliação Heurística
 
Ihm07
Ihm07Ihm07
Ihm07
 
Retorno do Investimento em Usabilidade
Retorno do Investimento em UsabilidadeRetorno do Investimento em Usabilidade
Retorno do Investimento em Usabilidade
 
Prototipagem
PrototipagemPrototipagem
Prototipagem
 
Prototipação de software
Prototipação de softwarePrototipação de software
Prototipação de software
 
Prototipação
PrototipaçãoPrototipação
Prototipação
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
 

Semelhante a Usabilidade Aula-06. Processos: User Stories

Workshop User Stories
Workshop User StoriesWorkshop User Stories
Workshop User Stories
Mayra de Souza
 
O Papel do Product Owner
O Papel do Product OwnerO Papel do Product Owner
O Papel do Product Owner
Marcia Maia
 
Mta1 aula-04 Framework DECIDE
Mta1 aula-04 Framework DECIDEMta1 aula-04 Framework DECIDE
Mta1 aula-04 Framework DECIDE
Alan Vasconcelos
 
Usabilidade - Uma introdução
Usabilidade - Uma introduçãoUsabilidade - Uma introdução
Usabilidade - Uma introdução
Erico Fileno
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 

Semelhante a Usabilidade Aula-06. Processos: User Stories (20)

Workshop User Stories
Workshop User StoriesWorkshop User Stories
Workshop User Stories
 
Requisitos Ágeis
Requisitos ÁgeisRequisitos Ágeis
Requisitos Ágeis
 
ALM - Testes Exploratórios
ALM - Testes ExploratóriosALM - Testes Exploratórios
ALM - Testes Exploratórios
 
O Papel do Product Owner
O Papel do Product OwnerO Papel do Product Owner
O Papel do Product Owner
 
Aula 01.ppt
Aula 01.pptAula 01.ppt
Aula 01.ppt
 
A arte de escrever US - Agile brazil 2017
A arte de escrever US - Agile brazil 2017A arte de escrever US - Agile brazil 2017
A arte de escrever US - Agile brazil 2017
 
SCRUM - Aula 2
SCRUM - Aula 2SCRUM - Aula 2
SCRUM - Aula 2
 
Mta1 aula-04 Framework DECIDE
Mta1 aula-04 Framework DECIDEMta1 aula-04 Framework DECIDE
Mta1 aula-04 Framework DECIDE
 
Aula 03 - Metodologias Ágeis.pdf
Aula 03 - Metodologias Ágeis.pdfAula 03 - Metodologias Ágeis.pdf
Aula 03 - Metodologias Ágeis.pdf
 
Ux Presentation
Ux PresentationUx Presentation
Ux Presentation
 
Aula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisAula05 - Metodologias Ágeis
Aula05 - Metodologias Ágeis
 
Usabilidade - Uma introdução
Usabilidade - Uma introduçãoUsabilidade - Uma introdução
Usabilidade - Uma introdução
 
A Arte de Escrever User Stories: Quais são os segredos
A Arte de Escrever User Stories: Quais são os segredosA Arte de Escrever User Stories: Quais são os segredos
A Arte de Escrever User Stories: Quais são os segredos
 
Prototipagem em Papel - Oficina
Prototipagem em Papel - OficinaPrototipagem em Papel - Oficina
Prototipagem em Papel - Oficina
 
GRUPO DE FOCO
GRUPO DE FOCOGRUPO DE FOCO
GRUPO DE FOCO
 
Proposta para especificação de histórias de usuários alinhadas a IEEE 830
Proposta para especificação de histórias de usuários alinhadas a IEEE 830Proposta para especificação de histórias de usuários alinhadas a IEEE 830
Proposta para especificação de histórias de usuários alinhadas a IEEE 830
 
Aula 3
Aula 3Aula 3
Aula 3
 
(Petrobras) Repensando o design de experiências e processos
(Petrobras) Repensando o design de experiências e processos(Petrobras) Repensando o design de experiências e processos
(Petrobras) Repensando o design de experiências e processos
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Melhorando a experiência do usuário e otimização conversões através de aplica...
Melhorando a experiência do usuário e otimização conversões através de aplica...Melhorando a experiência do usuário e otimização conversões através de aplica...
Melhorando a experiência do usuário e otimização conversões através de aplica...
 

Mais de Alan Vasconcelos

MPP-III - Aula 08 - Usabilidade
MPP-III - Aula 08 - UsabilidadeMPP-III - Aula 08 - Usabilidade
MPP-III - Aula 08 - Usabilidade
Alan Vasconcelos
 
Mta1 aula-06 - Design Universal
Mta1 aula-06 - Design UniversalMta1 aula-06 - Design Universal
Mta1 aula-06 - Design Universal
Alan Vasconcelos
 
MTA1 Aula-02. Acessibilidade
MTA1 Aula-02. AcessibilidadeMTA1 Aula-02. Acessibilidade
MTA1 Aula-02. Acessibilidade
Alan Vasconcelos
 
Usabilidade aula-04. Processos: Personas
Usabilidade aula-04. Processos: PersonasUsabilidade aula-04. Processos: Personas
Usabilidade aula-04. Processos: Personas
Alan Vasconcelos
 
Usabilidade aula-03. Processos: Arquitetura de informação
Usabilidade aula-03. Processos: Arquitetura de informaçãoUsabilidade aula-03. Processos: Arquitetura de informação
Usabilidade aula-03. Processos: Arquitetura de informação
Alan Vasconcelos
 
Aula 03 - elementos-basicos
Aula 03 - elementos-basicosAula 03 - elementos-basicos
Aula 03 - elementos-basicos
Alan Vasconcelos
 

Mais de Alan Vasconcelos (20)

Design Universal - Os 7 Principios
Design Universal - Os 7 PrincipiosDesign Universal - Os 7 Principios
Design Universal - Os 7 Principios
 
Design Universal e arquitetura hostil
Design Universal e arquitetura hostilDesign Universal e arquitetura hostil
Design Universal e arquitetura hostil
 
Cibercultura
CiberculturaCibercultura
Cibercultura
 
MPP-III - Aula 08 - Usabilidade
MPP-III - Aula 08 - UsabilidadeMPP-III - Aula 08 - Usabilidade
MPP-III - Aula 08 - Usabilidade
 
Ergo2 aula-14 Avaliação Heurística
Ergo2 aula-14 Avaliação HeurísticaErgo2 aula-14 Avaliação Heurística
Ergo2 aula-14 Avaliação Heurística
 
Mta1 aula-06 - Design Universal
Mta1 aula-06 - Design UniversalMta1 aula-06 - Design Universal
Mta1 aula-06 - Design Universal
 
MTA1 Aula-02. Acessibilidade
MTA1 Aula-02. AcessibilidadeMTA1 Aula-02. Acessibilidade
MTA1 Aula-02. Acessibilidade
 
Usabilidade aula-04. Processos: Personas
Usabilidade aula-04. Processos: PersonasUsabilidade aula-04. Processos: Personas
Usabilidade aula-04. Processos: Personas
 
Usabilidade aula-03. Processos: Arquitetura de informação
Usabilidade aula-03. Processos: Arquitetura de informaçãoUsabilidade aula-03. Processos: Arquitetura de informação
Usabilidade aula-03. Processos: Arquitetura de informação
 
Aula 10--revisao
Aula 10--revisaoAula 10--revisao
Aula 10--revisao
 
Aula 07 - Web
Aula 07 - WebAula 07 - Web
Aula 07 - Web
 
Aula 04 - Prototipação
Aula 04 - PrototipaçãoAula 04 - Prototipação
Aula 04 - Prototipação
 
Aula 06 - variabilidade
Aula 06 - variabilidadeAula 06 - variabilidade
Aula 06 - variabilidade
 
Aula 03 - elementos-basicos
Aula 03 - elementos-basicosAula 03 - elementos-basicos
Aula 03 - elementos-basicos
 
Aula 02 - Introducao
Aula 02 - IntroducaoAula 02 - Introducao
Aula 02 - Introducao
 
MPIII - Aula 01 - Apresentação
MPIII - Aula 01 - ApresentaçãoMPIII - Aula 01 - Apresentação
MPIII - Aula 01 - Apresentação
 
ARIA - Aplicações web ricas e acessíveis
ARIA - Aplicações web ricas e acessíveisARIA - Aplicações web ricas e acessíveis
ARIA - Aplicações web ricas e acessíveis
 
Acessibilidade em SRI - Mhtx
Acessibilidade em SRI - MhtxAcessibilidade em SRI - Mhtx
Acessibilidade em SRI - Mhtx
 
Web Standards
Web StandardsWeb Standards
Web Standards
 
Personas na prática - Um estudo de caso (re)pensado
Personas na prática - Um estudo de caso (re)pensadoPersonas na prática - Um estudo de caso (re)pensado
Personas na prática - Um estudo de caso (re)pensado
 

Usabilidade Aula-06. Processos: User Stories

  • 1. ALAN VASCONCELOS DESIGN DE INTERAÇÃO / USABILIDADE Processos / User Stories
  • 2. RECORDAR É VIVER! Quando? As avaliações podem ser aplicadas em diversos momentos do ciclo de vida de um produto. Avaliações formativas (ocorrem em cada ciclo de sprint) Avaliações somativas (ocorrem no final do ciclo, ou mesmo depois)
  • 3. RECORDAR É VIVER! Como? No que diz respeito à aplicação, os métodos de avaliação de usabilidade podem ser empíricos ou analíticos Empíricos: • Requer a participação de usuários durante a coleta de dados, que, posteriormente, serão analisados pelo especialista, a fim de identificar os problemas da interface. • É realizado em ambientes controlados, no qual os avaliadores gravam toda a interação em vídeo para posterior análise. Durante a realização do teste, um dos avaliadores vai anotando os incidentes ocorridos durante a interação, além dos comentários do usuário em relação à interface. • Logo após o teste, os usuários respondem a um questionário com perguntas relacionadas à satisfação em relação ao produto e, também, perguntas com sugestões de melhorias.
  • 4. RECORDAR É VIVER! Como? No que diz respeito à aplicação, os métodos de avaliação de usabilidade podem ser empíricos ou analíticos Analíticos: • Também conhecidos como métodos de inspeção, ou de prognóstico, caracterizam-se pelo fato do usuário não participar diretamente das avaliações. • Requer a presença de um especialista, que explorará a interface, a fim de encontrar problemas de usabilidade. • Além da identificação dos problemas, os avaliadores fazem sugestões de correção. • Tem como resultado um relatório formal dos problemas identificados e as sugestões de melhorias.
  • 5. RECORDAR É VIVER! Jakob Nielsen (1993), em seu livro Usability engineering, propõe um conjunto de dez heurísticas de usabilidade: 1. visibilidade e reconhecimento do estado ou contexto atual do sistema; 2. compatibilidade com o mundo real; 3. controle e liberdade do usuário; 4. consistência e padrões; 5. prevenção de erros; 6. reconhecimento ao invés de memorização; 7. flexibilidade e eficiência de uso; 8. projeto estético minimalista; 9. diagnóstico e correção de erros; e 10. ajuda e documentação. As heurísticas, neste caso, são um conjunto de regras e métodos que levam à descoberta e à resolução* de problemas (NIELSEN, 1993). *Leva à resolução, mas não aplica/implementa a resolução dos problemas encontrados.
  • 7. USER STORIES Uma história... Uma estória não é mais do que a descrição de uma pequena funcionalidade que o cliente pretende ver desenvolvida no sistema. O termo em inglês é story (história – conto) e não history (história - relato de fatos);
  • 8. USER STORIES O que são: • Uma breve descrição de uma funcionalidade que foi discutida; • São tradicionalmente escritas em cartões ou post-its; O que não são: • Documentos de implementação (classes, modelagem...); • Imutáveis: Podem sofrer alterações e negociações ao longo do projeto; • Casos de uso: Este último se refere à narrativa de funções de forma impessoal, ou seja, independente do usuário.
  • 9. USER STORIES Características • User Stories focam nos objetivos do usuário e como o sistema alcança esses objetivos. • User Stories fracionam os requisitos para que seja possível (e mais fácil) estimar o esforço para realizar aquele objetivo. Resumindo, User Stories são descrições simples que descrevem uma funcionalidade e é recomendável que sejam escritas segundo o ponto de vista do usuário. • User Stories devem ser curtas, simples e claras. Devemos conseguir escrevê-las em um simples e pequeno cartão (conhecidos como User Index Cards). Se não há espaço para escrevê-la em um cartão é porquê devemos refiná-la mais, e as dividir em outras User Stories. • Stakeholders escrevem User Stories, não os desenvolvedores. User Stories são simples o suficiente para que as pessoas possam aprender a escrevê-las em alguns minutos. © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 10. USER STORIES User Stories Aqui
  • 11. USER STORIES Formato • Os cartões seguem um formato como o descrito abaixo: © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 12. USER STORIES Formato • Os cartões seguem um formato como o descrito abaixo: © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 13. USER STORIES Formato • Ator – O proprietário da User Story. De forma simplista é o usuário, o interessado naquela funcionalidade. Mas é recomendado descrever de forma específica quem é o ator para ser mais fácil identificar o contexto da história dentro do sistema. • Ação – É o que o ator quer fazer. Utilizando aquela ação ele espera alcançar seu objetivo dentro do sistema. • Objetivo/Funcionalidade – É o que o ator espera que aconteça ao realizar a ação. Ou seja, é o resultado de executar a ação segundo a ótica do ator. Também pode ser visto como justificativa. © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 14. USER STORIES Escrevendo boas histórias Independentes: Histórias devem ser independentes uma das outras; (exemplo: usuário pode entrar com o nome do meio, primeiro nome e último nome.) Negociáveis: Histórias não são contratos, mas lembretes para discussões; (por questões de escopo, orçamento ou complexidade, as histórias podem ser removidas ou alteradas.) De valor agregado: Histórias devem agregar valor para o usuário/cliente; (exemplo: dizer que o sistema será feito em PHP e MySQL não é relevante para o usuário/cliente). © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 15. USER STORIES Escrevendo boas histórias Estimáveis: Os desenvolvedores devem ser capazes de estimar o tamanhos das história; (se não puder ser estimada, não será usada no sprint. Se for muito complexa, dividir em histórias menores.) Curtas: histórias grandes dificultam as estimativas. Bem como histórias muito pequenas. Quebre ou agrupe dependendo do caso. (Grandes histórias (épicas) são difíceis de estimar e difíceis de planejar, elas não se encaixam bem em uma única iteração) Testáveis: Histórias devem ser possíveis de serem testadas. (Em vez de: “Não fazer o usuário esperar muito em cada tela”, use: “As telas não deverão demorar mais que 2 segundos para abrir”.) © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 16. USER STORIES Processo: cada cartão uma história 1. Em cada cartão, listar todas as AÇÕES factíveis do usuário no produto Comece sempre com um verbo. Este será o “título” da história. 2. Escreva a história. Seguindo os critérios mostrados anteriormente. Ex.: Eu como JARDINEIRO preciso CAVAR UM BURACO para que eu possa PLANTAR UMA SEMENTE. (Deixe espaço para mais detalhes) 3. Atribua um valor de negócio (ROI) para cada cartão Pode ser: BAIXO, MÉDIO ou ALTO © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 17. USER STORIES Processo: o mapa 1- Organize os cartões horizontalmente em uma sequência lógica de operação tempo © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 18. USER STORIES Processo: o mapa 2- Empilhe os cartões que possuem atividades simultâneas tempo © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 19. USER STORIES Processo: o mapa 3- Ordene verticalmente os cartões em ordem de importância ou criticidade (frequência de uso, ROI, valor do negócio, etc...) Tempo importância © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 20. USER STORIES Processo: o mapa 4- Observe os agrupamentos que se formam e discuta com a equipe. Um conjunto de tarefas, forma uma atividade Tempo importância © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 21. USER STORIES Processo: o primeiro release 4- Discuta e escolha uma das atividades que será implementada primeiro. Peça para a equipe de desenvolvimento estimar a implementação de cada cartão. Essa é uma decisão estratégica! tempo necessário Primeiro release opcional Segundo release importância mais Terceiro release opcional © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 22. HEIN?!?! ?
  • 23. VALEU! ALAN VASCONCELOS – www.alanvasconcelos.com