[quote=gilmatryx][quote=Gustavo Serafim]
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.
[/quote]
Desculpe, mas “calcular” pode ser um cálculo requisitado e observável pelo ator sim. Mas acho que entendi o sentido da frase.[/quote]
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.
-> 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.
Isso é a sua opinião. Certa ou errada não corresponde à realidade de todos -ou da maioria- dos projetos ágeis.
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.[/quote]
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.
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.
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.
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)
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.
… 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… 8)
[quote=pcalcado]
Isso é a sua opinião. Certa ou errada não corresponde à realidade de todos -ou da maioria- dos projetos ágeis.[/quote]
Têm alguma pesquisa que fundamente esse teu ponto de vista? :roll: Que dados você tem para dizer que minha colocação não corresponte à realidade da maioria dos projetos ágeis?
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.
[quote=rodrigoy]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… 8)
[/quote]
Foram péssimas porque…? Elas foram claras: não é porque não está no livrinho dourado que não é usada.
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”?
[quote=rodrigoy]
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. [/quote]
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.
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.
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:
[quote]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).
[/quote]
Repare que a visao foca no core, nao na camada dominio como todo.
[quote=pcalcado]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?
[/quote]
Sim, dou mais crédito do que a suposições pessoais.
Ah… sim… mais uma suposição… se eu documento a visão sou cascateiro :x… muito científico também… :roll: 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…
[quote=pcalcado]
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.[/quote]
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. :x :x :x
[quote=rodrigoy][quote=pcalcado]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?
[/quote]
Sim, dou mais crédito do que a suposições pessoais.
[/quote]
Então acho que damos valores há coisas muito diferentes. Eu trabalho atualmente numa empresa com 1000 pessoas e no meu projeto atual existem 300 pessoas. Uma pesquisa com 240 pessoas que responderam uma enquete na Internet não me diz nada. Se você realmente vê qualquer valor estatístico nisso…
Pode explicar onde eu falei que voc6e faz Cascata na frase acima? Na verdade o que a frase acima mostra é que uma coisa não depende da outra.
Reposta à RFP é uma coisa completamente do projeto, qualquer pessoa que já participou de um projeto deste sabe disso. Mas nós trabalhamos com visão de projeto, claro. A diferença é que nós não instituinalizamos isso cm um artefato ou coisa do tipo, cada projeto possui necessidades distintas, em muitos projetos não existe qualquer visão sobre o que precisa ser feito antes de se iniciar a fazer alguma coisa.
De qualquer forma, não entendi seu ponto. Onde foi que eu falei que não existe uma visão inicial do projeto? O que eu falei foi que sua crítica sobre como xUP é mais completo porque tem templates e documentos de visão não procede. Você não precisa de documentos ou templates para ter umd ado benefício, do metodologias ágeis simplesmente não funcionariam.
[quote=rodrigoy]
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. :x :x :x[/quote]
Espera aí: são 248 pessoas naquela pesquisa, não 248 projetos. Pessoas anônimas e que preencheram um questionáriozinho de internet tão credível quanto uma equete de jornal (aliás, aqui tem um bom exemplo da confiabilidade deste método). Eu posso dizer que esta é a minha experiência, que já envoleram bem mais que 500 pessoas em projetos ágeis.
Como disse algumas vezes antes:
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.
Meu!!! E daí?!??! Você saiu perguntando para as 300 pessoas se elas acham uma boa ou não documentar a visão do projeto, mesmo que seja um documento de 1 página? 300 pessoas também não são 300 projetos e não é porque a ThoughtWorks não documenta a visão que isso não é válido.
Foi sarcasmo seu! :? Deixa pra lá…
A visão também é documento do projeto. Escopo é uma das coisas sob responsabilidade da visão, assim como envolvidos, integrações e coisas do tipo. Visão não é puramente um documento de requisitos.
O xUP apresenta boas práticas para estabelecer uma visão. O modelo de artefatos é o menos importante. De resto, deixa pra lá também…
OK, aqui sim vc colocou mais claramente. É SUA OBSERVAÇÃO PESSOAL AD-HOC. Só para aprofundar a questão: 500 pessoas em quais empresas? Globo e ThoughtWorks, certo? Não estou desmerecendo seu trabalho, mas é uma amplitude de empresas muito pequena. Eu, por outro lado já rodei por mais de 70 empresas aqui no Brasil e foram muito mais que 500 pessoas. Não que todas estejam estabelecendo uma visão no papel, para falar a verdade, algumas empresas não sabem o que é uma visão.
Resumindo meu ponto de vista: Por que ter uma visão no papel? Uma das maiores aversões a agilidade que está ocorrendo aqui no Brasil é o sentimento de falta de escopo. Talvez não tenhamos a maturidade dos projetos de vocês. Porém, vejo que documentar uma visão macro que permita o escopo deslizar no processo iterativo, MAS QUE DÊ PROPÓSITOS CLAROS para o projeto é muito saudável para essas equipes que tenho contato. Os sponsors ficam mais tranquilos e aceitam melhor a iteratividade.
[quote=rodrigoy][quote=pcalcado]
Eu trabalho atualmente numa empresa com 1000 pessoas e no meu projeto atual existem 300 pessoas.
[/quote]
Meu!!! E daí?!??! Você saiu perguntando para as 300 pessoas se elas acham uma boa ou não documentar a visão do projeto, mesmo que seja um documento de 1 página? 300 pessoas também não são 300 projetos e não é porque a ThoughtWorks não documenta a visão que isso não é válido.
[/quote]
E dai que soh uma empresa isolada possui 3 vezes mais pessoas que a pesquisa que voce da valor. Alias, eu nao sou o unico que questionou a validade desta pesquisa:
E ate onde eu li a pesquisa seria sobre o que as pessoas seguem, nao sobre o que elas acham.
Visao nao eh, necessariamente, um documento, Rodrigo. Muito menos eh necessariamente um " documento de visao".
ok.
Voce quer meu curriculum, Rodrigo? Voce me conhece desde quando para saber onde e com quem ja trabalhei? Nao eh porque voce sabe de duas empresas que eu ja trabalhei que minha experiencia resume-se a isso. Vamos evitar as falacias, por favor.
Eu pratico agilidade no Brasil desde 2003 e com projetos internacionais desde 2005. Isso nunca foi problema " do Brasil", no mundo todo este eh um ponto de atencao. Se voce prefere utilizar um documento de visao para fazer isso otimo.
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.
