10 Pré-requisitos de Escalabilidade que Deve Conhecer Antes de Expandir

Se trabalha no desenvolvimento de software há tempo suficiente, é muito provável que já tenha vivido este pesadelo:

1. É prometido ao cliente um grande número de funcionalidades num prazo irrealisticamente curto (que ninguém tem coragem de contestar).
2. Mais tarde, quando o prazo está perigosamente próximo, alguém numa posição de autoridade decide lançar mais equipas para o problema, de modo a cumprir o prazo.
3. As coisas começam a desmoronar-se.

Parece-lhe familiar?

Neste artigo, explicarei o que precisa de fazer para evitar novamente essa situação de pesadelo (ou, se teve a sorte de nunca a viver, para a evitar por completo).

Os conhecimentos que partilho neste artigo resultam da experiência de fazer crescer equipas de desenvolvimento de software à escala, mas pode aplicar a teoria fundamental ao crescimento de uma empresa ou de uma equipa em qualquer setor. Isto ser-lhe-á útil mesmo que esteja a adotar uma das estruturas de crescimento à escala prontas a utilizar — Large Scale Scrum (LeSS), Scrum@Scale, SAFe.

Isto acontece porque me concentro em vários aspetos importantes da escalabilidade que nunca são mencionados nessas metodologias — a verdade fundamental sobre a natureza do crescimento à escala que é frequentemente esquecida ou ignorada.

A Lei Fundamental do Crescimento à Escala

A Lei Fundamental do Crescimento à Escala é uma observação empírica do que acontece aos projetos quando crescem à escala:

O crescimento à escala amplifica o que está mal e torna o que está bem mais difícil.

Fui eu que formulei a frase, mas não sou a única pessoa, nem a primeira, a chegar a esta conclusão.

Vejamos o que a Lei significa na prática através de alguns exemplos de escalabilidade.

1. Exemplo: Comunicação e escalabilidade

O primeiro e mais óbvio exemplo é a comunicação. É um facto bem conhecido que, quando o número de pessoas num projeto aumenta, também aumenta o número de canais de comunicação. Se os canais de comunicação não forem suficientemente bons à partida, o crescimento à escala agravará o problema.

Por outro lado, se os canais de comunicação forem bons à partida, o crescimento à escala introduzirá alguns desafios, não só devido ao aumento do número de pessoas, mas também devido à sua distribuição. Muitas vezes, são criadas novas equipas em locais diferentes, obrigando a alterações nos canais de comunicação — por exemplo, passar de reuniões presenciais para videoconferências ou substituir um quadro branco por uma ferramenta eletrónica.

2. Exemplo: Integração Contínua/Entrega Contínua e escalabilidade

Também vemos a Lei Fundamental do Crescimento à Escala nos processos de Integração Contínua (CI) e entrega contínua (CD). Quando existe apenas uma equipa, as coisas são bastante simples.

Ao passar de uma para duas equipas, os sistemas de CI e CD tornam-se mais complexos — normalmente, quando existem n equipas, o número de processos de CI tende a ser n+1 (um processo por equipa, mais um para a integração). Isto tem repercussões óbvias no aprovisionamento de ambientes e na coordenação entre equipas.

3. Exemplo: Ciclos de feedback e escalabilidade

Um último exemplo: os ciclos de feedback. Os projetos maiores têm ciclos de feedback mais longos. Por isso, aperfeiçoar o sistema de forma iterativa torna-se muito mais difícil, aumentando as probabilidades de construir o produto errado.

Estes são apenas três exemplos de alguns dos desafios introduzidos pelo crescimento à escala. Tenho a certeza de que conseguirá encontrar muitos mais.

Partamos do princípio de que está disposto a aceitar os compromissos envolvidos. A próxima coisa de que precisa é que o seu projeto satisfaça alguns pré-requisitos importantes para comprovar a sua escalabilidade.

10 pré-requisitos para o crescimento à escala

O facto de ter ou não uma empresa, um projeto ou uma equipa escalável depende de vários pré-requisitos apresentados abaixo. Se cumprir estes pré-requisitos, terá uma elevada escalabilidade. Por outro lado, se algum deles não for cumprido, as probabilidades de insucesso aumentam drasticamente.

