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.