usabilidade aula-06. processos: user stories

DESIGN DE INTERAÇÃO / USABILIDADE Processos / User Stories

ALAN VASCONCELOS

RECORDAR É VIVER!

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

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

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

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; e10. 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:


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.


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).


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”.)


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 produtoComece 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ãoPode ser: BAIXO, MÉDIO ou ALTO


USER STORIES

Processo: o mapa

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


tempo

USER STORIES

Processo: o mapa

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


tempo

USER STORIES

Processo: o mapa3- Ordene verticalmente os cartões em ordem de importância ou criticidade (frequência de uso, ROI, valor do negócio, etc...)


Tempo

impo

rtân

cia

USER STORIES

Processo: o mapa4- Observe os agrupamentos que se formam e discuta com a equipe.Um conjunto de tarefas, forma uma atividade


Tempo

impo

rtân

cia

USER STORIES

Processo: 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!


tempo

impo

rtân

cia

necessário

opcional

maisopcional

Primeiro release

Segundo release

Terceiro release

HEIN?!?!

?

VALEU!

ALAN VASCONCELOS – www.alanvasconcelos.com