1. A existência de objetivos claros e partilhados

Isso deveria ser um dado adquirido, mas, na minha experiência, a ausência de objetivos claros e partilhados é extremamente comum. Sem estes objetivos, as equipas seguirão em direções diferentes, tornando mais difícil entregar algo útil.

2. A utilização de métricas adequadas

Quanto maior for o projeto, mais importante é poder medir o impacto das decisões tomadas. Por exemplo, a adição de uma nova equipa melhorou a capacidade de entrega do projeto? Estamos a pressionar as equipas ao ponto de a qualidade estar a diminuir? As equipas estão a trabalhar bem em conjunto ou estão a interferir umas com as outras?

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

3. Uma arquitetura adequada

Se a “forma” do sistema não corresponder à estrutura das equipas, adicionar mais equipas só irá piorar as coisas. Este é um efeito direto da Lei de Conway, uma observação empírica bem conhecida e comprovada na prática.

4. Disponibilidade de competências de gestão e técnicas

Os problemas causados pela falta de competências terão um efeito negativo amplificado à medida que o projeto cresce.

5. Bons canais de comunicação

Quanto mais pessoas estiverem envolvidas, mais comunicação terá lugar. Um aumento de escala bem-sucedido requer uma comunicação simplificada.

6. Boa priorização e planeamento

A falta de priorização e planeamento adequados é, na minha experiência, um fator muito comum no fracasso dos projetos. Em particular, quando está envolvida mais do que uma equipa, as atividades de priorização e planeamento têm de prever medidas para mitigar os efeitos dos atrasos e da falta de sincronização.

7. Boa recolha e gestão de requisitos

Isto está intimamente ligado à priorização e ao planeamento. Além disso, o efeito de requisitos errados, mal compreendidos ou desnecessários será amplificado à medida que aumenta o número de equipas.

8. Trabalho de elevada qualidade

Quanto maior for o projeto, maior será o efeito negativo da má qualidade. Em alguns cenários patológicos (e comuns), alguns erros podem tornar-se funcionalidades, uma vez que os ciclos de retorno para os corrigir podem ser tão longos que outras equipas podem ter concebido soluções alternativas para os neutralizar.

9. Disponibilidade de recursos

Mais equipas precisam de mais secretárias, computadores, ferramentas e ambientes.

10. Automatização implacável

Qualquer atividade manual é um estrangulamento cujos efeitos se agravam com o número de pessoas e equipas. Um exemplo (muito comum): atividades de testes manuais para garantir que não foram introduzidas regressões antes de uma versão para produção. Na minha experiência, este é um dos maiores estrangulamentos em qualquer projeto, mas especialmente em projetos com mais do que uma equipa.

Cuidado com o aumento de escala prematuro

A escalabilidade está no topo das prioridades das empresas emergentes e dos empreendedores em série — e eles têm uma ou duas lições para nos ensinar sobre o aumento de escala prematuro.

Se iniciar um esforço de aumento de escala antes de ter realmente cumprido os pré-requisitos para aumentar com sucesso a escala de uma empresa, equipa ou organização, obterá aquilo a que a comunidade de empresas emergentes chama “aumento de escala prematuro”.

Uma definição simples de aumento de escala prematuro, do empreendedor em série Jim Pitkow:

Aumento de escala prematuro: crescer em antecipação à procura, em vez de crescer impulsionado pela procura.

Com efeito, aumentar a escala corretamente leva tempo — e a verdadeira escalabilidade é impulsionada por uma necessidade real de escala devido à procura, não por uma noção artificialmente imposta de simplesmente ficar maior e fazer mais coisas mais depressa.

A comunidade de empresas emergentes oferece algumas lições que podemos aplicar novamente às nossas equipas e projetos quando pensamos se é ou não altura de aumentar a escala. Eis algumas estatísticas do relatório adicional do Startup Genome sobre o aumento de escala prematuro:

• As empresas emergentes que aumentam a escala corretamente demoram mais 76% de tempo a atingir a dimensão da equipa do que as empresas emergentes que aumentam a escala prematuramente.
• 74% das empresas emergentes de Internet de elevado crescimento fracassam devido ao aumento de escala prematuro.
• As empresas emergentes que aumentam a escala corretamente crescem cerca de 20 vezes mais depressa do que as empresas emergentes que aumentam a escala prematuramente.

