User Stories X use cases

Alexandro.Almeida wrote:
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?

Caso de uso não modela telas. Isso é um erro muito comum. Extend e Include são práticas para reutilizar comportamentos. Não fui muito radical não... geralmente quando vejo um include e um extend num diagrama a chance é de 99% de estar errado. O Martin Fowler diz "esqueça include e extend", eu só concordo com ele.

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

Concordo caso de uso é um objetivo maior e é um concentrador de situações (cenários). E esses cenários podem ou não serem iguais a user stories.

MarceloAraujo wrote:
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?

Nada impediria você fazer o seguinte:

Caso de Uso: Reservar Quartos
Ator: Atendente

Este caso de uso reserva um quarto para um cliente aprovado. Deve-se levar em consideração se o quarto está disponível para o período da reserva. Clientes não aprovados não podem reservar. Quando a reserva é efetivada um e-mail é enviado ao cliente.

Mais uma vez... casos de uso não precisam ser formais, não precisam constar em diagramas, não precisam ser descritos na forma de fluxos, podem até estar em Index Cards pra ficar mais na moda.

(sim... isso foi uma provocação gratuita)

This message was edited 1 time. Last update was at 30/07/2008 14:55:48

rodrigoy wrote:

Alexandro.Almeida wrote:
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?

Caso de uso não modela telas. Isso é um erro muito comum. Extend e Include são práticas para reutilizar comportamentos. Não fui muito radical não... geralmente quando vejo um include e um extend num diagrama a chance é de 99% de estar errado. O Martin Fowler diz "esqueça include e extend", eu só concordo com ele.

Entendo .... talvez seja este erro recorrente de modelar baseado em tela que gere estes includes e extends mesmo. Vou ter que pensar mais um pouco no assunto.

Mas e neste cenário, de um caso de uso com 85% das funcionalidade do sistema, como dividi-lo em entregaveis? Por cenário? Não ficaria dificil de gerenciar? Ou não divido, entrego "85%" das funcionalidades sistema de uma única vez e depois os outros 15%?

Pergunto isso porque nunca peguei um caso destes.

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

A primeira etapa de uma jornada é saber onde vc quer chegar. Mas quem diz isso?

Não sou nenhum estudioso do assunto, mas já ouvi falar de um "cartão de visão", que tem como característica ser sucinto, mas que tem o objetivo de fornecer uma visão conceitual do sistema para ambas as partes, cliente e desenvolvedor.

A grande diferença entre o documento de visão tipo (UP, RUP e semelhantes), é que o cartão é escrito pelo cliente e ele tem o direito de não ter que conceituar todo o sistema desde o início.

Mas se vc faz isso pelo cliente não está deixando de ser ágil, é verdade, mas está mas distante da visão dele, o especialista.

This message was edited 1 time. Last update was at 30/07/2008 15:01:32

rodrigoy wrote:

MarceloAraujo wrote:
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?

Nada impediria você fazer o seguinte:

Caso de Uso: Reservar Quartos
Ator: Atendente

Este caso de uso reserva um quarto para um cliente aprovado. Deve-se levar em consideração se o quarto está disponível para o período da reserva. Clientes não aprovados não podem reservar. Quando a reserva é efetivada um e-mail é enviado ao cliente.

Mais uma vez... casos de uso não precisam ser formais, não precisam constar em diagramas, não precisam ser descritos na forma de fluxos, podem até estar em Index Cards pra ficar mais na moda.

(sim... isso foi uma provocação gratuita)

Mas desta forma não são mais casos de uso, seria melhor chama-lo de história e pronto!
Histórias e caso de uso tem objetivos em comum mas não são iguais.

Alexandro.Almeida wrote:
Mas de qualquer forma, acredito que os casos de uso com seu fluxo de informação de forma textual seja mais util nos casos em que não temos a oportunidade de termos o cliente ou um bom PO dentro do projeto.

Concordo, nesse caso ele funciona mas como um manual de consulta para visualizar algo, do que um mecanismo de projeção semântico-lógico-conceitual (Ou coisa parecida

).

