07 dezembro 2008

A Guerra Ágil (ou "Outras Verdades Inconvenientes")


Até que ponto os debates e críticas dentro da própria comunidade ágil devem ser encarados como picuinhas e sopas de letrinhas, e a partir de onde se tornam pertinentes e transformadores? Que questões estão envolvidas? Quem vence, quem perde?

Nas últimas semanas temos assistido a uma verdadeira guerra de palavras, confrontando as metodologias que normalmente se associam ao movimento Agile, como um todo. Resolvi analisar as principais críticas e discursos que se observa pela comunidade a esse respeito (me posicionando) e argumentar, principalmente, a favor da preservação do debate (que não precisa ser uma "guerra") como instrumento de reflexão construtiva e aprendizado coletivo da nossa comunidade.


Passei o último mês de férias, por isso não tenho escrito muito. Apesar disso, estive acompanhando toda movimentação na comunidade e até participei de uma ótima discussão em uma lista de email (embora alguns colegas da lista pareçam não ter gostado muito).

O que me pareceu mais relevante, durante esses dias, foi um foco no que vou passar a chamar "a guerra ágil". Talvez o ponto mais alto das últimas batalhas tenha sido o post do James Shore, e toda a repercussão que isso teve (pelo menos na blogosfera brasileira). Só pra não deixar de me posicionar sobre esse episódio, achei o post fantástico! Gostei especialmente porque noto muita relação com o que escrevi sobre Scrum e XP. Diferentemente do que algumas pessoas interpretaram, acho que a crítica dele está bem mais relacionada ao modelo de negócios por traz do Scrum, do que ao método em si.

Afinal de contas, de quem é a responsabilidade, pelos efeitos colaterais da estratégia de marketing por traz do Scrum? Ouvi a pouco tempo uma das pessoas mais envolvidas com Scrum no Brasil reconhecer com todas as letras que a certificação de Scrum Master não certifica nada... O que é que falta então? Alertar o "consumidor" ?

o ministério da ciência e tecnologia adverte:
o certificado de Scrum Master não certifica nada.
(O nome CertifiedScrumMaster é mera conhecidência.)

Não que o certificado seja a raiz do problema ou coisa parecida, mas faz parte de todo um modelo de negócios que tem contribuido surpreendentemente com a popularização de Agile, mas que tem sido irresponsável (ou no mínimo desatento) com outras questões subliminares.

Não podemos esquecer também da publicação do relatório do SEI sobre CMMI e agilidade, que também deu o que falar!

Recentemente li ainda uma discussão na agile-brasil (e outras) sobre um "ataque" de FDD a XP, que rendeu um post desaforado do Milfont.

Sendo curto e grosso: o bixo tá pegando!

Ao invés de me posicionar a respeito de cada evento desses, isoladamente, preferi escrever um ponto de vista mais amplo sobre a tal guerra.

Dou-me a liberdade de concordar primeiramente com a posição do Al Gore a respeito da convivência entre os costumes antigos e os novos valores da comunidade global. Enquanto um baseou-se na mecanização, produção em larga escala, desenvolvimento tecnológico e econômico, o outro clama por um pensamento mais holístico, que valoriza a sustentabilidade do sistema, e coloca em cheque vários costumes básicos da sociedade moderna, guiada pelo consumo.

A posição dele a respeito dessa mudança de pensamento - segundo um amigo me explicou - é que se trata de uma espécie de "evolução" do pensamento (não necessariamente linear) que engloba e supera as ideologias e concepções atuais. Mas isso não implica, de forma alguma, na classificação dos valores antigos como "maus" ou "ruins", simplesmente. Não se trata de separar o que é bom do que é ruim. O pensamento anterior foi importantíssimo, por bastante tempo. E continua sendo, mesmo porque - mas não apenas por isso - nos serve em análises, comparações, críticas, analogias, etc. (Foi um pouco disso que eu quis expressar quando escrevi sobre agile e pmbok).

O mesmo acontece com Agile. Não é simples como dizer "XP é bom, FDD é ruim". Do ponto de vista prático, a posição mais sensata que ouvi foi a do AlissonVale. Entenda todos os pontos de vista, e aplique aquilo que for mais apropriado ao contexto específico de cada projeto. Nomes e siglas não importam muito mesmo... (Acho que é a opnião do FelipeRodrigues também, BTW) Pelo menos não importam muito (ou não deveriam importar) na prática, no dia a dia de um projeto ou de uma organização.

Mas sob outros pontos de vista (metodológico, comercial, cultural, ideológico, ético) acho a discussão e o confronto dos métodos muito pertinentes e bem vindos. Porque evitar o debate?

Conflitos e divergências são oportunidades de aprendizado!

