User Stories X use cases

Estava discutindo no grupo que temos aqui em Maceió e ao perguntar se alguém tinha o livro Writing Effective Use Cases um amigo (que fez o curso de CSM) disse que eles abominaram o uso de Casos de Uso para usar apenas User Stories.

Eu queria saber de vocês uma comparação entre as duas técnicas para descrição dos requisitos. Em um ambiente ÁGIL(Claro).

Vcs continuam usando casos de uso?
Uma não impede a utilização da outra?
O fato de casos de uso serem escritos pelo time e user stories pelo cliente altera em muita coisa?
Agile requirements…quais outras opções vcs estão usando?

Estou viajando e uma não tem nada a ver com a outra ?? hhehehehe

Artigo sobre requirements in an agile environment -> http://www.ibm.com/developerworks/library/ar-archman4/index.html?ca=drs- Ajudar para quem não conhece.

Cara,

sinto dizer-lhe, seu amigo está certo…

tem várias threads no GUJ discutindo isso…

http://www.guj.com.br/posts/list/15/79552.java

http://www.guj.com.br/posts/list/90453.java

Abraço.

Segundo o Fowler:

Segundo o Ambler:

http://www.agilemodeling.com/artifacts/userStory.htm

Segundo o c2 (Ward Cunningham e cia ltda)

http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison

Se você pegar o conceito por trás de casos de uso cunhado pelo Ivar Jacobson você verá que praticamente é a mesma coisa. Caso de uso não precisa ser formal. Na literatura do Kent Beck eu não vejo ele diferenciando muito Casos de Uso de Stories. Pra quem tá começando pode cair na modinha e falar que só usa Stories porque está no Index Card…

[quote=rodrigoy] Pra quem tá começando pode cair na modinha e falar que só usa Stories porque está no Index Card…

[/quote]

Isso aí … além de estar na moda será mais feliz… :wink:

Perceba a diferenciação q o Fowler faz entre Casos de Usos e Stories, provando que são coisas DIFERENTES.

Perfeito, como sempre…

Taz? Vamos começar tudo de novo?

  • Casos de Uso e Stories são técnicas para desenvolver o sistema pelo ponto de vista do Ator.
  • Casos de Uso e Stories não são documentos técnicos.
  • Casos de Uso e Stories são suscintos.
  • Casos de Uso e Stories são atômicos.
  • Casos de Uso e Stories agregam valor de negócio.
  • Casos de Uso e Stories são utilizadas para gerenciar o projeto.
  • Casos de Uso e Stories dividem o sistema funcionalmente.
  • Casos de Uso e Stories podem ser estimados.
  • Casos de Uso e Stories direcionam os testes.

Eu só consigo ver semelhanças entre Casos de Uso e Stories. Talvez a razão de enxergar toda essa diferença é que poucas pessoas sabem a técnica correta de Casos de Uso. A julgar pelas mais de 3000 pessoas que estão inscritas no nosso curso on-line grátis sobre Casos de Uso, pode ter certeza que tenho bons fundamentos para fazer tal afirmação.

Se você puder citar um número maior de diferenças marcantes com relação aos dois eu posso concordar que eles são diferentes.

Outro ponto: Foram raros os casos que ví o cliente escrever User Stories da maneira que o XP prega. Eles podem participar dando informações mas não sabendo lidar com histórias diretamente. Essa talvez possa ser uma das diferenças, mas que nunca ocorre na prática.

Casos de Uso e User Stories são diferentes, apesa de parecidos, como o próprio Fowler falou:

Não tem nada de “modinha”, é um modo diferente de particionar o que precisa ser feito. É claro que os conceitos são os mesmos, assim como boa parte dos conceitos basicos de qualquer metodologia iterativa -como XP e RUP- são os mesmos, mas ter os mesmos conceitos básicos não faz de duas coisas iguais (católicos x protestantes que o digam).

Bom, siceramente eu não uso Use Cases há aluns anos simplesmente porque além de ninguém conseguir me convencer que eles são melhores que histórias eu nunca vi um use case ser realmente entendido pelo cliente -o que acontece com histórias, que o próprio cliente escreve.

Estranho seria se ele não entendesse o que escreveu. :wink:

Abraços,

Você pode comparar Stories com Cenários segundo o Fowler. Não tenho um estudo, mas é muito comum um Caso de Uso ser um único cenário (só tem fluxo básico), ou talvez um único cenário importante. Mais uma vez: Casos de Uso não precisam ser formais, não precisa ser descrito na forma de fluxos, as vezes o nome do caso de uso já basta.

:shock: Isso pra mim é modinha. Como já tinha também dito anteriormente o Kent Beck toma a literatura do Jacobson como base para lidar com Stories. Já tinha falado pro próprio Taz em tópicos anteriores. É uma discussão meio morta essa. IMHO, seria a mesma coisa que dizer que abominam o uso de Iterações… só usam Sprints agora. :?

