ALAN VASCONCELOSDESIGN DE INTERAÇÃO/ USABILIDADEProcessos /User Stories
RECORDAR É VIVER!Quando?As avaliações podem ser aplicadas em diversos momentos do ciclo de vida de um produto.  Avaliações...
RECORDAR É VIVER!Como?No que diz respeito à aplicação, os métodos de avaliação de usabilidade podem serempíricos ou analít...
RECORDAR É VIVER!Como?No que diz respeito à aplicação, os métodos de avaliação de usabilidade podem serempíricos ou analít...
RECORDAR É VIVER!Jakob Nielsen (1993), em seu livro Usability engineering, propõe um conjunto de dezheurísticas de usabili...
USER STORIES
USER STORIESUma história...Uma estória não é mais do que a descrição de uma pequenafuncionalidade que o cliente pretende v...
USER STORIESO que são:• Uma breve descrição de uma funcionalidade que foi  discutida;• São tradicionalmente escritas em ca...
USER STORIESCaracterísticas•   User Stories focam nos objetivos do usuário e como o sistema alcança    esses objetivos.•  ...
USER STORIES  User Stories Aqui
USER STORIESFormato•   Os cartões seguem um formato como o descrito abaixo:© Jeff Patton, all rights reserved, www.AgilePr...
USER STORIESFormato•   Os cartões seguem um formato como o descrito abaixo:© Jeff Patton, all rights reserved, www.AgilePr...
USER STORIESFormato• Ator – O proprietário da User Story. De forma    simplista é o usuário, o interessado naquela    func...
USER STORIESEscrevendo boas históriasIndependentes: Histórias devem ser independentes uma das outras;(exemplo: usuário pod...
USER STORIESEscrevendo boas históriasEstimáveis: Os desenvolvedores devem ser capazes de estimar o tamanhos das história;(...
USER STORIESProcesso: cada cartão uma história1. Em cada cartão, listar todas as AÇÕES factíveis do usuário no   produto  ...
USER STORIESProcesso: o mapa1- Organize os cartões horizontalmente em uma sequência lógica de operação                    ...
USER STORIESProcesso: o mapa2- Empilhe os cartões que possuem atividades simultâneas                                      ...
USER STORIESProcesso: o mapa3- Ordene verticalmente os cartões em ordem de importância ou criticidade(frequência de uso, R...
USER STORIESProcesso: o mapa4- Observe os agrupamentos que se formam e discuta com a equipe.Um conjunto de tarefas, forma ...
USER STORIESProcesso: o primeiro release4- Discuta e escolha uma das atividades que será implementada primeiro.Peça para a...
HEIN?!?!           ?
VALEU!ALAN VASCONCELOS – www.alanvasconcelos.com
Upcoming SlideShare
Loading in …5
×

Usabilidade Aula-06. Processos: User Stories

750 views
685 views

Published on

Published in: Design
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
750
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
36
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Usabilidade Aula-06. Processos: User Stories

  1. 1. ALAN VASCONCELOSDESIGN DE INTERAÇÃO/ USABILIDADEProcessos /User Stories
  2. 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. 3. RECORDAR É VIVER!Como?No que diz respeito à aplicação, os métodos de avaliação de usabilidade podem serempíricos ou analíticosEmpí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. 4. RECORDAR É VIVER!Como?No que diz respeito à aplicação, os métodos de avaliação de usabilidade podem serempíricos ou analíticosAnalí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. 5. RECORDAR É VIVER!Jakob Nielsen (1993), em seu livro Usability engineering, propõe um conjunto de dezheurí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; e10. ajuda e documentação.As heurísticas, neste caso, são um conjunto de regras e métodosque levam à descoberta e à resolução* de problemas (NIELSEN, 1993).*Leva à resolução, mas não aplica/implementa a resolução dos problemas encontrados.
  6. 6. USER STORIES
  7. 7. USER STORIESUma história...Uma estória não é mais do que a descrição de uma pequenafuncionalidade que o cliente pretende ver desenvolvida nosistema.O termo em inglês é story (história – conto) e não history(história - relato de fatos);
  8. 8. USER STORIESO 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. 9. USER STORIESCaracterí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. 10. USER STORIES User Stories Aqui
  11. 11. USER STORIESFormato• Os cartões seguem um formato como o descrito abaixo:© Jeff Patton, all rights reserved, www.AgileProductDesign.com
  12. 12. USER STORIESFormato• Os cartões seguem um formato como o descrito abaixo:© Jeff Patton, all rights reserved, www.AgileProductDesign.com
  13. 13. USER STORIESFormato• 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. 14. USER STORIESEscrevendo boas históriasIndependentes: 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. 15. USER STORIESEscrevendo boas históriasEstimá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óriasmenores.)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 emuma ú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. 16. USER STORIESProcesso: cada cartão uma história1. 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. 17. USER STORIESProcesso: o mapa1- Organize os cartões horizontalmente em uma sequência lógica de operação tempo© Jeff Patton, all rights reserved, www.AgileProductDesign.com
  18. 18. USER STORIESProcesso: o mapa2- Empilhe os cartões que possuem atividades simultâneas tempo© Jeff Patton, all rights reserved, www.AgileProductDesign.com
  19. 19. USER STORIESProcesso: o mapa3- Ordene verticalmente os cartões em ordem de importância ou criticidade(frequência de uso, ROI, valor do negócio, etc...) Tempoimportância© Jeff Patton, all rights reserved, www.AgileProductDesign.com
  20. 20. USER STORIESProcesso: o mapa4- Observe os agrupamentos que se formam e discuta com a equipe.Um conjunto de tarefas, forma uma atividade Tempoimportância© Jeff Patton, all rights reserved, www.AgileProductDesign.com
  21. 21. USER STORIESProcesso: o primeiro release4- 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! temponecessário Primeiro release opcional Segundo release importância mais Terceiro release opcional © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  22. 22. HEIN?!?! ?
  23. 23. VALEU!ALAN VASCONCELOS – www.alanvasconcelos.com

×