Tem havido muita discussão sobre como as práticas de desenvolvimento Agile estão prejudicando mais do que ajudando. As pessoas se queixam de coisas como testes unitários, TDD, CI, programação em par, e falam que revisões de código limitam a criatividade do desenvolvedor e criam um trabalho desnecessário.
Isso é naturalmente irônico, já que os processos Agile surgiram precisamente porque as pessoas sentiram que os processos não-Agile que os precederam estavam prejudicando mais do que ajudando. Então, o que está acontecendo aqui?
Por que os processos existem?
Os processos existem para garantir os resultados. Se você não se preocupava com a rapidez com que podia fazer algo, ou com quão bem ele funcionará, você não precisa de processos. Mas você se importa. Então descobre maneiras para garantir que possa entregar a tempo, com qualidade, e com qualquer outra característica com que se importe.
Processos também existem para obter resultados previsivelmente bons de grupos de trabalhadores qualificados de formas diferentes. Se eu tiver um exército de pessoas que fazem widgets, quero alguma garantia de que vão continuar a fazer widgets bons, não importa quem esteja envolvido (desde que tenham algum nível base de habilidades).
Mas e o desenvolvimento de software?
Isso não deveria surpreender ninguém, mas o desenvolvimento de software também precisa de processos. Por que não precisaria? Afinal, você se preocupa com fornecimento de bons softwares e deseja resultados bons das pessoas que o constroem.
E o que faz um bom software? Além do óbvio (que funciona bem e faz o que você quer que ele faça), um bom software é fácil de conviver. É fácil de corrigi-lo se for necessário, é fácil mudá-lo se quiser.
Por que os processos tendem a ser ruins?
É quase inevitável que os processos limitarão os impulsos individuais (ou seja, criatividade). Levados ao extremo, eles sufocarão a paixão, transformarão todos em ociosos estúpidos, e geralmente tirarão a diversão do trabalho. Ninguém quer isso. Mas ainda precisamos fazer as coisas.
O truque é não levar as coisas longe demais. Parte disso está no reconhecimento de que quanto mais capazes são os desenvolvedores, de menos processos você precisa para orientá-los. E vice-versa.
Imagine por um segundo que a sua equipe de desenvolvimento seja composta por ninjas que podem fazer rapidamente um código como se não estivesse estlizado. Eles podem construir o que você quiser, com rapidez e eficiência, sem bugs, e levar aos clientes finais com o mínimo de perturbação quantas vezes você quiser. Será que você ainda precisaria de processos elaborados para ajudar a guiá-los? Provavelmente não.
Mas aqui está a realidade: a maioria das empresas não tem equipes de ninjas escrevendo código. Isso vai soar duro, mas a maioria dos desenvolvedores não é ótima. Na verdade, a maioria nem sequer é especialmente boa. E pensam que são melhores do que realmente são (incluindo eu mesmo).
E isso fica ainda pior. A maioria das equipes também tem que lidar com bases de código hostis, o que torna muito mais difícil fazer um bom trabalho. Mesmo desenvolvedores bons podem se complicar com isso.
No entanto, apesar dessa realidade, você ainda precisa fazer as coisas. Então, você encontra maneiras de obter desenvolvedores (excelentes e não tão excelentes) para fazer um bom trabalho. É disso que trata a maioria das práticas de Agile.
Você faz uma unidade de teste ou TDD ou par, porque ajuda a reduzir erros e a escrever um código mais sustentável. Você configura a CI, pois ela ajuda você a encontrar bugs rapidamente e lhe ensina como fazer o deploy do seu aplicativo de forma eficiente. E assim sucessivamente.
Pensamento final
Se você acha que as práticas de engenharia Agile são dolorosas ou desnecessárias, você pode muito bem estar certo. Mas, seja como for, essas práticas são as melhores ferramentas que temos hoje para conseguir que os desenvolvedores façam um bom trabalho. Então, se você realmente quer uma mudança, há dois caminhos a percorrer: ou obter desenvolvedores muito melhores ou inventar melhores práticas.
?
Texto original disponível em http://tatiyants.com/are-agile-dev-practices-needed/







