O evento Agile 2011 aconteceu em Salt Lake City e contou com um misto tracks da indústria e da academia. Junto com o Maurício Aniche foi possível aprender um pouco mais da visão de cada lado, além de presenciar exemplos dessa rica experiência de prática e teoria.

A Caelum apresentou o resultado de uma pesquisa interna com seus instrutores de como funciona o aprendizado, qual seu papel e como ele acontece dentro da empresa.

Um workshop acadêmico muito interessante discutia e apresentava de forma didática a questão das decisões técnicas adequadas: qual é a importância da qualidade do nosso código? O grupo de arquitetura da Carnegie Mellon criou um simples jogo de tabuleiro, o Hard Choices. É uma forma fácil de você apresentar ao seu chefe o custo/benefício de utilizar gambiarras, evitar testes e o cowboy coding.

Três ou quatro jogadores começam na posição Start de um tabuleiro. A cada rodada, um jogador rola um único dado e pode anda o número de casas de acordo. Ao tirar um 5, por exemplo, ele pode andar cinco casas para frente, ou quatro casas para frente e uma para trás, ou cinco casas para trás: isto é, ele pode misturar passos para frente e para trás. Ao terminar sua rodada, o jogador que parar em uma casa com ferramenta, ganha uma carta (que vale 1 ponto).

Por outro lado, o primeiro jogador que chegar ao final ganha 7 pontos, o segundo 3 pontos e o terceiro 1 ponto. Como pode ser interessante acabar em primeiro, existem alguns atalhos (pontes). Ao passar pela ponte, o jogador corta caminho (para frente ou para trás) e recebe uma carta de ponte. Enquanto o jogador possui essa carta, ele anda somente o número resultante do dado menos o número de cartas de ponte que possui. Por exemplo, se ele possui uma carta de ponte e tira 3 no dado, ele anda somente 2 casas.

Quando um jogador terminar o tabuleiro, todos os outros só podem andar para frente (usando, ou não, pontes). Para remover o peso da decisão de cortar caminho, em qualquer rodada o jogador pode ficar parado, trocando sua movimentação por jogar uma carta de ponte fora, voltando então a andar mais rápido (uma analogia a gastar tempo para refatoração e melhoria do código).

O jogo é bem simples e cada jogador usa táticas diferentes para acumular o máximo de pontos. Ele reflete já na primeira rodada a grande dúvida de todo processo de desenvolvimento: corto o caminho e chego antes, trocando isso por andar mais devagar daqui pra frente? Isto é, como desenvolvedor, faço algo negativo e assumo o prejuízo até o momento que julgar adequado? E quando será esse momento?

Matematicamente, o jogo é um modelo simplificado do que enfrentamos no dia a dia: cortar caminho afeta somente o jogador, enquanto no mundo real afeta todos os desenvolvedores. Também é possível quantificar o prejuízo no jogo, mas na vida real é difícil saber o quanto vamos perder em cada ação. Ao mesmo tempo, assumir o caminho do perfeccionismo pode levar muito tempo e não maximizar o resultado: a entrega de uma funcionalidade. Aqui sentimos o peso da dívida técnica. Em geralessa dívida consiste no tradeoff de entregar uma parte de uma implementação com menos qualidade do que a adequada, para depois melhorá-la. Os perigos estão, claro, quando não se paga a dívida e deixa a mesma acumular os juros, a ponto de se tornar muito caro qualquer mudança futura.

No QConSP três palestras abordaram a dívida técnica (ou débito, uma outra possível tradução) de projetos: “Refatoração em larga escala“, “Design de código: a qualidade que faz a diferença” e a “Dívida técnica: precisando de crédito?” (alguns autores traduzem como dívida técnica).

E você, qual tática você usaria no jogo? E no dia a dia como desenvolvedor? Quando abre mão da qualidade conscientemente e quando luta para recuperá-la?

Ainda há uma certa desconfiança quando se fala em ensino a distância. O que poderia torná-lo uma alternativa viável ao presencial?

Há 7 anos tenho o privilégio de trabalhar com a equipe da Caelum, buscando potencializar o aprendizado em uma sala de aula, trazendo a experiência do desenvolvimento. Questões de didática, colaboração com alunos, entre alunos, muitos exercícios e avaliação do código produzido são alguns pontos que consideramos cruciais para um curso.

Nos últimos meses, criamos nossa própria plataforma online, uma tentativa de levar para a internet tudo o que aprendemos nesses anos de ensino.
Experimentamos com vários amigos, alunos, desenvolvedores e instrutores. Focamos o aprendizado não só nos videos, textos e exercícios, mas sim na colaboração de todos os participantes. É importante que o aluno não esteja sozinho durante seus exercícios, dúvidas e comentários; para isso, ele contará com a ajuda não só do instrutor, mas de todos os seus colegas, afinal aprendemos muito quando trabalhamos em equipe.

