O que deve ser feito primeiro: casos de uso ou histórias de usuários?

Ouvi falar de casos de uso (estou falando da descrição, não do diagrama) e de histórias de usuários que estão sendo usadas para reunir requisitos e organizá-los melhor.

Como trabalho sozinho, estou apenas tentando encontrar a melhor maneira de organizar requisitos, entender o que deve ser feito no desenvolvimento. Não tenho nem preciso de nenhuma metodologia formal com documentos enormes e assim por diante.

Histórias de usuários Parece que estou sendo usado para criar o backlog do produto, que contém tudo o que precisa ser feito no desenvolvimento.

Os casos de uso, por outro lado, fornecem uma descrição de como as coisas são feitas no sistema, o fluxo de interação entre atores externos e o sistema.

Parece-me que, para um caso de uso, existem várias histórias de usuários.

Isso me leva à seguinte pergunta: ao descobrir requisitos, o que devo fazer primeiro? Encontrar e escrever histórias de usuários ou encontrar e escrever casos de uso? Ou eles devem ser feitos "ao mesmo tempo" de alguma forma?

Na verdade, estou bastante confuso. Em relação aos casos de uso e histórias de usuário, para um desenvolvedor que trabalha sozinho, o que é um bom fluxo de trabalho, usar essas metodologias corretamente para ter um melhor desenvolvimento?

Casos de uso e histórias de usuário são ferramentas para reunir e expressar requisitos.
Como você já descobriu, um único caso de uso tem tipicamente um escopo mais amplo que uma única história de usuário, porque tenta descrever completamente uma interação do usuário, incluindo erros e desvios do caminho normal. Uma história de usuário pode ser comparada aproximadamente a um único fluxo através de um caso de uso.

Como em todas as ferramentas, você deve usar as ferramentas que considera necessárias em uma situação específica. Isso significa que você pode usar apenas casos de uso, apenas histórias de usuário ou uma combinação de casos de uso e histórias de usuário como achar melhor.

Está se tornando cada vez mais comum usar histórias de usuários como a unidade de trabalho do que pode ser desenvolvido e entregue em uma iteração / sprint.
Com isso em mente, eu não focaria muito na coleta de requisitos como casos de uso, a menos que os casos de uso ocorram naturalmente ao conversar com as partes interessadas.

No meu caso, sempre achei que o nível de detalhes necessários para casos de uso completos acontecia pensando primeiro nas histórias de meus usuários. A primeira pergunta que faço é "o que as pessoas precisam ser capazes de fazer?". Depois de ter os cenários, é mais fácil começar a analisar todos os casos de uso e variantes de fluxo do sistema.

Dito isto, para um único desenvolvedor que trabalha sozinho, você realmente não precisa se preocupar se é um caso de uso ou uma história de usuário ou um adesivo na parede que diz "não se esqueça do 'x'". O que você precisa é de qualquer processo que faça você pensar no que seus usuários estão tentando alcançar e o ajudará a rastrear as diferentes coisas que eles precisam poder fazer. Tudo o resto depende de você quanto ao nível de detalhes que você precisa anotar para planejar seu desenvolvimento.

Por exemplo, quando trabalho em um projeto paralelo solo, minhas tarefas de trabalho são mais ou menos assim:

1. Conecte-se
2. Ver a lista de 'foo'
3. Salvar seleções da lista
4. Procurar

Honestamente, cada um deles não teria nada mais do que uma estimativa. Por quê? Porque estou apenas usando-os como um lembrete do que preciso para que o usuário faça e vou descobrir os detalhes quando chegar a essa parte. Com uma equipe de uma única pessoa, tudo pode estar na sua cabeça e tudo bem, porque você não precisa comunicá-lo a mais ninguém.

Agora, existem advertências ...

Desenvolvedor único trabalhando com outros especialistas

Você precisa relatar o progresso para outra equipe? Você tem testadores que precisam validar seu trabalho? Você tem um gerente que quer saber o que fez? Você tem um gerente de projeto que precisa prever uma linha do tempo? Você tem um proprietário do produto que está determinando os recursos necessários?

Se essas pessoas fazem parte do seu projeto, você precisa garantir que suas tarefas de trabalho tenham informações suficientes sobre elas para permitir que elas façam seu trabalho. O PM provavelmente precisa de uma maneira de ver tamanhos relativos das coisas e progredir nesse trabalho. Seus testadores precisarão de detalhes sobre como as coisas devem fluir (casos de uso) e você pode até pedir para ajudá-lo a escrevê-las. A gerência pode querer saber em que está trabalhando, portanto, você precisará de uma descrição comercial suficiente para que eles possam entender os recursos que você fornecerá.

Se você respondeu "sim" a todas essas perguntas, provavelmente precisará ter uma lista de pendências mais rigidamente documentada, pois a usará para se comunicar com os outros membros da sua equipe.

• Você provavelmente precisará ter o conceito de 'Épicas' ou 'Recursos', que serão a funcionalidade de alto nível que você pode usar para relatar à gerência ou aos proprietários do produto.
• Você aninhará Histórias de usuário nessas Epopeias / Recursos que definirão os blocos menores de funcionalidade que serão usados ​​para comunicar o progresso com o gerente de projeto, definirão as tarefas de trabalho em um sprint e serão usados ​​para comunicar o objetivo de negócios ao equipe de teste.
• Você terá casos de uso ou casos de teste definidos para as histórias para capturar as várias decisões de fluxo de baixo nível necessárias para garantir que você, os negócios e a equipe de teste estejam alinhados e saibam o que será aceito como 'correto'.

Todos os itens acima podem ser ignorados se você definir o trabalho, gerenciar o progresso, testar o software e decidir se algo está 'correto'. Reduza o esforço extra e verifique se está fazendo o que é importante: criar software de trabalho!

