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

164

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?
vog
fonte
12
Eu diria que isso só pode trazer respostas baseadas em opiniões. Minha opinião instintiva é que nenhum "engenheiro de software" quer ser visto como um papel de "suporte". Eles querem ser vistos como iguais a todos os outros da equipe. Isso pode estar relacionado ao fato de que a maioria dos desenvolvedores de software é extremamente jovem. A maioria das equipes não tem ninguém que possa reivindicar a antiguidade e ser considerado o "cirurgião" da equipe.
Euphoric
43
Um problema em potencial que vejo quando você intencionalmente tenta organizar uma equipe dessa maneira é identificar corretamente quem deve ser o cirurgião.
Bart van Ingen Schenau,
9
@Euphoric Não se esqueça de alguns dos gerentes que se iludem ao pensar que já têm seu programador de super-guru-estrela-cirurgião, então por que empregar todos esses camponeses de apoio em primeiro lugar? Vi minha parcela de gerentes que não mostraram evidências de entender o desenvolvimento de software e seus desafios inerentes ao "gerenciar" equipes de software ou muito além de suas planilhas coloridas de excel, infelizmente (normalmente, embora nem sempre, pessoas próximas à aposentadoria )
code_dredd
7
Pode ter algo a ver com o fato de que "cirurgia" é um dos ramos mais remotos da medicina - na verdade, é uma piada bem conhecida no Reino Unido que os cirurgiões passam 7 anos estudando para que possam ser chamados de "médico", e mais sete anos para que possam ser chamados de "senhor" ou "sra" novamente! De fato, reorganizar a cirurgia para melhorar seu desempenho, seguindo as "melhores práticas" de outras indústrias com taxas de erro muito mais baixas, etc. (em particular, aviação civil) é um esforço contínuo da profissão médica. ...
alephzero
6
@alephzero: Essas são algumas afirmações engraçadas. Onde exatamente você praticou a cirurgia? Aqui, a quantidade de porcaria que você chama de "melhores práticas" ocupa grande parte do tempo de um cirurgião e produz benefício zero. Pessoas super inteligentes [irônicas] se esforçam para melhorar algo que não entendem, adicionando mais porcarias burocráticas a ele quase toda semana. As causas da taxa de falhas mencionadas, no entanto, não são abordadas, pelo contrário. Quase todas as falhas são devidas à privação do sono, falta de educação e superestimação. Muitas vezes, os três juntos.
Damon

Respostas:

103

"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... :-}

Bob Jarvis
fonte
20
Se alguém que lê isso tem a edição do 20º aniversário do livro, vale a pena ler o novo prefácio e o novo capítulo 19. Embora até a edição do 20º aniversário tenha mais de 20 anos a partir de 2017, o autor aponta várias das afirmações em essa resposta, que muitas vezes é negligenciada na pressa de resumir o livro inteiro, como "adicionar engenheiros a um projeto já atrasado o torna ainda mais tarde".
11
O que no mundo significa "UUGE"? Ótima resposta, a propósito.
Wayne Conrad
5
@WayneConrad vernacular por enorme .
ZzzzBov
11
Tendo sido um programador de sistemas IBM durante esse período, era comum ter papéis muito bem definidos na equipe, com especialização em uma determinada parte do sistema operacional. Espera-se que a pessoa em cada uma dessas funções saiba ou aprenda tudo o que há para saber sobre ela e atue como equipe de suporte para qualquer um dos outros especialistas. Essencialmente, acabamos com uma equipe cirúrgica por membro da equipe, cada um com sua própria especialidade.
9138 Joe McMahon
11
Em resposta ao seu comentário sobre cometer os mesmos erros repetidamente, o artigo da Wikipedia para o livro tem uma citação do autor que você pode gostar: A tendência dos gerentes de repetir esses erros no desenvolvimento do projeto levou Brooks a dizer que seu livro se chama "A Bíblia da engenharia de software", porque "todo mundo cita, algumas pessoas lêem e outras seguem".
Ryan
87

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.