O contato social – fundamental no aprendizado – é feito a todo instante, como ao assistir uma explicação, ao ouvir uma segunda explicação caso não tenha entendido, ao repetir uma das anteriores, etc. Seus colegas de sala, assim como diversos instrutores da Caelum, podem ser alcançados para requisitar feedback sobre o código criado, assim como em uma sessão de pareamento ou revisão de código (code review). Tudo de maneira assíncrona, sem necessidade de estar online em determinados horários.

Inicialmente, estamos oferecendo 3 novos cursos. Durante as próximas semanas, lançaremos os que já estão sendo produzidos, e vocês podem aguardar mais. Há 30% de desconto durante essa fase beta, além de um trial para o início de cada curso. Aguardamos feedback, dicas, críticas, sugestões e ideias para os próximos cursos. Veja como o sistema funciona:

Com novas tecnologias e práticas surgindo a todo instante, espero encontrá-lo na nossa sala de aula, para juntos aprendermos, discutirmos e criarmos software de qualidade no Brasil.

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.

Mas em diversos momentos existe a tentação de criar branches, linhas separadas de desenvolvimento, para cada funcionalidade: um feature branch, em cada um deles um conjunto de desenvolvedores trabalha de maneira isolada. O problema de desenvolver muito tempo sem integrar é que no momento que um feature branch terminar integrando-se ao mainline, os outros branches terão um processo de merge grande e custoso a ser feito.

Variações do “feature branch” são branches por cliente, onde cada um possui um conjunto distinto de funções que está disponível. Gerenciar esse trabalho é difícil e propenso a erro como por exemplo quando bugs que são corrigidos em determinados branches não são passados para outros. Para mantermos os benefícios da integração contínua, tentamos minimizar o impacto dos feature branches e encontrar uma maneira de remover o efeito negativo dos mesmos, mantendo os benefícios.

Se o branch vive menos de um dia, por exemplo, a prática de feature branches não vira uma discussão: o merge e seu respectivo impacto é pequeno, não é necessário se preocupar com o impacto dessa decisão na integração contínua pois o tempo no qual a integração não é contínua é relativamente baixo.

Por outro lado, existem dois possíveis motivos para um branch viver mais de um dia. O primeiro deles é o de criar uma história muito grande, que para ser implementada é necessário muitas horas de trabalho. A solução aqui é simples: quebrar as histórias em pedaços menores permitirá que os desenvolvedores terminem mais cedo algo entregável que possivelmente resultará em feedback para os próximos trechos a serem criados.

O segundo motivo, mais complicado, é para manter um branch master (ou trunk) limpo que pode ser deployado para produção a qualquer instante. O motivo é justo e nobre uma vez que boas práticas como integração contínua andam de mãos dadas com entrega contínua e feedback frequente mas ao invés de criarmos um bloqueio para algo melhor (a integração contínua), é mais interessante ganhar o benefício de ambos.

Durante o tempo de compilação, build do artefato de deploy ou ainda execução podemos utilizar técnicas para não registrar componentes de funcionalidades ainda não prontos. O exemplo a seguir mostra como utilizar um container simples de injeção de dependências para controlar diversos ambientes com features distintas. Todos os métodos que retornam objetos do tipo Ambiente são utilizados por convenção:

public class Ambientes {
  public Ambiente desenvolvimento() {
    return homologacao().com(OpenIdLogin.class);
  }

  public Ambiente homologacao() {
    return producao().com(ExcelExport.class);
  }

  public Ambiente producao() {
    return new Ambiente(new Container()).com(ClienteController.class).e(ProjetoController.class).e(LoginController.class);
  }
}

Da mesma maneira, em aplicações web, arquivos jsp templates de qualquer template engine podem ser customizados para mostrar determinadas partes de acordo com o ambiente atual:

<feature name="OpenId">
  ... codigo html ...
</feature>

E em qualquer ponto do sistema é possível verificar a disponibilidade de uma feature:

public class LoginController {
  private final FeatureSet features;
  public LoginController(FeatureSet features) {
    this.features = features;
  }

  public Usuario login(Map parametros) {
    LoginFeature login = features.for(Login.class);
    return login.valida(...);
  }
}

Toggles limpos e bem elaborados como esses permitem total customização do seu sistema sem ser um peso tão grande no desenvolvimento. Outras opções de implementações menos rebuscadas mas tão eficientes quanto envolvem a simples leitura de arquivos de propriedades. Ferramentas como o envie adicionam suporte a feature toggles em qualquer ponto de uma aplicação. O mesmo container acima funciona em Ruby da seguinte maneira:

production = Envie.production.with(:oauth)
development = production.derive.with(:openid)

feature(:oauth) do
   # codigo que utiliza oauth
end

