Danilo Sato

One of the best resources about Pair Programming to date is Laurie Williams’ book “Pair Programming Illuminated“, as well as all the research she’s been conducting on the subject. At Agile 2008 I was lucky enough to meet her personally and present my experience report in the same slot as her’s. She showed us a video that was produced to teach Pair Programming to students at the North Carolina State University.

Although targeted to the University environment, the video is great and shares some important lessons about the Do’s and Don’ts of Pair Programming. If you replace references to teacher and teaching assistant (TA) with tech lead or project manager, I’m sure most of the advices will make perfect sense.

The video is really well produced and is worth watching and sharing. Please take the time to check it out and learn from someone who’s been not only doing Pair Programming, but also teaching and publishing research on the subject.

It’s been a while since I read the 2nd Edition of “XP Explained” and I really enjoyed the emphasis on separating practices from values and principles. If you try to map the original 12 XP Practices to the new primary and corollary practices, you will notice that it’s not a one-to-one map. And that’s great! Practices are good when you are at the Shu level of learning, but they should be tailored to specific situations, and understanding the underlying principles and values is what will help you do that.

Besides Pair Programming and Test-Driven Development, most of the original XP practices are distilled in more than one practice in the second book. Refactoring and Simple Design are better exposed as Incremental Design, while the Planning Game can be recognized in a list of practices such as: Stories, Weekly Cycle, Quarterly Cycle, and even Slack. Although Coding Standards are not explicitly cited as a practice, you can see its importance when reading about Shared Code and Single Code Base. But you will miss one practice in particular from the first book: the System Metaphor.

The System Metaphor was probably the less adopted practice and usually one of the hardest to explain. If you’re able to express and design your system in a shared metaphor such as “Payroll is like an Assembly Line”, you will see the benefits of this practice shining through: communication with domain experts will be easier and the gap between domain model and implementation will become much shorter. But as it turns out, it is not easy to find a useful metaphor for every system.

If you miss this practice from XP and is looking for the underlying principles behind it, I strongly recommend reading Domain Driven Design, by Eric Evans. Striving to find an Ubiquitous Language to bridge the communication gap between developers and domain experts, and isolating complexity in a rich domain model are goals worth fighting for. In Eric’s words:

System Metaphors are not useful on all projects. Large-scale structure in general is not essential. In the 12 practices of Extreme Programming, the role of a System Metaphor could be fulfilled by a Ubiquitous Language. Projects should augment that language with System Metaphors or other large-scale structures when they find one that fits well. 

Other patterns for large-scale structure are discussed in the book, as well as a lot of other precious material. So if you still haven’t done it, go read the book!

For a while I’ve been planning to write on this subject. The question of whether going broad or going deep into a subject area has always been present in my life. In this post I will scratch some of my current thoughts on the subject. Feedback and other opinions are welcome!

Some Background

My parents always told me that I couldn’t be good at everything. But they’ve always been very supportive on everything I decided to do. Being a great musician, magician, and programmer was not an easy task, but that never stopped me from trying. But then I read something funny that became a good argument for a while…  

The Specialist Paradox

An specialist is someone who knows more and more about less and less, ultimately knowing everything….. about nothing!

That even made me review my resumé to remove any reference to the word “specialist” and include the word “generalist”. :-)  

Swinging the pendulum

But I forgot that you can always change the argument to take the other extreme and come up with a “Generalist Paradox”. And then I watched Kent Beck’s keynote speech last year at XP 2007 about Ease at Work. We are always trying to be the best, but then we realize how bad we are and start thinking we are the worst. A great lesson that I took from his words is that while swinging that pendulum back and forth, we never stop to think that neither of those extremes are good. Being at ease is trying to find how to stay in the middle. In our discussion, the extremes of the pendulum would be the common view that generalists are best at defining the problem or goal and specialists are best at solving the problem or “executing the plan”:

While researching about this subject, I learned that you have similar concepts in Biology (highlights are mine):

A generalist species is able to thrive in a wide variety of environmental conditions and can make use of a variety of different resources (for example, a heterotroph with a varied diet). Specialist species can only thrive in a narrow range of environmental conditions and/or have a limited diet. Organisms do not fit neatly into either group, however. Some species are highly specialized, others less so, while some can tolerate many different environments. In other words, there is a continuum from highly specialized to broadly generalist species.