Se você está fazendo algum tipo de agilidade, a resposta dogmática é: faça o que funciona para você.

O processo deve fazer parte de suas retrospectivas. Você deveria estar falando sobre gargalos, redundâncias, problemas de comunicação, documentos que ninguém nunca lê, etc.

Na minha experiência, gerentes de projeto, analistas e "pessoas de negócios" são treinados para executar o processo "de dentro para fora". Eles reúnem requisitos, que geralmente são dados verbalmente pelas partes interessadas na forma de história do usuário. Eles fazem perguntas para esclarecer, para que possam criar documentos detalhados de "casos de uso", que a equipe de desenvolvimento tenta converter de volta em histórias de usuários nas quais eles podem repetir ...

Minha recomendação, com base em minha própria experiência: tente levar sua equipe ou analista ou quem colocar as histórias dos usuários diretamente no backlog, com o mínimo de detalhes. Inclua informações prioritárias e descreva o "problema" que a história pretende solucionar. Talvez liste algumas soluções em potencial ... mas, além disso, deixe que os "casos de uso" surjam à medida que seus desenvolvedores interagem com o controle de qualidade e / ou com as partes interessadas nas histórias.

Registre os casos de uso em que você chegou na documentação à medida que a história é resolvida, em qualquer formato que ajude as pessoas a entender o sistema.

Histórias de usuário e casos de uso não são mutuamente exclusivos e não há "deveria" .

São apenas ferramentas que podem ou não ser úteis para aprimorar seu processo em algum momento. Há muitas maneiras possíveis, eu apenas proporia uma com casos de uso e histórias usadas juntas:

• Para backlog e planejamento, tente histórias de usuários como espaços reservados para recursos de alto nível. (É claro que os casos de uso até o nível da meta do usuário também podem ajudar.)
• Para documentar os requisitos já implementados, os casos de uso funcionariam como os melhores.

Depende . Se você estiver trabalhando sozinho, tente abordagens diferentes e adote o que funciona melhor para você.

Isenção de responsabilidade: Existem muitas metodologias para escrevê-las. "Histórias de usuários" têm uma definição muito comum, enquanto "Casos de uso" podem ter significados muito diferentes. Refiro-me aos diagramas UML clássicos, que são muito comuns.

Histórias de usuário ou casos de uso

Na minha experiência, existem diferentes tipos de mentalidades sobre como melhor compreender. Então, eu decidia em cada nova equipe do projeto como documentar os requisitos. Geralmente, uma combinação é comum, usando Casos de Uso para a visão geral e histórias de usuários para detalhes.

• Os casos de uso , especialmente como diagramas, são mais adequados para pessoas que pensam visualmente
• As histórias de usuários são preferidas por pessoas que pensam em discussões muito faladoras

(isto é baseado em opinião, sem fundamento científico)

O que fazer primeiro?

Ao escrever os requisitos para um projeto, começaria em um nível muito abstrato. Usando casos de uso, você pintaria um diagrama (UML-) com os objetivos globais do projeto. Nas histórias de usuários, escreva algumas "histórias épicas" descrevendo os principais objetivos.

Um segundo passo seria entrar nos detalhes. Fazendo isso, você deve tentar manter uma referência a uma "história épica" ou a uma meta global. Isso ajuda a estruturar muito os requisitos.

Vou olhar para o contrário: o que precisa vir por último?

O último passo é que você (ou outra pessoa) insira requisitos no seu backlog. Os requisitos devem ser tais que você saiba como o código que você escreve deve se comportar e para que os testadores possam verificar se seu código se comporta da maneira que deveria.

Esses requisitos podem muito bem ser registrados na forma de uma história de usuário bem definida. Portanto, a história do usuário pode ser o último passo. Os casos de uso geralmente se transformam em mais de uma história do usuário, portanto, eles devem ser apresentados antes da história do usuário.

Eu costumava pensar que os Casos de Uso eram voltados para a abordagem em cascata, enquanto as Histórias de Usuário vinham com o processo Agile. Levei um tempo para perceber que eles não são exclusivos.

Como você não precisará compartilhá-los, não será sobre comunicação, exceto consigo mesmo. Contanto que você possa entender suas anotações uma semana mais tarde, você estará bem. Caso contrário, adicione mais detalhes ao observar os requisitos.

Você precisa de uma maneira visual e flexível para acompanhar seu progresso e definir prioridades? Nesse caso, as Histórias de usuário seriam úteis, juntamente com o quadro de progresso, que você encontrará na maioria das metodologias ágeis (todo, feito, sprint atual).

Quando se trata de requisitos puros, sabendo o que precisa ser resolvido e como, sugiro começar com User Stories, pois elas são fáceis de criar (uma frase) ou um Diagrama de Casos de Uso listando apenas atores e ações de alto nível.

Quando os detalhes forem necessários, faça uma busca detalhada com mais histórias de usuário. Ao encontrar um processo complexo (ramificação, muitos condicionais e pré-requisitos), você pode vincular a história do usuário a um caso de uso, independentemente de usar um diagrama ou a versão do modelo de texto. E lembre-se de que mesmo esses podem ser criados com vários níveis de detalhes. O livro Requisitos de Software de Karl Wiegers & Joy Beatty recomenda manter apenas o nível de detalhe necessário para entender. Se algo é totalmente óbvio para você, você não precisa detalhar.

A descrição acima é o que eu pessoalmente não entendi no início: as Histórias de Usuário são um ponto de partida, um "resumo", mas cada uma pode ser complementada por documentos adicionais para definir melhor o que é necessário e necessário, incluindo Casos de Uso detalhados, quando necessário.