¿Qué pasó con el patrón del "Equipo quirúrgico" de "The Mythical Man-Month"?

164

Hace años, cuando leí The Mythical Man-Month, encontré muchas cosas que ya sabía de otras fuentes. Sin embargo, también había cosas nuevas allí, a pesar de que el libro era de 1975. Una de ellas era:

El equipo quirurgico

Mills propone que cada segmento de un trabajo grande se aborde como un equipo, pero que el equipo se organice como un equipo quirúrgico en lugar de un equipo de carnicería de cerdos. Es decir, en lugar de que cada miembro elimine el problema, uno hace el recorte y los demás le brindan todo el apoyo que mejorará su efectividad y productividad.

Este es un patrón muy interesante para organizar un equipo de desarrollo de software, pero nunca lo encontré descrito en ningún otro libro de Ingeniería de Software, ni siquiera mencionado en ningún lado.

¿Porqué es eso?

  • ¿Era el "Equipo quirúrgico" incluso inusual en aquel entonces?
  • O, ¿ha sido probado y fallido?
    • Si es así, ¿cómo falló?
    • Si no, ¿por qué no vemos ese patrón implementado en los proyectos de software actuales?
vog
fuente
12
Yo diría que esto solo puede traer respuestas basadas en opiniones. Mi opinión instintiva es que ningún "ingeniero de software" quiere ser visto como un rol de "soporte". Quieren ser vistos como iguales a todos los demás en el equipo. Esto puede estar relacionado con el hecho de que la mayoría de los desarrolladores de software son extremadamente jóvenes. La mayoría de los equipos no tienen a nadie que pueda reclamar antigüedad y ser considerado el "cirujano" del equipo.
Eufórico el
43
Un problema potencial que veo cuando intencionalmente intentas organizar un equipo de esa manera es identificar correctamente quién debe ser el cirujano.
Bart van Ingen Schenau
99
@Euphoric No se olvide de algunos de los gerentes que se engañan al pensar que ya tienen su programador super-súper-gurú-estrella-cirujano, entonces, ¿por qué emplear a todos esos campesinos de apoyo en primer lugar? Desafortunadamente, he visto mi parte de gerentes que no mostraron evidencia de comprender el desarrollo de software y sus desafíos inherentes al "administrar" equipos de software, o mucho más allá de sus coloridas hojas de cálculo de Excel (generalmente, aunque no siempre, personas cercanas a la jubilación )
code_dredd
77
Puede tener algo que ver con el hecho de que la "cirugía" es una de las ramas de la medicina más retrospectivas; de hecho, es una broma bien conocida en el Reino Unido que los cirujanos pasan 7 años estudiando para que puedan ser llamados "médicos", ¡y luego otros 7 años para que puedan volver a llamarse "Sr." o "Sra."! De hecho, reorganizar la cirugía para mejorar su desempeño siguiendo la "mejor práctica" de otras industrias con tasas de error mucho más bajas, etc. (en particular, la aviación civil) es un esfuerzo continuo dentro de la profesión médica. ...
alephzero
66
@alephzero: Esas son un par de afirmaciones divertidas. ¿Dónde practicaste exactamente la cirugía? Aquí, la cantidad de basura que usted llama "mejor práctica" ocupa una parte importante del tiempo del cirujano y no produce ningún beneficio. Las personas súper inteligentes [irónicas] se esfuerzan mucho por mejorar algo que no entienden agregando más basura burocrática casi todas las semanas. Sin embargo, las causas de la tasa de falla que usted menciona no se abordan, por el contrario. Casi todas las fallas se deben a la falta de sueño, la falta de educación y la sobreestimación. A menudo los tres juntos.
Damon

Respuestas:

103

