ENGENHARIA DE SOFTWARE: UMA IDEIA CUJO TEMPO VEIO E SE FOI?

Tom DeMarco Acabamos de passar o 40 aniversrio da Conferncia da Engenharia de Software da OTAN em Garmisch, Alemanha, onde a disciplina de engenharia de software foi proposta pela primeira vez. Uma parcela do meu trabalho inicial se tornou parte daquela nova disciplina, ento isso parece um momento oportuno para reavaliao. Meu livro de mtricas, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982) (Controlando Projetos de Software: Gerenciamento, Mensurao e Estimao) teve um papel na forma que muitos aprendizes de engenharia de software quantificavam seu trabalho e planejavam seus projetos. Agora me pergunto se o conselho do livro estava correto na poca, se ainda relevante e eu ainda acredito que mtricas so essenciais para qualquer esforo de desenvolvimento de software? Minhas respostas so no, no e no. O livro, para mim, uma combinao curiosa de coisas verdadeiras em geral escritas em cada pgina, mas combinadas em uma mensagem global que est errada. como se o jovem autor do livro nunca tivesse encontrado uma mtrica que no gostasse. O recado principal parece ser mtricas so boas, mais seria melhor, e muito mais seria melhor ainda. Hoje em dia todos ns entendemos que mtricas de software custam dinheiro e tempo e precisam ser utilizadas com moderao cuidadosa. Alm disso, desenvolvimento de software inerentemente diferente de uma cincia natural, como fsica, e suas mtricas so muito menos precisas em capturar as coisas que elas propem a descrever. Elas precisam ser levadas com uma pitada de sal em vez de depositarmos nossa confiana sem reservas. Mania de controle A citao mais usada do livro sua primeira fr ase: Voc no pode controlar aquilo que no pode mesurar. Essa linha contm uma verdade real, mas eu tenho me tornado cada vez mais desconfortvel com seu uso. implcito na citao (e de fato no ttulo do livro) que controle um aspecto importante, talvez o mais importante, de qualquer projeto de software. Mas no . Muitos projetos tm procedido sem muito controle, mas foram capazes de produzir produtos maravilhosos, como GoogleEarth ou Wikipdia. Para entender o verdadeiro papel de controle, voc precisa distinguir entre dois tipos de projetos drasticamente diferentes: Projeto A vai custar cerca de um milho de dlares e vai produzir um valor de cerca de $1.1 milho. Projeto B vai custar cerca de um milho de dlares e produzir um valor de mais de $50 milhes.

 visivelmente aparente que o controle realmente importante para Projeto A, mas no tem quase nenhuma importncia para Projeto B. Isso nos leva estranha concluso de que controle rgido algo que tem muita importncia em projetos relativamente sem utilidade e muito menos importante em projetos de grande utilidade. Isso sugere que por mais que voc foque no controle, mais provvel que voc esteja trabalhando num projeto que est envolvido em algo de um valor relativamente pequeno. Na minha cabea, a questo muito mais importante do que como controlar um projeto de software , por que estamos trabalhando em tantos projetos que entrega to pouco valor? Eu estou realmente dizendo que no tem problema nenhum realizar projetos sem controle ou com relativamente pouco controle? Quase. Eu estou sugerindo que, em primeira mo ns precisamos selecionar projetos onde controle rgido no ter tanta importncia. Ento, ns precisamos reduzir nossa expectativa do nvel exato de controle que seremos capazes de exercer, independente da nossa vontade de controlar. Uma analogia perturbadora Imagine que voc est tentando controlar a criao de um adolescente. A idia de controlar sua prole deve te fazer sentir um pouco tonto. Mas mesmo assim, as apostas para controle no podiam ser mais altas. Se voc fracassar na sua tarefa, o fracasso total, vidas podem ser arruinadas. Ento, absolutamente essencial que voc no perca seu controle totalmente. Voc como um jogador de esgrima que est aprendendo a segurar sua espada como se fosse um pssaro: aperta demais e o pssaro ferido; afrouxa demais e ele sai voando. Agora aplica voc no pode controlar aquilo que no pode mesurar ao adolescente. A maioria das coisas que realmente importa honra, dignidade, disciplina, personalidade, calma sob presso, valores, tica, pro atividade, lealdade, humor, bondade no so mesurveis. Voc precisa direcionar seu filho da melhor maneira possvel sem muito feedback mtrico. difcil, mas ser pai difcil. Voc recebe um pouco de mensurao em forma de notas escolares, e voc agradece por isso. Mas voc tambm sabe que a nota do seu filho em matemtica um melhor indicador do que sua nota em espanhol, porque compreenso matemtica mais fcil de mesurar. E s ua nota em comportamento provavelmente diz mais sobre o professor do que seu filho. Ento, como que voc gerencia um projeto sem ter controle dele? Bem, voc gerencia as pessoas e controla o tempo e o dinheiro. Voc diz para seu lder de equipe, por exemplo, eu tenho um prazo final em mente, e eu nem vou compartilh-lo com voc. Quando eu chegar num determinado dia e disser para voc que o projeto vai terminar em uma semana, voc tem que estar pronto para empacotar e entregar o que voc tem como produto final. Seu trabalho tocar o projeto de uma forma incremental, juntando peas ao principal na ordem do seu valor relativo, fazer integrao e documentao e testar aceitao incrementalmente durante o trabalho.

At agora eu tinha falado principalmente sobre o componente mtrico da engenharia de software. E o restante? Eu estou gradualmente chegando concluso que engenharia de software uma idia cujo tempo j passou. Eu ainda acredito que ele faz perfeito bom senso para o engenheiro de software. Mas isso no exatamente o que engenharia de software veio a significar. O termo define um conjunto especfico de disciplinas incluindo processo definido, inspees e walkthroughs, engenharia de requerimentos, matrizes de rastreamento, mtricas, controle de qualidade rgido, planejamento e acompanhamento rigoroso, codificando e documentando padres. Todos esses miram para uniformidade de prtica e previsibilidade. Uniformidade e previsibilidade ainda so desejveis, mas nunca foram as coisas mais importantes. Durante os ltimos 40 anos, por exemplo, ns nos torturamos por causa de nossa incapacidade para terminar um projeto de software no prazo e dentro do oramento. Mas como eu sugeri antes, isso nunca deveria ter sido o objetivo maior. O objetivo mais importante transformao, criando um software que muda o mundo ou que transforma a companhia ou a forma como ela faz negcios. Ns fomos razoavelmente bem sucedidos no quesito transformao, frequentemente enquanto trabalhando fora da nossa zona de controle. O desenvolvimento de software e sempre ser de alguma forma experimental. A construo do software de fato no necessariamente experimental, mas a sua concepo . Nosso foco sempre deveria ter estado ali. Tom DeMarco, um diretor do Atlantic Systems Guild. Contate ele nesse endereo: tdemarco@systemsguild.com