Apresentação sobre Agile na Câmara dos deputados

Faz tempo que não reservo um tempinho pra escrever por aqui. Estou cheio de assuntos engatilhados, mas tenho andado meio comprometido demais com coisa demais... :-P

Assim que der eu volto a escrever com mais regularidade.

Por enquanto, aproveito pra deixar publicada aqui essa filmagem que o pessoal fez da palestra que apresentei na Câmara semana passada. Aproveito pra agradecer a gentileza do pessoal ter filmado e me passado.

.

Patterns e XP

Ainda traduzindo...

O exemplo do JUnit me leva inevitavelmente a trazer à tona os patterns. A relação entre patterns e XP é interessante, e é uma questão comum. Joshua Kerievky argumenta que patterns são pouco enfatizados em XP e ele coloca seu argumento eloquentemente, de modo que não preciso repeti-lo. Mas vale notar que para algumas pessoas patterns parecem ser conflituosos com XP.

A essência desse argumento é que patterns são frequentemente usado em excesso. O mundo está cheio de programadores legendários, frescos de sua primeira leitura do GOF que aplicam dezesseis patterns em 32 linhas de código. Me lembro uma tarde, movido por uma deliciosa puro-malte, planejando com Kent um artigo a se chamar "Not Design Patterns: 23 truques baratos". Estávamos imaginando coisas como usar um IF ao invés de uma estratégia. A piada tinha um fundo de verdade, patterns são frequentemente usados em excesso, mas isso não faz deles uma má idéia. A questão é como você os usa.

Uma teoria sobre isso é que as forças do design simples o levarão aos patterns. Muitos refactorings fazem isso explicitamente, mas mesmo sem eles, seguindo a regra do design simples, você chegará aos patterns mesmo que você ainda não os conheça. Isso pode ser verdade, mas será que essa é realmente a melhor forma de fazer isso? É claro que é melhor se você já souber de antemão aonde está indo e se tiver um livro que possa te ajudar com as dificuldades, ao invés de ter que inventar isso tudo por conta própria. Eu certamente ainda vou ao GOF sempre que percebo um pattern surgindo. Para mim o design efetivo implica que precisamos saber o preço que vale a pena pagar por um pattern - isso é sua própria habilidade. Similarmente, como Joshua sugere, precisamos estar mais familiarizados sobre como derivar um pattern gradativamente. A esse respeito XP trata o modo como usamos patterns de modo diferente do usual, mas certamente não remove seu valor.


Mas lendo algumas das listas de e-mail eu tenho o sentimento distinto de que muitas pessoas acham que XP desencoraja patterns, apesar da ironia que a maioria dos proponentes de XP foram lideres do movimento de patterns também. Isso é porque eles viram além dos patterns, ou porque os patterns estão tão impregnados em seus pensamentos que eles nem percebem mais? Eu não sei a resposta para os outros, mas pra mim patterns ainda são vitalmente importantes. XP pode ser um processo para desenvolvimento, mas patterns são a espinha dorsal do conhecimento sobre design, conhecimeno que é valioso tanto quanto o processo. Processos diferentes podem usar os patterns de modos diferentes. XP enfatiza tanto a não utilização de patterns até que eles sejam necessários como evoluir o código do seu modo derivando um pattern por meio de uma implementação simples. Mas patterns são ainda uma peça chave de conhecimento a se adquirir.

Meu conselho aos XPeiros usando patterns seriam:

* Invistam tempo aprendendo sobre patterns
* Concentrem-se em quando aplicar o pattern (não tão cedo)
* Concentrem-se em como implementar o patterns em sua forma mais simples primeiro, então adicione complexidade depois.
* Se você utilizar um pattern, e depois descobrir que não valeu a pena - não tenha medo de tirar ele fora de novo.

Eu acho que XP deveria enfatizar mais o aprendizado sobre patters. Não sei ao certo como encaixaria isso nas práticas de XP, mas tenho certeza de que o Kent pode descobrir um jeito.

Maré de Agilidade - Swell Salvador

Opa,

Só pra avisar que vamos fazer o MaréDeAgilidade versão Salvador-BA.

Ô meu rei, num deixe de participar! :-)

Visão de futuro

Incrível como a visão que tinham da internet em 1969 estava correta:



Me faz lembrar o primeiro MSX que tive... humm.. nem lembro quando... Devia ser 90, 91...



Me lembro exatamente a expectativa em que fiquei quando minha vó comprou pra mim um modem!

