Danilo Sato

Muitas coisas aconteceram no último dia da main track: painel de discussão sobre certificações, artigos científicos, painel de discussão sobre “melhores práticas”, DSLs e keynote do Kent Beck. No terceiro dia de conferência diversos tópicos foram abordados e, daqui pra frente, participarei apenas de tutoriais e workshops, então espero que a densidade dos posts diminua :-)

Painel de Discussão sobre Certificação

 

Certificação no mundo ágil é um assunto que está na moda. A Agile Alliance anunciou recentemente sua posição sobre o assunto; Scott Ambler colocou sua opinião a favor num artigo da DDJ; além disso, muitos debates vêm acontecendo nas diversas listas de discussão, como scrumdevelopment@Yahoo, extremeprogramming@Yahoo e na nossa XP@Rio. A opinião dos participantes do painel estava dividida entre:

 

• Contra: Joshua Kerievsky e David Hussman
• A Favor: Jeff Patton e Boris Gloger
• Em cima do muro: Rachel Davis, representando a Agile Alliance

Uma das grandes discussões girou em torno do Certified Scrum Master. Joshua e David argumentaram que é um excelente treinamento (eu concordo), porém dá um título muito poderoso (para o observador desatento) para um curso de 2 dias sem uma prova no final. Em outras palavras, empresas procuram SCMs sem saber o que eles tiveram que fazer para se tornar um (está escrito na descrição do curso na Scrum Alliance). Do outro lado o Boris argumentou que, apesar de ser sim uma ferramenta de marketing (muito eficiente, por sinal), foi um programa que propiciou a criação de uma enorme comunidade interessada no Scrum e que, de uma forma ou de outra, contribuiu para o aumento na adoção dos Métodos Ágeis na indústria. Sobre esse tópico, estou um pouco mais pendente pro lado contra (apesar de ser um SCM) devido à fragilidade da nossa indústria. Infelizmente as empresas buscam profissionais certificados sem saber o que os torna certificados. Apesar disso, concordo com o argumento do Boris de que a formação de uma comunidade é importante. Acredito que uma estratégia de longo prazo para popularização dos Métodos Ágeis não deve ser tão ambiciosa a ponto de querer atingir quantidade e qualidade ao mesmo tempo. Olhando por esse lado, acredito que é mais fácil (e natural) conseguir a quantidade antes da qualidade. Por isso, acho que os treinamentos de SCM são importantes.

Dentre outras discussões sobre o tema, surgiu a idéia de ter uma “certificação” ágil mais parecida com o que fazemos na universidade: um curso muito mais longo, muito mais abrangente e que fornece uma base comum de conhecimento para que o aluno possa evoluir. Quando um aluno se forma na graduação, não espera-se que ele saia totalmente proficiente. Existe um consenso de que a experiência trará benefícios. Gostei dessa idéia de uma “faculdade ágil”. :-)

Outro ponto interessante da discussão foi a separação entre habilidade e certificação (ou treinamento). Ter uma certificação ou participar de um treinamento não é garantia de que o participante irá adquirir a habilidade necessária. Isso pareceu ser consenso. O único ponto do Joshua foi que ele prefere chamar isso de treinamento ao invés de certificação, pois é mais realista. Por outro lado, o Boris argumentou que qualquer programa de certificação gera um mercado mais atraente para empresas.

Outros assuntos interessantes foram abordados na discussão, mas esse espaço é muito curto (e minhas anotações muito sucintas) para expor de forma adequada. Acho que a discussão está boa e deve continuar…

Artigos Científicos

 

Após o debate, houve uma sessão de apresentação de artigos científicos, dentre eles o meu. Confesso que fiquei um pouco nervoso por ter que apresentar em inglês e um pouco mais nervoso quando vi o Kent Beck na platéia. Mas isso passou assim que comecei a falar (como costumava acontecer quando tinha que tocar piano na frente dos outros.. he he) e acho que correu tudo bem. Após a sessão fui conversar com o Kent Beck (sobre outro assunto) e ele me disse que gostou da minha apresentação, o que me deixou muito orgulhoso :-)

 

Dentre os outros papers apresentados, teve um que não gostei (nem o Boris.. he he) sobre um meta-modelo para modelar e medir a eficácia de processos ágeis. O exemplo usado foi o Scrum e me pareceu uma tentativa de fazer um framework-de-processos(RUP)-ágil-genérico, onde outras metodologias ágeis poderiam ser “instanciadas”. Enfim, não deu pra entender muito bem a motivação para usar aquilo (e eu também tenho um certo preconceito quando começam a falar de processos com caixinhas parecidas com UML, setinhas e coisas <<entre símbolos estranhos>>).

 

Por outro lado, os outros dois papers foram bem mais interessantes. O primeiro foi sobre o FitClipse, um plugin do Eclipse para execução e edição de testes de aceitação do FIT. Ele roda em cima do FitNesse e permite a distinção entre testes que falham por motivos aceitáveis (ainda não foram implementados) ou por motivos inaceitáveis (já foram verde e ficaram vermelho depois de um tempo), além de mostrar uns gráficos bonitinhos. O outro foi sobre o EzUnit, uma extensão do JUnit que permite a identificação mais precisa de qual pedaço de código pode ter causado uma falha. O framework permite a definição do(s) método testado(s) (Method Under Test ou MUT) com anotações (isso achei estranho) ou, para quem é preguiçoso como eu, escreve as anotações através de análise estática e dinâmica do código. Gostei da idéia, mas não tanto dessa parte das anotações/análise estática. Concordo com o comentário do Kent Beck no final de que a análise dinâmica, associada aos deltas das mudanças efetuadas mais recentemente, dão uma informação muito boa sobre onde uma possível falha pode estar localizada. Além disso, linguagens dinâmicas não permitem análise estática de qualquer forma. Acho/espero que no futuro vamos usar testes unitários como “compiladores” e ferramentas como essa podem facilitar a vida.

 

Painel de Discussão sobre “Melhores Práticas em Software”

 

Antes de mais nada, uma colocação da Mary: “Não existe uma MELHOR prática”. A partir do momento que consideramos algo como o melhor, deixamos de pensar em formas de melhorar, afinal de contas já temos O MELHOR. Muito bem colocado e os presentes no painel concordaram: Giancarlo Succi, Jutta Eckstein, Robert Beedle e Yael Dubinsky.

 

