Escrever testes de unidade é uma prática cada vez mais adotada. Ela ajuda a verificar se tudo funciona como o esperado mesmo após mudanças, trazendo mais segurança para a equipe ao alterar o código. Mas os testes de unidade vão além, possibilitando a validação de um design.

Um código fácil de testar tende a apresentar um bom design. Existe uma grande sinergia entre testabilidade e um bom design. Isso acontece pois, para que o programador consiga testar uma classe de maneira isolada e facilmente, essa classe deve lidar muito bem com suas dependências (buscando sempre um baixo acoplamento) e possuir pouca responsabilidade (ou seja, ser altamente coesa). Caso contrário, o programador gastará muito tempo tentando testá-la, um possível indicador de que a classe apresenta um design pobre.

Um design que apresenta classes com alto acoplamento são difíceis de testar, surgindo a necessidade de passar as dependências para nossos objetos e só então testá-los.

O primeiro resultado ao adicionar testes de unidade a um sistema é a mudança de padrões imperativos de execução onde instanciamos objetos e invocamos métodos para a injeção de dependências.

O exemplo a seguir mostra um processador sendo instanciado, o que torna difícil verificar se o comportamento do ExecutorDeBatch foi correto sem executar o código da classe Processador:

public class ExecutorDeBatch {
  public void le(ListaDeItens itens) {
    Processador processador = new Processador();
    while(itens.temProximo()) {
       String item = sc.proximo();
       processador.interpreta(item);
    }
  }
}

O teste acima verifica o comportamento do ExecutorDeBatch junto com o Processador. Esse tipo de teste é considerado de integração, não passando muita informação sobre o acoplamento entre as classes, mas somente garantindo o comportamento em conjunto.

Para isolar a classe acima seria necessário a utilização de um mock no lugar do Processador. Da maneira que o código está, seria bastante trabalhoso. No Java exigiria até manipulação de bytecode durante o classload para que fosse possível alterar a classe instanciada no momento do new Processador() por exemplo. Para isso, o programador deve deixar essas dependências bem explícitas, recebendo-as através do construtor, por exemplo. Teríamos então o seguinte código:

public class ExecutorDeBatch {
  private Processador processador;
  public ExecutorDeBatch(Processador processador) {
    this.processador = processador;
  }

  public void le(ListaDeItens itens) {
    while(itens.temProximo()) {
       String item = sc.proximo();
       processador.interpreta(item);
    }
  }
}

Passar um mock para a classe acima e consequentemente testá-la de maneira isolada ficou é fácil. A adoção dos testes de unidade deixa explícito o excesso de dependências (ou dependências implícitas escondidas).

Por fim, os testes precisam ser simples e curtos, limitando seu escopo; um teste muito grande ou complicado pode indicar que o método em questão possui muita responsabilidade.

Considere uma classe que é responsável por gerar uma nota fiscal a partir de uma fatura e disparar a mesma para o e-mail do cliente, assim como para um sistema SAP qualquer. Essa classe já possui as dependências bem explícitas:

public class GeradorDeNotaFiscal {
       private final Sap sap;
       private final EnviadorDeEmails enviador;

       public GeradorDeNotaFiscal(Sap sap, EnviadorDeEmails enviador) {
               this.sap = sap;
               this.enviador = enviador;
       }

       private NotaFiscal geraNotaFiscalAPartirDa(Fatura fatura) {
           // codigo de geracao da nota fiscal
       }

       public void gera(Fatura fatura) {
               NotaFiscal nf = geraNotaFiscalAPartirDa(fatura);

               sap.armazena(nf);
               enviador.envia(nf);
       }
}

Passar mocks para essa classe é fácil, já que é possível injetar todas as dependências nela. O problema é que, para criar testes para ela, o programador se preocuparia em testar se a nota fiscal foi gerada, se ela é enviada ao SAP e se ela é enviada para o cliente:

@Test public void deveGerarANf() { ... }
@Test public void deveArmazenarNfNoSap() { ... }
@Test public void deveEnviarNfParaOEmailDoCliente() { ... }

Perceba que essa classe tem responsabilidades demais: ela gera NF, envia para o SAP, envia para o cliente. Ao escrever esses testes, o programador perceberia que, em cada teste, ele estaria preocupado em testar uma responsabilidade da classe, sem se importar com a outra. No teste deveArmazenarNfNoSap, por exemplo, o programador seria obrigado a passar um stub da classe Email, mesmo não sendo o foco daquele teste. Isso torna a escrita do teste mais massante é um sinal de que a classe tem baixa coesão.

