A revista National Geographic Brasil de julho 2007 veio com uma matéria sobre Inteligência Coletiva, que falava do comportamento de pássaros, abelhas, formigas e peixes que estavam sendo estudados e também aplicados no trabalho, no aeroporto, na internet e eu diria também no desenvolvimento de software com objetivo de facilitar e otimizar processos.

No caso do formigueiro, a colônia é capaz de resolver problemas impossíveis para cada formiga individualmente, como por exemplo, achar o caminho mais curto para a melhor fonte de comida. Se individualmente elas são estupidas, coletivamente são ágeis e eficientes, fenômeno denominado de “inteligência de enxame”.

Uma característica muito importante no formigueiro é o fato de ninguém está no comando, e a colônia funciona muito bem, mesmo sem ter um sistema de controle. O funcionamento da colônia é baseado em diversas interações entre as formigas, cada qual seguindo regras práticas muito simples sendo a comunicação por meio do toque e odor (ferormônio).

Outro fato interessante ocorre num enxame de abelhas que mesmo havendo desacordos frequentes sobre os lugares onde formar nova colmeia, elas sempre escolhem o melhor local. Chegando a essa decisão por avaliações independentes e algum tipo de votação. Novamente é um trabalho coletivo descentralizado. A abelha rainha possui a única função de pôr ovos.

Esse comportamento das formigas já é extensamente aproveitado na computação na área de otimização combinatória através do algoritmo “colônia de formigas” que é utilizado para descobrir a melhor rota para coleta de lixo em uma cidade, transporte de combustíveis a partir de poços de petróleo espalhados geograficamente, com objetivo de diminuir o tempo do serviço, diminuir o gasto com combustível, evitar que o caminhão passe mais de uma vez pela mesma rua, entre outros problemas.

Comparando um pouco esses princípios da inteligência coletiva podemos identificá-los em práticas do Extreme Programing como a do “Código Coletivo” onde todas as classes e métodos pertencem à equipe e caso seja necessário qualquer integrante poderá modificá-lo sem ter que pedir permissão, mas para garantia de segurança só é possível o uso pleno dessa prática se a equipe investir na criação de testes automatizados.

Fazendo analogia com as comunicações simples das formigas o XP utiliza-se das práticas de “programação em pares” e de “Reunião em pé“, em que o conhecimento poderá ser dividido e propagado para todos os integrantes da equipe garantindo dessa forma a prática do código coletivo e evitando o risco de determinada rotina ou código fique sem manutenção devido a falta de algum desenvolvedor por motivo de doença. Nesse caso logo outro assume pois já tem uma noção do funcionamento do código. As reuniões garantem o andamento correto do desenvolvimento sem correr o risco de fugir do que foi priorizado em planejamento.

Existe várias outros valores, princípios e práticas no XP, que juntos acabam tornando o desenvolvimento mais produtivo, mas algo importante deve ser reforçado: para o funcionamento efetivo cada integrante da equipe deve estar comprometido e assumir as responsabilidades. Isso deve ficar bem claro, senão acaba voltando para outras práticas hierarquizadas em que o desenvolvedor fica esperando que o gerente de projeto lhe dê algo para fazer.

É bem semelhante à coletividade das abelhas, formigas e peixes que sozinhos são prezas fáceis e não conseguem realizar tarefas complexas, mas em conjunto, cada qual fazendo sua parte, conseguem realizar tarefas que até hoje facinam os pesquisadores da área.

Bom, fico por aqui e até o próximo “pense nisso!”.

Bom, como vocês podem perceber não coloquei nem vou colocar link para páginas que explicam sobre POG, pois trata-se de práticas que realmente são inúteis para um desenvolvedor, mas caso queiram ler com o intuito de distração, ou divertimento sem tomar como referência profissional, podem colocar o termo no google ou na wikipedia que encontrarão algo.

Vejam a definição de gambiarra citada por Rodrigo em sua dissertação de Mestrado.

“Gambiarra é o nome dado informalmente ao procedimento necessário para a configuração de um artefato improvisado. O termo também costuma ser usado para definir o artefato em si.”

Ele também mostra que é preciso compreender tal atitude como um raciocínio projetivo imediato, determinado em situações momentâneas além de associa-lo culturalmente ao chamado jeitinho brasileiro.

Já sei, agora vocês querem saber o que é que isso tem a ver com a prática do XP.

É exatamente isso que vocês pensaram! Não tem absolutamente nada a ver! XP não é improviso, não é um jeitinho e definitivamente não é gambiarra!

O XP são um conjunto de práticas consolidadas que visa tornar o desenvolvimento de software mais dinâmico, incremental, com maior velocidade de resposta, com mudanças freqüentes e sempre com participação ativa do cliente e usuários.

Ele segue com princípios contrários a outras práticas mais tradicionais, devido ao gargalo formado pelo excesso de documentação e dificuldade de comunicação efetiva entre os diversos responsáveis pelo desenvolvimento. Que terminavam com muita freqüência entregando software com prazo extrapolado e muitas vezes com cliente insatisfeito, que quando não falava pelo menos pensava na seguinte frase: “Não é nada disso que eu estava querendo!”.

Ao invés de separar a equipe por funções diferenciadas: analista, gerente de projeto, programadores, etc, cada integrante deve estar envolvido em todo o processo do desenvolvimento de um software, da reunião para decidir o que deverá ser feito, de uma análise para definir como será feito, criação do teste (TDD), criação do módulo escolhido (interface que o usuário poderá testar para dar seu feedback). Essa forma de deixar o profissional ficar a par de todo o processo, deixando-o muito bom no específico ato criativo de programar e também possibilitando uma visão geral foi inspirado na metodologia da Toyota.

