O que aconteceu com o padrão "Equipe Cirúrgica" de "O Mês do Homem Mítico"?

Anos atrás, quando li The Mythical Man-Month, encontrei muitas coisas que eu já sabia de outras fontes. No entanto, também havia coisas novas, apesar do livro ser de 1975. Uma delas era:

A equipe cirúrgica

Mills propõe que cada segmento de um grande trabalho seja abordado por uma equipe, mas que a equipe seja organizada como uma equipe cirúrgica e não como uma equipe de açougueiros. Ou seja, em vez de cada membro interromper o problema, um faz o corte e os outros dão a ele todo apoio que aumentará sua eficácia e produtividade.

Esse é um padrão muito interessante para organizar uma equipe de desenvolvimento de software, mas nunca o encontrei descrito em nenhum outro livro de Engenharia de Software, nem mencionado em nenhum lugar.

Por que é que?

• A "equipe cirúrgica" era incomum naquela época?
• Ou, foi tentado e falhou?
  • Se sim, como falhou?
  • Caso contrário, por que não vemos esse padrão implementado nos projetos de software atuais?

"The Mythical Man-Month" saiu no ano em que comecei a faculdade e, para usar o vernáculo atual, UUUGE! :-) O que você precisa entender é a diferença de como o software foi desenvolvido ENTÃO vs. AGORA. Back In The Day (tm) praticamente toda a codificação foi feita primeiro no papel, depois digitada nos cartões perfurados (você adivinhou), depois lida, compilada, vinculada, executada, os resultados foram obtidos e o processo foi repetido. O tempo de CPU foi caroe recursos limitados e você não queria desperdiçá-lo. O mesmo acontece com o espaço em disco, o tempo da unidade de fita, etc., blá. Perder tempo de CPU perfeitamente bom em uma compilação que resultou em erros (choque e horror!) Foi ... bem, um desperdício de tempo de CPU perfeitamente bom. E isso foi em 1975. Na época em que Fred Brooks estava desenvolvendo suas idéias, que era o tempo de CPU de meados do final da década de 1960, era ainda maisdispendioso, memória / disco / o que for ainda mais limitado, etc. A idéia por trás da equipe cirúrgica era garantir que o super grande desenvolvedor Rockstar não tivesse que perder seu tempo em tarefas mundanas como código de verificação de mesa, digitação de teclas, enviando trabalhos, aguardando (às vezes por horas) por resultados. O Rockstar Dude Developer Man deveria ser o código de escrita. Sua legião de groupies / funcionários / desenvolvedores juniores deveria fazer as coisas mundanas.

O problema era que, dentro de dois anos após a publicação do livro de Brooks, as idéias básicas por trás da Equipe Cirúrgica estavam desmoronando:

1. Os terminais CRT e os arquivos de disco começaram a substituir os toques de teclas e os decks de cartões. O tempo do computador ficou mais barato, vários computadores se tornaram disponíveis e o tempo de resposta dos trabalhos caiu drasticamente. Quando cheguei à faculdade (Universidade de Miami, Oxford, Ohio, turma de 79, obrigado por perguntar) boaa rotação do trabalho foi de cerca de uma hora. Durante a semana final - quatro horas, talvez, às vezes seis. (Competimos pelo tempo de CPU com várias empresas e universidades comerciais - e os usuários comerciais obtiveram a primeira prioridade). Durante meu último ano, quando Miami havia saído de seu arranjo de "computadores compartilhados", tinha seu próprio IBM 370/145 instalado no campus e tinha um bom mini HP em que trabalhei que agia como uma estação RJE em que poderíamos transformar o mainframe trabalhos em torno de cinco minutos ou menos. Agora valia a pena inserir seu código no HP, enviá-lo do HP para o mainframe, girar os polegares / fumar um cigarro e recuperar a saída muito antes que você pudesse terminar de checar seu código.