Os “painelistas” (como se escreve isso em português?) mostraram uma preocupação na definição e escolha de práticas muito técnicas. A agilidade propõe aspectos humanos que dificilmente são expressados em práticas específicas. Por outro lado, medir e avaliar a adoção de princípios e valores é complicado. Robert Beedle defendeu o ponto de que a prática mais importante é a colaboração. Ela inclui os valores humanos e dirige o resto do processo na direção certa. Segundo ele, sua primeira impressão sobre XP foi positiva pois servia como uma ferramenta cognitiva para compartilhamento de conhecimento que, mesmo sem saber explicar muito bem como, fazia com que as coisas certas acontecessem. Em outras palavras, se você seguisse as práticas (e suas sinergias e valores embutidos), você seria capaz de dirigir a produção do software certo, ao contrário da abordagem da engenharia de software tradicional que busca a forma certa de produzir software. Produzir certo vs. Produzir o software certo. Conceitos bem diferentes.

 

Por fim, houve uma discussão sobre como medir o sucesso nos projetos. O Giancarlo defendeu o ponto de que é preciso utilizar métricas e objetivos claros para avaliação do sucesso. Num debate sobre o valor de métricas quantitativas e qualitativas, Robert Beedle disse que para medir o lado humano dos Métodos Ágeis, métricas qualitativas são a única solução. Por outro lado, Giancarlo disse que é mais fácil entender dados quantitativos, apesar de serem facilmente manipuláveis ou mal-interpretados.

 

Birds of a Feather: Domain Specific Languages – Emily Bache

 

Apesar de não constar na programação oficial, a Emily havia mandado uma proposta de workshop que foi recusada e, mesmo assim, decidiu fazer uma sessão aberta para interessados em discutir DSLs. Eu achei muito louvável a atitude e, como não programaram nenhum Open Space na conferência desse ano, também demonstrou o poder da comunidade em adaptar o programa e compartilhar conhecimentos.

 

Nesse workshop, discutimos o conceito de uma DSL que, para minha surpresa, não era consenso. Eu ainda não tive muitas experiências utilizando uma DSL numa situação onde precisei de verdade, a não ser na definição de testes de aceitação. Porém, como disse para os participantes, já houve momentos na minha carreira (antes de saber o que era XP) onde consigo ver uma DSL ajudando a diminuir a distância entre especialistas e programadores. Após diversas discussões surgiram alguns aspectos do que seria uma DSL:

 

• Uma DSL deve maximizar a densidade semântica: em outras palavras, dependendo do público-alvo (os especialistas no domínio), usar muitos parênteses e símbolos de programação podem atrapalhar a legibilidade (particularmente em DSLs internas).
• Uma DSL deve ser executável: isso inclui a habilidade de edição e execução na frente do especialista do domínio, trazendo feedback imediato.
• Deve ser fácil e rápido alterar uma DSL: em outras palavras, o especialista de domínio deve ser praticamente capaz de escrever na DSL (ler é mais fácil que escrever).

Ainda no tópico da densidade semântica, houve uma pequena discussão sobre se uma DSL deve ou não ser obrigatoriamente legível para o cliente (ao invés do programador). Nesse caso, o rake não seria uma DSL.

Keynote de encerramento: Ease at Work – Kent Beck

 

Para não tornar um post longo ainda mais longo, não vou me estender muito sobre esse keynote. Kent Beck é O CARA. E dessa vez, ao invés de falar sobre aspectos técnicos, metodologias ou empresas, ele deu uma palestra quase como psicólogo (tudo bem que a esposa dele é psicóloga), para tentar fazer-nos refletir sobre nosso papel como programadores e como encaramos nosso trabalho. Em outras palavras, como fazer com que possamos nos sentir bem com nossas qualidades e defeitos?; como conviver e aceitar que não estaremos sempre no auge ou na lama?; como sair do trabalho com a consciência tranquila de que demos nosso melhor?; Como sustentar mudanças?; Como sermos mais responsáveis e transparentes no trabalho?

 

Como disse, espero que o post de amanhã seja mais resumido pois também cansa escrever esses relatos… brincadeira :-)

 

Lean, velocidade, Ferrari e computadores quânticos foram alguns dos temas do meu segundo dia na XP2007: uma palestra pela manhã, a main track começando durante a tarde e muitas coisas interessantes acontecendo.

Lean Software Development – Mary e Tom Poppendieck

Minha programação do dia era assistir outra palestra, sobre Anti-Padrões em Métodos Ágeis, porém o palestrante não conseguiu chegar a tempo em Como. Isso não é um grande problema para alguém ágil, afinal um plano é apenas um plano, certo? Fui então assistir o tutorial excelente sobre Lean Software Development. Apesar de já ter participado da sessão dos mesmos autores na Agile 2006, pude vivenciar na prática a construção e a análise de um Value Stream Map, uma ferramenta muito boa para encontrar desperdícios em um processo.

Um dos tópicos interessantes discutido no tutorial foi levantado por alguém da platéia e se encaixa perfeitamente numa das recentes discussões na XP@Rio: “O que levar em consideração no cálculo da velocidade?”. Assim como eu disse, a Mary argumentou que a velocidade é uma medida de capacidade (eu chamei de cadência) e, portanto, todo tempo que é gasto durante a iteração deve ser levado em consideração: seja com design, teste, desenvolvimento, integração ou tirando dúvida com o cliente. A velocidade é uma medida da capacidade da equipe para entregar software funcionando no final da iteração (ou release). No contexto Lean, ela serve como ferramenta para cortar desperdícios. Se sua “lista de coisas a fazer” é maior que sua capacidade de entrega, então você pode estar desperdiçando tempo gerenciando coisas com baixa prioridade. O conselho da Mary é que essa lista não tenha mais trabalho do que a equipe consegue entregar nas próximas 2 ou 3 iterações.

Se a sua capacidade de entrega (velocidade) é a segunda seta, não faz sentido querer entregar (ou gerenciar) a primeira seta. Ao final do tutorial, fui falar com ela sobre nossa discussão e eis o que ela me disse:

• Sim, bugs definitivamente devem ser contados na velocidade pois impactam a capacidade de entrega freqüente de software.
• Defeitos não devem ser tolerados. Um processo que permite defeitos é um processo defeituoso. Se você chegar em qualquer linha de produção (manufacturing) e disser isso, eles irão concordar facilmente. No mundo do software isso ainda não aconteceu.

