Danilo Sato

Conforme eu havia previsto, hoje teria menos coisas para escrever. Como houve manifestações a favor dos meus relatos, vou tentar compensar esse post mais “magro” com mais fotos. Mas isso não significa que pouca coisa aconteceu. Pelo contrário, muita coisa interessante aconteceu: 2 tutorias excelentes, almoço com a Mary e Agile Café. Pena que está acabando…

Thinking, Refining, and Communicating the Business Perspective with Executable Documents – Rick Mugridge e David Hussman

Pela manhã, decidi participar do tutorial sobre Documentos Executáveis com o David Hussman (Agile Coach) e o Rick Mugridge, co-autor do famoso livro sobre FIT, apesar de ter participado de uma sessão sobre o framework na Agile 2006. O interessante foi que a ênfase da apresentação foi muito além da ferramenta FIT/FitNesse/FitLibrary. O conceito da documentação executável como elemento de comunicação com os clientes e como forma de definir os cenários de aceitação de uma história vai muito além da ferramenta. Documentos Executáveis são aqueles que não são escritos uma vez só; aqueles que não tendem a ser esquecidos ou a crescer infinitamente; aqueles que ajudam as pessoas a pensar e colaborar; aqueles que ajudam as pessoas a comunicar o que o produto realmente faz.

Algo que gostei muito, e que não tinha visto de forma formalizada antes, foi a prática conhecida como Story-Test Driven Development (STDD ou Desenvolvimento Dirigido por Testes de Histórias), onde antes de fazer TDD, a equipe de programadores, analistas, testers e clientes colabora para definir os critérios de aceitação da história antes mesmo de começar a desenvolver. Como a Mary disse no seu tutorial, por que uma equipe de desenvolvedores deve começar a trabalhar numa história sem saber o que deve fazer? Segunda ela, na empresa do Jeff Sutherland (criador do Scrum e CTO da PatientKeeper) os desenvolvedores não podem colocar a mão numa história se ela não é “testável”. Se o cliente não consegue (ou não se importa em) sentar com a equipe para definir exatamente o que espera do software desenvolvido, não tem sentido começar a programar. Qual o valor esperado?

Segundo os palestrantes, o caminho para chegar a uma documentação executável passa por diversas etapas:

• Personas: Para quem não conhece, é uma prática criada por Alan Cooper para descrever os usuários do sistema de forma mais humana. Ao invés de usar “homens-palito” (ou seja lá como chamam esses bonequinhos), uma persona tem nome, foto (ou caricatura), interesses pessoais e valores que espera extrair do produto. No artigo que vou apresentar semana que vem na WDRA (em Porto de Galinhas!), apresento de forma breve essa prática que é muito eficiente (e divertida).
• Histórias: Partindo das personas, você consegue enxergar diversos objetivos e tarefas que um usuário irá realizar no seu sistema. Fica bem mais fácil escrever histórias a partir dessas tarefas.
• Testes de Histórias (Story-Tests): Uma vez que temos histórias, é hora de colaborar com o cliente para entender o que eles realmente querem. Dessa conversa devem surgir os testes de histórias (ou testes de aceitação, como o Kent Beck definiu em XP).
• Cenários, tabelas/fixtures (no caso do FIT), APIs, etc: No momento que a equipe entende a real necessidade do cliente (que pode mudar com o tempo, mas isso é normal), precisam garantir que aquilo seja armazenado de forma executável e que sirva como ferramenta para informar o desenvolvedor quando uma história está quase pronta (“quase” pois o seu conceito de “pronta” pode – e deve – ir mais além da codificação/teste).
• Documentos Executáveis: Só depois de tudo isso você é capaz de construir uma documentação executável. Essa documentação serve como registro de como o sistema deve funcionar e, quando o cliente mudar de idéia ou quiser discutir algo em particular, ela pode ser alterada/testada em ciclos curtos de feedback para garantir que o sistema se adapta às novas necessidades.

