Estava discutindo no grupo que temos aqui em Maceió e ao perguntar se alguém tinha o livro Writing Effective Use Cases um amigo (que fez o curso de CSM) disse que eles abominaram o uso de Casos de Uso para usar apenas User Stories.
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
Se você pegar o conceito por trás de casos de uso cunhado pelo Ivar Jacobson você verá que praticamente é a mesma coisa. Caso de uso não precisa ser formal. Na literatura do Kent Beck eu não vejo ele diferenciando muito Casos de Uso de Stories. Pra quem tá começando pode cair na modinha e falar que só usa Stories porque está no Index Card…
A
andre_salvati
rodrigoy:
Pra quem tá começando pode cair na modinha e falar que só usa Stories porque está no Index Card…
Isso aí … além de estar na moda será mais feliz…
Perceba a diferenciação q o Fowler faz entre Casos de Usos e Stories, provando que são coisas DIFERENTES.
Perfeito, como sempre…
R
rodrigoy
Taz? Vamos começar tudo de novo?
Casos de Uso e Stories são técnicas para desenvolver o sistema pelo ponto de vista do Ator.
Casos de Uso e Stories não são documentos técnicos.
Casos de Uso e Stories são suscintos.
Casos de Uso e Stories são atômicos.
Casos de Uso e Stories agregam valor de negócio.
Casos de Uso e Stories são utilizadas para gerenciar o projeto.
Casos de Uso e Stories dividem o sistema funcionalmente.
Casos de Uso e Stories podem ser estimados.
Casos de Uso e Stories direcionam os testes.
Eu só consigo ver semelhanças entre Casos de Uso e Stories. Talvez a razão de enxergar toda essa diferença é que poucas pessoas sabem a técnica correta de Casos de Uso. A julgar pelas mais de 3000 pessoas que estão inscritas no nosso curso on-line grátis sobre Casos de Uso, pode ter certeza que tenho bons fundamentos para fazer tal afirmação.
Se você puder citar um número maior de diferenças marcantes com relação aos dois eu posso concordar que eles são diferentes.
Outro ponto: Foram raros os casos que ví o cliente escrever User Stories da maneira que o XP prega. Eles podem participar dando informações mas não sabendo lidar com histórias diretamente. Essa talvez possa ser uma das diferenças, mas que nunca ocorre na prática.
P
pcalcado
Casos de Uso e User Stories são diferentes, apesa de parecidos, como o próprio Fowler falou:
Não tem nada de “modinha”, é um modo diferente de particionar o que precisa ser feito. É claro que os conceitos são os mesmos, assim como boa parte dos conceitos basicos de qualquer metodologia iterativa -como XP e RUP- são os mesmos, mas ter os mesmos conceitos básicos não faz de duas coisas iguais (católicos x protestantes que o digam).
Bom, siceramente eu não uso Use Cases há aluns anos simplesmente porque além de ninguém conseguir me convencer que eles são melhores que histórias eu nunca vi um use case ser realmente entendido pelo cliente -o que acontece com histórias, que o próprio cliente escreve.
R
rodrigoK
Estranho seria se ele não entendesse o que escreveu.
Abraços,
R
rodrigoy
Você pode comparar Stories com Cenários segundo o Fowler. Não tenho um estudo, mas é muito comum um Caso de Uso ser um único cenário (só tem fluxo básico), ou talvez um único cenário importante. Mais uma vez: Casos de Uso não precisam ser formais, não precisa ser descrito na forma de fluxos, as vezes o nome do caso de uso já basta.
:shock: Isso pra mim é modinha. Como já tinha também dito anteriormente o Kent Beck toma a literatura do Jacobson como base para lidar com Stories. Já tinha falado pro próprio Taz em tópicos anteriores. É uma discussão meio morta essa. IMHO, seria a mesma coisa que dizer que abominam o uso de Iterações… só usam Sprints agora. :?
P
pcalcado
O trecho que você colou apenas confirma o que eu disse. Existe correlação, aprtem do mesmo princípio. Existe uma diferença enorme entre correlação e equivalência e o mesmo trecho citado mostra exatamente como não se podem intercambiar ambos. Se você tiver apenas o nome do caso de uso ele ainda é muito diferente de uma história. Uma história é apenas um placeholder para uma conversa direta entre analista e desenvolvedor. Quando essa conversa está acotnecendo levanta-se critérios de aceita para a história.
Novamente: não é porque possuem conceitos parecidos que são iguais. RUP e XP partem dos mesmos princípios com soluções parecidas mas bem diferentes.
Sua comparação com sprint é sem sentido, creio. Não existe diferença prática entre sprint e iteração, é apenas o nome que Scrum usa (Scrum é otemo em inventar nomes novos para coisas velhas) mas existem diferençar entre casos de uso e histórias. Como disse o Fowler existe diferença: satisfazer um objetivo x organizar entregas.
Para mim também é uma conversa morta. São coisas diferentes, cada um possui seu lugar e não há motivo para tentar iguala-las -a menos que se faça como o Ambler que precisa vender um processo baseado em casos de uso.
L
leofernandesmo
Qual?? UP?
Alguém tem conhecimento de Crystal? Como ela trata o assunto?
Já que o livro citado é do próprio Cockburn.
S
sergiotaborda
leofernandesmo:
Estava discutindo no grupo que temos aqui em Maceió e ao perguntar se alguém tinha o livro Writing Effective Use Cases um amigo (que fez o curso de CSM) disse que eles abominaram o uso de Casos de Uso para usar apenas User Stories.
Casos de Uso são descrições não técnicas e não-tecnologicas daquilo que o usuário pode esperar do sistema. São descrições da
interação do usuário com o sistema. São compostos pelas ações que o usuário toma e o sistema toma em resposta até que um objetivo seja conseguido. Esse objetivo é um objetivo de negocio. Por exemplo “Reservar Quarto”.
Caso de Uso são utilizados em vez/como se fosse um protótipo, mas com todas as referencias a layout e tecnologia removidas.
Não importa como sistema será desenhado/construido, ele tem que funcionar daquela forma. Casos de uso são utilizados para levantar requisitos ( não para os documentar) e para que os testes saibam como confirmar que o sistema faz o que deve.
Casos de Uso estão relacionados aos requisitos funcionais mas não são requisitos nem servem para os documentar. Eles são escritos normalmente pelo analista num documento de analise, mas os bons CU devem ser escritos em conjunto com o cliente. Nada impede que o cliente os escreva sozinho.
Estórias ( não Histórias (stories =/= histories) ) são descrições simples e curtas (titulos) daquilo que o sistema terá que fazer. Como são limitadas em tamanho devem ser partidas em estórias menores até que seja claro que há a fazer. Por exemplo “Reservar quarto” é muito genérico. O processo de criação é o mesmo, mas o detalhes e o propósito é diferente. Em XP elas devem ser criadas pelo cliente (afinal são USER stories) , mas nisso não ha diferença paras os CU que tb podem ser escritos pelo cliente.
A diferença é que os UC servem como um protótipo para que todos saibam o que esperar do sistema, enquanto estórias servem para que a equipe possa estimar o que tem que fazer e portanto quanto o esforço necessário. Ambas mantêm um nivel alto desprovido de detalhes tecnológicos ou de interface gráfica.
dizer que aboliu caso de uso é irrelevante já que não servem o mesmo proposito que as estorias. A pergunta ser feita é: se não usa casos de uso o que vc usa em vez? Se responder “User Stories” das duas uma:
não sabe o que está a fazer e acha que é tudo a mesma coisa
dá preferencia a formas de avaliar esforço em vez de formas de avaliar requisitos.
não faz levantamento de requisitos ( cenário é que os CU são irrelevantes)
Por outro lado se a pessoa usa CU mas não estórias a pergunta é : como estima o esforço do projeto ?
Já que CU não servem para isso e não são usadas estórias, então outro método é necessário. A menos, é claro, que o esforço não seja estimado.
São coisas que nascem do mesmo lugar ( cliente) e dizem quase a mesma coisa ( muda o nivel de detalhes e a forma) mas não servem para a mesma coisa.
A
agazola
O vocábulo “estória” entrou em desuso… deve-se utilizar “história” para todos os casos
abs
R
rodrigoy
O XP também na minha opinião. Eu achei uma frescura sem tamanho o Schwaber chamar Iteração de Sprint, assim como não ví diferença entre cenário de story quando estudei XP. São nomes diferentes para coisas que já existiam. Mas pra ficar na modinha, vamos chamar de Story. (Isso é bem IMHO, não precisa despejar bibliografia. Pra uma conversa morta, essa tá rendendo demais até). 8)
:lol: :lol: :lol: :lol: Essa foi boa… ele que não nos ouça…
[editado] escreví storie no post todo! [/editado]
S
sergiotaborda
O vocábulo “estória” entrou em desuso… deve-se utilizar “história” para todos os casos
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.
A
andre_salvati
É verdade…
Por outro lado estou pensando em voltar a usar CU (nome estranho esse :roll: ) de novo, só pq nossos colonizadores ainda usam e quem não usa “não sabes o que estaires a fazer”
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.
Segue exemplo simples para ilustrar (um exemplo mais complexo justificaria melhor a abordagem, acredito)
Reservar Apartamento
Fluxo básico
Atendente informa hotel, datas e tipo de apartamento
Sistema fornece disponibilidade e preço
Atendente informa CPF do cliente e confirma
Sistema exibe um identificador (R1)
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?
R
rodrigoy
Gustavo Serafim:
Reservar Apartamento
Fluxo básico
Atendente informa hotel, datas e tipo de apartamento
Sistema fornece disponibilidade e preço
Atendente informa CPF do cliente e confirma
Sistema exibe um identificador (R1)
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?
</blockquote>
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.
A
Andre_Brito
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 :-
G
gilmatryx
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”?
G
Gustavo_Serafim
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.
G
Gustavo_Serafim
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”?
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.
G
Gustavo_Serafim
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.
S
sergiotaborda
Gustavo Serafim:
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.
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 ?
R
Rodrigo_Manhaes
Principalmente se você utiliza testes de aceitação.
P
pcalcado
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.
R
rodrigoy
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”.
R
rodrigoy
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.
R
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.
P
pcalcado
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.
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.
A
Alexandro.Almeida
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.
R
rodrigoy
:?: :?: :?: :?: :?: :?: :?:
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.
R
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.
P
pcalcado
rodrigoy:
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.
:?: :?: :?: :?: :?: :?: :?:
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.
É ó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.
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.
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.
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)
A
Alexandro.Almeida
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.
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?
P
pcalcado
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.
M
MarceloAraujo
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
Atendente informa hotel, datas e tipo de apartamento
Sistema fornece disponibilidade e preço
Atendente informa CPF do cliente e confirma
Sistema exibe um identificador (R1)
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?
A
Alexandro.Almeida
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?
M
MarceloAraujo
Alexandro.Almeida:
MarceloAraujo:
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?
Entendo esse ponto de vista, já passei por projetos exatamente assim, onde a área de TI do cliente obrigava a entrega de determinados documentos. Mas a questão que quero levantar é relativa a benefício. O que faz uma pessoa, seja cliente ou desenvolvedor, preferir representar fluxo de informação de forma textual em casos de uso formais? Não seria falta de conhecimento sobre técnicas mais ágeis para o mesmo objetivo? Ou então aquela falsa sensação de segurança que um documento mais formal acaba passando pra gerentes acostumados com desenvolvimento em cascata?
A
Alexandro.Almeida
Bingo !!!
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.
R
rodrigoy
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.
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.
Desculpe, mas “calcular” pode ser um cálculo requisitado e observável pelo ator sim. Mas acho que entendi o sentido da frase.
R
rodrigoy
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.
G
gilmatryx
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.
R
rodrigoy
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. 8)
(sim… isso foi uma provocação gratuita)
A
Alexandro.Almeida
rodrigoy:
Alexandro.Almeida:
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.
G
gilmatryx
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.
A
Alexandro.Almeida
rodrigoy:
MarceloAraujo:
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. 8)
(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.
G
gilmatryx
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 :D).
M
MarceloAraujo
rodrigoy:
MarceloAraujo:
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. 8)
(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í 8)
R
rodrigoy
Faça o meu curso on-line grátis no site da Aspercom: www.aspercom.com.br
(basta se cadastrar no site)
Sim… quebra por cenário e ficará praticamente igual a Stories. No RUP é assim. No MSF é assim. No EssUP é assim. No OpenUP é assim.
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.
S
sergiotaborda
rodrigoy:
sergiotaborda:
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 = NT testes por requisito.
Se todos os NT 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 ?
A
Alexandro.Almeida
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:
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.
C
cmoscoso
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.
G
gilmatryx
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 :roll:
É isso, essa é apenas uma resposta a pergunta do tópico. :lol:
R
rodrigoy
MarceloAraujo:
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í 8)
Marcelo… você me superou em provocação gratuita. :x
G
Gustavo_Serafim
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.
M
MarceloAraujo
rodrigoy:
MarceloAraujo:
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í 8)
Marcelo… você me superou em provocação gratuita. :x
ok ok… pago uma rodada caso você faça um Agile Beer Drinking aqui no Rio
G
Gustavo_Serafim
gilmatryx:
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.
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.
P
pcalcado
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.
Isso é a sua opinião. Certa ou errada não corresponde à realidade de todos -ou da maioria- dos projetos ágeis.
S
sergiotaborda
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.
C
cmoscoso
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.
A
andre_salvati
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
Sim, será que não é falta de prática e excesso de teoria?
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
andre_salvati
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
R
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)
pcalcado:
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? :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.
P
pcalcado
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)
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”?
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.
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.
D
dc.rec1
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.
P
pcalcado
Só lembrando que não é porque você não tem um documento que você não tem visão
R
rodrigoy
Vixe… aonde o Vinicius disse isso? Não trabalhar com visão? Nem com requisitos?
C
cmoscoso
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.
R
rodrigoy
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?
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…
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.
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
M
marcosalex
"
P
pcalcado
Não tinha visto isso até agora.
rodrigoy:
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?
Sim, dou mais crédito do que a suposições pessoais.
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.
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
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.
R
rodrigoy
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.
P
pcalcado
rodrigoy:
pcalcado:
Eu trabalho atualmente numa empresa com 1000 pessoas e no meu projeto atual existem 300 pessoas.
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.
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.
S
seufagner
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.
