Vitor Pamplona

Innovation on Vision: Imaging , Enhancement and Simulation

Analogias Falham

 Esta discussão com o Guilherme me fez levantar uma série de questões sobre o uso de analogias na Engenharia de Software. Apesar de concordar com a maioria dos autores ágeis que pregam o uso de analogias como forma de explicar e salientar características de um problema, o uso de analogias normalmente não funciona comigo. Dando alguns exemplos, o Guilherme comentou sobre duas analogias para o desenvolvimento de software: da construção de prédios e a da jardinagem.

A da construção de prédios, segundo ele mesmo, diz que: " você deve ter engenheiros [arquitetos na verdade] que fazem um grande projeto especificando exatamente como tudo vai ser (RUP), depois os pedreiros constroem e no final está tudo pronto e funcionando conforme a especificação ". Outras versões desta mesma analogia dizem que a qualidade do teu prédio é diretamente proporcional a qualidade dos materiais (Bibliotecas, RADs, etc) e mão de obra (Programadores) que você comprou para fazê-lo, que toda a obra começa com um engenheiro civil (Analista) projetando o estágio final, a meta do projeto (goal), que as plantas   (especificações) não só dizem o que fazer, mas também informam um primeiro chute para o custo total do projeto (análise de requisitos), entre outras coisas.  

A analogia da Jardinagem, também citada pelo Guilherme diz que: " [Desenvolvimento de software] é muito mais ' orgânico ' do que ' concreto '. Inicialmente você planeja muitas coisas para o seu jardim de acordo com as condições atuais de terra, clima, etc. Você precisa plantar as sementes, regar todo dia e cuidar para que as pragas não acabem com tudo. Você pode com o passar do tempo mover suas plantas de lugar para tirar vantagem de fatores como exposição ao sol, sombra ou até mesmo para fazer a rotatividade da terra. Você poda suas plantas constantemente e move alguns tipos de flores de um lugar para o outro para que o jardim fique melhor esteticamente. Se alguma planta cresce demais, pode ser que o espaço que você planejou para ela tenha ficado pequeno, e então é necessário movê-la de lugar. "

No mesmo post, eu citei a analogia a construção de casas de classe média, que é mais maleável, diferente daquela de construção de prédios, mas ainda segue um certo conjunto de regras. Nesta analogia, a planta (especificação), que nada mais é do que a meta a longo prazo (goal), da casa pode sofre alterações freqüentes, de acordo com as novas necessidades do cliente ou problemas detectados pelos engenheiros / pedreiros (bugs de especificação). A construção de uma casa pode variar na sua forma (arquitetura) e na ordem dos processos (prioridades) dependendo do cliente: pode-se construir o teto (segurança) antes das paredes (features), por exemplo. É comum existirem mutirões para terminar uma determinada parte da casa (feature), ou mutirões para destruir algo já feito para arrumar algum erro do engenheiro ou dos pedreiros (refactoring). As prioridades decidem o que será feito primeiro. A casa pode ser entregue aos poucos (small releases), inclusive com o cliente morando nela, do mesmo jeito que o software.  

Outra analogia que o Antonio Carlos postou lá no blog do Guilherme é a do Chefe de cozinha: " Pense que o desenvolvimento é como criar uma receita e que a produção é como seguir (executar) esta receita. Estas são atividades muito diferentes, e elas deveriam ser resolvidas com abordagens diferentes. Desenvolver uma receita é um processo de aprendizado envolvendo tentativas e erros. Você não espera que a primeira tentativa de um Chef, de nível internacional, ao fazer um novo prato seja sua última tentativa. Na verdade, toda a idéia de desenvolver uma receita tem o objetivo de testar muitas variações e descobrir o melhor prato. Uma vez que o Chef tenha descoberto a receita, para preparar o prato, basta seguir a receita. "

