rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Versão 5
Escrevendo
Estórias do
Usuário
Eficazes
Rildo F Santos
rildo.santos@etecnologia.com.br
@rildosan
http://rildosan.blogspot.com/
(11) 9123-5358
(11) 9962-4260
www.etcnologia.com.br
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 2
Programa: “Menos Papel, Mais Árvores ®”
Qual é o mundo que queremos ?
O primeiro passo para criar um mundo melhor, é saber qual tipo de mundo que queremos
ter e qual tipo que deixaremos de herança para as próximas gerações.
Nossa missão: É buscar pelo equilibro: do homem, tecnologia e meio ambiente, isto é o
que queremos.
Para cumprir esta missão é necessário; conscientizar, comprometer e AGIR.
O programa Menos Papel, Mais Árvores®, é uma ação, com objetivo de
estimular o consumo sustentável de papel dentro das organizações.
Quer participar ?
- Reduza o uso de papel (e de madeira) o máximo possível.
- Só imprima se for extremamente necessário.
- Evite comprar produtos com excesso de embalagem.
- Ao imprimir ou escrever, utilize os dois lados do papel.
- Use papel reciclado.
Este material não deve ser impresso..
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 3
Facilitador: Rildo F. Santos (@rildosan)
Coach, Consultor, Instrutor e Palestrante de Negócio, Processos, Inovação, Sustentabilidade e Tecnologia.
Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de
Software. Formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia
de Software pela Universidade Macaense.
Fui instrutor de Tecnologia de Orientação a Objetos, IML e Linguagem Java na Sun Necrosastes e na IBM.
Conheço Métodos Ágeis (SCRUM, Lean, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço),
OpenUP, Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.
Possuo conhecimento de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e
GRC - Governance, Risk ando Compliance), SOX, Basel II e PCI;
E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais
frameworks e padrões: ITIL, Cobit, ISO 27001 e ISO 15999;
Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software,
Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde,
Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.
Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified
Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;
Sou membro do IIBA-International Institute of Business Analysis (Canada)
Onde me encontrar:
Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Comunidade: http://etecnologia.ning.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 4
1 – Problemas de Comunicação
2 – Estória do Usuário
3 – Boas Práticas
4 – Ferramentas e técnicas
O Conteúdo:
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 5
Comentário inicial:
Objetivo:
Esta apresentação tem como objetivo discutir sobre a Estória do Usuário e suas técnicas
para que elas se tornem eficazes.
A estória do usuário é forma de facilitar a comunicação e entendimento entre o cliente de
negócio (PO) e a equipe Scrum (Desenvolvedores).
Uma estória do usuário eficaz é aquela que ajuda no entendimento daquilo que deve ser
feito.
Pré-requisito:
A ênfase deste curso é para SCRUM e XP. Logo , conhecer Scrum é um pre-requisito.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 6
Objetivo desta parte:
1
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 7
Problemas de Comunicação
Uma questão essencial nos projetos de desenvolvimento de software é a maneira pela qual
os clientes dizem para os desenvolvedores o que eles esperam que seja feito.
Cenas comuns:
1ª. Cena: O cliente não sabe exatamente o que ele quer.
2ª. Cena: Os desenvolvedores apresentam para o cliente o que fizeram e o cliente diz que
não era bem aquilo o que ele queria.
3ª. Cena: Depois que o software é entregue, é comum que o cliente tem novas ideias de
coisas a serem feitas ou alteradas.
Se você já participou em uma destas cenas...com certeza, isto é decorrente de problemas
de comunicação e falta de entendimento.
Para evitar essas situações, muitas pessoas fazem especificações de requisitos de
software antes de se começar o desenvolvimento. Nesses casos, a especificação deve ter
todos os detalhes que os desenvolvedores precisam saber antes de começarem a
trabalhar.
Contudo, a especificação de requisitos de software, não é garantia de sucesso, pois,
geralmente os requisitos especificados sofrem mudanças e é muito difícil e dispendioso
colocar todas as características de um software no papel com clareza e exatidão.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 8
Problemas de Comunicação
Falhas na comunicação são uma eterna fonte de problemas
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 9
Requisitos são responsáveis por 37% das falhas dos projetos de
desenvolvimento de software:
Informação
errada
13%
Requisitos
incompletos
12%
Mudança de
Requisitos
12%
Falta de
conhecimento
técnico
7%
Falta de
competência
Outros
50%
37% das falhas estão
relacionadas com
requisitos
Problemas de Comunicação
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 10
Introdução: Problemas de Comunicação
Cliente: Tem dificuldade para externar suas necessidades
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 11
Cliente x Desenvolvedores:
Clientes:
- Alguns clientes têm dificuldades em externar
suas necessidades ou desejos de forma clara e objetiva
(Não sabem o que querem)
- Geralmente fazem mudanças de requisitos durante o
desenvolvimento ou quando o software é entregue.
- Sempre precisam do software funcionando para ontem
- Não têm tempo e nem paciência para falar com os
desenvolvedores.
Desenvolvedores:
- Não sabem ou não querem conversar com o cliente
- Dificilmente conseguem atender o negócio e todas suas
demandas
- Têm dificuldade em se comunicar e entender os clientes
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Boas Práticas de Comunicação:
- Ter uma linguagem comum
- Ter simplicidade
- Ser objetiva
- Usar diversas técnicas para melhorar a comunicação e o entendimento
- Dar preferência a comunicação face-a-face (exemplos: XP exploram bastante isto)
Objetivo da boa comunicação:
Facilitar o entendimento
12
Como melhorar a comunicação ?
Se levarmos em consideração somente o lado técnico, a linguagem será técnica, o que
dificultará o entendimento de quem não é técnico.
Se a linguagem é de negócio, na maioria das vezes o desenvolvedor tem dificuldades em
entender o negócio e suas demandas.
Qual é a solução ?
O ideal é chegar em ponto de equilíbrio, definir uma linguagem comum, que facilite o
entendimento e a comunicação entre o pessoal de negócio e os desenvolvedores.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 13
O que fazer ?
Manifesto Ágil dá algumas dicas:
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 14
O que fazer ?
Princípios por trás do Manifesto Ágil:
A prioridade é satisfazer o cliente, entregando o mais rápido possível e de forma contínua, software que tenha
valor;
Requisitos mutantes são bem vindos, mesmo no final do desenvolvimento. Os processos ágeis podem ser usados a
favor de mudanças que tragam vantagem competitiva para o cliente;
É importante entregar software funcionando freqüentemente, mensalmente, quinzenalmente ou, se possível, toda
semana;
Clientes e desenvolvedores devem trabalhar juntos diariamente num projeto;
Projetos devem ser feitos por indivíduos motivados. Os indivíduos precisam da confiança de que seu trabalho será
realizado. Eles devem ter suas necessidades atendidas e trabalhar num ambiente adequado;
Conversa face-a-face é SEMPRE a melhor forma de comunicação;
Software funcionando é a primeira medida de progresso;
O processo ágil torna o desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários devem manter a paz
indefinidamente;
Atenção constante à excelência técnica e bom design aumenta a agilidade;
A chave é SIMPLICIDADE: a arte de minimizar a quantidade de trabalho desnecessário;
As melhores arquiteturas, requisitos e design surgem de equipes auto-organizadas;
Em intervalos regulares, a equipe reflete como se tornar mais eficiente. Então ajusta seu comportamento para atingir
esse objetivo.
Manifesto Ágil dá algumas dicas:
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 15
Se trabalhamos com desenvolvimento Ágil:
Logo temos:
Colaboração com cliente:
A estória do Usuário é escrita em colaboração entre os desenvolvedores e o cliente (PO).
A prioridade é satisfazer o cliente, entregando o mais rápido possível e de forma contínua software que
tenha valor:
Para satisfazer o cliente é preciso entendê-lo. A estória ajuda a melhorar o entendimento da necessidade do
cliente para que ocorra a entrega de valor.
- Conversa face-a-face é SEMPRE a melhor forma de comunicação:
A estória do usuário geralmente é feita na Reunião de Planejamento (Planning Meeting).
Titulo: Pagamento com Cartão de Crédito Prioridade: Alta
Como cliente de negócio eu gostaria de fazer pagamento com Cartão
de Crédito para minha comodidade.
Pontos: 5
A Estória de Usuário é uma “ferramenta” simples que pode ajudar. Uma Estória de Usuário nada mais
é que um cartão com algumas frases, escrita pelo cliente e desenvolveres em linguagem comum,
sobre algo que o software deve fazer.
Aqui entra a Estória do Usuário:
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 16
Objetivo desta parte:
2
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 17
O que é Estória do Usuário ?
É uma pequena descrição, que detalha um item do Product Backlog.
Para que serve a Estória do Usuário ?
Uma estória ajuda no entendimento do que deve ser feito, ela permite fazer
a estimativa de velocidade da equipe e também é, utilizada como lembrete e
para as atividades de planejamento. Geralmente a estimativa é feita em
pontos (pontos de estória) ou dias ideais. (dias ideais).
Como escrever uma Estória do Usuário ?
Conversações sobre a estória, entre os usuários e desenvolvedores, de
modo a detalhar o item do Product Backlog e esclarecer todas as dúvidas
sobre do que deve ser feito.
Boa Prática:
- A Estória do Usuário deve prover o entendimento do que deve ser feito.
- Deve facilitar a estimativa de velocidade da equipe.
Diferenças entre a Estória do Usuários e Especificações de Requisitos Tradicionais:
Um dos maiores mal-entendidos com as Estórias do Usuário é como elas diferem das especificações de
requisitos tradicionais. A maior diferença está no nível de detalhe.
Estória do Usuários só devem fornecer detalhes suficientes para “chegar” no entendimento do que deve
ser feito e facilitar a estimativa de velocidade da equipe.
Outra diferença fundamental entre as estórias e as especificações de requisitos é o foco.
Quando escrevemos uma Estória o foco é nas necessidades do usuário, devemos evitar os detalhes
técnicos, tais como descrição de tecnologia, desenho das interfaces do usuário, wireframes, modelo de
dados, algoritmos e etc.
Boa Prática:
- Mantenha a Estória focada nas necessidades do usuário e nos benefícios.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 18
Diferença entre a do Estória do Usuário e Casos de Uso:
Uma Estória do Usuário descreve um detalhamento
de alto nível de uma funcionalidade e/ou de um
item do Product Backlog. E facilita na estimava da
velocidade da esquie
Fazer Reserva
O Caso de Uso especificam a interação entre o
Usuário e o Sistema.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 19
Um “modelo” para a escrita de Estórias do Usuário:
Como <papel/função> eu quero <objetivo/meta> para que <alguma razão/benefício>
Como cliente de negócio, eu quero sacar dinheiro em qualquer caixa
eletrônico para que não tenha que ir na agência bancária.
Como paciente, eu quero fazer agendar minha consulta médica pela
web para que não tenha que usar o telefone.
Boa Prática:
- Cada Estória do Usuário deve ser um texto escrito com aproximadamente 3 sentenças
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
20
Framework SCRUM:
Artefatos
Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
Sprint
(2-4 Semanas)
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Visão
Reuniões
Sprint Burndown
Release Burndown
Product
Backlog
Legenda:
• Product Owner (PO)
• ScrumMaster (SM)
• Equipe Scrum
• Product Backlog
• Sprint Backlog
• Sprint Burndown
• Release Burndown
Papéis
Eventos (Reuniões)
Artefatos
O Framework SCRUM é composto por Regras, Equipe SCRUM e os Eventos de duração fixa (time-
box), Artefatos e a Definição de Pronto.
 Planejamento da Release
 Planejamento da Sprint
 Diária
 Revisão da Sprint
 Retrospectiva da Sprint
