Danilo Sato

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.