Dentre outros tópicos interessantes que foram levantados no tutorial, destaco mais um: a importância de Respeitar as Pessoas. O Teste de Litmus deve dar uma boa idéia sobre a motivação de seus funcionários: “Quando alguém está chateado com alguma coisa no trabalho, ele reclama, ignora ou tenta arrumar?”. Ainda nessa discussão, Mary falou sobre o papel dos padrões numa empresa Lean: “Padrões são feitos para serem questionados. Servem apenas como base para mudanças”. Na sua empresa, padrões são impostos ou desafiados? (não responda se não quiser – ou não puder) :-)

Keynote: The grand-prix starts at 2 o'clock – A race to race software development eXPerience – Piergiorgio Grossi

No keynote de abertura, o CTO da Ferrari (sim, a equipe de corrida na Fórmula 1) apresentou como eles usam XP para gerenciar seus (diversos) projetos. Apresentaram algumas coisas interessantes como a urgência das coisas (mudança é uma constante. A cada corrida os clientes mudam suas prioridades), a dificuldade de determinar os testes de aceitação (o cliente nem sempre sabe exatamente o que quer. Ex: “Nosso software de estratégia de corrida deve levar em conta a nova regra e devemos usar os 2 tipos de pneu durante a corrida”) e os desafios de lidar com um número pequeno de programadores e diversos projetos (segundo eles, uma taxa de 1:5).

Artigos, Painel de Discussão e Outras Coisas Mais…

O resto da tarde foi bem variado. Assisti algumas apresentações de artigos publicados (para ter uma idéia do tempo disponível e para me preparar para apresentar o meu amanhã). Outra parte interessante foi um painel de discussão aberto, no estilo fishbowl. Para quem não conhece, é um estilo de discussão onde as pessoas levantam tópicos e um moderador escolhe o primeiro a ser discutido. Quem estiver interessado em discutir vai ao centro (daí o termo “aquário”) e discute. Qualquer um pode entrar ou sair em qualquer tópico. Após um tempo pré-determinado, o moderador pergunta se a platéia quer continuar a discutir o mesmo tema ou trocar (cada um tem um post-it vermelho e um verde para votar). Nessa discussão aberta surgiram alguns tópicos interessantes:

• Agilidade e valor de negócio: cheguei um pouco no meio da discussão, mas uma frase impactante veio do Joshua Kerievsky: “Agile is Dead”. Mais sobre o assunto daqui a pouco.
• O futuro ágil?: Acreditam que deve continuar existindo, assim como muitas coisas “velhas” ainda existem, como Cobol, sistemas legados, etc. Alguém levantou uma preocupação do Ken Schwaber em 2002 sobre o perigo das abordagens ágeis se tornarem tão rígidas, estruturadas e burocráticas como aconteceu com outras coisas.
• Como sustentar as mudanças propostas pelos Métodos Ágeis?: Citaram novamente a importância da motivação, contando a história dos trabalhadores quebrando pedras (não consegui achar uma boa referência, vou deixar a história nos comentários). Comentaram também sobre o perigo da desvalorização dos coaches e das empresas que deixam as práticas ágeis degradarem com o passar do tempo.

Por fim, foi proposto um novo formato de discussão: um “Agile Café” (ou, como alguns preferiram: “Agile Bar”). As pessoas sentam nas mesas do lado de fora do hotel para discutir qualquer assunto relacionado ao mundo ágil e quem estiver interessado pode se juntar e debater o assunto em questão. Se ninguém estiver discutindo, você pode sentar e esperar alguém aparecer para discutir o assunto que desejar. Logo após o fim da conferência, já fui participar de um e aproveitei bastante. Dentre algumas das discussões que tivemos, destaco:

• Agilidade não existe: existem diferentes “sabores” de metodologias. Você sempre discute com base nos sabores que conhece (ou experimentou). Como uma coisa que não existe pode viver (ou morrer)? :-)
• Evolução e Computadores Quânticos: apresentei a idéia do Dick Gabriel sobre design evolutivo (aquele que um humano não consegue explicar ou entender), seus paralelos com a biologia, algoritmos genéticos e tudo mais. Uma idéia interessante (viagem) que surgiu da discussão foi a utilização de TDD para definir o comportamento esperado do sistema e deixar que um algoritmo genético evolua uma solução aceitável. Claro que para evitar a explosão combinatória precisaríamos de computação quântica, mas não sabemos o que o futuro nos prepara. :-)

Mais um dia produtivo na Itália com muitas idéias e pessoas interessantes. Volto com mais novidades/relatos amanhã (ou hoje, se conseguir conexão no fim do dia).

Apesar de ler e concordar com o Thiago que esse tipo de post não é o ideal, meu blog se encaixa nessa categoria a maioria das vezes, portanto por que não continuar mais um pouco? :-) Prometo tentar melhorar depois dessa série. Além disso, sei que algumas pessoas vão se beneficiar desses relatos (me incluo nessa lista, pois esse tipo de registro já me foi útil em outras ocasiões e agora eu terei que escrever um relatório de qualquer jeito). Então, aproveitem os meus comentários sobre a XP 2007, diretamente de Como, na Itália.

Selling: How to Effectively Communicate the Value of Agility? – Joshua Kerievsky

Quem nunca teve problemas “vendendo” ou apresentando algumas das práticas ágeis para outras pessoas? Na AgilCoop eu me vi nessa situação diversas vezes: “Programação Pareada? Metade da Produtividade?”, “Parar para escrever testes e refatorar? Não posso parar, preciso entregar novas funcionalidades!”, e por aí vai. Por causa dessas e outras pré-concepções (não estou dizendo preconceito, muitas vezes eles são infudados), muitas pessoas resistem a mudanças.

No tutorial, Joshua, fundador da Industrial Logic e escritor do ótimo livro Refactoring to Patterns (que, por sinal, estou lendo agora), nos fez passar pela experiência da mudança através de uma pequena simulação, mostrando como mudar é anti-natural para as pessoas e como geralmente associamos mudança com a perda de alguma coisa (ao invés de ganho). Uma das discussões foi sobre a curva de mudanças de Virginia Satir, que diz que toda mudança leva um tempo para surtir efeito, passando por uma fase de caos antes de atingir um novo patamar, melhor que o anterior:

Através de algumas histórias sobre vendas bem e mal sucedidas, ele apresentou algumas das características de uma boa venda:

• Venda apenas o necessário: Isso inclui conhecer muito bem o problema e o contexto do seu cliente. Muitas vezes a solução para um problema pode ser obtida com custo reduzido se o verdadeiro problema é identificado. Quando a única ferramenta disponível é um martelo, todos os problemas se parecem com um prego.
• Venda riscos: ao invés de enfatizar os benefícios de uma prática ou outra, discuta com os interessados quais os riscos associados a não implementá-las.
• Compartilhe experiências: um gerente ou executivo não vai entender os benefícios dos testes automatizados, pois essa não é a linguagem que ele entende. Procure compartilhar vídeos, fotos e experiências de equipes que obtiveram sucesso, para que ele vivencie os benefícios.

Diversos outros assuntos e histórias foram compartilhados nesse tutorial, além de algumas boas recomendações de leitura: Selling the Invisible e The Secrets of Consultancy (esse eu já ouvi falar muito bem em diversos outros lugares).

Coder's Dojo: Acceptance-Test Driven Development in Python – Emily Bache and Geoff Bache

Nessa apresentação, em formato de Dojo, resolvemos parte de um problema do Ruby Quiz (Texas Hold'em) em Python, usando uma variação um pouco diferente de TDD, escrevendo os testes de aceitação antes. Nesse caso, o teste de aceitação final seria a saída esperada do programa, conforme a página de descrição no Ruby Quiz. Ao partir de cenários mais simplificados (porém ainda de aceitação) e utilizando o TextTest como ferramenta de teste, resolvemos parte do problema (infelizmente, o problema era grande demais para o tempo disponível). Algumas das minhas impressões da experiência:

• Como o exercício era relativamente simples comparado a um cenário real, os testes de aceitação, que escrevíamos incrementalmente, eram muito parecidos com testes de unidade. Apesar disso, os exemplos ainda estavam na “linguagem de negócio” do poker. Isso pode ter confundido um pouco algumas pessoas da platéia que não tinham experiência com TDD.
• Para quem tem experiência com TDD os passos pareciam um pouco grandes demais, apesar de ainda pequenos. Muitas vezes precisamos implementar muita coisa para fazer um teste de aceitação passar. Uma discussão interessante que tive depois da sessão, com o Emmanuel Gallot (fundador do Dojo de Paris, o mais antigo Dojo em funcionamento) e os apresentadores, percebemos que existem duas abordagens para aplicar TDD: enquanto alguns preferem escrever diversos testes de aceitação para “pedir” por uma implementação, outros preferem quebrar as necessidades que vão surgindo ao longo do caminho, e aplicar TDD separadamente para cada parte antes de integrar tudo no cenário de aceitação inicial. A primeira abordagem tem a vantagem de conectar toda funcionalidade com um teste de aceitação, enquanto a segunda acaba gerando diversos passos intermediários que, em muitas situações, são mais fáceis de acompanhar e fazem o design surgir da necessidade. Eu me identifiquei mais com a segunda abordagem, apesar de entender que é possível seguir outro caminho.
• O TextTest é uma ferramenta de teste em Python baseada na comparação de texto ou, em outras palavras, um teste baseado em diffs da saída do programa. Eu não conhecia a ferramenta e achei interessante duas práticas aplicadas pelos apresentadores (que estavam seguindo a primeira das abordagens que apresentei acima): em primeiro lugar, a ferramenta permite salvar a saída esperada de acordo com o que aconteceu (resultado da execução do teste). Isso permite que você diga que o resultado do teste que acabou de falhar, na verdade está correto. A princípio, isso me pareceu “roubar”, mas como a abordagem deles era diferente, permitiu que eles convivessem com a implementação atual, podendo refatorar no verde (no final da sessão, algumas pessoas disseram preferir uma cor amarela para essa situação. Eu concordo). A segunda prática é a utilização de logs nos cenários de teste. Como a ferramenta se baseia na saída de texto do programa, os apresentadores puderam testar passos intermediários com logs que “explicam” o que o programa está fazendo. Eu pessoalmente batizei a técnica de printf-debugging automatizado :-)

Bom, por hoje foi isso. Continuo com os relatos com o passar da semana. Se estiverem interessados em fazer alguma pergunta para alguém importante aqui na conferência, deixem um comentário que eu tentarei entrar em contato. Alguns dos nomes que podem interessar estão disponíveis no website da Conferência.

No último dia da conferência também estava cheio de trabalho agendado na parte da manhã e na parte da tarde.
As duas últimas sessões que participei foram também muito interessantes: refatoração de banco de dados e técnicas
eficientes para trabalhar com código legado. Para finalizar, uma última palestra no banquete servido a noite.

Refactoring Databases: Evolutionary Database Design – Scott Ambler e Pramod Sadalage

Essa palestra foi muito interessante. Ambos os apresentadores acabaram de lançar um
livro
sobre o assunto e falaram sobre como as pessoas do mundo dos bancos de dados estão atrasadas
em relação ao mundo “ágil”. Poucas ferramentas
existem para teste em banco de dados e, conforme os autores
comentaram, os bancos de dados relacionais já estão no mercado há muito tempo. Eles lançaram uma pergunta desafiadora:
“Você acha possível fazer uma mudança trivial no seu banco de dados atual, como mudar o nome de uma coluna, e implantar
essa mudança em produção no dia seguinte?”. Muitos dos presentes achavam muito difícil fazer essa simples mudança nas
empresas onde trabalham. Scott Ambler está
lançando uma série de pesquisas no site do Dr. Dobb's e uma delas é sobre
banco de dados ágeis. Os resultados serão publicados em Novembro e os dados estarão disponíveis no
site dele, porém ele disse que, apesar da maioria das pessoas afirmarem que
as informações armazenadas no banco de dados são consideradas ativos da empresa, poucos têm uma estratégia
para recuperação e manutenção dos dados em produção.

Durante o tutorial, Pramod mostrou exemplos de como trazer a evolução do
banco de dados para seu sistema de controle de versão (CVS, SVN, …) e como executar algumas das
refatorações propostas, integrando tudo com Ant e
Cruise Control.