We can leverage that same idea, letting go the “Us vs. Them” argument and starting to think about generalist and specialist as complementary skills. David Armano has already suggested changing the “or” to “and”, but I would dare taking it one step further…  

It’s all about context

Specialty is contextual. Anyone in my family would consider myself a specialist in programming and software development. But they don’t have a clue that Computer Science is a broad area with so many fields. Some interest me more than others, so I could say I’m a generalist at that level. But since my interest in software development and Agile Methods is greater than other fields, one could say I’m a specialist, although I wouldn’t consider myself an expert at anything :-) I can see the XP principle of Self-Similarity applied here. I think that the above picture is just a simplification of reality. There are some dots underneath the surface that you can only connect if you specialize a little bit. And I would say that the same fractal structure would appear as you go deeper and deeper into your endless search for knowledge. Sometimes you will have to go back and look broader for a while, but that’s not wasted effort. That’s why I now see value in being both a generalist and a specialist in different contexts.

A ImproveIt está deixando o mercado de serviços e consultoria em Métodos Ágeis e XP. Estava escrevendo esta resposta como um comentário e percebi que estava ficando grande demais, então resolvi dedicar um post, afinal, meus amigos da ImproveIt merecem :-)

Mais importante que vender e disseminar os valores ágeis é mostrar que eles fazem parte da sua filosofia de vida. Com essa mudança vocês demonstram tudo aquilo que é difícil de vender em XP mas que faz muito sentido para quem usa: coragem, abraçar as mudanças, transparência na comunicação e envolvimento com a comunidade.

Até poucas semanas atrás eu não conhecia o pessoal da ImproveIt pessoalmente. Tive o prazer de conhecê-los graças aos eventos de rails em São Paulo e no Rio. Agora posso afirmar com certeza que eles têm o talento e o conhecimento necessários para que o sucesso venha rapidamente.

Tenho certeza que a mudança não é uma reação aos pontos levantados pelo Vinicius. Apesar de eu mesmo ter participado e até promovido os treinamentos de Scrum do Boris, concordo com as críticas. Tanto que, se olharem meu currículo, coloco o treinamento como curso e não certificação. Prefiro olhar pelo lado positivo da mudança. Acho que a mudança de rumos está muito mais relacionada com as possibilidades que enxergam no futuro do que com o que já fizeram no passado. E é exatamente esta atitude que eu admiro. Mudar sem medo. Coragem.

Desejo muito sucesso a todos: Vinicius, Tapa, Rafael, Felipe e Leandro (o único que não conheci pessoalmente, infelizmente). Continuem produzindo produtos de qualidade assim como fizeram com os treinamentos, palestras, consultorias, posts e podcasts sobre Métodos Ágeis e XP. Um grande abraço!

Final de feriado chegando. É hora de voltar a ativa e contar como foram os eventos da última semana. Primeiro um pouco sobre o Conexão Java.

Sexta-Feira

Foi a primeira vez que participei do Conexão Java e gostei bastante do evento. Além de re-encontrar amigos, as palestras que assisti foram excelentes. Na sexta-feira o Alexandre Magno falou um pouco sobre Scrum e, apesar de ter precisado sair no meio da palestra, os comentários que ouvi foram todos positivos. Na sexta acabei assistindo só essa palestra, pois fiquei o resto do dia ajudando o Carlos Villela terminar seus slides (percebam que minha participação foi importante.. he he).

Sábado

No sábado, o keynote do CV criticou os “arquitetos de uma nota só” que preferem usar sempre a mesma ferramenta para resolver qualquer problema. Além de argumentar sobre a importância da plataforma Java vs. da linguagem Java, os tópicos levantados deixaram a platéia preparada para as próximas apresentações.

O Philip Calçado re-apresentou a palestra de arquitetura do Just Java (dessa vez sem o Paulo) e agradou bastante o público. Apesar de eu já ter assistido a palestra, foi bom para ouvir mais um pouco sobre as “arquiteturas Java do passado”. Particularmente achei muito valioso ele ter levantado temas recentes como Domain-Driven Design e DSLs.