Na reunião de Planejamento
da Sprint as Estórias do Usuário
podem ser escritas e
estimadas
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 21
Os 3 “C”s de uma Estória do Usuário:
Cartão
Conversa
Confirmação
Estória do Usuário são tradicionalmente escritas em um cartão.
Cartão podem ter notas, estimativas, observações, comentários e etc
Detalhes que podem surgir durante as conversas com PO (Product
Owner) e/ou cliente.
Testes de aceitação “confirmam” se a Estória do Usuário foi codificada
da forma correta. Testes de aceitação são tipo Caixa Preta.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 22
Cartão:
Como cliente de negócio, eu quero fazer reserva de um apartamento
Como cliente de negócio, eu quero cancelar a reserva de um
apartamento
Como cliente de negócio, eu quero ver fotos dos apartamentos do hotel.
Exemplos de Estórias do Usuário para site de um Hotel:
Um modelo:
Como <papel/função> eu quero <objetivo/meta> para que <alguma razão/benefício>
Cartão
As Estórias do Usuário devem ser escrita em cartão:
Exemplo:
de Cartão
Para escrever as Estórias do Usuário podemos comprar os cartões de papel ou utilizar um software. (O
software somente recomendado quando parte da equipe está fisicamente em outro local).
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 23
Exemplos de Estórias do Usuário:
Como cliente de negócio, eu quero ver as promoções de passagens áreas
Como cliente de negócio, eu quero comprar uma passagem área (TKT)
Como cliente de negócio, eu quero pagar com meu cartão de crédito
corporativo o valor das passagens áreas
Como cliente de negócio, eu quero escolher o assento que melhor me
convier.
Exemplos de Estórias do Usuário para site de uma empresa Aérea
Como cliente de negócio, eu posso realizar pelo meu smartphone o
check-in para otimizar meu embarque.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 24
Cartão:
Exemplos de Estórias do Usuário para Portal de Educação: Cartão
Boa Prática:
- Use cartão padrão (9 x 15 cm) para escrever as Estórias do Usuário. Esta tamanho de cartão ajuda a
manter a Estória pequena e objetiva.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 25
Conversa:
Como cliente,
eu quero fazer
o acompanhamento
dos meus pedidos...
PO (Product Owner) Equipe
O que você
quer (necessita)?
Como cliente, eu quero fazer acompanhamento dos meus pedidos para
que possa planejar o recebimento dos pedidos.
Cartão:
Conversa
No SCRUM as conversas geralmente acontecem na Reunião de Planejamento da
Sprint (Planning Meeting) e também durante o desenvolvimento da Sprint.
Mas, também elas durante os Workshop de Requisitos e de Escrita de Estória que
são realizados antes das Reuniões de Planejamento.
A conversa:
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 26
Estilos para escrita das Estórias do Usuário:
Titulo: Pagamento com Cartão de Crédito Prioridade: 1-Alta
Quem ?
como um cliente
O que ?
preciso de uma interface de pagamento por cartão de
crédito que seja intuitiva e fácil de usar.
Por que ?
Com objetivo de facilitar os pagamentos.
Estilo 1
Pontos: 8
Titulo: Pagamento com Cartão de Crédito Prioridade: 1-Alta
Por que ?
Com objetivo de facilitar os pagamentos
Quem ?
Como um cliente
O que ?
Preciso de uma interface de pagamento por cartão de
crédito que seja intuitiva e fácil de usar.
Estilo 2
Pontos: 8
Boa Prática:
Definir um estilo ajuda na escrita das Estórias do Usuário
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 27
Confirmação
Na frente do cartão escreva a Estória do Usuário e no verso escreva os Testes de
Aceitação.
Confirmação
Para confirmar se a Estória do Usuário foi bem implementa podemos definir Teste de
Aceitação.
Testes de Aceitação:
Toda estória deve ser associada a pelo menos um Teste de Aceitação, o ideal é ter um
conjunto de testes. Estes testes definem as respostas que a funcionalidade deve
fornecer de acordo com a utilização por parte do usuário. Estes testes se materializam
na forma de “scripts” que indicam os resultados desejados (esperados) bem como os
resultados indesejados e que não devem ser providos pelo sistema.
Os Testes de Aceitação devem ser mais detalhados do que as estórias. Isto, por duas
razões:
A primeira e mais importante: Para validar se a Estória do Usuário foi corretamente
implementada (codificada).
E a segunda: Para prover o máximo de informações sobre a Estória.
Boa Prática:
Automatizar os Testes de Aceitação (sempre que possível).
Frente Como cliente de negócio, eu quero fazer reserva de um apartamento
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 28
Confirmação
Verificar se o status do apartamento, para o período da reserva, foi
alterado para “R” (reservado).
E verifique se o cliente foi notificado por e-mail da confirmação da
reserva.
Verificar se possível fazer reserva para um apartamento que esteja com
o status de reservado.
Exemplo de Testes de Aceitação: Confirmação
Verso
Boa Prática:
- Escreva os Teste de Aceitação no verso do cartão.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 29
Um “template” (modelo) para Estória do Usuário:
Frente Titulo: <escrever o titulo da estória> ou <ID da estória> Prioridade: <___>
<Por que ?>
<Quem ?>
<O que ?>
Obs: <escrever observações>
Verso
Pontos: <__>
Testes de Aceitação
<teste 1>
<teste 2>
<teste n>
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Tema
30
O que é Tema ?
Um tema é um agrupamento de Estórias do Usuários relacionadas. Por exemplo, em Portal de uma
Operadora de Plano de Saúde, pode haver temas em torno de Cliente, Rede Credenciada, Especialidade
Médica, Agendamento de Consulta e Pagamentos e etc.
Como cliente, eu quero consultar os pagamentos realizados no Portal
da Operadora para que possa controlar as minhas contas.
Como cliente de negócio, eu quero escolher o assento que melhor me
convier.
Como cliente, eu quero o imprimir a segunda via do boleto de
pagamento pelo Portal da Operadora para que não tenha que ir a
Operadora.
Como cliente, eu quero imprimir o relatório de comprovante de
pagamentos pelo Portal da Operadora para que possa controlar
as minhas contas.
Exemplo de Tema: Agrupamento de Estórias sobre o tema “Pagamento”
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Épico:
31
O que é Épico ?
São Estórias do Usuários de grande porte, normalmente aquelas que são demasiado grandes para
implementar em uma única iteração e, portanto, elas precisam ser decompostas em Estórias do
Usuário menores. Os épicos são difíceis de planejar e estimar.
Como tradutor eu quero fazer traduções utilizando uma ferramenta
que permita traduzir para 40 idiomas diferentes para facilitar o meu
trabalho.
Exemplo de Épico:
Esta Estória do Usuário é de
grande demais, para ser
implementada em uma Sprint de
30 dias. Neste caso ela deverá ser
“quebrada” ou decomposta em
Estórias do Usuário menores.
Como tradutor eu quero fazer traduções utilizando uma ferramenta
que permita traduzir para o inglês para facilitar o meu trabalho.
Como tradutor eu quero fazer traduções utilizando uma ferramenta
que permita traduzir para o espanhol para facilitar o meu trabalho.
Depois da quebra ou da
decomposição, as Estórias
ficaram menores e agora elas
podem ser implementadas em
uma Sprint.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 32
Estimar as “Estórias do Usuário”:
Estimar é Difícil ?
- Estimativa (mundo real) representa um valor aproximado.
- Estimativa (em desenvolvimento de software) algumas pessoas acham que representa um valor exato.
Contudo, devemos estimar as Estórias do Usuário para saber se elas “cabem” dentro de uma Sprint.
Uma vez que os pontos são estimados eles ajudam a definir a velocidade da equipe, a partir deste
parâmetro, podemos chegar a conclusão se estória cabe ou não dentro da Sprint. Se ela não couber a
opção é quebrar esta estória em estórias menores.
Pessoal, qual
estimativa para
essa estória...
Product Owner
Titulo: Pagamento com Cartão de Crédito Prioridade: ?
Quem ?
como um cliente
O que ?
preciso de uma interface de pagamento por cartão de
crédito que seja intuitiva e fácil de usar.
Por que ?
Com objetivo de facilitar os pagamentos.
Pontos: ?
Exemplo de Estórias do Usuário:
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 33
Estimar as “Estórias do Usuário”:
Baseado na duração de tarefas.
- Dias ou horas é unidade bem definida, contudo o “tempo ideal”
quase nunca é igual ao “tempo real”...
- É mais fácil de estimar, mas pode ser tornar difícil de estimar se
consideramos todas as interrupções e variações
Baseia-se no tamanho da estória influenciado pela:
- Nível de dificuldade, complexidade e experiência (é empírico);
Foco nas funcionalidades;
O importante são os valores relativos;
Pontos são medidas sem unidade;
Equipe diferentes podem ter pontos diferentes para a mesma
estórias.
Pontos de Estória (Story Points)
Principais técnicas:
◦ Opinião de especialista;
◦ Analogia;
◦ Decomposição (Dividir para conquistar).
Dias Ideais (Ideal Days)
Pontos de Estória:
◦ Valores relativos
◦ Mais abstrato
Ideal Days:
◦ Mais fácil para iniciantes
◦ Fácil de explicar
Quando trabalhamos com métodos ágeis temos pelo menos duas formas para estimar a velocidade da
equipe: Ideal Days e Pontos de Estória. Recomendamos utilizar os Pontos de Estória.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 34
Estimar “Estórias do Usuário”:
Estimativa* e o Planning Poker:
Geralmente o Planning Poker usa um conjunto de cartas com valores específicos que
podem representar pontos relativos e é praticado como se fosse um jogo de cartas. Os
pontos devem estar em uma escala não linear, por e exemplo a Fibonacci:
(1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala
Para fazer estimativa de velocidade da equipe ou de duração da Sprint, antes é preciso o escrever as
estórias do usuário.
O Planning Poker é uma “prática” que ajuda na estimativa de uma estória ou de uma tarefa e é baseada
no consenso de toda a equipe.
Pessoal, qual
estimativa para
essa estória...
Product Owner Equipe
8
8
8
5
Jogando o Planning Poker:
Antes de começar o jogo é necessário definir um valor de referência. Por exemplo: Identificar a estória
que pode ser atribuído a menor quantidade pontos, esta estória será utilizada como referência para
pontuação das demais estórias.
O PO apresenta uma estória e pede para os membros da equipe fazer a estimativa de velocidade...
8
8
8
8
1ª. Rodada Quando todas as cartas
estiverem lançadas, elas
são viradas e caso não
haja consenso nos
pontos, as diferenças são
discutidas de forma
breve, e uma nova
rodada acontece até que
haja a convergência.
Nª. Rodada
Equipe
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 35
Estimar as “Estórias do Usuário”:
Exemplo:
Se a Estória do Usuário tem 8 pontos e a equipe tem a velocidade de 2 pontos por dia, isto significa que
a equipe precisará de 4 dias para implementar a estória.
Titulo: Pagamento com Cartão de Crédito
Prioridade: ?
Quem ?
como um cliente
O que ?
preciso de uma interface de pagamento por cartão de
crédito que seja intuitiva e fácil de usar.
Por que ?
Com objetivo de facilitar os pagamentos.
Pontos: 8
Exemplo de Estórias do Usuário:
Importante:
Para fazer a estimativa, você deve levar em consideração outros aspectos além da codificação da estória, como por
exemplo: realização do teste unitários, preparação do ambiente de teste e outras coisas que são necessário e
importantes (mesmo que de baixo valor para o negócio) para que você entregue o software funcionando.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 36
Objetivo desta parte
3
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 37
Onde estão os detalhes da Estória do Usuário ?
Como já dizemos boa parte dos detalhes de uma Estória do Usuário estão presentes nos testes de
aceitação.
Mas, se não for suficiente para ter entendimento e fazer a estimativa ?
Caso seja necessário, podemos decompor a estória do usuário principal em sub-estórias.
Exemplo:
Título: Cliente faz saque de dinheiro
Como um cliente, eu gostaria de sacar dinheiro
em um caixa eletrônico, para que eu não tenha
que esperar numa fila de banco.
Como um cliente especial,
poderei fazer saques, mesmo
que o saldo da conta esteja
negativo
Como um cliente comum, não
poderei fazer saques se o
saldo da conta estiver
negativo.
Detalhando uma Estória do Usuário
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 38
As Estórias do Usuário devem herdar o nível de prioridade do Product Backlog (O PO é responsável
por priorizar os itens do Product Backlog).
Cabe ao PO e a equipe devem chegar a um acordo de qual estória será feito primeiro, algumas
dicas são importantes:
1 - Identificar a estória de maior valor para o cliente (maior ROI).
2 - Identificar a estória com maior impacto no negócio (se ela não for feita na prioridade correta).
3 - Identificar a estória com maior o risco de não ser implementada
Contudo, se uma Sprint tem duas estórias, qual estória será feita primeiro e qual será feita
depois, eis a questão...???
Priorização de Estórias do Usuários:
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 39
Fazer a boa definição dos papéis dos usuário, ajudam a melhorar a escrita da Estória do
Usuário:
Exemplo: Em um site de um hotel, temos pelo menos dois papéis distintos:
- Visitante
- Cliente
Definição:
Visitante : São pessoas que navegam pelo site mas não fazem nenhum reserva, não possuem um login
e nem senha de acesso.
Cliente: São pessoas que navegam pelo website e fazem reserva e possuem login de acesso.
Como usuário, eu quero
navegar pelo site para que
possa encontrar as promoções
Como visitante , eu quero
navegar pelo site para que possa
encontrar as promoções
Evitar Usar (boa prática)
Modelo:
Como <papel/função>, eu quero <objetivo/meta> para que <alguma razão/benefício>
papel
identifique os principais
usuários.
Técnica: Faça uma sessão
de Brainstorming
identifique os papéis
desempenhados pelos
principais usuários.
Organize, revise e
consolide a lista de
usuários e de papéis
1 2 3
Passos para criação da lista de usuários e papéis:
Papéis do Usuário:
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 40
Modelo:
Como <perfil>, eu quero <objetivo/meta> para que <alguma razão/benefício>
Uma outra forma de trabalhar os usuário e os papéis, é o conceito de persona (personagem).
Identificar os papéis e as funções de usuário é um grande passo, mas para algumas funções de usuário
é mais importante, ir um passo além e criar um personagem para o papel.
O personagem é uma representação imaginária de uma função de usuário. Criação de um
personagem exige mais do que apenas adicionar um nome a uma função de usuário. O personagem
exigirá uma descrição detalhada e que seja suficiente para que todos os membros equipe conheçam e
entendam o personagem.
Exemplos:
João é executivo que trabalho em empresa de consultoria tributária, ele viaja a
trabalho. E se hospeda em hotel de padrão 5 estrelas. Geralmente ele faz
seus pagamentos utilizando cartão corporativo.
Neste exemplo João é um persona. Este é perfil do João.
Maria é uma cliente preferencial. Ela visita o site pelo menos duas vezes por
semana. Ela compra livros, DVDs e CDs. Ela faz o pagamento dos pedidos
com cartão de débito.
Neste exemplo Maria é uma persona. Este é perfil da Maria.
Quando utilizamos o conceito de persoangem as estórias do usuário se tornam muito mais expressivas.
Depois de ter identificado as funções de usuário e, possivelmente, um personagem ou dois, podemos
começar a “falar” em termos de papéis e personagens, em vez do genérico “cliente".
João
Personas
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 41
Existem diversas técnicas que podem ser utilizadas para coletar informações para escrita das Estórias
do Usuário.
Boa Prática:
- Combine mais que uma técnica para obter as informações necessárias para escrever as Estórias do
Usuário.
Principais técnicas:
- Entrevistas com usuários.
- Preenchimento de questionários.
- Observação de campo.
- Workshop de Escrita de Estórias do Usuário*.
Entrevistas com usuários:
Entrevista com os usuários
geralmente é a técnica mais utilizada
para coleta de informações.
Dicas:
- Informe qual é objetivo da
entrevista e como a pessoa poderá
contribuir.
- Escolher os entrevistados certos,
ou seja, aqueles que podem e
querem dar informação.
- Fazer mais que uma entrevista
para o mesmo tema. A diversidade
de visões podem ajudar no
entendimento .
- Respeitar horários.
- Escutar o entrevistado.
- Manter “o foco” da entrevista.
Preenchimento de Questionários:
Preenchimento de questionário é uma
técnica eficiente para coleta de
informações, principalmente quando o
número de usuários é muito grande.
Dicas:
- Faça um workshop para explicar o
qual é objetivo do questionário.
- O questionário deve ser objetivo e de
fácil preenchimento.
- Não faça um questionário muito
longo, pois, responde-lo pode ser
cansativo e desinteressante.
- Estabeleça prazos para entrega do
questionário.
- Ajude as pessoas com dúvidas sobre
as questões.
Observação de Campo:
Observação permite capturar “como”
os usuários fazem suas atividades e
tarefas.
Dicas:
- Informe qual é objetivo da
observação.
- Escolher os observados certos, ou
seja, aqueles que podem e querem
dar informação.
- Observar pessoas diferentes para
obter a diversidade de visões.
- Respeitar a privacidade dos
observados.
- Respeitar horários.
- Não fazer inferências.
- Seja discreto.
Técnicas para coleta de informações
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 42
Além de ser uma técnica para coleta de informação, o Workshop é uma ferramenta de
prototipação.
• Participantes: desenvolvedores, usuários, cliente (PO) e etc
• Fazer uma sessão de “brainstorming” para geração de ideias e
estórias.
• Algumas estórias do usuário estarão prontas para implementar.
• Outras serão “Épicos”. No futuro elas deveram ser decompostas.
• Não existe a necessidade de priorização.
O workshop dever seguir algumas regras:
- O objetivo é a quantidade, ao invés de qualidade. Ou seja,
aqui a ideia é identificar e escrever o máximo de Estórias do
Usuário possíveis.
-Foco no “alto nível de abstração”, ou seja, não perder tempo
detalhando ou discutindo demais alguns assuntos.
- Não julgar as ideias. A menos que seja algo fora do
propósito, algumas Estórias do Usuário que pareçam inúteis,
podem dar vazão a outras ideias.
No final do workshop devemos ter uma visão mais clara do
produto suas funcionalidades e será mais fácil identificar, escrever
e refinar as estórias do usuário.
Workshop de Escrita de Estória do Usuário
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
INVEST, uma boa prática para escrita de Estórias do Usuário:
43
Kelly Waters tem escrito há muito tempo sobre Estória do Usuário, introduzindo o conceito de INVEST
como uma definição clara sobre como trabalhar com esta ferramenta.
Segundo ele uma boa Estória do Usuário deve ter seis atributos:
INVEST
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Como cliente de negócio, eu quero consultar os apartamentos pela web
para facilitar a reserva
44
Tarefas:
Fazer Consulta
de Apartamentos
pela Web
Fazer
interface
do usuário
Integrar
com Sistema
de Reserva
Criar
Componentes
de validação
Pontos: 8
Sprint Backlog
Titulo: “Consulta de Apartamentos”
Executar
testes
unitários
Prioridade: Alta
Executar
testes
aceitação
Estória do Usuário
Boa Prática:
- Quebre a estória do usuário em tarefas para facilitar a estimativa.
Devemos buscar meios para facilitar a estimativa de velocidade da equipe, quebrar a estória em tarefas
pode fazer que todos os membros da equipe visualizem todas as tarefas que devem ser feitas para
implementar a Estória do Usuário.
As tarefas
tem baixo
valor agregado
ao negócio
As estórias
tem alto valor
agregado ao
negócio
Quebrando Estória do Usuário em Tarefas
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 45
Vejamos como aplicar o SMART para escreve as tarefas:
Específico:
A tarefa deve ser específica o suficiente para que todos possam entende-la. Ela deve
ser simples, objetiva e concisa. Isso ajuda as pessoas a compreender quais as tarefas devem ser adicionadas
para completar estória do usuário.
Mensurável:
Saber medir as tarefas é fundamental, pois, precisamos saber quantas tarefas será possível fazer dentro da
Sprint. Lembre-se de incluir também as tarefas técnicas, tais como teste de aceitação. Para mensurar as tarefas
o ideal é conhecer a velocidade do time.
Realizável:
As tarefas podem ser feitas ? Existem algum débito técnico ou algo que cause algum impedimento na realização
das tarefas ? A equipe deve identificar tudo aquilo que é necessário para realização da tarefa na reunião de
planejamento da Sprint.
* Existe uma grande quantidade de variações sobre o SMART., geralmente este acrônimo é usada para a definição de metas, ele também tem boas características para tarefas
Use INVEST para a Estórias e SMART para as Tarefas
Use "INVEST" para escrever as Estórias do Usuário e "SMART" para escrever as Tarefas.
As boas práticas recomendam que para escrever as estórias do usuário usar o "INVEST", isto é
bastante difundido e praticado. Mas, qual é a boa prática para escrever as tarefas ?
Recomendo usar o "SMART" para escrever
as tarefas como uma boa prática.
O que significa SMART* ?
S - (Specific) Específico
M - (Measurable) Mensurável
A - (Achievable ) Realizáveis
R - (Relevant) Relevante
T - (Duração fixa) Time-boxed
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 46
Relevante:
Cada tarefa deve ser relevante contribuindo para a estória do usuário. Todas tarefas consideradas irrelevantes
para entrega da estória deve ser eliminada ou guardadas para uma próxima iteração. Somente as tarefas
relevantes devem fazer parte da Sprint.
Time-Boxed:
O Time-box (duração fixa) é um conceito aplicado a Sprint e não as tarefas. Contudo,
as tarefas devem caber dentro da Sprint.O time deve fazer todas as tarefas do Sprint Backlog para que a meta
da Sprint seja atingida, quando isto não acontece será necessário negociar com o PO ou as tarefas voltaram
para Backlog.
* Existe uma grande quantdade de variações sobre o SMART., geralmente este acrônimo é usada para a definição de metas, ele também tem boas características para tarefas
Boas Práticas:
Ao trabalhar com as estórias de usuário (escreve-las e estima-las), o INVEST pode ajudar a lembrar
das boas práticas para estória. Ao criar as tarefas (que são derivadas das estórias) , aplicando-se o
SMART, que pode auxiliar na aplicação das boas práticas para definição das tarefas.
Use INVEST para a Estórias e SMART para as Tarefas
Recomendo usar o "SMART" para escrever
as tarefas como uma boa prática.
O que significa SMART* ?
S - (Specific) Específico
M - (Measurable) Mensurável
A - (Achievable ) Realizáveis
R - (Relevant) Relevante
T - (Duração fixa) Time-boxed
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 47
Parte das boas práticas estão espalhadas na Lição 3. Apresentamos mais alguma dicas e boas
práticas que devem ser utilizadas na escrita e a na estimativa das estórias:
1 - Escreva em Voz Ativa:
Estória do usuário são mais fáceis de ler e compreender, quando escrita na voz ativa. Por exemplo, ao
invés de dizer "Um currículo pode ser enviado por um candidato a emprego", diga: "Um candidato
pode enviar um currículo.“
2 - Responsabilidade da escrita das estórias:
O ideal seria o cliente escrever as estórias. Mas, na maioria das vezes os membros da equipe (os
desenvolvedores) acabam ajudando os clientes na escrita das estórias. Mas, a responsabilidade de
escrever as estórias do usuário é do cliente e isto não pode ser delegado para os membros da equipe.
3 - Ao escrever as estórias do usuário use e abuse do INVEST.
4 - Lembre-se dos três Cs (Cartão, Conversa e Confirmação)
5 - Use o “Planning Poker” para ajudar na estimativa das estórias.
6 - Utilize diversas técnicas combinada para coletar informações.
7 - Sempre que possível utilize o conceito de persona (personagem).
8 - Nunca utilize linguagem ou jargões técnicos na escrita das estórias do usuário.
9 – Use de software:
Somente opte por utilizar o software para “escrita” e a “estimativa” das estórias do usuário quando a
equipe, parte da dela ou cliente estão à distância.
Lista de Boas Práticas:
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 48
Objetivo desta parte
4
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 49
A ferramenta indispensável: O Cartão para escrita das estórias do usuário
Ferramenta: Cartão
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 50
Planning Poker
é uma ferramenta
que permite
escrever e estimar
as Estórias do
Usuário para equipe
distribuídas ou
quando o cliente
(PO) esteja a
distância.
http://www.planningpoker.com/
É uma ferramenta web, de colaboração, que permite que as Estórias do
Usuário sejam escritas e estimadas, por uma equipe distribuída ou quando o
cliente estiver à distância.
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 51
http://www.planningpoker.com/
O moderador
(pessoa que
conduzirá o jogo –
neste caso o PO).
deverá fazer o login
(informar nome do
usuário e senha).
Quem não tem
usuário e senha,
basta fazer o
cadastro.
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 52
http://www.planningpoker.com/
Após o login, se for
sua primeira vez
será informado que
o moderador não
tem nenhum jogo
criado.
Para criar um novo
jogo
Clique no link
“Create a new
game”
Caso contrário será
exibido todos os
jogos.
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 53
http://www.planningpoker.com/
Para criar um novo
jogo, você deverá
informar os dados.
E depois clique no
botão “Create
Game”
Você pode optar por
fazer a importação
das estórias
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 54
http://www.planningpoker.com/
Após a criação do
jogo, você deverá
adicionar as
estórias do usuário
que fazem parte do
jogo.
Para adicionar as
estórias do usuário
basta preencher os
campos e clicar no
botão “Add story”
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 55
http://www.planningpoker.com/
Para adicionar
novos participantes
(estamos “falando”
de um jogo de
Planning Poker –
novos participantes
devem ser os
membros da
equipe).
Basta informar a
URL aos demais
participantes.
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 56
http://www.planningpoker.com/
Cada participante
deverá escolher
uma carta e jogar.
Importante: todos os
participantes vão
visualizar as cartas
jogadas.
Para que não haja
influência entre os
participantes é
preciso
sincronizar as
jogadas, assim
todos os
participantes
selecionaram a
carta e jogarão
simultaneamente
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 57
http://www.planningpoker.com/
Quando todos os
jogadores
apresentaram as
cartas, o moderador
(PO), poderá optar
por aceitar os
pontos para a
estória (clicando no
botão “Accept”) ou
fazer um nova
rodada (clicando no
botão “again”).
Para finalizar (após
aceitar os pontos
para a estória)
clique no botão
“Complete game”
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Outro exemplo: Fazendo estimativa de uma estória do usuário:
Ferramentas: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
É apresentada a estória e os participantes devem jogar as cartas para estimar quantos pontos
são necessários para implementa-la.
participantes
estória
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Na primeira rodada, não existe um consenso entre os membros da equipe, será necessário fazer
uma nova rodada.
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Após algumas rodadas, os membros da equipe conseguem chegar a um consenso. A estória do
usuário tem 8 pontos .
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Após consenso. A estória do usuário é estimada em 8 pontos e jogo está completo.
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
O status da estória do usuário foi alterado para completo.
Ferramenta: Planningpoker.com
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 64
Planning Poker no iPhone App Stote
Somente as cartas para
jogar o Planning Poker
Ferramenta: Planning Poker no iPhone
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 65
User Stories Applied: For Agile Software Development
Autor: Mike Cohn
Editora : Addison Wesley
Ano de publicação: 2004
ISBN: 0-321-20568-5
http://xp123.com/xplor/
http://www.planningpoker.com/
Scrum Experience:
http://rildosan.blogspot.com/2009/06/scrum-experience-o-tutorial-scrum.html
Scrum Product Owner:
http://rildosan.blogspot.com/2010/03/scrum-product-owner.html
Referências
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 66
Dúvidas:
Ficou com dúvida ?
Entre em contato: treinamento@etecnologia.com.br
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Quer mais
http://etecnologia.ning.com/
Venha participar da Comunidade eTecnologia
67
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 68
Notas:
Marcas Registradas:
Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de
responsabilidade de seus proprietários. O autor informa não estar associada a nenhum produto e/ou
fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes
podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo e/ou educativo, não
visando ao lucro, favorecimento ou desmerecimento do produto/fabricante.
Melhoria e Revisão:
Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema
ou erro envie um e-mail nós.
Criticas e Sugestões:
Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor
envie um e-mail para nós.
Rildo F dos Santos (rildo.santos@etecnologia.com.br)
Imagens:
Google, Flickr e Banco de Imagem.
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010 69
Licença:
rildo.santos@etecnologia.com.br
Versão 1 Ago 2010 | RFS
Escrevendo
Estórias
do
Usuário
Eficazes
Todos os direitos reservados e protegidos © 2006 e 2010
Versão 5
Escrevendo
Estórias do
Usuário
Eficazes
Rildo F Santos
rildo.santos@etecnologia.com.br
twitter: @rildosan
skype: rildo.f.santos
http://rildosan.blogspot.com/
(11) 9123-5358
(11) 9962-4260
www.etcnologia.com.br

Escrevendo Estórias do Usuário - User Stories

  • 1.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Versão 5 Escrevendo Estórias do Usuário Eficazes Rildo F Santos rildo.santos@etecnologia.com.br @rildosan http://rildosan.blogspot.com/ (11) 9123-5358 (11) 9962-4260 www.etcnologia.com.br
  • 2.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 2 Programa: “Menos Papel, Mais Árvores ®” Qual é o mundo que queremos ? O primeiro passo para criar um mundo melhor, é saber qual tipo de mundo que queremos ter e qual tipo que deixaremos de herança para as próximas gerações. Nossa missão: É buscar pelo equilibro: do homem, tecnologia e meio ambiente, isto é o que queremos. Para cumprir esta missão é necessário; conscientizar, comprometer e AGIR. O programa Menos Papel, Mais Árvores®, é uma ação, com objetivo de estimular o consumo sustentável de papel dentro das organizações. Quer participar ? - Reduza o uso de papel (e de madeira) o máximo possível. - Só imprima se for extremamente necessário. - Evite comprar produtos com excesso de embalagem. - Ao imprimir ou escrever, utilize os dois lados do papel. - Use papel reciclado. Este material não deve ser impresso..
  • 3.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 3 Facilitador: Rildo F. Santos (@rildosan) Coach, Consultor, Instrutor e Palestrante de Negócio, Processos, Inovação, Sustentabilidade e Tecnologia. Minha Experiência: Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia de Software pela Universidade Macaense. Fui instrutor de Tecnologia de Orientação a Objetos, IML e Linguagem Java na Sun Necrosastes e na IBM. Conheço Métodos Ágeis (SCRUM, Lean, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), OpenUP, Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias. Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA. Possuo conhecimento de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC - Governance, Risk ando Compliance), SOX, Basel II e PCI; E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais frameworks e padrões: ITIL, Cobit, ISO 27001 e ISO 15999; Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás. Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games; Sou membro do IIBA-International Institute of Business Analysis (Canada) Onde me encontrar: Twitter: @rildosan Blog: http://rildosan.blogspot.com/ Comunidade: http://etecnologia.ning.com
  • 4.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 4 1 – Problemas de Comunicação 2 – Estória do Usuário 3 – Boas Práticas 4 – Ferramentas e técnicas O Conteúdo:
  • 5.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 5 Comentário inicial: Objetivo: Esta apresentação tem como objetivo discutir sobre a Estória do Usuário e suas técnicas para que elas se tornem eficazes. A estória do usuário é forma de facilitar a comunicação e entendimento entre o cliente de negócio (PO) e a equipe Scrum (Desenvolvedores). Uma estória do usuário eficaz é aquela que ajuda no entendimento daquilo que deve ser feito. Pré-requisito: A ênfase deste curso é para SCRUM e XP. Logo , conhecer Scrum é um pre-requisito.
  • 6.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 6 Objetivo desta parte: 1
  • 7.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 7 Problemas de Comunicação Uma questão essencial nos projetos de desenvolvimento de software é a maneira pela qual os clientes dizem para os desenvolvedores o que eles esperam que seja feito. Cenas comuns: 1ª. Cena: O cliente não sabe exatamente o que ele quer. 2ª. Cena: Os desenvolvedores apresentam para o cliente o que fizeram e o cliente diz que não era bem aquilo o que ele queria. 3ª. Cena: Depois que o software é entregue, é comum que o cliente tem novas ideias de coisas a serem feitas ou alteradas. Se você já participou em uma destas cenas...com certeza, isto é decorrente de problemas de comunicação e falta de entendimento. Para evitar essas situações, muitas pessoas fazem especificações de requisitos de software antes de se começar o desenvolvimento. Nesses casos, a especificação deve ter todos os detalhes que os desenvolvedores precisam saber antes de começarem a trabalhar. Contudo, a especificação de requisitos de software, não é garantia de sucesso, pois, geralmente os requisitos especificados sofrem mudanças e é muito difícil e dispendioso colocar todas as características de um software no papel com clareza e exatidão.
  • 8.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 8 Problemas de Comunicação Falhas na comunicação são uma eterna fonte de problemas
  • 9.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 9 Requisitos são responsáveis por 37% das falhas dos projetos de desenvolvimento de software: Informação errada 13% Requisitos incompletos 12% Mudança de Requisitos 12% Falta de conhecimento técnico 7% Falta de competência Outros 50% 37% das falhas estão relacionadas com requisitos Problemas de Comunicação
  • 10.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 10 Introdução: Problemas de Comunicação Cliente: Tem dificuldade para externar suas necessidades
  • 11.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 11 Cliente x Desenvolvedores: Clientes: - Alguns clientes têm dificuldades em externar suas necessidades ou desejos de forma clara e objetiva (Não sabem o que querem) - Geralmente fazem mudanças de requisitos durante o desenvolvimento ou quando o software é entregue. - Sempre precisam do software funcionando para ontem - Não têm tempo e nem paciência para falar com os desenvolvedores. Desenvolvedores: - Não sabem ou não querem conversar com o cliente - Dificilmente conseguem atender o negócio e todas suas demandas - Têm dificuldade em se comunicar e entender os clientes
  • 12.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Boas Práticas de Comunicação: - Ter uma linguagem comum - Ter simplicidade - Ser objetiva - Usar diversas técnicas para melhorar a comunicação e o entendimento - Dar preferência a comunicação face-a-face (exemplos: XP exploram bastante isto) Objetivo da boa comunicação: Facilitar o entendimento 12 Como melhorar a comunicação ? Se levarmos em consideração somente o lado técnico, a linguagem será técnica, o que dificultará o entendimento de quem não é técnico. Se a linguagem é de negócio, na maioria das vezes o desenvolvedor tem dificuldades em entender o negócio e suas demandas. Qual é a solução ? O ideal é chegar em ponto de equilíbrio, definir uma linguagem comum, que facilite o entendimento e a comunicação entre o pessoal de negócio e os desenvolvedores.
  • 13.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 13 O que fazer ? Manifesto Ágil dá algumas dicas:
  • 14.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 14 O que fazer ? Princípios por trás do Manifesto Ágil: A prioridade é satisfazer o cliente, entregando o mais rápido possível e de forma contínua, software que tenha valor; Requisitos mutantes são bem vindos, mesmo no final do desenvolvimento. Os processos ágeis podem ser usados a favor de mudanças que tragam vantagem competitiva para o cliente; É importante entregar software funcionando freqüentemente, mensalmente, quinzenalmente ou, se possível, toda semana; Clientes e desenvolvedores devem trabalhar juntos diariamente num projeto; Projetos devem ser feitos por indivíduos motivados. Os indivíduos precisam da confiança de que seu trabalho será realizado. Eles devem ter suas necessidades atendidas e trabalhar num ambiente adequado; Conversa face-a-face é SEMPRE a melhor forma de comunicação; Software funcionando é a primeira medida de progresso; O processo ágil torna o desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários devem manter a paz indefinidamente; Atenção constante à excelência técnica e bom design aumenta a agilidade; A chave é SIMPLICIDADE: a arte de minimizar a quantidade de trabalho desnecessário; As melhores arquiteturas, requisitos e design surgem de equipes auto-organizadas; Em intervalos regulares, a equipe reflete como se tornar mais eficiente. Então ajusta seu comportamento para atingir esse objetivo. Manifesto Ágil dá algumas dicas:
  • 15.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 15 Se trabalhamos com desenvolvimento Ágil: Logo temos: Colaboração com cliente: A estória do Usuário é escrita em colaboração entre os desenvolvedores e o cliente (PO). A prioridade é satisfazer o cliente, entregando o mais rápido possível e de forma contínua software que tenha valor: Para satisfazer o cliente é preciso entendê-lo. A estória ajuda a melhorar o entendimento da necessidade do cliente para que ocorra a entrega de valor. - Conversa face-a-face é SEMPRE a melhor forma de comunicação: A estória do usuário geralmente é feita na Reunião de Planejamento (Planning Meeting). Titulo: Pagamento com Cartão de Crédito Prioridade: Alta Como cliente de negócio eu gostaria de fazer pagamento com Cartão de Crédito para minha comodidade. Pontos: 5 A Estória de Usuário é uma “ferramenta” simples que pode ajudar. Uma Estória de Usuário nada mais é que um cartão com algumas frases, escrita pelo cliente e desenvolveres em linguagem comum, sobre algo que o software deve fazer. Aqui entra a Estória do Usuário:
  • 16.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 16 Objetivo desta parte: 2
  • 17.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 17 O que é Estória do Usuário ? É uma pequena descrição, que detalha um item do Product Backlog. Para que serve a Estória do Usuário ? Uma estória ajuda no entendimento do que deve ser feito, ela permite fazer a estimativa de velocidade da equipe e também é, utilizada como lembrete e para as atividades de planejamento. Geralmente a estimativa é feita em pontos (pontos de estória) ou dias ideais. (dias ideais). Como escrever uma Estória do Usuário ? Conversações sobre a estória, entre os usuários e desenvolvedores, de modo a detalhar o item do Product Backlog e esclarecer todas as dúvidas sobre do que deve ser feito. Boa Prática: - A Estória do Usuário deve prover o entendimento do que deve ser feito. - Deve facilitar a estimativa de velocidade da equipe. Diferenças entre a Estória do Usuários e Especificações de Requisitos Tradicionais: Um dos maiores mal-entendidos com as Estórias do Usuário é como elas diferem das especificações de requisitos tradicionais. A maior diferença está no nível de detalhe. Estória do Usuários só devem fornecer detalhes suficientes para “chegar” no entendimento do que deve ser feito e facilitar a estimativa de velocidade da equipe. Outra diferença fundamental entre as estórias e as especificações de requisitos é o foco. Quando escrevemos uma Estória o foco é nas necessidades do usuário, devemos evitar os detalhes técnicos, tais como descrição de tecnologia, desenho das interfaces do usuário, wireframes, modelo de dados, algoritmos e etc. Boa Prática: - Mantenha a Estória focada nas necessidades do usuário e nos benefícios.
  • 18.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 18 Diferença entre a do Estória do Usuário e Casos de Uso: Uma Estória do Usuário descreve um detalhamento de alto nível de uma funcionalidade e/ou de um item do Product Backlog. E facilita na estimava da velocidade da esquie Fazer Reserva O Caso de Uso especificam a interação entre o Usuário e o Sistema.
  • 19.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 19 Um “modelo” para a escrita de Estórias do Usuário: Como <papel/função> eu quero <objetivo/meta> para que <alguma razão/benefício> Como cliente de negócio, eu quero sacar dinheiro em qualquer caixa eletrônico para que não tenha que ir na agência bancária. Como paciente, eu quero fazer agendar minha consulta médica pela web para que não tenha que usar o telefone. Boa Prática: - Cada Estória do Usuário deve ser um texto escrito com aproximadamente 3 sentenças
  • 20.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 20 Framework SCRUM: Artefatos Sprint Backlog Produto Planejamento da Sprint Reunião diária Sprint (2-4 Semanas) 24 horas Revisão da Sprint Retrospectiva da Sprint Visão Reuniões Sprint Burndown Release Burndown Product Backlog Legenda: • Product Owner (PO) • ScrumMaster (SM) • Equipe Scrum • Product Backlog • Sprint Backlog • Sprint Burndown • Release Burndown Papéis Eventos (Reuniões) Artefatos O Framework SCRUM é composto por Regras, Equipe SCRUM e os Eventos de duração fixa (time- box), Artefatos e a Definição de Pronto.  Planejamento da Release  Planejamento da Sprint  Diária  Revisão da Sprint  Retrospectiva da Sprint Na reunião de Planejamento da Sprint as Estórias do Usuário podem ser escritas e estimadas
  • 21.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 21 Os 3 “C”s de uma Estória do Usuário: Cartão Conversa Confirmação Estória do Usuário são tradicionalmente escritas em um cartão. Cartão podem ter notas, estimativas, observações, comentários e etc Detalhes que podem surgir durante as conversas com PO (Product Owner) e/ou cliente. Testes de aceitação “confirmam” se a Estória do Usuário foi codificada da forma correta. Testes de aceitação são tipo Caixa Preta.
  • 22.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 22 Cartão: Como cliente de negócio, eu quero fazer reserva de um apartamento Como cliente de negócio, eu quero cancelar a reserva de um apartamento Como cliente de negócio, eu quero ver fotos dos apartamentos do hotel. Exemplos de Estórias do Usuário para site de um Hotel: Um modelo: Como <papel/função> eu quero <objetivo/meta> para que <alguma razão/benefício> Cartão As Estórias do Usuário devem ser escrita em cartão: Exemplo: de Cartão Para escrever as Estórias do Usuário podemos comprar os cartões de papel ou utilizar um software. (O software somente recomendado quando parte da equipe está fisicamente em outro local).
  • 23.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 23 Exemplos de Estórias do Usuário: Como cliente de negócio, eu quero ver as promoções de passagens áreas Como cliente de negócio, eu quero comprar uma passagem área (TKT) Como cliente de negócio, eu quero pagar com meu cartão de crédito corporativo o valor das passagens áreas Como cliente de negócio, eu quero escolher o assento que melhor me convier. Exemplos de Estórias do Usuário para site de uma empresa Aérea Como cliente de negócio, eu posso realizar pelo meu smartphone o check-in para otimizar meu embarque.
  • 24.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 24 Cartão: Exemplos de Estórias do Usuário para Portal de Educação: Cartão Boa Prática: - Use cartão padrão (9 x 15 cm) para escrever as Estórias do Usuário. Esta tamanho de cartão ajuda a manter a Estória pequena e objetiva.
  • 25.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 25 Conversa: Como cliente, eu quero fazer o acompanhamento dos meus pedidos... PO (Product Owner) Equipe O que você quer (necessita)? Como cliente, eu quero fazer acompanhamento dos meus pedidos para que possa planejar o recebimento dos pedidos. Cartão: Conversa No SCRUM as conversas geralmente acontecem na Reunião de Planejamento da Sprint (Planning Meeting) e também durante o desenvolvimento da Sprint. Mas, também elas durante os Workshop de Requisitos e de Escrita de Estória que são realizados antes das Reuniões de Planejamento. A conversa:
  • 26.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 26 Estilos para escrita das Estórias do Usuário: Titulo: Pagamento com Cartão de Crédito Prioridade: 1-Alta Quem ? como um cliente O que ? preciso de uma interface de pagamento por cartão de crédito que seja intuitiva e fácil de usar. Por que ? Com objetivo de facilitar os pagamentos. Estilo 1 Pontos: 8 Titulo: Pagamento com Cartão de Crédito Prioridade: 1-Alta Por que ? Com objetivo de facilitar os pagamentos Quem ? Como um cliente O que ? Preciso de uma interface de pagamento por cartão de crédito que seja intuitiva e fácil de usar. Estilo 2 Pontos: 8 Boa Prática: Definir um estilo ajuda na escrita das Estórias do Usuário
  • 27.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 27 Confirmação Na frente do cartão escreva a Estória do Usuário e no verso escreva os Testes de Aceitação. Confirmação Para confirmar se a Estória do Usuário foi bem implementa podemos definir Teste de Aceitação. Testes de Aceitação: Toda estória deve ser associada a pelo menos um Teste de Aceitação, o ideal é ter um conjunto de testes. Estes testes definem as respostas que a funcionalidade deve fornecer de acordo com a utilização por parte do usuário. Estes testes se materializam na forma de “scripts” que indicam os resultados desejados (esperados) bem como os resultados indesejados e que não devem ser providos pelo sistema. Os Testes de Aceitação devem ser mais detalhados do que as estórias. Isto, por duas razões: A primeira e mais importante: Para validar se a Estória do Usuário foi corretamente implementada (codificada). E a segunda: Para prover o máximo de informações sobre a Estória. Boa Prática: Automatizar os Testes de Aceitação (sempre que possível). Frente Como cliente de negócio, eu quero fazer reserva de um apartamento
  • 28.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 28 Confirmação Verificar se o status do apartamento, para o período da reserva, foi alterado para “R” (reservado). E verifique se o cliente foi notificado por e-mail da confirmação da reserva. Verificar se possível fazer reserva para um apartamento que esteja com o status de reservado. Exemplo de Testes de Aceitação: Confirmação Verso Boa Prática: - Escreva os Teste de Aceitação no verso do cartão.
  • 29.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 29 Um “template” (modelo) para Estória do Usuário: Frente Titulo: <escrever o titulo da estória> ou <ID da estória> Prioridade: <___> <Por que ?> <Quem ?> <O que ?> Obs: <escrever observações> Verso Pontos: <__> Testes de Aceitação <teste 1> <teste 2> <teste n>
  • 30.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Tema 30 O que é Tema ? Um tema é um agrupamento de Estórias do Usuários relacionadas. Por exemplo, em Portal de uma Operadora de Plano de Saúde, pode haver temas em torno de Cliente, Rede Credenciada, Especialidade Médica, Agendamento de Consulta e Pagamentos e etc. Como cliente, eu quero consultar os pagamentos realizados no Portal da Operadora para que possa controlar as minhas contas. Como cliente de negócio, eu quero escolher o assento que melhor me convier. Como cliente, eu quero o imprimir a segunda via do boleto de pagamento pelo Portal da Operadora para que não tenha que ir a Operadora. Como cliente, eu quero imprimir o relatório de comprovante de pagamentos pelo Portal da Operadora para que possa controlar as minhas contas. Exemplo de Tema: Agrupamento de Estórias sobre o tema “Pagamento”
  • 31.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Épico: 31 O que é Épico ? São Estórias do Usuários de grande porte, normalmente aquelas que são demasiado grandes para implementar em uma única iteração e, portanto, elas precisam ser decompostas em Estórias do Usuário menores. Os épicos são difíceis de planejar e estimar. Como tradutor eu quero fazer traduções utilizando uma ferramenta que permita traduzir para 40 idiomas diferentes para facilitar o meu trabalho. Exemplo de Épico: Esta Estória do Usuário é de grande demais, para ser implementada em uma Sprint de 30 dias. Neste caso ela deverá ser “quebrada” ou decomposta em Estórias do Usuário menores. Como tradutor eu quero fazer traduções utilizando uma ferramenta que permita traduzir para o inglês para facilitar o meu trabalho. Como tradutor eu quero fazer traduções utilizando uma ferramenta que permita traduzir para o espanhol para facilitar o meu trabalho. Depois da quebra ou da decomposição, as Estórias ficaram menores e agora elas podem ser implementadas em uma Sprint.
  • 32.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 32 Estimar as “Estórias do Usuário”: Estimar é Difícil ? - Estimativa (mundo real) representa um valor aproximado. - Estimativa (em desenvolvimento de software) algumas pessoas acham que representa um valor exato. Contudo, devemos estimar as Estórias do Usuário para saber se elas “cabem” dentro de uma Sprint. Uma vez que os pontos são estimados eles ajudam a definir a velocidade da equipe, a partir deste parâmetro, podemos chegar a conclusão se estória cabe ou não dentro da Sprint. Se ela não couber a opção é quebrar esta estória em estórias menores. Pessoal, qual estimativa para essa estória... Product Owner Titulo: Pagamento com Cartão de Crédito Prioridade: ? Quem ? como um cliente O que ? preciso de uma interface de pagamento por cartão de crédito que seja intuitiva e fácil de usar. Por que ? Com objetivo de facilitar os pagamentos. Pontos: ? Exemplo de Estórias do Usuário:
  • 33.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 33 Estimar as “Estórias do Usuário”: Baseado na duração de tarefas. - Dias ou horas é unidade bem definida, contudo o “tempo ideal” quase nunca é igual ao “tempo real”... - É mais fácil de estimar, mas pode ser tornar difícil de estimar se consideramos todas as interrupções e variações Baseia-se no tamanho da estória influenciado pela: - Nível de dificuldade, complexidade e experiência (é empírico); Foco nas funcionalidades; O importante são os valores relativos; Pontos são medidas sem unidade; Equipe diferentes podem ter pontos diferentes para a mesma estórias. Pontos de Estória (Story Points) Principais técnicas: ◦ Opinião de especialista; ◦ Analogia; ◦ Decomposição (Dividir para conquistar). Dias Ideais (Ideal Days) Pontos de Estória: ◦ Valores relativos ◦ Mais abstrato Ideal Days: ◦ Mais fácil para iniciantes ◦ Fácil de explicar Quando trabalhamos com métodos ágeis temos pelo menos duas formas para estimar a velocidade da equipe: Ideal Days e Pontos de Estória. Recomendamos utilizar os Pontos de Estória.
  • 34.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 34 Estimar “Estórias do Usuário”: Estimativa* e o Planning Poker: Geralmente o Planning Poker usa um conjunto de cartas com valores específicos que podem representar pontos relativos e é praticado como se fosse um jogo de cartas. Os pontos devem estar em uma escala não linear, por e exemplo a Fibonacci: (1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala Para fazer estimativa de velocidade da equipe ou de duração da Sprint, antes é preciso o escrever as estórias do usuário. O Planning Poker é uma “prática” que ajuda na estimativa de uma estória ou de uma tarefa e é baseada no consenso de toda a equipe. Pessoal, qual estimativa para essa estória... Product Owner Equipe 8 8 8 5 Jogando o Planning Poker: Antes de começar o jogo é necessário definir um valor de referência. Por exemplo: Identificar a estória que pode ser atribuído a menor quantidade pontos, esta estória será utilizada como referência para pontuação das demais estórias. O PO apresenta uma estória e pede para os membros da equipe fazer a estimativa de velocidade... 8 8 8 8 1ª. Rodada Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos pontos, as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja a convergência. Nª. Rodada Equipe
  • 35.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 35 Estimar as “Estórias do Usuário”: Exemplo: Se a Estória do Usuário tem 8 pontos e a equipe tem a velocidade de 2 pontos por dia, isto significa que a equipe precisará de 4 dias para implementar a estória. Titulo: Pagamento com Cartão de Crédito Prioridade: ? Quem ? como um cliente O que ? preciso de uma interface de pagamento por cartão de crédito que seja intuitiva e fácil de usar. Por que ? Com objetivo de facilitar os pagamentos. Pontos: 8 Exemplo de Estórias do Usuário: Importante: Para fazer a estimativa, você deve levar em consideração outros aspectos além da codificação da estória, como por exemplo: realização do teste unitários, preparação do ambiente de teste e outras coisas que são necessário e importantes (mesmo que de baixo valor para o negócio) para que você entregue o software funcionando.
  • 36.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 36 Objetivo desta parte 3
  • 37.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 37 Onde estão os detalhes da Estória do Usuário ? Como já dizemos boa parte dos detalhes de uma Estória do Usuário estão presentes nos testes de aceitação. Mas, se não for suficiente para ter entendimento e fazer a estimativa ? Caso seja necessário, podemos decompor a estória do usuário principal em sub-estórias. Exemplo: Título: Cliente faz saque de dinheiro Como um cliente, eu gostaria de sacar dinheiro em um caixa eletrônico, para que eu não tenha que esperar numa fila de banco. Como um cliente especial, poderei fazer saques, mesmo que o saldo da conta esteja negativo Como um cliente comum, não poderei fazer saques se o saldo da conta estiver negativo. Detalhando uma Estória do Usuário
  • 38.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 38 As Estórias do Usuário devem herdar o nível de prioridade do Product Backlog (O PO é responsável por priorizar os itens do Product Backlog). Cabe ao PO e a equipe devem chegar a um acordo de qual estória será feito primeiro, algumas dicas são importantes: 1 - Identificar a estória de maior valor para o cliente (maior ROI). 2 - Identificar a estória com maior impacto no negócio (se ela não for feita na prioridade correta). 3 - Identificar a estória com maior o risco de não ser implementada Contudo, se uma Sprint tem duas estórias, qual estória será feita primeiro e qual será feita depois, eis a questão...??? Priorização de Estórias do Usuários:
  • 39.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 39 Fazer a boa definição dos papéis dos usuário, ajudam a melhorar a escrita da Estória do Usuário: Exemplo: Em um site de um hotel, temos pelo menos dois papéis distintos: - Visitante - Cliente Definição: Visitante : São pessoas que navegam pelo site mas não fazem nenhum reserva, não possuem um login e nem senha de acesso. Cliente: São pessoas que navegam pelo website e fazem reserva e possuem login de acesso. Como usuário, eu quero navegar pelo site para que possa encontrar as promoções Como visitante , eu quero navegar pelo site para que possa encontrar as promoções Evitar Usar (boa prática) Modelo: Como <papel/função>, eu quero <objetivo/meta> para que <alguma razão/benefício> papel identifique os principais usuários. Técnica: Faça uma sessão de Brainstorming identifique os papéis desempenhados pelos principais usuários. Organize, revise e consolide a lista de usuários e de papéis 1 2 3 Passos para criação da lista de usuários e papéis: Papéis do Usuário:
  • 40.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 40 Modelo: Como <perfil>, eu quero <objetivo/meta> para que <alguma razão/benefício> Uma outra forma de trabalhar os usuário e os papéis, é o conceito de persona (personagem). Identificar os papéis e as funções de usuário é um grande passo, mas para algumas funções de usuário é mais importante, ir um passo além e criar um personagem para o papel. O personagem é uma representação imaginária de uma função de usuário. Criação de um personagem exige mais do que apenas adicionar um nome a uma função de usuário. O personagem exigirá uma descrição detalhada e que seja suficiente para que todos os membros equipe conheçam e entendam o personagem. Exemplos: João é executivo que trabalho em empresa de consultoria tributária, ele viaja a trabalho. E se hospeda em hotel de padrão 5 estrelas. Geralmente ele faz seus pagamentos utilizando cartão corporativo. Neste exemplo João é um persona. Este é perfil do João. Maria é uma cliente preferencial. Ela visita o site pelo menos duas vezes por semana. Ela compra livros, DVDs e CDs. Ela faz o pagamento dos pedidos com cartão de débito. Neste exemplo Maria é uma persona. Este é perfil da Maria. Quando utilizamos o conceito de persoangem as estórias do usuário se tornam muito mais expressivas. Depois de ter identificado as funções de usuário e, possivelmente, um personagem ou dois, podemos começar a “falar” em termos de papéis e personagens, em vez do genérico “cliente". João Personas
  • 41.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 41 Existem diversas técnicas que podem ser utilizadas para coletar informações para escrita das Estórias do Usuário. Boa Prática: - Combine mais que uma técnica para obter as informações necessárias para escrever as Estórias do Usuário. Principais técnicas: - Entrevistas com usuários. - Preenchimento de questionários. - Observação de campo. - Workshop de Escrita de Estórias do Usuário*. Entrevistas com usuários: Entrevista com os usuários geralmente é a técnica mais utilizada para coleta de informações. Dicas: - Informe qual é objetivo da entrevista e como a pessoa poderá contribuir. - Escolher os entrevistados certos, ou seja, aqueles que podem e querem dar informação. - Fazer mais que uma entrevista para o mesmo tema. A diversidade de visões podem ajudar no entendimento . - Respeitar horários. - Escutar o entrevistado. - Manter “o foco” da entrevista. Preenchimento de Questionários: Preenchimento de questionário é uma técnica eficiente para coleta de informações, principalmente quando o número de usuários é muito grande. Dicas: - Faça um workshop para explicar o qual é objetivo do questionário. - O questionário deve ser objetivo e de fácil preenchimento. - Não faça um questionário muito longo, pois, responde-lo pode ser cansativo e desinteressante. - Estabeleça prazos para entrega do questionário. - Ajude as pessoas com dúvidas sobre as questões. Observação de Campo: Observação permite capturar “como” os usuários fazem suas atividades e tarefas. Dicas: - Informe qual é objetivo da observação. - Escolher os observados certos, ou seja, aqueles que podem e querem dar informação. - Observar pessoas diferentes para obter a diversidade de visões. - Respeitar a privacidade dos observados. - Respeitar horários. - Não fazer inferências. - Seja discreto. Técnicas para coleta de informações
  • 42.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 42 Além de ser uma técnica para coleta de informação, o Workshop é uma ferramenta de prototipação. • Participantes: desenvolvedores, usuários, cliente (PO) e etc • Fazer uma sessão de “brainstorming” para geração de ideias e estórias. • Algumas estórias do usuário estarão prontas para implementar. • Outras serão “Épicos”. No futuro elas deveram ser decompostas. • Não existe a necessidade de priorização. O workshop dever seguir algumas regras: - O objetivo é a quantidade, ao invés de qualidade. Ou seja, aqui a ideia é identificar e escrever o máximo de Estórias do Usuário possíveis. -Foco no “alto nível de abstração”, ou seja, não perder tempo detalhando ou discutindo demais alguns assuntos. - Não julgar as ideias. A menos que seja algo fora do propósito, algumas Estórias do Usuário que pareçam inúteis, podem dar vazão a outras ideias. No final do workshop devemos ter uma visão mais clara do produto suas funcionalidades e será mais fácil identificar, escrever e refinar as estórias do usuário. Workshop de Escrita de Estória do Usuário
  • 43.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 INVEST, uma boa prática para escrita de Estórias do Usuário: 43 Kelly Waters tem escrito há muito tempo sobre Estória do Usuário, introduzindo o conceito de INVEST como uma definição clara sobre como trabalhar com esta ferramenta. Segundo ele uma boa Estória do Usuário deve ter seis atributos: INVEST
  • 44.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Como cliente de negócio, eu quero consultar os apartamentos pela web para facilitar a reserva 44 Tarefas: Fazer Consulta de Apartamentos pela Web Fazer interface do usuário Integrar com Sistema de Reserva Criar Componentes de validação Pontos: 8 Sprint Backlog Titulo: “Consulta de Apartamentos” Executar testes unitários Prioridade: Alta Executar testes aceitação Estória do Usuário Boa Prática: - Quebre a estória do usuário em tarefas para facilitar a estimativa. Devemos buscar meios para facilitar a estimativa de velocidade da equipe, quebrar a estória em tarefas pode fazer que todos os membros da equipe visualizem todas as tarefas que devem ser feitas para implementar a Estória do Usuário. As tarefas tem baixo valor agregado ao negócio As estórias tem alto valor agregado ao negócio Quebrando Estória do Usuário em Tarefas
  • 45.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 45 Vejamos como aplicar o SMART para escreve as tarefas: Específico: A tarefa deve ser específica o suficiente para que todos possam entende-la. Ela deve ser simples, objetiva e concisa. Isso ajuda as pessoas a compreender quais as tarefas devem ser adicionadas para completar estória do usuário. Mensurável: Saber medir as tarefas é fundamental, pois, precisamos saber quantas tarefas será possível fazer dentro da Sprint. Lembre-se de incluir também as tarefas técnicas, tais como teste de aceitação. Para mensurar as tarefas o ideal é conhecer a velocidade do time. Realizável: As tarefas podem ser feitas ? Existem algum débito técnico ou algo que cause algum impedimento na realização das tarefas ? A equipe deve identificar tudo aquilo que é necessário para realização da tarefa na reunião de planejamento da Sprint. * Existe uma grande quantidade de variações sobre o SMART., geralmente este acrônimo é usada para a definição de metas, ele também tem boas características para tarefas Use INVEST para a Estórias e SMART para as Tarefas Use "INVEST" para escrever as Estórias do Usuário e "SMART" para escrever as Tarefas. As boas práticas recomendam que para escrever as estórias do usuário usar o "INVEST", isto é bastante difundido e praticado. Mas, qual é a boa prática para escrever as tarefas ? Recomendo usar o "SMART" para escrever as tarefas como uma boa prática. O que significa SMART* ? S - (Specific) Específico M - (Measurable) Mensurável A - (Achievable ) Realizáveis R - (Relevant) Relevante T - (Duração fixa) Time-boxed
  • 46.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 46 Relevante: Cada tarefa deve ser relevante contribuindo para a estória do usuário. Todas tarefas consideradas irrelevantes para entrega da estória deve ser eliminada ou guardadas para uma próxima iteração. Somente as tarefas relevantes devem fazer parte da Sprint. Time-Boxed: O Time-box (duração fixa) é um conceito aplicado a Sprint e não as tarefas. Contudo, as tarefas devem caber dentro da Sprint.O time deve fazer todas as tarefas do Sprint Backlog para que a meta da Sprint seja atingida, quando isto não acontece será necessário negociar com o PO ou as tarefas voltaram para Backlog. * Existe uma grande quantdade de variações sobre o SMART., geralmente este acrônimo é usada para a definição de metas, ele também tem boas características para tarefas Boas Práticas: Ao trabalhar com as estórias de usuário (escreve-las e estima-las), o INVEST pode ajudar a lembrar das boas práticas para estória. Ao criar as tarefas (que são derivadas das estórias) , aplicando-se o SMART, que pode auxiliar na aplicação das boas práticas para definição das tarefas. Use INVEST para a Estórias e SMART para as Tarefas Recomendo usar o "SMART" para escrever as tarefas como uma boa prática. O que significa SMART* ? S - (Specific) Específico M - (Measurable) Mensurável A - (Achievable ) Realizáveis R - (Relevant) Relevante T - (Duração fixa) Time-boxed
  • 47.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 47 Parte das boas práticas estão espalhadas na Lição 3. Apresentamos mais alguma dicas e boas práticas que devem ser utilizadas na escrita e a na estimativa das estórias: 1 - Escreva em Voz Ativa: Estória do usuário são mais fáceis de ler e compreender, quando escrita na voz ativa. Por exemplo, ao invés de dizer "Um currículo pode ser enviado por um candidato a emprego", diga: "Um candidato pode enviar um currículo.“ 2 - Responsabilidade da escrita das estórias: O ideal seria o cliente escrever as estórias. Mas, na maioria das vezes os membros da equipe (os desenvolvedores) acabam ajudando os clientes na escrita das estórias. Mas, a responsabilidade de escrever as estórias do usuário é do cliente e isto não pode ser delegado para os membros da equipe. 3 - Ao escrever as estórias do usuário use e abuse do INVEST. 4 - Lembre-se dos três Cs (Cartão, Conversa e Confirmação) 5 - Use o “Planning Poker” para ajudar na estimativa das estórias. 6 - Utilize diversas técnicas combinada para coletar informações. 7 - Sempre que possível utilize o conceito de persona (personagem). 8 - Nunca utilize linguagem ou jargões técnicos na escrita das estórias do usuário. 9 – Use de software: Somente opte por utilizar o software para “escrita” e a “estimativa” das estórias do usuário quando a equipe, parte da dela ou cliente estão à distância. Lista de Boas Práticas:
  • 48.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 48 Objetivo desta parte 4
  • 49.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 49 A ferramenta indispensável: O Cartão para escrita das estórias do usuário Ferramenta: Cartão
  • 50.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 50 Planning Poker é uma ferramenta que permite escrever e estimar as Estórias do Usuário para equipe distribuídas ou quando o cliente (PO) esteja a distância. http://www.planningpoker.com/ É uma ferramenta web, de colaboração, que permite que as Estórias do Usuário sejam escritas e estimadas, por uma equipe distribuída ou quando o cliente estiver à distância. Ferramenta: Planningpoker.com
  • 51.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 51 http://www.planningpoker.com/ O moderador (pessoa que conduzirá o jogo – neste caso o PO). deverá fazer o login (informar nome do usuário e senha). Quem não tem usuário e senha, basta fazer o cadastro. Ferramenta: Planningpoker.com
  • 52.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 52 http://www.planningpoker.com/ Após o login, se for sua primeira vez será informado que o moderador não tem nenhum jogo criado. Para criar um novo jogo Clique no link “Create a new game” Caso contrário será exibido todos os jogos. Ferramenta: Planningpoker.com
  • 53.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 53 http://www.planningpoker.com/ Para criar um novo jogo, você deverá informar os dados. E depois clique no botão “Create Game” Você pode optar por fazer a importação das estórias Ferramenta: Planningpoker.com
  • 54.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 54 http://www.planningpoker.com/ Após a criação do jogo, você deverá adicionar as estórias do usuário que fazem parte do jogo. Para adicionar as estórias do usuário basta preencher os campos e clicar no botão “Add story” Ferramenta: Planningpoker.com
  • 55.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 55 http://www.planningpoker.com/ Para adicionar novos participantes (estamos “falando” de um jogo de Planning Poker – novos participantes devem ser os membros da equipe). Basta informar a URL aos demais participantes. Ferramenta: Planningpoker.com
  • 56.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 56 http://www.planningpoker.com/ Cada participante deverá escolher uma carta e jogar. Importante: todos os participantes vão visualizar as cartas jogadas. Para que não haja influência entre os participantes é preciso sincronizar as jogadas, assim todos os participantes selecionaram a carta e jogarão simultaneamente Ferramenta: Planningpoker.com
  • 57.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 57 http://www.planningpoker.com/ Quando todos os jogadores apresentaram as cartas, o moderador (PO), poderá optar por aceitar os pontos para a estória (clicando no botão “Accept”) ou fazer um nova rodada (clicando no botão “again”). Para finalizar (após aceitar os pontos para a estória) clique no botão “Complete game” Ferramenta: Planningpoker.com
  • 58.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Outro exemplo: Fazendo estimativa de uma estória do usuário: Ferramentas: Planningpoker.com
  • 59.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 É apresentada a estória e os participantes devem jogar as cartas para estimar quantos pontos são necessários para implementa-la. participantes estória Ferramenta: Planningpoker.com
  • 60.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Na primeira rodada, não existe um consenso entre os membros da equipe, será necessário fazer uma nova rodada. Ferramenta: Planningpoker.com
  • 61.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Após algumas rodadas, os membros da equipe conseguem chegar a um consenso. A estória do usuário tem 8 pontos . Ferramenta: Planningpoker.com
  • 62.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Após consenso. A estória do usuário é estimada em 8 pontos e jogo está completo. Ferramenta: Planningpoker.com
  • 63.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 O status da estória do usuário foi alterado para completo. Ferramenta: Planningpoker.com
  • 64.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 64 Planning Poker no iPhone App Stote Somente as cartas para jogar o Planning Poker Ferramenta: Planning Poker no iPhone
  • 65.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 65 User Stories Applied: For Agile Software Development Autor: Mike Cohn Editora : Addison Wesley Ano de publicação: 2004 ISBN: 0-321-20568-5 http://xp123.com/xplor/ http://www.planningpoker.com/ Scrum Experience: http://rildosan.blogspot.com/2009/06/scrum-experience-o-tutorial-scrum.html Scrum Product Owner: http://rildosan.blogspot.com/2010/03/scrum-product-owner.html Referências
  • 66.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 66 Dúvidas: Ficou com dúvida ? Entre em contato: treinamento@etecnologia.com.br
  • 67.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Quer mais http://etecnologia.ning.com/ Venha participar da Comunidade eTecnologia 67
  • 68.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 68 Notas: Marcas Registradas: Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de responsabilidade de seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento ou desmerecimento do produto/fabricante. Melhoria e Revisão: Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie um e-mail nós. Criticas e Sugestões: Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-mail para nós. Rildo F dos Santos (rildo.santos@etecnologia.com.br) Imagens: Google, Flickr e Banco de Imagem.
  • 69.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 69 Licença:
  • 70.
    rildo.santos@etecnologia.com.br Versão 1 Ago2010 | RFS Escrevendo Estórias do Usuário Eficazes Todos os direitos reservados e protegidos © 2006 e 2010 Versão 5 Escrevendo Estórias do Usuário Eficazes Rildo F Santos rildo.santos@etecnologia.com.br twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ (11) 9123-5358 (11) 9962-4260 www.etcnologia.com.br