User Stories X use cases

rodrigoy wrote:

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.

ok ok... pago uma rodada caso você faça um Agile Beer Drinking aqui no Rio

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

gilmatryx wrote:

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

Desculpe, mas "calcular" pode ser um cálculo requisitado e observável pelo ator sim. Mas acho que entendi o sentido da frase.

Pode ser... depende do negócio. Em um UC Calcular Empréstimo, o retorno observável é o valor do empréstimo (o empréstimo calculado), então está aderente a um negócio de banco. Como o calculo é feito, quais sistemas participam, em que banco eh gravado, não é observável pelo ator.

rodrigoy wrote:
Shoes, eu não afirmei que equipes ágeis não aplicam esta análise, para clarificar, estou falando sobre as literaturas e não como aplicamos no mercado. O fato é que essa análise de negócio não é escopo de XP e Scrum que são as práticas ágeis mais utilizadas (elas personificam essas práticas em papéis). O Kent Beck fala sobre isso no XP? O Ken Schwaber fala sobre isso no Scrum? É muito superficial certo? Quando usamos essas metodologias sem um bom Product Owner e sem cliente presente geralmente temos que adaptar muita coisa pra metodologia funcionar.

Vamos tentar analogias:

-> A especificação de Java não fala em Sistema Operacional. Se eu programo em Java eu não uso Sistema Operacional?
-> XP não fala em Domain-Driven Design. Ao usar XP eu não tenho Domain-Driven Design?

O que eu estou dizendo é que não é porque uma metodologia X não prescreve análise de negócios que esta não existe num projeto usando tal metodologia.

rodrigoy wrote:
Geralmente vejo analise do negócio como estabelecer o problema, os objetivos de ROI, escopo high-level. IMHO não vejo que fazer isso com o barco andando é uma boa idéia. Isso é a visão. Acho uma boa prática documentar isso nem que seja 3 parágrafos. Nos meus projetos reais mesmo com cliente presente eu estabeleço a visão no papel.

http://www.aspercom.com.br/ead/mod/resource/view.php?id=125
http://www.aspercom.com.br/ead/mod/resource/view.php?id=17

Isso é a sua opinião. Certa ou errada não corresponde à realidade de todos -ou da maioria- dos projetos ágeis.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3171 Offline

cmoscoso wrote:

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.

Então ... o problema que eu vejo é um requisitos do tipo : "a aplicação deve apresentar todos os cálculos com 3 casas decimais".
Fazer um teste para isso é até simples, mas criar um storie parece complexo. Tlv criar várias stories mas .. A ideia de storie seria mais Calculo de X , Calculo de Y e todos eles têm que obedecer ao requisito.
Por outro lado vejo que seria simples uma storie : Implementar controle transacional de envio de email. Mas é dificil imaginar um cliente escrever essa frase.

Tem alguma coisa - que não consigo identificar ao certo - que não bate.

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

sergiotaborda wrote:
Então ... o problema que eu vejo é um requisitos do tipo : "a aplicação deve apresentar todos os cálculos com 3 casas decimais".
Fazer um teste para isso é até simples, mas criar um storie parece complexo. Tlv criar várias stories

Se nao houver mais nada de importante sem duvida vc pode especificar isso em codigo tb. Entretanto acredito que na maioria das vezes esse tipo de requisito se for de apresentacao sobra para os testes de QA realizados em noutro momento.

sergiotaborda wrote:
mas .. A ideia de storie seria mais Calculo de X , Calculo de Y e todos eles têm que obedecer ao requisito.

A ideia de storie e um interesse do usuario no sistema, mas nao o interesse no conhecimento empregado para realizar a tarefa mas como aquela tarefa em sua essencia esta relacionada com o seu dominio de atuacao.

This message was edited 1 time. Last update was at 01/08/2008 19:05:45

sergiotaborda wrote:

Então ... o problema que eu vejo é um requisitos do tipo : "a aplicação deve apresentar todos os cálculos com 3 casas decimais".
Fazer um teste para isso é até simples, mas criar um storie parece complexo.

O exemplo q vc citou não poderia ser mais perfeito para uma estória/ticket. Acho que vc é quem está querendo fazer parecer complicado algo tão simples

sergiotaborda wrote:

Tem alguma coisa - que não consigo identificar ao certo - que não bate.

Sim, será que não é falta de prática e excesso de teoria?

http://www.parleys.com/display/PARLEYS/Home#title=Enough%20Process%2C%20let's%20do%20some%20practices;talk=4653123;slide=1

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3171 Offline