Depois foi minha vez. Minha estréia como palestrante foi bem recebida. As pessoas que me procuraram depois da palestra me deram um feedback positivo e alguns comentários online que li (aqui e aqui) me deixaram bastante feliz com o resultado. Espero que tenha conseguido passar minha mensagem, deixando algumas sementes para discussão sobre Métodos Ágeis, XP, Scrum e Lean. Minha apresentação já está disponível para download aqui.

Após minha palestra fomos almoçar numa churrascaria e acabei perdendo a palestra do Vinícius. A última palestra do dia foi do Fernando Meyer, core developer do JBoss, sobre ANTLR e seu uso na criação de DSLs externas. Gostei pois ele mostrou os conceitos básicos de um compilador (parsing, análise léxica, análise semântica, interpretação, geração de código, etc.) e partiu para um exemplo prático de código. Dei uma ajudinha depois da palestra com um bug (essas coisas acontecem) e os slides e o código estão disponíveis no blog do Fernando Meyer.

Espero poder participar de mais eventos como esse. Se você assistiu minha palestra, deixe algum comentário (positivos ou negativos). Feedback é sempre importante e me ajudará a melhorar para as próximas apresentações. O que você gostou e não gostou da minha palestra? Você aprendeu alguma coisa? Algumas das idéias surtiram efeito no seu dia-a-dia?

Já faz um tempo que estou para falar das novidades e, depois das palestras em novembro/dezembro, é com orgulho que apresento o novo curso de XP na Caelum.




Eu sou um pouco suspeito pra falar bem dos cursos deles, pois não só sou amigo do pessoal de lá, como também ajudei a montar esse novo curso. No entanto, posso garantir que a preocupação deles com a qualidade do treinamento, do material, a didática e, principalmente, com o aluno é um diferencial em comparação aos cursos encontrados no mercado. É por isso que fiquei feliz com o convite para ajudar a montar esse curso e ministrar a primeira turma.




O conteúdo está muito legal e quem participar vai aprender e se divertir. O treinamento terá um enfoque bastante prático, e exigirá que os alunos programem bastante. Minha meta nessas 20 horas de curso é falar não só sobre a filosofia Ágil, os princí­pios e valores de XP, como também mostrar os aspectos técnicos e mostrar a sinergia entre as práticas da metodologia. Espero que o aluno saia do treinamento com diversas idéias novas para implantar na sua empresa.




Fico bastante feliz que novos cursos desse tipo estão aparecendo no mercado de software nacional. Isso só vem a reforçar o fato de que os Métodos Ágeis estão ganhando mais interesse no Brasil a cada dia que passa.




Quem estiver interessado em participar, é só entrar em contato com o pessoal da Caelum para mais informações ou para fazer a reserva.

Se você é de São Paulo ou do Rio de Janeiro, nunca me (ou)viu falar ao vivo e estiver interessado em me conhecer para bater um papo, vai ter algumas chances nos próximos meses. Depois de participar de um evento de Software Livre, de XP e de Python nesse ano, vou apresentar algumas palestras para a comunidade Java, Ruby e Rails. Detalhes a seguir…

09/Nov e 10/Nov: Conexão Java '07 Hands On

No dia 10 de Novembro, das 11:30 - 13:00, vou apresentar uma palestra sobre Métodos Ágeis chamada “Agile Methods for the Traditional Guy”. Espero que o título não assuste as pessoas, pois o tema é legal e a idéia é dar uma introdução geral sobre os princípios do Manifesto Ágil, XP, Scrum, Lean, discutir problemas dos métodos tradicionais e desmistificar alguns mitos sobre Métodos Ágeis. As inscrições podem ser feitas pelo site do evento (com desconto até o dia 31/Out) e o evento acontecerá na Universidade Anhembi Morumbi da Vila Olímpia.

Quem for participar terá a chance de assistir ótimas palestras de alguns amigos: o Carlos Villela vem apresentar o keynote e falar sobre o “Arquiteto de uma nota só”; o Phillip Calçado vem reapresentar a ótima palestra sobre arquitetura do JustJava (dessa vez sem o Paulo), além de coordenar uma atividade que promete ser divertida: a Oficina do Arquiteto; O Fernando Meyer vai falar sobre DSLs e ANTLR; o Alexandre Magno vai falar sobre Scrum, dentre outras palestras muito boas.

