História do Usuário x Requisito

A história do usuário captura o que o usuário deseja fazer com o sistema em um nível alto. Entendo que a história do usuário direcionaria ainda mais vários requisitos de baixo nível. A história do usuário é o mesmo requisito de alto nível para o sistema?

Para ser sincero, depois de passar quase dois anos imerso no desenvolvimento Agile, ainda acho que "história do usuário" é apenas um termo sofisticado para "requisito funcional".

É diferente em um nível superficial , por exemplo, sempre assume uma certa forma ( "como X, quero Y para que Z ..." ), mas os elementos-chave - identificando a parte interessada e a lógica - também são inerentes ao bem-estar. requisitos funcionais escritos. É tão fácil escrever uma história ruim para o usuário quanto escrever um requisito ruim ( "como [o nome da empresa], eu quero [recurso vago] para que eu possa [fazer algo que evidentemente faz parte do meu trabalho, como 'vender mais para os clientes'] " ).

Na minha experiência, o que as histórias de usuários quase nunca capturam são requisitos não funcionais , como desempenho e segurança. Esses tipos de requisitos são muito difíceis de escrever corretamente e o formato da história do usuário simplesmente não é muito bom para capturá-los, porque eles são mais sobre qualidade geral do produto e mitigação (mas não eliminação) de riscos, em vez de atender a um usuário específico. precisar.

Então, eu realmente penso nas histórias de usuários como um subconjunto de requisitos, com uma fórmula específica, e ainda uso os termos de forma bastante intercambiável.

A principal vantagem das histórias de usuários sobre os requisitos é que a palavra "requisito" sugere que um recurso é necessário onde geralmente é apenas desejado . As histórias de usuário podem, em teoria, ser priorizadas e inseridas em qualquer versão, enquanto os requisitos parecem ser um pré-requisito para cada versão.

Obviamente, para que a distinção mencionada seja importante, seus clientes e / ou gerência sênior devem adotá-la; não adianta nada se você tiver 30 histórias de usuários agrupadas em um "projeto" que deve ser concluído ao mesmo tempo. Você também pode chamá-los de "requisitos" nesse caso, porque eles são de fato necessários.

