Usabilidade 4 - User Story Mapping

  • View
    1.203

  • Download
    1

  • Category

    Design

Preview:

DESCRIPTION

Aula para a disciplina Produção e Ferramentas Colaborativas Pós-Graduação em Engenharia de Software Centrada em Métodos Ágeis Prof. Marcello de Campos Cardoso www.mcardoso.com.br Maio 2011

Citation preview

UsabilidadeEngenharia de Software Centrada em Métodos Ágeis

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

aula

4

Saturday, May 21, 2011

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

Saturday, 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

Saturday, May 21, 2011

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

Saturday, May 21, 2011

User Story Mappingslides por Karine Drumond

Saturday, 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

Saturday, 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

Saturday, May 21, 2011

O que é story mapping?

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

desenvolvida por Patton (2005).

Saturday, May 21, 2011

Sprint zero

user story user story

Release 1

Release 2

Release 3

Saturday, May 21, 2011

Lista de backlog

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

Saturday, May 21, 2011

Ao invés de lista, mapa

user story

user story user story

user story

user story

user story

Saturday, May 21, 2011

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;

Saturday, May 21, 2011

Quem deve participar?

A equipe

‣ negócios

‣ marketing

‣ designers

‣ desenvolvedores

‣ cliente

‣ usuários

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

Saturday, May 21, 2011

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

Saturday, May 21, 2011

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

Saturday, May 21, 2011

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

Saturday, May 21, 2011

Passo 1

• Escreva cada item em um cartão diferente

• Deixe espaço para outros detalhes

Fazer pedido ao f

ornecedor

Saturday, May 21, 2011

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

Saturday, May 21, 2011

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)

Saturday, May 21, 2011

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)

Frequência: diárioValor: alto

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

Valor: alto

Devolver e reembolsar

(consultor de vendas)

Frequência: diário

Valor: médio

Saturday, May 21, 2011

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

Saturday, May 21, 2011

sequência de uso

Necessidade

muito usado

raramente usado

Fazer pedido ao fornecedor

(comprador)

Frequência: semanalmente

Valor: médio

Receber pedido do comprador

(controlador de estoque)

Frequência: diário

Valor: alto

Gerar etiqueta para os produtos recebidos

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

Vender produto(consultor de vendas)

Frequência: diárioValor: alto

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

Valor: alto

Devolver e reembolsar

(consultor de vendas)

Frequência: diário

Valor: médio

Saturday, May 21, 2011

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

Saturday, May 21, 2011

compra recebimento

venda

análise

sequência de uso

Necessidade

muito usado

raramente usado

Fazer pedido ao fornecedor

(comprador)

Frequência: semanalmente

Valor: médio

Receber pedido do comprador

(controlador de estoque)

Frequência: diário

Valor: alto

Gerar etiqueta para os produtos recebidos

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

Vender produto(consultor de vendas)

Frequência: diárioValor: alto

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

Valor: alto

Devolver e reembolsar

(consultor de vendas)

Frequência: diário

Valor: médio

Saturday, May 21, 2011

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

Saturday, May 21, 2011

compra recebimento

venda

análise

sequência de uso

Necessidade

muito usado

raramente usado

Fazer pedido ao fornecedor

(comprador)

Frequência: semanalmente

Valor: médio

Receber pedido do comprador

(controlador de estoque)

Frequência: diário

Valor: alto

Gerar etiqueta para os produtos recebidos

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

Vender produto(consultor de vendas)

Frequência: diárioValor: alto

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

Valor: alto

Devolver e reembolsar

(consultor de vendas)

Frequência: diário

Valor: médio

MVP

Saturday, May 21, 2011

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

Saturday, May 21, 2011

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

Saturday, May 21, 2011

Saturday, May 21, 2011

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

Saturday, May 21, 2011

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.

Saturday, May 21, 2011

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)

Saturday, May 21, 2011

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!

Saturday, May 21, 2011