Usabilidade 4 - User Story Mapping

UsabilidadeEngenharia de Software Centrada em Métodos Ágeis

Marcello de Campos Cardoso | www.mcardoso.com.br | [email protected]

aula

4

Saturday, May 21, 2011

http://edgarddavidson.com/?p=365

http://edgarddavidson.com/?p=365

http://www.mcardoso.com.br

http://www.mcardoso.com.br

mailto:[email protected]

mailto:[email protected]

Recapitulando...

Personas ágeisTécnica colaborativa para a definição de modelos de usuários do sistema, no intuito de melhorar a

visibilidade, compreensão e comunicação sobre seu comportamento de uso.

Auxilia no levantamento de user stories.

sequência de usoSaturday, May 21, 2011

Recapitulando...

Backlog do produto

Backlog do sprint

Reunião diária

Produto potencialmente

“entregável”

Personas ágeisLevantamento de:

requisitos,funcionalidades,

user stories


Recapitulando...

Backlog do produto

Backlog do sprint

Reunião diária


“entregável”



user stories


Plano de curso

Introdução a Usabilidade: conceitos, origem (DCU, IHC), aplicação (IxD), metas de usabilidade, princípios de design, estudo de casos, benefícios, ciclos de vida de desenvolvimento (cascata x ágil), técnicas (overview).

Técnica de Modelagem: Personas ágeis (workshop)

Story Mapping (workshop)

Perguntando a especialistas:Análise Heurística, As 10 heurísticas de Nielsen (workshop)

Projetando a interface:Task Flow + Prototipação rápida (workshop)

Testes de usabilidade (workshop - roteiro)

Testes de usabilidade (workshop - aplicação)

1ª aula2ª aula

3ª aula

4ª aula

5ª aula

6ª aula

7ª aula

8ª aula


User Story Mappingslides por Karine Drumond


Recapitulando...

Backlog do produto

Backlog do sprint

Reunião diária


“entregável”



user stories


Recapitulando...

Backlog do produto

Backlog do sprint

Reunião diária


“entregável”



user stories


O que é story mapping?

Técnica colaborativa, que auxilia na priorização e planejamento de releases de produtos interativos.

desenvolvida por Patton (2005).


Sprint zero

user story user story

Release 1

Release 2

Release 3


Lista de backlog

Exemplo de uma lista de backlog.Fonte: http://www.it-zynergy.dk/Scrum-Overview-Of-Process.aspx


http://www.it-zynergy.dk/Scrum-Overview-Of-Process.aspx

http://www.it-zynergy.dk/Scrum-Overview-Of-Process.aspx

Ao invés de lista, mapa

user story

user story user story

user story

user story

user story


Por que mapa e não lista?

‣Dificuldade de comunicar a visão do "todo"

‣Risco de faltar funcionalidades importantes para os usuários realizarem uma tarefa de forma plena;


Quem deve participar?

A equipe

‣ negócios

‣ marketing

‣ designers

‣ desenvolvedores

‣ cliente

‣ usuários

fonte: http://www.selfishprogramming.com/2008/10/


http://www.selfishprogramming.com/2008/10/

http://www.selfishprogramming.com/2008/10/

Etapas

1. Criar cartões de estórias

2. Ordenar em fluxo de tarefas

3. Ajustar posição quanto à criticidade

4. Marcar o primeiro release


Passo 1

• Identificar as possíveis user stories do seu sistema.

• Pense “O que as pessoas podem fazer no meu sistema?”

• Cada item deve começar com um verbo, mantenha ponto de vista do usuário, NÃO DO SISTEMA

• Esqueça detalhes de implementação, mantenha o foco nas tarefas


Passo 1

• Ex.: software de controle de vendas• Fazer pedido ao fornecedor

• Receber pedido do fornecedor

• Gerar etiquetas para itens recebidos

• Vender produtos

• Devolver e reembolsar produtos

• Analisar vendas


Passo 1

• Escreva cada item em um cartão diferente

• Deixe espaço para outros detalhes

Fazer pedido ao f

ornecedor


Passo 2• Adicione detalhes importantes:

• Usuários (profissão, cargo, papel desempenhado)

