Scrum em grande escala #2: menos é mais

Por Cesar Brod

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

Em um livro lançado em 1975, Practical strategies for developing large software systems, o autor, Ellis Horowitz, menciona que um dos diretores do projeto SAGE discutia, em um seminário no MIT, a razão pela qual o trabalho de programação havia escapado do controle. Ele concluiu que, se tivesse que fazer tudo novamente, identificaria as dez melhores pessoas do projeto e faria com que elas trabalhassem, apenas elas, na programação do sistema.

A página da Wikipedia sobre o projeto SAGE conta que ele foi grandemente subestimado. Constituído por um sistema de grandes computadores em rede, o SAGE coordenava os dados de diversos radares e produzia a imagem do espaço aéreo de uma grande área e alimentava a defesa aérea americana com informações sobre possíveis ataques soviéticos durante a guerra fria. Ele envolvia milhares de pessoas e muitos centros de coordenação.

Craig Larman e Bas Vodde, em seu livro Practices for Scaling Lean & Agile Development - Large, Multisite and Offshore Products with Large-Scale Scrum basicamente recomendam (adaptação e tradução livre):

• projetos grandes, não os faça;
• projetos divididos em múltiplos locais, não os faça;
• projetos externos ou terceirizados, não os faça.

Dito isso, Craig e Bas passam a descrever a aplicação do Scrum em projetos de grande escala e detonar o mito de que métodos ágeis (como ainda dizem alguns) apenas aplicam-se a projetos pequenos, usando o framework LeSS - Large Scale Scrum.

A questão básica é entender qual deve ser o tamanho real de um projeto e aplicar, independente desse resultado, os valores, papéis, ritos e artefatos do Scrum a ele. E isso deve ser simples. Menos é mais.

Projetos costumam inflar por vários motivos. Quando comecei a trabalhar profissionalmente com software já existia a divisão entre o programador e o DBA, o analista de base de dados, o mago da otimização e segurança no acesso aos dados que permitia, ao programador, concentrar-se na "lógica do negócio". É óbvio que um arranjo deste tipo estava fadado ao fracasso e a inflação. A solução para isso piorou ainda mais a situação: o controle de qualidade, equipe de testes, QA ou outro nome bonito.

Ou seja, compartimentou-se o conhecimento entre programação e o acesso aos dados e, claro, sem um entendimento claro, sem o desenvolvimento de uma unidade sistêmica, conceitual, o código perdeu sua qualidade e, em vez de se resolver tratando de permitir que o desenvolvedor entendesse de tudo, criou-se mais um papel e mais canais de comunicação. Fred Brooks Jr. em seu O Mítico Homem-Mês já alertava que quanto mais pessoas em um projeto, mais ele atrasa, justamente em função da ampliação dos canais de comunicação.

Com as interfaces gráficas e, posteriormente com a web e dispositivos móveis, mais compartimentação aconteceu. Agora temos projetistas de interface, analistas de interação com o usuário, especialistas em experiência de usuário e, para que todos possam se comunicar, há gerentes de projeto, gerentes de produto, arquitetos de sistemas e por aí vai.

Esforços seguem subestimados e, com atrasos, quem paga a conta? O pessoal de testes, que recebe um produto desintegrado e com pouquíssimo tempo para realizar um trabalho de qualidade. Os bugs são encontrados, de fato, pelos clientes e, para que eles não atrapalhem o trabalho dos programadores, eles devem ser resolvidos por uma equipe destacada de suporte que não esteve envolvida na programação.

Eu poderia ir adiante.

Um dos valores do Scrum é a transparência (openness). Na medida em que trabalhamos juntos, evidenciamos o que fazemos, os obstáculos em nosso caminho e nossas preocupações. O efeito colateral positivo disso é que também é evidenciado o que não é feito, os obstáculos irreais colocados no caminho de quem não quer trabalhar e preocupações que surgem nos riscos à manutenção de posições, cargos e status. A função maior das instituições é sua autopreservação e, por isso, quanto maior o tamanho de um projeto, mais aqueles que fazem parte de sua instituição serão resistentes à transparência que pode levar à sua reforma.

É preciso coragem, outro valor do Scrum. Trabalhamos como um time, apoiamos uns aos outros e temos os recursos sob nosso controle. Isso nos dá a coragem de enfrentar grandes desafios. Tomamos as rédeas do nosso destino e assumimos o compromisso (outro valor) com o sucesso.

Como as equipes mantém seu foco (outro valor) em poucas coisas por vez, trabalhamos em conjunto (dentro das equipes e entre múltiplas equipes) para produzir resultados excelentes, dentro de prazos acordados.

Faltou um valor, que é o respeito. Dividimos sucessos e fracassos, respeitando uns aos outros e nos mantendo dignos de respeito. Ou seja, quem não merece respeito não faz parte da equipe e ponto final. E não merece respeito quem se esconde atrás de obstáculos artificiais, nichos especializados de conhecimento, cargos no cartão de visita. Alguém disse, não lembro quem, que o cargo em um cartão de visita é a maior desculpa que alguém pode ter para não fazer nada além do que está escrito ali.

Em resumo, o Scrum pode ser usado independente do tamanho do projeto, desde que seus valores (foco, coragem, transparência, compromisso, respeito), ritos (a reunião diária, planejamento, revisão e retrospectiva de sprints) sejam seguidos; papéis (um único product owner, um scrummaster rotativo nas equipes, equipes multidisciplinares) sejam cumpridos; e artefatos (product backlog, sprint backlog, burndown chart, scrum board) sejam preenchidos.

Em grandes projetos é preciso cuidado na montagem das equipes, identificando-as a aspectos funcionais diversos do sistema e permitindo que a comunicação entre elas seja fluida. A forma como isso é feito pode variar e depende da natureza de cada projeto e estado em que se encontra. O projeto é novo? É um sistema legado? Há legislação específica a ser atendida?

Uma pessoa, o Product Owner, deve comunicar a visão única do projeto. Mais que uma pessoa irá transformar-se, rapidamente, em um comitê. Em projetos muito grandes, divididos em áreas funcionais (entendidas, pelo cliente, como conjuntos correlatos de requisitos), até aceitam-se (sub) Product Owners por área, mas esse assunto fica para, quem sabe, outro artigo.

Os canais de comunicação devem ser poucos e eficazes e, por isso, cada uma das equipes devem ter cinco, sete ou nove pessoas (números ímpares pois a cada sprint um dos membros da equipe assumirá o papel de scrummaster e as demais trabalharão em pares).