Agilismo em perigo?

Há poucos dias James Shore, um dos grandes nomes do agilismo mundial (autor do ótimo The Art of Agile Development), escreveu um polêmico post em seu blog, chamado "The Decline and Fall of Agile" e suscitou um monte de polêmica. Eu concordo com o que ele escreveu em praticamente tudo.

Meses atrás, o Ivan Sanchez havia levantado, ainda que de modo menos incisivo, a mesma coisa em seu blog em português. Hoje, ele voltou a postar reivindicando o pioneirismo e reafirmando suas posições. Neste post há também links para a repercussão do artigo do Shore na blogosfera brasileira. Aliás, o post também traz a promessa de se manter atualizado quanto aos links para a repercussão, portanto fique de olho.

O Uncle Bob (Robert C. Martin) também se manifestou a respeito, discordando em certa medida das posições de Shore.

Pessoalmente, tendo a concordar com o Shore. A culpa não é do Scrum, certamente. Mas agilismo é como uma faca: é um excelente instrumento, mas não é bom que fique nas mãos de crianças nem de psicopatas. O problema é que Scrum, por ser fácil de compreender e ter forte apelo gerencial, tem sido vendido e comprado por crianças (sem avisar que elas deveriam crescer antes de utilizar) e psicopatas (sem um devido tratamento psiquiátrico). E aí não há boa vontade que impeça a faca ágil de fazer o que não deveria: mutilar o próprio usuário e qualquer um que esteja por perto.

leia isto >> Iterações pra que te quero

_{Na seção "leia isto", linkarei bons textos e posts relacionados ao tema do blog.}

http://blog.thiagoarrais.com.br/2008/10/02/iteracoes-pra-que-te-quero/

Quando chegarmos a este ponto, será que deveríamos parar aí? A beleza deste processo de encolhimento das iterações é poder continuar diminuindo-as. Iterativamente, se você me permite. O limite será alcançado quando em uma iteração couber somente um requisito. Neste ponto, a única maneira de continuar encolhendo as iterações é encolher os próprios requisitos, tornando-os cada vez mais simples e atômicos.

Mas será que sua organização vai ter coragem para chegar lá?

Passos de bebê

Na lista de discussão do núcleo de pesquisa de que faço parte, surgiu uma polêmica a respeito do uso da técnica de passos de bebê. Resumindo a história, alguém estranhou os passos minúsculos preconizados pela literatura de TDD. Por exemplo, em se tendo apenas o teste (em Java):

Template template = new Template("#{tecnica-agil} é legal!");
template.set("tecnica-agil", "TDD");
assertEquals("TDD é legal!", template.parse());

a implementação seria necessariamente

...
public String parse()
{
return "TDD é legal!";
}
...

Bom, vamos à minha visão da coisa toda: a técnica de "passos de bebê" serve para evitar complexidade desnecessária, como generalização prematura e overengineering. O tamanho do passo - o que parece ser o centro da polêmica - deve ser baseado no bom senso e no quanto é confortável para o desenvolvedor. Se um desenvolvedor ou par se sente confortável em utilizar a técnica de modo mais ortodoxo, ótimo. Se não, é uma questão de ajuste fino. Eu, por exemplo, normalmente utilizo passos um pouco (mas não muito) maiores, exceto quando o domínio é pouco conhecido.

Os passos de bebê estão diretamente ligados a Test-Driven Development. Em TDD, a implementação deve ser unicamente aquela suficiente para passar nos testes, e nada mais. Deste modo, os passos de bebê não estão na implementação, mas na elaboração dos testes. Caso se queira que os passos sejam maiores, basta aumentar a granularidade dos testes unitários. Escrever um teste apenas para, por exemplo, uma entrada "N" e implementar uma solução genérica para o alfabeto inteiro é algo que contraria diretamente os princípios do agilismo (ou seja, da engenharia de software moderna), é implementar a solução para um problema ainda não formulado. Do ponto de vista da programação, os testes unitários são a especificação de requisitos. Assim, uma solução geral para o alfabeto inteiro com um teste só para "N" recairia em uma das duas situações: (1) ou há implementação desnecessária, ou seja, desperdício e complexidade inútil ou (2) o conjunto de testes é deficiente, o que mostra requisitos mal formulados e pode ter consequências ruins como bugs de regressão.

A questão é que a implementação tem que ser a coisa mais simples (sem ser simplória, já dizia Einstein) que possa passar nos testes (e uma cascata de if-elses é tosqueira, não simplicidade). Se você consegue ter uma função que passa nos testes com um mero return "n", o problema está em um conjunto fraco de testes. A implementação está correta, pois cumpre os requisitos (testes unitários) de modo claro, simples, rápido e manutenível.

Toda e qualquer prática ágil deve estar ancorada em princípios e valores. No caso em questão, o valor é a já citada simplicidade, traduzida nos lemas KISS e YAGNI. Os passos de bebê asseguram que o software terá apenas a complexidade necessária e nada mais.

Olá mundo!

Esta é a estréia do blog. Por aqui teremos, certamente com periodicidade halleyana, programação em geral, orientação a objetos, metodologias ágeis e devaneios relacionados.

Que ninguém espere nada de revolucionário ou impressionante feito aqui. Coisas assim aparecem nos links aí do lado e na seção leia isto. Por aqui só tijolinhos sem muita importância. Até breve!