Scrum em grande escala

Por Cesar Brod

Data de Publicação: 03 de Dezembro de 2015

Ainda que o Scrum tenha sido apresentado ao mundo em 1995 (Jeff Sutherland criou o framework em 1993), foi em 2012 que ele atingiu seu "tipping point" e sua aplicação tomou proporções avassaladoras. Mais recentemente tenho sido consultado sobre a aplicação do Scrum em projetos muito grandes, mas isso também não é uma coisa nova.

Em 2002 Mike Cohn publicou sua introdução ao Scrum, que traduzi para o português. Nela, Mike aponta que a escalabilidade é garantida por Scrums de Scrums, sempre com cada time Scrum formado por sete mais ou menos duas pessoas. E, ainda que Mike não explicite isso na sua apresentação, cada time fica responsável por uma função do grande sistema em desenvolvimento.

Aqui, chamo de função um conjunto de histórias relacionadas umas às outras (ou que componham um épico), de acordo com a percepção do cliente ou dos usuários, conforme a visão comunicada pelo Product Owner. Para mais informações, leia esse artigo do Roman Pichler.

Ou seja, não há segredo. Se o projeto for muito grande ele fica incontrolável. É necessário dividí-lo em funções com interfaces claras (e muito bem combinadas) entre si. É, de novo, a filosofia do Unix que, dentre outras coisas, prega que cada programa deve fazer apenas uma coisa, mas muito bem. A saída de cada programa, porém, pode servir de entrada para outro.

Existem, porém, algumas abordagens distintas à escalabilidade do Scrum. O framework LeSS, criado pelos agilistas Bas Vodde e Craig Larman; o SAFe, concebido por Dean Leffingwell; o intricado DAD do Scott Ambler; e o Nexus, desenvolvido pelo Ken Schwaber, um dos pais do Scrum, junto com o pessoal bacana do Scrum.org.

Se você tem um projeto muito grande no qual quer aplicar métodos ágeis de desenvolvimento, recomendo que comece pela leitura do Nexus Guide e assista o vídeo introdutório do Craig Larman sobre o LeSS.

A questão é que há empresas e equipes que querem aplicar o Scrum em sistemas legados antigos, enormes, que não foram concebidos usando métodos ágeis e, nesse caso, para evitar frustrações é preciso entender, de imediato, que uma grande refatoração de código será necessária.

Há muita literatura sobre o trabalho com sistemas legados, incluindo o excelente livro do Michael Feathers mas, obviamente, não há bala de prata. Eu gosto de identificar a função mais crítica do sistema a ser migrada (sempre há uma dor maior no meio das muitas dores) e começar por ela. Para isolar essa função, muitas vezes é necessário escrever uma API (uma interface que permita a troca de informações entre o sistema em funcionamento e a função que está sendo reescrita) que permita tal isolamento. Nem sempre é trivial, mas nunca é impossível e, uma vez feita para uma função, fica muito mais fácil de fazer isso com as demais.

Faço uma analogia com a máquina coração-pulmão usada em cirurgias de peito aberto. Uma interface é aberta antes e depois do coração e o sangue passa a circular com o auxílio de uma bomba externa, até que o coração seja "refatorado". O pulmão também tem que parar porque é muito ruim ficar refatorando um coração com um pulmão se mexendo por baixo dele, assim um oxigenador externo também é providenciado. Ora, se é possível fazer isso em um ser humano, porque não seria possível usar uma técnica semelhante em um programa escrito em Cobol?

As novas funções já nascem com essa capacidade de comunicação, através de interfaces bem definidas, tanto com o sistema legado quanto com outras funções que vão sendo reescritas. Na medida em que a prova de conceito é validada (uma função) com uma equipe Scrum, agora duas ou mais equipes podem cuidar, simultaneamente, de mais funções. Verificado o sucesso e, dependendo do tamanho do sistema, tantas equipes quanto necessárias podem trabalhar simultaneamente, sempre em comunicação plena e transparente, para acelerar o processo de migração.

É bom aproveitar esse processo para ir migrando a equipe, tipicamente monolítica e hierarquizada, que trabalha com o legado, para times Scrum cuidando das mais diversas funções. É a hora de capacitar e motivar as pessoas para trabalhar com métodos ágeis, tornando-as mais produtivas e, especialmente, mais felizes.

Lembre-se sempre do primeiro item do Manifesto Ágil: pessoas e suas interações são mais importantes que processos e ferramentas.