Se7e Pecados 

Jul/11
27

Fazer software é uma arte, mas ao contrário da pintura e da escultura é um tipo de arte que se faz em equipa.  Algo mais como  um concerto  e menos como um solo.  Fazer software sozinho é possivel, mas lento e chato.

No mundo profissional software é feito em equipa. A equipe de desenvolvimento não são apenas os programadores. São todos aqueles que participam de alguma forma no desenvolvimento. Desde do arquiteto até o testador, passando pelo programador,  pelo gerente e até pelo representante do cliente.

O problema é que nem sempre a equipe é tratada com respeito. A principal razão para isso é que a equipa não exige respeito.  Às vezes por falta de conhecimento do seu valor ou do seu papel no grande esquema das coisas, às vezes por modéstia e às vezes por que não estão nem ai. O problema maior acontece quando ela não exige respeito porque sua qualidade é pobre.

A qualidade da equipe ¬†de desenvolvimento √© um fator a ser considerado independentemente da plataforma de desenvolvimento escolhida. Uma equipe bem treinada, afiada, com acesso a uma base de c√≥digo √ļtil que ela entenda e domine, pode ser a diferen√ßa entre o sucesso e o fracasso dos projetos. ¬†Sim, projetos , plural.

A equipe de desenvolvimento n√£o pode ter muitos membros, pois √© sabido que apenas aumentando o n√ļmero de elementos em uma equipe os problemas de comunica√ß√£o crescem em rela√ß√£o ao quadrado do numero de pessoas na equipa. Isso leva √† confus√£o e √† necessidade de longas ¬†reuni√Ķes constantes para que todos estejam no mesmo n√≠vel. ¬†O tamanho da equipe √©, portanto,¬† fundamental.

Outro fator √© a rotatividade. Se os membros da equipe constantemente s√£o substituidos a qualidade sofre porque mais tempo tem que ser passado ensinando os novos membros como as coisas funcionam. Quanto menos padroniza√ß√£o mais dificil √© essa tarefa. Um outro fator que adv√©m de uma elevada rotatividade √© a dispers√£o de conhecimento. ¬†Digamos que temos 4 membros na equipe que conhecem o negocio e a base de c√≥digo, se sair um por m√™s em 4 meses todo o conhecimento que eles tinham acumulado se perdeu. Os novos integrantes da equipa n√£o ter√£o o mesmo insight sobre o neg√≥cio e ter√£o que ser retreinados. ¬†Al√©m disso n√£o saber√£o quais decis√Ķes tecnicas foram tomadas e porqu√™ foram tomadas levando √† reescrita de novo codigo ou ao abandono do que j√° existe e √† cria√ß√£o de um novo software.

Outro ponto fulcral √© a capacita√ß√£o dessa equipe. A experi√™ncia √© importante, o conhecimento das tecnologias envolvidas √© importante. √Č possivel criar um software com uma pessoa, e √© possivel cri√°-lo com 8 juniors trabalhando 50 horas por semana, mas n√£o √© possivel fazer isso com a mesma qualidade e rapidez que com 4 s√™niors trabalhando 7 horas por dia. ¬†Existe um fator de eficiencia inerente √† capacita√ß√£o tecnica e ¬†√† pr√≥pria experiencia. O s√©nior n√£o vai passar 90% do seu tempo testando ideias , algoritmo ou tecnologias. Ele j√° fez isso antes. Ele ir√° passar 90% do tempo implementando features reais. ¬†Uma equipa eficiente tende a ser pequena e a ter uma raz√£o senior/junir elevada. Claro que, como n√£o poderia deixar de ser, isso est√° longe da realidade. ¬†S√≥ √© preciso ter cuidado quando voc√™ contrata a produ√ß√£o de um software que ela n√£o esteja inteiramente na m√£o de juniors que por defini√ß√£o s√£o menos preparados tecnicamente e com menos viv√™ncia no ramo. ¬†Contudo, o treinamento de pessoas √© importante e a equipa tamb√©m n√£o deve apenas ser formada de s√™niors. ¬†E lembre-se sempre que l√° porque uma pessoa faz programas √† 20 anos n√£o significa que saiba criar aplica√ß√Ķes hoje e muito menos que saiba gerenciar a produ√ß√£o delas.

Al√©m de tudo isto, o mais importante √© que todos aceitem bons valores e rejeitem maus valores e que haja concenso sobre quais valores adotar. A Extreme Programing assenta b√°sicamente sobre valores de onde s√£o estrapoladas pr√°ticas e √© um bom exemplo de porqu√™ valores s√£o mais importantes que experi√™ncia. Experiencia adquire-se. Se aprende e se ensina. Valores, ou se t√™m, ou n√£o se t√™m. √Č demorado e custoso incutir valores em algu√©m. Isso fica al√©m do aprendizado simples e requer uma educa√ß√£o completa, e portanto, cara. Contratar pessoas com os valores certos, √© mais importante para o custo e sucesso do que contratar pessoas com experi√™ncia. A experiencia deles pode simplesmente enganar voc√™.

