Podemos definir e organizar os requisitos de um sistema utilizando User Stories (histórias de usuário). User Stories são artefatos de desenvolvimento utilizados em sistemas geridos segundo metodologias ágeis.
Muitas perguntas são levantadas na hora de escrever User Stories, por exemplo:
* User Stories são iguais Casos de Uso?
* Como descrevo minhas User Stories?
* Que tipo de informações podemos inserir nas User Stories?
* De quem e pra quem são feitas?
As respostas para essas perguntas são amplamente discutidas na comunidade Scrum e vamos tentar analisá-las abaixo.
Casos de Uso e User Stories são similares, como é apresentado por Martin Fowler em seu texto Use Cases and User Stories. Ambos são utilizados para organizar requisitos. Porém, enquanto Casos de Uso descrevem ações de interação segundo uma narrativa impessoal entre o usuário e o sistema, User Stories focam nos objetivos do usuário e como o sistema alcança esses objetivos.
User Stories fracionam os requisitos para que seja possível (e mais fácil) estimar o esforço para realizar aquele objetivo. Resumindo, User Stories são descrições simples que descrevem uma funcionalidade e é recomendável que sejam escritas segundo o ponto de vista do usuário.
User Stories devem ser curtas, simples e claras. Devemos conseguir escrevê-las em um simples e pequeno cartão (conhecidos como User Index Cards). Se não há espaço para escrevê-la em um cartão é porquê devemos refiná-la mais, e as dividir em outras User Stories.
Podemos construir User Stories como mostrado na figura abaixo. Especificando o ator, a ação e a funcionalidade desejada.
Ator – O proprietário da User Story. De forma simplista é o usuário, o interessado naquela funcionalidade. Mas é recomendado descrever de forma específica quem é o ator para ser mais fácil identificar o contexto da história dentro do sistema.
Ação – É o que o ator quer fazer. Utilizando aquela ação ele espera alcançar seu objetivo dentro do sistema.
Funcionalidade – É o que o ator espera que aconteça ao realizar a ação. Ou seja, é o resultado de executar a ação segundo a ótica do ator. Também pode ser visto como justificativa.
Alguns aspectos importantes podem ser notados no uso de User Stories:
- Validar se a funcionalidade é realmente necessária antes de incluí-la
- Análise das necessidades reais do usuário
- Ajuda a priorizar o que deve ser feito
- É mais fácil estimar o esforço que será necessário para implementar a funcionalidade
O interessante no uso de User Stories é o foco nas necessidades reais e práticas do usuário.
Imagine um sistema de aluguel de filmes pela internet, onde uma das funcionalidades do sistema é visualizar os filmes disponíveis para locação. Então a User Story para esse caso seria:
Agora, imagine o seguinte: além de visualizar os filmes disponíveis para locação, seria interessante que o cliente pudesse reservar também o filme desejado. Nesse caso a User Story seria:
A pergunta é: será que essa User Story é realmente útil agora de forma a atender ao que os usuários desejam mais nesse momento?
Perguntas como essa surgem constantemente no processo de planejamento das sprints e cabe ao PO pensar sobre a necessidade de implementar ou não tal funcionalidade nesse momento.
O cenário descrito acima apresentou como criar User Stories, mas quais são as vantagens em utilizar User Stories? No próximo post daremos continuidade ao assunto – “User Story”- falando também sobre como escrever os critérios de aceitação das User Stories.
Olá, diante de um projeto ao qual existem somente um desenvolvedor, ao qual todo o processo desde a análise, desenvolvimento até a implementação do produto, ao qual o produto não possui dono do produto, sendo o próprio um projeto MVP para testar o mercado, na minha concepção seria válido aplicar somente a fase de elicitação de requisitos, use cases, e diagramas de sequência?
Oi Jean,
não vejo regra específica para isso. O fato da configuração da equipe e do projeto serem conforme você falou não significa que somente determinados modelos ou artefatos precisam ser produzidos.
Eu, por exemplo, não costumo usar, nem recomendar, diagramas de sequência para elicitar requisitos. MAs se você gosta de trabalhar assim, não há problema. Somente tenha cuidado para não envolver o “como” na descoberta do “o que”.
Simplificando, se você está trabalhando somente em um MVP, acho que você precisa fazer os artefatos que efetivamente irão te ajudar a construir o seu “protótipo”. Ou seja, foque na documentação como a mídia da sua solução, não se preocupando tanto com registro das decisões tomadas. Entende?
Boa Tarde!
Como vai?
Tenho uma dúvida. Como fica a criação de histórias do usuário quando não existe usuário, o que existe seria apenas a interação entre sistemas (sem intervenção humana)? Seria como no caso de uso, onde em algumas situações o ator é o próprio sistema.
Desde já, agradeço!
Kennia
Oi Kennia,
de uma forma geral, a perspectiva é sempre de quem, ou o que, usa o sistema. Se você precisa definir histórias aonde o “ator” é outro sistema, a história deve ser escrita sob a perspectiva desse “ator”, que na verdade é quem está usando o sistema. Na prática, alguém que conheça o sistema usuário deve escrever essa história. Seria essa a sua dúvida?
Obrigado por curtir nosso blog.
Aproveite e conheça a nossa ferramenta, o ScrumHalf.
Bom dia!
Agradeço pela atenção! : )
Considerando essa afirmativa “a perspectiva é sempre de quem, ou o que, usa o sistema”, então, é certo afirmar que neste caso o usuário poderia ser o próprio sistema.
Exemplo:
Como um Sistema de Meios de Pagamento
Eu preciso enviar as baixas de pagamento para o sistema de Matriculas dos Alunos
para confirmar os pagamentos das matriculas realizadas
Isso procede?
Att
Kennia Siqueira
Oi Kennia,
acho que você pegou o espírito da coisa. Só para deixar claro, o usuário não seria o próprio sistema, mas outro sistema que interaja com o sistema sendo criado.
Conte conosco. Estamos aqui para ajudar. 🙂
Conheça também a nossa ferramenta, o ScrumHalf. Ela ajuda bastante os times no uso do Scrum.
Um abraço.
Existe algum metodo ou ferramenta para converter user stories em casos de uso?
Oi Fidel,
User Stories e Use Cases não tem formatos rígidos e são bem semelhantes. No seu caso, que tipo de transformação você procura? Ou seja, qual o formato de User Story e de Use Case que você usa?
Como convertemos a lista de requisitos em User Stories? como ficariam os requisitos funcionais e não funcionais neste formato? Com o uso das User Stories faz sentido usar UML para os casos de uso?
Oi Paulo,
Na verdade basta você reescrever os seus requisitos como User Stories, que são muito próximas de Casos de Uso. E pode usar UML a vontade também. Lembrando que a documentação necessária às suas histórias será a que for combinada com o seu time na definição de história preparada.
Você pode assistir a um vídeo sobre User Stories no nosso canal no Youtube, a Universidade Scrum.
Boa tarde!
No caso User Stories, existem documentos de apoio? Por exemplo, as regras de negócios e as regras de interfaces?.
Oi Cristiano.
Não há restrições para o que pode ser usado em conjunto com as User Stories. Na verdade, o Scrum define que o Product Backlog é composto por “itens”. A maioria dos times opta por utilizar User Stories, mas podem ser usados Casos de Uso também, p.ex. Na prática, você pode agregar o que for necessário à forma de trabalho da sua equipe. No próprio ScrumHalf temos uma funcionalidade para anexar arquivos às User Stories. Cuidado somente para não tornar o “item” pesado demais, agregando artefatos desnecessários ou que não ajudarão o trabalho do time, e consequentemente não agregarão valor sob a perspectiva do usuário.
Obrigado pelo comentário e boa sorte em seus projetos.
Adorei!!!
Salvou.
As explicaoes me auxiliaram bastante para desenvolver bem meu trabalho.
Agradeço a ajuda!
Oi Adriana, que ótimo. Em breve liberaremos mais artigos. De nada. 🙂