Bate-Papo - Mitos da Engenharia de Software

Empresas investem altas cifras no desenvolvimento de metodologias e ferramentas de desenvolvimento de sistemas. Mas será que "Somente uma boa metodologia garante que a equipe terá êxito em seus resultados?"

O Projeto atrasou. Sempre tem uma mente brilhante para dizer: "Vamos trazer fulano!"

Será que aumentar a equipe realmente é uma boa saída para resolver um atraso?

Aqui o velho dilema: "O que é necessário do ponto de vista de requisitos para começar um projeto".

Essa questão pode parecer bem mais simples do que é de verdade!

Será que é só dividir em "Equipe de Projeto" e "Equipe de Manutenção" e esse problema está resolvido?

O fato de implantar marca o fim do trabalho da equipe?

Esse é o primeiro papo dessa "Segunda fase" do mitos da engenharia de software, agora falando mais especificamente dos "Mitos da Engenharia de Requisitos no Contexto Ágil".

O primeiro papo só poderia ser sobre o mito mais difundido por aí pelos menos informados: "Não há engenharia de requisitos no modelo Ágil"

No segundo papo da "segunda fase", vamos abordar um mito muito comumente propagado entre os profissionais de TI, até mesmo sem perceber: Dizer que Engenharia de Requisitos é a mesma coisa que Documentação.

Escrever histórias de usuário é a única forma de documentação de requisitos no modelo ágil. Será que as histórias de usuário são suficientes para que o software seja entregue funcionando (e continue funcionando depois da entrega)?

Existe valor final na documentação de requisitos? Será que apenas código funcionando tem valor final no ágil?

Este vídeo é uma resposta para a pergunta do aluno Wesley, que gostaria de saber o que eu (Sabino) e o Prof. Eduardo Castro faríamos se estivéssemos à frente de uma equipe em atraso. O mais interessante é que quando perguntei a primeira vez para o Eduardo o que ele faria para comparar com o que eu faria, nossas opiniões foram muito parecidas. O primeiro passo é... (veja no vídeo rsrsrsrss)