Se tiver interesse em mais estatísticas sobre empreendedorismo, consulte o nosso estudo sobre os estados mais empreendedores da América.

Está realmente preparado para aumentar a escala?

Se o seu projeto for bem gerido e cumprir os pré-requisitos acima, a sua próxima pergunta deverá ser:

“Quantas equipas podem contribuir de forma produtiva?”

Responderemos a esta pergunta na próxima secção.

Qual é o Limite da Escalabilidade? As Leis de Brooks e de Amdahl

É um facto bem conhecido que adicionar mais pessoas a um projeto de software não irá necessariamente aumentar a produtividade.

Na realidade, na maioria dos casos, adicionar mais pessoas provocará uma queda significativa da produtividade.

Fred Brooks fez esta observação no seu livro O Mês do Homem Mítico, que ficou conhecida como a Lei de Brooks:

“Adicionar mão de obra a um projeto de software atrasado fará com que este se atrase ainda mais […] O número de meses de um projeto depende das suas restrições sequenciais. O número máximo de pessoas depende do número de subtarefas independentes. A partir destas duas quantidades, é possível definir calendários utilizando menos pessoas e mais meses[…]. No entanto, não é possível obter calendários viáveis utilizando mais pessoas e menos meses.”

A segunda metade da citação acima é, na minha opinião, a mais interessante. Na realidade, é basicamente a versão em linguagem simples da Lei de Amdahl—uma fórmula que indica o aumento máximo teórico da velocidade de um sistema concorrente:

Lei de Amdahl

Aumento de velocidade = 1 / (s + p / n )

Onde:

s = percentagem de tarefas sequenciais

p = percentagem de tarefas paralelas

s + p = 1

n = número de processadores (equipas, no nosso caso)

Na realidade, um projeto com várias equipas é uma espécie de sistema concorrente em que cada equipa é uma unidade de processamento. Na prática, a Lei de Amdahl estabelece que a quantidade máxima de trabalho concorrente é limitada pela quantidade de trabalho sequencial que precisa de ser realizada.

Por outras palavras, isto significa que as tarefas que precisam de ser realizadas numa determinada ordem restringem a quantidade de trabalho em que as equipas podem trabalhar simultaneamente.

O que é Trabalho Sequencial no Contexto do Desenvolvimento de Software?

Poderá estar a perguntar-se que tipo de trabalho sequencial afeta as equipas de software.

Eis alguns exemplos (tenho a certeza de que conseguirá encontrar muitos mais):

• Qualquer trabalho em pipelines de integração e implementação
• Fusão de alterações de software em código partilhado por diferentes equipas
• Qualquer tipo de sincronização—por exemplo, uma equipa que depende dos resultados entregues por outra antes de prosseguir com o seu trabalho
• Aguardar pelo aprovisionamento de recursos

Aplicar a Lei de Amdahl à Escalabilidade das Equipas

O gráfico abaixo apresenta as implicações da Lei de Amdahl ao aumentar o número de equipas na produtividade.

Podemos ver que a produtividade aumentará de forma sublinear à medida que o número de equipas aumenta—até atingir um pico, após o qual voltará a diminuir.

Uma ilustração da lei de Amdahl: o fluxo de resultados entregues aumenta com o número de equipas, mas apenas até um determinado ponto—e normalmente não é aquilo que os gestores esperam.

Se guardar apenas uma ideia deste artigo, que seja esta:

Aumentar o número de equipas pode aumentar o fluxo de trabalho concluído—mas apenas até um determinado ponto.

Então, qual é o Número Ideal de Equipas para um Determinado Projeto?

Infelizmente, não existem equações que permitam calcular antecipadamente o número ideal de equipas para um determinado projeto. A única forma é utilizar um conjunto de métricas do projeto para medir aspetos como a produtividade e a qualidade, e observar o que acontece quando se adicionam ou removem equipas. A minha recomendação é começar com uma equipa pequena, composta por 3-6 pessoas, e aumentar a dimensão apenas quando e se for necessário.