O trecho que você colou apenas confirma o que eu disse. Existe correlação, aprtem do mesmo princípio. Existe uma diferença enorme entre correlação e equivalência e o mesmo trecho citado mostra exatamente como não se podem intercambiar ambos. Se você tiver apenas o nome do caso de uso ele ainda é muito diferente de uma história. Uma história é apenas um placeholder para uma conversa direta entre analista e desenvolvedor. Quando essa conversa está acotnecendo levanta-se critérios de aceita para a história.

Novamente: não é porque possuem conceitos parecidos que são iguais. RUP e XP partem dos mesmos princípios com soluções parecidas mas bem diferentes.

Sua comparação com sprint é sem sentido, creio. Não existe diferença prática entre sprint e iteração, é apenas o nome que Scrum usa (Scrum é otemo em inventar nomes novos para coisas velhas) mas existem diferençar entre casos de uso e histórias. Como disse o Fowler existe diferença: satisfazer um objetivo x organizar entregas.

Para mim também é uma conversa morta. São coisas diferentes, cada um possui seu lugar e não há motivo para tentar iguala-las -a menos que se faça como o Ambler que precisa vender um processo baseado em casos de uso.

Qual?? UP?

Alguém tem conhecimento de Crystal? Como ela trata o assunto?
Já que o livro citado é do próprio Cockburn.

[quote=leofernandesmo]Estava discutindo no grupo que temos aqui em Maceió e ao perguntar se alguém tinha o livro Writing Effective Use Cases um amigo (que fez o curso de CSM) disse que eles abominaram o uso de Casos de Uso para usar apenas User Stories.
[/quote]

Casos de Uso são descrições não técnicas e não-tecnologicas daquilo que o usuário pode esperar do sistema. São descrições da
interação do usuário com o sistema. São compostos pelas ações que o usuário toma e o sistema toma em resposta até que um objetivo seja conseguido. Esse objetivo é um objetivo de negocio. Por exemplo “Reservar Quarto”.

Caso de Uso são utilizados em vez/como se fosse um protótipo, mas com todas as referencias a layout e tecnologia removidas.
Não importa como sistema será desenhado/construido, ele tem que funcionar daquela forma. Casos de uso são utilizados para levantar requisitos ( não para os documentar) e para que os testes saibam como confirmar que o sistema faz o que deve.
Casos de Uso estão relacionados aos requisitos funcionais mas não são requisitos nem servem para os documentar. Eles são escritos normalmente pelo analista num documento de analise, mas os bons CU devem ser escritos em conjunto com o cliente. Nada impede que o cliente os escreva sozinho.

Estórias ( não Histórias (stories =/= histories) ) são descrições simples e curtas (titulos) daquilo que o sistema terá que fazer. Como são limitadas em tamanho devem ser partidas em estórias menores até que seja claro que há a fazer. Por exemplo “Reservar quarto” é muito genérico. O processo de criação é o mesmo, mas o detalhes e o propósito é diferente. Em XP elas devem ser criadas pelo cliente (afinal são USER stories) , mas nisso não ha diferença paras os CU que tb podem ser escritos pelo cliente.
A diferença é que os UC servem como um protótipo para que todos saibam o que esperar do sistema, enquanto estórias servem para que a equipe possa estimar o que tem que fazer e portanto quanto o esforço necessário. Ambas mantêm um nivel alto desprovido de detalhes tecnológicos ou de interface gráfica.

dizer que aboliu caso de uso é irrelevante já que não servem o mesmo proposito que as estorias. A pergunta ser feita é: se não usa casos de uso o que vc usa em vez? Se responder “User Stories” das duas uma:

  1. não sabe o que está a fazer e acha que é tudo a mesma coisa
  2. dá preferencia a formas de avaliar esforço em vez de formas de avaliar requisitos.
  3. não faz levantamento de requisitos ( cenário é que os CU são irrelevantes)

Por outro lado se a pessoa usa CU mas não estórias a pergunta é : como estima o esforço do projeto ?
Já que CU não servem para isso e não são usadas estórias, então outro método é necessário. A menos, é claro, que o esforço não seja estimado.

São coisas que nascem do mesmo lugar ( cliente) e dizem quase a mesma coisa ( muda o nivel de detalhes e a forma) mas não servem para a mesma coisa.

1 curtida

O vocábulo “estória” entrou em desuso… deve-se utilizar “história” para todos os casos

abs

O XP também na minha opinião. Eu achei uma frescura sem tamanho o Schwaber chamar Iteração de Sprint, assim como não ví diferença entre cenário de story quando estudei XP. São nomes diferentes para coisas que já existiam. Mas pra ficar na modinha, vamos chamar de Story. (Isso é bem IMHO, não precisa despejar bibliografia. Pra uma conversa morta, essa tá rendendo demais até). 8)

