Ultimamente, com as metodologias ágeis ganhando força, uma
nova forma de capturar requisitos vem sendo discutida e adotada por muitas
empresas – as user stories ou histórias de usuários. Uma user story é um
requisito capturado normalmente em 1 parágrafo que descreve a necessidade de um
usuário de forma breve utilizando uma linguagem comum ao negócio.
Em primeiro lugar gostaria de deixar claro que cada projeto
de desenvolvimento de software tem suas características e que não existe uma
abordagem “certa” para todos os casos. Tendo isso em perspectiva, em quais
situações as user stories se apresentam como uma alternativa mais interessante
que os Casos de Uso?
Exemplo de user story: Como um cliente da loja online eu
gostaria de procurar por itens para adicionar ao meu pedido.
As user stories possuem uma característica que deriva do XP
e das demais metodologias ágeis (de onde a técnica surgiu): as user stories
focam mais na comunicação face-a-face do que na documentação. O que isso
significa? Se o seu projeto, por alguma razão, necessita de uma documento
formal que contemple todas as informações a cerca dos requisitos – tente outra
abordagem pois as user stories sozinhas não trarão o resultado esperado. Não
faça como outros que tentaram adotar as user stories e acabaram com documentos
de 20 páginas para cada história (o que não faz o menor sentido chamar de
história...).
Ao meu ver, o fato de não fornecer uma documentação completa
dos requisitos é uma das vantagens de se
utilizar user stories. Essa técnica ajuda a estabelecer uma comunicação clara
no time. Ao invés de ser uma forma muito especializada de capturar requisitos,
que exige um especialista para aplicá-la corretamente, as user stories podem
ser elaboradas e compreendidas por qualquer membro da equipe de projeto. Nesse sentido, essa técnica fortalece a
colaboração pois ela exige que os membros da equipe conversem para que a user
story seja compreendida por todos.
Outro ponto importante é que as user stories são pequenas e
simples e não capturam muitos detalhes. E exatamente por deixar de fora
detalhes de implementação, como a navegação no sistema, a user story requer
muito pouca manutenção, não se tornando um documento obsoleto rapidamente ou
que exija muito esforço para mantê-lo atualizado.
Acima de tudo, as user stories ajudam a transformar um
grande problema (que o sistema irá resolver) em pequenas partes. Essas partes
são utilizadas para guiar o desenvolvimento. Dessa forma, as user stories
possibilitam o desenvolvimento iterativo, permitindo que a equipe do projeto
faça pequenas entregas evolutivas enquanto interage e colabora com o cliente.
E os Casos de Uso? Normalmente, os casos de uso contrapõem
os falhas das user stories sendo mais indicados para projetos grandes e
complexos, onde a interação com o cliente (usuário) não possa ser tão frequente
quanto exigido pelas user stories. Mas os casos de uso cobram seu preço por
fornecer uma maneira mais estruturada de capturar e descrever os requisitos do
usuário. Primeiramente, aprender a técnica de casos de uso leva um pouco mais
de tempo. Muitas equipes acabam se perdendo em detalhes de como aplicar a
técnica e com isso não consegue usufruir dos benefícios.
Conclusão: para equipes que estão começando com o desenvolvimento
iterativo (ou com alguma metodologia de desenvolvimento ágil) e que ainda não
estão muito familiarizadas com casos de uso, as user stories são a opção mais
natural. Os casos de uso aparecem como complemento e evolução das user stories
podendo ser utilizados em conjunto, ou para equipes com maior experiência,
podem substituir as user story.
Nenhum comentário:
Postar um comentário