UNA - Eng Usa '12 - aula 03

Engenharia de Usabilidade / Marcello Cardoso

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

Engenharia de Software Centrada Em Métodos Ágeis

Fatiando releases com

User Story Mapping

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 ágeis

Técnica 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.

Nome, Idade Papel

descrição, frase

emblemática

Tarefas no sistema

para necessidades

Necessidades no

mundo real


1o passo: Determinar tipos de usuários

2o passo: Listar características de cada tipo

3o passo: Determinar usuários focais

Personas ágeis


Plano de curso

1ª

2ª

3ª

4ª

5ª

Introdução à EngUsa

Técnica de Modelagem: Personas ágeis

Fatiando releases com User Story Mapping

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

Perguntando a especialistas: As 10 heurísticas de Nielsen

10pts

20pts

20pts

25pts

25pts


User Story Mapping

pesquisa

planejamento

desenvolvimento

validação


Ciclo de vida do produto

personas

Benchmarking

Story

mapping

Etnografia digital


Onde aplicar?

Backlog do produto

Backlog do sprint

Reunião diária

Produto

potencialmente

“entregável”

definição do backlog


Técnica colaborativa, que auxilia

na priorização e planejamento

de releases (lançamentos) de

produtos interativos.

(desenvolvida por Jeff Patton em 2005)

O que é User Story mapping?


Priorizando durante o planejamento

user story

user st

ory

user story

user story

user st

ory

user story

user st

oryuser storyuser story

user story

user storyuser storyuser story

user st


user story

user storyuser storyuser story

release

1

(MVP)

release 2

release 3


Priorizando durante o planejamento

user story

user st

ory

user story

user st


user story

user storyuser story

user story user story

user story

user story

user story


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

‣ Risco de faltar funcionalidades importantes

para os usuários realizarem uma tarefa

de forma plena;

Por que mapa e não lista?


A equipe

•negócios

•marketing

• designers

• desenvolvedores

• cliente

• usuários

• etc


1. Criar cartões de estórias

2. Ordenar em fluxo de tarefas

3. Ajustar posição quanto à criticidade

4. Marcar o primeiro release

Etapas


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 pedid

o ao forne

cedor


comprador interno

controlador de estoque

consultor de venda

analista de venda

Fazer pedid

o ao forne

cedor

(comprador int

erno)

Frequência:

semanalm

ente

Valor: médio

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)

Passo 2


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)


Analisar vendas

(analista de vendas)

Frequência: mensal

Valor: alto

sequência de uso

Necessidade

mais usado

raramente usado

Fazer pedid

o ao forne

cedor

(comprador inte

rno)

Frequência:

semanalmente

Valor: médio

Receber pedido do

fornecedor

(comprador interno)Frequência: diário

Fazer pedido ao comprador

(controlador de estoque)

Frequência: semanalmente

Valor: médio

Vender prod

uto

(vendedor)

Frequência: d

iário

Valor: alto

Devolver e

reembolsar

(vendedor)

Frequência: d

iá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

mais usado

raramente usado

Analisar vendas


Frequência: mensal

Valor: alto

Fazer pedid

o ao forne

cedor

(comprador inte

rno)

Frequência:

semanalmente

Valor: médio

Receber pedido do

fornecedor





Valor: médio

Vender prod

uto

(vendedor)

Frequência: d

iário

Valor: alto

Devolver e reembolsar

(vendedor)

Frequência: diário

Valor: médio


Passo 5

Divida e 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


sequência de uso

Necessidade

mais usado

raramente usado

compra

recebim

ento

venda

análise

Analisar vendas


Frequência: mensal

Valor: alto

Fazer pedid

o ao forne

cedor

(comprador inte

rno)

Frequência:

semanalmente

Valor: médio

Receber pedido do

fornecedor





Valor: médio

Vender prod

uto

(vendedor)

Frequência: d

iário

Valor: alto


(vendedor)


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


sequência de uso

Necessidade

mais usado

raramente usado

compra

recebim

ento

venda

análise

1º RELEASEMVP

Analisar vendas


Frequência: mensal

Valor: alto

Fazer pedid

o ao forne

cedor

(comprador inte

rno)

Frequência:

semanalmente

Valor: médio

Receber pedido do

fornecedor





Valor: médio

Vender prod

uto

(vendedor)

Frequência: d

iário

Valor: alto


(vendedor)


Valor: médio


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

Desafios e Recomendações


EM GRUPO!

Fazer um User

Story Map

Backlog

para seu pro

duto.

Enviar apres

entação pa

ra email at

é

a próxima aula

com “UNA USA

USM”

no subject.

Não esquece

r nome dos

integrantes

!

TO DO DONE


Este arquivo contém a apresentação realizada por Marcello de Campos

Cardoso, em Agosto de 2012, 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.

obrigad

o!

UNA - Eng Usa '12 - aula 03

Design

Transcript of UNA - Eng Usa '12 - aula 03