Processos e Metodologias não vão te Ajudar
Depois de tanto tempo falando de metodologias, processos, procedimentos, existe uma coisa que já deveria ser óbvia mas que a maioria das empresas ignora: metodologias nunca vão substituir bons profissionais.
Se eu disser isso a qualquer um, todos vão dizer: “mas isso é óbvio”. E minha vontade é retrucar: “então porque diabos você está tentando implantar essa metodologia?”
Antes de mais nada, vamos a algumas definições:
- Metodologia: um sistema de métodos usados em uma área particular de estudo ou atividade.
- Processos: uma série de ações ou passos tomados para atingir um determinado objetivo.
- Procedimento: uma maneira estabelecida ou oficial de se fazer alguma coisa.
Notem que em desenvolvimento de software sempre falamos em processos ou metodologias, nunca em procedimentos. Isso porque não existe uma maneira estabelecida ou oficial de se fazer software. O problema é que a maioria das pessoas confunde processos e metodologias com procedimentos e tenta aplicá-los como se fosse a maneira “oficial” de fazer software. E não são. Por isso mesmo disputas do tipo Ágil vs PMI, por exemplo, não faz sentido. O PMI chama seu conjunto de processos de PMBOK, onde BOK significa Body of Knowledge, ou “Corpo de Conhecimento” justamente porque não é um procedimento, é apenas um conjunto de conhecimento que pode ou não ser útil dependendo do seu setor de atividade. Ágil não é diferente disso: um conjunto de metodologias e técnicas que pode ou não ser útil na sua empresa. Nenhuma delas e de outras são procedimentos. Entenda isso primeiro.
Entendendo isso vem o segundo erro: as pessoas não-praticamentes de desenvolvimento de software identificam que o software sendo gerado é de baixa qualidade. Os indicadores são óbvios: reclamações de clientes, reclamações internas, percepção de demora excessiva para se concluir qualquer trabalho de software e assim por diante. Vendo isso, a primeira conclusão que chegam é: “faltam procedimentos”. E começa a procura pelo elo perdido. Encontram vários processos e metodologias e tentam institucionalizá-las. Por um pequeno período parece que o resultado é o esperado, mas não demora muito para ver que as coisas não mudaram tanto assim e então culpam as metodologias por “não funcionarem”.
Desenvolvimento de Software é uma atividade de “prática” – aliás, cuidado, “praticar” e “ser prático” não são a mesma coisa. E aí cabe mais uma definição:
- Prática: 1. a aplicação ou uso real de uma idéia, crença, ou método em oposição a teorias sobre sua aplicação ou uso. 2. exercício repetitivo em ou performar em uma atividade ou capacidade de forma a adquirir ou manter proficiência nisso. (Leia definição mais apurada na Wikipedia).
Repitam comigo: se você não pratica software, você não entende software. Da mesma forma que não adianta dizer que você era bom de futebol 10 anos atrás, mas não pratica mais mas mesmo assim quer acreditar que continua bom. Não, se você não pratica há 10 anos, é ruim há 10 anos, não há o que discutir. E em software, não praticar continuamente, diariamente, deliberadamente, há 5 anos, é o mesmo que um engenheiro civil dizer que não pratica engenharia há 50 anos. 5 anos em idade de software é uma eternidade.
E se você não pratica software, não tem nada a dizer a respeito, por definição. Então vai a dica: processos e metodologias não vão ajudá-lo, justamente porque não são procedimentos. Se software tivesse procedimento, não seria uma prática. Basta seguir mecanicamente a série de passos e no final se teria software de qualidade. Mais do que isso, se fosse procedimento, já seria possível ter software que gera software sozinho, sem nenhuma ajuda humana. Mas isso não existe, e nem vai existir.
Se um restaurante tem comida ruim, processos não vão ajudá-lo, trocar de cozinheiro sim. Se sua orquestra toca mau, não é processo que vai ajudá-la, trocar os músicos sim. Se seu time de futebol joga mal, não é processo que vai ajudá-lo, trocar os jogadores sim. Trocar talvez seja drástico, antes disso eu diria que “praticar”, “treinar”, certamente vai ajudar. Mas aí é que está: se seu jogador de futebol acredita que só precisa jogar depois que bate o cartão de entrada, e pode parar quando bate o cartão de saída, ele não é um bom jogador. Então forçá-los a treinar não vai ajudar e por consequência, processos e metodologias definitivamente não vão ajudá-lo.
Com um bom programador é a mesma coisa. Você não precisa obrigá-lo a colocar seu código num repositório versionado: ele mesmo vai sentir falta disso e fazer algo a respeito. Você não precisa obrigá-lo a testar seu código, ele mesmo vai sentir falta disso e fazer algo a respeito. Você não precisa obrigá-lo a refatorar seu código, ele mesmo vai sentir que está ruim e vai fazer algo a respeito. Um bom profissional de prática não precisa que outros lhes digam o que fazer: ele sabe o que constitui um bom trabalho e irá performá-lo de acordo ou irá procurar o que lhe falta e treinar até se tornar proficiente nisso.
Um bom profissional de prática tem como realidade que ele tem que ser hoje melhor do que era ontem e continuar nesse ritmo todos os dias. Um profissional de procedimento sabe que seu trabalho de hoje é igual ao seu trabalho de ontem. Essa é a diferença: se sua empresa fabrica parafusos, ela segue procedimentos. Hoje existem pessoas montando esses parafusos, seguindo procedimentos, amanhã você provavelmente os substituirá por máquinas que farão o mesmo trabalho melhor e mais rápido. É o destino de todo profissional de procedimento.
Se sua empresa é da área de gastronomia, música, esporte, literatura, arte, software, etc você quer profissionais de prática. Caso não tenha, lembre-se: processos e metodologias não são procedimentos. Processos e metodologias não podem ser instalados como procedimentos. Processos e metodologias nunca vão transformar pessoas com mentalidade de procedimento em profissionais de prática. E sem profissionais de prática, seu resultado sempre será ruim.
Nós desenvolvemos software faz mais de 70 anos. Se a solução fosse tão simples assim, não acham que todo mundo já teria feito dessa forma décadas atrás com resultados continuamente, por décadas, de excelência? Não seja ingênuo achando que você encontrou o “elo perdido”: isso não existe.
A única coisa que podemos fazer, sempre, é tentar amanhã ser melhor do que hoje. Mas isso não se faz com reuniões, comitês, procedimentos, receitas mágicas, gurus ou palestras. Se faz com prática. Quer ser melhor em software? Pratique software. Agora, você tem uma boa equipe, bons profissionais que realmente se importam com a prática? Agora sim, refinar os processos e aplicar boas técnicas e táticas vai melhorar ainda mais. Mas a ordem é esta: bons profissionais, depois boas metodologias. Repetindo: boas metodologias não criam bons profissionais, mas bons profissionais com certeza saberão tirar vantagem de boas metodologias.
domingo, 3 de abril de 2011 -
15:21
|
Fabio Akita é um conhecido blogueiro e evangelista da comunidade Ruby on Rails e Agile. Atualmente é Gerente de Projetos pela Gonow Tecnologia. Foi Gerente de Projetos na Locaweb, onde também fez parceria na concepção da conferência anual Rails Summit (rebatizada de "RubyConf Brasil"). Já trabalhou como Brazil Rails Practice Manager para a consultoria americana Surgeworks LLC. Por mais de 5 anos foi consultor de integração e desenvolvimento no mundo SAP. Tem mais de 15 anos de experiência nas áreas de desenvolvimento de software e gestão de projetos, dá palestras em faculdades e conferências de tecnologia e gestão
Muito bom o artigo.
Muitas pessoas ainda se espelham em empresas que “produzem parafusos” para desenvolver software, quando na verdade deveriam se espelhar em empresas que “projetam parafusos”.
Abraços.
Akita,
Concordo quando você diz que desenvolvimento de software é uma atividade prática e que depende do aperfeiçoamento continuo (práticar/falhar diariamente como Michael Jordan, Pelé e demais atletas de sucesso) das habilidades das pessoas envolvidas no desenvolvimento de software.
Mas, eu diria que processos também podem ajudar já que esses vem muitas vezes da experiência de pessoas que já praticaram e falharam várias vezes como:
* os pais do RUP (Alguém tem alguma coisa a falar dos três amigos?);
* o próprio Humprey (que pouco gente sabe, mas que gerenciou equipes na IBM por mais de 30 anos antes de publicar o livro Managing the Software Process que deu origem ao CMM)
* o próprio Kent Beck (“pai” do XP – Alguém ainda dúvida que Testes Unitários e de Aceitação Automatizados, TDD, Integração Continua e as demais práticas “definidas” pelo Kent Beck na “metodologia” XP não funcionam?)
Grady Booch (um dos “pais” da UML e da Orientação a Objetos) disse: “Pessoas boas com um bom processo sempre superam pessoas boas com um mau processo. Mas nada substitui pessoas boas.” //Eu gosto muito dessa frase dele.
Walker Royce (“pai” do processo cascata): “Pessoas, processo e ferramentas. Essas são as coisas onde as empresas devem investir dinheiro, nessa ordem, se quiserem aumentar as chances de sucesso dos projetos de software.”
Concorda ou Discorda disso Akita?
Eu concordo bastante com o que o Rodrigo Yoshima escreveu em um post chamado “Não jogue dinheiro fora com melhoria de processos”, segue o link:
http://blog.aspercom.com.br/2008/05/27/nao-jogue-dinheiro-fora-com-melhoria-de-processos/
Eu diria que um processo de software pode ser comparada a uma estratégia/esquema tático usado/adaptada pelo Treinador (Couch) para o seu time vencer em um esporte coletivo, como o basquete e o futebol. O que você acha? Será que o Michael Jordan teria sido o jogador que foi se o esquema tático usado pelo Chicago Bulls fosse péssimo?
Se for pegar qualquer mau exemplo de qualquer coisa você consegue fundamentar que algo “não funciona”, assim como não usar metodologias. E aí nunca vai se chegar a um ponto sólido, mas apenas observações pessoais.
Vejamos o ponto principal de sua observação: “Por um pequeno período parece que o resultado é o esperado, mas não demora muito para ver que as coisas não mudaram tanto assim e então culpam as metodologias por “não funcionarem”.
Você consegue desenvolver software de forma ágil e com qualidade sem boas ferramentas por melhor profissional prático que seja? É só comparar!
E boas ferramentas são eternas!? Substituem profissionais “práticos”!? A resposta é óbvia.
Qual a diferença para metodologias? Nenhuma.
O ponto é o equilíbrio sustentado por uma cultura organizacional que sempre pensa e se atualiza estrategicamente em todos os níveis.
Sinceramente, acho que você conseguiu ver os sintomas de uma doença mas não entendeu o funcionamento do organismo da empresa. E receitou errado.
Thiago Ghisi: Primeiro, é Winston e não Walker Royce
Mas detalhes à parte. É claro que concordo. Em nenhum momento eu disse que é para jogar fora metodologias e processos. O que eu disse é para pararem com a idéia de que essa é a “solução”. Processos e metodologias, inclusive, nascem naturalmente entre bons profissionais de prática, afinal nada mais são do que a compilação das boas “práticas” conhecidas até esse momento. E justamente estou dizendo que não faz sentido também dizer que RUP é ruim, que UML é ruim, que PMI é ruim ou qualquer coisa desse tipo. Essa “aversão” que vemos hoje surge justamente porque existem aqueles que enxergam esses processos como “procedimentos” e tentam institucionalizá-las sem entender do que se trata. Agora, dado que você tem uma boa equipe, é óbvio que boas táticas vão fortalecer seu resultado. O artigo é contra o oposto: achar que um esquema tático substitui primeiro a formação de uma boa equipe.
Aislan Fernandes: Não entendi onde você quer chegar. E de novo soltou um termo pouco entendido e jogado ao vento o tempo todo: “Cultura organizacional”. E o que diabos é “cultura”? Definição: as artes e outras manifestações das conquistas do intelecto humano reconhecidas coletivamente. Cultura não se instala, não se institui, não se receita, se constrói com pessoas e com prática, não com procedimento. Não existe “importar uma cultura de outro lugar”. Cultura é aquilo que você já tem hoje numa determinada comunidade, no caso uma empresa. E uma empresa que entende que qualidade vem com aplicação de procedimentos primeiro, não vai a lugar algum. E você está confundindo, eu nunca em nenhum lugar disse “não use metodologias”. Muito pelo contrário. Eu disse sim: “não acredite que metodologias sozinhas vão trazer resultados sem primeiro ter bons profissionais”. E isso é um fato. Portanto minha conclusão é que você provavelmente pensou a mesma coisa, mas leu o artigo errado e receitou errado. Ah sim, e ser “prático” e “praticar” não são a mesma coisa.
Grande Akita, tens razão, Walker Royce é o pai do Winston W. Royce, o criador do Waterfall.
Você chegou a ler o artigo do Yoshima? Ele vai na mesma linha que você, curte:
“Se você é “a pessoa responsável pelos processos” não desanime! Existe uma alternativa! O foco da melhoria dos processos deve ser treinamento e menthoring. Acredite, os resultados serão muito melhores. Ajuste o foco para as práticas e para a colaboração das pessoas. Deixe de lado as reuniões inúteis, a definição de papéis e os templates do modelo de artefatos. Todas as metodologias são fundamentadas em valores e não em modelos de artefatos.”
Abs.
Akita, falei do post do Yoshima pois, baseado nele, faço a você as seguintes perguntas:
- Você acha que dar treinamentos/mentoring para a equipe vai resolver problemas de qualidade (de código, por exemplo ou falta de testes automatizados) visto que hoje qualquer um pode aprender sozinho pesquisando na internet?
– Será mesmo que um bom profissional de prática não precisa que outros lhes digam o que fazer: ele sabe o que constitui um bom trabalho e irá performá-lo de acordo ou irá procurar o que lhe falta e treinar até se tornar proficiente nisso?
- Pouquíssimos empresários tem a visão de que é preciso melhorar é a capacitação das pessoas da organização, isto é, investir nas pessoas, e os que tem essa visão não investem justamente porque tem medo do fenomeno da alta rotatividade que eles mesmo criaram no mercado. (muitas vezes grande parte das pessoas tem que ser demitida para conseguir mudar uma cultura de “Programadores Cowboys”) Ex: Empresario / Diretor de TI: ___ Não vou pagar um treinamento sobre testes (ou seilá o que for) para os meus funcionários, porque se eles fizerem esse curso nas minhas costas…depois eles vão para outra empresa e eu me ferro.//ou seja, não vou bancar eles de otário.
Já, se eu investir no processo de desenvolvimento ou em metodologias, opá, as pessoas podem sair e eu nunca vou “perder” esse investimento porque a certificação/processo de desenvolvimento será da Organização e não de alguem em especifico…. Então, não importa o custo, os empresários mesquinhos (90% do que temos hoje) sempre vão preferir investir em melhorias de processo do que melhorias da capacidade técnica/profissional dos seus funcionários por causa da alta rotatividade que temos hoje em TI. Entendeu o pq desse mercado de processos/metodologias ser tão forte? Enquanto não tivermos uma mudança drástica de pensamento dos empresários/diretores/gerente que temos hoje no mercado, vamos continuar nessa “merda”.
Enquanto isso, esses empresários mesquinhos vão continuar jogando dinheiro fora com melhorias de processo de software inúteis pois as pessoas são muito ruins tecnicamente…
O que você sugere para mudarmos essa realidade Akita?
Gosto dos artigos do Yoshima, também recomendo. Sobre suas perguntas:
É o que eu digo: resolver não vai. Pode ajudar? Com certeza, melhor do que nada. Mas é pouco, absolutamente pouco, menos de 0.1% do que é necessário. E se o próprio desenvolvedor não tem noção do que falta aprender, é perda de tempo. É como se fosse um jogador amador que só sabe chutar reto acreditando que já sabe tudo de futebol. Daí você mostra o que é um drible e ele pensa “nossa! coisa de guru! mas não é importante pro meu trabalho”.
Se é “de prática”, parte-se do princípio que você está sempre em busca de outros praticamentes, quer comparar as práticas, quer discutir novas técnicas e continuamente se aprimorar. Não se pode esperar que alguém vai vir dizer como fazer, tem que esperar que você mesmo é quem vai ver o que os outros estão fazendo. Antigamente artistas da Renascença, por exemplo, tinham que literalmente camelar centenas de quilômetros para achar outros praticantes. Ou então todos mais ou menos sabiam que indo para determinado centro urbano teria mais chances de encontrar outros da mesma prática. Programadores que não saem do cubículo são puramente preguiçosos. E na nossa profissão isso é trivialmente simples: basta estudar as centenas de projetos de código-aberto que estão publicamente disponíveis. Se o programador sequer sabe fazer isso, sinto muito, é um caso perdido.
Sinceramente, sou contra empresas serem responsáveis por pagar qualquer tipo de capacitação. Não é obrigação da organização fazer isso. É obrigação do profissional buscar sempre aumentar seu próprio valor de mercado. A empresa pode certamente colaborar, ajudar, mas tirem essa visão de que ela tem “obrigação”. Não tem. Quando você resolveu entrar em alguma empresa, tanto você quanto seu empregador tiveram que negociar. Seu empregador não o obrigou a aceitar qualquer coisa. Ambos os lados negociaram de forma voluntária para mútuo benefício. Se na negociação havia “verba para treinamento”, então o combinado não sai caro. Se não tinha isso e continua não tendo, a negociação continua sendo justa.
Você pode renegociar ou sair da empresa, é sua escolha.
E justamente por isso é bom que você saiba o que precisa ter para que o mercado pague o que você acha que merece. Aliás, o que você “acha” que merece normalmente é mais do que o mercado está disposto a pagar. E é o segundo valor que importa, o que cada um “acha” não vale nada se ninguém está disposto a pagar. E a culpa é unicamente sua.
Não existe empresário “mesquinho”, existe profissional que não sabe adicionar valor a si mesmo e não entende como funciona uma negociação. Ninguém é escravo. E a porta da rua é serventia da casa. Nenhum “empresário” vai te segurar, nem te obrigar a ficar, é você quem escolhe se fica ou se sai. E eu não acredito nessa visão paranóica de que os “empresários” acham mais barato custear implantação de metodologias do que pagar treinamentos em técnicas. Como diria sobre a Navalha de Occam, a resposta mais simples normalmente é a verdade: simplesmente quem investe não tem idéia dessas diferenças todas que eu mencionei, e eles efetivamente acreditam que o que estão fazendo é o melhor investimento. Só isso. Não existe teoria da conspiração nem “mesquinharia”, existe simplesmente falta de entendimento, que é o que estou tentando remediar.
Não conheço bons profissionais desempregados. Aliás, é meu maior problema, porque todo mundo que quero contratar já está bem empregado. Eu fico sempre de olho nas transições. Um bom profissional não precisa “procurar por emprego”, o empregador vai até ele. Sempre foi assim. Vai continuar sendo assim. Quem se enxerga como commodity, vai continuar sendo valorizado como tal: commodity.
PS: e só pra não dar mal entendido, quando eu digo “você” no comentário, não me refiro a “você Thiago” mas a “vocês programadores em geral que estão lendo meu artigo”.
Grande Akita, excelente resposta!
Estou vivenciando o que você falou, principalmente essa parte:
“Aliás, o que você “acha” que merece normalmente é mais do que o mercado está disposto a pagar. E é o segundo valor que importa, o que cada um “acha” não vale nada se ninguém está disposto a pagar. E a culpa é unicamente sua.”
//Conclusão: Não adianta ir pedir aumento sem ter uma outra proposta de emprego na mão (de preferência com o $ bem maior)
E, essa outra parte, com certeza vai ficar de reflexão pra mim e para muitos “Thiagos”:
Como diria sobre a Navalha de Occam, a resposta mais simples normalmente é a verdade: simplesmente quem investe não tem idéia dessas diferenças todas que eu mencionei, e eles efetivamente acreditam que o que estão fazendo é o melhor investimento. Só isso. Não existe teoria da conspiração nem “mesquinharia”, existe simplesmente falta de entendimento, que é o que estou tentando remediar.
Abraços
Akita, só para fechar, concordo com tudo que você falou em resposta ao meu segundo comentário.
E, novamente (caso não tenha visto meu “PS”), a idéia não foi dar um “sermão” sobre seu comentário, mas só colocar uma visão geral mesmo. E valeu pela discussão.
Akita e Thiago, ótima discussão.
Só acrescento que acho utópico partir do princípio que todos os profissionais de uma área, desenvolvimento de software, no caso, devem ser apaixonados pelo que fazem. Isso, simplesmente, não existe. Pode até existir num universo reduzido de uma empresa, mas, de modo geral, nós já sabemos como funciona.
Sempre houve e sempre haverão aqueles que “não treinam”. Os não-praticantes.
Como lidar com essa situação?
Hamon: não tem uma resposta
Claro, se tivesse estaríamos todos aplicando com sucesso. Você está dizendo que apenas uma parcela pequena dos profissionais de TI efetivamente se importam com a profissão como eu descrevi. E isso é verdade. Agora o que é utópico é todo mundo acreditar que isso pode ser “corrigido” via aplicação de processos e metodologias. Esse é o erro. Não se muda um mercado inteiro da noite para o dia, mas à medida que as empresas passam a valorizar mais esse tipo de profissional que eu descrevi, em detrimento dos batedores de cartão, naturalmente a lei da oferta e da procura fará seu trabalho. Como hoje todo mundo contrata qualquer coisa imaginando que “basta encaixar no processo que funciona”, continuará existindo as aberrações que vemos todos os dias. Eu barro logo na entrada e se passar, facilito a saída, ou seja, minha equipe hoje é muito acima da média do mercado. Dá mais trabalho montar, com certeza, mas o resultado é muito melhor.
Akita, o que fazemos então com a péssima qualidade das nossas universidades e a crescente demanda? Se a solução é ter bons profissionais e estes faltam no mercado como fazer?
O que eu creio que não ajuda é dogmatismo. o problema de todos os métodos e processo que tiveram até agora é que muito poucos se preocupam no modelo de transição para eles. Inclusive os métodos ágeis são dogmáticos. Eles não ensinam como implantar eles.
Um cultura Kaizen é a solução mesmo com uma equipe que não é madura. Veja o que postei neste fim-de-semana também:
http://blog.aspercom.com.br/2011/04/03/o-mito-da-cultura-agil/
Ótimo post, e concordo que processos/metodologias não vão, sozinhos, resolver a questão do batedor de cartão, que não se importa muito com o trabalho que está fazendo. Mas gostaria de contribuir com as minhas opiniões para prolongar um pouco mais essas discussão.
Na primeira vista acredito que usando cegamente alguma metodologia(ágil ou não), podemos apenas expor o problema, se para o caso em questão isso realmente for um problema. E a adoção de um processo, em média, pode acabar forçando uma prática que o bendito não acredita. O que em geral vai leva-lo a não se adequar e ser demitido ou se “encaixar” no perfil procurado e burlar/boicotar o processo em questão.
E fazendo um fork da idéia apresentada pelo Rodrigo Yoshima, eu não acredito na idéia de um profissional irrecuperável, isso tem uma faceta dogmática e extremista. Uma pessoa que está em um estado de batedor de cartão, está assim por algum motivo. Se pegarmos um profissional exemplar nos moldes deste contexto e voltássemos no tempo e fizéssemos com que ele passasse por todas as experiências que um dito profissional ruim passou desde o início de sua vida, será que esse profissional continuaria sendo bom? Acredito que em boa parte dos casos a metáfora da tabula rasa se aplica. Me parece ser muita responsabilidade julgar um sujeito como irrecuperável e mandá-lo para a cadeira elétrica.
Creio que o que falta para um profissional “ruim” é visão, seja de sua capacidade de ser um profissional melhor ou visão do que realmente importa na sua vida pessoal. Nós não podemos projetar os nossos anseios sobre as nossas vidas sobre a de outra pessoa. Eu não sou um Coach e não conheço muito sobre o assunto, mas parece que pode ser mais um caminho.
Yoshima e Daniel: vocês dois disseram a mesma coisa, mas eu continuo dizendo que a premissa está errada. Resumidamente vocês disseram: “sim, concordo que processos e metodologias não resolvem o problema. Porém o problema existe, programadores ruins existem. Portanto, tentar aplicar metodologias é melhor do que nada.” Eu discordo. X é solução para Y. Mas temos o problema B, cuja solução é A. O que vocês estão dizendo é que dado o problema B, não dá pra aplicar A, mas de repente aplicar X não é tão ruim assim. Eu vejo um distúrbio na Força
Processos e metodologias tem um pré-requisito: que eu tenha profissionais minimamente qualificados. Não estou dizendo Jedis que escrevem Assembler no café-da-manhã. Um Padawan serve, claro. Tenho programadores novos, de menos de 25 anos, que ainda precisam de experiência mas que claramente estão melhorando tecnicamente todos os dias, que tem preocupação em buscar as técnicas, em buscar bons exemplos, em pesquisar e estudar continuamente. Por outro lado eu pessoalmente fiz alguns “project rescue”, de programadores ditos “seniors”, em empresas ditas “ágeis”, que dá VERGONHA de ler. Código que não é ruim, é absolutamente péssimo, o equivalente a um motorista que bate o carro toda vez que pensa em ligá-lo.
O que eu estou dizendo é que todo mundo tenta resolver o problema B com a solução X. Eu estou dizendo que X resolve Y e para resolver B você precisa de A. Não tem segredo. A única diferença é o que eu já vi várias vezes: código ruim que em vez de ser entregue uma vez por mês, passa a ser entregue uma vez por semana ao final do sprint. Ou qualquer equivalente. Mas continua sendo código ruim. “Ah, mas isso quer dizer que a empresa/equipe não entendeu Ágil”. Bullocks. É o que estou dizendo: os resultados corretos de uma metodologia só dá para ser interpretado e entendido porque quem entende do ofício. E isso me leva de volta a tudo que eu disse no artigo.
Ah, e todos que querem refutar um argumento sem argumentar partem pra falácia de dizer que a afirmação é “extremista” ou “radical”. O entendimento implícito é que isso é ruim de algum modo. Mas lembrem-se de uma coisa: um extremista ou radical, por definição, simplesmente significa que ele é “consistente”. Existe preto ou existe branco, cinza é a raíz de todo o mal. Leiam: http://akitaonrails.com/2009/09/08/off-topic-o-culto-da-moral-cinzenta
Yoshima, creio que a situação de nossas faculdades não são a causa do problema e sim consequência. Consequência de um péssimo ensino básico.. mas isso são outros 500.
[]‘s
Considero que extremismo pode ser algo limitante para a evolução do ser humano. O fato de querer ser consistente pode te forçar a não admitir um erro ou mal julgamento, já que você estaria contra o seu ego. É a mesma força que faz um grupo querer adotar métodos ágeis a qualquer custo.
Até as ciências exatas não são exatamente preto ou branco. Se olharmos a matemática por exemplo partimos sempre de axiomas e a partir daí tudo de fato é preto ou branco, uma equação está certo ou errada. Mas o nosso cinza está justamente nos axiomas que são o que podem mudar com o tempo, mas para um matemático isso não entra na questão ele só te diz que se uma dado conjunto de axiomas for verdade ele prova que o resto também é.
Quando chegamos na Física o caso só piora, não só usamos a matemática como ferramenta mas como nos baseamos muito em fenomenologia e interpretação, que são fontes de mais áreas cinzas. Historicamente diversas “verdades” absolutas foram alteradas, comprovadas, demonstradas como inválidas e comprovadas novamente. Localmente e em um dado instante tudo poderia ser visto como preto e branco, mas na média é tudo cinza.
O meu argumento é que não existem programadores definitivamente bons ou definitivamente ruins e mesmo que existisse a definição desta distinção não é unica e nem a mesma ao longo do tempo. Tudo depende das necessidades de um dado projeto, de uma dada empresa, de uma dada época.
Não acho que extremismo seja bom porque dá brecha a muita intolerância, quando penso em extremismo lembro logo de Talibans e Nazistas. Entendo que o extremista acredita em uma verdade absoluta acima de qualquer outra(Dogma), ele quer uma resposta unica para o seu questionamento seja lá qual ele for, o fato é que realmente existem várias verdades, pergunte para vários extremistas religiosos e eles vão te dar as suas verdades absolutas, que em geral são divergentes.
PS.: vou me desculpar pelo Hijack desse post e pelo ligeiro desvio de rota do assunto. Espero que essa conversa não pareça ofensiva ou desrespeitosa. Pelo contrário, Akita, eu adimiro a sua participação na comunidade de desenvolvimento.
Daniel: não ofendeu
e a idéia é discutir mesmo, por isso os comentários são abertos (com exceção dos que o wordpress considera spam e ai pode demorar até eu aprovar). Enfim. A questão no artigo não é classificar quem é desenvolvedor “bom” ou “ruim”, não entrei nesse mérito. O artigo discute o seguinte problema: “o desenvolvimento de software na minha empresa é ruim, portanto preciso adotar metodologias X”. É uma conclusão válida, mas não deveria ser a primeira. Primeiro defina “ruim”. Se disser que os problemas são: a) é lento e afeta meu time-to-market; b) constrói-se coisas que não deveriam; c) bugs funcionais já corrigidos voltam a aparecer. Coisas assim provavelmente podem ser remediadas com algumas técnicas de algumas metodologias, por exemplo a) priorizar o que deve ser construído, refinando o backlog continuamente; b) criando testes de regressão e garantindo que eles estão sendo executados continuamente. São duas técnicas.
Agora se o problema é: a) estou infestado de bugs técnicos, o tipo que dá crash ou corrompe minha transação; b) toda vez que um novo desenvolvedor entra na equipe ele reclama que se desmotiva pela má qualidade geral do código; c) todo novo código que entra gera novos problemas; d) é lento porque toda vez que precisa construir alguma coisa, outra coisa quebra e todo mundo corre atrás do próprio rabo. Enfim, coisas relacionadas a código ruim, existem várias coisas que podem ser feitas e normalmente não é aplicação de processos ou só aplicação de processos.
Em algum momento no passado talvez a tecnologia era nova demais, ou de fato não era possível fazer de outro modo, enfim, código ruim foi injetado e débito técnico foi acumulado. Não é automaticamente “culpa” de quem fez primeiro, pois existem dezenas de motivos justos para que código ruim exista. Porém uma vez identificado que isso está se tornando um problema, é preciso resolver código com código. Seja refatorando partes do código para melhorar a manutenção, seja reescrevendo com técnicas e tecnologias melhores. Enfim, é um trabalho puramente técnico. E isso um “arquiteto” (daqueles que acham que ser arquiteto o torna isento de entender código em mais detalhes) ou um “analista de processos” jamais vão resolver, nem vão chegar perto.
Quanto a ser extremista, por favor releia o artigo linkado sobre “O Culto da Moral Cinzenta”. Para ser cinza você precisa saber o que é preto e o que é branco. Digamos que preto é o que você considera “certo” e branco é o que você considera “errado”. Se você só conhece branco, sem conhecer o preto, e ainda defende o branco, de fato é um problema. Mas se você se diz “cinza” é porque conhece tanto o certo quanto o errado e está conscientemente escolhendo “cinza”. Mas lembre-se: o meio do caminho da mistura de comida e veneno é que o veneno vence (você pode só morrer mais devagar). Porque escolher cinza se você já conhece o preto?
Quanto a argumentos, obviamente todos podem ser refutados, inclusive os considerados “irrefutáveis”. Mê dê os argumentos e eu mudo minha conclusão. Mas me dizer “não vou discutir porque você está sendo extremista” ou “você está automaticamente errado porque está sendo extremista” é a saída dos ignorantes para terminar uma discussão, o que obviamente não acrescenta nada à questão. E isso eu não aceito.
Partindo da analogia com música.
Música que é refinada e elegante, que existe uma harmonia nas notas, que você percebe que quem a fez teve muito carinho pela sua obra, pode, as vezes, ter valor apenas para poucos que apreciam essa beleza. Mas se o objetivo por trás da música é vender um CD, uma música pop é mais eficiente nisso. Se o objetivo final é apenas divertir o ouvinte, um Rebolation vende mais, por que? Porque pode até existir alguém que se preocupe com a melodia, mas não é o foco. O foco está no produto final. Os malefícios disso pode ser que a cada 3 meses a banda pop tenha que produzir mais músicas, talvez porque as que ele fez são tão pobres que são esquecidas facilmente, mas o fato é que para este mercado isso é aceitável e normalmente desejável.
Se estivéssemos entregando código e não produto, aí sim o foco estaria na elegância do código. Mas isso se aplica em geral em algum projeto pessoal, ou algum laboratório de pesquisa. Código bom só é importante para o produto se a manutenção para o produto é prevista e o tempo de resposta tem que ser rápido. Fazer código bom por fazer é muito divertido para o programador, mas não vende, e por isso existem diversos artistas na rua tocando Bob Marley por umas moedas. Quantos dos grandes artistas morreram com pouco sucesso? Não é que eu goste desse modelo mas aparentemente é bem próximo da realidade que eu tive contato. Eu prefiro 1000x escutar Beethoven do que Parangolé, mas dado a nossa estrutura voltada para o capital, Parangolé dá de 10 no pobre Ludwig.
Mas digamos que o código tenha que ser manutenível por um longo período de tempo. Concordo que em geral o time, ou algum de seus membros, deveria ter a noção disso antes de qualquer outro. Mas digamos que esse não é o caso, estamos com um time mediano, que não conhece o que é um código bom, o que sendo otimista pode representar uns 60% do mercado, certo?
Agora vamos supor que eu seja um gerente que está participando desse projeto, não desenvolvo a mais de 5 anos, não sei como escrever código bom, mas sei que isso é importante para a sustentabilidade do projeto, o que eu faria? Como posso mudar o processo para que isso ocorra? já que do time eu não vou esperar nenhum movimento. A princípio dar a visão de que código bom importa e que o código que eles produzem é ruim para manutenção. Como? uma frase que acho que se aplica é: se algo está difícil faça mais vezes. Se manutenção é um problema faça mais frequentemente, e isso em geral só é feito mudando o processo. Por exemplo, se existir uma equipe somente para manutenção, remova ela e diga para o time de desenvolvimento fazer isso. Use desenvolvimento iterativo, que no fundo estamos sempre fazendo alteração, e assim, mantendo o código que mexemos semana passada. Se com isso o código continuar ruim isso vai refletir mais rápido na performance do time e não depois de um ano de código não lido, o que dá mais tempo para tentar outras coisas.
Enfim, com mudanças no processo estamos buscando alterar a mentalidade do time e assim ter um profissional melhor. Isso é impossível?
o que eu quero dizer é que as vezes (60% do mercado?) mudar o processo é a única opção para um determinado time. Concordo com você que não dá para alterar o processo de uma forma que eu obrigue o meu sistema a gerar código com qualidade, isso não tem como garantir. Mas podemos usar o processo para que ele de um maior feedback, e com mais frequência e assim tentando gerar aprendizado que pode ou não melhorar o código. Acho que no fundo tudo depende da intenção de quem está gerenciando esse processo.
Daniel: concordo com o que você disse. Seu comentário tem duas etapas. Primeiro sobre valor: nao estou evangelizando que todo código deve ser excelente nem que todo programador tem que ser excelente. Felizmente ou infelizmente tem mercado para todos. Existem os que realmente nao estão nem aí se o produto tem bugs, sem manutenções são demoradas e dolorosas ou se a equipe é ruim: o produto esta dando muito dinheiro e só isso já é uma bom argumento. Eu já fiz a besteira de tentar mudar tanto técnica, processo e profissional desse tipo de projeto mas foi perda de tempo. No final das contas nao se pode discutir contra resultado: um Windows pode ser mil vezes pior que um Linux, mas para a maioria das pessoas o Windows da ordens de grandeza mais lucro e é isso que importa.
Agora, você tem uma equipe ruim e quer mudar isso apenas via mudança de processo? Eu acho pouco. E isso porque economicamente nao faz sentido. Se nao existe motivação do profissional em melhorar a si mesmo, mudar o processo ou criar novas regras simplesmente vai aumentar ou criar corrupção. Se o objetivo no fim do dia nao é fazer o melhor código visando maior lucro mas sim ganhar salário no fim do mês, se você aumentou as restrições as pessoas vão sempre, e eu ressalto o sempre, procurar o caminho de menor esforço. Corrupção, trapaça, enganação. Afinal o salário nao mudou e agora você esta exigindo “trabalho extra”, se o indivíduo for racional ele vai procurar continuamente meios de burlar o sistema (corrupção, que é o sinônimo de “jeitinho brasileiro”).
Mudar processos, buscar melhoria continua só funcionam para quem enxerga valor nisso. Então a primeira premissa é separar o joio do trigo, e estatisticamente falando, a as pessoas ruins – que se chegaram ate esse ponto por tanto tempo conformados – serão a maioria. Conclusão: nao inclua um plano meramente de mudança de processo. Inclua um plano de reciclagem, obrigatoriamente. Barrando mais pessoas iguais de entrar e realizando cortes sistemáticos.
O problema: nao é só a equipe que tem elementos ruins, seus chefes e gerentes também são assim, e eles também nao querem mudar o status quo. O corte deveria começar no nível da gerência que permitiu que as coisas chegassem a esse ponto lamentável, pois se a equipe é ruim no fundo estavam seguindo orientações ou ordens de alguém. Onde esta esse alguém agora para assumir a responsabilidade.
Agora existem sim pessoas motivadas, com potencial e que querem verdadeiramente melhorar. Quer ajuda-las? Contrate mais gente sênior de verdade (nao esses certificados, arquitetos, blá blá), mas gente de credibilidade (isso é difícil) e que eles sejam os exemplos de onde as pessoas podem chegar. Exemplo, esse é o primeiro passo. Exemplo de como se faz vindo de quem tem autoridade e autonomia para isso.
Nao adianta pagar curso, pagar palestra, só pratica e orientação e alguns anos extras de pratica vão ajudar. Anos. Nao semanas.
E quem esta perdendo tempo fazendo reuniões e comitês porque acha que entende do assunto deveria estar arregaçando as mangas e escrevendo código para mostrar como faz. No tempo de uma hora de reunião inútil para definir padrões sem sentido já dava para ter instalado e configurado um Hudson para integração continua. E assim por diante.
Nao gosto do pensamento pequeno de “melhor do que nada”. Se for para fazer tão pouco, melhor nao fazer, ou encarar que a empresa nao tem futuro e abandona-la de vez.
“Do, or do not. There is no try.”
Gostei bastante do artigo!!
Acho que o único ponto de discussão seja mais o título “Processos e metodologias não vão te ajudar”.
Se entendi o ponto é que processos e metodologias podem ajudam, mas o melhor dos processos com profissionais ruins nunca será tão bom quanto bons profissionais sem nenhum processo, afinal de contas bons profissionais irão encontrar o processo necessário para que realizem o que são pagos para realizar! E concordo absolutamente com isto!
Abraços!
@ricardofluiz
Ricardo: é isso mesmo. O título é destinado a quem defino no começo do artigo: a quem acha que “basta aplicar algum processo ou metodologia que tudo vai se resolver”. Por favor, recomendo ler os artigos que publiquei logo depois desse para ler uma “continuação” ao tema.