Será que os Casos de Uso tem lugar

no SCRUM ?
CURTIR6PRINT
19 NOV 2010 3 MIN(S) DE LEITURA

por
 Dan Puckett
SEGUIR
traduzido por
 Marcelo Costa
SEGUIR
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?
Scott Kendrick pergunta:
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 ?