"The Mythical Man-Month" salió el año en que comencé la universidad y, para usar el vernáculo actual, ¡INDIVIDUAL! :-) Lo que necesita comprender es la diferencia en cómo se desarrolló el software ENTONCES vs. AHORA. Back In The Day (tm) casi toda la codificación se realizó primero en papel, luego se introdujo en las tarjetas perforadas (lo adivinó), luego se leyó, compiló, vinculó, ejecutó, se obtuvieron resultados y se repitió el proceso. El tiempo de CPU fue costosoy recursos limitados y no quería desperdiciarlo. Lo mismo ocurre con el espacio en disco, el tiempo de la unidad de cinta, etc., bla. Perder un tiempo de CPU perfectamente bueno en una compilación que resultó en errores (¡sorpresa y horror!) Fue ... bueno, una pérdida de tiempo de CPU perfectamente bueno. Y esto fue en 1975. En el momento en que Fred Brooks estaba desarrollando sus ideas, que era de mediados a fines de la década de 1960, el tiempo de CPU era aún máscostoso, memoria / disco / lo que fuera MÁS limitado, etc., etc. La idea detrás de The Surgical Team era asegurarse de que One Super Great Rockstar Developer no tuviera que perder su tiempo en tareas mundanas como código de verificación de escritorio, pulsación de teclas, enviar trabajos, esperar (a veces horas) los resultados. Rockstar Dude Developer Man debía ser CÓDIGO DE ESCRITURA. Se suponía que su legión de fanáticos / empleados / desarrolladores junior debía hacer lo mundano.

El problema era que dentro de los 2 años posteriores a la publicación del libro de Brooks, las ideas básicas detrás de The Surgical Team se estaban desmoronando:

  1. Los terminales CRT y los archivos de disco comenzaron a reemplazar los juegos de teclas y los mazos de tarjetas. El tiempo de la computadora se volvió menos costoso, varias computadoras estuvieron disponibles y el tiempo de entrega del trabajo disminuyó drásticamente. Cuando llegué a la universidad (Miami University, Oxford, Ohio, clase del '79, gracias por preguntar) bienel cambio de trabajo fue de aproximadamente una hora. Durante la semana final: cuatro horas, tal vez, a veces seis. (Competimos por tiempo de CPU con un grupo de empresas comerciales y universidades, y los usuarios comerciales obtuvieron la primera prioridad). Durante mi último año, cuando Miami había salido de su arreglo de "computadora compartida", tenía su propio IBM 370/145 instalado en el campus, y tenía un buen HP mini en el que trabajaba que actuaba como una estación RJE en la que podíamos convertir mainframe trabajos en cinco minutos o menos. Ahora valía la pena golpear su código en el HP, enviarlo desde el HP a la unidad central, girar los pulgares / fumar un cigarrillo y recuperar su salida mucho antes de que pudiera terminar de verificar su código en el escritorio.

  2. El Equipo Quirúrgico tiene como premisa básica la idea de que usted (o "administración", que Dios nos ayude a todos) puede identificar a The Rockstar Surgical Developer Dude. De hecho, dudo que sea posible. No son los desarrolladores de Rockstar, todo el mundo sabe que - los estudios han demostrado diferencias de productividad entre los mejores y peores desarrolladores de hasta un 2000% - pero la identificación de esa persona sin tener que escribir código durante un largo período de tiempoEs muy probable que sea imposible. La única forma de saber si alguien es un desarrollador de rockstar es hacer que realmente desarrollen el código, pero si NO son el Desarrollador Quirúrgico de Rockstar, estarán haciendo cosas emocionantes como verificar su código en el escritorio, introducirlo en las tarjetas y enviando cajas de tarjetas perforadas al departamento de Ingreso de trabajo, y luego esperando los resultados para que puedan regresarlas al Sr. Rockstar Surgical Developer Dude en lugar de aprender a codificar de la única manera que realmente funciona: escribiendo código, depurando código, y etc. Back In The Day (tm) no hubo concursos de programación, no hubo desbordamiento de pila, no tenía una PC en la que pudiera escribir código cada vez que quisiera, no había libros de Algoritmos para idiotas: la única forma de aprender programación era ir a la escuela y especializarse en algo en lo que debías programar un poco. Pero la programaciónper se no se tomó en serio, y se asumió que era algo que la gente no quería hacer . En mi primer curso universitario (SAN151 - Introducción al análisis de sistemas, Dr. Tom Schaber - gracias, Tom :-) el instructor nos dijo que "... solo teníamos que enfrentar el hecho de que tendríamos que gastar un Un par de años como programadores antes de que pudiéramos convertirnos en analistas de sistemas ". "¿Dos años?", Pensé. "¿SOLO PUEDO HACER ESTO POR DOS AÑOS?!?". Estaba seriamente desanimado. Afortunadamente se equivocó y he estado codificando desde entonces. :-)

  3. El equipo quirúrgico supone que los programadores son un recurso relativamente raro. Realmente tomó unos años más, pero con la llegada de las PC a principios de los 80, la programación se convirtió en algo en lo que cualquier geek podría involucrarse. El precio de las computadoras comenzó a caer, el precio de las herramientas de desarrollo comenzó a caer, y todo fue granizo Turbo Pascal: para los estándares de hoy no era mucho, pero en ese momento era un IDE Pascal completo por aproximadamente 40 dólares, ¡lo cual era absolutamente loco! Ahora CUALQUIERA podría entrar en la programación, si pudiera pagar una computadora, y cuando IBM decidió poner la PCjr (sí, mi primera PC fue uno de los mayores errores de IBM :-) a la venta por alrededor de $ 500 para deshacerse de esos pavos, efectivo frikis atrapados en todas partes se saltaron el pago de la renta durante un mes ("Sí, eh, lo sé, pero yo, eh ... me rompí la uuvula y tuve que someterme a una cirugía y ... .uh ... sí, la semana que viene, no hay problema, gracias, hombre ...) y los tragué a precios increíbles. Luego gasté más de lo que pagamos por la computadora en complementos para que sea utilizable. ("Sí, hombre, la próxima semana, seguro, probablemente ..." :-).

Lo que me entristece realmente es que incluso hoy, si le preguntas a la gente si alguna vez leyeron "The Mythical Man-Month" o si entendieron su lección principal ("Agregar recursos a un proyecto tardío lo hace más tarde") te dan un espacio en blanco mirar fijamente, y luego proceder a cometer exactamente los mismos errores que se cometieron todos esos años atrás durante el desarrollo de OS / 360. Todo lo viejo es nuevo otra vez... :-}

