No Scrum, os requisitos são normalmente chamados de user stories. Mas seria CERTO utilizar casos de uso com Scrum? E, em caso afirmativo, sob que circunstância você deveria fazer esse uso?
Será que os casos de uso têm um lugar no Scrum? Minha intuição é que se uma user story foi escrita corretamente, ela é o suficiente para conduzir uma discussão e uma colaboração, e também é o suficiente para o desenvolvimento dos casos de teste.
Em primeiro lugar, não é uma exigência que utilizemos no Scrum user stories ao invés de casos de uso? Não de acordo com Roy Morien:
Scrum não impõe qualquer forma particular de elucidar e registrar requisitos, além das recomendações de conversação face a face, reuniões regulares de posicionamento (onde você pode sentar se você realmente desejar, sessões de planejamento do sprint ou talvez até mesmo a análise das user stories mas acima de tudo prega atividade colaborativa e transparência em geral. Trabalhar com essas orientações, eu acredito que mostra até para você o que você realmente faz.
Sob quais circunstâncias você poderia querer usar user stories? Charles Bradley recomenda:
Costumo aconselhar novas equipes Scrum a usar as práticas de requisitos que eles utilizavam antes dos primeiros meses de sua transição para o Scrum. Aprender Scrum é difícil o suficiente sem ter que aprender um novo processo de coletar requisitos.
Charles Bradley também escreve que, “[...] o Guia Scrum sugere que a maioria das equipes Scrum utilizem [user stories], enquanto alguns times que precisam de “Comportamento de Missão Crítica” precisam fazer uso de [casos de uso]”. Adam Sroka não concorda com esta abordagem:
A experiência convencional é de que as aplicações "críticas" precisam de mais documentação. Eu acredito que isso seja uma sensação falsa. O que as aplicações críticas precisam é de mais (e melhor) verificação. A forma de de fazer isso acontecer é por meio de testes automatizados exaustivos, que a maioria dos times de aplicações "críticas" não fazem por alguma razão que eu não sou capaz de compreender.
Pode ser que exista valor agregado pela documentação por meio de casos de uso fora do âmbito puramente funcional, no entanto. Charles Bradley escreve que:
Bem, eu trabalhei no domínio da aviação por um tempo e, enquanto eu não tinha o conhecimento detalhado para fazer com que isso subisse (ou seja, que requisitos exigem essas coisas), a impressão que eu tive dos nossos esforços de documentar, foi que a finalidade da documentação era menos sobre o processo de auditoria, e mais sobre a de reconstruir a causa e identificar o responsável por um acidente de avião (algumas regulamentações, e alguma proteção judicial). Como tal, alguns documentos necessários ajudaram (protegendo a empresa) nos esforços, e não vi onde os casos de uso poderiam ajudar a provar o seu caso (por não estarem faltando) melhor do que User Stories.
Como todos os aspectos dos métodos ágeis, o valor que os casos de uso trazem para a organização devem ser examinados de perto. O que você está realmente começando a partir do esforço que você dispensa ? Afinal, como Ron Jeffries escreveu: "Eu não conheço muitos seres humanos reais, que eram bons em casos de uso." Se você aceitar que vocês provavelmente não são tão bons escrevendo casos de uso, há alguma outra coisa que você poderia estar fazendo e que daria mais valor a sua organização ?