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

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?

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

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.

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

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

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.

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.

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.

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

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.

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

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.