Quais são as maneiras de mitigar os efeitos do Mythical Man Month?

Lei de Brooks: A adição de mão de obra a um projeto de software atrasado torna-o mais tarde.

Em seu livro No Silver Bullet - Essence and Accidents of Software Engineering, Frederick Brooks define o conceito de Mythical Man Month :

A suposição de Brooks é que projetos complexos de programação não podem ser perfeitamente particionados em tarefas discretas que podem ser trabalhadas sem comunicação entre os trabalhadores e sem estabelecer um conjunto de inter-relações complexas entre as tarefas e os trabalhadores que as executam .

Desde 1982, certamente avançamos e reunimos mais experiência na mitigação desse problema. Quais são algumas das soluções que você aplicou com sucesso no seu trabalho para adicionar recursos a um projeto sem criar mais problemas.

O que é o MMM

Primeiro, quero explicar o contexto da lei de Brook. Qual foi a suposição que o fez criá-lo em 1975?

Um mês-homem é uma unidade hipotética de trabalho que representa o trabalho realizado por uma pessoa em um mês; A lei de Brooks diz que é impossível medir o trabalho útil em homens-mês.

^{fonte: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

No passado, projetos de programação complexos significariam grandes sistemas de monólitos. E Brooks afirma que isso não pode ser perfeitamente particionado em tarefas discretas que podem ser trabalhadas sem comunicação entre os desenvolvedores e sem o estabelecimento de um conjunto de inter-relações complexas entre as tarefas e as pessoas que as executam.

Isso é verdade em monólitos de software altamente coesos. Independentemente da dissociação, o grande monólito exige o tempo necessário para que os novos programadores aprendam sobre o monólito. E maior sobrecarga de comunicação que consumirá uma quantidade cada vez maior do tempo disponível.

Mas realmente tem que ser assim? Temos que escrever monólitos e manter canais de comunicação para n(n − 1) / 2onde nestá o número de desenvolvedores?

Sabemos que existem empresas em que milhares de desenvolvedores estão trabalhando em grandes projetos ... e funciona. Portanto, deve haver algo que mudou desde 1975.

Possibilidade de mitigar o MMM

Em 2015, o PuppetLabs e o IT Revolution publicaram os resultados do 2015 State of DevOps Report . Nesse relatório, eles se concentraram na distinção entre organizações de alto desempenho e não-alto desempenho.

As organizações de alto desempenho mostram algumas propriedades inesperadas. Por exemplo, eles têm o melhor desempenho de prazo de entrega do projeto em desenvolvimento. Melhor estabilidade operacional e confiabilidade nas operações. Além do melhor histórico de segurança e conformidade.

Uma das coisas surpreendentes destacadas no relatório são as métricas de implantações por dia. Mas não apenas as implantações por dia, elas também mediram a implantação / dia / desenvolvedor e qual é o efeito de adicionar mais desenvolvedores em organizações de alto desempenho versus baixo desempenho.

Este é o gráfico desse relatório -

Enquanto as organizações de baixo desempenho estão alinhadas com as premissas do Mythical Man Month. As organizações de alto desempenho podem escalar linearmente o número de implantações / dia / dev com o número de desenvolvedores.

Uma excelente apresentação no DevOpsDays London 2016 por Gene Kim fala sobre essas descobertas.

Como fazer isso

Primeiro, como se tornar uma organização de alto desempenho? Existem alguns livros que falam sobre isso, não há espaço suficiente nesta resposta, então vou apenas vincular a eles.

• Bom a ótimo: por que algumas empresas dão o salto ... e outras não por Jim Collins
• A vantagem da alta velocidade: como os líderes de mercado aproveitam a excelência operacional para vencer a concorrência por Steven Spear
• The New Economics for Industry, Government, Education por W. Edwards Deming

Para organizações de software e TI, um dos fatores críticos para se tornar uma organização de alto desempenho é: foco na qualidade e velocidade .

Por exemplo, Ward Cunningham explica Dívida técnica como todas as coisas que deixamos sem correção. Isso é aceito pela gerência porque sempre vem com a promessa de que será corrigido quando houver tempo.

Nunca há tempo suficiente e a dívida técnica se torna cada vez pior.

Quais são essas coisas que causam o crescimento da dívida técnica?

• código legado
• configuração manual de ambientes
• teste manual
• implantações manuais

Código legado Conforme definido em Trabalhando efetivamente com o código legado de Michael Feathers, qualquer código que não tenha testes automatizados.

Sempre que atalhos são usados ​​para obter o código para produção; as operações estão sobrecarregadas com a manutenção dessa dívida para sempre. Então, o processo de implantação se torna cada vez mais longo.

Gene conta uma história em sua apresentação sobre uma empresa que tem implantações de seis semanas. Envolvendo dezenas de milhares de etapas tediosas e extremamente propensas a erros, atando 400 pessoas, e elas o faziam quatro vezes por ano.

Um dos princípios do DevOps é que a confiabilidade advém de implantações menores com mais frequência.

Exemplo

• Jon Jenkins no Velocity 2011 : Amazon realiza 15 mil implantações / dia
• Ken Exner na AWS Summit 2015 : a Amazon está realizando 136k implantações / dia

Essas duas apresentações mostram tudo o que a Amazon fez para diminuir o tempo necessário para implantar o código na produção.

Segundo Gene, a única coisa que muda ao longo do tempo nessas organizações de alto desempenho é o número de desenvolvedores. Assim, pelo exemplo da Amazon, você poderia dizer que em quatro anos eles aumentaram suas implantações dez vezes apenas adicionando mais pessoas.

Isso significa que, sob certas condições, com a arquitetura certa, as práticas técnicas corretas, as normas culturais corretas, a produtividade do desenvolvedor pode aumentar à medida que o número de desenvolvedores aumenta. E o DevOps está definitivamente no meio de tudo isso.

O que eu fiz (e isso é apenas subjetivo) é o seguinte:

Quando um gerente que pensa em uma data de vencimento deseja adicionar pessoas à minha equipe para reduzir o tempo necessário e parecer no MMM, primeiro discuto com ele sobre por que isso pode ser ruim. Minha analogia favorita para isso é lembrá-los de que, se uma mulher pode ter um bebê em nove meses, nove não terão um bebê em um mês, mas terão nove bebês em nove meses. O tempo não é reduzido, apenas o processamento paralelo é melhor.

Quando a decisão é imposta à nossa equipe, geralmente tentamos dividir ainda mais algumas tarefas e, quando isso não é possível, geralmente confiamos na programação em pares , onde um programador é responsável pela digitação e o outro determina o código (e alterna periodicamente). )

