sergiotaborda wrote:
i.e. em lado algum vi escrito que Agile /Stories significa ignorar a fase de levantamento. Como se relacionam estas duas coisas: levantamento de requisitos e stories ?

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

rodrigoy wrote:
Esse caso de fato é muito banal, porém, ocorrem situações como um sistema de Call Center Vendas onde 85% das funcionalidades estão num único caso de uso e de lá se extraem umas 20 histórias. Aí o caso de uso é bom para concentrar tudo.

pcalcado wrote:
Isso não é verdade. Eu já apliquei metodologias ágeis onde clientes não estavam presentes -inclusive no meu projeto atual. Metodologias ágeis em geral não falam sobre análise de negócios bem como não falam em arquitetura de camadas, domain-driven design ou outra prática técnica. 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.

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

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

rodrigoy wrote:

pcalcado wrote:
Isso não é verdade. Eu já apliquei metodologias ágeis onde clientes não estavam presentes -inclusive no meu projeto atual. Metodologias ágeis em geral não falam sobre análise de negócios bem como não falam em arquitetura de camadas, domain-driven design ou outra prática técnica. 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.

rodrigoy wrote:

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

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.

rodrigoy wrote:

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.

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

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

MarceloAraujo wrote:
Qual a vantagem de se representar fluxo de informação de forma textual?
Criar uma história simples e rabiscar um protótipo não seria mais direto e de fácil entendimento?

Alexandro.Almeida wrote:

MarceloAraujo wrote:
Qual a vantagem de se representar fluxo de informação de forma textual?
Criar uma história simples e rabiscar um protótipo não seria mais direto e de fácil entendimento?

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?

MarceloAraujo wrote:... Ou então aquela falsa sensação de segurança que um documento mais formal acaba passando pra gerentes acostumados com desenvolvimento em cascata?

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

pcalcado wrote:
Muitas vezes o software é desenvolvido ao mesmo tempo que é feita a análise de negócios. Muitas vezes a análise é feita antes.

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.