2. A equipe cirúrgica tem como premissa básica a idéia de que você (ou "gerência", Deus nos ajude a todos) pode identificar The Rockstar Surgical Surgical Dude. Na verdade, duvido que seja possível. Não são desenvolvedores rockstar, todo mundo sabe disso - estudos têm mostrado diferenças de produtividade entre os melhores e piores desenvolvedores de até 2.000% - mas identificar essa pessoa sem tê-los escrever o código durante um longo período de tempoé provavelmente impossível. A única maneira de saber se alguém é um desenvolvedor de rockstar é fazê-lo realmente desenvolver código - mas se ele NÃO é o Cara do Desenvolvedor Cirúrgico da Rockstar, estará fazendo coisas interessantes como checar seu código, digitar em cartões e esquivando caixas de cartões perfurados até o departamento de Job Entry, aguardando os resultados para que eles possam devolvê-los ao Sr. Rockstar Surgical Developer Dude em vez de aprender a codificar da única maneira que realmente funciona - escrevendo código, código de depuração, e etc. Back In The Day (tm) não havia concursos de programação, não havia Stack Overflow, você não tinha um PC no qual podia escrever código sempre que quisesse, não havia livros sobre Algoritmos para Idiotas - a única maneira de aprender programação era ir à escola e se especializar em algo em que você precisava fazer um pouco de programação. Mas a programaçãopor si só não foi levado a sério, e foi assumido que era algo que as pessoas não queriam fazer . No meu primeiro curso universitário (SAN151 - Introdução à análise de sistemas, Dr. Tom Schaber - obrigado Tom :-), o instrutor nos disse que "... nós apenas tínhamos que enfrentar o fato de que teríamos que gastar um tempo. dois anos como programadores antes de nos tornarmos analistas de sistemas ". "Dois anos?", Pensei. "SOMENTE FAZER ISSO POR DOIS ANOS?!?". Eu estava seriamente chateado. Felizmente, ele estava errado e eu tenho codificado praticamente desde então. :-)

3. A equipe cirúrgica assume que os programadores são um recurso relativamente raro. Na verdade, levou mais alguns anos, mas com o advento dos PCs, no início dos anos 80, a programação se tornou algo em que qualquer nerd podia se envolver. O preço dos computadores começou a cair, o preço das ferramentas de desenvolvimento começou a cair, e foi tudo granizo Turbo Pascal - pelos padrões de hoje, não era muito, mas na época era um IDE completo de Pascal por cerca de 40 dólares, o que era absolutamente louco! Agora, ALGUÉM poderia entrar em programação - se você pudesse comprar um computador, e quando a IBM decidiu colocar o PCjr (sim, meu primeiro PC foi um dos maiores erros da IBM :-) à venda por cerca de US $ 500 para se livrar desses perus, dinheiro nerds sem dinheiro em todos os lugares pularam seus pagamentos de aluguel por um mês ("Sim, eu sei, mas eu ... eu quebrei minha uuvula e tive que fazer uma cirurgia e ... .uh ... sim, na próxima semana, não há problema, obrigado, cara ...) e sugou-os a preços de liquidação. Em seguida, gastamos mais do que pagamos pelo computador em complementos para torná-lo utilizável. ("Sim, cara, na próxima semana, com certeza, provavelmente ..." :-).

O que me deixa realmente triste é que, ainda hoje, se você perguntar às pessoas se elas já leram "O Mês do Homem Mítico" ou entenderam sua principal lição ("A adição de recursos a um projeto atrasado o torna mais tarde"), elas ficam em branco olhar - e depois cometer os mesmos erros exatos que foram cometidos todos os anos atrás durante o desenvolvimento do OS / 360. Tudo velho é novo outra vez... :-}

Existem alguns aspectos desse conceito que às vezes são implementados hoje, outros são evitados .

Manter as equipes pequenas é um dos recursos básicos dos Métodos Ágeis, mas também é praticado fora do Agile.

As equipes multifuncionais também são um grampo do Agile, mas também são comuns fora do Agile.

O papel do Assistente de Programa é amplamente incluído em sistemas computadorizados, como Sistemas de Controle de Versão, Sistemas de Gerenciamento de Configuração de Software, Sistemas de Gerenciamento de Mudanças, Sistemas de Gerenciamento de Documentos, Wikis, Sistemas de Construção Contínua com Repositórios de Artefatos e assim por diante. Quero dizer, você pode realmente imaginar pagar um funcionário em tempo integral para imprimir o código-fonte e indexá-lo e arquivá-lo manualmente?

Da mesma forma, o papel de Administrador do Sistema (não parte da Equipe Cirúrgica de Mills, mas parte de uma equipe multifuncional típica dos últimos anos) está sendo obsoleto por conceitos como DevOps (absorvendo o papel do Sysadmin no papel de Engenheiro de Software) , Plataforma como serviço, Infraestrutura como serviço e Computação de utilitários (tornando o Sysadmin "o problema de outra pessoa") ou Infraestrutura como código (transformando a Administração do sistema em Engenharia de software).

Um dos aspectos que tentamos evitar hoje é que no máximo duas pessoas entendem o sistema. Apenas o cirurgião tem a garantia de entender completamente o sistema, o copiloto pode ou não. Isso fornece um fator de barramento entre 1 e 2. Se o cirurgião ficar doente, o projeto estará morto. Período. A resposta ágil para isso é a propriedade do código coletivo, que é exatamente o oposto desse modelo: ninguém é o único responsável por qualquer parte do sistema. Em vez disso, todos são responsáveis ​​por tudo como um grupo .

