Danilo Sato

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.