Saudações a todos!!!
O objetivo deste artigo é despertar alguns times para algumas práticas de engenharia (como um bom design de domínio, refactoring e TDD) que são peças fundamentais para que possamos colher os benefícios das metodologias ágeis. Vamos começar voltando um pouco no tempo e explicar como era o mundo antes das práticas ágeis:
Crise do Software
A “crise do software” foi um termo cunhado para descrever as dificuldades enfrentadas no desenvolvimento de software no fim da década de 60. A complexidade dos problemas, a ausência de técnicas bem estabelecidas e a crescente demanda por novas aplicações começavam a se tornar um problema sério. Foi nessa época, mais precisamente em 1968, que ocorreu a Conferência da OTAN sobre Engenharia de Software (NATO Software Engineering Conference) em Garmisch, Alemanha. O principal objetivo dessa reunião foi estabelecer práticas mais maduras para o processo de desenvolvimento. Por essa razão, o encontro é considerado hoje como o nascimento da disciplina de Engenharia de Software.
NATO Software Engineering Conference 1968
Duas décadas depois, em 1986, Alfred Spector, presidente da Transarc Corporation, foi coautor de um artigo comparando a construção de pontes ao desenvolvimento de software. Sua premissa era de que as pontes normalmente eram construídas no tempo planejado, no orçamento, e nunca caíam. Na contramão, os softwares nunca ficavam prontos dentro do prazo e do orçamento, e, além disso, quase sempre apresentavam problemas.
Custo das mudanças
Uma das consequências de tentarmos igualar metodologias de desenvolvimento de software a metodologias de engenharia tradicionais (como construção civil) é a visão de que o custo de modificar o programa aumenta exponencialmente ao longo do tempo, conforme gráfico abaixo:
Acolhendo as mudanças
A partir da metade dos anos 90, começaram a surgir discussões sobre se a forma faseada acima (cascata), como ocorre na construção civil, era realmente o melhor modelo para o desenvolvimento de software. As metodologias ágeis de desenvolvimento surgiram exatamente para permitir maior flexibilidade no processo de desenvolvimento de sistemas e minimizar o custo de mudanças ao longo dos projetos, fazendo com que o gráfico acima fique mais próximo do apresentado abaixo:
Mas, afinal de contas, como isso é possível? Como podemos adicionar mudanças ao software sem implicar em altos custos para o mesmo? A resposta a essa pergunta é o título do artigo: aplicando boas práticas de engenharia!
Muitos times adotam Scrum, mas deixam de lado as boas práticas de engenharia que são necessárias para que seja possível acolher as mudanças ao longo do projeto como pregam as metodologias ágeis. Esse tipo de problema já foi discutido por Martin Fowler e James Shore. E meu objetivo com este artigo é despertar esses times para o estudo de práticas de engenharia como refatoração, boas práticas de design de domínio e TDD.
Se você usa Scrum, mas não utiliza essas práticas, sugiro que comece com urgência a estudar esses assuntos.
Um bom caminho para iniciar são os 3 livros abaixo:
De 0 a 10, o quanto você recomendaria este artigo para um amigo?