Devemos dar a devida atenção para a integração entre as 2 comunidades (banco de dados e a comunidade ágil),
pois essa será uma área que receberá grande atenção nos próximos anos. Acredito que através da colaboração conjunta,
existe um grande potencial para o surgimento de novas ferramentas e processos que devem mudar a perspectiva
das empresas em relação ao assunto. E isso não deve acontecer num futuro tão distante. Para finalizar, uma foto
com os apresentadores:

Working Effectively with Legacy Code – Michael Feathers

Na parte da tarde eu fui auxiliar a sessão do Michael Feathers sobre o livro homônimo
“Working Effectively with Legacy Code”.
O tutorial começou com a sua definição de código legado: “Todo código que não tem teste”. Muito boa essa definição.
O resto da palestra foi sobre técnicas para conseguir colocar pedaços de código existentes numa suite de testes. Grande
parte do desafio nessa tarefa é conseguir instanciar objetos numa suite de teste, evitando operações
demoradas ou efeitos colaterais indesejados num teste de unidade. Alguns dos critérios que Michael propôs para saber quando
um teste de unidade não é eficiente são:

• O teste fala com o Banco de Dados
• O teste faz algum tipo de comunicação na rede
• O teste fala com o Sistema de Arquivos
• O teste não pode ser executado ao mesmo tempo que outros testes (dependência entre testes)
• Você precisa fazer alterações especiais no ambiente para poder executá-los

De modo geral, ele não quis dizer que você não deve testar coisas como acesso ao Banco de Dados ou Sistema de Arquivos,
mas sim que essas coisas fazem seu teste de unidade demorar para rodar. Testes de unidade devem rodar rápido. Ou melhor:
você considera o Banco de Dados parte da “unidade” que está testando?

A grande fonte de dificuldade quando você precisa lidar com código legado é que ele está muito acoplado ou dependente
de outras partes do código, tornando difícil instanciá-lo independentemente do resto no seu teste.
Michael mostrou
diversas técnicas para quebrar tais dependências. Refatorar o código para melhorar o design e diminuir as
dependências é algo inseguro, por isso a refatoração depende tanto da suite de testes: ela é sua rede de segurança
para evitar que as coisas quebrem. Porém, ao lidar com código legado, é difícil saber se você quebrou alguma outra
coisa, pois os testes não estão lá para te ajudar. Por isso as técnicas mostradas no tutorial são muito cuidadosas,
compostas de pequenos passos seguros onde as chances de quebrar são muito pequenas. Pode ser que seu código fique
mais feio para conseguir escrever o teste. Porém, uma vez que seu código está “cercado” por testes, você tem
segurança para começar a mudá-lo e melhorá-lo, levando-o em direção a um design mais robusto.

Engineering Outside the Box – Greg Harbaugh

O dia e a conferência terminaram com um banquete na parte da noite, com muita comida, bebida,
cowbells e colares brilhantes:

Durante o banquete, Greg Harbaugh, um ex-astronauta, deu uma palestra inspiradora sobre a forma com a qual
encaramos nossos problemas. Após a palestra, foram apresentados os ganhadores do prêmio
Gordon Pask desse ano, um prêmio entregue
para lembrar e recompensar as pessoas que contribuíram para o movimento ágil durante o último ano.

Essa foi a primeira vez que fui a uma conferência e foi uma experiência incrível. Durante esses 6 dias eu aprendi
muita coisa, conheci muita gente (não é todo dia que você almoça do lado do Martin Fowler)
e fiquei realmente inspirado com as idéias e valores do movimento ágil. Mais do que assistir palestras dos
autores que admiro, eu consegui apreciar por completo o valor da existência de uma comunidade que suporta e
promove os mesmos valores. São pessoas que realmente gostam e acreditam naquilo que fazem e trabalham para
elevar o estado da arte da nossa profissão. Termino com uma frase dita por um dos ganhadores do prêmio desse ano,
Laurent Bossavit:

“Devemos continuar trabalhando para fazer da nossa profissão algo tão nobre quanto a profissão do bombeiro ou do astronauta”

Penúltimo dia de conferência. Minha agenda de voluntário está cheia nesses dois últimos dias e,
para minha sorte, consegui alocar o trabalho nas sessões mais interessantes. Hoje assisti (em ambos os
sentidos) dois autores famosos: Mary Poppendieck e Kent Beck.

From Concept to Cash: Managing the Pipeline – Mary Poppendieck

Mary é uma pessoa incrível e uma ótima apresentadora. Ela está trabalhando num novo livro que será continuação
do famoso “Lean Software Development”,
chamado “Implementing Lean Software Development: From Concept to Cash”
e que será lançado em Setembro desse ano. Na palestra ela falou sobre alguns dos princípios do pensamento
“Lean” aplicados no contexto do desenvolvimento de software. A idéia tem suas origens no Sistema de Produção da
Toyota para manufatura de carros “just-in-time”. Mais tarde essas idéias foram reutilizadas no contexto do desenvolvimento
de produtos (e onde ela tem muita experiência trabalhando para a 3M).

Sabemos das limitações da antiga metáfora que
compara o desenvolvimento de software à manufatura ou à engenharia civil. Se existe algo de parecido entre esses
dois mundos, devemos comparar o desenvolvimento de software com o desenvolvimento de produtos: uma área onde o sucesso
depende de um ambiente criativo e adaptativo.

A palestra foi muito informativa e esclarecedora. O timing também foi excelente. Dentre os principais tópicos que
ela cobriu, cito alguns:

• Princípios “Lean”: aplicados no contexto do desenvolvimento de software.
• Liderança: a importância de enxergar o todo, evitar a micro-otimização e o papel da liderança nas soluções mais bem sucedidas.
• Desperdício: eliminar desperdícios é o principal foco do pensamento “Lean”. Ela falou sobre as principais fontes de desperdício em projetos de software.
• Indivíduos e Times: a importância do trabalho em equipe.
• Conhecimento: o momento certo de tomar uma decisão. Atrase decisões irreversíveis para o último momento.

Aprendi muita coisa nessa sessão e estou ansioso para terminar de ler seu primeiro livro, que comecei a ler na semana
passada no aeroporto. Aqui vai uma foto que tirei ao final da sessão (depois de recolher os milhares de formulários
de avaliação da palestra):

XP Geography: A Guide to Mapping Your First Steps – Kent Beck e Cynthia Andres

