Agile

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.

Anúncios
Agile

Documentar o processo da sua empresa é ruim

No vídeo do relato do pessoal da Bluesoft sobre o evento Ágiles 2009, é citada uma ideia de Taiichi Ono da Toyota sobre porque o ato de documentar processos é ruim. A frase é mais ou menos assim:

Documentar processos é ruim porque o processo se cristaliza e a melhoria contínua fica comprometida.

Outra frase interessante, dessa vez de Donald G. Reinertsen:

Melhores práticas só são “melhores” em certos contextos e para atingir certos objetivos. Um mudança no contexto ou nos objetivos pode rapidamente transformar uma “melhor prática” em uma abordagem estúpida.

Agile

RUP é iterativo

No slide 11 da palestra “Implantando Scrum, experiência de um Agile Coach” de Rodrigo Yoshima no Maré de Agilidade, há algo muito interessante sobre a adoção de metodologias no Brasil.

RUP

O uso de RUP no mercado brasileiro se fortaleceu em 1999. RUP tem a ver com

  • Foco no Usuário, Iteratividade e Arquitetura

mas o mercado brasileiro entendeu que era sobre

  • Documentos, Burocracia, Controle

XP

XP, que começou no Brasil em 2001, é sobre

  • Coragem, Boa Engenharia e TDD

mas o mercado brasileiro entendeu que era sobre

  • Anarquia, falta de templates do RUP e algo que não funciona

Scrum

O uso de Scrum no Brasil se alastrou em 2003. O foco principal do Scrum é

  • ROI, Auto-Organização e Transparência

mas o mercado brasileiro entendeu que era sobre.

  • Iteratividade(!), modinha Ágil e certificação

É interessante notar que só com o Scrum que o mercado brasileiro conseguiu entender as vantagens de um processo iterativo incremental para se desenvolver software.

TDD

Desenvolvendo uma calculadora pós-fixada com TDD

Bret Schuchert, da Object Mentor (a empresa de Uncle Bob),  criou uma série de screencasts em que ele ensina conceitos de TDD, refatoração e design emergente enquanto desenvolve uma calculadora pós-fixada (do estilo da HP) em Java.

A série é muito boa. Bret é muito bem-humorado e tem bons insights de design durante os vídeos.

Abaixo está o primeiro vídeo e alguns pontos que achei interessantes.

Uma das partes que achei mais interessantes é quando ele renomeia a classe RpnCalculator deixando os nomes muito mais claros:

public class RpnCalculator {
  @Test
  public void NewCalculatorHas0InItsAccumulator { ... }
  @Test
  public void NewAccumulatorShouldAllowItsAccumulatorToBeSet { ... }
}

vira

public class ANewlyCreatedRpnCalculatorShould {
  @Test
  public void Have0InItsAccumulator { ... }
  @Test
  public void AllowItsAccumulatorToBeSet { ... }
}

Bret diz que a inspiração para a mudança de nome vem do BDD, metodologia que se preocupa muito com a maneira como as coisas são representadas no código. Realmente ajuda bastante.

Na mesma linha de raciocínio, há uma mudança muito interessante que Bret faz em um código que caminha na direção de um assert por teste e remove duplicação do código.

public class ANewlyCreatedRpnCalculatorShould {
  private RpnCalculator calculator;
  @Before
  public void init(){
    calculator = new RpnCalculator();
  }
  @Test
  public void Have0InItsAccumulator{ ... }
  @Test
  public void AllowItsAccumulatorToBeSet{ ... }
  @Test
  public void AllowMultipleValuesToBeStored(){
    BigDecimal value = new BigDecimal(42);
    BigDecimal value2 = new BigDecimal(2);
    BigDecimal value3 = new BigDecimal(3);
    calculator.setAccumulator(value);
    calculator.enter();
    calculator.setAccumulator(value2);
    calculator.enter();
    calculator.setAccumulator(value3);
    assertEquals(value3, calculator.getAccumulator());
    calculator.drop();
    assertEquals(value2, calculator.getAccumulator());
    calculator.drop();
    assertEquals(value, calculator.getAccumulator());
  }
}

vira

public class ACalculatorWithThreeValuesShould{

  private RpnCalculator calculator;
  BigDecimal value = new BigDecimal(42);
  BigDecimal value2 = new BigDecimal(2);
  BigDecimal value3 = new BigDecimal(3);

  @Before
  public void init(){
    calculator = new RpnCalculator();
    calculator.setAccumulator(value);
    calculator.enter();
    calculator.setAccumulator(value2);
    calculator.enter();
    calculator.setAccumulator(value3);
  }

  @Test
  public void HaveTheLastValueEnteredInItsAccumulator(){
    assertEquals(value3, calculator.getAccumulator());
  }

  @Test
  public void HaveTheSecondToLastValueAfterASingleDrop{
    calculator.drop();
    assertEquals(value2, calculator.getAccumulator());
  }

  @Test
  public void HaveTheFirstValueEnteredAfterTwoDrops(){
    calculator.drop();
    calculator.drop();
    assertEquals(value, calculator.getAccumulator());
  }

  @Test
  public void Have0AfterThreeDrops(){
    calculator.drop();
    calculator.drop();
    calculator.drop();
    assertEquals(BigDecimal.ZERO, calculator.getAccumulator());
  }
}

Ao mover um código que testava três coisas ao mesmo tempo para uma classe específica, Bret pôde fazer um único método que criou as fixtures para os demais testes.  Assim, foi possível separar cada assert em um método com uma responsabilidade bem específica e melhorou bastante o design e a clareza do código.

Um outro momento interessante é quando Bret identifica inveja de funcionalidades na classe RpnCalculator em relação à classe Stack do Java. Esse mal-cheiro de código o faz discutir se a classe RpnCalculator está com responsabilidades demais. Então, Bret extrai a classe OperandStack (com os devidos testes antes), que fica responsável por utilizar a classe Stack.

Em um vídeo posterior, Bret adiciona as funções de adição, subtração e fatorial, sempre mudando a classe RpnCalculator para implementar essas operações. Ele diz que isso viola o princípio Open/Closed, que diz que entidades de software tem que ser abertas para extensão e fechadas para modificação. Para implementar uma operação de divisão na RpnCalculator, por exemplo, teríamos que modificar o código da classe. Então, Bret usa o pattern Strategy, e define uma interface chamada MathOperator para as operações e classes Add, Subtract e Factorial que implementam essa interface. É interessante notar que, ao invés de definir operandos diferentes para cada uma das operações, a interface recebe a pilha de números armazenados. Isso evita problemas na definição de uma mesma interface para operadores unários (fatorial) e binários (adição e subtração).

É interessante ver o ciclo red/green/refactor em ação. A parte mais rica, onde o aprendizado de software design mais acontece, é na refatoração. Mas sem o red/green, a refotaração não seria uma atitude responsável a ser tomada.