Estas quatro analogias de exemplo são só algumas de várias existentes por aí. Percebam que cada uma delas funciona no contexto em que o autor as introduziu, retirando-as do contexto passam a não fazer mais sentido. A analogia de prédios funciona naquele contexto do antigo e gigantesco RUP. A de jardinagem funciona num ambiente muito dinâmico, o mesmo lugar onde eu usaria drools, por exemplo. A de construção de casas funciona em contextos onde a arquitetura (fundação de uma casa) dificilmente é reconstruída ou adaptada. A do Chefe de cozinha faz sentido quando suas atividades demandam um certo aprendizado da equipe e não em locais onde a equipe é experiente o suficiente para saber instintivamente o que, como e quando implementar as features.    

Além do contexto, as analogias falham se exploradas mais detalhadamente. Exemplos: A analogia do prédio falha quando pensamos que a decoração (user interfaces) só pode ser desenvolvida depois do prédio pronto. A da Jardinagem falha quando pensamos que que o software não é uma planta, que cresce sozinha. A meu ver ainda a analogia da Jardinagem não é uma analogia ao desenvolvimento de software, é uma analogia ao papel do coach ou do líder da equipe. A analogia da casa de classe média falha quando pensamos em qualidade, visto que o processo de construção deste tipo de casa dificilmente será tranqüilo para o cliente. A do chefe de cozinha falha se pensarmos que, na prática, o chefe de cozinha não cria receitas (desenvolvimento de software) todos os dias. O desenvolvimento de software é um processo incremental dificilmente você apaga tudo e começa do zero como com os chefes de cozinha e o processo de tentativa e erro, tecnicamente, não é tolerável.

Cada vez que eu vejo uma analogia eu me remeto a analisar detalhes do processo análogo que me façam descobrir pontos em que o processo original está incorreto. Eu tento usar a analogia como forma de identificar problemas e argumentação. No entanto, este uso tem um risco muito grande, pois há pontos em que a analogia falha e o processo original está errado e há outros pontos de falha que o processo original semelhante está correto. Esta incoerência entre analogia e processo original é inevitável, todas elas possuem pontos de falha. Tome cuidado ao apresentá-las e ao interpretá-las. Lembre-se que as diferenças geográficas podem influenciar na interpretação da analogia e nunca transforme uma analogia em regra. Analogias existem para explicar processos, não servem como guidelines.

Posted in Jul 22, 2008 by Vitor Pamplona - Edit - History

Showing Comments

Fala Vitor.

Eu tb acho que as analogias podem dar margem à interpretações, porém, elas são uma forma muito boa de explicar coisas. As analogias fazem com que alguém transfira parte do conhecimento que têm sobre alguma coisa para outra, diminuindo o " gap " do aprendizado: http://pt.wikipedia.org/wiki/Analogia

Fora isso, tenho duas considerações importantíssimas:

No primeiro parágrafo vc disse que RUP é waterfall: " você deve ter engenheiros [arquitetos na verdade] que fazem um grande projeto especificando exatamente como tudo vai ser (RUP) ". O RUP é iterativo (http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process), ou seja, não se especifica tudo antes - > " The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003 ".

Além disso, depois vc disse que " A analogia de prédios funciona naquele contexto do antigo e gigantesco RUP ". Assim como não é waterfall, o RUP não é gigantesco se vc não quiser - vc pode adaptá-lo para suas necessidades usando apenas um subset do que é oferecido - > " RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. "

[] s, gc

- - Guilherme Chapiewski

- - Posted in Jul 23, 2008 by 201.7.186.73

Quando eu falei de " RUP antigo " me referia aquela primeira versão, imatura e ainda baseada no modelo em cascata, na qual a recomendação era utilizar todos os documentos e não selecioná-los e adaptá-los a sua estrutura.

[] s

- - Vitor Pamplona

- - Posted in Jul 23, 2008 by 143.54.13.191



- - Janice Borges

- - Posted in Mar 24, 2009 by 201.18.95.50

Add New Comment

Your Name:


Write the code showed above on the text below.