um dos maiores desafios no desenvolvimento de software é a tarefa quase impossível de reunir requisitos claros e, em seguida, obter esses requisitos para permanecer inalterado durante o desenvolvimento de código. Na abordagem da cachoeira para o desenvolvimento de software—apesar dos esforços para definir, documentar e aprovar todas as contingências possíveis antes do desenvolvimento começar—o produto entregue raramente é o que o cliente quer.a alternativa ágil? Criação de histórias de utilizador.,
uma das maiores vantagens de usar uma abordagem ágil para o desenvolvimento de software é que os requisitos não são definidos em pedra, mas em vez disso são esperados para mudar, com feedback constante dos stakeholders e do negócio. Metodologias ágeis como Scrum e programação extrema (XP) substituem documentos de requisitos tradicionais e longos por um backlog de produto priorizado composto por histórias concisas de usuários, cujos detalhes emergem mais perto de quando a história está pronta para ser implementada.,
embora a criação de histórias de usuário seja mais arte do que ciência, este tutorial lhe dará a informação, exemplos e passos que você precisará para criar histórias de Usuários de alta qualidade.
A história das histórias de usuários
XP introduziu pela primeira vez o conceito de histórias de usuários em 1998, comparando-as com casos de uso. In Object-Oriented Software Engineering: A Use Case Driven Approach, Ivar Jacobson introduced use cases as a way to document requirements by defining interactions between a role (a person using the system) and the system itself to achieve a goal using the Unified Modeling Language (UML).,
esta abordagem foi popular no desenvolvimento orientado a objetos e ainda é usado como um processo chave em frameworks de desenvolvimento de software, tais como o processo unificado (UP), o processo unificado racional IBM (RUP), e o método unificado Oracle (OUM). O uso de casos de uso, ao invés de histórias de usuário, permite o desenvolvimento iterativo e incremental e é considerado uma abordagem ágil para a definição de requisitos.,
com a introdução das histórias de usuário muito mais curtas e a popularidade do XP e Scrum, um backlog de produto composto de histórias de usuários tornou-se a abordagem mais conhecida para a definição de requisitos ágeis. Muitos praticantes ainda pensam que as histórias de usuários são a única abordagem ágil aceitável. No entanto, Alistair Cockburn, um dos Signatários do Manifesto Ágil, prefere casos de uso a histórias de usuários.
embora haja muitas opiniões fortes sobre o Significado de “ágil”, tanto os casos de uso e histórias de usuário são compatíveis com essa abordagem., Alguns dizem que as histórias de usuários eventualmente se tornam semelhantes a casos de uso, uma vez que a equipe concorda com os detalhes da implementação. Nos estágios iniciais, a história do Usuário é simplesmente uma frase curta, mas não está completa até que os detalhes e critérios de aceitação sejam definidos.
criando histórias de usuário
existem opiniões variadas sobre a definição de uma história de usuário e como melhor ir sobre a criação de uma., Algumas orientações para uma boa história de usuário incluem o seguinte:
- deve ser escrito por alguém que representa usuários de negócios (geralmente o dono do produto)
- inicialmente deve incluir uma breve descrição do “quem, o quê e por que,”mas não o “como”
- deve produzir uma fatia vertical do código de trabalho
- Ele deve ser pequeno o suficiente para que ele pode ser codificado e testado em uma iteração (geralmente um período de quatro semanas)
Vários modelos, técnicas e siglas são utilizadas para ajudar proprietários de produtos escrever histórias de usuário., Três das técnicas mais comuns são o modelo role-feature-reason, os três C (card, conversation, confirmation), e INVEST (independente, negociável, valioso, estimável, pequeno, testável).
exemplos
diga que está a desenvolver uma aplicação que permitiria aos formadores carregar courseware e atrair estudantes que estão interessados em fazer uma aula. Aqui está como você aplicaria técnicas de história de usuário.,
Role-Feature-Reason
As Mike Cohn of Mountain Goat Software explains, the role-feature-reason template, or RGB (role, goal, benefit), looks something like this:
“As A I want so that .”
embora haja variações, esta estrutura de frases curtas mantém o foco na OMS, o quê e porquê. Isso impede o proprietário do produto de dar à equipe de desenvolvimento muita informação sobre como eles devem implementar uma solução. Concentrando-se na OMS, o quê e porquê, a equipa de desenvolvimento está habilitada a encontrar a melhor solução técnica.,exemplo 1: Fornecer um treinador com a capacidade de adicionar um curso
Como um treinador, eu gostaria de ser capaz de adicionar um novo curso, de modo que eu terei o potencial de atrair novos alunos.
Exemplo 2: fornecer a um estudante a capacidade de procurar por um curso
Como estudante, eu gostaria de ser capaz de procurar as ofertas de curso, para que eu seja capaz de encontrar uma oferta que mais me interessa.
O papel (OMS)
O papel descreve quem irá beneficiar desta função. Note que o papel não é simplesmente “o usuário”.,”Existem diferentes tipos de usuários, e por isso queremos que o papel seja mais específico do que “usuário”, mas descrever o tipo de usuário que se beneficiará com a história. Os proprietários de produtos são muitas vezes incumbidos de entrar na mente de seus usuários, a fim de entender o que seria mais valioso para eles.
exemplo 1 Função = formador
Exemplo 2 Função = estudante
A característica (o que)
Este passo descreve muito brevemente o que o Utilizador quer. Isto representa mais de perto a exigência que você descreve no desenvolvimento de software tradicional., No entanto, você quer ter cuidado para não ser muito específico ou descrever como escrever o código. Isso será determinado eventualmente, mas não quando você primeiro criar a história do Usuário. A história do Usuário deve ser escrita a partir da perspectiva do usuário que vai se beneficiar da função, não a partir da perspectiva do desenvolvedor que vai codificá-la.
Recurso de exemplo 1 = adicionar um novo curso
Recurso de Exemplo 2 = procurar as ofertas de curso
A razão (porque)
finalmente, queremos indicar por que o Utilizador quer esta funcionalidade. Qual o valor que o usuário obterá dele?, Isso ajuda o proprietário do produto a avaliar como priorizar a história do usuário no backlog. Se o valor ou benefício não pode ser articulado, pode ser algo que não é necessário. Compreender o valor muitas vezes ajuda a equipe de desenvolvimento a encontrar maneiras inovadoras de implementar o código, a fim de resolver os caminhos objetivos que podem ser diferentes do que o proprietário do produto tem em mente.,
Exemplo 1 Razão = atrair novos alunos
Exemplo 2 Razão = encontrar uma oferta que mais me interessa
Os Três C: Cartão de Conversa, a Confirmação
Os Três C fórmula, desenvolvida por Ron Jeffries, ajuda-o a chegar a um acordo entre a empresa e a equipe técnica sobre o significado da história de usuário. Os três C os guiam através da elaboração progressiva de uma história, de uma breve declaração a uma história de usuário totalmente desenvolvida.,
Card
A história do usuário começa propositadamente breve, com uma declaração simples que poderia caber em uma placa de índice 3×5, normalmente seguindo o formato de função-característica-benefício que acabei de cobrir. Por exemplo:
Como treinador, eu gostaria de ser capaz de adicionar um novo curso, para que eu tenha o potencial de atrair novos alunos.embora a história do usuário Comece como uma declaração simples, os detalhes devem emergir antes que a equipe comece a trabalhar na história., Em vez de descrever o que é necessário na documentação, a equipe incluirá 1) representação do negócio (geralmente o proprietário do produto), e 2) a própria equipe de desenvolvimento, incluindo desenvolvedores, testadores, analistas de negócios, ou qualquer outra pessoa na equipe.
esta conversa permite que a equipe de desenvolvimento faça perguntas para garantir que eles tenham uma compreensão clara do que está sendo pedido e do valor que está sendo fornecido. Por exemplo:
desenvolvedor: o formador terá de carregar o courseware para um website?,
Proprietário do produto: não, o treinador estará apenas adicionando informações sobre o curso que será oferecido, e o recurso deve incluir uma forma de o estudante entrar em uma lista de interesse. Esta história dá ao treinador a capacidade de anunciar um curso.Desenvolvimento
: Quais os campos que devem ser incluídos?proprietário do produto: título do curso, resumo, datas e horas, localização.desenvolvimento: isto será apenas para a publicidade de classes cara-a-cara?proprietário do Produto: sim., Podemos adicionar uma opção de classe virtual mais tarde, mas esta história só irá cobrir a adição de informações do curso para ofertas de classe cara-a-cara.
desenvolvedor: que informação deve ser recolhida quando um estudante potencial pede para entrar numa lista de interesses?proprietário do Produto: Nome, Número de telefone e endereço de E-mail.
a equipa irá actualizar a história do utilizador com a informação que recolheu da conversa, e irá discutir a implementação—ou o “como”—que muitas vezes cria tarefas específicas que devem ser feitas para completar a história., Embora a história do usuário seja escrita a partir da perspectiva do usuário, a equipe de desenvolvimento escreve as tarefas para os desenvolvedores e inclui os detalhes de implementação técnica.
confirmação
a equipe de desenvolvimento precisa ter uma compreensão clara de como o recurso irá funcionar em diferentes situações, incluindo condições de erro. Eles precisam obter confirmação sobre os critérios de aceitação do proprietário do produto. Estes são os critérios que devem ser cumpridos para que a história seja considerada feita e aceita., Aqui está um exemplo de critérios de aceitação:
- um treinador é capaz de adicionar um novo curso, inserindo o título do curso, abstrato, datas e horas, e localização para um formulário e pressione um botão “Adicionar curso”.
- se faltarem alguns campos ou se faltarem datas ou horários inválidos, aparecerão mensagens de erro.
- Uma vez que o curso tenha sido devidamente adicionado, ele será exibido publicamente no site do curso e haverá um botão para um estudante expressar interesse.,
- o botão de interesse permitirá que um usuário digite nome, endereço de E-mail e número de telefone, e estes dados serão armazenados e associados com o novo curso.
INVEST: the attributes of a solid user story
INVEST is an acronym that helps evaluate whether you have a high-quality user story. Aqui está como os atributos do acrônimo se aplicam à história em que temos trabalhado.
I = independente-esta história pode ser completada pela equipe? Queremos que a equipe seja capaz de completar toda a história em vez de ser dependente de uma equipe diferente para fazer o GUI, por exemplo.,
N = negociável—a história não é tão detalhada a ponto de descrever exatamente quanto tempo os campos devem ser ou dar detalhes sobre formatos de data e afins. Muito provavelmente haverá rotinas ou bibliotecas comuns que permitirão que a equipe de desenvolvimento implemente da forma que faz mais sentido para eles.
V = valioso—o proprietário do produto descreve que o valor a ser procurado é a capacidade do treinador para ser capaz de anunciar as próximas classes. Isto está claro no” porquê ” da declaração original e ressaltado na conversa.,
E = estimável—a equipe fará perguntas suficientes e reunirá os detalhes para se sentir confiante em sua capacidade de estimar a história.
S = pequeno—a equipe precisa se sentir confiante de que eles serão capazes de completar a história dentro de um sprint. Se não o fizerem, podem dividir a história. Por exemplo, em nossa história de amostra, eles podem decidir fazer com que a capacidade de reunir a informação do estudante seja uma história diferente e simplesmente exibir informações sobre a classe para esta história.
T = testável-com critérios de aceitação claros, tanto o caminho feliz como as condições de erro podem ser testados.,
alinhando-se a uma visão
eu cobri o básico de criar uma história de usuário, mas você ainda precisa entender o quadro geral antes de criar suas próprias histórias de usuário. Há muito trabalho que você deve fazer na frente, em um nível superior, para determinar quais as características de maior valor são que devem ser entregues aos clientes. Essas são, em última análise, decompostas em histórias de usuários.
é importante para a equipe entender primeiro a visão de alto nível e garantir que as características, e, em última análise, as histórias do Usuário, se alinham a essa visão de alto nível.,
normalmente, você divide o produto em grupos que vão por nomes como” temas “ou” características.”Embora a rotulagem destes itens de backlog possa diferir dependendo do método ágil e ferramentas que você usa para descrevê-los, a idéia é certificar-se de que eles se alinham para que o trabalho possa ser rastreado até a sua visão, o que irá garantir que você está cumprindo os objetivos e valores da visão do produto.
novamente, não inicie um projeto criando histórias de usuário; Comece por criar uma visão., Para o nosso exemplo, eu simplesmente mostrar uma demonstração de visão, que leva a algumas características de amostra, que podem ser decompostos em histórias de usuário.
visão
proporcionar um site de alta qualidade que permitirá aos formadores publicitar os cursos e permitir que os alunos façam esses cursos.
características
- fornecer uma página de oferta de curso que permitirá que os alunos se inscrevam para os cursos.
- forneça uma home page que irá dizer aos usuários sobre o que o nosso site é tudo.
- fornece um processo de registro que permite aos usuários fazer login, criar um perfil e manter o controle de suas classes.,
- forneça um blog que irá ajudar a anunciar as nossas ofertas e ganhar publicidade para o nosso site.
histórias de utilizador
- fornece ao formador a capacidade de adicionar um curso na página de oferta de curso.
- fornece aos estudantes a capacidade de procurar um curso.
no exemplo acima, você pode ver como as histórias do Usuário se originaram. As histórias do Usuário foram parte de um recurso para “fornecer uma página de oferta de curso” que se alinha à visão de alto nível.,
mapeamento de Impacto
embora o alinhamento com uma visão o ajude a preencher o seu backlog inicial, não é a única forma de o fazer. Existem muitas ferramentas e técnicas que os gerentes de produtos podem usar para criar as histórias que vão em um novo backlog e que se alinham com a visão.uma técnica de planejamento estratégico usada para ajudar a entender o quadro geral, mapeamento de impacto, foi popularizada por Gojko Adzic, autor de cinquenta ideias rápidas para melhorar suas histórias de usuário e mapeamento de Impacto: fazer um grande impacto com produtos de software e projetos., Mapeamento de impacto é um mapa mental que começa com o objetivo, que deve abordar a questão do valor e por que você está construindo o produto.
O próximo nível lista os “atores”, ou pessoas que ajudarão a alcançar o objetivo. Em seguida, o mapa lista os comportamentos, ou “impactos”, que os atores irão realizar para ajudar a alcançar esse objetivo. O nível final do mapa apresenta os “resultados” que a equipe pode implementar. Estes permitem e apoiam os actores criar os impactos desejados. É a partir desses produtos que você obtém as características do software e histórias.,objectivo: tornar amplamente disponíveis os cursos que os estudantes irão querer frequentar. actores: formadores, estudantes. impactos: os formadores fornecerão aulas de alta qualidade que interessam aos estudantes; os estudantes fornecerão referências e recomendações.como treinador, quero receber feedback dos alunos, para que possa melhorar continuamente.,como treinador, quero descobrir o que os alunos querem, para que possa adicionar ao meu currículo.como estudante, quero encontrar aulas que me interessem mais.” ” como estudante, eu quero encontrar aulas que eu sou capaz de fazer online, de modo que eu não vou precisar viajar.”
mapeando histórias de usuários desta forma permite a rastreabilidade no processo de pensamento de como as histórias finalmente criam valor e como você as usa para atingir o objetivo final., A idéia não é implementar tudo, mas encontrar o caminho mais curto através do mapa para alcançar o seu objetivo.
dividir histórias
um dos problemas mais comuns que as equipes ágeis enfrentam é quando as histórias são muito grandes e não podem ser completadas em uma iteração. Quando a equipe cria as tarefas associadas com a história, eles percebem que há muitas incógnitas, ou que as tarefas envolvidas vão levar mais tempo do que a equipe tem disponível em uma única iteração. As equipas às vezes abordam isto dividindo uma história maior em histórias mais pequenas.,
lembre-se, no entanto, que você quer uma história de usuário para entregar software de trabalho que irá adicionar valor para o usuário. Ao invés de criar uma história de usuário que irá apenas parcialmente completar uma função, dividir histórias em “fatias verticais” que irá entregar funcionalidade de ponta a ponta.
voltar para a comunidade para uma aprendizagem mais profunda
soluções detalhadas sobre como resolver os problemas mais difíceis relacionados com os requisitos e histórias de usuário são únicas para cada situação. No entanto, uma característica comum dos praticantes ágeis bem sucedidos é que eles estão ansiosos para ajudar os outros e compartilhar o que eles sabem.,o site do userStories de Cohn permite que aqueles que trabalham com backlogs de produtos e histórias de usuários compartilhem produtos, recursos e conhecimento. A página de produtos inclui uma lista impressionante de ferramentas, muitas disponíveis gratuitamente, com oportunidades para comentários e entrada de usuários. Cohn observa no site que ele espera expandir o site para que os backlogs do Produto possam ser compartilhados.
nunca haverá uma resposta de tamanho único sobre como escrever histórias de usuário perfeitas., No entanto, com o tempo, com uma mistura saudável de experiência, conselhos dos especialistas, e experimentação com ferramentas e técnicas sugeridas, você pode melhorar continuamente.