Bob Jarvis
fuente
20
Si alguien que lee esto tiene la edición del vigésimo aniversario del libro, vale la pena leer el nuevo prefacio y el nuevo capítulo 19. Si bien incluso la edición del vigésimo aniversario tiene más de 20 años a partir de 2017, el autor señala varias de las afirmaciones en Esta respuesta, que a menudo se pasa por alto en la prisa por resumir todo el libro como "agregar ingenieros a un proyecto que ya está retrasado, lo hace aún más tarde".
1
¿Qué significa "UUGE" en el mundo? Gran respuesta, por cierto.
Wayne Conrad
55
@WayneConrad vernáculo para enorme .
zzzzBov
1
Habiendo sido un programador de sistemas de IBM durante ese período, era común tener roles muy bien definidos en el equipo, con una especialidad en una parte particular del sistema operativo. Se esperaría que la persona en cada uno de esos roles sepa o aprenda todo lo que hay que saber al respecto, y actúe como personal de apoyo para cualquiera de los otros expertos. Básicamente terminamos con un equipo quirúrgico por miembro del personal, cada uno con su propia especialidad.
Joe McMahon
1
En respuesta a su comentario sobre cometer los mismos errores una y otra vez, el artículo de Wikipedia para el libro tiene una cita del autor que podría gustarle: la tendencia de los gerentes a repetir tales errores en el desarrollo del proyecto llevó a Brooks a decir que su libro se llama "La Biblia de la Ingeniería del Software", porque "todo el mundo lo cita, algunas personas lo leen y algunas personas lo siguen".
Ryan
87

Hay algunos aspectos de ese concepto que están a veces en práctica hoy en día, hay otros aspectos que son evitados .

Mantener equipos pequeños es una de las características básicas de Agile Methods, pero también se practica fuera de Agile.

Los equipos multifuncionales también son un elemento básico de Agile, pero también son comunes fuera de Agile.

