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

16

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.

Jiri Klouda
fonte
5
Estou votando para encerrar esta questão como fora de tópico, porque ela se encaixa melhor no Software Engg. SE ( softwareengineering.stackexchange.com ), e também porque não é específico DevOps estritamente
Dawny33
2
Esta é uma pergunta estritamente específica do DevOps. Está diretamente relacionado ao processo de entrega do software. Tem certeza de que realmente entende o que significa DevOps?
Jiri Klouda 3/03
3
Você continua dizendo DevOps, acho que não significa o que você pensa.
precisa saber é o seguinte
3
@ Dawny33: Por favor, leia um dos livros fundamentais do DevOps - The Phoenix Project. Você não encontrará uma única menção à AWS, Docker, Jenkins ou qualquer outra ferramenta. O livro inteiro é sobre processo, hierarquia organizacional e estrutura, a maneira de trabalhar em equipe. O DevOps é uma maneira de trazer as idéias científicas que aprimoraram a fabricação no Japão e, posteriormente, nos Estados Unidos, para o processo de Desenvolvimento de Software. Ideias baseadas no trabalho de Edward W. Deming e Eliyahu M. Goldratt. O que você vê como DevOps é apenas a superfície, as ferramentas, os resultados. As partes supérfluas disso.
Jiri Klouda 3/03
5
@ Dawny33 Esta pergunta não é adequada para Engenharia de Software. Embora esse tópico geral seja, a questão é muito ampla. É buscar opiniões em vez de tentar resolver um problema. Por favor, não sugira outras comunidades se você não entender que tipos de perguntas elas aceitam. Se essa pergunta fosse publicada na Engenharia de Software, ela seria votada, encerrada e provavelmente excluída muito rapidamente. Isso leva a uma má experiência do usuário.
Thomas Owens

Respostas:

18

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 -

Implantações por dia por desenvolvedor

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.

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

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.

Evgeny
fonte
4

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.

Tensibai
fonte
11
Eu gosto da ideia de programação em pares. Isso é realmente algo que poderia ajudar. Talvez eu possa explicar por que mais tarde, com base na teoria em que tenho trabalhado.
Jiri Klouda # 03
por favor, aguarde!
Peter Peter
4

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.

Dan Cornilescu
fonte
Em organizações de alto desempenho, adicionar mais desenvolvedores geralmente significa criar equipes mais independentes que escrevem software dissociado. Isso permite que mais pessoas alcancem mais e mais rápido. Ter todos eles se comunicando por meio de um único ramo de integração é um anti-padrão e, provavelmente, atrasará consideravelmente as coisas.
Evgeny
Having them all communicate via a single integration branch is an anti-pattern- porque? Se forem dissociados no sentido de que não precisarão mais integrar seu trabalho, tocarão o ramo de maneira não sobreposta / não conflitante. Se o trabalho deles ainda precisar ser integrado, continuar em filiais adicionais apenas atrasará e complicará a integração, desviando-se da metodologia de IC e perdendo todas as suas vantagens.
precisa
Eu acho que não estamos concordando com o significado de "ramo". É bom ter um repositório grande, com uma única ramificação (git ou svn), e sofrer a sobrecarga de todos que trabalham no mesmo. Também é bom ter vários repositórios em que cada repositório possui uma ramificação que rastreia esse serviço desacoplado específico. Depende da ferramenta, a quantidade de sobrecarga que ela adiciona ao código de confirmação e de finalização da compra.
Evgeny
Ah, desculpe, sim - estou tão acostumado a isso e continuo esquecendo que os outros não. Por ramo, estou me referindo à representação genérica de alto nível do ramo SCM, não importa realmente quais são as particularidades dos sistemas SCM subjacentes, contanto que sejam gerenciados juntos de maneira monolítica . Um grande repositório com uma mainramificação ou 10 repositórios lado a lado (módulos git?), Cada um com uma mainramificação deve ser praticamente equivalente ao potencial de IC.
precisa
Então minha afirmação desde o primeiro comentário é verdadeira. A independência não pode ser feita em uma torre de babel, quando você tem um monólito, a sobrecarga é muito alta para todos - então todos estão sobrecarregados. É muito melhor representar projetos dissociados como pequenos sistemas VCS dissociados para gerenciar. Se você se lembra o suficiente, algumas empresas estavam usando o ClearCase e outros VCS para gerenciar TODA a empresa - a sobrecarga era horrível.
precisa