A dada altura, poderá descobrir que já atingiu o número máximo de equipas, mas que o seu projeto continua sem conseguir cumprir os seus compromissos. É aí que as suas competências de priorização e comunicação se revelam úteis, pois poderá ter de manter conversas difíceis com os seus clientes.

Considerações sobre a Estrutura das Equipas: Equipas de Funcionalidades ou de Componentes?

Ao adicionar uma nova equipa ao projeto, como deverá trabalhar? Para começar, faça a si próprio estas duas perguntas:

1. Serão responsáveis por desenvolver funcionalidades visíveis para o cliente de ponta a ponta ou por alterar algo no sistema para alcançar o seu objetivo?
2. Serão responsáveis por trabalhar num componente específico que fornece parte de alguma funcionalidade visível para o utilizador?

Se respondeu afirmativamente à questão n.º 1, a equipa será uma equipa de funcionalidades.

Se respondeu afirmativamente à questão n.º 2, será uma equipa de componentes.

Sugestões para escolher a estrutura de equipa adequada

Escolher a estrutura e a organização de equipa adequadas é muito importante, mas não é fácil. Atualmente, as equipas de funcionalidades parecem ser a opção preferida na maioria das situações. No entanto, essa escolha baseia-se frequentemente no hábito ou na rotina, em vez de se basear em dados.

A realidade é que «depende». Mais especificamente, depende da arquitetura do sistema. Os projetos de software tendem a seguir aquilo que é conhecido como a Lei de Conway — uma observação empírica de Mel Conway:

«As organizações que concebem sistemas… estão condicionadas a produzir conceções que são cópias das estruturas de comunicação dessas organizações»

Por outras palavras, a «forma» da estrutura das equipas tem de corresponder à «forma» do sistema, caso contrário o projeto enfrentará problemas graves.

É por isso que recomendo sempre aos gestores que envolvam arquitetos sénior e responsáveis técnicos nas decisões relativas à estrutura das equipas — caso contrário, os gestores estão, na realidade, a conceber o sistema sem se aperceberem disso (e sem as competências adequadas). Isto, por sua vez, pode aumentar significativamente o risco de insucesso do projeto.

Dois paradoxos da escalabilidade

Com base na minha experiência como consultor em vários projetos de grande escala, cheguei à conclusão de que, na maioria dos casos, os projetos são dimensionados pelos motivos errados.

Criei dois paradoxos que resumem aquilo que tenho observado na prática:

Primeiro paradoxo do dimensionamento

A maioria dos projetos é ampliada porque não cumpre os pré-requisitos para ser ampliada

Segundo paradoxo do dimensionamento

Os projetos que cumprem os pré-requisitos para serem ampliados têm menos necessidade de o ser

O primeiro paradoxo afirma que, na maioria das situações, os projetos avançam lentamente simplesmente porque não são bem geridos.

O segundo afirma que os projetos bem geridos terão menos necessidade de escala simplesmente porque são bem geridos.

Na verdade, os projetos mais produtivos que vi tinham apenas uma ou duas equipas pequenas e cumpriam todos os pré-requisitos para serem ampliados. De todos os projetos de grande escala em que participei, não vi um único em que todos os pré-requisitos para a ampliação fossem cumpridos. Na verdade, todos tinham bastantes problemas em cumprir qualquer um dos pré-requisitos.

Se está envolvido num projeto que enfrenta problemas e atrasos, a melhor recomendação que posso dar é reduzir a dimensão da confusão antes de considerar ampliar o projeto.

Conclusões para dimensionar corretamente as suas equipas

Dimensionar equipas de software não é fácil e deve ser feito com extremo cuidado. Antes de terminar, ficam algumas ideias finais sobre como encontrar a forma mais eficaz de dimensionar uma equipa de desenvolvimento de software:

1. Se trabalhar para cumprir os pré-requisitos de escalabilidade, poderá descobrir que consegue manter a equipa pequena e evitar todos os problemas associados a uma dimensão maior.
2. Por outro lado, se o seu projeto já for grande e estiver a enfrentar dificuldades, concentre-se primeiro em reduzir a dimensão da confusão.

Eis os primeiros passos que sugiro que dê depois de ler este artigo:

1. Descubra o que está a acontecer no terreno
2. Implemente algumas métricas para poder avaliar a situação atual, bem como a qualidade das decisões tomadas.