El papel del secretario del programa está ampliamente subsumido por sistemas computarizados como los sistemas de control de versiones, sistemas de gestión de configuración de software, sistemas de gestión de cambios, sistemas de gestión de documentos, wikis, sistemas de construcción continua con repositorios de artefactos, etc. Quiero decir, ¿te imaginas pagarle a un empleado a tiempo completo para imprimir el código fuente e indexarlo y archivarlo manualmente?

Del mismo modo, el papel de un administrador del sistema (no parte del equipo quirúrgico de Mills, sino parte de un equipo multifuncional típico de los últimos años) está siendo obsoleto por conceptos como DevOps (absorbiendo el papel de Sysadmin en el papel de ingeniero de software) , Plataforma como servicio, Infraestructura como servicio e Informática de servicios públicos (haciendo del rol de Sysadmin "el problema de otra persona") o Infraestructura como código (convirtiendo la Administración del sistema en Ingeniería de software).

Uno de los aspectos que tratamos de evitar hoy en día es que, como máximo, dos personas entienden el sistema. Solo el cirujano tiene la garantía de comprender completamente el sistema, el copiloto puede o no. Esto da un factor de bus de entre 1 y 2. Si el cirujano se enferma, el proyecto está muerto. Período. La respuesta ágil a eso es la propiedad del código colectivo, que es exactamente lo contrario de ese modelo: nadie es el único responsable de ninguna parte del sistema. En cambio, todos son responsables de todo como grupo .

Por último, hay algunas suposiciones integradas en ese concepto, que están desactualizadas. Por ejemplo, aunque no se indique explícitamente, el equipo está configurado de tal manera que solo una persona del equipo (el cirujano) tiene una computadora. Eso es, por supuesto, porque en el momento en que se escribió el artículo, incluso la idea de que todo un equipo tendría una computadora para ellos, y mucho menos una persona en el equipo, era una exageración. (Incluso en 1980, cuando se lanzó Smalltalk, una de las cosas que contribuyó a su falla fue el hecho de que el sistema estaba configurado de tal manera que cada desarrollador y cada usuario tenían su propia computadora, completamente impensable en ese momento).

En resumen: no creo que el concepto se haya implementado exactamente como se describe, pero algunos aspectos definitivamente se implementan, algunos se consideran indeseables y se evitan activamente, algunos son obsoletos y otros son probablemente Good Ideas ™, Pero nadie lo hace.

Jörg W Mittag
fuente
1
Con respecto al penúltimo párrafo, creo que se esperaba que el cirujano trabajara con lápiz y papel y que el empleado hubiera sido el único miembro del equipo con acceso a la computadora.
Bart van Ingen Schenau
15
'¿realmente puede imaginar pagarle a un empleado a tiempo completo para imprimir el código fuente e indexarlo y archivarlo manualmente?' No, pero definitivamente puedo imaginar pagarle a un empleado a tiempo completo para administrar el control de versiones y los sistemas de compilación continua, y de hecho en cualquier empresa mediana o grande, esta es la norma. De hecho, la gestión de wikis, sistemas de gestión de documentos y tal es un papel completamente separado, incluso más grande que generalmente hay un tiempo completo de escritores técnicos que pagan por hacer a tiempo completo.
Miles Rout
99
"Todo el equipo tendría una computadora para sí mismos ... era una exageración": a principios de la década de 1980, las organizaciones tenían sistemas basados ​​en minicomputadoras + terminales, por lo que, si bien era la misma computadora, los usuarios aún tendrían acceso a ella de la misma manera base y la capacidad de ejecutar sus propios programas (suponiendo que existiera un aislamiento y seguridad decente del usuario)
Dai
2
Mientras que las computadoras eran caras en 1975, las combinaciones de teclas eran bastante baratas. Cuando programé mainframes por primera vez (no en 75, sino en 77), escribíamos el código en papel, lo perforamos en las tarjetas, lo enviamos a un wicket y luego revisamos periódicamente para ver si la impresión había sido devuelta. (El tiempo de entrega podría ser de 2 horas para nosotros y en algunos sitios más de un día). Un empleado hubiera sido muy útil para todas las tareas, excepto la primera. No vi terminales hasta 1979 más o menos.
Theodore Norvell
1
Re: Smalltalk: no solo se suponía que cada desarrollador y cada usuario tenían su propia computadora, sino que también se suponía que esas computadoras eran computadoras poderosas con mucha memoria y una GUI . Piense en "estación de trabajo" en lugar de "PC". Las PC originales de IBM no tenían la potencia para ejecutar Smalltalk. Una lástima, en mi opinión ...
Bob Jarvis
20