Na parte da tarde foi a vez da palestra do Kent Beck e sua esposa Cynthia Andres! A palestra durava o dia inteiro,
então o Sergei cobriu a parte da manhã e eu fiquei com a parte da tarde. Como peguei
as coisas no meio do caminho, acabei perdendo uma parte da palestra. Porém, pelo material que estava espalhado na
sala e pelos desenhos no flip chart, eu pude perceber que ele havia falado sobre os valores, princípios e
práticas de XP, explorando algumas das práticas primárias através de Mind Maps.

Na parte da tarde, eles falaram sobre uma técnica chamada “Appreciative Inquiry”,
onde um time lembra de fatos positivos sobre o passado e tenta aplicá-los em situações no presente. Os participantes
trabalharam em pares: enquanto um contava sua história o outro capturava os pontos positivos. Depois de um tempo os
papéis se invertiam. Ao final, cada mesa trabalhava em conjunto para compartilhar as experiências e lições aprendidas.

No final da palestra ele falou sobre a importância do comprometimento e da responsabilidade para uma mudança
sustentável. Apesar do lado um pouco filosófico, eu achei muito interessante a forma com que o tutorial foi
conduzido, pois fez os participantes realmente pensarem sobre os valores por trás das práticas de XP e, mais ainda,
na forma em que esses valores podem ser aplicados durante a implantação sustentável de XP na sua organização.

Após as palestras eu estava realmente cansado e decidi não participar da
festa promovida pela Google e voltei para
o albergue para descansar. Amanhã será mais um dia de agenda cheia, então quero estar com as energias recarregadas
para aproveitar o último dia da conferência.

Resumo do terceiro dia de conferência: uma sessão pela manhã, quatro na parte da tarde e eu descobri que estou ficando míope :-)

Storytelling with FIT – Steve Freeman e Mike Hill

Depois da sessão de ontem
com o Ward Cunningham sobre a importância dos testes para a evolução de um sistema, decidi assistir uma palestra
sobre o framework que ele inventou para testes de aceitação: FIT. O ponto principal
da palestra foi mostrar a importância dos testes de aceitação como meio de comunicar requisitos. Eu já ouvi muitas
conversas por aqui sobre a utilização da palavra “teste”, pois muitos podem achar que o único objetivo de um teste
é encontrar erros (e sabemos que, apesar de eficientes, testes não provam a ausência de bugs). Ao invés de “teste”,
os apresentadores tentaram usar o termo “documento”, pois os testes de aceitação no FIT são páginas HTML contendo
texto e tabelas com exemplos que especificam o comportamento esperado do sistema. O mais interessante é que o
documento é algo executável. Com isso você tem como especificar os critérios de aceitação de uma história antes de
ter a implementação pronta (a idéia de escrever testes antes do código aplicada num contexto mais amplo).
Ao implementar a funcionalidade esperada, você utiliza ferramentas como os testes de unidade e
TDD para garantir
a qualidade do código. Porém o desenvolvedor é também responsável por fazer o teste de aceitação passar. Para isso,
você precisa escrever um Fixture, que na verdade é uma classe
que será chamada pelo framework e te dará acesso aos dados escritos no documento FIT. A partir daí, você faz as
chamadas necessárias ao código da sua aplicação e avalia os resultados de acordo com as expectativas descritas no
documento FIT. Abaixo são duas tabelas que fizemos para especificar uma parte de um sistema de venda online de
serviços de internet:

Agile Quality: A Canary in a Coal Mine – Ken Schwaber

A sessão que escolhi participar depois do almoço foi do outro inventor do Scrum:
Ken Schwaber. Ele falou sobre a importância da qualidade como
atributo essencial num sistema de software: devemos nos preocupar com a qualidade desde o início. O custo para
colocar a qualidade depois é muito alto, podendo até levar um projeto ao fracasso no longo prazo devido à perda
de vantagem competitiva. Quando mais tempo você gasta lidando com defeitos no seu sistema, menos tempo sobre para
pensar no valor que ele está trazendo para o negócio. E o principal objetivo de qualquer sistema de software
deve ser agregar valor ao negócio. Na sua palestra, Ken tentou mostrar a importância da qualidade para um projeto de software e defendeu a idéia de que cortar qualidade deve ser uma decisão de negócio.

Agile Stories – Research Papers

Na segunda metade da tarde, resolvi assistir à apresentação de 3 papers, numa trilha chamada “Agile Stories”.
Falarei um pouco sobre cada um dos papers nos tópicos abaixo:

The Deployment Production Line – Jez Humble, Chris Read e Dan North

Esse artigo foi bem interessante: eles mostraram uma forma efetiva de estruturar e automatizar a implantação da sua
aplicação em diferentes ambientes (teste, integração, aceitação, …). O artigo explica de forma mais detalhada a idéia
da linha de produção que eles desenvolveram num projeto da ThoughtWorks. O interessante
é que eles automatizaram o processo de tal forma que qualquer pessoa podia fazer o deploy de qualquer versão do sistema
em qualquer ambiente com poucos cliques. É interessante ressaltar também o modo em que eles quebraram as dependências
para acelerar a execução dos testes nos diferentes ambientes, paralelizando em várias instâncias separadas do
Cruise Control a execução dos testes de unidade, testes de aceitação nos
cenários de sucesso (smoke tests, que rodam mais rápido), testes de aceitação nos cenários mais complicados (demoram
mais), testes de performance, etc. Com isso, um determinado build vai ganhando “medalhas” conforme passa em
cada etapa de teste, ficando fácil de saber quando ele pode ou não ser implantado em ambiente de produção.

The Cost of Code Quality – Yuri Kharmov

Essa apresentação foi, por enquanto, a pior da conferência. Foi o oposto da palestra do Ken Schwaber
que eu tinha acabado de assistir. O autor defendeu a idéia de que nem sempre precisamos
nos preocupar com a qualidade quando escrevemos código. O principal argumento dele é: toda preocupação com
qualidade tem um custo associado e você deve considerá-lo na hora de usar técnicas como TDD ou Integração Contínua,
em outras palavras, não é um grande problema ter um sistema cheio de bugs se eles não te atrapalham.
Duas coisas me incomodaram: em primeiro lugar ele transpareceu não entender a verdadeira essência de
TDD como uma
ferramenta que possibilita o Design Incremental.
Segundo, quando perguntaram para ele ao final da palestra quantas vezes ele discutia sobre qualidade de código com
o cliente, ele respondeu “Quase nunca”. Como ele pode julgar pelo cliente o valor da ausência ou não de bugs se ele
nunca discute sobre isso?

Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value – Deborah Hartmann e Robin Dymond