Muito j√° foi falado sobre os bons valores que devem ser abra√ßados pela equipe, mas conhecer as tenta√ß√Ķes dos maus valores e como as evitar pode ser ainda mais √ļtil. Em outras palavras, mesmo que a equipe n√£o fa√ßa ¬†bem, desde que n√£o fa√ßa mal, j√° √© um passo em frente.

Podemos enumerar sete falhas, sete anti-valores, os sete “pecados” ¬†mais comuns dos membros da equipe de desenvolvimento:

Pressa

Decis√Ķes apressadas levam √† degrada√ß√£o da qualidade do software. Isto √© normalmente originado por um subjuga√ß√£o ao prazo irrealista do projeto que causa um stress e uma press√£o sobre a equipe para entregar o software – de qualquer jeito- at√© ao prazo. O risco disto √© imenso, pois qualquer pequeno erro feito agora causar√° preju√≠zos imensos depois. Claro, que, os causar√° ao cliente e n√£o a software house, ou pior, a software house cobrar√° para resolver esses problemas. ¬†Assim, √© l√≥gico que, do ponto de vista do fluxo de caixa, seja prefer√≠vel entregar cedo e com muitos defeitos ao inv√©s de tarde e sem defeitos. Os clientes s√£o os que¬†sofrem, mas devido √† l√°bia de alguns vendedores, os clientes nem se d√£o conta que est√£o sendo enganados. O charlatanismo ainda √© um problema no mundo da produ√ß√£o de software, como o foi de medicina ha n√£o muito tempo atr√°s.

A pressa viola o comprometimento com um prazo.O prazo tem que ser realista. Isto significa que tem que ser alcan√ßavel mesmo quando existem imprevistos e sem periodo extra¬†de trabalho. A pressa acontece normalmente porque alguem mentiu em informa√ß√Ķes que formaram o prazo ou o prazo foi ajustado artificialmente por alguem sem comprometimento de toda a equipa. O prazo n√£o √© uma promessa, √© um tempo m√°ximo. O software ser√° entregue at√© dia X. Isto significa que pode ser entregue antes. E √© isso que deve acontecer. √Č por isso que o prazo n√£o deve definir o custo.

Apatia

A aus√™ncia ¬†de preocupa√ß√£o em¬† buscar solu√ß√Ķes para problemas que aparecem durante o desenvolvimento, parecendo existir uma esp√©cie de m√° vontade natural em solucionar os problemas, n√£o procurando solu√ß√Ķes que outros j√° utilizam ou mesmo solu√ß√Ķes novas.¬† Neste caso, a tend√™ncia natural √© eliminar o problema fazendo algum tipo de malabarismo – mais conhecido como gambiarra – que permite que o problema simplesmente “desapare√ßa”. Claro que como nada √© m√°gico, essa “solu√ß√£o” acaba trazendo mais problemas no futuro. Devido √† apatia constante, a equipe n√£o v√™ rela√ß√£o entres esses problemas e as gambiarras que fizeram antes, criando mais gambiarras para resolver os problemas que encontraram. Isto gera um novelo de ajustes mal pensados que n√£o resolvem problemas, ao contr√°rio, criam outros problemas, levando a um novelo ainda maior num ciclo viciado pela n√£o-preocupa√ß√£o da equipe.

Vis√£o-curta

A recusa em utilizar solu√ß√Ķes j√° encontradas por outros e largamente utilizadas com sucesso. Estas solu√ß√Ķes podem ser desde boas pr√°ticas de programa√ß√£o at√© ¬†a utiliza√ß√£o de t√©cnicas de gerenciamento, como Scrum ou algo simples, como ter muitas equipes pequenas ao inv√©s de ter uma equipe grande. A velha “n√£o vamos fazer isso agora porque n√£o precisamos” √© o ex libris da vis√£o-curta.

Preguiça

Escolher a “solu√ß√£o mais f√°cil” repetidamente e sem analisar as consequ√™ncias da decis√£o. ¬†Normalmente o “mais f√°cil” significa “o mais r√°pido” ao inv√©s de “o que tem melhor raz√£o custo-benef√≠cio”. Avaliar as solu√ß√Ķes pelo tempo que demoram a ser implementadas √© a prova de que a pessoa √© pregui√ßosa, ela est√° tentando avaliar quanto tempo livre ter√° para ficar fazendo nada, ou inv√©s de estar preocupada com a qualidade do software. A rapidez da implementa√ß√£o depende de muitos fatores e nomeadamente da experi√™ncia de quem vai implementar (um s√™nior provavelmente implementa em muito menos tempo que um j√ļnior) e das ferramentas, bibliotecas e frameworks envolvidos. Se √© algo que j√° est√° quase pronto da plataforma de aplica√ß√£o √© r√°pido, se √© preciso criar, √© lento. Um outro exemplo comum √© escolher implementar uma funcionalidade no software ao inv√©s de na plataforma de aplica√ß√£o, sob a raz√£o de que no software ser√° mais r√°pido. Sempre que a palavra “r√°pido” √© usada est√° em causa a pregui√ßa de algu√©m. A an√°lise e decis√£o entre funcionalidades n√£o se d√° pelo tempo de implementa√ß√£o de cada uma e sim pelo tempo de implementa√ß√£o de todas as funcionalidades do software. Se a funcionalidade X implementada da maneira “A” demora vinte vezes mais que a “B”, mas diminui o tempo de Y e Z por oito vezes, provavelmente ser√° a escolhida.

