Valorizar Pr√°ticas ou Praticar Valores? 

Oct/09
22

Valorizar pr√°ticas ou praticar valores? A diferen√ßa parece s√ļtil, mas √© a distin√ß√£o essencial nos dias de hoje, porque √© a diferen√ßa entre o que interessa e o que n√£o interessa no ramo¬†do desenvolvimento de software

Pela tradi√ß√£o – tradicionalmente, historicamente – as empresas valorizam pr√°ticas.¬†S√£o criados, aglutinados, conjuntos de pr√°ticas a que chamam “metodologias”.¬†As pr√°ticas s√£o veneradas e chamadas de m√©todos (dai metodo+logia: compila√ß√£o/estudo de m√©todos).¬†Elas s√£o absolutas e essenciais em si mesmas. O conjunto √© a soma das partes, n√£o o produto das partes. Ou seja, se A √© X e B √© Y,¬†ent√£o A+B √© X+Y. Sem truques, sem fatores de correla√ß√£o. Sem sobreposi√ß√£o. Ou seja, irreal. ¬†Disfar√ßadamente o modelo “fordiano” da fabrica√ß√£o em linha de montagem √© trucidado, despeda√ßado e depois alguns peda√ßos remontados no melhor estilo frankeinstein para se criar uma metodologia.¬†Por que h√° incompet√™ncia de quem manda para reconhecer pr√°ticas reais, √ļteis, para a √°rea de software, pr√°ticas de outras √°reas tentam ser encaixadas.

Hoje n√£o se desenvolve software com uma metodologia da √°rea de software, mas sim com¬†conjuntos de pr√°ticas usurpadas de outras √°reas como a mencionada linha de montagem¬†e a engenharia civil. As pessoas simplesmente adoram comparar pr√©dios e software.¬†N√£o h√° sequer compara√ß√£o poss√≠vel. Acho que as pessoas esquecem – ou nunca aprenderam – porque se chama¬†software. Software √© o contr√°rio de Hardware. √Č um conceito t√£o et√©reo e abstrato que ele s√≥ pode¬†ser definido por oposi√ß√£o e n√£o tem um substantivo pr√≥prio (seu de fato).

Depois de tantas tentativas falhadas de h√≠bridos mutantes de bonecos de trapos ambulantes chamados “metodologias de desenvolvimento”¬†algumas coisas foram aprendidas. Lembre-se que este campo tem 50 anos. √Č muito mais novo que o artesanato (mil√™nios), a ind√ļstria (s√©culos) ou a constru√ß√£o civil (desde sempre que o Homem √© Homem).

O que aprendemos?

As pessoas querem software

Elas querem solu√ß√Ķes. Elas n√£o precisam de software. Ent√£o, como o software oferece solu√ß√Ķes, elas¬†passam a desejar software. E √© isso que elas compram, a satisfa√ß√£o de um desejo.¬†Ent√£o, √© a√≠ que est√° o erro … Erro? Quando uma pessoa assiste a um espet√°culo, √© porque precisa ou porque deseja?¬†√Č na realidade uma mistura prom√≠scua dos dois. Dif√≠cil de dizer quando √© um ou outro.¬†Isso √© a primeira indica√ß√£o da raz√£o pela qual as metodologias tradicionais n√£o funcionam. Cada espet√°culo √© √ļnico.¬†Existem t√©cnicas, regras, mec√Ęnicas, mas no fim n√£o existe uma forma √ļnica de produzir um espet√°culo…¬†apenas um conjunto de melhores pr√°ticas.

Ser√° mesmo que um espet√°culo, uma arte, √© um conjunto de pr√°ticas ? Ah! o espet√°culo, a arte n√£o s√£o um conjunto de pr√°ticas. √Č um conjunto de sensa√ß√Ķes que satisfazem o desejo do espectador.¬†A arte, em si, n√£o √© material, tal como o software. Cabe na cabe√ßa de algu√©m que arte seja montada como um pr√©dio?¬†Passa pela cabe√ßa de algu√©m que algo abstrato seja “montado” como algo f√≠sico seria? Bom, infelizmente passa .

Mas o “desenvolvimento” sim pode ter pr√°ticas, melhores pr√°ticas. Ent√£o, como um espet√°culo de arte com metas concretas¬†e pr√°ticas reais de produ√ß√£o, tamb√©m um software (coisa abstrata) pode ser produzido usando pr√°ticas concretas.

Arte é produzida. Prédios são produzidos. Carros são produzidos. Software é produzido. Mas Arte não é fabricada, software não é fabricado. Carros e prédios sim. Esta diferença é tudo.

A Necessidade de Uma Met√°fora

O problema é a necessidade de uma metáfora. Porque desenvolver software precisa ser comparado com desenvolver outra coisa? Este é o problema. A necessidade da metáfora. Porque sem a metáfora, você não consegue usurpar as práticas dessa outra área. Você precisa de uma metáfora, uma comparação com outro algo, para ver como esse algo se faz e usurpar as práticas de volta para o software. Genial? Mas não funciona. Está na própria essência da metáfora ser uma comparação provisória, limitada, um apelo à imaginação: nunca será real e nunca durará para sempre ou aplicável em todos os casos.

Historicamente, sempre que uma met√°fora foi usada, duas coisas foram verdade: primeiro, funciona por acaso, n√£o por m√©rito; segundo, prova que o assunto n√£o est√° entendido em si mesmo. Um exemplo, a medicina. Come√ßou como charlatanismo de venda da banha da cobra, virou “conjunto de pr√°ticas” metaf√≥ricas¬†(do tipo sangrar quando est√° com febre porque a febre √© o sangue fervendo, ou por panos frios, para diminuir a “fervura”), depois veio a¬†renascen√ßa,¬†e a medicina foi reintreptada √† luz do humanismo e da ciencia, e depois virou … bom, continua sendo um conjunto de pr√°ticas, mas agora n√£o metaf√≥ricas, baseadas em¬†experi√™ncias¬†concretas. Ainda n√£o se chegou no n√≠vel dedutivo da f√≠sica ou da qu√≠mica.

