Oi Leandro,

É o que sempre digo: o valor desse negócio aqui está, em grande parte, nas boas conversas que ele gera. Suas contribuições sempre me desafiam – e isso não tem preço.

Enquanto não experimentar (e pensar um tanto) em sua proposta, manterei minha sugestão principal: analistas trabalham em duplas; um deles se ocupará do registro do papo; a melhor maneira de descobrir e descrever requisitos funcionais é através de casos de uso. Estas são minhas sugestões que você conhece de longa data.

Mas, repito, sua provocação me fará pensar. De cara pensei numa adaptação de uma ferramenta pouquíssimo conhecida chamada Histórias de Aprendizado (a documentei no trabalho sobre Aprendizado Inter-Projetos).

Muito obrigado pelo “empurrão”. Coloca mais meia dúzia de chopps na conta. Abraços!

Paulo Vasconcellos

Entendo a sua decepção como um dos maiores defensores ( se não o maior) da ferramenta Caso de Uso ao ver os proprios idealizadores cederem as pressões de maneira tão patética, sem sequer assumirem isso. Patéticos como Ozzy Osbourne cantando Adele num show (as musicas ou a propria..hehehe).

Esses dias tive uma sacada que até cheguei a compartilhar contigo, sobre essa coisa de capturar requisitos. Pra virar proposta ainda precisa de muita teoria, mas tem seu pontencial. O lance é separar esse momento em dois, a history e a story. Na history temos a verdadeira descrição do processo e dos desejos mais intimos do stakeholder, temos o papo aberto e fluente, cheio de desvios naturais e sutilezas onde moram as pérolas que ajudarão na descrição dos requisitos de maior valor. Na story transformamos essas histórias em roteiros, desejos em requisitos.

Não podemos ignorar a influencia do escritor, no caso o analista, na construção desse roteiro (story), tampouco o estado de espirito do usuário no momento que o descreve. Esses dois fatores são prejudiciais para a construção de bons requisitos pois trazem consigo uma carga exagerada de “solução” para um momento onde o foco deveria ser no problema. Por isso proponho valorizarmos a history em detrimento da story no momento dessa conversa com o usuário.

Requisitos estruturados, extends, includes, casos de testes e afins, nada disso tem a ver com papo com usuário. Ouvir histórias, sim. Precisamos de uma forma de capturar essas histórias e preservá-las durante todo o ciclo de vida do sistema, mas certamente não será via casos de uso, como nos prova a sua própria história.

Não pretendo ser conclusivo nesse papo, pois como disse, precisa de teoria pra virar proposta, mas para quem tiver a oportunidade de praticar uma abordagem mais humana e natural nas entrevistas, fica a dica.

Abs!

Oi Marcelo,

Muitos, como eu, gostam tanto de “O Poderoso Chefão II” quanto do primeiro. Felizmente, existem exceções que comprovam a regra – a síndrome citada por ti. Mas é preciso ter cuidado.

Coplien e Bjørnvig, por exemplo, escreveram que até poderiam ter inventado um novo nome para a sugestão que apresentam em “Lean Architecture”. Mas optaram, felizmente, pela manutenção do termo “Caso de Uso”. Mas, não tenho dúvida, trata-se de uma evolução em relação aos formatos conhecidos até então. Jacobson e seus colegas, na minha opinião, não tiveram a mesma felicidade.

Sobre sua primeira colocação: a ferramenta Caso de Uso nunca teve a intenção de ser “auto-suficiente” e “definitiva”. Aliás, nenhuma ferramenta o é ou algum dia será. Martelo é martelo, chave de rosca é chave de rosca. Cada uma tem sua utilidade. Mas, como escrevi no artigo, estou para conhecer ferramenta mais eficaz que Casos de Uso para a descoberta e descrição de requisitos funcionais de um sistema.

Abraços! Obrigado pela participação.

Paulo Vasconcellos

Sinceramente, começaram a complicar as coisas. Não vejo o caso de uso como ferramenta auto-suficiente e definitiva. Porém, gosto muito de usá-la e realmente consigo descobrir muitos requisitos funcionais. Não consigo resolver tudo só com user stories, como alguns pregam por aí.

Agora, falar em Fatias de Casos de Uso é forçar a barra. Consigo resolver praticamente todas exceções com fluxos alternativos. Sei não. Está me parecendo aquela síndrome de continuidade de filme. O primeiro é bom, depois a continuação aparece e estraga tudo.

Marcelo Neves

Epic não, temas talvez. Os autores não fazem tal ligação nem citam esses termos. De qualquer maneira, é uma sugestão meio “varada n’água” (só serve para espantar os peixes) 🙂

Obrigado pela participação. Abraços!

Paulo Vasconcellos

Gostei do Post, mas deixa dar minha opinião, antes de qq coisa li o Guia (USE-CASE 2.0).
Acho que o “slice” é uma adaptação (“meia tosca”) ao conceito do “Epic” e “Temas” que existem a User Story.