Além das palestras, estarão acontecendo também mini-cursos em paralelo. O pessoal da Caelum vai ensinar Hibernate, AJAX e JSF, Java ME e JPA. Pelo que conheço da qualidade dos cursos deles, são mini-cursos ótimos e imperdíveis se você estiver interessado em aprender um pouco sobre essas tecnologias.

17/Nov: RejectConfSP '07

No fim de semana seguinte (sim, no meio dos feriados) estou ajudando o Fabio Akita a organizar a primeira RejectConf em São Paulo. A idéia é juntar a comunidade Ruby e Rails para mini-apresentações (de 10 a 30 minutos) sobre diversos assuntos, além do networking, troca de conhecimentos e diversão :-)

O evento vai acontecer no IME-USP, no Auditório Jacy Monteiro, das 11:00 - 17:00. As inscrições são gratuitas estão atualmente com lista de espera, mas pode ser feitas neste formulário. Quem estiver interessado em apresentar algum tópico, basta preencher este outro formulário.

Minha mini-palestra será sobre RSpec e RSpec on Rails. Quem quiser um gostinho de como é programar com RSpec/RBehave pode assitir o screencast #01 do Dojo@SP.

08/Dez: Rio on Rails

Por fim, mais um evento da comunidade Rails, organizado pelo Vinicius e o pessoal da Improve It. O evento está confirmadíssimo e acontecerá no SENAC, das 9:00 - 18:00. As inscrições custarão R$50,00 e estarão disponíveis em breve no site do evento (disponibilizado pela Improve It nos próximos dias).

O assunto será RSpec e RSpec on Rails novamente, mas dessa vez terei mais tempo para me apresentar.

Nos vemos por lá!

Acredito que os eventos serão bastante divertidos e informativos e espero que ninguém durma de tédio nas minhas apresentações :-). Faça sua inscrição e deixe um alô nos comentários para saber se devo te encontrar por lá!

Muitas equipes XP não automatizam seus testes de aceitação. Essa é uma afirmação dura, porém muito comum de acontecer. A equipe abraça TDD e testes de unidade automatizados, porém quando chega a hora dos testes de aceitação, a coisa complica. Por que isso acontece? Como melhorar essa situação?




Nesse post, inspirado por uma pergunta na XP@Rio, espero dar algumas dicas para ajudar quem tenha se identificado com minha alfinetada. :-)

O que é Teste de Aceitação?

Em primeiro lugar, é bom deixar claro qual a visão Ágil sobre testes. XP, em particular, pede que sejam escritos dois tipos de testes automatizados:

• Testes de Unidade: testes do programador. Geralmente testa um pedaço isolado do código. Quando seguimos TDD, o teste é escrito antes do código e funciona como especificação, te ajudando a pensar no design. Depois de escrito, serve como documentação executável do seu código.
• Testes de Aceitação: testes do cliente. Um teste de aceitação (ou Story Test, ou Customer Test) descreve um cenário (de sucesso ou não) com uma expectativa do cliente em relação à história ou funcionalidade. Como o nome sugere, ele ajuda a equipe a entender quando uma história está completa (aceita).

Um pequeno adendo: apesar de ser importante reconhecer esses dois tipos de teste propostos por XP, existem outros tipos de teste igualmente importantes como: testes funcionais, de interação, de carga, de segurança, etc… Isso varia conforme sua situação particular, mas esse não é o assunto desse post :-)

Algumas desculpas

Como disse no início do post, muitas equipes deixam de automatizar seus testes de aceitação. Existem muitas justificativas para explicar esse fato:

• Automatizar testes de aceitação é difícil: Testar um sistema web do ponto de vista do usuário ficou muito mais fácil atualmente com ferramentas como o Selenium ou Watir. Testar uma interface gráfica Swing é um pouco mais chato porém não impossível. Testar um software que gera imagens ou modelos visuais (um CAD como o Archimedes, por exemplo) é bem mais difícil. Testar um sistema embarcado depende do hardware. Testar um jogo depende de um jogador (automatizar o jogador pode não ser tão fácil). E por aí vai… dependendo da sua situação, tenho que concordar que sua tarefa pode não ser tão fácil. Mas qual a graça de programar sem desafios? :-)
• O teste fica muito grande: Para testar um cenário, geralmente é preciso fazer muito setUp. Você vai precisar criar diversos objetos, suas associações e terá que se preocupar em apagá-los depois (para manter a independência entre os testes e entre diferentes execuções do mesmo teste). Isso pode gerar problemas de dependência e você passa a perder mais tempo fazendo setUp e tearDown do que efetivamente escrevendo os testes importantes.
• O teste demora muito: O problema anterior faz com que seu teste demore muito para executar. Muitas vezes você pode depender de um banco de dados ou de outro sistema para testar um cenário de aceitação real. Se utiliza um sistema de Integração Contínua, perceberá rapidamente que seus ciclos de build demoram muito mais.
• O cliente não sabe escrever testes: É muito mais fácil um programador aprender a usar o JUnit ou qualquer framework do que o cliente. É papel da equipe encontrar a melhor forma de comunicação com o cliente. Se o cliente trabalha num banco, tente usar uma planilha ou uma tabela. Se seu sistema é cheio de regras de negócio complicadas, tente explorar os diferentes cenários pensando em exemplos. Infelizmente, não existe uma estratégia universal.

Alguns desses problemas são mais difíceis que outros. Mas de que adianta falar mal e enumerar problemas sem dar idéias de soluções?

Sugestões para melhorar a situação

Um novo papel

Quando falo que a Toyota eliminou o departamento de qualidade e teve ganhos incríveis de produtividade, geralmente recebo olhares espantados e desconfiados, principalmente da equipe de testes. “Você está dizendo que devo ser demitido?”. Calma, não é bem assim. A Toyota não eliminou sua preocupação com qualidade. Pelo contrário, ela valoriza tanto esse aspecto que compartilhou essa responsabilidade com TODOS os envolvidos no processo. Não quero que os testadores sejam mandados embora. Pelo contrário, suas habilidades devem ser espalhadas e aproveitadas por todo o processo de desenvolvimento. Devem trabalhar muito mais próximos e não no final da cadeia. Shigueo Shingo já dizia: “Inspecionar para procurar defeitos é desperdício. Inspecionar para previnir defeitos é essencial”.

O papel do testador numa equipe ágil é tão importante quanto o do programador. Ele ajuda a equipe e o cliente a aprimorar suas estratégias de teste (principalmente de aceitação). Eles fazem parte da equipe e também são responsáveis pela entrega! Lembrem-se: a história não está pronta enquanto não estiver testada!

Reaproveitando uma estratégia conhecida

Eu citei os maiores benefícios dos testes de unidade e TDD: eles te ajudam antes, durante e depois. Antes, te ajudam a especificar o problema e pensar no design do código. Durante, eles servem como rede de segurança, identificando um bug de regressão assim que ele é inserido e dando suporte à refatoração sem medo. Depois, servem como documentação executável do seu código, auxiliando você a dar manutenção e novos integrantes a entender o que o sistema faz.

Esses mesmos benefícios se aplicam aos testes de aceitação! O Kent Beck percebeu essa Auto Semelhança na segunda edição do livro de XP. A prática conhecida como Story Test Driven Development (ou STDD) funciona exatamente como TDD, porém no nível das histórias. Eu comentei sobre essa prática num post anterior da XP2007.

O cliente deve colaborar com a equipe para enumerar os cenários de aceitação. Pense em exemplos. Uma pergunta que te ajuda a definir tais cenários é: “Como saberei que terminei essa história?”. Se seu cliente não sabe ou não quer definir os cenários de aceitação, apenas responda: “Pronta!”. Os testes de aceitação te ajudam a saber quando a história está pronta. Se o cliente não define nenhum cenário de aceitação, a história está automaticamente pronta (inclusive testada!!). :-)

Ferramentas

Diversas ferramentas e frameworks têm surgido para auxiliar sua vida. Como já disse anteriormente, o Selenium e o Watir podem facilitar sua vida no teste de aplicações web. O FIT, que já comentei algumas vezes aqui, também te ajuda a sair do lado técnico e define uma linguagem de comunicação mais simples com o cliente (através de tabelas de exemplo). O Fitnesse armazena essas tabelas (e outras informações) num wiki.

