Eu tenho visto um grande número de times em nossa empresa se matando para adotar um Desenvolvimento Orientado a Testes (Test Driven Developement -TDD)[1]. Ocasionalmente um ou dois desenvolvedores obtém sucesso sem ajuda alguma, mas a maioria não. Para melhor compreender o problema fiz uma série de pesquisas com os membros dos times e cheguei a conclusão que mesmo após o treinamento em sala de aula, ainda havia muito a ser feito. Esta estratégia planejada foi desenhada para ajudar qualquer um que queira implementar TDD dentro de uma empresa, porém alguns destes problemas e idéias são aplicados somente em empresas de média e larga escala.
Minha pesquisa com os membros do time (onde todos receberam treinamento) revelou estes bloqueios:
- Pessoas acham difícil aplicar TDD em seu desenvolvimento, quando elas não possuem muita experiência com isto.
- O Treinamento em TDD tem sido muito focado em problemas mais simples do que na vida real.
- É preciso mais tempo para experimentar e testar sem a pressão corriqueira de liberar o software em uma data específica.
- Linguagens utilizadas no mundo real, como Visual Basic ou JavaScript, nunca são utilizadas como exemplos em documentação de testes unitários ou exercícios em classe de aula.
- A média de código é totalmente de código legado, e nenhum treinamento foi dado sobre como trabalhar com este tipo de código.
- Nunca a tempo de aprender – existe sempre (artificial) uma pressão para entregar o produto o mais rápido, de forma que não há tempo para melhorar o código.
Problemas Reais
Com todos estes sintomas, quais são os problemas reais?
Test Driven Development pode ser muito difícil de aprender. A fase de aprendizagem (a duração de tempo até que se torne um hábito latente) tipicamente dura de dois a quatro meses, tempo cuja produtividade é reduzida [2]. Geralmente os benefícios serão óbvios e a técnica é geralmente auto sustentável, mas a questão é: como chegar lá? Muitos desenvolvedores desistem após somente alguns dias.
A maioria das estratégias de adoção que tenho visto foca em treinamento em sala de aula (ou e-learning) e mentoring um-a-um. Quando bem feito, estas são ferramentas excelentes e pode fazer parte de uma solução, mas eu acho que é necessário mais.
Treinamento em sala de aula sofre por conta de dois problemas chave: os exemplos são muito fáceis e não se relacionam com problemas reais; e não há muita chance de praticar.
Treinamento online (tanto Object Mentor e Industrial Logic, entre outras, tem benefícios), tem a vantagem de ir mais a fundo. Entretanto, ainda assim não existe a chance de praticar. Em compensação, estes cursos são normalmente realizados sem a interação com outros estudantes. Ouvir questionamentos de outros estudantes e colegas de classe geralmente ajudam na compreensão.
Mentoring um-a-um não escala além de poucos membros de um time. Isto é especialmente difícil em um ambiente corporativo de larga escala onde existem somente alguns poucos especialistas e centenas ou milhares de pessoas precisando de ajuda.
Livros são uma opção excelente mas somente alguns desenvolvedores gostam de ler livros a respeito de seu trabalho, e mesmo aqueles que se propõe a aprender TDD desta maneira, tem dificuldades. Como em cursos online, o problema é aprender por sua conta e risco.
Finalmente: código legado torna um problema que já é difícil ainda mais duro. Desenvolvedores certamente perguntam a seguinte questão: “Como eu faço para testar estes objetos altamente acoplados? Este código é complicado, como eu testo este algoritmo?”
Uma Abordagem
Então, o que funciona? As abordagens anteriores sofrem por duas causas chave: falta de profundidade e falta de colaboração. Uma estratégia completa irá apelar para múltiplos modos de aprendizagem e possui muitos elementos.
-
Treinamento em Sala de aula -
Desenvolvedores precisam de uma introdução ao TDD, e treinamento em classe de aula é ainda a melhor opção para a maioria das pessoas. O truque é entender que treinamento por si só, não irá fazer com que as pessoas adotem o TDD.
-
Treinamento Online -
Irá ajudar a absorver as idéias básicas. Se um passo nesta jornada for opcional, este poderia ser o item.
- Paciência -
este vai tomar mais tempo do que o planejado.
- Medida -
utilizar ferramentas para cobertura de código (ex.: Emma, Cobetura, NCover, ...) e explicar aos membros do time que medição será uma maneira de dizer se as coisas estão indo melhor ou pior. Obviamente isto não mede a qualidade do teste e precisa ser feito com certa dosagem.
- Instigar Orgulho -
Desenvolvedores precisam saber que código simples e claro e testes são similares, e eles precisam saber que vale a pena o esforço de produzi-lo. Bob Martin escreveu um livro chamado “Clean Code” que esclarece muito bem isto.
- Gerenciamento - Desenvolvedores precisam de um sinal claro da gerência que eles entendem que a transição para o TDD irá levar tempo e “diminuir” o rendimento do time[3]. Eles precisam tornar claro que eles valorizam a qualidade vs toda a falta de velocidade e o acumulo de débito técnico. A maioria dos desenvolvedores se sente pressionada para produzir, produzir e produzir. O gerenciamento terá que provavelmente repetir este entendimento mais de uma vez. Quanto mais alto for a área que este enunciado for emitido (preferivelmente executivos nível C), mais as pessoas irão escutar.
- Programação em Par -
Se você se encontrar atolado e não saber para onde ir, um parceiro geralmente pode ajudar, mesmo fazer par com outro novato já pode ser um bom começo.
- Comunidade -
Crie uma comunidade com a sua empresa (ou cidade) para compartilhar as experiências. Um local para fazer network com outras pessoas que estão aprendendo a aplicar TDD, para aprender de outros os sucessos e insucessos. Um local para ajudar a disseminar a cultura para o TDD. Uma oportunidade de compartilhar novas idéias.
- Coding Dojo –
Um local para praticar em conjunto a solução de um pequeno problema. É um ambiente seguro, colaborativo com ênfase na exploração de um problema como um grupo e não necessariamente em como resolvê-lo.
- Workshops de Leitura –
Um grupo de não mais que oito pessoas, para juntas regularmente se encontrarem para discutir um capítulo de algum livro.
- Visitas periódicas de um Coach - pode ajudar o time a voltar aos eixos, quando eles saírem do trilho e pararem de praticar TDD. Nestes casos somente emparelhando com uma ou duas pessoas pode ajudar a re-infectar todo o time.
A idéia base deste plano é o seguinte: criar conversações e aumentar a colaboração em torno do TDD. Três destas estratégias são focadas nesta área: Programação em Par, Coding Dojo e um Workshop de Leitura.
Coding Dojo
O Coding Dojo (utilizando o Formato Randori) é um evento onde um pequeno grupo de pessoas (max. 15), resolvem um problema utilizando TDD (adaptado de Danilo Sato):
- O trabalho é feito em um computador com a tela projetada para que todos vejam.
- Codificação é feita em pares
- Um membro do par troca a cada 5-10 minutos (7 funcionou bem para nós).
- Os codificadores devem explicar o que eles estão fazendo, dessa maneira a platéia entende o que está acontecendo no teclado.
- A platéia deve somente comentar sobre o design quanto os testes rodarem claramente. Quando os testes estiverem falhando a platéia deve fazer perguntas.
- Se a audiência esta confusa, o trabalho deve parar e os codificadores devem explicar o que esta acontecendo.
Por experiência eu recomendo que você escolha um problema bem pequeno para começar.
Workshop de Leitura
Para os Workshops de Leitura existe um grande número de boas opções para livros:
-
-
- conforme você for aprendendo mais, xUnit Test Patterns: Refactoring Test Code de Gerard Meszaros.
- e se o seu código não foi desenvolvido com TDD: Working Effectively with Legacy Code de Michael Feathers.
Tipicamente, os times tentam cobrir um ou mais capítulos em uma sessão. O processo é devagar o bastante para que as pessoas possam ler fora do trabalho, sem que isto se torne um peso. Além disso, isto permite tempo suficiente para uma discussão mais aprofundada de poucos itens em um capítulo.
Os Benefícios de Aprender em Conjunto
Ambos workshops devem ter um fornecimento de pizza (ou uma opção de lanche mais saudável) – você está pedindo para que as pessoas gastem o seu tempo fazendo algo relacionado a trabalho, elas precisam de um incentivo. Os dois workshops podem alternar as semanas, desta maneira as pessoas não sentem que estão encurraladas em um beco. Finalmente não espere os mesmos membros de um grupo em toda sessão.
Workshops e comunidades são uma melhoria do aprendizado direcionado porque os membros do grupo estão engajados na conversação e colaboração. Como resultado nós aprendemos sobre coisas que normalmente não consideraríamos.
Tornando TDD Simples
Resumindo, aqui estão os pontos que identifiquei para criar uma estratégia de adoção de sucesso:
- Paciência, Prática, Aprofundamento
- Suporte da Gerência
- Abordagem em múltiplas vertentes
- Desenvolvedores ajudando desenvolvedores
Esta abordagem já esta em uso, trabalhando para melhorar a adoção de TDD dentro de uma grande empresa.
Agradecimentos para Lasse Koskela, Nat Pryce, Dave Nicolette e Dave Rooney por cederem seu tempo para revisar os esboços deste artigo.
Notas
[1] Para os propósitos deste artigo, TDD é o habito de escrever os testes antes de codificar e trabalhar em pequenos incrementos. E não produzir um grande número de testes Unitários após o código estiver escrito.
[2] http://tech.groups.yahoo.com/group/testdrivendevelopment/message/29461
[3] Produção atual irá cair - ex. o numero de estórias entregues em uma iteração irá reduzir. Entretanto uma vez que a qualidade irá melhorar logo após o inicio desta prática a queda não irá ser percebida.
Sobre o Autor
Mark Levison
é consultor principal na Pure Agile Consulting, uma empresa de consultoria Agile e Lean que foca em ajudar seus clientes a entregar software funcional a cada duas semanas. Mark tem sido um praticante de Agile desde 2001, introduzindo uma prática de métodos Ágeis por vez em um time pequeno. Nos últimos três anos, como funcionário de uma grande ISV, ele esta sendo responsável por introduzir Scrum na empresa e fazer coaching em um número de times – incluindo o design de uma estratégia de Test Driven Development e a introdução de um número de práticas para suportar isto. Mark é Editor Agile na InfoQ e tem escrito dezenas de artigos sobre o tópico Agile. Ele também publica um blog – Notes from a Tool User. Quando não está em frente a um computador, Mark passa seu tempo com sua esposa e duas filhas.