Ron Jeffries escreveu há muito tempo sobre os 3Cs de histórias de usuários ( http://xprogramming.com/articles/expcardconversationconfirmation/ ), com ênfase em um cartão (breve descrição), conversa entre os clientes e a equipe de entrega, uma vez que uma história de usuário torna-se acionável e a confirmação acordada de uma história após essa conversa.

essencialmente, antes da conversa, as histórias dos usuários são apenas o escopo planejado - idéias aproximadas sobre o que poderíamos fazer. após a conversa, você deve confirmar que a história está completa. Portanto, dependendo do momento em que você olha a história nesta linha do tempo, uma história pode ser apenas uma idéia ampla sobre o escopo ou um requisito detalhado.

hoje em dia, o significado de "história do usuário" parece ser limitado apenas à parte "cartão" dos 3Cs de Jeffries. nesse caso, uma história de usuário não é um requisito, mas uma promessa de manter uma conversa sobre os requisitos.

Você pode encontrar uma tonelada de pepitas de ouro de sabedoria sobre histórias de usuários no wiki do c2 ( http://xp.c2.com/UserStory.html )

Histórias de usuário e requisitos são bestas muito diferentes.

Exigências

Os requisitos pressupõem que o design do aplicativo seja feito antecipadamente e que o desenvolvimento seja a implementação desse design. Portanto, os requisitos se concentram em como implementar uma funcionalidade.

Exemplo de requisito:

• Crie um formulário de contato do usuário com os seguintes campos: nome, sobrenome, email, texto livre e um botão de envio. Quando o botão enviar é pressionado, um email é enviado à nossa equipe de suporte.

Histórias de usuários

As histórias do usuário concentram-se no que alcançar e insistem em que o design do produto seja feito no último minuto e seja uma colaboração entre uma pessoa do produto e uma pessoa do desenvolvedor. Os detalhes são decididos durante a implementação com base na oportunidade.

Exemplo de uma história:

• Como Jimmy, o usuário, quero entrar em contato com sua equipe de suporte quando não puder usar o site corretamente para que eles possam me ajudar.

Qual é a diferença?

Como você pode ver, certamente há uma diferença na quantidade de detalhes fornecidos, mas também há muitas informações disponíveis apenas na história, ou seja, o objetivo que estamos tentando alcançar com esse recurso.

Embora possa parecer que o objetivo seja relativamente sem importância, essa é uma suposição errada no desenvolvimento ágil. Normalmente, existem dois casos em que conhecer o objetivo é muito importante: reduzir o custo de oportunidade e permitir agilidade.

Custo de oportunidade

Se houver suposições ocultas no requisito, pode ser muito difícil de alcançar. Por exemplo: existe um servidor de correio disponível? Caso contrário, o requisito poderá levar muito mais tempo para ser desenvolvido. Em alguns outros casos, uma maneira mais simples de alcançar o mesmo objetivo pode ser perdida por causa do design.

Por outro lado, a história do usuário é sobre um usuário entrando em contato com nosso departamento de suporte. Se o envio de um email for inviável ou muito caro, podemos criar uma solução diferente no local: escrever em um banco de dados, por exemplo, ou usar um formulário via documentos do Google, ou simplesmente colocar um endereço de email em vez do formulário. Isso não pode ser feito facilmente com um requisito, mas é fácil com uma história e uma pessoa do produto presente.

Agilidade

Por esse motivo, com os requisitos, geralmente tendemos a pensar nessas suposições ocultas antecipadamente e a garantir que não haja problemas. Portanto, nesse caso, pode haver um requisito diferente, agendado previamente, que garante a presença de um servidor de correio.

Isso nos leva a outra enorme diferença entre histórias e requisitos, que é a hierarquia . Como exemplifiquei acima, os requisitos devem, por sua própria natureza, ser ordenados em alguma hierarquia natural para que as dependências sejam atendidas. As histórias, por outro lado, concentram-se no propósito e não têm tais restrições.

Isso ocorre por design, já que no ágil é de fundamental importância adicionar, remover, reagendar e modificar histórias, conforme necessário durante a execução do projeto. Os requisitos geralmente podem ser adicionados, às vezes modificados ou removidos, mas geralmente é muito doloroso movê-los por causa de todas as dependências. Simplesmente não é feito com muita frequência. Se você estiver trabalhando com requisitos, sua implementação ágil sofrerá, ou provavelmente não será muito ágil, no sentido de poder abraçar a mudança.

Para mim, um elemento crítico de uma história de usuário é que ela captura por que e como um usuário usa o sistema. É especialmente útil porque não especifica muito na maneira como o sistema entrega a funcionalidade necessária. Quando testes de interface do usuário e usabilidade são necessários, a história do usuário pode ser o documento mais importante.

Claro, você pode fazer com que o selênio verifique se certos nós estão presentes no HTML ou faça capturas de tela ou verifique se certos pixels estão onde você espera que estejam. Mas se houver texto enganoso, ou não for aparente como o usuário deve usar o sistema ou for difícil para o usuário descobrir como atingir seu objetivo, de repente você não terá mais um sistema completo. Agora é necessário treinamento para usar o sistema. A revisão do sistema concluído em relação aos cenários do usuário é um componente crítico do teste manual.

Existe uma mentalidade capturada nas histórias / cenários do usuário que deve influenciar muitas decisões detalhadas sobre o projeto sobre a implementação. A menos que os desenvolvedores conversem diretamente com os usuários ou os assistam usar o sistema, o cenário do usuário pode ser o único link para permitir que eles entendam as necessidades do usuário.

Por fim, eles permitem que as pessoas de negócios especifiquem o que precisam sem sugerir como isso deve ser alcançado. É muito mais fácil descrever uma solução do que uma necessidade, e os cenários do usuário fornecem uma estrutura para descrever as necessidades sem propor uma solução específica. O requisito comercial mais comum que ouvi foi: "Quero que seja exatamente como o Excel, mas na Web", que nunca foi o que eles realmente precisavam.

Então, eu diria que uma boa história não deve incluir detalhes específicos sobre como o sistema deve ser implementado. Deveria dizer: "Uma vez por mês, o sistema A precisa ser atualizado com todos os novos dados do sistema B. Esses dados podem exigir correções. O cliente tem um histórico de entrada de dados inválidos e não percebe o problema por semanas". Não se deve dizer: "O sistema deve aceitar um arquivo CSV latin1 pelo menos uma vez por mês e lançar uma NumberFormatException se a coluna 3 não for um número". Você vê a diferença? O cenário descreve a necessidade, não qualquer solução específica. Em seguida, ao testar, você volta ao cenário para garantir que a solução atenda às necessidades. Os requisitos podem misturar algumas necessidades com algumas soluções ou até se concentrar inteiramente em soluções.

Encontrei isso durante uma pesquisa no google e pensei que eu jogaria minha opinião.

Realmente não há diferença entre um requisito e uma história de usuário. Ambos estão declarando o resultado ou objetivo desejado da perspectiva do usuário.

A única diferença é a maneira como esse objetivo ou resultado é capturado por um analista de negócios. Nesse caso, está no texto.

Exemplo:

Como líder de equipe, quero ver quais membros da minha equipe estão trabalhando em casos de hipoteca para que eu possa monitorar o desempenho deles.

A solução deve exibir membros da equipe trabalhando em casos de hipoteca.

Ambos os itens acima podem ser interpretados da mesma maneira, mas ambos também têm muita ambiguidade. O ponto principal aqui é uma diferença de estilo. Penso que a questão que mais vemos é até que ponto vamos definir a solução antes de sairmos do mundo dos requisitos e do mundo do design funcional. Cabe ao analista de negócios declarar "a lista de usuários logados pelo nome e segundo nome no menu principal do aplicativo" ou é muita informação? Quando estamos conversando com as partes interessadas e todos conhecemos a solução e podemos interpretar como ela será, mesmo a provável linguagem de código em que será criada e a maneira como será implantada, precisamos realmente jogar o jogo purista de " vamos definir objetivos e não soluções ". É aqui que realmente sinto a confusão.

Os requisitos geralmente assumem que nada sabemos sobre a solução apenas resultados desejados. Sim, isso torna tudo a solução agnóstica, mas isso realmente nos ajuda no ciclo de desenvolvimento? Se podemos definir com precisão algo cedo, por que não fazê-lo?

Apesar de tudo, eu não me preocuparia com as histórias de usuários e as diferenças de requisitos. Por fim, você deseja definir informações suficientes para que alguém possa desenvolver uma solução. Uma história de usuário com nível muito alto será simplesmente revertida e solicitada para ser dividida em histórias de usuário menores. O mesmo que o estilo "o sistema deve". As exigências provavelmente serão repassadas por serem ambíguas demais se não tiverem detalhes suficientes.

No final, escolha o que seus desenvolvedores e partes interessadas gostam de ver e trabalhar com isso.

Eu acho que há muita inconsistência no que a palavra requer significa, mesmo nos livros clássicos. A mesma inconsistência se aplica às histórias de usuários. Diferentes organizações e livros didáticos tratam esses termos de maneira diferente. Por exemplo, como o livro clássico de Engenharia de Software de Roger Pressman fala sobre requisitos é bem diferente do livro Agile Software Requirements de Dean Leffingwell. Eu respeito os dois e os dois podem ser válidos.

Os requisitos podem ser coisas que codificamos que têm uma especificidade extraordinária, com pouco que resta à imaginação. Por outro lado, pode-se argumentar que os requisitos devem especificar qual é o problema de negócios e não a solução. Eu acho que é mais sutil e a resposta está em algum lugar de um espectro exclusivo para cada empresa e setor (nem todo desenvolvimento de software ocorre em TI).

Aprendi que a elicitação de requisitos leva à análise, ao design, à arquitetura que leva à elaboração ou especificação de requisitos , que leva a algo que pode ser codificado. Não acredito que isso desapareça com o ágil. O momento em que essas coisas acontecem muda e essa é a diferença mais importante. No modelo em cascata, a elicitação e elaboração acontecem cedo. No lean e no scrum, a elicitação e a elaboração acontecem em vários estágios, com mais elaboração acontecendo à medida que você se aproxima da implementação em um sprint. Assim como o design emergente.

Em nossa organização, estamos nos inclinando para o modelo de Epopeias, Recursos e Histórias de Leffingwell, não como requisitos, mas como detalhamento e priorização do trabalho. Requisitos são uma coisa diferente. Os requisitos são gerenciados separadamente porque somos obrigados a fazê-lo para as agências reguladoras. E, no entanto, algumas equipes certamente estão desenvolvendo requisitos nas histórias de usuários durante o incremento do programa e o planejamento do sprint.

Os requisitos funcionais são geralmente uma especificação formal que permite saber exatamente se o seu software funciona ou não. A história do usuário geralmente é uma maneira muito mais informal de descrever a necessidade de uma história do usuário. Ele não especifica uma especificação rígida para determinar se o software é "válido" ou "inválido". Embora você possa testar parte dela, a conclusão real de uma história de usuário (se você a fizer corretamente) é quando o usuário diz "sim, isso resolve meu problema!". Lembre-se do manifesto ágil:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Em seu livro "User Story Applied", Mike Cohn diz especificamente que algumas coisas não são mapeadas para a história do usuário e você não precisa usar apenas isso.

Na minha própria equipe, usamos o seguinte:

• História do usuário : uma necessidade comercial de algum tipo de usuário. A ênfase aqui está na necessidade e por que ele precisa disso. Como já foi dito, o importante aqui não é especificar como isso é feito e aprofundar a real necessidade do usuário (por exemplo: ele não precisa exibir dados em uma tabela, ele precisa ver o valor exato do dados e ele está familiarizado com a tabela para fazer exatamente isso).
• Bug : Um comportamento inesperado do software que prejudica o uso normal. Geralmente, vem com uma "Importância" (independente da prioridade de desenvolvimento) que classifica o quanto isso afeta o fluxo de trabalho do usuário.
• Dívida técnica. Algo que não impede o uso o uso do software, mas vai prejudicar -nos , os desenvolvedores, no futuro. Exemplo: alguma classe é difícil de ler, a compilação é lenta, algum código não é testado por unidade, o IDE mostra avisos estranhos ...
• Melhoria : uma alteração no software que não permite novos cenários, mas proporciona uma experiência melhor. Exemplo: alterando as fontes, redesenhando um formulário para torná-lo mais claro, adicionando padrão sensível ao aplicativo etc.

Os requisitos funcionais não nos permitem perceber que um recurso que implementamos não resolve a necessidade de um usuário, mesmo que nosso teste de pepino passe e tenhamos implementado todas as palavras escritas. Uma história é uma discussão e é informal. O ponto é que a equipe de implementação entenda qual é o problema. Eles não são uma ferramenta de contrato. Se você faz "scrum but ... " e sua história é simplesmente uma maneira divertida de escrever os requisitos do software, então sim, não há diferença.

O ponto não é a história do usuário, o ponto é a enorme mudança de paradigma na maneira como você aborda o trabalho a ser realizado. Você não está fazendo um contrato, está ajudando alguns usuários a resolver um problema. Se você não vê suas histórias de usuário como uma ferramenta de discussão com um usuário real , não está usando histórias de usuários, está usando uma sintaxe de requisitos divertida .

O resto aqui é a minha opinião: a história do usuário nunca pode ter sucesso de maneira unilateral. Você precisa que seu cliente trabalhe com ele. A queda de água está fadada a ser uma bagunça estranha de requisitos, mas não requisitos. Se você tem um contrato de lance fixo com requisitos específicos, não use iterações e histórico do usuário, não faz sentido . Use o restante do kit de ferramentas ágil: teste de unidade / funcional automatizado, revisão de código, integração contínua, refatoração, etc. Verifique se o software está funcionando continuamente e que você pode enviá-lo a qualquer momento. Disponibilize-o em sua forma inacabada ao cliente para que ele possa dar o máximo de feedback possível. Se você fizer isso, meu amigo, mesmo que não faça "História do usuário" e "Scrum", você teria sido mais ágil do que muitas lojas ditas "Agile".

Acredito que todo mundo implementará e rotulará tudo de maneira diferente, dependendo da experiência passada e não importa o que quer que seja que a linguagem funcione para a empresa que realiza o trabalho.

No entanto, a IMO, Uma história de usuário, segue a abordagem do Agile de "um cliente no edifício ou o cliente está imediatamente disponível", onde a documentação não é necessariamente necessária porque os detalhes estão na cabeça dos clientes e estão prontamente disponíveis para que uma SRS formal possa não é necessário. Agora, uma "Tarefa" de uma "História do usuário" é como um desenvolvedor criará as histórias do usuário de forma digerível.

Um exemplo de história do usuário pode ser:

Como usuário administrador, desejo visualizar os dados de meus clientes listados em uma grade

e uma "tarefa" pode ser:

1. Crie uma grade que lista os dados a serem exibidos

2. Ative a classificação na grade que classificará a coluna selecionada

Agora, cada uma das tarefas é estimada e concluída em seu respectivo sprint.

De uma perspectiva "tradicional", na qual "o cliente é difícil de obter, precisamos escrever isso para que eles possam confirmar que acertamos antes de começar a planejar / codificar" a abordagem, a Especificação de Requisitos de Software é serão as idéias que estavam na cabeça dos clientes e suscitadas e, em seguida, escritas e formalizadas, e então baseladas e gerenciadas.

Nesse caso, um "requisito funcional" é o detalhe essencial dessa SRS e parte da Idéia maior. Portanto, na minha opinião, uma história de usuário pode ser vista como uma (parte do) "Requisito" formal, e a tarefa dessa história de usuário é um (ou um dos muitos) requisitos funcionais.

No exemplo da história do usuário, o "Requisito" formal seria um documento longo com fluxogramas e geralmente será centrado na documentação, em oposição à abordagem mais "Ágil", centrada no cliente.

A diferença é que o "Requisito" formal seguirá as orientações de um documento de 10 páginas que descreve a seção de administração do aplicativo, indicando que serão necessárias algumas listagens, alguma segurança baseada em funções, etc. e, em seguida, algumas das funcionalidades os requisitos serão "as grades de listagem devem permitir a classificação", "as informações do usuário devem ser listadas em uma grade", etc.

e eu acredito que hoje em dia os termos são todos misturados e misturados .. o que não importa