Story Mapping para Planejamento de Releases

aula 4
Engenharia de Software Centrada em Métodos Ágeis

Usabilidade
Marcello de Campos Cardoso | www.mcardoso.com.br | mcardoso@gmail.com

Saturday, May 21, 2011

Recapitulando...

Personas ágeis
Té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.

Saturday, May 21, 2011 sequência de uso

Recapitulando...

Levantamento de:

requisitos,
Personas ágeis
funcionalidades,
user stories
Reunião diária

Produto
Backlog do Backlog do potencialmente
produto sprint “entregável”


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

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

4ª aula Story Mapping (workshop)

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

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

7ª aula Testes de usabilidade (workshop - roteiro)

8ª aula Testes de usabilidade (workshop - aplicação)


User Story Mapping slides por Karine Drumond

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
Release 3

Release 2

Release 1

user story user story


Lista de backlog

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


Ao invés de lista, mapa



user story
user story


Por que mapa e
não lista?
‣ Dificuldade de comunicar a visão do
"todo"
‣ Riscode 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.selﬁshprogramming.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

r
necedo
ao for
pedido
Fazer


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)

o rnecedor
Fazer pe dido ao f comprador

(co mprador) controlador de estoque
n almente
cia: sema
consultor de venda
Frequên
lor: médio
analista de venda
Va


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)


muito usado

Gerar etiqueta para os
Fazer pedido ao fornecedor Receber pedido do comprador Vender produto Analisar vendas
produtos recebidos
(comprador) (controlador de estoque) (consultor de vendas) (analista de vendas)
(controlador de estoque)
Frequência: semanalmente Frequência: diário Frequência: diário Frequência: mensal
Frequência: diário
Valor: médio Valor: alto Valor: alto Valor: alto
Valor: médio

reembolsar
Devolver e
(consultor de vendas)
diário
Necessidade

Frequência:
Valor: médio

raramente usado

sequência de uso


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


muito usado

mprador
Receber pedido do co Vender produto
de estoque) (consultor de vendas)
(controlador
iário
Frequência: d Frequência: diário
Valor: alto Valor: alto

rnecedor bolsar Analisar vendas
pedido ao fo Devo lver e reem
Fazer produtos recebidos
endas) (analista de vendas)
(comprador) (consultor de v
Necessidade

almente diário Frequência: mensal
Frequ ência: seman Frequência:
Valor: médio Valor: médio Valor: alto
Valor: médio

raramente usado

sequência de uso


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


muito usado
venda

compra mprador
recebimento análise
(controlador
iário

Necessidade

Valor: médio

raramente usado

sequência de uso


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


muito usado
venda

compra mprador
recebimento análise
(controlador
iário

MVP

Necessidade

Valor: médio

raramente usado

sequência de uso


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ções
1. Como escrever as user story? Não usar termos técnicos para descrever
(“Busca” “Digitar palavra” ou “Encontrar as estórias. Qual o objetivo do usuário?
produtos”?) Usar “Eu como [usuário] preciso de...”

2. Frequência de uso de cada
estória. (a frequência pode variar em Observações, entrevistas contextuais e
grupos de usuários e pode haver falta de testes de usabilidade.
conhecimento real sobre a atividade dos
usuários)

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

4. Os requisitos, as ideias Repriorização, ciclo de vida iterativos de
mudam. 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)


obrigado!

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.


Story Mapping para Planejamento de Releases

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (8)

Ähnlich wie Story Mapping para Planejamento de Releases

Ähnlich wie Story Mapping para Planejamento de Releases (20)

Mehr von Marcello Cardoso

Mehr von Marcello Cardoso (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

Story Mapping para Planejamento de Releases