Solía ​​ser, una educación universitaria era algo único, y los ingenieros estaban entre los pocos elegidos. Las computadoras eran caras y los equipos trabajaban en proyectos con un ROI comercial definido. Estos no eran muy comunes.

Lo que sucedió fueron las micro computadoras, la ubicua educación universitaria y los sistemas informáticos que ni siquiera necesitan títulos universitarios para progresar. Además, lo que sucedió fue un cambio en la economía y un aumento en el costo de la mano de obra.

La economía de una relación 8: 2 de soporte: ingeniero ya no tiene sentido. Los ingenieros deben ser su propio apoyo. Un ser humano moderno con suficiente educación y habilidades para ser eficaz unido a un equipo de desarrollo es demasiado costoso para no estar haciendo su propio desarrollo de algún tipo.

(Un término económico relacionado es "la enfermedad del costo del sector de servicios").

Jon Watte
fuente
55
Voté en contra debido al absurdo reclamo sobre el aumento del costo de la mano de obra. La mano de obra, incluso el conocimiento especializado en ingeniería, es más barata hoy que en 1969. De hecho, el costo de la mano de obra que es más cara hoy respalda toda esta respuesta y es una afirmación falsa.
RibaldEddie
2
@RibaldEddie con respecto a qué? Si compara la mano de obra con el costo de vida, ha estado disminuyendo; una hora de trabajo puede brindarle más comida / vivienda de lo que podría en 1969
k_g
3
@k_g bueno, depende de la ubicación. En términos de inflación, en la mayoría de los lugares de los EE. UU., Puede contratar a un desarrollador por menos en dólares ajustados a la inflación hoy que en 1969. Como referencia, en el libro Brooks sugiere 20k para lo que hoy consideraríamos un arquitecto de desarrollo senior y 10k para una ejecución del programador de fábrica que hace la mayor parte del trabajo. En dólares de hoy, esos 10k son aproximadamente 65k. Hoy, tener la mayoría de los desarrolladores de tu equipo que ganan 65k es un muy buen precio.
RibaldEddie
3
Esto, esencialmente, los salarios del software no han cambiado desde 1969. Dada la inflación general y el mayor costo de vida, los desarrolladores son significativamente más baratos hoy en día.
RibaldEddie
11
De hecho, todos los beneficios del entorno económico moderno en términos de productividad y mano de obra más barata han pasado a la clase ejecutiva y de accionistas en los negocios. Como dije, incluso ajustado por la inflación, los salarios de los desarrolladores de software se han mantenido igual, mientras que la compensación ejecutiva ha aumentado muchos cientos de veces más que la inflación. Además, en muchos lugares, particularmente a lo largo de la costa oeste de América del Norte, los costos de vida han aumentado significativamente más rápido que la inflación (ver bienes raíces) y, sin embargo, los salarios de los desarrolladores profesionales apenas han mantenido el ritmo de la inflación.
RibaldEddie
13

Estos patrones me suenan mucho a la programación de Mob:

Todo el grupo (control de calidad, desarrolladores e incluso propietario del producto, si es necesario) está trabajando al mismo tiempo en el mismo problema. Sin soporte, alta comunicación, implementada directamente en vivo.

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

El concepto básico de la programación de la mafia es simple: todo el equipo trabaja en equipo en una tarea a la vez. Es decir: un equipo, un teclado (activo), una pantalla (proyector, por supuesto). Es como hacer una programación de pareja de equipo completo.

Véalo en acción aquí: https://www.youtube.com/watch?v=dVqUcNKVbYg

