User Stories X use cases

Mas essas 20 histórias foram extraídas durante a análise de “Funcionalidade X” ou foram relacionadas posteriormente?

Acho que quando são extraídas 20 histórias temos uma melhor visualização de proposta de “O que entregar para a próxima iteração”. Já dizer que vou entregar alguma porcetagem (%) do correspondente caso de uso não é muito atrativo, palpável, restritivo, incetivador, etc…

Nesse caso acho que pela técnica do caso de uso pode-se dividi-lo em outros menores não? Se puder qual seria a grande diferença então nesse caso da “Funcionalidade X”?

Acredito que UC fica mais organizado, quando bem feito.

(tenho bons resultados com UC, mas concordo que não é necessariamente melhor que História, é apenas meu ponto de vista atual).

Seguindo essa idéia: retorno atômico, observável, na perspectiva do ator; um sistema de Call Center poderia ter um UC por serviço prestado. Depende do negócio.

Obrigado pelo exemplo.

[quote=gilmatryx]

Nesse caso acho que pela técnica do caso de uso pode-se dividi-lo em outros menores não? Se puder qual seria a grande diferença então nesse caso da “Funcionalidade X”?[/quote]

Um caso de uso “não abstrato”, tem que trazer um valor observável para o ator (gravar ou calcular, por exemplo, não é “observável” acontece internamente no sistema). Contudo, você pode dividir em cenários.

Tentando comparar as abordagens:

UC não tem necessariamente uma discrição em passos, neste sentido pode ser igual a historia, eu acredito. A diferença está na identificação, existe mais formalismo para ser um UC.

Enviar e-mail não seria um UC (só se o sistema fosse um servidor de e-mail), mas Reservar Quarto poderia ser. Depende do negócio.

A História 2 é uma regra de negócio. Pode ficar diretamente no código, testes, ou documentada (no UC) se algum gerente exigir.

[quote=Gustavo Serafim][quote=rodrigoy]

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.

[/quote]

Acredito que UC fica mais organizado, quando bem feito.

(tenho bons resultados com UC, mas concordo que não é necessariamente melhor que História, é apenas meu ponto de vista atual).

Seguindo essa idéia: retorno atômico, observável, na perspectiva do ator; um sistema de Call Center poderia ter um UC por serviço prestado. Depende do negócio.

[/quote]

A meu ver , julgando pelo que li por ai sobre Stories elas não se aplicam durante a analise mas apenas durante a implementação (i.e. não existe sprint de analise) Logo elas têm que ser derivadas de informações “maiores” que seriam levantadas durante a analise : os casos de uso.
Na verdade as stories são levantadas diretamente dos requisitos dos quais os casos de uso são exemplos “funcionais”.
Casos de Uso e Requisitos são traduzidos em tarefas “macro” enquanto stories são tarefas tão “micro” quanto necessário.
Stories podem ser partidas em outras stories 'mais simples" a bem de aumentar a velocidade ou separar o trabalho de implementação por alguma razão prática, quanto que os casos de uso e os requisitos são atômicos, não podendo se divididos.

A minha interrogação é como cria um conjunto de stories sem passar pelo levantamento de requisitos ( podemos ignorar os casos de uso aqui já que os requisitos são algo mais abrangente). Parece-me que ha uma certa defesa que usar Stories significa passar por cima da fase de levantamento mas ao mesmo tempo isso não é compatível com o que li sobre o assunto, i.e. em lado algum vi escrito que Agile /Stories significa ignorar a fase de levantamento. Como se relacionam estas duas coisas: levantamento de requisitos e stories ?

Principalmente se você utiliza testes de aceitação.

O próprio Rodrigo disse isso neste tópico já mas quem deu o exemplo de UC foi você.

Uma história é agum pequeno incremento que agregue algum valord e negócio. Para histórias não existe esta distinção.

Tanto faz… histórias surgem, são quebradas, são incorporadas durante o desenvolvimento.

