Your SlideShare is downloading. ×
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Usabilidade Aula-06. Processos: User Stories
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Usabilidade Aula-06. Processos: User Stories

585

Published on

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

No Downloads
Views
Total Views
585
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
32
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ALAN VASCONCELOSDESIGN DE INTERAÇÃO/ USABILIDADEProcessos /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 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. 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. 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. USER STORIES
  • 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. 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. 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. USER STORIES User Stories Aqui
  • 11. USER STORIESFormato• Os cartões seguem um formato como o descrito abaixo:© Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 12. USER STORIESFormato• Os cartões seguem um formato como o descrito abaixo:© Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 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. 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. 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. 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. 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. USER STORIESProcesso: o mapa2- Empilhe os cartões que possuem atividades simultâneas tempo© Jeff Patton, all rights reserved, www.AgileProductDesign.com
  • 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. 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. 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. HEIN?!?! ?
  • 23. VALEU!ALAN VASCONCELOS – www.alanvasconcelos.com

×