rodrigoy wrote:

MarceloAraujo wrote:
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?

Nada impediria você fazer o seguinte:

Caso de Uso: Reservar Quartos
Ator: Atendente

Este caso de uso reserva um quarto para um cliente aprovado. Deve-se levar em consideração se o quarto está disponível para o período da reserva. Clientes não aprovados não podem reservar. Quando a reserva é efetivada um e-mail é enviado ao cliente.

Mais uma vez... casos de uso não precisam ser formais, não precisam constar em diagramas, não precisam ser descritos na forma de fluxos, podem até estar em Index Cards pra ficar mais na moda.

(sim... isso foi uma provocação gratuita)

Pois é. Caso de uso não precisa disso, não precisa daquilo. Eles são quase tão customizáveis quanto o RUP

Minha dúvida então fica sendo com o caso de uso feito em um modelo mais formal, cheio de fluxos, idas e vindas. Que é o modelo mais comum de ser usado no mercado, descrito em artigos de revista e em cursos on-line por aí

Alexandro.Almeida wrote:
Entendo .... talvez seja este erro recorrente de modelar baseado em tela que gere estes includes e extends mesmo. Vou ter que pensar mais um pouco no assunto.

Faça o meu curso on-line grátis no site da Aspercom: www.aspercom.com.br
(basta se cadastrar no site)

Alexandro.Almeida wrote:
Mas e neste cenário, de um caso de uso com 85% das funcionalidade do sistema, como dividi-lo em entregaveis? Por cenário? Não ficaria dificil de gerenciar? Ou não divido, entrego "85%" das funcionalidades sistema de uma única vez e depois os outros 15%?

Pergunto isso porque nunca peguei um caso destes.

Sim... quebra por cenário e ficará praticamente igual a Stories. No RUP é assim. No MSF é assim. No EssUP é assim. No OpenUP é assim.

Alexandro.Almeida wrote:
Mas desta forma não são mais casos de uso, seria melhor chama-lo de história e pronto!
Histórias e caso de uso tem objetivos em comum mas não são iguais.

Me diga a literatura que diz que casos de uso DEVEM ser descritos na forma de fluxos. Pelo que me lembro Jacobson, Cockburn e Larman dizem que eles podem ser descritos de forma sucinta.

Casos de uso com fluxos definidos só te ajudam quando você quer fazer o desenho da iteração com diagramas de sequência a lá RUP.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

rodrigoy wrote:

sergiotaborda wrote:
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 ?

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.

Bom, se entendi o que escreveu :
Independentemente da fonte e da metodologia usada existe a necessidade de um levantamento de requisitos.
Se esse levantamento é documentado ou não, e se sim, como é uma escolha à parte. O ponto é que a lista de requisitos existe, nem que seja na cabeça de alguém (memória volatil).

Stories são uma ferramenta da equipe de desenvolvimento ( que exclui o analista, o gerente e o cliente) e não uma forma de linguagem comum embora possa ser utilizada pelo analista para se fazer entender pela equipe. Aqui dá-me a impressão que Stories são artificios de contole de desenvolvimento e não de controle de projeto ( que algo mais lato porque inclui custos, tempos etc...)
Sim ?

Estou imaginando o analista aparecer com uma lista de requisitos e isso virar uma lista de stories não necessáriamente 1 para 1. Ou seja, fazer o breakdown dos requisitos em algo que se possa programar. Os testes unitários atuaram sobre as stories sendo que são a unidade mínima possível de programar e por conseqüência espera-se que os requisitos estão implementados corretamente. Ou seja

1 Requitiso -> N Stories -> T testes por Storie = N*T testes por requisito.
Se todos os N*T testes passarem isso signfiicaria ( se os testes forem bem feitos etc) que o requisito está implementado corretamente.