• Frequência de uso (muito, pouco, raro ou diariamente, semanalmente etc.)

• Valor (valor para o negócio. ROI: baixo, médio ou alto)

Fazer pedido ao fornecedor

(comprador)

Frequência: semanalmente

Valor: médio

compradorcontrolador de estoqueconsultor de vendaanalista de venda


Passo 3

• Ordene as cartas em uma sequência lógica de tarefas

• O objetivo é contar uma história de como o sistema funciona

• Sobreponha os cartões que aconteçam no mesmo tempo (este OU este)


sequência de uso

Necessidade

muito usado

raramente usado

Fazer pedido ao fornecedor(comprador)

Frequência: semanalmenteValor: médio

Receber pedido do comprador(controlador de estoque)

Frequência: diárioValor: alto

Gerar etiqueta para os produtos recebidos

(controlador de estoque)Frequência: diárioValor: médio

Vender produto(consultor de vendas)


Analisar vendas(analista de vendas)Frequência: mensal

Valor: alto

Devolver e reembolsar

(consultor de vendas)

Frequência: diário

Valor: médio


Passo 4

• Ajustar conforme criticidade (verticalmente)• Coloque acima as cartas mais importantes: alta frequência e alto valor.

• Discuta com a equipe o quão crítico cada funcionalidade é para o negócio


sequência de uso

Necessidade

muito usado

raramente usado


(comprador)


Valor: médio

Receber pedido do comprador

(controlador de estoque)


Valor: alto






Valor: alto




Valor: médio


Passo 5

• Dê nome aos conjuntos de tarefas• Discuta onde há quebras no modelo

• Pode ser uma mudança de usuário, regras de negócio ou processo

• Divida verticalmente as quebras e dê um nome


compra recebimento

venda

análise

sequência de uso

Necessidade

muito usado

raramente usado


(comprador)


Valor: médio




Valor: alto






Valor: alto




Valor: médio


Passo 6

• Marcar primeiro release (MVP)

• Deve ser o menor número de funcionalidades úteis para os usuários e o contexto do negócio

• É o primeiro release mas não necessariamente o primeiro a ser público


compra recebimento

venda

análise

sequência de uso

Necessidade

muito usado

raramente usado


(comprador)


Valor: médio




Valor: alto






Valor: alto




Valor: médio

MVP


Passo 7

• Estime o tempo de desenvolvimento• Peça a equipe de desenvolvimento que estime o tempo para cada

cartão (em dias, horas, semanas etc.)


Passo 8

• Reparta o bolo: programe outros releases• No final você poderá ver quantos releases serão necessários e quais

funcionalidades conterá em cada um



Exercício

1. Listar funcionalidades

2. Escrever em cartões

3. Ordenar em fluxo de tarefas

4. Ajustar posição quanto à criticidade

5. Agrupar por atividades macros

6. Marcar o primeiro release


Desafios e Recomendações1. Como escrever as user story? (“Busca” “Digitar palavra” ou “Encontrar produtos”?)

Não usar termos técnicos para descrever as estórias. Qual o objetivo do usuário? Usar “Eu como [usuário] preciso de...”

2. Frequência de uso de cada estória. (a frequência pode variar em grupos de usuários e pode haver falta de conhecimento real sobre a atividade dos usuários)

Observações, entrevistas contextuais e testes de usabilidade.

3. Definir valor para negócio. Participação do dono do produto, equipe multidisciplinar.

4. Os requisitos, as ideias mudam.

Repriorização, ciclo de vida iterativos de design, reuniões diárias.


Benefícios

• Visão compartilhada do sistema -“Visão do todo”

• Facilita comunicação e colaboração da equipe

• Faz a ponte entre o DCU e desenvolvimento ágil

• Evita desenvolvimento de funcionalidades em excesso (feature creep)


Este arquivo contém a apresentação realizada por Marcello de Campos Cardoso, em novembro de 2010, para a disciplina Engenharia de Usabilidade ministrada no curso de especialização Engenharia de Software Centrada em Métodos Ágeis, no Centro Universitário UNA.

obrigado!


Design

Usabilidade 4 - User Story Mapping