Por fim, existem algumas suposições inseridas nesse conceito, que estão desatualizadas. Por exemplo, mesmo que não seja declarado explicitamente, a equipe é configurada de maneira que apenas uma pessoa na equipe (o cirurgião) tenha realmente um computador. Isso é claro, porque na época em que o artigo foi escrito, até a ideia de que uma equipe inteira teria um computador para si, e muito menos de uma pessoa na equipe, era exagerada. (Mesmo em 1980, quando o Smalltalk foi lançado, uma das coisas que contribuiu para sua falha foi o fato de o sistema ter sido configurado de tal forma que todo desenvolvedor e usuário tivesse seu próprio computador - completamente impensável na época.)

Então, resumindo: não acho que o conceito tenha sido implementado exatamente como descrito, mas alguns aspectos definitivamente são implementados, alguns são vistos como indesejáveis ​​e evitados ativamente, alguns são obsoletos e outros são provavelmente boas idéias ™, mas ninguém faz isso.

Antes, a educação universitária era algo único e os engenheiros estavam entre os poucos escolhidos. Os computadores eram caros e as equipes trabalhavam em projetos com RoI comercial definido. Estes não eram muito comuns.

O que aconteceu foram microcomputadores, onipresente ensino de graduação e sistemas de computadores que nem precisam de diploma universitário para progredir. Além disso, o que aconteceu foi a mudança da economia e o aumento do custo do trabalho.

A economia de uma proporção 8: 2 de suporte: engenheiro não faz mais sentido. Os engenheiros devem ter seu próprio suporte. Um ser humano moderno, com educação e habilidades suficientes para ser eficaz ligado a uma equipe de desenvolvimento, é muito caro para não estar desenvolvendo seu próprio tipo de desenvolvimento.

(Um termo econômico relacionado é "a doença de custo do setor de serviços".)

Isso me parece muito com a programação Mob:

Todo o grupo (controle de qualidade, desenvolvedores e até proprietário do produto, se necessário) está trabalhando ao mesmo tempo no mesmo problema. Sem suporte, alta comunicação, implantada diretamente no live.

De http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

O conceito básico de programação mob é simples: toda a equipe trabalha em equipe em uma tarefa de cada vez. Ou seja: uma equipe - um teclado (ativo) - uma tela (projetor, é claro). É como fazer a programação de pares de equipe completa.

Veja em ação aqui: https://www.youtube.com/watch?v=dVqUcNKVbYg

Esse modelo de equipe é mencionado novamente em Rapid Development - Taming Wild Software Schedules por Steve McConnell na página 305. Lá é chamado de Equipe de Programadores-Chefe.

Esse modelo surgiu porque havia um gênio na equipe e os recursos de computação eram limitados. Ele caiu em desuso porque o gênio é raro, e com computadores onipresentes e controle de versão distribuído, temos espaço para muitas mãos na mesa de operações.

Outras referências:

Baker, F. Terry. "Chief Programmer Team Management of Production Programming", IBM Systems Journal, vol. 11, n. 1, 1972, pp. 56-73.

Baker, F. Terry e Harlan D. Mills. "Equipes de programadores-chefe". Datamation, Volume 19, Número 12 (dezembro de 1973), pp. 58-61.

Meu palpite é que a maioria das pequenas equipes auto-organizadas tenderá a se estabelecer em um modelo de equipe cirúrgica de fato.

As duas últimas equipes em que participei tendem a consistir em três ou quatro pessoas, geralmente uma sênior (cirurgião), uma intermediária (copiloto) e dois juniores / especialistas. Atualmente, algumas das funções da equipe cirúrgica mencionadas por Brooks são preenchidas por mestres e administradores de sistemas Scrum ou provedores de nuvem. Lembre-se de que o controle da fonte mal existia na época, muito menos algo tão poderoso quanto o git.

Pense na regra das duas pizzas de Bezos. Essa é sua equipe cirúrgica auto-organizada ali mesmo.

Um artigo da HP sugeria algo semelhante:

• Cada engenheiro de software exigiria vários gerentes e várias pessoas de suporte.
• Deve haver um redator técnico, testador, gerente de construção e fabricante de ferramentas para cada engenheiro.

O jornal estava nos dias pré-web e era apresentado de tempos em tempos tão engraçado. A cada ano, o comentário passava um pouco mais de "tão ridículo é engraçado" para "talvez devêssemos fazer isso".