Quando o caso de uso é muito grande a técnica do RUP é quebrar em cenários. Nesta iteração entrego os cenários 1, 2 e 3 do caso de uso X. Pode ser que o caso de uso X tenha 20 cenários (ou histórias). Isso nos leva ao cerne da questão. Se um cenário pode ser uma execução de caso de uso, isso nos diz ainda mais sobre as grandes semelhanças entre eles.

Para a técnica de casos de uso, não seria uma boa idéia quebrar o objetivo do ator. Casos de uso é uma boa técnica para agrupar requisitos importantes para o ator. Não seria correto ter “Reservar Quarto com Disponibilidade” e “Reservar Quarto sem Disponibilidade”.

Aí é que está… quando falamos nisso nós teríamos uma RN no UC ou uma História para manifestar uma necessidade de construção. Não é necessariamente sobre documentação de Requisitos, e sim organizar a fila de construção do software.

Nos métodos ágeis é muito comum que o analista de negócio, o cliente ou Product Owner direcione a equipe através de Stories. Isso é, uma grande diferença entre Scrum, XP e RUP. Os dois primeiros não são tão focados em análise do negócio e de requisitos: as coisas iniciam com Stories a serem construídas. Isso funciona perfeitamente com um cliente interessado, presente, bem resolvido e capaz de controlar escopo, mas você perde em documentação do negócio (não há FIT, RSpec, TDD que documente o negócio, alguém discorda? dá pra escrever um documento de visão em JUnit).

O RUP é mais completo nesse aspecto. Abrange Análise de Negócio, se aprofunda em requisitos e possui um conjunto de práticas e modelo de artefatos pra isso.

Não é que stories ignoram levantamento de requisitos, basicamente muito dessa responsabilidade é repassada para o Prod. Owner, Cliente Presente ou um Analista de Negócios da equipe.

[quote=rodrigoy]
Nos métodos ágeis é muito comum que o analista de negócio, o cliente ou Product Owner direcione a equipe através de Stories. Isso é, uma grande diferença entre Scrum, XP e RUP. Os dois primeiros não são tão focados em análise do negócio e de requisitos: as coisas iniciam com Stories a serem construídas. Isso funciona perfeitamente com um cliente interessado, presente, bem resolvido e capaz de controlar escopo, mas você perde em documentação do negócio (não há FIT, RSpec, TDD que documente o negócio, alguém discorda? dá pra escrever um documento de visão em JUnit).

O RUP é mais completo nesse aspecto. Abrange Análise de Negócio, se aprofunda em requisitos e possui um conjunto de práticas e modelo de artefatos pra isso.

Não é que stories ignoram levantamento de requisitos, basicamente muito dessa responsabilidade é repassada para o Prod. Owner, Cliente Presente ou um Analista de Negócios da equipe.[/quote]

Isso não é verdade. Eu já apliquei metodologias ágeis onde clientes não estavam presentes -inclusive no meu projeto atual. Metodologias ágeis em geral não falam sobre análise de negócios bem como não falam em arquitetura de camadas, domain-driven design ou outra prática técnica. O cliente não é responsável pela documentação, ele é responsável por saber o que quer, e a documentação está expressa de diversas formas: histórias, testes e código são as mais comuns.

Se você não consegue documentar os processos de negócios relativos à aplicação de uma maneira automatizada (i.e. testes) não está fazendo bom uso de JUnit, RSpec, FIT e etc. De qualquer maneira, ainda com a documentação executável, o cliente pode querer manter uma documentação no formato que quiser, não há qualquer problema quanto a isso.

Neste caso eu não poderia dividir estes 20 ou mais casos de uso em casos de uso de inclusão e extensão? Ultimamente tenho feito isso e os resultados estão sendo bons. Cada caso de uso fica menor e evito aqueles monstros com 20 cenários e 400 fluxos alternativoms em um único caso de uso.

:?: :?: :?: :?: :?: :?: :?:

Calma lá Shoes… o assunto agora (sergiotaborda e depois eu) é Levantamento de Requisitos e Stories dentro de métodos ágeis. Eu não disse que métodos ágeis requerem cliente presente, mas sim que para a parte de requisitos isso é importante para usar Stories do jeito que o XP prega. Você concorda que com cliente presente este tem grande responsabilidade de análise e levantamento de requisitos? Não é ele que escreve as histórias?

