Danilo Sato

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!