A última palestra do dia foi sobre métricas ágeis. Eu achei bem interessante a distinção entre “Diagnósticos” e “Métricas”
proposta pelos autores:

• “Diagnósticos”: são números que te ajudam a entender o andamento das coisas em relação ao processo. Por exemplo: medir a velocidade do time; interpretar o gráfico de “Burn-Down” para descobrir se o time irá terminar no prazo; ou saber a quantidade de defeitos. “Diagnósticos” dependem do contexto do time e devem ser temporários, ou seja, descarte-os assim que o processo estiver funcionando.
• “Métricas”: são números que medem o valor de negócio que seu sistema está produzindo. Por exemplo: retorno de investimento; lucro; ou presença de mercado. “Métricas” são mais difíceis de medir, por isso é bom escolher apenas uma.

É preciso tomar cuidado com as métricas que você escolhe para avaliar o desempenho de uma equipe ágil, afinal
“You get what you measure”. Outra coisa que eles mostraram foi um template para ser utilizado na hora de
criar uma métrica ágil, com pontos que te fazem pensar sobre o verdadeiro valor que aquela métrica irá representar
quando estiver medindo o sucesso do seu software.

Segundo dia de conferência, e mais 3 sessões interessantes. Não é todo dia que você participa de uma palestra
com Jeff Sutherland, Ward Cunningham, Ron Jeffries e Michael Feathers.

Beyond the Manifesto: Readings for Agile Developers – Peter Coffee

Caminhamos até o hotel da conferência mais cedo para dar tempo de tomar café antes do Keynote com Peter Coffee.
A sessão estava cheia e ele basicamente recomendou 4 livros relacionados aos 4 valores do
Manifesto Ágil:

• Up the Organization: How to Stop the Organization From Stifling People and Strangling Profits – Robert Townsend
• Systemantics: How Systems Work & Especially How They Fail – John Gall
• The World Is Flat: A Brief History of the Twenty-first Century – Thomas Friedman
• Thriving on Chaos: Handbook for a Management Revolution – Tom Peters

Após o Keynote, as sessões começaram pra valer: a programação estava cheia
de opções sobre os mais variados temas relacionados aos métodos ágeis. Decidi então começar o dia com o pé
direito.

Intro to the Agile Manifesto – Jeff Sutherland, Ward Cunnigham, Ron Jeffries e Michael Feathers

Apesar de ser uma sessão de para iniciantes (“Begginer's Track”),
eu não pude resistir à tentação de assistir uma palestra com 4 nomes tão conhecidos:
Jeff Sutherland, um dos inventores do Scrum,
Ward Cunningham, invertor do Wiki,
Ron Jeffries, um dos principais ativistas de XP e
Michael Feathers, o autor do livro
“Working Effectively with Legacy Code”
(que eu já li e estou devendo um review aqui).

Cada um ficou responsável por falar sobre um dos itens do manifesto ágil. O primeiro a falar foi Jeff Sutherland,
sobre:

“Indivíduos e interações são mais importantes que processos e ferramentas”

Sob o ponto de vista do Scrum, Jeff mostrou dados muito interessantes a respeito do poder do trabalho em equipe. A diferença
de produtividade entre um programador brilhante e um programador normal pode chegar a 25:1. Porém, quando você leva em
consideração a produtividade de um time inteiro, a diferença pode chegar a 2098:1!! Estou para começar a ler o livro de
Scrum e entendi a importância do time ser responsável pela conclusão das tarefas, ao invés das tarefas serem atribuídas
por alguém (gerente de projeto ou cliente). O próximo foi Ward Cunningham, falando sobre:

“Software funcionando é mais importante que documentação completa e detalhada”

Esse foi provavelmente o melhor tópico. Ward conseguiu expressar em poucas palavras a importância de termos uma suite
de testes: armazenar conhecimento sobre o código. Quando estamos desenvolvendo, o código inevitavelmente vai
guardar um histórico de decisões que tomamos no meio do caminho e que com certeza iremos esquecer depois de um tempo.
Testes de unidade “falam” numa linguagem voltada para os programadores sobre as decisões tomadas durante a vida de
um sistema, enquanto os testes de aceitação falam numa linguagem que o cliente entende. Não posso deixar de ressaltar
uma frase que ele disse no meio da palestra (o homem é uma máquina de frases de impacto): “Refatorar é a
álgebra do seu código”: você pega uma equação complexa e vai reduzindo até transformá-la em algo que
consiga entender. O próximo a falar foi Ron Jeffries, sobre:

“Colaboração com o cliente é mais importante do que negociação de contratos”

A negociação de contratos parte de uma premissa errada, de que não há confiança entre a equipe de desenvolvimento e o
cliente. Quando você diz que fará apenas o que o cliente assinou, ele fica com medo de perder funcionalidade e
demora para chegar a um acordo sobre o que deve ou não entrar no contrato. E o fato é: ninguém sabe o que irá acontecer.
Tentar escrever um contrato sobre algo que será construído depois de 1 ano é tentar prever o futuro e sabemos que os
seres humanos não são bons em previsões de longo prazo (muito menos quando o assunto é o escopo de um sistema
complexo). Por último, Michael Feathers falou sobre:

“Adaptação a mudanças é mais importante que seguir um plano inicial”

O ato de planejar é a única parte importante ao fazer um plano. Quantas vezes você já não fez planos sobre as coisas
que faria no próximo mês ou ano e não conseguiu cumprir? Michael Feathers falou muito bem sobre a forma com a qual
geralmente criamos nossos planos: nós tentamos impor condições sobre o futuro que não serão necessariamente
verdadeiras na hora de executá-lo. Um exemplo interessante que ele mostrou é sobre o planejamento urbano em
algumas cidades européias: Quando alguém define que devemos olhar para o farol para atravessar a rua e que o
carro deve parar antes da faixa para não atropelar os pedestres, está definitivamente fazendo um plano para evitar
acidentes de trânsito. Porém, o fato de colocar esses elementos como regra, faz com que desviemos nossa atenção
para o farol e para a faixa ao invés de olharmos para o que realmente importa. Na Europa, algumas cidades estão
construindo ruas onde não há distinção entre calçada e asfalto e com pouca sinalização, para fazer com que os
motoristas e pedestres estejam sempre atentos. O que ele quis mostrar com esse exemplo é que apesar da importância
do planejamento, é mais importante você focar nas coisas que estão acontecendo e se adaptar conforme conhece
mais o ambiente.

The Lego XP Game – Sam Newman, Dan North e Mike Hill

Essa foi definitivamente a sessão mais divertida até o momento. Sam e Dan são desenvolvedores da
ThoughtWorks e mostraram o jogo que eles usam para ensinar as principais
práticas de XP num curto período de tempo. Um jogo onde cada time recebe especificações sobre um animal e devem
construí-lo, iterativamente, usando peças de Lego! Genial! Meu time acabou perdendo desenvolvedores no break e tive
que mudar de equipe no meio do caminho, então acabei ficando com duas versões:

É interessante como foi possível mostrar partes do Jogo do Planejamento,
do desenvolvimento iterativo-incremental e da importância de medir a velocidade do time em cada iteração, usando apenas blocos de Lego!

Após 12 horas totais de vôo e muita fila para fazer o check-in, tanto no Brasil quanto em NY, cheguei ontem em
Minneapolis, MN para participar da Agile 2006 como estudante voluntário.
Essa será a segunda edição da conferência, que é o resultado da junção de 2 outras, Agile Development Conference (ADC) e
XP/Agile Universe.

Dia 0

Apesar de um pouco cansado da viagem, o plano funcionou conforme o previsto. Eu havia combinado de ficar num albergue
perto do Hotel da conferência (uma caminhada saudável de
20 minutos) e dividir o quarto com um outro voluntário que conheci por e-mail:
Sergei Golitsinski. Ele é russo, mora nos EUA há 7 anos e, para minha sorte,
numa cidade relativamente perto de Minneapolis. Como estaria de carro, ele se ofereceu para me buscar direto no aeroporto.
Fomos direto para o albergue e, depois de se perder um pouco nas ruas da cidade, chegamos ao
Minneapolis International Hostel. Para minha surpresa, o quarto que eu
havia reservado era melhor que eu esperava, com 2 camas, banheiro privativo (não é normal em albergues) e até
internet wireless de graça no quarto! Muito legal! Só não tem TV e outras regalias de um Hotel normal, mas é bom
o suficiente para ficar durante esses dias de conferência.

Saímos de carro para conhecer a vizinhança e comer alguma coisa (a fila do check-in em NY demorou tanto que nem deu
tempo de almoçar na conexão), indo logo depois para o hotel da conferência ajudar os outros voluntários a preparar
as malas dos participantes e dobrar camisetas. Depois de trabalhar na linha de produção das malas, voltamos para
o albergue para tomar um banho. A noite fui assistir um filme,
“Lady in the Water”, de M. Night Shyamalan, o mesmo diretor de
“Sexto Sentido” e “Sinais”, mas estava com tanto sono que acabei perdendo umas partes do filme e acabei não
gostando :-) Na verdade a história é exatamente um daqueles contos de fada que contamos para crianças e,
se você está esperando algo brilhante ou lógico, será surpreendido por algo extremamente simples e direto. Não
vou falar muito pois vou acabar estragando a alegria daqueles que querem assistir o filme. Nem preciso dizer
que depois do filme voltei pro albergue e capotei.

