Eu já vi projetos nos quais as mudanças de requisitos são gerenciadas por um sistema de controle de mudanças muito pesado. Isto é mau. Muitas mudanças importantes não acontecem porque o cliente não deseja passar pelo trabalho de enviar um controle de alterações, para que o software não atenda às suas necessidades. Algumas pequenas alterações são inseridas "sob o radar" para evitar o processo, de modo que o software nem coincide com o que você pensa que faz.
Por outro lado, também vi projetos nos quais o gerente de projetos pensa que "reativo" significa fazer com que os codificadores respondam a todas as solicitações dos usuários, o que significa que você nunca realiza nenhum desenvolvimento principal e que seu código se torna uma grande bagunça pesada de hackers. hackear. Essencialmente, agora você não tem nenhum desenvolvedor, você tem uma equipe de engenheiros de vendas superqualificados.
Então, pode-se esperar que exista uma situação entre esses dois pólos que funcione bem, e espero que o que funcione melhor para você seja uma escolha pessoal e situada. Definitivamente, vale a pena capturar o custo de cada alteração. Em uma estrutura como o Scrum, você pode expressar o custo em pontos da história, e a equipe pode trocar o trabalho que eles fazem em cada iteração versus o esforço total disponível. Se você tiver um gerente de produto, poderá solicitar que essa pessoa quantifique o benefício esperado de uma solicitação de alteração ou recurso. Isso geralmente é feito em termos de receita protegida (quantos clientes sairiam se você não fizer isso) e receita atraída (quantos clientes chegarão se você fizer isso). Isso pode ajudar na priorização, mas também pode refletir apenas o viés ou preferência pessoal do gerente de produto.
dos princípios: