Coding Dojo @ engsoftagil

Depois de 7 horas de aula em pleno Sábado, uma galera corajosa da #engsoftagil se reuniu para um coding dojo. O problema escolhido foi o FizzBuzz. A linguagem foi Ruby. Os detalhes sobre o dojô estão no dojobh.

Tenho alguns comentários:

  1. Gostei das discussões sobre qualidade do código vs. preocupação com performance. O pessoal decidiu por deixar explícita a intenção do código, o que achei muito bom.
  2. Mesmo nesse problema muito simples (FizzBuzz), precisamos fazer muitas decisões de design ao implementar. Isso, pra mim, invalida opiniões (principalmente de alguns gerentes por aí) de que programação é algo mecânico. Espero que o pessoal tenha tido o mesmo feeling.
  3. Surgiram questões interessantes relacionadas a TDD:
    • devo escrever outro teste ou refatorar o código?
    • como sei que meus testes são suficientes?
    • para um problema com uma solução óbvia, posso escrever logo a solução que acho que é a correta e implementar os testes depois?

    Todas essas são questões pertinentes e que mostra que o pessoal estava interessado e questionando TDD, mas com a mente aberta.

Uma coisa que eu deveria ter evitado e que pretendo melhorar da próxima vez é o respeito a par que está programando. Fiquei dando pitaco e sugerindo um monte de coisa. Isso atrapalha quem está programando. Devia ter ficado mais calado.

Faltou um teste que juntasse tudo, que Rondy começou a implementar mas não teve tempo de terminar, porque o pessoal começou a Retrospectiva. Coloquei no Gist o código de um possível teste de wrap-up.

def test_fizzbuzz_de_1_a_20
      sequence = []
      1.upto(20) do |n|
           fizzbuzz = FizzBuzz.new(n)
           sequence.push(fizzbuzz.run)
       end
       assert_equal '1,2,fizz,4,buzz,fizz,7,8,fizz,buzz,11,fizz,13,14,fizzbuzz,16,17,fizz,19,buzz', sequence.join(",")
end

Houve um efeito ruim da decisão de passar o número como parâmetro do construtor, que é ter que instanciar um objeto a cada número. Acho que, como não precisamos manter estado, seria melhor passar o número em questão como parâmetro do método run, que executa a lógica do FizzBuzz.

Uma coisa interessante a se fazer, é implementar o FizzBuzz passando um Range como parâmetro. Aí, mudaria o código para retornar um Array, ao invés de um número ou String. Aí o código do teste acima iria ficar algo parecido com:

def test_fizzbuzz_de_1_a_20
       fizzbuzz = FizzBuzz.new
       sequence = fizzbuzz.run(1..20).join(",")
       assert_equal '1,2,fizz,4,buzz,fizz,7,8,fizz,buzz,11,fizz,13,14,fizzbuzz,16,17,fizz,19,buzz', sequence
end

O caminho do guerreiro Ágil

  • Faça as perguntas difíceis.
  • Encare a verdade.
  • Diga o que precisa ser dito.
  • Não tolere desperdício.
  • Afie suas espadas continuamente.
  • Nunca enxergue problemas – apenas desafios.
  • Saiba que você não pode ser definido por apenas um título ou papel.
  • Entenda que o ato de entregar software muda os requisitos.
  • Saiba quando deixar pra lá. E quando não.
  • Tenha respeito pelas idéias e opiniões dos outros.
  • Não leve o conteúdo dessa lista a sério.

Tradução livre do Way of the warrior, de Jonathan Rasmusson.

O chororô do Schwaber

No sábado, estava conversando sobre o chororô do Ken Schwaber sobre estarem desvirtuando o Scrum. Lembrei de Ken descendo a lenha no Kanban depois da galera da Scrum Alliance (incluindo muitos brasileiros) discutir sobre se a comunidade Scrum deveria apoiar o Kanban:

Kanban is a good alternative when Scrum demands too much of you. It allows managers to continue assigning work to resources (not people), treating people as interchangeable cogs in functional silos, using command-and-control management, and inhibiting people from working closely in self-organizing teams.

If you are having trouble getting the agile benefits from Scrum of value driven development, high productivity, and great quality, this is a good fall-back position. It doesn’t challenge management or …

Como disse Rodrigo Yoshima no Twitter:

O vendedor de pastel nunca vai falar que o milho é melhor. Até mesmo se o cliente tiver colesterol alto.

Não seja um Agilista Chato

Welcome to Fight Club. The first rule of Fight Club is: you do not talk about Fight Club. The second rule of Fight Club is: you DO NOT talk about Fight Club!

Uma coisa com a qual toda pessoa que se empolga com Ágil tem que tomar cuidado é não ser um tipo muito odiado por aí: o Agilista Chato.

No dia-a-dia da empresa, quando as coisas vão contra os princípios Ágeis que ele leu nos livros ou na Internet, o Agilista Chato fica nervoso e vocifera “no XP é assim”, “no Scrum é diferente”, “isso vai contra os princípios Lean”…

Eu fui esse tipo de agilista e tenho tentado me distanciar disso. Quando você está num ambiente não Ágil (e isso tem de monte por aí), é preciso ter tato para inserir novas ideias. Ágil, invariavelmente, requer mudança de comportamento e mudanças desse tipo são graduais.

Lance as ideias, mas não mencione XP ou Scrum. As pessoas não estão interessadas em XP ou Scrum, elas estão interessadas em resolver os problemas que elas enfrentam de maneira efetiva. Ágil oferece um bom guia para vários problemas comuns no desenvolvimento de software. Se você souber sugerir as soluções no momento certo, você se dará muito bem.

Tenha paciência e relaxe: implantar Ágil é difícil mesmo. Coragem não é um dos valores do XP à toa. Mas não confunda coragem com chatice. Foque sempre no ROI, saiba  adaptar as práticas (ou aprenda errando) e vá com calma.

Não importa o que o XP diz, o que você ouviu na sua aula de Scrum Master. Todo agilista enfrentará muitos problemas e os verdadeiramente bons saberão contornar a situação. Esqueça os processos: falar em processo ágil é tão paradoxal, que até dói o estômago. O que importa é o sucesso e não o processo.

Também é preciso tomar cuidado ao falar que os métodos tradicionais estão errados. Tem muita gente muito competente que acredita naquilo. Cuidado para não bancar o moleque, o xiita ágil, que não aceita ideias alheias. Aceite as ideias tradicionais, dependendo do contexto. Reavalie suas decisões a cada situação. Não deixe seu discernimento ser afetado por preconceitos e rigidez de valores. E assine o Juramento da Não-Lealdade.

Você nunca encontrará o projeto perfeito ou a equipe perfeita. São poucos os Becks, Fowlers e Jeffries por aí. Contente-se com o que você tem hoje, valorize sua equipe e tente melhorar sempre.

Um  bom conselho: não fale sobre Ágil.