Acho que você não compreendeu a minha colocação.

Não estou falando só referente à aplicação e só a processos de negócio. Me diga então como eu faço para escrever um documento de visão com JUnit, RSpec, FIT. Tem algum paper, artigo, livro que explique como é que faz isso? Você já fez isso?

Foi bem fora de contexto essas suas colocações e temo que elas possam desvirtuar o tópico.

Esqueça inclusão e extensão… essas ferramentas não foram feitas para decomposição funcional. Casos de uso não tem decomposição funcional. Não adianta deturpar a técnica. Para ter uma visão parcial de um caso de uso grande a técnica nos diz para usar cenários.

[quote=rodrigoy][quote=pcalcado]
Isso não é verdade. Eu já apliquei metodologias ágeis onde clientes não estavam presentes -inclusive no meu projeto atual. Metodologias ágeis em geral não falam sobre análise de negócios bem como não falam em arquitetura de camadas, domain-driven design ou outra prática técnica. O cliente não é responsável pela documentação, ele é responsável por saber o que quer, e a documentação está expressa de diversas formas: histórias, testes e código são as mais comuns.
[/quote]

:?: :?: :?: :?: :?: :?: :?:

Calma lá Shoes… o assunto agora (sergiotaborda e depois eu) é Levantamento de Requisitos e Stories dentro de métodos ágeis. Eu não disse que métodos ágeis requerem cliente presente, mas sim que para a parte de requisitos isso é importante para usar Stories do jeito que o XP prega. Você concorda que com cliente presente este tem grande responsabilidade de análise e levantamento de requisitos? Não é ele que escreve as histórias?

Acho que você não compreendeu a minha colocação.
[/quote]

É ótimo que o cliente escreva as histórias mas não é obrigação. Se ele não estiver presente -como acotnece em muitos casos- é dever do analista de negócios (ou de quem exercer este papel) escrever e mantêr histórias. Já trabalhei em muitos rojetos onde os clientes nem sabiam que existiam essas tais histórias, tudo ficava internamente na equipe de desenvolvimento. Funcionaria melhor com o cliente presente? Claro, mas isso não quer dizer que não seja eficiente mesmo que ele não esteja.

[quote=rodrigoy]

Não estou falando só referente à aplicação e só a processos de negócio. Me diga então como eu faço para escrever um documento de visão com JUnit, RSpec, FIT. Tem algum paper, artigo, livro que explique como é que faz isso? Você já fez isso?

Foi bem fora de contexto essas suas colocações e temo que elas possam desvirtuar o tópico.[/quote]

Eu estou apenas respondendo às suas colocações -com as quais não concordo- desta forma o contexto delas é seu post anterior. Se seu post anterior.

Qualquer paper, artigo ou livro vai te perguntar uma coisa: por que você precisa de um documento de visão em primeiro lugar?

Eu não falei que dê para escrever um documento de visão estilão RUP (apesar de ter minhas dúvidas que não dá), falei de documentação em geral e, especialmente, documentação que seja útil.

Shoes… a gente não está se entendendo!

http://blog.fragmental.com.br/2008/07/18/rastreabilidade-em-user-stories/#comment-96077

Antes de se chegar a Stories vc mesmo concordou que existe uma coisa chamada “Análise de Negócios”. Isso estuda a viabilidade do projeto, os objetivos de ROI, os envolvidos, os problemas, o escopo e etc… Isso tudo poderia fazer parte da visão, e nenhum analista de negócios responsável deixaria isso ad-hoc. É mais ou menos nisso que estou focando. Com relação a isso:

  • o RUP abrange isso tudo
  • o Scrum personifica isso no papel do Product Owner (que é o financiador)
  • o XP personifica isso com Cliente Presente (que é o financiador)

O Scrum ao menos cita a visão. O RUP dá uma grande enfase à visão. O XP crê que o cliente presente tenha uma visão. Um documento de visão é importante sim e não me lembro de nenhum autor que diga o contrário. O código não é tudo. Existem muitas outras coisas antes de System Requirements.