Portanto, se o seu design possue um alto acoplamento ou uma baixa coesão, será praticamente impossível escrever testes de unidade. Por esse mesmo motivo métodos estáticos, singletons, factories e estado global dificultam os testes de unidade.

Pensar e criar os testes antes do código também auxiliam no design. Usar Test-Driven Development força que a concentração do pensamento lógico foque nas responsabilidades de cada método, ao invés da exata implementação do mesmo.

Esse impacto no design é tão grande que muitos vão utilizar a sigla TDD para Test-Driven Design. Com TDD o programador é forçado a pensar em decisões de design antes do código de implementação, criando um maior desacoplamento, deixando mais claro suas necessidades.

O TDD, através dos testes de unidade e refatoração, possibilitam que o design apareça de uma maneira mais evolutiva, mas sem mágicas, sempre dependendo de conhecimento do desenvolvedor em relação a design e orientação a objetos.

Um exemplo desse tipo de abordagem é a tentativa de se testar uma constante, entre outros clássicos como a presença de uma anotação, métodos de delegação, getters e setters, etc. Supondo uma classe que armazena constantes de cartão de crédito e um possível teste de unidade para ela:

public class CartoesDeCreditoTest {
  @Test
  public void deveRelacionarVisaComOValor123() {
    assertEquals(123, CartoesDeCredito.VISA);
  }
}

public class CartoesDeCredito {
  public final static int VISA = 123;
  public final static int MASTERCARD = 456;
}

Repare que existe uma duplicação de dados entre o código de teste e o código de produção: o número 123. Quando o valor dessa constante mudar, você possui dois pontos de código para alterar. Ao fazer uma refatoração para remover essa duplicação, teremos um resultado como a seguir:

public class CartoesDeCreditoTest {
  @Test
  public void deveRelacionarVisaComOValor123() {
    assertEquals(CartoesDeCredito.VISA, CartoesDeCredito.VISA);
  }
}

Muitas vezes, o programador, acostumado a escrever testes de unidade para todo o código, acaba desenvolvendo testes sem utilidade: código que na realidade não testa nada. Naturalmente, o desenvolvedor não faria a refatoração acima, tal exemplo demonstra como um teste do genêro não traz valor, somente complexidade para nosso sistema.

Ou seja, em casos como o mostrado acima não há utilidade em escrever um teste de unidade para constantes. Ao fazer isso, o programador gera duplicação de dados entre a classe de teste e a de produção.

É importante testar constantes, mas no caso acima por exemplo, não através de testes de unidade: se ela representa um valor de um outro sistema, por exemplo, escreva um teste de integração.

No caso do cartão de crédito, suponha que a constante 123 seja o código do pagamento via cartão VISA no sistema do PayPal, portanto testamos a integração entre a aplicação e o sistema externo. Verifique se, ao passar o valor 123, o pagamento gerado foi um pagamento VISA.

@Test
public void deveEnviarCartaoVisaParaOPayPal() {
  Cobranca resultado = payPal.efetuaCobranca(valor, numeroDeUmCartaoVisa, CartoesDeCredito.VISA);

  assert(that(resultado.getStatus()).is(PayPal.APROVADO));
}

Em um exemplo mais elaborado, imagine agora o seguinte trecho de código abaixo que usa o Active Record do Rails para fazer um filtro:

def filtro(name)
  where("nome like %#{name}%")
end

def test_verifica_se_where_foi_invocado
  componente.should_receive(:where).with("nome like 'guilherme'")
  componente.filtro("guilherme")
end

# outra variação do mesmo teste:

def test_verifica_se_where_foi_invocado
  query = componente.filtro("guilherme")
  query[0].should == "nome like 'guilherme'"
end

Neste caso, uma vez que o método possui um corpo simples, uma invocação de uma função do Active Record, o teste abusa de mocks e é apenas uma mímica daquilo que o método executou. Ele garante somente que o programador digitou aquilo que ele esperava digitar. Testes como esse só indicam um problema no design do teste ou um problema no design do código.

No mundo Java é comum ver similares quando encontramos a utilização de Mocks ao extremo:

public void adiciona(Produto p) {
  this.session.save(p);
}

@Test
public void testSalvarEhInvocado() {
  Produto produto = new Produt();
  one(session).save(produto);
  dao.adiciona(produto);
}

Veja que o próprio nome do método diz que ele não serve pra nada: verifica se o salvar é invocado. Você quer testar o comportamento que essa classe terá sobre seu sistema e não se um determinado método foi invocado. A obviedade que o método está sendo invocado é trivial de ser notada e por isso mesmo não precisaria ser nosso foco no teste.

Mas alguns podem dizer: mas não preciso testar o Active Record, eu sei que ele funciona. Ou ainda, não preciso testar o Hibernate, eu sei que ele funciona. Sim, você não precisa testar o Active Record unitariamente pois ele já foi testado, mas existe a necessidade de testar a integração do seu código com o Active Record. No exemplo de uma query, sabemos que escrevemos uma query como desejávamos, mas ela está retornando aquilo que desejamos? E deixando de lado o resto? São essas perguntas que nosso teste precisa responder.

def test_deve_retornar_pessoas_que_tenham_parte_do_nome
  lista = executa_metodo_where("joão");

  lista.should_contain o_cidadao("João Gilberto")
end

O mesmo vale para queries em Java que utiliza JPA/Hibernate.

Para saber mais sobre teste e design: Kent Beck já discutia acoplamento tanto de dados quanto de código entre classes de teste e classes de produção. Isso é muitas vezes ignorado pelo programador. Imagine que você precise alterar muitos testes toda vez que fizer uma pequena alteração: é um indício de um design rígido, onde uma simples alteração propaga uma série de outras alterações.

Como regra geral, que possui suas excecões, não existe valor em um teste que é uma mímica daquilo que foi digitado e não de seus efeitos e retornos. Nesse caso, pense duas vezes antes de escrever esse teste e verifique se testar aquela classe de outra maneira (através de um teste de integração, por exemplo) não seria mais útil.

O processo de entrega de uma funcionalidade nova envolve implementar ou corrigir algo que o nosso sistema atualmente não comporta. Dados os problemas que o programa resolve nesse instante, existem diversas maneiras distintas de resolvê-los, todas válidas, algumas mais limpas e mais simples do que outras.

O gráfico a seguir mostra uma situação onde nosso programa não resolve o problema atual que desejamos atacar, onde:

a) vermelho: representa variações do sistema que não resolveriam meu problema;
b) amarelo: minha situação atual;
c) verde: soluções possíveis.

Soluções possiveis para um problema

Mas dentro das soluções possíveis, existem aquelas mudanças que são simples de serem executadas, por exemplo incluir um “if” ou simplesmente fazer um copy e paste de código, um pequeno passo, uma mudança simples, um baby step. Mudanças simples que resolvem o problema, representadas em verde escuro aqui:

Mudanças simples

Por fim, existem as soluções mais simples para o problema. A solução mais simples pode ser extrair uma classe ou utilizar uma biblioteca que executa a lógica para nós, por exemplo. No diagrama a seguir as soluções mais simples são representadas em azul:

Soluções simples

A execução desses passos, baby steps, traz o código para dentro das mudanças simples que resolvem o problema. Mas a sequência dos mesmos pode nos levar para diversos lugares diferentes: alguns mais próximos das soluções mais simples, outros cada vez mais distantes das mesmas, nos deixando com um débito técnico cada vez maior.

Pior ainda, a adoção cega de baby steps ou de mudanças simples sem nenhuma prática para garantir a qualidade pode levar a uma situação onde seja impossível chegar em uma solução simples: seu sistema vira uma grande bola de lama.

Essa situação é o inferno de qualquer sistema: passos simples não são mais capazes de manter as coisas simples.

Uso puro de baby steps não implica em melhoria de qualidade. Passos muito simples podem levar seu sistema a situações negativas.

Em algumas situações, o baby step pode implicar em uma das melhores soluções, mas para isso é necessário o domínio da tecnologia, do negócio, design e linguagem, algo que nem sempre é a realidade do desenvolvedor quando escreve uma funcionalidade:

Baby step de um desenvolvedor com domínio forte da tecnologia, linguagem, domínio de negócio e sistema.