Chococroc
fuente
Esa cita es básicamente lo que estaba pensando: suena como programación de pares, donde el "cirujano" es lo que hemos llamado el "controlador", excepto en una escala diferente.
Izkata
77
Me parece que esto requeriría que extrovertidos desarrolladores de software competentes orientados a las personas. Mucha suerte con eso.
Bob Jarvis
Vine aquí para decir esto; o varias formas de autoorganización del equipo.
Marcin
2
@BobJarvis No estoy de acuerdo. He tenido un gran éxito trabajando en equipos de introvertidos (y creo que algunos que también incluían extrovertidos). La clave es crear un espacio donde las personas se sientan seguras y abiertas a contribuir, y estén dispuestas a estirar sus inclinaciones naturales por un tiempo para el beneficio del grupo. Quiet de Susan Cain fue de gran ayuda para comprender cómo trabajar bien con diferentes temperamentos: ted.com/talks/susan_cain_the_power_of_introverts
David Carboni
12

Este modelo de equipo se menciona nuevamente en Desarrollo rápido - Programación de software de domesticación salvaje por Steve McConnell en la página 305. Allí se llama Equipo de programador jefe.

Este modelo surgió porque había un genio en el equipo y los recursos informáticos eran limitados. Ha caído en desgracia porque el genio es raro, y con computadoras ubicuas y control de versión distribuido tenemos espacio para muchas manos en la mesa de operaciones.

Otras referencias:

Baker, F. Terry. "Jefe de programación del equipo de gestión de programación de producción", IBM Systems Journal, vol. 11, no. 1, 1972, pp. 56-73.

Baker, F. Terry y Harlan D. Mills. "Jefe de equipos programadores". Datamation, Volumen 19, Número 12 (diciembre de 1973), pp. 58-61.

Matt Everson
fuente
9

Creo que la mayoría de los pequeños equipos autoorganizados tenderán a conformarse con un modelo de equipo quirúrgico de facto de todos modos.

Los últimos dos equipos en los que he estado tienden a consistir en tres o cuatro personas, generalmente un senior (cirujano), un intermedio (copiloto) y un par de juniors / especialistas. Algunos de los roles en el equipo quirúrgico mencionados por Brooks hoy en día son desempeñados por maestros Scrum y administradores de sistemas o proveedores de la nube. Recuerde que el control de fuente apenas existía en ese momento, y mucho menos algo tan poderoso como git.

Piensa en la regla de las dos pizzas de Bezos. Ese es su equipo quirúrgico autoorganizado allí mismo.

RibaldEddie
fuente
1
así que, básicamente, no le pasó nada. +
gordy
1
@ gordy sí y no. Notarás que en el ejemplo de Brook, con toda probabilidad dependería de los gerentes determinar quién estaba en cada rol en el equipo, pero en un concepto ágil moderno, el equipo se autoorganiza. Por lo tanto, los roles de cirujano o copiloto se deducen naturalmente de la forma en que trabaja el equipo. Creo que esa es una diferencia clave: autoorganizarse versus dictado por la compañía.
RibaldEddie
Cambiaría "la mayoría" a "algunos". Realmente depende de la dinámica del equipo. Y definitivamente tiene que crecer orgánicamente si un cirujano es dictado desde arriba, el resultado será subóptimo, por lo que +1 para autoorganizado.
Peter
2
Dichos del Tao del software: #IV - El Tao del trabajo en equipo: un buen software está escrito por pequeños equipos que trabajan rápido. El mal software está escrito por grandes equipos que trabajan lentamente. Corolarios: - El tamaño óptimo de un equipo es 1; - El valor práctico máximo para el tamaño del equipo es 3; - Para tamaños de equipo> 3, la (mala) comunicación se convierte en un problema grave; - Para el tamaño del equipo> 6, la finalización del proyecto se ve seriamente comprometida. La finalización del proyecto en la fecha límite probablemente salga por la ventana. En casos como este, los desarrolladores más inteligentes usarán la puerta ... Así está escrito ... ( BWOOoooonnnggggg !!! )
Bob Jarvis
6

