Vamos contar histórias ? User Story

Histórias do Usuário (User Storie) são unidades de entrega com foco em valor tipicamente usadas em projetos ágeis para documentar os requisitos, que devem ser escritos pela perspectiva dos usuários ou envolvido (stackeholder), esclarecendo para quem será o maior valor, o que deve ser feito e porque este requisito possui valor.

QUEM? Cada User Story deve antes de mais nada indicar quem é o usuário que vai utilizar e por isto tem o maior interesse neste requisito;
O QUE? Exatamente o que o interessado quer, precisa ou gostaria que este requisito lhe proporcionasse, pelo prisma de sua interação;
POR QUE? Afinal, é o porque ela existe a principal informação, aqui temos o valor que estará sendo entregue através desta User Story.

“Como <QUEM?> eu [quero|preciso|gostaria] <O QUE?> para <POR QUE?>.”

  • Como usuário eu quero poder fazer uma busca digitando os termos em um único campo para ser tão fácil como o Google;
  • Como vendedor eu preciso reportar uma venda através de um formulário simplificado pela web para fazê-lo de qualquer lugar;
  • Como anunciante eu preciso ter acesso aos números de audiência para poder avaliar o retorno do investimento.

VISÃO, ÉPICOS e HISTÓRIAS? A cada reunião ou técnica para elicitação de requisitos, estes podem coletar inicialmente uma Visão de alto nível daquilo que  queremos, talvez chegar aos Épicos, uma abstração ou funcionalidade, com maior ou menor granularidade, finalmente temos as Histórias com o detalhamento de uma interação específica do usuário com o sistema.

USER HISTORY? Ao detalharmos cada interação do usuário, o objetivo é fazê-lo em histórias segundo o ponto de vista do usuário que irá utiliza-la, fracionando-a em situações objetivas para determinado fim, simples e claras, passíveis de serem entendidas o suficiente para serem estimadas pelo time antes de iniciar.

Durante o Discovery as User Stories precisam ser detalhadas, idealizado o design, ergonomia, SEO, regras, além dos critérios de aceitação que nortearão os planos de testes e validação, inicialmente responsabilidade do product owner, mas a partir do Sprint Planning toda a equipe é responsável por manter ali centralizadas as suas definições. É a busca do DoR (Definition of Ready)!

agile-software-development-user-story-template

Anúncios

3 Respostas para “Vamos contar histórias ? User Story

  1. Irineu Licks Filho

    Jorge, na minha empresa adotamos o Scrum.
    Temos uma etapa de análise de negócio, onde os analistas conversam com o Cliente para descobrirem as necessidades (pode-se criar as User Stories), porém, não conseguimos fugir da etapa de especificação.
    Nossas regras de negócios são muito complexas, envolvem cálculos, integrações contábeis, etc…Então, o analista de negócio tem que escrever um documento gigante para ser passado ao desenvolvimento.
    Existe outra alternativa para esse caso?

    • Báh, esse tipo de pergunta só teria uma resposta categórica se o meu nível de contextualização fosse vários patamares acima, senão vejamos, no campo das idéias, conheces a técnica de Story Mapping (link 1 logo abaixo)? Ela é usada para o mapeamento daquilo que precisamos ou desejamos seja feito, da mesma forma, podemos usá-la para entender o relacionamento entre as US’s de forma visual.

      Um dos segredos em um Story Mapping baseia-se no uso de linguagem ubiqua (abstraimos a tecnologia) e geramos um mosaico de necessidades e sonhos em linguagem de negócio, a partir dele vamos separando em releases e sprints prováveis, quebrando tudo em sub-grupos priorizados e com objetivos e valores claros a todos, dai tu talvez esteja se perguntando o que foi que eu bebi :o)

      Onde quero chegar é que a co-relação e detalhamento necessários podem ser debatidos e alinhados no que realmente é necessário a cada ciclo de Discovery (link 2 logo abaixo) e não posso ser peremptório ao afirmar que talvez este detalhamento possa eventualmente ser maior que apenas as User Stories da Sprint Zero atual, posto que o que rege isto é bom senso.

      Vem do Lean o princípio ágil de redução de estoque (~ desperdício) e focar no realmente necessário, bases dos conceitos de decisão no último momento responsável, Mínimo Produto Viável e tudo o mais.

      link 1 – https://jorgekotickaudy.wordpress.com/2013/05/24/user-story-mapping-mais-colaborativo-nao-da/
      link 2 – https://jorgekotickaudy.wordpress.com/2012/04/08/discovery-x-delivery/

      Báh, desculpa se não sou mais objetivo, mas desenvolvimento de software são sistemas complexos e é por isso que métodos ágeis são adaptativos, sem entender bem o que é este documento gigante, o produto e empresa, o projeto, a equipe, é difícil responder esta pergunta de forma simples, talvez o grande Luiz parzianello consiga, ele é mágico em Agile Business Analysis.

      Amanhã (18/07) tem reunião do TecnoTalks – http://bit.ly/tecnotalks10 – se quiseres e puderes aparecer, recomendo!

  2. Pingback: Um ano e meio de blog – Obrigado galera! | Jorge Horácio "Kotick" Audy

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s