Como é difícil executar um passo-a-passo muito suave e chegar em uma solução simples qualquer, adicionamos mais uma técnica ao processo: além de executar as tarefas em pedaços pequenos (mas não mínimos), refatoramos nosso código, para simplificá-lo.

Cada passo de simplificação através da refatoração coloca nosso código mais próximo do sistema ideal: o mais simples de todos que resolve nossos problemas.

A refatoração que a cada passo simplifica o código nos leva cada vez mais próximos a melhor solução para nossos problemas.

Com a refatoração contínua, cada passo que damos ao implementar uma nova feature nos mantém ainda próximos das soluções simples.

Mais importante do que fazer passos minúsculos (baby steps) é fazer passos que fazem sentido para levá-lo em direção a melhor solução (e não somente a mudança mais simples). Para isso não podemos nos esquecer de refatorar. E não só refatorações de baixo nível (como renomear variáveis, mover métodos, etc), mas sim refatorações de alto nível (como abstrair comportamentos).

Imagine o seguinte trecho de código, responsável por calcular o salário de um funcionário. Dependendo do cargo do funcionário, o algoritmo para o cálculo é diferente.

public class CalculoDeSalario {

  public CalculoDeSalario(RegrasFiscais regrasFiscais, ...) {
    // ...
  }

  public double calcula(Funcionario f) {
    if(f.getCargo() == Cargo.VENDEDOR) {
      // calcula salario do vendedor usando regras fiscais, etc
    }

    if(f.getCargo() == Cargo.GERENTE) {
      // calcula salario do gerente usando regras fiscais, etc
    }
  }
}

Agora suponha que um novo cargo apareceu na empresa e precisamos calcular o salário das pessoas que farão o trabalho desse novo cargo. O código mais simples que faria isso acontecer, seria:

public class CalculoDeSalario {

  public CalculoDeSalario(RegrasFiscais regrasFiscais, ...) {
    // ...
  }

  public double calcula(Funcionario f) {
    if(f.getCargo() == Cargo.VENDEDOR) {
      // calcula salario do vendedor usando regras fiscais, etc
    }

    if(f.getCargo() == Cargo.GERENTE) {
      // calcula salario do gerente usando regras fiscais, etc
    }

    if(f.getCargo() == Cargo.MARKETING) {
      // calcula salario do marketing usando regras fiscais, etc
    }
  }
}

Mas essa não é a melhor solução que resolveria o problema. A cada novo if inserido nesse código, mais longe estamos da melhor solução. O design fica cada vez mais rígido. E pior: refatorar esse trecho de código fica cada vez mais difícil: até mesmo o segundo if que foi adicionado ao código já havia o afastado da melhor solução!

Ao implementar uma nova funcionalidade, o programador deve observar o design atual da sua aplicação. Se o design atual já provê uma maneira fácil de implementar a funcionalidade, então vá em frente. Caso contrário, o programador deve refatorar o design para permitir que você possa adicionar essa funcionalidade da maneira mais simples possível.

No exemplo acima, uma solução seria criar uma estratégia (do padrão de projeto Strategy) para calcular o salário de acordo com o cargo. Cada cargo seria responsável por devolver o seu algoritmo de cálculo. Por exemplo:

public class CalculoDeSalario {

  public CalculoDeSalario(RegrasFiscais regrasFiscais, ...) {
    // ...
  }

  public double calcula(Funcionario f) {
    AlgoritmoDeCalculoDeSalario calculadora = f.getCargo().getAlgoritmoDeCalculo(regrasFiscais);
    return calculadora.calcula();
  }
}

Se essa é a melhor solução, é difícil dizer. Mas com certeza ela é uma solução melhor do que as anteriores. Mas, veja que após essa refatoração, implementar o cálculo de salário para o novo cargo é muito mais fácil. Agora posso voltar aos meus baby steps, já que a implementação corrente está em um lugar seguro.

Toda essa experiência se resume a uma frase que surgiu em uma conversa entre Guilherme Silveira e Maurício Aniche:

A mudança mais simples para resolver um problema não é necessariamente a solução mais simples para resolvê-lo.

Problema: Ao fazer isso, o desenvolvedor acaba enviesando a estimativa dessa estória. Frases como essa durante a estimativa inibem os outros desenvolvedores e fazem com que eles escondam a sua opinião (pois, se o desenvolvedor experiente tem tanta certeza que a estória tem 3 pontos, ele deve estar certo, e eu devo estar errado; o problema que eu havia imaginado não deve existir…).

Solução: A estimativa acontece em grupo justamente para tentar diminuir o seu possível erro. Além disso, estimar em grupo ajuda a levantar melhor os possíveis problemas que a equipe irá passar durante a implementação da estória, afinal nesse momento temos uma equipe inteira pensando, e não só apenas uma pessoa.

Não só o desenvolvedor mas também o Product Owner (ou clientes dependendo de sua abordagem e metodologia) costuma utilizar palavras como “fácil” ou “simples” para descrever uma história. Qualquer tipo de adjetivo do gênero pode trazer um peso decisivo na hora de julgar a dificuldade da estória. Durante os treinamentos de Scrum e Lean, no momento de explicar uma história, adjetivos surgem a todo instante por parte do PO.

Todos os participantes mostram suas estimativas juntos, justamente para que um desenvolvedor não influencie na opinião do outro, e as ideias possam surgir mais livremente e serem discutidas. Mesmo o desenvolvedor iniciante pode ver problemas ou soluções que um desenvolvedor mais experiente não enxergou. Mas, por saber que ele é iniciante, ele é mais facilmente influenciado pelos experientes!

Portanto, por mais simples e clara que a história possa parecer para você, faça o planning poker (ou qualquer outra técnica para estimar) da maneira correta. Estime junto com o time. Deixe a estimativa emergir do time todo. Se o objetivo da estória estiver realmente claro, o time não vai levar muito tempo para chegar em um acordo sobre a estimativa.

Sintoma: no dia a dia o cliente envia emails perguntando a situação de determinada história e o andamento do projeto completo. Os desenvolvedores tem grande parte de seu tempo diário consumido para fazer um relatório de situação, ao invés de focarem em seu trabalho principal, o desenvolvimento.

Ação: como cliente sempre surge um desejo natural de entender a situação atual do que foi contratado: desejamos ter uma previsibilidade do que irá acontecer a curto prazo, mesmo que imprecisa.

Ao contratarmos um serviço de reforma, desejamos saber se o encanamento está pronto para que passemos a execução da pintura da parede. Se algum problema mais grave ocorrer, é importante que o cliente saiba logo para não ser pego de surpresa quando do atraso do projeto.

Em todos os cenários, é importante para o cliente conhecer o andamento do projeto para que, quando o mesmo não esteja andando, isto é, um impedimento esteja presente, possa ajudar a resolver o problema de alguma forma.

Tudo isso acelera o ciclo de feedback da situação do projeto para o cliente e um dos recursos mais comuns para isso é o uso do gráfico de Burndown. Nele plotamos os pontos a serem desenvolvidos na iteração atual, e decrescemos o mesmo a medida que as histórias são aprovadas de acordo com o conceito de pronto.

Na iteração atual desenhamos a linha média de acordo com a velocidade esperada. Enquanto estivermos acima da média.

Da mesma maneira, no lado positivo, caso o andamento seja melhor do que o esperado, o cliente pode rapidamente se preparar para dar novas informações sobre o que será feito durante o tempo livre nessa iteração.

Em uma iteração comum, o início da aprovação demora um pouco pois as histórias tem que ser terminadas e a partir de então os pontos são entregues.

Por fim, o gráfico pode indicar diversos impedimentos e basta bater o olho para perceber algum tipo de problema. O que há de estranho na iteração a seguir?

Nesse exemplo, as histórias finalizadas demoram para ser aprovadas: repare a barra horizontal onde as histórias podem estar terminadas aguardando aprovação.

A barra horizontal indica um momento de pausa na entrega, que estava indo bem até então: diversos fatores podem causar essa pausa. No caso dessa equipe e iteração, podemos verificar em um outro gráfico que as histórias eram entregues mas o tempo para aprovação era longo.

O perigo dessa pausa é chegar muito próximo ao fim da iteração e a entrega ser sempre parcial, nunca completa pois após a avaliação ser feita não há mais tempo na iteração para fazer as correções devidas.

Outro motivo comum para uma linha parada é a história não ser aprovada por falta de compreensão no momento da execução. Em uma equipe que segue Scrum, o Scrum Master é responsável por acompanhar e detectar tais impedimentos, além de ajudar a equipe a resolvê-los.