Había un documento de HP que sugería algo similar:

  • Cada ingeniero de software requeriría múltiples gerentes y múltiples personas de soporte.
  • Debe haber un escritor técnico, un probador, un administrador de compilación y un fabricante de herramientas para cada ingeniero.

El periódico estaba en los días previos a la web, y de vez en cuando aparecía como algo gracioso. Cada año que se mencionaba, el comentario se movía un poco más de "tan ridículo es divertido" a "tal vez deberíamos hacer eso".

Las pruebas reales son notoriamente difíciles de diseñar, por lo que probablemente siga siendo una opinión. Puede haber algunas encuestas de proyectos y sus tasas de finalización.

Charles Merriam
fuente
99
La parte que me hace sonreír (?) Es la cosa "... gerentes múltiples ...". Un gerente es más que suficiente para reducir la productividad. Varios gerentes pueden llevar a los desarrolladores a pensar en suicidio (introvertidos) o asesinato (extrovertidos).
Bob Jarvis
44
@BobJarvis - He tenido, dependiendo del proyecto, hasta cinco "gerentes" simultáneos con diferentes títulos. El efecto es más o menos como te imaginas.
Rob Crawford
1
Obviamente eres un extrovertido. Entonces ... ¿defensa de locura? Mexico ¿O ... homicidio justificable ...? :-)
Bob Jarvis
Por eso tenía cinco jefes en una empresa. Mientras estuve allí, cualquier problema, ya fuera mío o de otra persona, lo escucharía desde 5 perspectivas diferentes. Por lo general, lo analicé cuando llegó el número 2 y fue molesto escucharlo allí más veces.
Robert Baron el
La idea original no era "tener cinco gerentes diferentes tratando de interferir", sino proporcionar, por ejemplo, "una persona de beneficios de recursos humanos" y "una persona de desarrollo de carrera de recursos humanos", etc. con qué frecuencia contactaban al ingeniero. ¡Sería un videojuego divertido!
Charles Merriam
2

Me pregunto qué parte de la necesidad de un equipo quirúrgico se ha vuelto redundante debido al aumento de Internet, los entornos de desarrollo integrados y los kits de desarrollo de software , que pueden asumir muchas de las funciones que Fred Brooks atribuyó al equipo quirúrgico, que incluyen:

  • Cirujano: un programador
  • Copiloto: programadores de pares , compañeros de trabajo, comunidades en línea como StackExchange o IRC
  • Administrador: función generalmente asumida por un gerente de proyecto de software
  • Editor: IDEs que integran generadores de documentación como Javadoc o Doxygen; documentación de kits de desarrollo de software
  • Secretario: cliente de correo electrónico, herramientas de gestión de proyectos como rastreadores de problemas y solicitudes de extracción, salas de chat de la empresa y listas de correo
  • Empleado del programa: IDE que almacena información sobre el diseño del proyecto, con la capacidad adicional de refactorizar el código; documentación y ejemplos de kits de desarrollo de software
  • Toolsmith: toda la comunidad de código abierto
  • Probador: de forma inmediata, conjuntos de pruebas y bibliotecas de prueba. Pero, por supuesto, es necesario un proceso de control de calidad separado para el código de producción.
  • Abogado de idiomas: documentación en línea, StackExchange
Gaurav
fuente
1

Creo que debes mirar la premisa del Mes del hombre mítico. Contratar más programadores solo empeora un proyecto de software problemático / vencido. El problema está en la comunicación y en poner a los programadores recién agregados a acelerar el proyecto (toma tiempo del desarrollo existente), la tecnología y, a veces, el dominio mismo.

Un programador bien soportado elimina gran parte del tiempo de comunicación y coordinación. Supongamos que contrata a un consultor para Tecnología X. En lugar de poner a este consultor a la altura del proyecto lo suficiente como para que este individuo pueda hacer toda la codificación en esa área, simplemente entrena al desarrollador existente hasta el punto en el que puede obtener algo construido con algo de supervisión

