Scrum - Extreme Programming, programação em pares e testes

Por Cesar Brod

Data de Publicação: 10 de Março de 2015

Na absoluta maioria das vezes em que ministro treinamentos, participo de oficinas ou palestro sobre Scrum, o faço para um publico voltado ao desenvolvimento de software. Já tive gratas experiências, porém, de guiar oficinas de Scrum para o desenvolvimento de outros produtos e serviços, em especial para o pessoal da AISEC Porto Alegre.

No ambiente de desenvolvimento de software, sempre friso que o Scrum não funciona sozinho. Ele é um conjunto de atitudes apoiado por papéis, ritos e artefatos que deve ser associado a boas práticas de engenharia. Ainda que o Scrum não prescreva quais devem ser essas práticas, por uma questão histórica, é natural que o Extreme Programming (XP), seja adotado.

É do XP que vêm as práticas de programação em pares e de desenvolvimento orientado a testes:

• Dois desenvolvedores, usando um único computador - passado um curto período inicial de estranheza - produzem código de melhor qualidade, com maior produtividade do que se estivessem trabalhando isoladamente.
• Ao se pensar nos testes pelos quais um produto de software deve passar - e escrevê-los antes de escrever o código de produção - melhora-se a qualidade do software e reduz-se, absurdamente, a quantidade de bugs que atingem os usuários finais.

Já há inúmeras evidências dos bons resultados trazidos pela adoção dessas práticas e, ainda assim, elas são de difícil adoção.

A dificuldade de se trabalhar em pares tem duas origens. A primeira vem da própria formação do desenvolvedor, muitas vezes com uma grande capacidade de aprender e desenvolver sozinho. A segunda vem da antiga percepção das linhas de montagem e estilos de organização ultrapassados, onde se imagina uma pessoa especializada na sua ferramenta e processo. Lembre-se da constatação do manifesto ágil: os indivíduos e suas interações são mais importantes que processos e ferramentas.

Quanto ao desenvolvimento orientado a testes, é relativamente fácil fazer com que a equipe entenda que os requisitos devem ser definidos como histórias de usuário (user stories) e que a verificação destas histórias corresponde aos testes de aceitação. O difícil é vencer a resistência dos desenvolvedores à escrita dos testes unitários antes da escrita do código de produção, por mais que existam provas da eficácia dessa prática.

Em equipes novas, em especial em startups, tenho conseguido vencer a resistência à programação em pares pedindo um voto de confiança à equipe e observando que, após dois ou três Sprints, ela mesma passa a concordar com os benefícios da prática. Quanto aos testes unitários, isso leva mais tempo. Insisto para que, quando um bug é encontrado, que seja escrito um teste que o detecte antes que a solução seja codificada. Desta forma, a equipe começa a perceber que a dívida técnica diminui na medida em que a cobertura de testes unitários aumenta.

Em equipes mais antigas, tipicamente divididas em cargos especializados antes da adoção do Scrum, trazer aqueles que ocupavam funções de testadores, analistas de qualidade ou similares para parear com desenvolvedores costuma acelerar a escrita dos testes unitários e melhorar as historias de usuários para que elas fiquem mais atômicas, fáceis de se tornarem testes de aceitação.

Não custa repetir: a adoção do Scrum e de métodos ágeis implica na quebra de estruturas organizacionais departamentalizadas e na redução de níveis hierárquicos. Por isso, é necessário o suporte da cúpula das empresas e o compromisso de todos os envolvidos.