A escrita do código em si é mais lenta, mas há menos erros de digitação / erros e erros durante o teste devido à inevitável revisão feita durante a gravação. Sinto que a qualidade geral do código também é um pouco melhor, mas não tenho métricas para apoiar essa afirmação.

Falando exclusivamente da perspectiva do IC, aumentar o número de desenvolvedores trabalhando em um projeto normalmente se traduz em mais pessoas trabalhando no mesmo ramo.

Os sistemas de IC tradicionais têm um problema de escalabilidade a esse respeito: a probabilidade de quebras / regressões / bloqueios aumenta a velocidade da integração e convida equipes menores a interromperem e seguirem para os ramos secundários (ou seja, desacelerações adicionais). Consulte Como a integração contínua pode ser dimensionada para projetos / equipes muito grandes? . Isso segue o conceito do Mythical Man Month.

A solução que sugiro na minha resposta a essa pergunta é que um sistema de IC altamente escalonável permitiria a migração para um verdadeiro CI - integração baseada em ramo / tronco único para equipes maiores (mesmo com grandes tamanhos).

Com todos da mesma página, usando as mesmas ferramentas / processos automatizados e a grande maioria das verificações de controle de qualidade automatizadas dentro do próprio sistema de IC, fica muito mais fácil alternar funções e se concentrar entre os membros da equipe. Todo o processo de desenvolvimento se torna mais suave, mais previsível, mais relaxado.

Trazer novas pessoas a bordo nesse ambiente, obtendo-as produtivas simplesmente descarregando tarefas menos difíceis dos membros da equipe mais experientes, que podem assumir tarefas mais difíceis, é mais fácil.

Acredito que tudo isso possa acalmar os efeitos do conceito do Mythical Man Month.