Construindo o mundo perfeito

Todo os dias, escutamos desenvolvedores, gerentes, estagiários, analistas, e quem mais estiver envolvido com o mundo técnico do desenvolvimento de software reclamando de alguma coisa e falando “… se nós utilizarmos o framework XYZ …” ou “… se aplicarmos a metodoliga KXH…”, enfim sempre alguém tem uma “Bala de Prata” que mata todos os problemas possíveis e impossíveis que vemos pela frente.

Bom, a idéia aqui é iniciar uma discussão sobre como montar um ambiente de trabalho, simples, colaborativo e objetivo com base em práticas e técnicas que existem para que as pessoas que sempre reclamam e sugerem o mundo do “avesso” para resolver estes problemas, possam ver que tudo pode ser feito de forma simples e objetivas, fazendo com que todos os envolvidos participem de todo o processo, assumindo seus devidos papéis e responsabilidades.

É impossivel falar de ambiente de trabalho para quem trabalha com desenvolvimento de software sem falar de processo, documentação ou ferramentas de apoio, sendo assim, vamos começar.

Graças a Deus hoje escutamos e vemos muitas pessoas da área de TI falando sobre processos ágies, o que é excelente quando realmente aplicamos tais processos. A idéia de desburocratizar o dia-a-dia de trabalho é ótima, porém antes disso é necessário criar uma cultura de trabalho mais simples e não forçar as pessoas a trabalhar de uma maneira totalmente diferente em relação ao que elas estam habituadas.

O SCRUM e o XP são exemplos claros de que criar uma cultura de trabalho é muito melhor do que impor uma maneira de fazer as coisas. É inegável que processos mas conservadores contribuiram muito para os avanços que obtemos hoje, quando falamos em processos e metodologias, porém figuras como RUP criaram passos gigantescos entre o mundo de negócios e as implementações em código e que cada vez mais vemos esses abismos crescendo (o que normalmente implica em prazos estrapolados, recursos realocados, clientes insatisfeitos, etc.).

Outro ponto de vista, o técnico, mostra que quanto mais burocracia mais problema, exemplo: a velha e boa arquitetura J2EE vs. Arquiteturas apoiadas em DDD. É fato que tudo feito antes do surgimente de técnicas como o DDD criaram verdadeiros monstros como Arquitetos e Consultores, porém mais uma vez caimos na situação de ver o mundo dar milhões de voltas para conseguirmos dar pequeno passo.

A simplicidade de implementação que vemos em técnicas de engenharia de software dirigidas ao negócio ou a testes é o objetivo de milhões de ferramentas, porém, quanto custam estas ferramentas? E outra, o resultado é realmente eficiente? O que pode ser melhor do que ter nas mão um conjunto de práticas que resultam na simplicidade de implementação de uma regra de negócio que atende a demanda que o seu cliente tanto sonha em ver funcionando? Opa olha a cultura aparecendo novamente!

Processos e metodologias ágies são o “BUM” do momento, mas por quẽ? Simples, porque funcionam. Vamos pensar assim, se você que está lendo esse post (e possívelmente é ) for técnico pense da seguinte forma, você nunca programou na vida, nem sabe da existência das linguagens de programação, você é um administrador que subiu na vida e tem seu próprio negócio, mas depende de um setor de TI na sua empresa que lhe de apoio para que o seu negócio funcione. Você precisa de “feedback”, de comunicação, de flexibilidade de trabalho (afinal o mundo dos negócio vive em constante mudança), e não podemos esquecer que tudo são números (ou melhor valores). Metodologias ágeis trazem essas práticas para o dia-a-dia de quem às pratica. Veja o XP por exemplo, feedback, comunicação, coragem e simplicidade são seus principais valores e ajudam na flexibilidade de aceitar mudanças.

Testes, uma prática que infelizmente não vivi muito pelos clientes em que passei, para os gerentes que tive (nem todos) escrever testes ao invez de codificar um caso de uso é perda de tempo. Bom o fato é que ter um caso de testes como “alvo a ser atingido” pelo seu código é muito mais simples do que seguir um documento (as vezes mal escrito) é muito melhor, pois garante integridade e valida o seu trabalho. No livro “XP Explicada”, Kent Back cita um termo criado pelo Erich Gamma, “infectados por testes” que faz referência a pessoas (desenvolvedores, analistas e gerentes) que não conseguem aceitar não utilizar ou escrever testes, a idéia de não se antecipar a um problema é simplesmente inaceitável. Que bom seria trabalhar sempre assim!

Bom por enquanto é só, no proximo post vamos falar sobre onde entra a documentação em tudo isso. Fiquem a vontade para comentar, criticar e sugerir. Até mais.