Esta metáfora da construção civil comparando com software é usada a muito tempo e acho que hoje todo mundo já suspeita que a relação não é muito clara.
Uma forma de aproveitar a metáfora na linha que o Rodrigo trabalhou, levando a construção do software a ser comparada com construção apenas do projeto é uma forma de melhorar esta comparação, mas ainda acredito que a questão ainda fica mal posicionada, pois o resultado tangível de um projeto é apenas um papel, e o software bem desenvolvido é uma aplicação funcional que altera o nosso mundo ao redor.
Eu diria na realidade que a construção civil como conhecemos hoje é uma péssima referência para comparação, pois a mesma está em crise justamente por tentar se basear num ideal de fixar antecipadamente num projeto algo que não se pode prever sem custos absurdos, como a qualidade do terreno ou a definição final de como o espaço criado vai ser utilizado, além de provocar quantidades gigantes de retrabalho para poder mudar depois de pronto uma especificação "escrita numa pedra".
O sucesso do uso dos conceitos lean baseado em fluxo em vez do modelo de transformação em várias atividades humanas está provocando uma revolução também na construção civil. Estes conceitos caminharam da produção enxuta inicialmente aplicada no Japão para construir carros de baixo custo e alta qualidade e progrediram para vários segmentos, e em especial o desenvolvimento de software.
Esta evolução não era esperada nem mesmo pela Toyota, pois a mesma até a pouco ainda usava o modelo de transformação para sua área de desenvolvimento de produto.
A comunidade Ágil, que estava experimentando as técnicas XP, SCRUM e uma série de outras menos conhecidas começaram a reparar que as técnicas que estavam sendo criadas tinham relação muito forte com os conceitos lean, permitindo o casamento, cruzamento e transformação, fortalecendo o paradigma de fluxo de valor no software.
Agora o desenvolvimento de software passou a ser referência, e podemos encontrar até na construção civil uma revolução acontecendo: o Lean Construction.
Então acho que podemos dizer com orgulho que, na realidade, a construção civil é que tem que usar o desenvolvimento de software ágil como metáfora. A construção civil precisa tanto como o software:
- aceitar mudança de especificação do cliente, mesmo que cinco pavimentos já tenham sido construidos;
- focar no aprendizado durante o processo, nem que seja por protótipos;
- não perder tempo demais com projetos superdetalhados, que logo serão invalidados na prática da construção;
- reduzir a quantidade absurda de retrabalho, usando o valor para o cliente como principal métrica do progresso;
- adiar o máximo possível decisões de custo de retrabalho alto;
- implantar projetos de escopo variável.
2 comentários:
Olá Fábio!
Obrigado pelo comentário. Li seu post e concordo contigo. No meu post eu foquei nas semelhanças das fases de projeto das duas engenharias e não ataquei as diferenças da fase de construção.
A fase de construção em software pode ser automatizada e executada continuamente durante o projeto, algo que não pode ser feito em engenharia civil. Na engenharia civil é necessário um longo tempo de execução, o que no software demora poucos minutos de um algoritmo, na engenharia civil leva anos e deve ser feito por pessoas. Isso gera um enorme potencial para aplicação de métodos para maximização de valor. Como você bem disse, o Lean pode servir de ótima fonte de inspiração para a construção na engenharia civil.
Acredito que veremos nos próximos anos a convergência de métodos a medida que passamos a entender melhor os conceitos e traçar os paralelos corretos, e então cada uma das engenharias passará a se valer dos erros e acertos da outra.
Forte abraço, :)
Rodrigo Machado
Muito bom! Porém acredito que você discordou de forma muito branda, pois existem outros fatos de comparação citados na matéria do Rodrigo que não são bem reais. Como o mesmo citou no comentário da sua matéria: "No meu post eu foquei nas semelhanças das fases de projeto das duas engenharias" No meu ponto de vista é justamente aí que está o erro!
Podemos facilmente comparar as fases, equiparando os "tempos" de projeto. Contudo, não acontece na engenharia civil de as propriedades de um terreno mudarem após já ter sido construídos dois andares de um edifício, necessitando que a fundação ou a resistência dos pilares precisem ser alterados! Em software isso é natural! Quem não precisou refatorar um código porque uma correção de segurança de uma biblioteca alterou suas chamadas de execução? Ou até mesmo teve que adaptar um sistema a uma nova versão de um SO. Na minha opinião, isso sim é "mudar o terreno" e isso não acontece no tempo do projeto!
Postar um comentário