Jörg W Mittag
fonte
11
Em relação ao segundo ao último parágrafo, acho que o cirurgião deveria trabalhar com caneta e papel e o funcionário seria o único membro da equipe com acesso ao computador.
Bart van Ingen Schenau
15
'você pode realmente imaginar pagar um funcionário em tempo integral para imprimir o código-fonte e indexá-lo e arquivá-lo manualmente?' Não, mas definitivamente posso imaginar pagar um funcionário em tempo integral para gerenciar o controle de versão e os sistemas de criação contínua e, de fato, em qualquer empresa de médio ou grande porte, essa é a norma. De fato, gerenciar wikis, sistemas de gerenciamento de documentos e esse é um papel totalmente separado e ainda maior, que geralmente há um tempo inteiro de escritores técnicos pagos para fazer em tempo integral.
Route de milhas
9
"a equipe inteira teria um computador para si ... foi um trecho" - no início dos anos 80, as organizações teriam sistemas baseados em minicomputadores + terminais, portanto, embora fosse o mesmo computador, os usuários ainda teriam acesso a ele de forma igual. base e a capacidade de executar seus próprios programas (assumindo que existia isolamento e segurança decentes do usuário).
Dai
2
Enquanto os computadores eram caros em 1975, os keypunches eram razoavelmente baratos. Quando eu programava mainframes (não em 75, mas em 77), escrevíamos o código no papel, perfurá-lo em cartões, entregá-lo em um wicket e depois verificar periodicamente para ver se a impressão havia sido devolvida. (O tempo de entrega pode ser de duas horas para nós e em alguns locais mais de um dia.) Um funcionário seria muito útil para todas, exceto a primeira dessas tarefas. Eu não vi terminais até 1979 mais ou menos.
Theodore Norvell
11
Re: Smalltalk - não apenas todos os desenvolvedores e todos os usuários deveriam ter seu próprio computador, esses computadores também deveriam ser computadores poderosos, com muita memória e uma GUI . Pense em "estação de trabalho" em vez de em "PC". Os PCs IBM originais não tinham a potência necessária para executar o Smalltalk. Uma vergonha Dang, na minha opinião ...
Bob Jarvis
20

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".)

Jon Watte
fonte
5
Votou devido à alegação absurda em relação ao aumento do custo da mão-de-obra. A mão-de-obra, mesmo o conhecimento especializado em engenharia, é mais barata hoje do que em 1969. De fato, o custo da mão-de-obra mais cara hoje sustenta toda essa resposta e é uma afirmação falsa.
precisa saber é o seguinte
2
@RibaldEddie com relação a quê? Se você comparar o trabalho com o custo de vida, ele estará diminuindo; uma hora de trabalho você pode obter mais alimentos / habitação do que poderia em 1969
k_g
3
@k_g bem, depende da localização. Em termos de inflação, na maioria dos lugares nos EUA, você pode contratar um desenvolvedor por menos em dólares ajustados pela inflação hoje do que em 1969. Para referência, no livro Brooks sugere 20 mil para o que hoje consideramos um arquiteto sênior de desenvolvimento e 10k para uma execução do programador do moinho que faz a maior parte do trabalho. Nos dólares de hoje, esses 10k são cerca de 65k. Hoje, ter a maioria dos desenvolvedores em sua equipe ganhando 65k é um preço muito bom.
precisa saber é o seguinte
3
Isso, essencialmente, os salários de software permanecem inalterados em relação a 1969. Dada a inflação geral e o maior custo de vida, os desenvolvedores estão significativamente mais baratos hoje.
precisa saber é o seguinte
11
De fato, todos os benefícios do ambiente econômico moderno em termos de produtividade e mão-de-obra mais barata foram todos para a classe executiva e acionista nos negócios. Como eu disse, mesmo ajustados pela inflação, os salários dos desenvolvedores de software permaneceram os mesmos, enquanto a remuneração dos executivos aumentou centenas de vezes mais que a inflação. Além disso, muitos lugares, particularmente ao longo da costa oeste da América do Norte, os custos de vida aumentaram significativamente mais rapidamente que a inflação (ver imóveis) e, no entanto, os salários dos desenvolvedores profissionais mal acompanharam a inflação.
precisa saber é o seguinte
13

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

Chococroc
fonte
Essa citação é basicamente o que eu estava pensando: soa como programação em pares, onde o "cirurgião" é o que chamamos de "motorista", exceto em uma escala diferente.
Izkata
7
Parece-me que isso exigiria desenvolvedores de software competentes extrovertidos e orientados para as pessoas. Boa sorte com isso.
21417 Bob
Vim aqui para dizer isso; ou várias formas de auto-organização da equipe.
Marcin
2
@BobJarvis Eu discordo. Tive grande sucesso trabalhando em equipes de introvertidos (e acho que alguns também incluíam extrovertidos). A chave é criar um espaço onde as pessoas se sintam seguras e abertas a contribuir, e estejam dispostas a aumentar suas inclinações naturais por um tempo para o benefício do grupo. Silêncio de Susan Cain foi uma grande ajuda na compreensão de como trabalhar bem com temperamentos diferentes: ted.com/talks/susan_cain_the_power_of_introverts
David Carboni
12

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.