Taz wrote:

sergiotaborda wrote:

Tem alguma coisa - que não consigo identificar ao certo - que não bate.

Sim, será que não é falta de prática e excesso de teoria?

http://www.parleys.com/display/PARLEYS/Home#title=Enough%20Process%2C%20let's%20do%20some%20practices;talk=4653123;slide=1

Com certeza. Uma das coisas que me impede de usar isso na prática era não entender porque precisa existir uma diferença. A palestra acima realmente elabora um ponto que me parecia obvio desde um principio práticas são mais importantes que processo. Mas ele deixa claro também que mesmo assim é necessário um processo. Faltava encaixar então as práticas em um processo. Em particular duas : Levantamento Requisitos
(em que os casos de uso são uma das ferramentas) e breakdown de tarefas programáveis ( que eu achei que fossem as stories).

Achei que o breakdown e o conjunto de stories seria essa forma,mas agora, não sei mais. É que na minha cabeça, pelo menos agora, não é credivel entrar em um projeto sem saber quando acaba, quem precisa estar na equipa, etc.. o processo pode até ser iterativo, mas pegar os requisitos "on-the-fly" não parece credivel porque existem requisitos que não são programáveis. Para os que se traduzem em programação tem que haver um tradução para uma nova lista de "tarefas programáveis"

Mas é bom saber que existe alguém que também pensa que esse negocio de processo é overrated e que no final o que interessa são as práticas. As melhores práticas.
A palestras é boa para entender que não existem "as melhores práticas" existe o "conjunto de práticas, que juntas, mas se adequam ao objetivo em mãos" ( outro conceito que todo o mundo tem , mas que é dificil coloca em prática)

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

sergiotaborda wrote:

É que na minha cabeça, pelo menos agora, não é credivel entrar em um projeto sem saber quando acaba, quem precisa estar na equipa, etc.. o processo pode até ser iterativo, mas pegar os requisitos "on-the-fly" não parece credivel porque existem requisitos que não são programáveis.

Aí já entramos em outro assunto que são projetos de escopo aberto. Vc precisa convencer seu cliente interno/externo a, pelo menos, te dar uma chance de mostrar que a agilidade funciona e que um dos principais fundamentos dela é a mudança: requisitos mudam, conceitos mudam, prioridades mudam, etc.

sergiotaborda wrote:

Mas é bom saber que existe alguém que também pensa que esse negocio de processo é overrated e que no final o que interessa são as práticas.

... e que esse alguém e nada mais nada menos que um dos pais de UML/Casos de Usos

Fiquei um tempo out do GUJ, não tinha visto sua resposta. Suas analogias foram péssimas, mas não vale a pena discutir isso mais...

pcalcado wrote:
Isso é a sua opinião. Certa ou errada não corresponde à realidade de todos -ou da maioria- dos projetos ágeis.

Têm alguma pesquisa que fundamente esse teu ponto de vista?

Que dados você tem para dizer que minha colocação não corresponte à realidade da maioria dos projetos ágeis?

http://www.ambysoft.com/downloads/surveys/PracticesPrinciples2008.pdf

Página 4: Documentação do "Initial Requirements Envisioning" é comumente utilizado por ~50% das equipes pesquisadas.

Continuo dizendo que ter uma Visão documentada é uma boa idéia. Faz o projeto não perder o foco e deixa o escopo deslizar dentro do processo iterativo. Aliás, escreví um documento de visão nessa semana, e meu cliente gostou muito.

This message was edited 1 time. Last update was at 15/08/2008 23:08:47

rodrigoy wrote:Fiquei um tempo out do GUJ, não tinha visto sua resposta. Suas analogias foram péssimas, mas não vale a pena discutir isso mais...

Foram péssimas porque...? Elas foram claras: não é porque não está no livrinho dourado que não é usada.

rodrigoy wrote:
Têm alguma pesquisa que fundamente esse teu ponto de vista? Que dados você tem para dizer que minha colocação não corresponte à realidade da maioria dos projetos ágeis?

http://www.ambysoft.com/downloads/surveys/PracticesPrinciples2008.pdf

Página 4: Documentação do "Initial Requirements Envisioning" é comumente utilizado por ~50% das equipes pesquisadas.

Você realmente dá crédito a uma pesquisa na forma de formulário online e onde apenas 337 pessoas responderam algo e destas somente 248 a completaram? Ainda que ela fosse credível, o que "Initial requirements Envisioning" sinifica? Uma Master Story List entra nisso? Um relatório A3? Onde está escrito que isso é "estabelecer a visão no papel"?

