Ainda existe um agravante: até o “scrum master” pensa assim!
Mas ai já é outra história.

Pode apostar, eu como desenvolvedor não vou aceitar isso.
Comportamentos como esse com certeza levarão qualquer projeto ao fracasso.

Uma coisa é verdade: ganhamos muitos inimigos quando queremos trabalhar direito. irônico, não…

1) A arroância é inerente às pessoas, também já conheci desenvolvedores com ego maior que a fábrica de software, onde repetiam aos 4 ventos que não precisavam de caso de uso, nem de qualquer outra documentação, que eles eram os tais, e que o projeto não precisava de mais ninguém, além deles. Resumindo, não atrele arrogância ao analista, e sim àquela pessoa específica. Isso também vale para gerentes de projeto. Todos, desde o cara da limpeza até ao diretor da empresa, devem ser humildes. Todos devem admitir seus erros e suas limitações.

2) A burrice tb é inerente às pessoas, também já conheci vários analistas que são burros… isso mesmo… burros… que não têm competência na escrita o suficiente para elaborar uma documentação decente! Pois é claro, se há mtas dúvidas, é pq o caso de uso não foi detalhado o suficiente, isso é óbvio. A incopetência pode ser técnica também, o analista pode “achar” que conhece alguma metodologia, mas não conhece, pois todo processo/metodologia/boa_prática sempre tem uma atividade/tarefa/procedimento que é tipo uma “reunião de entendimento do caso de uso” com todo mundo (projetistas, desenvolvedores, analistas de teste, etc.), justamente com o objetivo de dirimir estas possiveis dúvidas que possam surgir, pois, por mais perfeito que seja o caso de uso, ele sempre terá alguma “falha”.

Então, caro Rafael, na minha opinião, vc deu azar de pegar um analista burro e arrogante em sua trajetoria profissional. Isso acontece mesmo. Paciência, né?! Eu imagino que o mercado inteiro não esteja assim, espero que isso seja exceção, pq se não for, estamos perdidos.

[]’s
Ronald.

Veja que relato importante.

Magno

Primeiro de tudo, quando um profissional é ruim ele não é parâmetro. O analista que tu citaste não sabe o que está falando, não sabe sobre processo e não sabe modelar.

Outra coisa é que mesmo com a modelagem o implementador (isso em processos prescritivos e não em agéis) ele vai conceber a aplicação com base nos requisitos funcionais, mas dando soluções de acordo com o seu conhecimento e experiência. A documentação e um processo prescritivo não tem nada haver com a questão do desenvolvedor não pensar.

Na verdade essas opiniões como a tua que foi expressada aqui acontece por falta de implementação de modelos de processos corretos. Com certeza nesta instituição que citaste o processo não funciona da maneira que deveria funcionar. O ideal realmente seria o implementador ter o mínimo de esforço pra enteder o negócio e os requisitos funcionais e implementar de acordo com as melhores técnicas e da melhor maneira possível. Esse é o objetivo da documentação/modelagem. No momento que o implementador não entende a documentação e o negócio, a documentação está mal feita ou há furos no processo. E tudo isso não tem haver com o processo cascata, só em instituições que utilizam este processo.

Trabalho em uma fábrica caso queiras qualquer relato sobre como funciona aqui posso passar. Aqui, com certeza, os implementadores conhecem o negócio e participam ativamente da concepção da solução, mesmo sendo um processo prescritivo.

Mas enfim, acho importante relatos como este teu.

Continue estudando um dia você será recompensado, nunca o resultado pode ser imediato.. tem que ser no tempo de casa.. carreira e vida.

Abs,

Abraços,

[]’s