Una razón por la que no ve mucho de esto es porque la mayoría del software es escrito por una persona de todos modos. Los equipos dividen el trabajo y todos van y hacen lo suyo. La programación de pares, las revisiones y todo lo que huele a microgestión está mal visto. Muchos no ven la programación como un deporte de equipo. Una persona resuelve un problema dado con cierta consideración por las restricciones generales.

JeffO
fuente
0

Yo diría que cuanto más separamos el diseño, la implementación, las pruebas, la documentación, la construcción, el despliegue, las operaciones, etc. en roles únicos realizados por especialistas, más seguimos la filosofía del "equipo quirúrgico" (aunque tal vez no exactamente de la manera descrita )

En mi experiencia, la filosofía de devOps de que cada persona debe ser capaz de cada tarea es un retorno al modelo de carnicería de cerdo (por no decir que es malo, simplemente diferente).

Mike Ounsworth
fuente
2
Definitivamente ese no es el modelo DevOps.
RibaldEddie
55
De hecho, DevOps se parece más al modelo de equipo quirúrgico porque Developer Operations implica que las operaciones existen al servicio del desarrollo. DevOps se trata de dos conceptos centrales: que las operaciones deben verse como una práctica de desarrollo y, por lo tanto, que las herramientas y técnicas utilizadas en el desarrollo, como el control de origen y los métodos ágiles de gestión, deben ser utilizadas por las operaciones y que las operaciones están ahí para apoyar el desarrollo.
RibaldEddie
1
@RibaldEddie Interesante. Mi experiencia con el grupo DevOps en mi empresa es que solo contratan desarrolladores y son responsables de todo, desde el desarrollo del producto, las pruebas, la documentación, la implementación, etc. La palabra "multifuncional" viene a mi mente. Bueno, con 2 votos negativos y un voto de eliminación en 15 minutos, supongo que me mantendré alejado de este sitio.
Mike Ounsworth
1
Ah, entonces tenemos una definición diferente de "multifuncional". Lo estoy usando para significar que cada miembro del equipo es capaz de hacer todas las tareas: las Jiras se ven expulsadas rutinariamente entre las personas porque han eliminado la especialización. Alguien que esté desarrollando esta función probará o documentará la siguiente función. Ese es el "DevOps" que he experimentado.
Mike Ounsworth
1
@MikeOunsworth: ese es un equipo de funciones cruzadas :-D
Jörg W Mittag
0

Como programador que a menudo desempeñaba los roles de DevOps y Build Master, sentí que a menudo terminaba en esa posición de ser el equipo quirúrgico ... err ... chico del equipo. Como maestro de compilación, tenía una visión general de todo el código y era la primera línea cuando fallaba. A menudo lo arreglaba yo mismo.
A menudo, yo era el que escribía estos sistemas de métricas y medía los puntos de acceso en el código, partes que fallaban con más frecuencia, que atraían la mayoría de los informes de errores, etc. No solo publicaba los resultados al equipo, también los analizaba, buscaba los torcedura que causó problemas y soluciones propuestas y cambios arquitectónicos para abordar esto.

Como DevOps, automatizaría grandes extensiones de procesos y gastos generales. Investigaría tecnologías y herramientas que facilitarían la vida del equipo, de todo el equipo, desde los desarrolladores, los probadores de control de calidad, las operaciones de TI hasta la administración. Mi papel era entender el proceso, sí; pero manteniendo mis ojos fijos en el equipo (los humanos reales) usando (sufriendo) ese proceso, pude destilarlo hasta el punto de hacerlo completamente transparente y al mismo tiempo obtener una franja de datos útiles para obtener una visión objetiva de eso siempre escurridizo "panorama general".

Es una posición desagradecida y probablemente por qué se evita tanto. Sé que hice bien mi trabajo cuando nadie notó ese proceso, cuando nadie pensó en la tubería de construcción. Entonces, sí, una máquina bien engrasada se da por sentado rápidamente. Pero sabía que, de hecho, medí, el impacto multiplicativo que este trabajo puede tener en la productividad de un equipo y vale la pena la inversión.

Entonces, sí, creo que ese papel todavía está muy vivo hoy, aunque es cierto que evolucionó de lo que era en ese entonces.

Newtopian
fuente