rodrigoy wrote:
Continuo dizendo que ter uma Visão documentada é uma boa idéia. Faz o projeto não perder o foco e deixa o escopo deslizar dentro do processo iterativo. Aliás, escreví um documento de visão nessa semana, e meu cliente gostou muito.

Eu já escrevi dezenas de documentos de visão e tenho certeza que meus clientes também gostaram. E foram todos para projetos waterfall. Logo...?

Novamente: se você usa documento de visão ou como queira chamar ótimo, se funciona para você ótimo. Só que isso não faz parte da maioria dos projetos ageis -pelo menos não da maioria dos que tenho notícia, se você possuir uma pesquisa que tenha um mínimo de credibilidade por favor compartilhe- cada caso é um caso.

JavaChild Membro desde: 15/07/2007 22:39:03 Mensagens: 107 Offline

Não sou muito experiente no assunto mas a idéia que eu tenho comprado é a de Vinicius Telles dizendo que na ImproveIt não trabalham com visões nem com requisitos porque acreditam que o cliente não sabe direito o que ele quer e no caso que o cliente saiba o que ele quer, com o tempo esse desejo pode mudar e é muito provável que mude porque as pessoas vão ganhando experiencias e conhecimentos e mesmo assim, caso o que o cliente quer não fosse mudar, eles acreditam que não vão conseguir entender direito o que o cliente deseja. Por tais motivos eles não criam tais documentos e deixam a vida os levar.

Seguindo o mencionado me parece que nao seria muita boa ideia criar um documento de visåo porque com o tempo o cliente pode perceber que o problema é outro ou aprender que fazendo tal coisa pode obtr um ROI maior, por exemplo.

Só lembrando que não é porque você não tem um *documento* que você não tem *visão*

dc.rec1 wrote:Não sou muito experiente no assunto mas a idéia que eu tenho comprado é a de Vinicius Telles dizendo que na ImproveIt não trabalham com visões nem com requisitos

Vixe.... aonde o Vinicius disse isso? Não trabalhar com visão? Nem com requisitos?

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

Existem diferentes tipos de 'visao'. Me parece que o Rodrigo se refere a visao utilizada para promover o projeto entre seus financiadores e nao importa que seja documento porque ele é abandonado uma vez que o desenvolvimento se inicia.

Por outro lado, nem todo artefato precisa ser executavel pra ser util. Eric Evans por exemplo trata no contexto de DDD (quase mudando de assunto completamente!) de um tipo diferente de visao. Ele evita usar o termo documentacao para esse tipo de artefato e nao é dificil entender porque:

Write a short description (about one page) of the CORE DOMAIN and the value it will
bring, the "value proposition." [...] Keep it narrow. Write this statement early and revise it as you gain new insight.

A DOMAIN VISION STATEMENT can be used as a guidepost that keeps the development team headed
in a common direction in the ongoing process of distilling the model and code itself. It can be
shared with nontechnical team members, management, and even customers (except where it
contains proprietary information, of course).

Repare que a visao foca no core, nao na camada dominio como todo.

This message was edited 1 time. Last update was at 23/08/2008 15:47:52

pcalcado wrote:Você realmente dá crédito a uma pesquisa na forma de formulário online e onde apenas 337 pessoas responderam algo e destas somente 248 a completaram?

Sim, dou mais crédito do que a suposições pessoais.

pcalcado wrote:
Eu já escrevi dezenas de documentos de visão e tenho certeza que meus clientes também gostaram. E foram todos para projetos waterfall. Logo...?

Ah... sim... mais uma suposição... se eu documento a visão sou cascateiro

... muito científico também...

Valeu shoes...

Vou além, duvido que na ThoughtWorks vocês não trabalhem com uma visão inicial do projeto, mesmo que isso não tenha esse nome. Qualquer resposta a RFP pode ser uma visão nos termos que estou defendendo aqui...

pcalcado wrote:
Só que isso não faz parte da maioria dos projetos ageis -pelo menos não da maioria dos que tenho notícia, se você possuir uma pesquisa que tenha um mínimo de credibilidade por favor compartilhe- cada caso é um caso.

Se você me apresentar uma única pesquisa (podendo ser dos projetos que você tem notícia, se forem mais do que 248 ) provando que eles não documentam a visão e nem os requisitos iniciais "high level" por favor compartilhe-a. Senão, fala logo que é opinião pessoal sua e não o que mercado vêm aplicando.

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