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 ?
Orientação a Objetos
by Vinicius Serpa,
Re: Orientação a Objetos
by Ton Carvalho,
Re: Orientação a Objetos
by Marcelo Costa,
Com ficam as classes?
by Constantino Moura,
Re: Com ficam as classes?
by Marcelo Costa,
Casos de Uso - Perda de tempo
by vitor farias dos santos,
Orientação a Objetos
by Vinicius Serpa,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Eu particularmente costumo utilizar os Casos de Uso e extrair as User Stories através deles. Parto do princípo de Projeto Orientado a Objetos e uso amplamente a UML, só preparo as User Stories porque o Scrum carrega essa prática, caso contrário dispensaria.
Mas se formos pensar que as User Stories é conflitante com os Casos de Usos, posso pressupor que o Scrum não se adapta com Orientação a Objetos? A princípio prefiro pensar que não, prefiro considerar que o Scrum é apenas um modo diferente de gerenciar. A prática poderia continuar a mesma (Orientada a Objetos com Casos e Uso e demais diagramas, estruturada, TDD, MDD, Data-Driven Developement, etc).
Será isso mesmo ou estou com uma visão errada do Scrum?
Re: Orientação a Objetos
by Ton Carvalho,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Ola, eu também utilizo casos e uso e bastante uml, a equipe analiza as estórias, em seguida produz a descriçao do caso de uso não so o diagrama, e então junto a estória + caso de uso com isso tenho bastante informação para o planning poker, pois quando a estória vai para o backlog da sprint ja temos muita informação a respeito doque terá q ser realmente codificado para concluir a estória, isso tem ajudado muito a não termos surpresas, do tipo " nossa achei q essa estória ia ser bem simples e estimei mal, acho q vou demorar muito mais doque tinha pensado!!!"
Re: Orientação a Objetos
by Marcelo Costa,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
As User Stories, no meu ponto de vista, são apenas mais uma técnica. Eu gosto muito da definição do Alistair Cockburn "A promessa de uma conversa". Na realidade, é uma técnica muito útil para adiar o desenvolvimento usando um esforço mínimo quando necessário.
Casos de Uso são uma forma de documentar a interação entre um sistema e seus atores (que podem ser usuários, outros sistemas, ou mesmo o tempo).
Algumas pessoas pensam que user stories representam o inicio e o fim de todas as análises do negócio. Outras pessoas acreditam que os Casos de Uso representam o inicio e o fim de todas as análises do negócio. Nesse sentido, ambas as técnicas são muito semelhantes. Se você está apenas fingindo fazer a análise, ambas as técnicas são quase idênticas (ou semelhantes, como queira).
Pergunte a qualquer analista de negócios com experiência em ambas as técnicas e você vai descobrir que ele considera ambas as técnicas e ferramentas válidas e que juntas acabam fazendo parte de um conjunto de ferramentas muito mais enriquecida. Além disso, você vai descobrir outras técnicas complementares na análise de negócios que incluem diagramas de estado de transição, modelos de negócios, storyboards e definições de regras de negócio ..... e muitas e muitas outras.
Aqui na empresa nós fazemos uso das duas técnicas. Na verdade o desenvolvedor escolhe e trabalha com aquela que ele mais se identifica e consegue entregar mais valor de negócio. São livres para escolher o que fazer. Meu papel é apenas o de garantir que o que foi "acordado" e "inteligível" por ambos os lados, o cliente e o desenvolvedor, será cumprido.
E sim o Scrum se adapta a qualquer metodologia que você possa imaginar basta que para isso você o adapte a sua necessidade. Quem diz para você como será gerenciado é o seu time e a sua garantia de que foi bem gerenciado com Scrum é a satisfação do seu cliente seja ele externo ou interno com o valor de negócio entregue.
Com ficam as classes?
by Constantino Moura,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Como seria possível identificar as classes sem definir corretamente os casos de uso, uma vez que estes indicam os "extends" e os "includes", que capacitam a identificação das classes, que por sua vez capacitam a orientação ao objeto, que por sua vez permite as reutilizações, heranças, etc. Não percebo um grande sistema, tipo um ERP apenas definido por Users Stories, me desculpem pela ignorância.
Re: Com ficam as classes?
by Marcelo Costa,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Olá Constantino,
Vou te responder com uma resposta do Mike Cohn que reflete exatamente isso baseado em uma pergunta similar a sua quando ele foi questionado sobre sistemas ERP / SAP onde quem perguntou dizia que após a fase de desenvolvimento o sistema entrava nos mais diversos tipos de testes, integração, etc e que não entendia como iso poderia ser tratado no Scrum.
"..Na medida do possível, essas atividades serão realizadas durante cada sprint. (Esta é uma boa razão do porque os testes automatizados são importantes.) Esta é a ideia por trás da natureza iterativa e incremental de um sprint. Às vezes, algumas das atividades que você citou são realizadas em um sprint isolado caso o custo de iteragir sobre ele (por exemplo, um grande teste de regressão manual) seja muito alto..."
Ou seja se a comunicação do seu time não for um problema e essa interação realmente existir tudo o que for necessário para o seu software "nascer" será tratado em um sprint.
E sim grandes empresas fazem uso da Scrum e cada uma o adapta a sua necessidade. Scrum não é uma metodologia amarrada que prega apenas "faça isso senão você morre".
Veja isso: tinyurl.com/ScrumNasa
Você certamente pode questionar que o homem não foi pra lua (no fundo no fundo eu também acho que não :-) ) mas fazer uma nave espacial de 700 toneladas decolar não é a mesma coisa que fazer um helimodelo subir. E Scrum pode sim ser usado em qualquer ambiente.
Atte,
Marcelo Costa
www.uplexis.com.br
Casos de Uso - Perda de tempo
by vitor farias dos santos,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Acredito que utilizar casos de uso em metodolgias ageis é meio que perda de tempo... eu sou mais por uma especificãção tecnica bem definida, a propria comunicação entre a equipe para definir a melhor forma de fazer oque tem que ser feito e incluir algum tipo de cultura de teste em todos os processos de desolvimento