O que acontece, na maioria das vezes, é que as pessoas se sentem ameaçadas - principalmente por já estarem comprometidas demais com alguma posição, organização, aliança - e não quererem "largar o osso"... Não dão o braço a torcer, e preferem evitar a discussão. Agora, rabos presos e egocentrismos a parte, qual o problema em confrontarmos as ideias e investigarmos as "causas raizes" das discordâncias?


Também não acho que invalida a discussão a posição de que Agile está além dos métodos, pois é um conjunto de valores e princípios; uma postura diante do trabalho, mais que uma forma específica de se trabalhar. Isso tudo é bem verdade! É totalmente viável e benéfico que se agregue valores ágeis a um projeto cascata, tradicional. E é perfeitamente possível também que um projeto XP falhe categoricamente, se levar em conta apenas as práticas, deixando os valores de lado. Seja como for, os métodos existem, são estudados, aplicados e estão no cerne dos projetos, influenciando e contribuindo com a formação da cultura da equipe e da organização, e consequentemente com sua postura. Portanto, a discussão sobre os métodos, por si só, já é relevante o suficiente.

Procuremos a bala de prata para cada caso específico, como o Milfont muito bem colocou.

O último argumento contrario à discussão que quero citar - e aquele com que mais discordo - é o de que nós, agilistas, devemos nos unir, juntar forças, pois nosso inimigo comum, na verdade, é o cascata. Oras, vai catar coquinho! - como diria minha vó... Isso aqui não é jogo de futebol, briga de torcida, nem brincadeira de polícia e ladrão. Aproveitemos os diversos pontos de vista para desenvolver uma nova visão, ao invés de nos conformarmos com as picuinhas infantis, apenas.

Há muito para ser discutido. Afinal de contas, por trás das siglas e nomes existem outros aspectos, além do que se costuma enxergar. Intenções, interesses, estratégias, política, disputa de mercado, egocentrismo, vaidade, e nem sei o que mais... Cabe a cada um julgar e separar o que se trata apenas de picuinhas infantis e o que são questões pertinentes e construtivas, embora incovenientes para alguns.

05 dezembro 2008

O que diabos é a simplicidade, afinal ?

Ainda traduzindo...
Então queremos que nosso código fique o mais simples possível. Não parece muito difícil argumentar a favor disso, afinal, quem quer ser complicado? Mas é claro que isso levanta a questão "O que é simples?"

No XPE Kent indica quatro critérios para um sistema ser simples. Em ordem (o mais importante primeiro):

* Executa todos os Testes
* Revela toda sua intenção
* Não há duplicação
* Menor número de classes e métodos

Executa todos os testes é um critério bastante simples. Sem duplicação é também bem direto, embora um monte de desenvolvedores precisem de orientação sobre como atingi-la. O mais estranho tem a ver com revelar a intenção. O quê exatamente isso significa?

O valor básico aqui é a clareza do código. XP atribui um alto valor ao código que é fácil de ler. Em XP "código claro" é um termo em abuso. O que é a intenção de uns revelando código é a clareza para outros.

Em seu artigo da XP 2000, Josh Kerievsky aponta um ótimo exemplo disso. Ele analisa possivelmente o código XP mais público de todos - JUnit. Junit usa decoradores para adicionar funcionalidades opcionais aos casos de teste, coisas como sincronização concorrente e código de setup de batch. Separar esse código em decoradores permite que o código genérico seja mas claro do que ele normalmente seria.

Mas você deve perguntar-se se o código resultante é realmente simples. Pra mim é, mas eu sou familiarizado ao padrão de decoradores. Mas para muitos que não são, é bastante complicado. Similarmente JUnit usa métodos plugáveis que, conforme notei, a maioria das pessoas iniciantes acha qualquer coisa, menos claro. Então devemos concluir que o design do JUnit é mais simples para designers experientes, mas mais complicado para pessoas menos experientes.



Eu acho que o foco na eliminação de duplicação, tanto do "Once and Only Once" do XP, como do DRY (Don't repeat yourself) do Pragmatic Programmer, é uma daquelas óbvias e maravilhosamente poderosas peças de bom conselho. Apenas seguindo ela sozinha já pode te levar bem longe. Mas isso não é tudo, e simplicidade é ainda uma coisa complicada de encontrar.

Recentemente, estive envolvido fazendo algo que bem poderia ser over-designed. O código foi refatorado e certa flexibilidade foi removida. Mas, como um dos desenvolvedores disse, "é mais fácil refatorar código over-designed do que refatorar código sem design." É melhor ser um pouco mais simples do que você precisa ser, mas não é um desastre ser um pouco mais complicado.

O melhor conselho que já ouvi sobre isso vem do Tio Bob (Robert Martin). Seu conselho era não ficar muito preocupado com o que é o design mais simples. Afinal você pode, deve e vai refatorar ele depois. No final a disposição para refatorar é muito mais importante que saber qual o design mais simples de primeira.