Matt Everson
fonte
9

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.

RibaldEddie
fonte
11
Então, basicamente, nada aconteceu. +
Gordy
11
@ordy sim e não. Você notará que, no exemplo de Brook, é bem provável que os gerentes determinem quem estava em cada função da equipe, mas, em um conceito ágil moderno, a equipe é auto-organizada. Portanto, os papéis de cirurgião ou copiloto caem naturalmente da maneira como a equipe trabalha. Eu acho que essa é uma diferença fundamental: auto-organização vs. ditada pela empresa.
precisa saber é o seguinte
Eu mudaria "mais" para "alguns". Realmente depende da dinâmica da equipe. E definitivamente tem que crescer organicamente se um cirurgião for ditado de cima, o resultado será abaixo do ideal, portanto +1 para se auto-organizar.
Peter
2
Palavras do Tao do software: #IV - O Tao do trabalho em equipe: Um bom software é escrito por pequenas equipes trabalhando rapidamente. Um software ruim é escrito por grandes equipes trabalhando lentamente. Corolários: - O tamanho ideal de uma equipe é 1; - O valor prático máximo para o tamanho da equipe é 3; - Para tamanhos de equipe> 3, a (des) comunicação se torna um problema sério; - Para o tamanho da equipe> 6, a conclusão do projeto fica seriamente comprometida. A conclusão do projeto dentro do prazo provavelmente está fora da janela. Em casos como este os desenvolvedores mais inteligentes usará a porta ... Assim está escrito ... ( BWOOoooonnnggggg !!! )
Bob Jarvis
6

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.

Charles Merriam
fonte
9
A parte que me faz sorrir (?) É a coisa "... vários gerentes ...". Um gerente é mais que suficiente para reduzir a produtividade. Vários gerentes podem levar os desenvolvedores a pensar em suicídio (introvertidos) ou assassinato (extrovertidos).
21417 Bob
4
@ BobJarvis - Eu tive, dependendo do projeto, até cinco "gerentes" simultâneos com títulos variados. O efeito é praticamente o que você imagina.
9789 Roblfordford
11
Obviamente você é extrovertido. Então ... defesa da loucura? México? Ou ... homicídio justificável ..? :-)
Bob Jarvis
É por isso que eu tinha cinco chefes em uma empresa. Enquanto eu estava lá, qualquer problema, fosse meu ou de outra pessoa, eu o ouviria de cinco perspectivas diferentes. Normalmente, eu o analisava quando o número 2 chegava e era irritante ouvir isso mais vezes.
Robert Baron
A idéia original não era "ter cinco gerentes diferentes tentando interferir", mas fornecer, por exemplo, "uma pessoa de benefícios de RH" e "uma pessoa de desenvolvimento de carreira de RH" etc. Acho que vários gerentes funcionariam se você cobrasse o departamento de cada gerente com base em com que frequência eles entraram em contato com o engenheiro. Faria um videogame divertido!
Charles Merriam
2

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
Gaurav
fonte
1

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.

JeffO
fonte
0

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).

Mike Ounsworth
fonte
2
Definitivamente, esse não é o modelo do DevOps.
precisa saber é o seguinte
5
De fato, o DevOps é mais parecido com o modelo da equipe cirúrgica, porque as Operações do desenvolvedor implicam que existem operações em serviço ao desenvolvimento. O DevOps é sobre dois conceitos principais: que as operações devem ser vistas como uma prática de desenvolvimento e, portanto, que as ferramentas e técnicas usadas no desenvolvimento, como controle de origem e métodos ágeis de gerenciamento, devem ser usadas pelas operações e que as operações existem para apoiar o desenvolvimento.
precisa saber é o seguinte
11
@RibaldEddie Interessante. Minha experiência com o grupo DevOps na minha empresa é que eles contratam apenas desenvolvedores e são responsáveis ​​por tudo, desde desenvolvimento de produtos, testes, documentação, implantação etc. A palavra "multifuncional" vem à mente. Oh, bem, com 2 votos negativos e um voto de exclusão em 15 minutos, acho que vou ficar longe deste site.
Mike Ounsworth
11
Ah, então temos uma definição diferente de "interfuncional". Estou usando isso para significar que todo membro da equipe é capaz de realizar todas as tarefas - Jiras é rotineiramente jogado entre as pessoas porque elas acabaram com a especialização. Alguém que está desenvolvendo esse recurso testará ou documentará o próximo recurso. Esse é o "DevOps" que experimentei.
Mike Ounsworth
11
@MikeOunsworth: que é uma equipe de cross-funcionais :-D
Jörg W Mittag
0

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.

Newtopian
fonte