¿Qué metodología se acerca más al equipo quirúrgico en el mes laboral mítico? [cerrado]

Question

El mes laboral mítico es ahora clásico, pero la metodología "Equipo quirúrgico" sigue siendo interesante. ¿Qué metodología se asemeja más se le parezcan o tiene la misma esencia?

Para resumir la analogía del equipo quirúrgico: Un cirujano entiende el dominio del problema / negocio y es el experto. Ellos son la autoridad cuando hay dudas o conflictos con en el equipo. Los cirujanos trabajan entre ellos cuando hay problemas, dicen con el diseño, que funciona como un equipo más pequeño apretado de expertos. Así que en esencia tienen el conocimiento del dominio, se confían a hacer que creen que es correcto, y hacer la codificación real? El resto del equipo se centra en el apoyo, pruebas, documentación, y los planes del proyecto se delegan tareas. En consecuencia, el cirujano también es el recurso más especializada y / entrenado.

La respuesta podría ser proyecto, programación, metodologías de diseño, ya que parece tener implicaciones a través de los principales dominios de metodología. Ágil, MDA, Detalle, en la obtención de desarrollo? Esta pregunta también tiene más sentido para el software que es grande en un dominio de negocio complejas, piense control, no un desarrollador COTS tráfico aéreo o utilidad común.

Answer 1

Uno de los patrones mencionados en patrones de organización del desarrollo ágil de software se titula "de tres a siete ayudantes por Papel"; se diferencia del equipo quirúrgico en el que se presta atención a cada función, por ejemplo, no es sólo que el cirujano 'papel' que tiene ayudantes o relaciones:. todos papeles tienen algún número de relaciones

Otro patrón de la misma fuente en el nombre "Architect también implementa", que puede ser análogo a "Equipo quirúrgico" en que el Arquitecto en particular es (presumiblemente) altamente cualificado.

Answer 2

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

es decir., Que es a la vez el director del programa de software (arquitecto) y el desarrollador.

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

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 -. Que es difícil de encontrar programadores de lanzamiento a tope que también son abogados, médicos, contadores, o de otra manera son expertos en el dominio del software es el modelado

• La escalabilidad está limitada por el número de "cirujanos" que tiene disponible.

• Hay una gran cantidad de tiempo de inactividad para el resto del personal mientras esperan instrucciones, ya que el altamente concentrado "hacedor" también está gestionando el equipo. Eso está bien en el quirófano, ya que está tratando con un mandato "cero error" y "software vivo." Pero en esta economía, una carga de trabajo más distribuida es más eficiente, incluso si resulta en el problema de sincronización ocasional entre los miembros del equipo.

Answer 3

No estoy seguro de cualquier metodología realmente se ocupa de eso, ya que es realmente una cuestión de dar prioridad a los desarrolladores y doblar todo a sus necesidades, en lugar de que ser nada acerca de cómo los desarrolladores realmente desarrollan su software.

Si estaba buscando un poco de metodologia que impements esto, supongo que esto puede ser una mala noticia. Yo prefiero considerarlo buena noticia , 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 ejecuta de esa manera. Era tan agradable, casi me siento mal que calificó de "trabajo". Cuatro de nosotros (los desarrolladores con personell de apoyo adicionales, incluyendo el ocasional mono código secundaria adicional) consiguieron una cantidad verdaderamente prodigiosa del código escrito y ponerse en funcionamiento en sólo 9 meses. Otros lugares que he estado no podría haber hecho lo mismo con un equipo de 20.

Answer 4

A partir del texto que veo lo siguiente:

Al igual ágil:

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

No ágil como:

• Los cirujanos son la autoridad, conducción del plan, determinar el diseño, la asignación de tareas de apoyo (viewng como subservent de codificación) y hacer la codificación. Todos estos son muy comando y control en el enfoque y contrario a dirigir equipos auto (vs un equipo dirigido)
• No parece haber ninguna colaboración con el socio de negocios (dejar solos colaboración frecuente con el socio busines)
• No parece haber ninguna 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 (bucle de realimentación ajustado)

Para un proyecto de cascada, se sugiere utilizar un equipo de expertos (cirujanos) para hacer la planificación, diseño, codificación, etc., y la asignación de tareas para el "apoyo" personal. En un equipo ágil, las pruebas no se trata como apoyo, pero una parte integral de la entrega.

No se puede decir con certeza la metodología preconizada. Sin embargo, parece utilizar la lengua (planes de proyectos, tareas) y asumir que se está siguiendo el enfoque en cascada (fases como el diseño, codificación, pruebas impulsado por un plan). Sea cual sea la metodología se está utilizando, es aquel para el cual los pocos determinar el trabajo para la mayoría.