:lol: :lol: :lol: :lol: Essa foi boa… ele que não nos ouça… :wink:

[editado] escreví storie no post todo! [/editado]

1 curtida

O vocábulo “estória” entrou em desuso… deve-se utilizar “história” para todos os casos

[/quote]

Embora o termo não se use em Portugal e seja visto como um Brasileirismo ele é adequado aqui.
Existe uma necessidade de referir que aquilo que está escrito não é real. É um conto do ponto de vista de quem o escreveu (o cliente)
e não é a Verdade. Não é fato. O conto tem que ser analisado para se torna útil. É a tradução direta da palavra story do inglês que se opõe a history. Ou seja, tb no original inglês ha a necessidade de distinguir a não realidade do que está escrito e numa boa tradução o sentido deve ser preservado o mais possível; mesmo que com palavras “arcaicas” (http://pt.wiktionary.org/wiki/est%C3%B3ria) ( nota: a palavra deixa de ser arcaica se for usada agora)

Não querendo ser Xiita, mas pra mim a descrição de Casos de Uso são uma imensa perda de tempo. Quando o cliente está presente, participando, dando a opinião de negócio sobre o que ele realmente espera da estória http://www.improveit.com.br/xp/praticas/cliente_real, tem-se uma melhor visão do que é necessário implementar e entregar na conclusão dela.

É verdade…

Por outro lado estou pensando em voltar a usar CU (nome estranho esse :roll: ) de novo, só pq nossos colonizadores ainda usam e quem não usa “não sabes o que estaires a fazer”

Mais uma Referência: http://www.infoq.com/news/2008/07/use-case-or-user-story

Acredito que quando a equipe é formada de desenvolvedores, Stories funcionam bem, mas quando temos um analista de negócio na equipe (com formação apenas de negócio), acho que o formalismo do UC é mais indicado. (Acredito que ajuda o analista de negocio pensar em uma solução funcional para os requisitos.)

Considerações: O formalismo do UC - retorno atômico observável na perspectiva do ator - ajuda organizar melhor o desenvolvimento (solução funcional pra os requisitos, não CRUDs ), pois representam formalmente uma funcionalidade significativa para o negócio. As iterações podem ser organizadas por cenários, se for o caso. Ainda temos recursos interessantes como, por exemplo, extensão e inclusão.

O caso de uso deve ser simples e sintético. Gosto da abordagem de especificar apenas os dados que passam na fronteira ator/sistema.  

Segue exemplo simples para ilustrar (um exemplo mais complexo justificaria melhor a abordagem, acredito)

Reservar Apartamento

Fluxo básico

  1. Atendente informa hotel, datas e tipo de apartamento
  2. Sistema fornece disponibilidade e preço
  3. Atendente informa CPF do cliente e confirma
  4. Sistema exibe um identificador (R1)
  5. Sistema envia a confirmação por e-mail

(R1 - Regra de negócio, apenas clientes aprovados poderão reservar apartamentos)

Fluxo Alternativo: Quarto não disponível
(substitui passo 2)
Sistema exibe mensagem de indisponibilidade.
(volta passo 1)

Como ficaria com Stories o exemplo?

[quote=Gustavo Serafim]
Reservar Apartamento

Fluxo básico

  1. Atendente informa hotel, datas e tipo de apartamento
  2. Sistema fornece disponibilidade e preço
  3. Atendente informa CPF do cliente e confirma
  4. Sistema exibe um identificador (R1)
  5. Sistema envia a confirmação por e-mail

(R1 - Regra de negócio, apenas clientes aprovados poderão reservar apartamentos)

Fluxo Alternativo: Quarto não disponível
(substitui passo 2)
Sistema exibe mensagem de indisponibilidade.
(volta passo 1)

Como ficaria com Stories o exemplo?
[/quote]

História 1: Um atendente pode reservar quartos

Critérios de aceitação:

  • Testar com um cliente aprovado e com disponibilidade de quarto
  • Testar com cliente aprovado e sem disponibilidade de quarto
  • Testar envio do e-mail
  • Testar com um cliente não aprovado

Se isso ficar muito grande e não caber na iteração você quebra em duas ou mais:

História 1: Um atendente pode reservar quartos para clientes aprovados

História 2: Um atendente não pode reservar quartos para clientes não aprovados

História 3: O sistema envia um e-mail ao reservar o quarto

Esse caso de fato é muito banal, porém, ocorrem situações como um sistema de Call Center Vendas onde 85% das funcionalidades estão num único caso de uso e de lá se extraem umas 20 histórias. Aí o caso de uso é bom para concentrar tudo.

1 curtida

Eu não trabalho com desenvolvimento de software ainda (sou estudante), mas confesso que também acho que Casos de Uso são perda de tempo :-