E isso ?
É que se for , então Casos de Uso são coisas que nada têm a ver com Stories, já que têm um proposito completamente diferente e na prática, se quiser documentar as coisas "no minimo detalhes" teria que fazer ambos no projeto. Só que o casos são feitos pelo analista enquanto stories pela equipe de desenvolvimento ( que não inclui o analista). É por ai ?

Por outro lado, se eu precisar orçar o projeto Stories não me adiantam já que eu preciso conhcer o escopo "todo" e portanto preciso da lista de requisitos. Por outro lado, o esforço vai ser ditado pela velocidade da implementação das stories. Como encaixam estes outras coisas : stories, casos de uso, lista de requisitos e orçamento ?

rodrigoy wrote:
Faça o meu curso on-line grátis no site da Aspercom: www.aspercom.com.br
(basta se cadastrar no site)

Fiz hoje mesmo e gostei, parabéns pelo trabalho.
Sua explicação de extends e includes foi aplicável em muitos casos onde eu já os usava, em outros realmete estam sendo usados de forma incorreta. Estou pensando em uma revisão dos conceitos usados aqui para o uso de extends e includes

rodrigoy wrote:

Alexandro.Almeida wrote:
Mas desta forma não são mais casos de uso, seria melhor chama-lo de história e pronto!
Histórias e caso de uso tem objetivos em comum mas não são iguais.

Me diga a literatura que diz que casos de uso DEVEM ser descritos na forma de fluxos. Pelo que me lembro Jacobson, Cockburn e Larman dizem que eles podem ser descritos de forma sucinta.

Casos de uso com fluxos definidos só te ajudam quando você quer fazer o desenho da iteração com diagramas de sequência a lá RUP.

Rodrigo, o caso não é a literatura que fala assim e a que fala assado, é a forma como o "mercado" entende como caso de uso.

Concordo que para que o caso de uso atinja o objetivo de auxiliar o desenvolvimento do software, ou mesmo documenta-lo de alguma forma, ele não precisa ser tão formal. Pode ser como uma história, acrescento uns diagramas, rascunhos e o que mais for útil.

Mas desta maneira ele não é visto como caso de uso por 90% das pessoas por ai. O fato é que eu tenho que fazer um CdU da maneira formal, e já que tenho que faze-lo assim, quero faze-lo de uma forma que seja util para o desenvolvimento e seja aceito pelo cliente. Acho que o seu curso online da uma grande ajuda neste trabalho de conciliar estes dois mundo.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

Só que o casos são feitos pelo analista enquanto stories pela equipe de desenvolvimento ( que não inclui o analista)

Stories sao escritas preferencialmente pelo cliente (ou quem estiver fazendo o seu papel). Desenvolvedores podem participar (eu acho que devem) porque muitas vezes lidamos com analistas que nao sao muito especialistas no negocio e neste caso sobra para os desenvolvedores a tarefa nao de escrever a estoria mas guiar a discussao para falar em termos de negocio e nao fluxos de tela. Acho que essa e a questao , tentar resolver o problema dos requisitos na forma de CRUD com aperta o botao aqui e entao mostra na tabela ali.

This message was edited 1 time. Last update was at 30/07/2008 16:31:19

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

UML: Agregação ou Composição?

Na UML muita gente tem dúvida como e quando usar composição e agregação (Losango aberto ou fechado?).
Está me parecendo o mesmo em relação aos Use Cases (UC) e User Stories (US). Em um ambiente ágil um caso de uso não deve ser escrito pelo desenvolvedor e sim pelo cliente. Mas ele não sabe com escrever, então a descrição textual vai ter um aspecto semelhante a uma user story, nisso os dois são iguais US e UC. Mas para por aí, por que depois do primeiro texto para esse caso de uso escrito pelo cliente (Reservar Apartamento, por exemplo) ele vai naturalmente “quebrar em outras coisas conceituais”, aí é que entram as diferenças de técnicas.

Então, Devo agrupar ou dispersar?

Esse é básicamente o "Q" da questão, levando em consideração que o cliente escreve os requisitos. UC e US são veículos de requisitos, ou seja, são iguais nesse aspecto, mas a natureza e conceitos envolvidos em cada um levam a pesamentos diferentes.

