me desculpe a demora.

É verdade, raramente um usuário entende um caso de uso. Eles são uma excelente ferramenta para os analistas (na absorção e desenvolvimento dos requisitos), mas péssimos para a interação com clientes e usuários.

Por isso sempre recomendo a elaboração de protótipos. A “tela” é um pouquinho mais complexa? Desenhe-a. Sinceramente, não conheço meio melhor para tirar aquela expressão de “?” do rosto dos usuários.

Meu problema com as histórias é a sua granularidade e sua amarração / organização. Em projetos de médio e grande portes, particularmente.

Quando as troco por UC’s, não estou trocando flexibilidade “por nada”. Aliás, não perco flexibilidade. E ganho uma unidade mais fácil de ser gerenciada.

Aqui acho que entramos em questão de gosto e experiência. A sua com histórias é maior que a minha. Mas reforço: não deixo de ser ágil ao adotar UC’s.

Abraços,

Não sei você mas eu NUNCA vi um usuário entender um caso de uso. Eles fingem que entendem, lêem, assinam, validam mas não têm idéia do que está escrito ali. No fim das contas o desenvolvedor implementa o caso de uso exatamente como especificado, definido e validado e não é nada do que o cliente queria.

Histórias são mais interessantes por diversos aspectos. Elas são escritas em linguagem natural e, principalmente, utilizando a ubiquitous language do sistemas (Evans, DDD). Elas não invluem todos os detalhes exatamente porque fazer isso seria besteira, os detalhes podem mudar a qualquer momento.

Num processo tradicional eu não vejo como histórias poderiam dar certo mas num processo agil não utilizá-las é perder flexibilidade a troco de nada.

[]s

Como vc sabe, o tema muito me interessa. Gostei da apresentação, particularmente da mensagem: “toda história tem que atender um objetivo do negócio”. Jóia.

Só não gosto e não concordo muito com o meio, as histórias. IMHO, Casos de Uso fazem mais sentido. Pq? Pq eles são o “constructo” dos processos de negócio. São mais naturais naquele mundo (o negócio). Processos, Atividades e Tarefas podem ser facilmente mapeados para um caso de uso.

Histórias, por obrigação, são muito pequenas. O que acaba forçando que o AN (ou BA) crie outra unidade de organização, planejamento e gerenciamento.

E, até que me provem o contrário, não deixo de ser ágil (e “agile”) por utilizar Casos de Uso.

Abraços,