Desenvolver software est√°, no dias de hoje, no n√≠vel de sagrar algu√©m… os desenvolvedores e os clientes, claro. Dizem que deveria ser ci√™ncia. Nunca ser√°. √Č baseado em ci√™ncia, como a medicina, com seus aparelhos de tomografia, raios-X¬†e ultrasons… ferramentas… mas n√£o dedu√ß√Ķes dos “porqu√™s”.

Praticando Valores

Por que tudo isto n√£o muda? Porque como estamos na fase de “conjunto de pr√°ticas” √© isso que se procura¬†sem analisar as raz√Ķes e as experi√™ncias. A Renascen√ßa trouxe √† medicina a luz que faltava: raciocinar e colocar o ser humano¬†na frente. Ou seja, a Renascen√ßa trouxe valores para as pr√°ticas. As boas, as m√°s, as em estudo, etc… abandonam-se as m√°s¬†e ficam as boas: sele√ß√£o natural.

O que precisamos ent√£o √© praticar valores. Salvar vidas √© um valor, existem v√°rias receitas como se faz, mas o que se ensina¬†e pratica √© algo maior, mais gen√©rico, mais…. humano. Mas quais valores? √Ä partida √© dif√≠cil de dizer¬†precisamos exemplos, precisamos experi√™ncias, casos reais.

Felizmente sempre tem alguém correndo na frente do paradigma, procurando o próximo. Estes exploradores descobriram coisas interessantes que podem ser compiladas em certos valores. E desses valores, avaliar as melhores práticas que atendem a eles.

Da mesma forma que o Juramento de Hipócrates antecede a medicina moderna, também a maioria dos valores necessários ao desenvolvimento de software antecede o próprio conceito de software. O juramento existe porque uma propriedade muito básica de toda a medicina existe Рindependentemente de como definirmos medicina e que práticas ela tem: toda a medicina começa sendo uma relação de confiança entre duas pessoas: o paciente e o médico. O cliente e profissional.

Confian√ßa. ¬†Este √© o valor prim√°rio da medicina. O paciente confia no m√©dico. O juramento √© exatamente a “certeza” que o m√©dico¬†honra essa confian√ßa e se compromete a n√£o viol√°-la. Comprometimento. Outro valor. Esta rela√ß√£o de valores √© t√£o forte que ela √© base de lei em muitos pa√≠ses e culturas.¬†Isto significa que ela existe no n√≠vel mais elevado poss√≠vel: o n√≠vel humano.

A mesma coisa √© necess√°ria em desenvolvimento de software. Mas desenvolver software √© uma atividade conjunta. Este fato simples – precisamos de uma equipa de pessoas –¬†traduz-se na necessidade de valores que sejam aplic√°veis entre os membros da equipa e entre eles e o interessado.

Atualmente existem algumas vertentes de desenvolvimento que tentam produzir software praticando valores.

Estas vertentes Рgenericamente chamadas ágeis Рconcordam que valores precisam ser praticados. Como tal eles precisam ser identificados. Nem sempre os mesmos são identificados, então vou pegar alguns como exemplo:

Comprometimento Рnão violar a confiança dos outros ou os compromissos assumidos. Este é essencial a qualquer atividade humana, comercial ou não.

Foco Рfaça o que se comprometeu com todo o esmero possível. Não inclua falhas ou pontos fracos, não se distraia.

Abertura Рmostre o que fez, a todos. Não esconda nada. Não utilize ou forme segredos. Peça ajuda. Não tenha medo de pedir e de sugerir.

Respeito Р dialogue com os outros de igual para igual como seres humanos e não numa hierarquia artificial. Não menospreze e não subestime ninguém. Experiência se aprende, mas genialidade se utiliza.

Coragem – √Č necess√°rio ter coragem para se comprometer , agir, demonstrar e esperar respeito. √Č necess√°ria coragem para dar pedir ajuda e assumir erros. Coisas v√£o dar errado,¬†e voc√™ ser√° o respons√°vel. Aceite isso mesmo antes de acontecer. Aceite isso para que n√£o aconte√ßa. Tenha a coragem de impedir que aconte√ßa.

As metodologias ágeis continuam sendo conjuntos de práticas, mas agora, práticas devotadas a praticar valores. As práticas não mais são suficientes em si mesmas. Elas precisam do aval, da inspiração, de um ou mais valores.

São os valores que ditaram o que desenvolver software significa. Não um conjunto falho de metáforas. Deste valores podemos distinguir entre práticas boas e más, e descartar as más, da mesma forma que hoje a sangria  é uma aberração da história da medicina.

3 comentários para “Valorizar Pr√°ticas ou Praticar Valores?”

  1. Sérgio, excelente sua fundamentação!
    Precisamos sim, fazer com que precisem-se de softwares…
    Sua permiss√£o para coletar algumas id√©ias e aplic√°-las numa apresenta√ß√£o que farei pr√≥xima semana…

    Parabéns,

    Grato

    Gilson Costa

  2. Você pode usar o conteudo do site sempre que mencione o autor e atribua o devido crédito.

    Me mande o material da sua apresenta√ß√£o depois, fiquei curioso… ūüôā

  3. Taborda,

    Parabens pelo post: muito suscinto, lenvado-se em conta o conte√ļdo que aborda.
    Fiquei surpreso com a sua comparação de Desenvolvimento de Software com a Medicina. Saquei o ponto e percebi que você o fez com muita propriedade.

Comente

Artigos