De qualquer fato, a questão é bem complexa pensando por este lado. O controle de escopo na maioria das vezes está nas mãos de quem está controlando a fila de construção, até a forma de contratação estaria envolvida na discussão. IMHO se você não tem cliente presente você precisa documentar o negócio antes de ter as Stories.

(eh um bom assunto para escrever a respeito, vou ver se coloco algo no blog)

[quote=rodrigoy]

Esqueça inclusão e extensão… essas ferramentas não foram feitas para decomposição funcional. Casos de uso não tem decomposição funcional. Não adianta deturpar a técnica. Para ter uma visão parcial de um caso de uso grande a técnica nos diz para usar cenários.[/quote]

Rodrigo, Não estou falando de decomposição funcional, acho que estamos com o caso de uso base diferente na cabeça.

Onde eu aplico os extends e includes são em telas do tipo “Painel de controle” onde a partir de uma unica tela eu tenho à disposição muitas funcionalidades distintas. Seria muito complicado neste caso colocar tudo em um unico caso de uso.

PS: Você não foi muito radical com o “Esqueça inclusão e extensão”? Ou você estava se referindo apenas nos casos em que eles são usados com a finalidade de decomposição funcional?

Meu ponto é que acima você implicou que com metodologias ágeis (seja qual nome estejamos usando para elas hoje) não existe esta análise, na verdade afirmou que não existe documentação do negócio. Isto não procede, a documentação do negócio apenas fica a cargo do responsável, é um processo externo (e não necessariamente paralelo) ao desenvolvimento de software.

Muitas vezes o software é desenvolvido ao mesmo tempo que é feita a análise de negócios. Muitas vezes a análise é feita antes.

O Scrum pode citar a visão mas eu não me recordo de citar o documento de visão. É como requisitos, nenhuma metodologia menospreza requisitos mas metodologias ágeis não falam em documento de requisitos.

Você fala “código não é tudo”. Acho que você está se referindo ao código do sistema. Eu não. Eu estou falando de documentação executável e verificável. Por um acaso ela está expressa em código, simplesmente porque não temos modo melhor de fazê-lo hoje em dia. É claro que estou falando em documentação do sistema. Mesmo tendo alguns anos como “análista de sistemas” (seja lá o que isso signifique) eu nunca iria dizer para um especialista no negócio (i.e. cliente) qual a melhor maneira de documentar o processo de negócio dele. Eu digo, como desenvolvedor, qual a melhor maneira de documentar o meu processo.

Comparando o exemplo de UC do Gustavo e o de história do Rodrigo eu chego a algumas conclusões e duvidas. Me corrijam se estiver errado.

UC - 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)

História - 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

Conclusões

1 - O caso de uso e a história atenderam a uma mesma necessidade do cliente que seria: um atendente poder reservar quartos.
2 - A história manteve seu foco em atender a necessidade do cliente usando critérios de aceitação e ponto final, simples assim.
3 - O caso de uso ficou maior do que a história e também uma pouco mais difícil de entender porque ele alem de mapear os critérios necessários para se atender a necessidade do usuário, também se preocupou em mapear o fluxo de informação que irá ocorrer entre o usuário e o sistema (atendente informa XXX, sistema exibe YYY, Quarto não disponível?, Substituir passo 2, Voltar passo 1, etc).

Dúvidas

Qual a vantagem de se representar fluxo de informação de forma textual?
Criar uma história simples e rabiscar um protótipo não seria mais direto e de fácil entendimento?

Porque alguns clientes pedem que os casos de uso sejam entregues como parte da documentação do sistema*, e muitos deles não iram aceitar este “rascunhos”.

Quando o caso de uso tem a finalidade de ser apenas uma ferramenta durante o desenvolvimento do sistema, os rascunhos em papel e os diagramas (em papel ou em alguma ferramenta) talvez sejam mais uteis.

*Este é um ponto iteressante, caso de uso é documentação do sistema ou apenas uma ferramenta usada na construção do sistema?