No final, o grupo se dividiu e a discussão continuou entre os mais interessados no nível mais técnico (discutindo o FIT/FitNesse em particular) e os mais interessados no nível mais amplo. Fiquei um pouco em cada discussão.

From User Story to User Interface – Jeff Patton

Na parte da tarde participei de mais um excelente tutorial com o Jeff Patton, da Thoughtworks. Material impecável, slides e timing muito bons, didática excelente e exercícios práticos divertidos e instrutivos. E, claro, um assunto muito interessante: como o design de usabilidade (por aqui mais conhecidos como Interaction Design) e o design de interfaces gráficas se encaixam no mundo ágil?

Quem vive no mundo do design de interfaces e da usabilidade tem uma propensão a trabalhar com BDUF (Big Design Up-Front). O que geralmente se diz é que você precisa ter uma idéia de todas as possíveis formas de interação e atividades que um (ou vários) usuário(s) terão com o sistema antes de projetar a melhor interface e o melhor design gráfco. Nós do mundo ágil sabemos que BDUF não funciona muito bem. Num dos relatos de experiência apresentados anteriormente, Robert Beedle mostrou um estudo empírico qualitativo mostrando que, em geral, a maioria das atividades de definição de interface tendem a acontecer no início dos projetos mesmo. Ele mostrou quatro abordagens diferentes:

• Fazer todas as atividades de design da interface antes de começar a desenvolver
• Fazer ambas as atividades em paralelo, de forma iterativa
• Fazer ambas as atividades em paralelo, porém trabalhando no design de interface uma iteração na frente (de forma que a equipe de desenvolvimento trabalha sempre em cima do que a equipe de interface desenvolveu na iteração anterior)
• Começar somente com atividades de design da interface e, gradualmente, inserir atividades de desenvolvimento. Conforme as iterações vão passando, a quantidade de trabalho de desenvolvimento vai aumentando enquanto de design diminui, até o momento em que só é preciso desenvolver. Algo como aqueles gráficos de baleia do RUP.

No tutorial, Jeff apresentou o modelo em camadas proposto por James Garrett para descrever os diferentes elementos da Experiência do Usuário:

• Superfície: interface gráfica, com cores e elementos gráficos do design.
• Esqueleto: uma espécie de “wireframe” de como os elementos estão estruturados na interface.
• Estrutura: como os elementos da interface estão conectados para formar um todo.
• Escopo: uma lista de tarefas que um usuário tipicamente irá realizar através da interface.
• Estratégia: os objetivos por trás das tarefas que serão realizadas na interface.

Apresentou também as diferentes formas de representar os usuários (Atores, Papel, Perfil ou Persona) e as diferentes formas de capturar e representar as interações do usuário com o sistema, como: Use cases, Histórias, Workflows, Cenários e Modelo de Tarefas. Durante o resto do tutorial, nos organizamos em grupos e realizamos diversas atividades para produzir e validar um protótipo em papel: partimos de uma história e definimos um simples cenário de uso, descrevendo as interações entre o usuário e o sistema (num formato de Use case essencial). A partir disso, definimos os diversos componentes que fariam parte da interface gráfica para que o cenário fosse atendido.

Depois veio a parte divertida: começamos a desenhar e recortar os diversos componentes e “montar” a interface em papel, usando canetinhas, papel, transparências, cola pritt e liquid paper.

Por fim, vimos como funciona um teste de usabilidade num protótipo de papel e como, depois de poucas iterações, conseguimos diminuir o número de erros de usabilidade. Para isso, cada um tinha um papel (role, para não confundir): o “facilitador” apresentava nossa proposta e era o único que podia conversar com o usuário-final (num estilo narrador de esporte). Outra pessoa faz o papel de “computador” e fica trocando os papéis/botões/transparências conforme o usuário-final interage com o protótipo. Além do “usuário-final” (que eram duas pessoas vindas de uma outra equipe), alguém precisa fazer o papel de “observador” e ficar tomando nota dos problemas encontrados durante o teste.