Na década de 40 a Toyota precisava encontrar fomas de produzir automóveis com maior agilidade e qualidade e ao mesmo tempo reduzindo os custos. Foi assim que criou a chamada Produção Enxuta e aperfeiçoou por décadas, hoje é conhecida como just in time.

O quinto e o sétimo princípio básico do método se chama “delegar poder à equipe” e “Ver o Todo” respectivamente. Eles partem do princípio que para ampliar ao máximo a qualidade é necessário obter os detalhes corretamente e a pessoa mais adequada para isso são as que efetivamente executam o trabalho, no popular “põem a mão na massa”. Coordenando com isso a uma constante verificação do todo, o conjunto final deve ser sempre mais importante que um componente específico, o que gera a necessidade de cada integrante estar além de sua especificidade tomando decisões também em níveis de análise e projeto.

Utilizando desses e de outros princípios, a Toyota conseguiu em abril de 2007 a marca história e simbólica de ultrapassar a General Motors(GM) na venda mundial de automóveis.

Em sua palestra sobre XP utilizando a interface do Treina Tom, Vinícius Teles mostrou um slide com a foto de Jack Järkvik que é o Vice-Presidente da Ericsson na suécia e que ele falava do quanto a empresa ganhava dinheiro no decorrer dos anos. Muito dinheiro, mas muito dinheiro mesmo! Falou também que Jack apontou para a tela que mostrava as práticas do XP e disse que tudo isso que estava sendo exposto no evento sobre XP eles já utilizavam desde a década de oitenta, que conseqüentemente foi o que fez com que eles ganhassem muito dinheiro.

Peço então aos que ainda acham que XP é gambiarra que perguntem aos dirigentes da Toyota e da Ericsson se os processos deles são gambiarra e acho que terão uma resposta muito interessante. E ainda dou uma dica, Vinícius falou que o Vice-Presidente da Ericsson em sua palestra tinha uma postura bem arrogante. Aqui em baixo tá a foto dele para vocês terem uma noção:

Mas ainda acredito bastante na liberdade de expressão, pois foi justamente por isso que consegui ter contato com novos conceitos e tenho também confiança que alunos, profissionais ou pessoas antenadas vão saber detectar a diferença entre um comentário superficial, sem valor, e um comentário melhor elaborado, que aliás é um dos princípios da academia, que repassa conceitos científicos e filosóficos para o cidadão obter mais ferramentas além do conhecimento do senso comum, que é importante, mas quando lidamos com ambientes de produção, ele sozinho não dá conta do domínio do problema.

Mas aí algum profissional pode me questionar, mas o RUP tem dado certo em instituições como Banco do Nordeste e não é uma metodologia ágil.

Não estou aqui me desfazendo de nenhum outro processo, só estou afirmando tecnicamente e historicamente que o XP é um processo válido, consolidado e tem gerado resultados bons, inclusive em grandes empresas. Sou a favor que o aluno tenha contato com diversas abordagens e no fim tome a decisão de tentar seguir a que mais se aproxime das suas expectativas e princípios. Confirmo novamente que a desburocratização do processo de comunicação que é praticado no XP torna o ambiente mais dinâmico, menos entediante e mais saldável para essa geração que não se identifica muito com exagero de hierarquias e processos burocráticos, para pessoas que gostam de priorizar o software e não o exagero de documentos.

Com relação a documentação, sempre há a dúvida se é feita ou não no XP. Sim é feita mas como complemento, somente o necessário, depois da iteração terminada e mostrado algum resultado para o cliente (interface do software) e ele afirmar que é realmente o que ele procura. A própria classe, se for bem feita é facilmente compreendida por um desenvolvedor experiente, que já pode ser considerado um documento que nunca fica desatualizado. Mas sabemos que também é importante dependendo da complexidade do software complementar com por exemplo um diagrama de classes ou um diagrama ER para obter facilmente uma visão geral do sistema, mas eles são utilizados primeiramente para planejar (tentar encontrar as melhores combinações em um nível de abstração mais alto) e consequentemente como documentação. Outro fator que complementa a documentação são os testes automatizados TDD (Desenvolvimento Orientado a Teste) que no caso específico dos testes unitários são rotinas para verificar se determinada classe terá um funcionamento adequado ou não, dando uma garantia melhor para que seja evitado falhas. Para garantir a integridade dessas práticas voltadas “mais para o software menos para os documentos”, utiliza-se as técnica de refatoração com o objetivo de deixar o código cada vez mais simples, sem modificar a execução e programação em pares que consegue diminuir a quantidade de falhas que um programador individualmente poderia cometer além de propagar o conhecimento sobre o software de uma forma que se torne responsabilidade de cada membro da equipe, não somente de indivíduos isolados.

Para fechar digo também que as práticas do XP não devem ser tomadas como imposições necessárias para obter sucesso. Elas podem e devem ser modificadas dependendo do contexto, podem ou não ser usadas em conjunto. Elas devem ser tomadas como princípios que podem ser aprimorados.

Bom, fico por aqui, até o próximo “Pense nisso”.
Para saber mais sobre XP e metodologias ágeis acessem os seguintes links:

• 
  Dissertação de Vinicius Teles e um extenso material de divulgação do XP e suas práticas
• Podcasts tudoquequerosaber sobre desenvolvimento ágil
• podcast da improvit sobre Extreme Programing
• Podcast da Cooperativa de Desenvolvimento Ágil de Software – Agilcoop