User Stories X use cases

Virtual Machine Man Membro desde: 02/06/2005 16:28:38 Mensagens: 702 Offline

fabeen wrote: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

) de novo, só pq nossos colonizadores ainda usam e quem não usa "não sabes o que estaires a fazer"

This message was edited 1 time. Last update was at 17/07/2008 21:43:35

Uma das mais importantes diferença é o tempo de vida. Casos de uso são artefatos estáticos, permanentes, que continuam existindo ao longo da vida do produto, mesmo que descartáveis. Estórias, por outro lado, são transientes, não teêm vida após a iteração terminar, pois eles são adicionados ao software em forma de testes de aceitação automatizados (caso ideal).

Eu também não vejo quando é aplicável optar por casos de uso. Não faz sentido há anos. Como o Ambler cita no Agile Modeling, você só precisa de algo bom o suficiente como documento, pois o que é realmente mais proveitoso, no quesito comunicação com o cliente, é a conversa olho-no-olho, citação esta comprovada por um estudo no mesmo livro.

Thread.start() Membro desde: 04/09/2006 15:33:40 Mensagens: 49 Offline

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

Thread.start() Membro desde: 04/09/2006 15:33:40 Mensagens: 49 Offline

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?

This message was edited 1 time. Last update was at 29/07/2008 17:23:21

Gustavo Serafim wrote:
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?

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.

fabeen wrote:Não querendo ser Xiita, mas pra mim a descrição de Casos de Uso são uma imensa perda de tempo.

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 :-

rodrigoy wrote:
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.

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"?

Thread.start() Membro desde: 04/09/2006 15:33:40 Mensagens: 49 Offline

rodrigoy wrote:

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.

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.

Thread.start() Membro desde: 04/09/2006 15:33:40 Mensagens: 49 Offline

gilmatryx wrote:

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"?

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.

This message was edited 1 time. Last update was at 29/07/2008 22:13:26

Tentando comparar as abordagens:

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

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.

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

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

This message was edited 1 time. Last update was at 30/07/2008 08:38:29

Gustavo Serafim wrote:

rodrigoy wrote:

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.

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.

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 ?

fabeen wrote:Não querendo ser Xiita, mas pra mim a descrição de Casos de Uso são uma imensa perda de tempo.

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

Gustavo Serafim wrote:
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.

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

Gustavo Serafim wrote:
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.

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

gilmatryx wrote:
Mas essas 20 histórias foram extraídas durante a análise de "Funcionalidade X" ou foram relacionadas posteriormente?

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

gilmatryx wrote:
Já dizer que vou entregar alguma porcetagem (%) do correspondente caso de uso não é muito atrativo, palpável, restritivo, incetivador, etc...

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.

gilmatryx wrote:
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"?

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".

Gustavo Serafim wrote:

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

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

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.

Notícias, artigos e o maior fórum brasileiro sobre Java