Qual não foi minha frustração quando descobri que só existiam 2 ou 3 serviços disponíveis que pudessem fazer uso do tijolo - que não tinha sido nada barato. Os serviços não eram ainda ligados em rede, a gente tinha que discar diretamente para o número do Bradesco, por exemplo.

E o diabo é que nenhum dos serviços eram úteis pra mim! :-P

Pra mim a internet já existia naquela época. Quando saí da loja com o modem debaixo do braço, tinha certeza abstoluta de que iria chegar em casa e visitar museus pelo computador, comprar vídeos, conhecer pessoas, criar coisas.

Embora a imagem que façamos do futuro não seja exata nos detalhes, simbolicamente parece que já sabemos pra que lado as coisas estão se encaminhando.

Que diabos é GTD?

Esse vídeo vale a pena ver... Seria ótimo se houvesse uma versão legendada por aí, embora o inglês dele seja bem fácil de entender...

O Video é longo, se tiver sem paciência, dê uma olhada nesse post, que traz uma "resenha" do video.

Refactoring viola YAGNI?

Continuando a tradução do MartinFowler...

Esse tópico surgiu na lista de XP recentemente, e é importante discuti-lo já que estamos revendo o papel do design em XP.

Basicamente, a questão começa com o ponto que refactoring toma tempo mas não adiciona funcionalidade. Uma vez que o ponto em YAGNI é que deveria-se projetar para o presente, não para o futuro, isso é uma violação?

O ponto em YAGNI é que você não adiciona complexidade que não é necessária para as histórias atuais. Isso faz parte da prática do design simples. Refactoring é necessário para manter o design o mais simples possível, então você deve refatorar sempre que perceber que pode tornar as coisas mais simples.


Design simples tanto explora as práticas de XP como é também uma prática habilitadora. Apenas se você tiver teste, integração contínua e refactoring, é possível praticar design simples efetivamente. Mas, ao mesmo tempo, manter o design simples é essencial para manter a curva de mudanças estável. Qualquer complexidade desnecessária torna o sistema mais difícil de mudar em todas as direções, exceto naquela em que você antecipou com a flexibilidade complexa que colocou. No entanto, as pessoas não são boas em antecipar, então é melhor esforçar-se pela simplicidade. Mas não se consegue a coisa mais simples de primeira, então você precisa refatorar para chegar mais perto do objetivo.

GTD.reset()

O final de 2008 (e o começo de 2009) estão sendo especiais pra mim. Cheguei no final do ano voltando de férias (viajei em novembro). Apesar de ter estado "aéreo" por um mês, quando voltei foi como se não tivesse ido. Todos os problemas vieram à tona novamente, e voltava aquele sentimento de sobrecarga, muitas coisas pra resolver, e tal. Estava eu novamente me segurando pra não explodir com o primeiro que chegasse com mais qualquer coisa pra resolver.


Poucos dias antes do natal, recebo a notícia de que as inscrições no mestrado da UnB terminariam no dia 06 de fevereiro (hoje). Naquele momento a noticia me caiu como uma bomba. Apesar das férias, meu cansaço intelectual era tanto que não cogitava nem de longe que fosse possível eu me inscrever a tempo. Pra se inscrever no mestrado a gente precisa ter um plano de pesquisa. (Já parou pra pensar o que é isso?) e pra isso, precisa de... ... ... um plano! Meu Deus!

Pra ter um plano, preciso ter um objetivo claro, preciso ter uma boa idéia do que a ciência anda pensando a respeito (ler muito), e... caramba! Nem sequer um tema eu tinha! :-o 1 mes de prazo, um saco (bem) cheio, e não mais que alguns interesses na manga... :-(

Foi aí que "sem mais nem menos" me volta à memória o GTD.

Durante todo o ano de 2008, eu fiquei.. hum... "brincando" de GTD - havia passado o olho no livro, achado o maior barato, mas não tinha lido de verdade, e achava que tinha entendido tudo só olhando as figuras. Té parece :-/

Mas então resolvi parar e ler o diabo do livro. Minha estratégia inicial era ler o livro todo, de cabo a rabo (como não costumo fazer) e entender o todo. Depois via como fazia.

Antes da metade eu não pude mais me conter, joguei o livro de lado e comecei a coletar minhas coisas.


O resto da história eu conto com calma, em outros posts.

O importante é que estou comemorando hoje não a inscrição no mestrado (pois o resultado sai só na semana que vem), mas o cumprimento de uma meta que pelo menos pra mim foi maravilhosa. Um mês depois, estou me sentido leve como poucas vezes na vida. Meus compromissos estão todos (absolutamente todos) sob controle e meus fins de semana estão sendo tão profundos que é como se estivesse de férias.