Danilo Sato

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.

O post do rbp sobre “teste para ter menos o que testar” me inspirou a pensar um pouco sobre o assunto. Eu já percebi que muitos desenvolvedores têm medo de jogar código fora. É sempre aquela coisa: “Não, deixa comentado CASO a gente precise algum dia”. E é assim que a coisa começa. Com o tempo, você começa a ter trechos enormes de código comentado que você não sabe mais o que faz e prefere não mexer para não piorar. Se comentário no código é considerado desodorante, para mim código no comentário é mal-cheiro muito pior!




Por isso, está lançada a campanha antes chamada “Eu Não Tenho Medo de Jogar Código Fora”, que foi renomeada para anti-CC (Código Comentado) por sugestão do Julian. A nova sigla segue a filosofia “menos é mais” e evita eventuais problemas de censura se eu escolhesse duas letras de cada palavra :-)




Se você compartilha desse sentimento, deixe um comentário e espalhe a notícia! Vamos acabar com esse mal, que pode ser facilmente resolvido com um bom sistema de controle de versão, propriedade coletiva do conhecimento e um pouco de coragem. E tenho dito! :-)

Depois de recentes discussões sobre o assunto, achei interessante compartilhar algumas idéias sobre uma das práticas de XP: a Propriedade Coletiva de Código.




Uma das principais características nas definições da prática é o que podemos chamar de socialização do código. Não é que ninguém é dono do código, mas sim TODOS são responsáveis por TODO o código. Isso implica que a equipe não corre o risco de depender do “dono da classe” para fazer uma alteração ou melhorar uma parte do sistema. Se o “dono” ficar doente ou tirar férias, a equipe continua produzindo. Porém, como em toda metodologia ágil, essa prática pode precisar ser adaptada ao seu contexto.




O Giuliano me fez perceber hoje que minha definição da prática ia um pouco além do que descrevi acima. Acredito que a equipe tem muito mais a ganhar com o compartilhamento do conhecimento sobre o código. Poder alterar qualquer classe é importante, mas é muito melhor saber o que está acontecendo no sistema como um todo. É essa visão global que vai aguçar o “olfato” da equipe para identificar “maus-cheiros”.




Mas como esse compartilhamento de conhecimento acontece na prática? XP sugere outras práticas que podem ajudar, como Programação Pareada e Integração Contínua. Minha experiência me mostrou que analisar os logs e diffs entre as revisões do repositório também ajuda. Não vamos excluir também a comunicação face-a-face. No entanto, analisar logs e diffs nem sempre é uma tarefa trivial. Especialmente quando a equipe integra código novo várias vezes ao dia.




Outro dia estava discutindo exatamente sobre o mesmo assunto com o Julian e ele estava procurando por um meio mais eficaz de garantir que certas informações essenciais seriam lidas pelos outros programadores. Coisas do tipo: “Criei uma nova classe para encapsular o comportamento X. Usem essa classe a partir de agora”, “Novo padrão de código: cabeçalho alterado para incluir dados-extra. Alterar em todas as classes criadas/atualizadas a partir de agora” ou “Filtro de autenticação criado. Considerar esse aspecto ao criar novas funcionalidades”. Seria uma espécie de “Release Notes” das últimas alterações no repositório. Acredito que uma ferramenta poderia auxiliar os desenvolvedores na comunicação desse tipo de conhecimento. Eu gostaria de ver algo assim ao sincronizar minha cópia local do projeto.




E vocês, como lidam com esse compartilhamento de conhecimento técnico no seu projeto? Quais as adaptações que vocês consideram apropriadas para o seu contexto?

Boas novas! Meu artigo foi aceito e agora estou planejando minha viagem para Como na Itália para participar do XP 2007. Se você também está pensando em ir para a conferência, entre em contato ou deixe um comentário para combinarmos de nos encontrar por lá para dividirmos experiências e, quem sabe até, despesas de hotel. :-)

Conforme o Vinicius anunciou, esse ano promete para as conferências ágeis no mundo e, quem sabe, no Brasil também. As coisas estão esquentando por aqui ultimamente. Tivemos o nosso Curso de Verão da AgilCoop e já estamos planejando ministrá-lo novamente em horários melhores. Além disso, a Teamware está organizando novos cursos de Certified Scrum Master em São Paulo, Rio de Janeiro, Florianópolis, Brasília e Buenos Aires, e Certified Scrum Leader em São Paulo. A Heptagon está organizando um workshop sobre FDD. A ImproveIt está com um curso super interessante de Imersão Ágil.

Estamos semeando novos conceitos e paradigmas na indústria brasileira de software e tenho certeza que em breve teremos muitas empresas interessadas em adotar métodos ágeis. Não vamos deixar a bola cair!

Apesar das coisas parecerem paradas por aqui, estive bastante ocupado nos últimos meses. Nada melhor que aproveitar o pós-carnaval para voltar a escrever (um post curto) :-)

É claro que nada serve como desculpa para não escrever no blog, mas deixo aqui uma lista com algumas das coisas que me mantiveram ocupado desde o último post:

• Mestrado: O tema do meu mestrado é tracking de projetos ágeis (mais especificamente XP) e minha qualificação foi no dia 12 de Dezembro. O feedback recebido da banca de avaliação foi bastante positivo e enriquecedor. O texto da qualificação não está disponível pois está em fase de “refatoração+implementação” para a defesa, que deve ocorrer nos próximos meses.
• Artigos: Meu primeiro artigo científico foi aceito numa edição especial de uma das principais publicações da SBC, o Journal of Brazilian Computer Science. O artigo foi escrito em inglês, com o título “Experiences Tracking Agile Projects: an Empirical Study”. A versão impressa já deve sair em breve mas a versão online já está disponível aqui e no site da AgilCoop. Além disso, em Janeiro submeti outro artigo para a conferência XP 2007 que ainda não sei se vai ser aceito.
• Curso de Verão: A AgilCoop ministrou em Fevereiro dois cursos de uma semana (um teórico e outro prático) sobre Métodos Ágeis. Foi muito divertido preparar e apresentar esses cursos e o feedback que recebemos foi muito positivo. Devo falar um pouco mais sobre o curso em outro post, mas para quem estiver curioso, os slides estão disponíveis (com Copyleft) no site da AgilCoop.
• Coaching XP: Desde Dezembro, estou prestando consultoria em XP/Métodos Ágeis numa empresa start-up que tem potencial para ganhar o seu espaço na web brasileira: o Ikwa. A premissa básica do projeto é criar uma comunidade ao redor do tema “orientação profissional”, onde estudantes do ensino médio ao universitário possam explorar o seu futuro e traçar suas carreiras através de ferramentas que os auxiliam na busca pelo auto-conhecimento, desde a escolha do curso até a vida profissional. O trabalho está muito legal! Nós passamos por uma fase de entrevistas e testes para montar a equipe de desenvolvimento que acaba de ser completada. Devo falar mais sobre as experiências por lá em outros posts. Por enquanto os curiosos podem acessar o Ikwa Blog.

Por enquanto é só. Até breve! E, dessa vez, espero que seja breve mesmo :-)

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.

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.

Nesse post falaremos um pouco sobre alguns dos mitos relacionados ao design em XP e sobre a nova abordagem de Kent Beck para garantir a qualidade e a simplicidade do design de um sistema.

Na primeira edição do livro Extreme Programming Explained, Kent Beck propôs 3 práticas que estavam diretamente relacionadas ao design do sistema: Design Simples, Refatoração e Metáfora. Dessas três, a última é a que mais gerou confusão nos praticantes de XP, sendo uma das menos utilizadas na prática. Com relação às outras duas, já ouvi diversas críticas e dúvidas:

• Como garantir que estou sempre implementando a idéia mais simples para resolver meu problema?
• Quais os fatores para determinar a simplicidade do meu código?
• Evitar BDUF (Big Design Up-Front) significa nunca pensar no design?

Algumas dessas dúvidas estão relacionadas à forma como elas foram apresentadas na primeira edição, enquanto outras se baseiam numa interpretação errônea da prática no contexto de XP. A resposta para essas perguntas está melhor estruturada numa nova prática da segunda edição do livro: o Design Incremental. Invista no design do sistema um pouco a cada dia e se esforce para que o design seja excelente para resolver as necessidades atuais do sistema.

• Quando?: Ao contrário de pensar pouco ou nunca pensar no design, a estratégia de XP é pensar sempre no design.
• Como?: Faça mudanças em passos seguros e pequenos. A disciplina que facilita a evolução constante do design em XP é a refatoração, que melhora a qualidade do código sem alterar o comportamento do sistema.
• Onde?: A heurística mais simples e eficaz é eliminar código duplicado. Adicionar uma feature num único lugar é muito mais simples e rápido do que ter que mexer em código espalhado por diversas classes.
• Por quê?: Um design simples é mais comunicativo e mais fácil de ser entendido e alterado. Se o objetivo de XP é manter o custo da mudança constante, a facilidade de alterar o design a qualquer momento é fundamental.

Os novos critérios propostos por Kent Beck para avaliar a simplicidade são, em ordem de prioridade:

1. Apropriado para o público-alvo: O código deve ser facilmente entendido pelas pessoas que vão trabalhar com ele.
2. Comunicativo: Todas as idéias e intenções devem estar presentes no código, facilitando o entendimento do time e de um futuro leitor.
3. Fatorado: A existência de código duplicado dificulta as alterações e o entendimento.
4. Mínimo: Cumprindo as três restrições acima, um sistema deve ter o menor número de elementos possível. Menos classes implicam em menos código para testar, documentar e comunicar.

Para auxiliar o entendimento dos critérios de XP para avaliar e produzir código de qualidade, uma outra prática – que a princípio não parece ter relação direta com o design – se mostra muito importante: o Desenvolvimento Orientado a Testes (TDD – Test Driven Development). Ela será o tema dos próximos posts e, ao contrário do que possa parecer, está tão relacionada à produção de testes automatizados quanto à produção de código mais simples, comunicativo, fatorado e mínimo.