Dia 1

Hoje de manhã viemos para a primeira reunião geral com todos os voluntários para entender o que devemos fazer para
ajudar na mesa de registro e nas palestras e sessões da conferência. A única coisa que me deixou um pouco chateado
é que não ganhamos a bolsa da conferência com informações como: o programa detalhado (com horários), preceedings
e outras informações. Não tanto pelas coisas que vêem dentro da bolsa ou pela bolsa em si, mas sim pelo fato de
dizerem que os voluntários só irão ganhar após ter certeza que todos os pagantes tenham recebido suas bolsas. No
total não devem ser mais que 20 voluntários que se registraram para ajudar. Enfim… não é nada que irá piorar
meu aproveitamento da conferência então vou deixar pra lá e falar sobre a parte importante: as sessões.

Durante a parte da tarde participei de 2 sessões: uma “Discovery Session”
com um pessoal da ThoughtWorks muito interessante, onde fizemos uma coleta de
dados sobre o estado atual das metodologias ágeis de desenvolvimento de software. Primeiro fomos para a parte externa
do prédio do hotel e formamos vários “gráficos humanos”, onde cada pessoa representa um ponto no gráfico (por exemplo:
“Quão feliz você está com seu trabalho atual” X “Há quanto tempo usa métodos ágeis”). Depois voltamos para a sala e
nos dividimos em grupos, fazendo uma retrospectiva sobre os seguintes tópicos:

• As 3 coisas que mais me atraíram nos Métodos Ágeis
• As 3 coisas que eu mais gosto de fazer quando uso Métodos Ágeis
• As 3 principais decepções que tive com Métodos Ágeis
• As 3 coisas que mais me surpreenderam sobre Métodos Ágeis

Os resultados serão publicados no wiki da conferência mais tarde e estarão
disponíveis para quem quiser. Por enquanto mando uma foto parcial do mural com alguns dos post-its:

A outra sessão que assisti foi do Scott Ambler sobre dois questionários online que
ele publicou no site Dr. Dobb's para tentar captar o ponto de vista da comunidade em
relação ao estado atual das práticas e princípios dos métodos ágeis. Uma boa discussão sobre as perguntas da pesquisa
e sobre os dados levantados. Quem estiver interessado pode tirar suas próprias conclusões a partir dos
dados obtidos.

Para fechar o dia, tivemos um “Ice Breaker” muito legal no maior saguão do hotel, um evento com a finalidade de
integrar todos os participantes da conferência e entretê-los. Tinha comida a vontade (muita comida), bebidas, doces,
um trio de jazz, um mágico, pessoas fazendo chapéu de balão e até um cartunista, que me desenhou assim:

Por enquanto estou aproveitando bastante a conferência e a experiência está sendo fantástica. Não sei se conseguirei
escrever todos os dias sobre as novidades, mas vou tentar fazer um resumo a cada dois dias. Amanhã promete ser mais
um dia de muitas palestras, troca de conhecimento e aprendizado.