Equipes maduras que gerenciam seu próprio trabalho e lidam com seus próprios problemas são responsáveis por fazer tal acompanhamento, identificar e solucionar os problemas e seus impedimentos através de praticas ágeis que visam entregas de qualidade.

Ter esses gráficos em mãos no momento necessário e ser capaz de entender o que eles dizem é fundamental para um time tirar seus impedimentos da frente: seja através de seu scrum master ou de suas próprias mãos.

Sintoma: durante o processo de desenvolvimento de uma funcionalidade, a equipe se direciona ao Product Owner ou cliente para tirar dúvidas, mas o mesmo se encontra frequentemente ocupado e não pode responder. Quando o PO está livre, a equipe está concentrada em outra tarefa.

Ação: crie uma lista de discussão envolvendo todos os interessados no projeto (Product Owner, desenvolvedores, User Experience, clientes envolvidos com aceitação etc) e envie um email para a lista.

Deixamos de lado a antiga “pastelaria” que exigia disponibilidade dos desenvolvedores no exato instante do aparecimento de uma necessidade, tudo era “para agora”. O mesmo vale para o Product Owner e qualquer outro ser humano em seu trabalho.

Apesar de muito desejado, é impossível exigir que no exato instante que surge uma dúvida da equipe de desenvolvimento, o Product Owner esteja disponível para conversar.

Vale lembrar que o email é uma comunicação assíncrona que leva mais tempo para obter resultados, além de ter chances de ser mal compreendido, portanto a primeira maneira a ser abordada para resolver um problema deve ser sempre a cara a cara com o PO.

Lista de discussão de um projeto/produto. Criar uma lista de discussão leva 2 minutos e permite receber feedback da primeira pessoa disponível, além de facilitar a busca por conversas quando novos membros entrarem.

Como o problema é a escassez de tempo de um indíviduo específico do qual esperamos uma resposta, o envio para uma lista que envolve PO, UX e clientes diminui o tempo no escuro, sem feedback. Para evitar uma discussão, faça perguntas diretas que esperam respostas fechadas, por exemplo:

Bom dia,

Estamos com uma dúvida em relação a listagem de contas atrasadas.
As com mais de um mês de atraso devem aparecer com outra cor,
conforme o padrão da tela de faturas?

Nesse caso um mês é considerado 30 dias, correto? Ou precisamos ter precisão de dias de acordo com o mês?

Caso a pergunta enviada seja um pedido de aprovação de história, inicie a próxima história até receber o feedback da mesma:

Bom dia,

As histórias A e B foram finalizadas e estão aguardando aprovação.

Caso a pergunta permanença em aberto sem resposta mesmo após o envio de um email, procure a conversa pessoal novamente: também é nosso papel como desenvolvedor conseguir a resposta, removendo impedimentos.

Veja também: prefira terminar a começar outra história.

Sintoma: Próximo ao término do ciclo de desenvolvimento (um sprint ou similar) todas as histórias estão marcadas como terminadas, resultando em uma sensação de sucesso. Mas durante a revisão das histórias pelo Product Owner, o número de recusas por detalhes pequenos é muito grande, e o número de aprovações é muito pequeno.

Ação: Mesmo que o ciclo de desenvolvimento seja curto – por exemplo 2 semanas – esperar o último momento para pedir aprovação é adiar as recusas e impedir as correções a tempo, algo potencializado em métodos waterfall.

O momento de pedir o feedback do cliente é assim que a equipe de desenvolvimento colocou a mesma em homologação (veja deploy contínuo e one click homologa).

Para quem utiliza um quadro físico, adicione nesse instante uma coluna de aprovação pelo cliente, para que o critério de pronto dependa da aprovação, que será recebida durante o ciclo de desenvolvimento.

Quadro físico com coluna de "aguardando aprovação"

Quando utilizar um sistema de tickets, crie um estado equivalente “a aprovar”, que mostre a pendência de aprovação:

Quadros digitais com estado de aprovação

Quando parar: Após criado esse estado ou coluna, com o passar do tempo, é natural que o processo de pedir aprovação durante o ciclo se transforme em algo cotidiano.

Nesse momento é possível remover tal coluna novamente pois o mesmo já passou a fazer parte do dia a dia da equipe.

Por mais de dois anos, a Caelum tem feito um esforço sobre cortar diversos tipos de débitos técnicos, incluindo levar práticas ao extremo, como testes end-to-end em grid.