Uma user story é a menor quantidade de informações (uma etapa) necessárias para que o cliente defina um caminho através de um sistema. Um caso de uso é uma descrição completa (textual, de simples texto a formalidades) de uma seqüência de interações; ele não é normalmente um passo ou atividade individual em um processo. Por exemplo: Imprimir Recibo não é um caso de uso em si, mas uma subseqüência dentro do caso de uso Comprar Produto.

Um caso de uso agrupa todas as seqüências específicas de ações e interações entre atores e o sistema em forma de cenários, regras de negócio, requisito de interface, requisitos de desempenho, etc (seja sob referências ou não). Ele agrupa coisas, e um cliente não agrupa isso, um cliente pede. Quem agrupa, organiza, molda, etc é o desenvolvedor. Se vc quiser pode separar um documento para regras de negócio, outro para isso e aquilo, mas o cliente não faz isso, o cliente pede, requisita. Dentre essas requisições pode até pedir documentação de software, mas esse pedido não vai sair na escrita de um caso de uso vai?

Em resumo, o enfoque ao utilizar-se de casos de uso e seus relacionamentos é identificar os objetivos do usuário, em vez de funções do sistema. O caso de uso é sim uma visão externa do sistema mas uma visa externa de um objetivo maior. O usuário pode escrever a descrição de um caso de uso da forma que puder (grau de formalidade), mas a organização de cenários (Na forma que conhecemos) ele jamais fará, a não ser que seja treinado para isso. Já um diagrama de caso de uso, que representa os objetivos do sistema ele gostaria de ver. Note que são coisas diferentes diagramas e descrições do caso de uso.

Ao passo que um User Story também se concentra no comportamento externo do sistema, mas ela é uma unidade informação menor, menos arbitrária e “É escrita pelo cliente” ou pelo menos, uma transcrição tão fiel quanto possível de uma história dele. A descoberta de user stories é feita constantemente, dede um conjunto inicial, criado no início do projeto, que seria na forma de “levantamento de requisitos” do sistema, até o fim do projeto. É um processo constante, derivativo e refinador, onde à medida que novas expectativas de funcionalidades existentes são descobertas novas user stories são criadas para refinar tais descobertas.

Portanto pode sim usar as duas, mas vc escolhe como. Eu uso uma mistura onde utilizo user stories para incrementar e de fato desenvolver e vou documentando o sistema com os casos de uso, simples descritivos, faço isso porque tem um agrupamento de funcionalidades que me ajudam na rastreabilidade das mesmas. Quando implemento um ou mais objetivos me comunico com o cliente de forma gráfica (diagramas de caso de usos e atividades e até classes) e obtenho seu feedback em forma de Use Stories.

Minha realidade: trabalho desenvolvendo internamente soluções para uma empresa de negócios financeiros, ou melhor, para um cliente fixo. Por isso estou sempre contando com o cliente

É isso, essa é apenas uma resposta a pergunta do tópico.

MarceloAraujo wrote:
Pois é. Caso de uso não precisa disso, não precisa daquilo. Eles são quase tão customizáveis quanto o RUP
Minha dúvida então fica sendo com o caso de uso feito em um modelo mais formal, cheio de fluxos, idas e vindas. Que é o modelo mais comum de ser usado no mercado, descrito em artigos de revista e em cursos on-line por aí

Marcelo... você me superou em provocação gratuita.

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

MarceloAraujo wrote:
Pois é. Caso de uso não precisa disso, não precisa daquilo. Eles são quase tão customizáveis quanto o RUP

Toda abordagem tem usa essência, sua invariante... o importante é entender o conceito, o retorno. E escolher a abordagem em função do retorno que você precisa.

Fluxos do UC ajuda levantar os dados/conceitos da interação ator/sistema. Ajuda também na organização dos cenários no UC, pois permite referenciar/relacionar fluxos alternativos.

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