Saudações a todos!!!
O objetivo deste artigo é demonstrar que algumas práticas de engenharia (como um bom design de domínio, refactoring e TDD) 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 era 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 co-autor 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 caiam. 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 isto é possível? Como podemos adicionar mudanças ao software sem implicar em altos custos para o mesmo? A reposta a esta 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. Este tipo de problema já foi discutido por Martin Fowler e James Shore . E meu objetivo com este post é despertar estes 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 estas práticas, sugiro que comece com urgência a estudar estes assuntos.
Um bom caminho para iniciar são os 3 livros abaixo:
Fonte: Blog Ricardo Fernandes Luiz
2 Comentários
A curva do impacto financeiro na mudança não segue a linha apresentada (tendendo a não subir).
O custo deve ser encarado como custo do projeto e não apenas como custo de escrever linhas de código.
Se já estamos em uma fase de testes, provavelmente os manuais e treinamentos para as pessoas já foram realizados, processos, etapas já foram redesenhados. Uma mudança (por bug ou arquitetura, mesmo que arquitetura do processo) impacta altamente nesta fase, além que o prazo para a entrega foi modificado.
Não podemos encarar o scrum apenas como uma entrega semanal/quinzenal, ele é apenas uma ferramenta para garantir a entrega de um projeto em um determinado prazo, com um determinado escopo e no custo previsto.
Ponte ou Software, o processo é o mesmo.
Abraços a todos.
Olá Fernando!
Estou falando de desenvolvimento não feito no modelo waterfall (ou cascata) e sim no modelo agile utilizando orientação à objetos e com práticas de engenharia como DDD, TDD, e técnicas de clean code.
Neste caso o impacto de uma mudança (estou falando de uma mudança, não de um módulo novo feito) será como o gráfico mais linear, porque todos os módulos são cobertos por testes (técnica conhecida como Test Driven Development).
O que estou falando é defendido pelos papas da engenharia de software moderna, como Kent Back (Em Programação extrema explicada, de onde foi extraído o gráfico), Martin Fowler, Bob Martin, entre outros…
Se você não trabalha com orienteção à objetos, sem um bom modelo de domínio, não tem testes automatizados, o custo realmente será exponencial, como o da construção de pontes.