¿Qué metodología es la más cercana al Equipo Quirúrgico en The Mythical Man-Month?

Question

El Mythical Man-Month es ahora clásico, pero la metodología del "Equipo Quirúrgico" sigue siendo interesante. ¿Qué metodología se parece más a ella o tiene la misma esencia?

Para resumir la analogía del equipo quirúrgico: Un cirujano entiende el problema/dominio comercial y es el experto. Ellos son la autoridad cuando hay preguntas o conflictos en el equipo. Los cirujanos trabajan entre ellos cuando hay problemas, por ejemplo, con el diseño, que funcionan como un pequeño y apretado equipo de expertos. Entonces, en esencia, ellos tienen el conocimiento del dominio, están confiados a lo que piensan que es correcto, y ¿hacen la codificación real? El resto del equipo se centra en el soporte, las pruebas, la documentación y los planes de proyectos son tareas delegadas. En consecuencia, el cirujano es también el recurso más capacitado/capacitado.

La respuesta podría ser proyectos, programación, metodologías de diseño, ya que parece tener implicaciones en los principales dominios de la metodología. Agile, MDA, Extreme, en el desarrollo de abastecimiento? Esta pregunta también tiene más sentido para el software que es grande en un dominio comercial complejo, piense en el control de tráfico aéreo, no en un desarrollador de COTS o en una utilidad común.

Answer 1

Uno de los patrones mencionados en Organizational Patterns of Agile Software Development se titula "Tres a siete ayudantes por rol"; difiere del equipo quirúrgico en que presta atención a cada rol, por ejemplo, no es solo que el rol del cirujano tenga ayudantes o relaciones: todos los roles tienen alguna relación.

Otro patrón de la misma fuente en el nombre "Architect Also Implements", que puede ser análogo al "Equipo quirúrgico" en el que el Arquitecto en particular es (presumiblemente) altamente calificado.

Answer 2

No estoy seguro de que ninguna metodología realmente aborde eso, ya que es una cuestión de priorizar a los desarrolladores y doblar todo a sus necesidades, más que nada acerca de cómo esos desarrolladores realmente desarrollan su software.

Si estaba buscando alguna metodología que impida esto, supongo que esto puede ser una mala noticia. Prefiero considerarlo buenas noticias, ya que significa que puede utilizar este enfoque con casi cualquier metodología de desarrollo de software.

He trabajado en exactamente un proyecto que se ejecutó de esa manera. Fue muy divertido, casi me siento mal llamarlo "trabajo". Cuatro de nosotros, los desarrolladores (con personal de apoyo adicional, incluido el mono de códigos extra junior ocasional) obtuvimos una cantidad verdaderamente prodigiosa de código escrito y funcionando correctamente en solo 9 meses. Otros lugares en los que he estado no podrían haber hecho tanto con un equipo de 20.

Answer 3

En el caso de un cirujano, el actor clave es tanto el experto en el dominio como el implementador.

Es decir, es tanto el administrador del programa de software (arquitecto) como el desarrollador.

Este tipo de metodología podría adaptarse a ciertas situaciones de corto consumo: por ejemplo, una operación compleja como una migración de servidor en vivo o actualización de software.

Para el desarrollo general, sin embargo, hay algunos problemas con este tipo de metodologías "héroe":

• pocos desarrolladores clave comprendan el dominio del problema en un grado suficiente, y deben confiar en los expertos de dominio.Esto es simplemente una función de la especialización: es difícil encontrar programadores de kick-butt que también sean abogados, médicos, contadores o expertos en el dominio que modela el software.

• La escalabilidad está limitada por la cantidad de "cirujanos" que tiene disponibles.

• Hay mucho tiempo de inactividad para el resto del personal mientras esperan instrucciones, ya que el "ejecutor" altamente enfocado también está administrando el equipo. Está bien en el quirófano, ya que se trata de un mandato de "error cero" y de "software en vivo". Pero en esta economía, una carga de trabajo más distribuida es más eficiente, incluso si ocasiona un problema de sincronización ocasional entre los miembros del equipo.

Answer 4

A partir del texto que veo lo siguiente:

ágil igual:

• Los equipos pequeños enfocados a la resolución de problemas específicos
• colaboración entre los surgeions

para no ágil Me gusta:

• Los cirujanos son la autoridad que impulsa el plan, determina el diseño, asigna las tareas de soporte (las visualiza como subordinadas a la codificación) y realiza la codificación. Todos ellos son muy comandantes y de control en el enfoque y contrario a los equipos de autodirección (frente a un equipo dirigido)
• Parece no haber colaboración con el socio comercial (ni hablar de la colaboración frecuente con el socio comercial)
• Parece que no hay pila de producto priorizado, por tanto, el cirujano recoge lo que es importante no es el socio de negocios
• no parece haber ninguna entrega incrmental (apretado bucle de retroalimentación)

para un proyecto de cascada, se sugiere utilizar una equipo de expertos (cirujanos) para planificar, diseñar, codificar, etc. y asignar tareas al "apoyo" t "personal". En un equipo ágil, las pruebas no se tratan como soporte, sino como parte integral de la entrega.

No se puede afirmar con certeza la metodología que se defiende. Sin embargo, parece utilizar el lenguaje (planes de proyecto, tareas) y asumir que se sigue el enfoque de cascada (fases como el diseño, la codificación y las pruebas impulsadas por un plan). Cualquiera que sea la metodología que se use, es una para la cual unos pocos determinan el trabajo para muchos.