Meus 2 cents,

Houve um tempo, quando trabalha em uma fabrica de software, onde as tarefas eram bem divididas: quem falava com o cliente e fazia o levantamento de requisito (os analistas de negocio e analistas de sistema) e quem codava. O DEV ja recebia um briefing pronto com os requisitos mastigados - era uma questao de ver se o sistema ja tinha todos os dados necessarios no banco, e caso negativo, chamar o DBA e conversar com ele sobre o assunto. Ele verificava os requisitos, e se necessario conversava com o team leader sobre as alteracoes necessarias (o sistema tinha versoes para DB2, Oracle e outros bancos - cheio de triggers e stored procedures, dai a necessidade do DBA analisar antes). Isso nos anos 90.

Era bom ? Funcionava, mas era uma estrutura grande. Na epoca usar PMBOOK/PMI, ITIL, COBIT, CMMI - tudo parecia fazer sentido.

Tinha o lado positivo que alguem ja negociava as regras de negocio - o DEV nao precisava ficar quebrando a cabeca com isso, exceto codar o necessario para fazer a ideia funcionar.

Ja nos anos 2000, participei de equipes com scrumm/agile - mas confesso que a ideia de microgerenciamento que alguns leaders fazem a cada sprint tornam o processo meio estressante.

Mas sim - engenharia de software eh uma materia as vezes negligenciada que vale a pena acompanhar com mais cuidado.