Testes reais são notoriamente difíceis de projetar, por isso provavelmente permanece opinião. Pode haver algumas pesquisas de projetos e suas taxas de conclusão.

Pergunto-me quanto da necessidade de uma equipe cirúrgica se tornou redundante devido ao aumento da Internet, ambientes de desenvolvimento integrados e kits de desenvolvimento de software , que podem assumir muitas das funcionalidades que Fred Brooks atribuiu à equipe cirúrgica, incluindo:

• Cirurgião: um programador
• Co-piloto: emparelhe programadores , colegas de trabalho, comunidades online como StackExchange ou IRC
• Administrador: função geralmente assumida por um gerente de projeto de software
• Editor: IDEs integrando geradores de documentação como Javadoc ou Doxygen; documentação de kits de desenvolvimento de software
• Secretário: cliente de e-mail, ferramentas de gerenciamento de projetos, como rastreadores de problemas e solicitações pull, salas de bate-papo e listas de discussão da empresa
• Funcionário do programa: IDE armazenando informações no design do projeto, com a capacidade adicional de refatorar o código; documentação e exemplos de kits de desenvolvimento de software
• Toolsmith: toda a comunidade de código aberto
• Testador: imediatamente, suítes de teste e bibliotecas de teste. Mas é claro que é necessário um processo de controle de qualidade separado para o código de produção.
• Advogado de idiomas: documentação on-line, StackExchange

Eu acho que você precisa olhar para a premissa do Mês do Homem Mítico. A contratação de mais programadores só piora um projeto de software problemático / atrasado. O problema está na comunicação e na atualização dos programadores recém-adicionados (leva tempo no desenvolvimento existente), na tecnologia e, às vezes, no próprio domínio.

Um programador bem suportado elimina muito do tempo de comunicação e coordenação. Digamos que você contrate um consultor para a Tecnologia X. Em vez de acelerar esse consultor no projeto o suficiente para que esse indivíduo possa fazer toda a codificação nessa área, ele apenas orienta o desenvolvedor existente até o ponto em que ele pode construir algo com alguma supervisão.

Uma razão pela qual você não vê muito disso é porque a maioria dos softwares é escrita por uma pessoa de qualquer maneira. As equipes dividem o trabalho e todo mundo vai e faz o que quer. A programação em pares, as revisões e tudo o que cheira a microgerenciamento é mal visto. Muitos não vêem a programação como um esporte de equipe. Uma pessoa resolve um determinado problema com alguma consideração pelas restrições gerais.

Eu diria que quanto mais separamos design, implementação, teste, documentação, construção, implantação, operações etc. em funções únicas feitas por especialistas, mais seguimos a filosofia da "equipe cirúrgica" (embora talvez não exatamente da maneira descrita )

Na minha experiência, a filosofia do devOps de que todas as pessoas devem ser capazes de todas as tarefas é um retorno ao modelo de abate de porcos (para não dizer que é ruim, apenas diferente).

Como programador que costumava ocupar os papéis de DevOps e Build Master, eu sentia que acabava nessa posição de ser a equipe cirúrgica ... err ... cara na equipe. Como mestre de construção, eu tinha uma visão geral de todo o código e era a primeira linha quando falhava. Muitas vezes, eu mesmo consertava.
Muitas vezes, eu escrevia esses sistemas de métricas e media os pontos de acesso no código, partes que falhavam com mais frequência, que atraíam mais relatórios de bugs etc. Não apenas publiquei os resultados para a equipe, mas também os analisei. que causou problemas e propôs soluções e alterações arquiteturais para resolver isso.

Como DevOps, eu automatizava grandes quantidades de processos e custos indiretos. Eu pesquisava tecnologias e ferramentas que facilitariam a vida da equipe, de toda a equipe, desde desenvolvedores, testadores de controle de qualidade, operações de TI até o gerenciamento. Meu papel era entender o processo, sim; mas, mantendo meus olhos fixos na equipe (os humanos reais) usando (sofrendo) esse processo, eu era capaz de destilá-lo a um ponto de torná-lo completamente transparente enquanto ainda obtinha uma faixa de dados úteis para obter uma visão objetiva disso. sempre evasivo "quadro geral".

É uma posição ingrata de ter e provavelmente por que é tão evitada. Sei que fiz bem meu trabalho quando ninguém percebeu esse processo, quando ninguém pensou no pipeline de construção. Então, sim, uma máquina bem oleada é rapidamente considerada um dado adquirido. Mas eu sabia, de fato, que medi, o impacto multiplicativo que esse trabalho pode ter na produtividade de uma equipe e vale a pena o investimento.

Então, sim, acho que esse papel ainda está muito vivo hoje, apesar de ter evoluído do que era na época.