feature(:openid) do
  # codigo que utiliza openid
end

Utilizando tais ferramentas de toggle, que são baseadas na criação de enviroments, é possível automatizar o processo de oficialização de uma feature. Dada que a feature “openid” foi aceita, um script é capaz de adiciona-la no ambiente de produção, ou uma variação que removeria as definições de chamada ao métod feature, resultando em um código mais limpo a partir do próximo commit.

Feature branches e toggles são uma alternativa extremamente popular no desenvolvimento open source e muito bem feita em alguns projetos como o kernel do linux que pode ser construído utilizando inúmeras combinações. Testes de integração não são mais capazes de garantir o comportamento através de todas as possíveis combinações mas continuam adicionando valor.

Durante o www 2010, Ian Robinson descreveu como o Neo4j pode ser utilizado como alternativa para propragação da configuração de nós diferentes em clusters de máquinas de determinadas aplicações de larga escala na web. A abordagem de feature toggles como esses é interessante e positiva para projetos grandes que envolvem a constante necessidade de integrar funcionalidades ainda não aprovadas por completo e serve como segunda opção durante a utilização de feature branches. Também serve como solução simples para feature toggle por grupos de clientes.

A primeira regra no instante de criar um feature branch é: evite criá-lo. A segunda regra é, integre-o ao mainline o mais rápido possível.

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: o número de bugs novos que são abertos é maior do que o número de bugs fechados a cada iteração. O backlog é dominado por bugs e cada vez menos funções novas são adicionadas ao projeto.

Ação: Por muito tempo acreditou-se que aumentando o número de desenvolvedores aumentaria a produtividade de uma equipe em um projeto, crença hoje combatida pelos métodos ágeis.

O primeiro fator para combater a sensação de fracasso na luta contra os bugs é criar uma medida que incentive a equipe a melhorar a qualidade do código.

Uma maneira fácil de criar essa métrica é medir o número de bugs novos abertos e de bugs fechados no último ciclo. A cada ciclo novo meça novamente esses valores. A medida pode ser tirada automaticamente através da criação de plugins para determinadas plataformas online ou de maneira bem simples durante o review de seu projeto – manualmente.

Para aqueles que usam o pivotal tracker, o projeto Buggie integra com o processo de build e pode gerar os dados a cada novo build executado no servidor de integração, mantendo o gráfico sempre atualizado. A tabela a seguir mostra o gráfico de um projeto durante as seis meses, gerado com o Buggie:

Features sendo entregues e corrigidas continuamente até o momento da grande entrega de muitas novas funcionalidades: um grande impacto no número de bugs, mas em número absoluto é o mesmo que anteriormente.

Fica visualmente claro que os bugs vinham em um ritmo natural e corrigidos também da mesma maneira. Mas de repente uma avalanche de bugs aparece – e são corrigidos proporcionalmente. O feedback é instantâneo, e o time percebe que algo precisa mudar nessa parte do processo de desenvolvimento para melhorar a qualidade de seu código.

Para melhorar a qualidade do código devemos adotar práticas como o pareamento, mais comunicação com o cliente e evitar adivinhar como as funcionalidades deveriam funcionar. A análise do gráfico de bugs junto com o histórico da equipe nos diz o que acontece e o que podemos fazer.

Desafio para o leitor

1. Cite motivos pelos quais o time acima possui um acúmulo de bugs próximo a iteração 18?

2. Quais motivos levam outro time a ter um gráfico diferente, como o a seguir?

Executando a entrega contínua de um projeto, mesmo que sem o processo de deploy totalmente automatizado em um clique.

3. E o seu projeto controlado pelo Pivotal? Gere seu gráfico com o Buggie e envie via twitter ou email. Se preferir basta compartilhar o acesso ao pivotal.

Veja também: pontos de bug contam na velocidade de meu time?

A noite começou com o Adolfo Souza falando sobre os problemas resolvidos e em aberto em “O papel de QA em equipes ágeis” na Locaweb, com vídeo online:

Em seguida, tivemos o bate papo e explanação “Kanban: Você não precisa de iterações” do Rodrigo Yoshima.

Cecilia Fernandes e eu comentamos sobre a aplicação de restrições de processos ágeis em tipos diferentes de equipes dentro da Caelum na apresentação “Restrições são boas mas restrições são ruins“:

Após o lanche, a última apresentação foi do André Pantalião falando sobre “Erros e acertos na implantação de agile“.

Nas próximas edições, esperamos abrir mais espaço para as discussões, envolvendo outras abordagens que potencializam a discussão e participação do grupo. Vamos analisar e adaptar o próprio encontro para obter melhores resultados.

Para saber mais sobre os encontros, acompanhe o GUJ, blog da Caelum e o twitter dos desenvolvedores da Caelum. Nos encontramos na próxima Noite Ágil!