Avareza

Esta tem v√°rias formas. Resistir ao compatilhamento do c√≥digo com a equipe ou at√© achar que o c√≥digo √© seu e n√£o da empresa onde trabalha √© um sinal claro. Mais s√ļtil √© achar que sabe como o software tem que ser feito √† margem da documenta√ß√£o, do cliente, e pior, dos outros membros da equipe. Por√©m, mais s√ļtil ainda √© escrever e organizar o c√≥digo da forma que acha certa sem pensar no que s√£o as melhores pr√°ticas, ou a pr√°tica comum do resto da equipe. Pouca abstra√ß√£o √© um sinal disto porque a pessoa s√≥ abstrai o que √© necess√°rio para ela e n√£o pensa que uma abstra√ß√£o maior poderia ser √ļtil para outras √°reas do software. Falta de comunica√ß√£o e decis√Ķes baseadas em cren√ßas pessoais s√£o um outro sinal da avareza.

Ignor√Ęncia

√Č a falha em procurar entendimento. Mant√©m-se as pessoas est√ļpidas, comentendo erros a longo prazo que voltar√£o potencializados para atacar e p√īr em risco o software. A ignor√Ęncia¬† tamb√©m se apresenta no n√≠vel gerencial e at√© vindo do cliente. Ao falharem em entender alguma coisa, o gerente ou o cliente n√£o pedem explica√ß√Ķes,¬† mas¬† decidem fazer as coisas de outra forma, levando a retrabalho e a um sobresfor√ßo da equipe. Isto √© comum quando n√£o se entende porque o programador passou dois dias implementando algo que n√£o consta dos requisitos. Em vez de perguntar e tentar entender a raz√£o t√©cnica, o gerente automaticamente decide que a pessoa est√° enrolando. A Ignor√Ęncia apresenta-se tamb√©m pela falta de treinamento da equipe em tecnologias novas e at√© pela falta de abertura de que a equipe procure esse conhecimento. “Faltar um dia para assistir uma confer√™ncia ou conven√ß√£o? Nem pensar!” “Ficar uma semana fazendo um curso de Java ? ‘T√° louco?”

Orgulho

O orgulho vem v√°rias faces. Para a equipe √©¬† a s√≠ndrome de “n√£o-foi-inventado-aqui” em que a equipe quer reescrever tudo o que j√° existe, procurando uma perfei√ß√£o que n√£o pode ser encontrada no que j√° existe pronto mas foi feito por outros. A recusa em utilizar frameworks e bibliotecas de mercado simplesmente porque n√£o foram feitas aqui. Claro que nem todas podem ser usadas e nem sempre existem coisas j√° prontas para o que precisamos, mas a recusa a procurar por elas √© a marca do orgulho. Outra forma de orgulho, mais pessoal, √© a pessoa se vangloriar de alguma experi√™ncia que teve para justificar a decis√£o que tomou sendo mais comum o resalte dos anos de “experi√™ncia”, o famoso “Eu trabalho com isto h√° 30 anos”. Embora seja muito interessante para a biografia do sujeito, isto √© irrelevante ao problema j√° que ter trabalhado com Clipper √† 20 anos n√£o o prepara para utilizar Java hoje em dia. A tecnologia evolui todos os dias, assim como as boas pr√°ticas e os paradigmas, a experi√™ncia long√≠nqua n√£o serve de nada agora. Isto n√£o significa que a pessoa n√£o possa utilizar o que sabe, o que aprendeu, apenas que ela n√£o pode usar isso como trunfo para impor a sua decis√£o.

Os sete pecados s√£o um assunto interessante e se est√° querendo saber mais leia Anti-Patterns ‚Äď Refactoring Software, Architectures and Projects in Crisis (ISBN 0-471-19713-0) em que este t√≥pico foi baseado. ¬†Recomendo.

Criar um software √© um trabalho colaborativo tanto da equipe de desenvolvedores, como da ger√™ncia e, principalmente, do cliente. O cliente precisa saber o que pode dar errado num projeto de software e vigiar para que n√£o aconte√ßa. N√£o faz sentido que a gerencia de um projeto de software seja da software house apenas. √Č como colocar uma venda nos olhos do cliente. Se ele sabe vigiar problemas com todos os outros fornecedores porque n√£o com o o fonecedor de software? Cuidado com os defeitos e a cobran√ßa para resolver defeitos. O cliente entende muito melhor e¬† mostra-se muito mais flex√≠vel quanto mais por dentro ele tiver do andamento do projeto. Seja honesto com o cliente. Aplique o tri√Ęngulo de projeto sem medo. Ele compreende isso, pois ele usa o mesmo tri√Ęngulo quando negocia com os clientes dele, no ramo dele.

Repeite o cliente, respeite a equipe e tudo dar√° certo.

Comente

Artigos