Uma forma de enxergar que devemos melhorar o processo de desenvolvimento é verificar que perdemos dinheiro ao tomar decisões ou muito cedo, ou tarde demais.

O descuido gera débitos que cortam a produtividade de sua equipe. Também o excesso de cuidado, gera muitas trocas de decisões, visando o preciosismo técnico, pode levar a um atraso muito grande.

Além disso, uma empresa que espera 4 meses para colocar algo em produção pode ser uma empresa 4 meses atrás de seus concorrentes. Entregar valor tardio é ficar para trás.

Mas o que causa empresas ágeis a não entregar tão frequentemente?

Muito produtos criados em ambientes ágeis só são colocados em produção depois de muito tempo. Durante todo esse tempo, os únicos a testarem e aprovarem as funcionalidades são a equipe de QA e o Product Owner. Ao colocar este produto em produção depois de um ciclo tão grande, o cliente final vai encontrar os problemas que costumavam aparecer em metodologias tradicionais.

No lado gerencial, o Product Owner apresenta dificuldades em priorizar seu backlog de maneira a entregar valor, acabando por entregar funcionalidades. Além disso, é dificil aceitarmos algo “incompleto para o uso mínimo” e, na visão de quem é dono de um produto, o “mínimo necessário” acaba sendo maior do que o real e nunca é atingido para ser colocado em produção. É aí que seu projeto para: ele ficara sem entregas durante muito tempo.

Existe uma prática bem simples para um PO executar e perceber se possui essas dificuldades. Olhe seu penúltimo sprint e veja as funcionalidades que já estão sendo utilizadas por seu cliente. Agora jogue na fórmula:

GPD = (salario da equipe * pontos_desnecessários) / pontos_do_sprint

GPD é o Gasto que você teve com Priorização Desnecessária durante o penúltimo sprint. Ser ágil é entregar valor, e seus pontos estão sendo utilizados em funcionalidades completas sem tanto valor. Se existiam outras tarefas que entregavam valor para os usuários, a priorização poderia ter sido melhor.

Outra possível melhora na parte gerencial está na execução de testes somente por QAs e POs: o feedback não vem do cliente final. Devemos entregar cedo e frequentemente para receber feedback real, e não apenas do PO. Mas como alcançar isso se o produto possui um conjunto mínimo de funcionalidades, que é razoavelmente grande, para entrar em produção?

Assim como diversos ramos de software, adote o conceito de usuários beta. Ele possuem acesso a suas funcionalidades mais cedo, em servidores suficientemente estáveis que acessam dados de produção, rodando a última versão de seu produto, mas com o risco de algo dar errado. O conceito de beta potencializa a propaganda do seu produto, podendo criar uma legião de fanboys.

Na parte técnica, desenvolvedores tem percebido cada vez mais a importância de todos tipos de testes automatizados, controle de versão, integração contínua e outras práticas com base em XP, mas outra causa ainda mais comum de problemas em diversas empresas é o truck factor. Se durante a reunião de planejamento alguém responde que determinada tarefa é dele – pois ele “conhece mais aquela parte do sistema” – ou se alguém é o único que vota os pontos de parte do sistema; ou ainda se é comum esperarem por alguém para executar qualquer tarefa, está na hora de compartilhar mais o conhecimento e acabar com esse impeditivo antes que o truck acabe com ele. Parear e ensinar mais o que conhecemos permite que, ao invés de produzirmos por nós mesmos, diversas pessoas produzam através do que compartilhamos. Essa é a mágica do ensino, levado ao pareamento. Não parear por causa daquela parte ser responsabilidade de uma única pessoa é um paradoxo! É justo esse tipo de caso que mais ganha vantagens do pareamento.

O outro fator para desenvolvedores e sysadmins se perguntarem é quanto tempo leva para fazer deploy? Alguns dias? Se sim, a metodologia ágil que foi alcançada perdeu grande parte do seu valor pois o feedback rápido virou feedback semanal ou ainda mensal.

Apesar de processos de build automatizados junto com integração contínua serem importantes, deploy contínuo é cada vez mais fundamental.

Essas e outras práticas, gerenciais ou técnicas, servem para encontrar o que está implicando na não-entrega de valor ao cliente. Depois de detectado esse gargalo, devemos agir para melhorar nosso processo de desenvolvimento.