Foi uma experiência valiosíssima (o melhor tutorial até agora na conferência) e aprendi bastante sobre como integrar o mundo do design com o mundo de desenvolvimento. Nós sempre aprendemos bastante quando passamos por problemas parecidos. O Jeff está fazendo um trabalho excelente para juntar essas duas comunidades. Para quem se interessar, vale a pena conferir as suas idéias.

Discussões em Geral

Não bastassem os ótimos tutoriais, aind tive o privilégio de ser convidado para almoçar com a Mary e com o Tom para discutir várias coisas. Uma das discussões foi a respeito da velocidade, e expressei minha opinião (e a da Mary) na XP@Rio. Não vou me repetir por aqui. Se alguém se interessar, é só seguir o link. :-)

Como comentei, as pessoas que não estão participando de workshops ou tutoriais geralmente se reúnem nas mesas de fora do hotel para discutir assuntos ágeis, no que foi batizado como Agile Café. Dei uma passada no final do dia, mas já estava cansado e resolvi voltar pro hotel para descansar. Por hoje é só, pessoal. Amanhã é dia de mais um tutorial e um workshop. Arrivederci!

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.

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?

Finalmente tomei vergonha na cara nesse fim de semana e fiz os trackbacks do meu blog funcionarem. \o/ Ainda está em fase experimental, mas fiz uns testes internos e parece que está ok.




Aproveitando que o assunto é diversão, parece que o Settlers fez sucesso! Por falar nisso, estou devendo marcar umas partidas com algumas pessoas. Se você é uma delas, deixe um comentário para me cobrar. Se não for, mas tiver interesse em conhecer o jogo, deixe um comentário também. Na pior das hipóteses podemos jogar uma partida online :-)

Para fechar essa série de posts sobre o FISL, resolvi falar um pouco sobre algumas das curiosidades da minha viagem a Porto Alegre:

1-1 = 3 ?

O hotel em que ficamos era um tanto curioso. Em primeiro lugar, nosso quarto tinha, além dos usuais 2 quartos e banheiro, uma cozinha gigante, uma sala de TV, uma área de serviço e até campainha! Com certeza era um prédio de apartamentos que virou hotel. O quarto do pessoal do BCC 2005 ficava na cobertura e tinha 2 andares! Muito chique. Mas o mais engraçado era o que tinhamos que fazer para chegar no nosso quarto, 501B. A recepção ficava no prédio “A”, no andar 1. O andar térreo era onde ficava a passagem para o nosso prédio “B”. Então tínhamos que descer um andar para atravessar de um prédio para o outro. Até aí tudo bem. O mais engraçado era que saíamos do térreo do prédio “A” e, andando em linha reta, chegávamos ao terceiro andar do prédio “B”! Sim, 1 – 1 = 3! A última parte do percurso era fácil: só subir mais 2 andares para chegar no quinto. Que confusão!

Churrascarias e taxistas

No primeiro dia todo o pessoal do IME foi jantar numa das melhores churrascarias de Porto Alegre (pelo menos segundo a propaganda e as indicações de algumas pessoas). Fomos todos de táxi e, segundo relatos do pessoal que foi antes, alguns dos motoristas de táxi ganhavam comissão para levar as pessoas nas churrascarias “conveniadas”. Ou seja: ele tentava te empurrar outra churrascaria e, na pior das hipóteses, te levava na conveniada dizendo que era a outra. :-) Não vou nem comentar muito sobre o que aconteceu na volta para o hotel mas, aparentemente, o convênio dos motoristas de táxi não se limita às churrascarias, mas também a outros estabelecimentos noturnos da cidade (com direito a escolher 1 entre 3 opções sem pagar a corrida!). Essa foto foi tirada pelo Guilherme:

No terceiro dia, fui encontrar com uma amiga que estudou comigo e fomos jantar numa churrascaria uruguaia. A comida era muito boa. O Julian não se conteve e teve que pedir um “Tapa no Quadril” de janta. Sim, picanha tem esse nome naquele restaurante. Tinha até a opção “Tapa no Quadril – Gaúcho”. Imaginem ele pedindo para a garçonete: “Por favor, eu gostaria de um Tapa no Quadril”. Foi engraçado. :-)

Google

Conforme já comentei, no último dia, tivemos que ralar para conseguir ganhar brindes no stand do Google. A protagonista da cena engraçada do dia foi a Mari: depois de ensinar eu e o Julian a resolver o Cubo Mágico, uma outra menina pediu para aprender. A Mari, já cansada de ficar em pé, puxou a cadeira do stand do Google e começou a explicar para sua nova aprendiz. Depois de um tempo ensinando os movimentos e as etapas para chegar na solução, a menina conseguiu terminar. Foi então que a Mari me tira um chaveiro do Google do bolso e dá para a menina, como prêmio por ter resolvido o cubo. Ha ha ha.. A menina até perguntou se ela trabalhava no Google. Enquanto eu dava risada o pessoal do Google estava inconformado com a cena (e rindo também).

Settlers

Tirando o fiasco que foi minha participação no jogo do primeiro dia,
uma frase ficou marcada: no meio das negociações eu ouço alguém pedindo “Eu quero uma madeira” (você vai ter que ler em voz alta para entender a graça… ou não). Ok, essa nem foi tão engraçada, podia ter terminado sem essa. :-)

Assim termino essa série de posts sobre o FISL 2007 e espero encontrá-los por lá no ano que vem!

O último dia do FISL foi bem intenso, apesar de ter assistido apenas 3 palestras:

• AJAX: A primeira palestra do dia que assisti foi sobre Web 2.0, AJAX, Hibernate, JSF, JPA, EJB, Netbeans… No entanto o que assisti foi uma mera introdução sobre AJAX – ponto. Com direito a exemplos de código funcionando. O pessoal parecia estar curtindo, mas não foi nenhuma novidade para mim.
• Being a Sysadmin at Google: Essa palestra foi mais interessante, apesar de um pouco curta. A Fernanda falou um pouco sobre alguns dos projetos em que já trabalhou: um para colocar um escritório novo funcionando a partir do primeiro dia, um para monitoramento do parque de servidores e o Goobuntu, uma distribuição Linux interna que utilizam nas máquinas dos funcionários (e que não pretendem liberar para uso público, ainda). Claro que não poderia faltar falar um pouco sobre o dia-a-dia de um admin no Google e atrair interessados para novas vagas.
• Arena de Programação: Mais para o final do dia, fui assitir uma discussão sobre o que rolou na Arena de Programação, uma novidade interessante dessa edição do FISL. Fui prestigiar nosso representante (e companheiro de quarto), o Guilherme Silveira da Caelum, que acabou vencendo nas 2 etapas (individual e por equipe) e levando um notebook para casa. Na verdade, levando um “vale-notebook”. O prêmio verdadeiro deve chegar na casa dele um pouco depois :-)

O mais divertido do dia não foram as palestras, mas os desafios propostos no stand do Google, que fiquei resolvendo com o pessoal do IME. Eles levaram um jogo com peças coloridas no estilo tetris e, a cada dia, mudavam o desafio para distribuir brindes. No começo era só montar tudo colocando as cores iguais juntas, mas no último dia você já não podia encostar peças de cores iguais (nem na diagonal), nem tirar a peça depois de colocar e nem “simular” na mesa antes de encaixar a peça. Tinha também um Cubo Mágico pro pessoal resolver. Tive que me esforçar para ganhar brindes:

• Meu primeiro chaveiro eu ganhei resolvendo o joguinho das peças coloridas quando ainda podiam encostar cores iguais na diagonal.
• Um dos pontos altos do dia foi ter aprendido a resolver o Cubo Mágico! Valeu Mari! Ganhei um ímã com uns LEDs piscando de brinde.
• O ponto mais alto do dia foi o que tivemos que fazer pra ganhar uma camiseta, canetas e mais chaveiros/ímãs piscantes: O pessoal soltou um desafio para calcularmos o número de soluções possíveis para o jogo das peças coloridas. Ficamos quebrando a cabeça um tempo e, com a ajuda do Guilherme (mesmo depois de ficar 3 dias programando na Arena), do Julian e da Mari, conseguimos programar um algoritmo de backtracking para resolver o problema (tudo bem que não conseguimos calcular para as 10 colunas, mas acho que aprendi um monte durante as 2:00hs que passamos programando).

De noite fomos jantar numa churrascaria uruguaia com a Luiza, uma amiga que fez BCC comigo e está terminando o mestrado na URGS. Voltando para o hotel, joguei mais uma partida de Settlers e dessa vez eu consegui ganhar :-)

Em resumo, o FISL foi muito divertido. Poucas das palestras foram realmente proveitosas, porém o número de pessoas que conheci/re-encontrei e a troca de experiências foi impressionante. É legal participar de um evento como esse para conhecer pessoas excepcionais e encontrar boa parte da comunidade geek do país.

Continuando meus relatos do FISL 8.0 em highlights, meus comentários sobre o segundo dia:

• OLPC: Uma das principais atrações do FISL é o projeto One Laptop Per Child. O governo brasileiro está analisando e testando outros protótipos, mas pelo que eu vi por aqui, o OLPC-XO me parece bem mais “child-friendly”. Uma das coisas mais legais é que ele já funciona numa rede mesh sem fio, e as crianças conseguem detectar os amigos mais próximos e trocar informações/dados. Numa das palestras que assisti sobre o protocolo de comunicação dessa rede, fizeram uma demonstração de como a rede se recompõe quando um nó “servidor de stream” (tocando música) sai do alcance e um terceiro nó entra no meio para continuar roteando o pacote. Muito legal!

• Sourceforge.net: A palestra sobre a infra-estrutura do SourceForge foi bem interessante e o palestrante mostrou que eles aplicam vários conceitos ágeis na forma como pensam sobre o assunto. Eu anotei algumas das quotes que ele colocou na apresentação para ilustrar o que estou falando:
• Sobre simplicidade: “Complex Structures that work evolve from simple structures”
• Sobre otimização precoce: “Capacity planning is imprecise, based on What is the Next Bottleneck?”
• Sobre adaptação a mudanças: “The only one thruth about luck is that it will change”
• Sobre os objetivos do projeto: “Our goal is to have quicker developement and get things done”
• Maddog: Através de uma comparação entre Software Livre e Pianolas (aqueles pianos que “tocam” sozinho), John “Maddog” Hall apresentou de forma descontraída e informativa um resumo da história da evolução dos cravos/pianos/orgãos/pianolas, fazendo um comparativo interessante com a comunidade do Software Livre.
• Ubuntu: Apesar de pegar só o finalzinho da palestra do Jono Bacon, do Ubuntu, acho que foi uma palestra bem interessante, onde ele falou da importância e do papel da comunidade no desenvolvimento do Software Livre (focou mais nos aspectos de colaboração entre pessoas). O título da palestra era bem sugestivo: “How to Herd Cats and Influence People”. Suas idéias sobre comunidades estão totalmente alinhadas com o que o Kent Beck fala. Na segunda edição do livro de XP, inclusive, ele torna a comunidade parte da metodologia, colocando-a ao lado dos valores, princípios e práticas de XP.
• Settlers of Catan: A noite voltamos para o hotel, pedimos uma “pizza” de metro (sim, a pizza é quadrada, e não, não tem 1 metro quadrado). A massa tinha gosto de pão e o molho de tomate era daqueles de latinha, que já vem pronto. O mais legal foi jogar Settlers (com direito a expansão e tudo – 6 jogadores) com o pessoal do BCC 2005 e ficar em último lugar :-) Aliás, todos desse pessoal mais novo do IME, que eu não conhecia, são muito legais.