Um framework que atraiu bastante minha atenção ultimamente foi o RBehave. Atualmente ele está sendo incorporado ao RSpec, um framework bem conhecido para BDD em Ruby (e Rails, mais recentemente). O assunto teve até um tutorial na última RailsConf na Europa. Ele te permite escrever cenários de aceitação da história de forma executável. Vale a pena dar uma olhada. Tem a versão Java também: jBehave.

Apesar de ter escrito muito, acredito ter apenas arranhado a superfície desse assunto tão interessante e tão amplo. Para um pouco mais de informações, sugiro ouvir o AgilCast #9 e assistir alguns dos nossos AgilVídeos.

Também gostaria de saber: O que você programa/desenvolve? Qual sua estratégia para automatização dos testes de aceitação? O que de legal você fez em relação ao assunto? Qual sua maior dificuldade?

Fui convidado pelo Eduardo Fiorezi para a gravação do décimo episódio do seu podcast: Tudo que quero saber. O bate papo foi muito legal e contou com a participação do Marcos Tapajós da Improve It. O assunto foi “Disciplina em XP” e o áudio já está disponível em MP3.




Alguns dos assuntos tratados foram:

• Disciplina em XP e Métodos Ágeis em geral
• Resistência a práticas de XP
• Liderança e o papel do coach
• Abordagens para adoção de XP (artigo do Kent Beck)
• Sustentabilidade de mudanças
• Dojo e formas de aprendizado (Shu-Ha-Ri)
• Importância das retrospectivas (artigo do Alex)

Programadores não treinam. Essa é uma triste constatação para a grande maioria dos programadores. Apesar de não ser verdade para todos os casos, aprendi com o Scott Adams que é importante começar com uma boa frase de impacto. Agora que tenho a sua atenção, posso falar da minha tentativa de mudar essa realidade: O Dojo@SP.

O que é o Dojo?

O Dojo é um espaço onde programadores se reúnem para treinar e aprender. As reuniões são periódicas e centradas num desafio de programação. Apesar do desafio, o objetivo não é terminar o problema. A idéia é aprender com as experiências vivenciadas pelo grupo. O ambiente é inclusivo, seguro e convidativo.

Eu vejo vários princípios de XP na forma como o Dojo funciona: passos de bebê, humanidade, falha, redundância, qualidade, melhoria, dentre outros.

As reuniões geralmente são conduzidas em dois formatos: no formato Kata alguém resolve o desafio em casa e apresenta na reunião “ao vivo”, começando do zero e seguindo TDD. No formato Randori o problema é resolvido “ao vivo” pelos participantes, usando TDD e Programação Pareada em turnos. A cada turno, o piloto volta para a platéia, o co-piloto passa a pilotar e um novo co-piloto é convidado da platéia.

Um pouco de história

A idéia do Kata como exercí­cio de treinamento foi proposta originalmente por Dave Thomas numa série de posts do seu blog. No final de 2003, Laurent Bossavit levou a analogia um passo adiante e propôs a criação de um espaço de treinamento em grupo um Dojo. A partir daí­, juntamente com Emannuel Gaillot, eles fundaram o Dojo de Paris, que está em funcionamento desde 2003. Outros gostaram da idéia e começaram movimentos semelhantes em outras partes do mundo.

Depois de conhecer o Emannuel e a Emily no XP 2007, me motivei para começar um Dojo por aqui. Com o apoio deles e do wiki internacional, criado justamente para esse propósito, reuni alguns colegas e começamos a nos reunir no mês de Julho de 2007. Desde entnao estamos nos reunindo toda quarta-feira no Instituto de Matemática e Estatí­stica da USP.

No Brasil, o Ivan Sanchez foi o primeiro a trazer essa idéia, fundando o DojoFloripa. Nossa iniciativa é a segunda do Brasil e esperamos que a participação do público paulista cresca no futuro e que outros Dojos comecem a aparecer em outras localidades do país.

Update: Esqueci de mencionar o Dojo de Recife que começou suas atividades no mesmo mês que a gente.

Como posso participar?

Se você está em São Paulo, junte-se a nós! Leia um pouco mais sobre nossas experiências no wiki e entre no nosso grupo de discussão. Não é necessário ter profundos conhecimentos de Python, Ruby ou TDD. Caso não esteja seguro para programar “ao vivo”, participe como ouvinte para sentir o clima. Espero vocês lá!

Boa programação!