A Analogia Errada para o Desenvolvimento de Software

Compartilhe:

Desde quase o começo da história do desenvolvimento de software, a comparação com a construção civil foi largamente utilizada para descrever esse tipo de projeto. São, no entanto, trabalhos de naturezas muito distintas.

Ouça agora ao artigo!

Embora tenham evoluído ao longo dos tempos, projetos de construção existem há eras na história da humanidade.

E, em linhas gerais, sua forma de execução se manteve a mesma: uma longa fase de definições e especificações no início que tem como saída um plano, seguida de sua fase de execução.

Parece natural para o ser humano comparar outros tipos de trabalho com um que lhe seja tão familiar.

Os métodos tradicionais de desenvolvimento de software buscaram algo similar com o modelo em cascata e suas fases sequenciais de levantamento e análise de requisitos, especificação, desenvolvimento e testes.

Ainda hoje é comum utilizarem-se as expressões “engenharia ou engenheiro de software”, “arquitetura ou arquiteto de software ”. E até mesmo “construção de software ”, todas vindas da analogia com a construção civil.

Por que métodos tradicionais de desenvolvimento de software não funcionam?

O livro Wicked Problems, Righteous Solutions (DeGrace & Stall, 1990 apud. Sutherland, 2004) já descrevia em 1990 as razões por que métodos tradicionais de desenvolvimento de software não funcionam, a partir de suas prerrogativas básicas:

  • requisitos não são completamente compreendidos antes do início do projeto;
  • usuários só sabem exatamente o que querem após ver uma versão inicial do produto;
  • requisitos mudam frequentemente durante o processo de desenvolvimento;
  • novas ferramentas e tecnologias tornam as estratégias de desenvolvimento imprevisíveis.

Sabemos, portanto, que comparar projetos de desenvolvimento de software com projetos de construção civil não faz sentido. A analogia simplesmente não funciona.

Sobre o autor(a)

Função não encontrada

Artigos relacionados

O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar…

Marcos Garrido, Sócio-fundador e Trainer na K21

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…

Após alguns anos desenvolvendo produtos e ajudando outras empresas a fazer tal, gostaria de listar com vocês alguns erros comuns que percebi ao longo dessa jornada. Olhando para as 4 Áreas de Domínio da Agilidade (Negócio, Cultural, Organizacional e Técnica)…

Uma das principais habilidades que desenvolvemos enquanto consultores é a de fazer boas perguntas. Uma vez que as pessoas percebem o poder que tem uma boa pergunta, colocada ali na hora certa e que muda o destino de uma reunião,…