lunes, 12 de agosto de 2013

El Mítico Hombre-Mes (The Mythical Man-Month) capítulo 3 en español

Hola a todos!
He terminado la traducción del Capítulo 3 del libro The Mythical Man-Month: Essays on Software Engineering.
En este capítulo Brooks explica un estilo de organizar un equipo de desarrollo de software en base un equipo quirúrgico (cuya idea inicial fue de Harlan Mills), donde todos tienen roles bien diferenciados.

¿Será aplicable en la actualidad este modelo? Yo creo que sí, adaptado ciertos roles gracias a las nuevas tecnologías existentes hoy.

Como dice Luigi del videojuego, "Here we go!":

The Mythical Man-Month : Essays on Software Engineering.
Capítulo 3: El equipo de cirugía

Figura 3.1.
Estudios revelan grandes diferencias individuales de desempeño, a menudo relacionado por el grado de importancia de lo que se realiza.
SACKMAN, ERIKSON Y GRANT

En los debates o foros de computación se ve muchas veces a jóvenes jefes o líderes de proyectos que dicen estar a favor de un equipo fuerte y reducido, pero de un nivel de primera clase, en vez de tener un equipo con cientos de desarrolladores pero de un nivel medio-bajo. Así lo creen muchos. 

Pero esta ingenua afirmación no resuelve la difícil pregunta: ¿cómo construir grandes sistemas informáticos que tienen una planificación muy larga? Echemos un vistazo más detallado de este problema.

El problema


Los gerentes informáticos o los Jefes de Proyecto (JP) desde hace tiempo han reconocido la diferencia de productividad entre los buenos y malos desarrolladores. Pero si se llega a medir dicha diferencia, el resultado nos sorprendería a todos. En uno de estos estudios, los autores Sackman, Erikson y Grant midieron el desempeño de un grupo de desarrolladores experimentados. En tan sólo este grupo, la relación entre los mejores y peores desempeños fue de 10:1 en una medición de la productividad, ¡y de un increíble 05:01 en velocidad de programación! En resumen los 20,000 dólares / año de un programador experimentado (Nota del traductor: en la época sería algo como 1.2 millones en pesos chilenos mensuales) puede ser hasta 10 veces más productivo que un programador de 10,000 dólares al año. Además, los datos no mostraron correlación alguna entre la experiencia y el rendimiento (dudo que eso es una verdad universal).

He sostenido anteriormente que la coordinación de un gran número de mentes tiene un gran costo en esfuerzo y una parte importante de ese costo es la comunicación, esto a la vez tiene un costo en la corrección de los efectos nocivos por la falta de comunicación (y hay que modificar o depurar algo). Esto también nos lleva a pensar que el sistema debería ser construido por el menor número de mentes posible. Por ejemplo, se tiene la experiencia del desarrollo de algunos grandes sistemas donde se usa una gran fuerza bruta, por lo tanto, son lentos de construir, ineficientes y con subsistemas que no están integrados conceptualmente. Por ejemplo tenemos el OS/360, Exec 8, Alcance 6600, Multics, TSS, SAGE, etc, y la lista sigue y sigue.

Entonces uno podría lanzar ideas: si un proyecto es de 200 hombres y de ellos hay 25 líderes o jefes de proyectos que son los analistas desarrolladores más competentes y experimentados, lo mejor sería despedir al resto, los 175 desarrolladores, y poner sólo a los jefes y líderes desarrollar. Otra idea sería tomando en cuenta lo se dijo al inicio, es decir, de tener sólo un equipo pequeño pero fuerte, que por consenso no excede las 10 personas. 

Si tomamos la idea de tener 200 personas, es tanta gente que tendrá que ser necesario tener dos niveles de administración, y cerca de cinco directores o jefes. Además se necesita el apoyo en finanzas, personal administrativo, espacio, secretarias y operadores. Por otro lado, este equipo de 200 hombres en verdad no es lo suficientemente grande para construir un sistema "muy grande" por el método de fuerza bruta. Considere por ejemplo la posibilidad del desarrollo de un OS/360 (Nota del traductor: Sistema Operativo de IBM hecho entre 1962 y 1972) que en su mejor momento trabajaban más de 1000 personas, entre ellos desarrolladores, escritores, operadores, oficinistas, secretarias, ejecutivos, soporte, etc. De 1963 a 1966 probablemente trabajaron en esta empresa 5000 años/hombre en etapas de diseño, construcción y documentación. ¡Si los hombres y meses fueran uniformes, nuestro equipo de 200 hombres habría tardado 25 años y no 10 en llevar el producto a su presente estado! 

En conclusión, este es el problema con un equipo pequeño pero fuerte: es demasiado lento para desarrollar sistemas grandes. Consideremos de nuevo el caso de OS/360, y veamos la opción de abordarlo con un equipo más pequeño pero muy agudo técnicamente. Para esto consideremos lo que dijimos antes, de dejar como consenso que un equipo pequeño es de 10 hombres. Según las estadísticas, a lo más estos serán 7 veces más productivos que un equipo de desarrolladores de nivel medio-bajo tanto en codificación como en documentación. Supongamos además, que el OS/360 se construye sólo por desarrolladores de nivel promedio (cosa que está "lejos" de ser verdad). Como dato aparte, hay una mejora de la productividad al menos en 7 veces debido a la baja comunicación que se requiere por parte de este equipo reducido.
Ahora supongamos que el mismo único equipo está trabajando todo el tiempo del proyecto, esto sería: 5000 / (10x7x7) = 10 años aproximadamente, entonces el trabajo 5000 años/hombres se hará en 10 años.

La consulta que se genera ahora es: ¿el producto será interesante 10 años después de su diseño inicial? ¿O ha quedado obsoleto debido al rápido desarrollo de nuevas tecnologías de software?

El dilema es algo cruel. Para sistemas medianos o chicos, uno debería preferir pocas pero buenas mentes para obtener una eficiencia y una integridad conceptual. Sin embargo, en sistemas grandes uno requiere saber manejar una considerable mano de obra, para que el producto de software tenga una fecha de finalización acorde. ¿Cómo se pueden conciliar estas dos necesidades?

Propuesta de Mills


Una propuesta de Harlan Mills ofrece una solución fresca y creativa. Mills propone que cada segmento de un gran trabajo debe ser abordado por un equipo, pero que el equipo se organizará como un equipo quirúrgico en lugar de un equipo estilo "matanza de cerdo". Es decir, en lugar de que cada miembro haga cortes sobre el problema, uno sólo hace el corte y los demás le dan todo el soporte posible, lo que mejorará la eficiencia y productividad de toda la actividad.

Este mismo concepto se puede encontrar en el poema Desiderata si lo aplicáramos en el trabajo. Pocas mentes están involucrados en el diseño y la construcción, sin embargo, muchos "meten mano", ¿funcionará? ¿Quiénes son los anestesiólogos y enfermeros en un equipo de desarrollo y cómo se divide el trabajo? Permítanme libremente mezclar metáforas para sugerir cómo un equipo puede funcionar de esta forma aplicando un sistema de soporte o colaboraciones.

El cirujano. Mills le llama programador jefe. Él (el Cirujano), personalmente define las especificaciones funcionales y de desempeño, los diseños del programa, códigos, tests y escribe la documentación. Programa en un lenguaje de programación estructurado como PL/I (Nota del traductor: parecido a Pascal, no quedaba de otra, en la epoca no habían lenguajes como C# o Java que son orientados a objetos), y accede a algún sistema de computación donde ejecuta sus pruebas, pero también almacena las diferentes versiones de sus programas, actualiza sus archivos y documenta. Debe tener un gran talento, de unos diez años de experiencia desarrollando sistemas importantes y con muchos conocimientos de aplicaciones, matemáticas, negocios, etc.

El asistente o copiloto. Él es el alter ego del cirujano, capaz de hacer cualquier parte del trabajo, pero tiene menos experiencia. Su principal función es participar en el diseño con puntos de vista críticos y visión de evaluador. El cirujano discute las ideas con él, pero no está obligado a aceptar sus consejo a ojos cerrados. El asistente a menudo representa a su equipo en los debates sobre la función y la conexión con otros equipos. Lo sabe todo acerco del código. Investiga el diseño de estrategias alternativas. Obviamente, él sirve también como una especie de seguro contra desastres para el cirujano. Incluso puede escribir código, pero la responsabilidad final de las líneas escritas no recae en él.

El administrador. El cirujano es el jefe pero también debe ver todo lo referente al personal, aumentos, manejo de espacio, etc., por lo que no le alcanza el tiempo para estos en estos asuntos. Así que necesita un administrador profesional que maneje el dinero, la gente, el espacio, y las máquinas, pero a la vez, que interactúe con toda el resto de la organización. F. Terry Baker, sugiere que el administrador debe tener un trabajo a tiempo completo solamente si el proyecto es de importancia legal, contractual, de informes o requerimientos financieros debido a una relación productor-comprador. Por otra parte, un administrador puede apoyar a un máximo de dos equipos.

El editor. El cirujano es responsable de generar la documentación para obtener la máxima claridad en el diseño y desarrollo. Este es tanto para los casos de descripciones externas como internas. El editor, sin embargo, toma la documentación generada por el cirujano, la critica, la hace un reworks (retrabajo), le proporciona referencias y bibliografía en la medida de los posible, la agranda por medio de versiones y supervisa la mecánica de la documentación.

Dos secretarios. El administrador y el editor tendrán cada uno, un secretario, estos se encargarán de la correspondencia del proyecto y archivos que no sean el producto mismo. (Nota del traductor: hay que ponerse en contexto de que en el año 1972 cuando se estableció este sistema de manejo de equipos no se usaban los correos electrónicos como hoy en día).

Un recepcionista. Él es responsable de mantener todos la registros técnicos que genere el equipo, en un archivo tipo librería de software. El recepcionista se entrenó como secretario y tiene por lo tanto archivos legibles tanto por un computador como por humanos. Todo lo que sea una entrada al sistema pasa por el recepcionista, quien deja registro de los puntos claves si son necesarios. Los aspectos de salida pasan igual por él para ser archivados y ordenados. En la actualidad, esta información de las ejecuciones y estados se mantienen en un notebook, antes se guardaban en un archivos físicos.

Es absolutamente vital para el concepto de Mills lo que él llama la transformación de la programación de un arte privado a una práctica pública haciendo que el equipo funcione visiblemente para todos los miembros del equipo y la identificación de todos programas y datos sean propiedad de todo el equipo, no una propiedad privada.

La función especial del recepcionista es liberar a los programadores de las tareas administrativas, sistematizar y asegurar un rendimiento adecuado de esas tareas a menudo olvidadas y aumentar el activo más valioso: el producto que se genera. Es evidente que estas tareas se deben realizar de manera secuencial. Cuando se utilizan elementos de interacción, especialmente aquellos que requieren una copia impresa, las funciones del recepcionista no disminuyen, sino que cambian. Él registra todas las copias privadas de cada actualización que tenga algún miembro del equipo y utiliza su propia herramienta para el control de la integridad y la disponibilidad del producto.

El toolsmith (Nota del traductor: es como un experto en herramientas de apoyo). Para que funcione este modelo, debe existir un conjunto de servicios de edición de archivos, textos y de depuración, por lo que un equipo rara vez tendrá que usar su propia máquina para esto. Sin embargo, estos servicios deben estar disponibles con una alta capacidad de respuesta y fiabilidad, y el cirujano debe ser el único que puede de adecuar estos servicios a su disposición. Por lo tanto aquí nace la figura de un toolsmith que trabaja para el cirujano. Este personaje que es responsable de garantizar la idoneidad de estos servicios básicos y que a la vez debe construir, mantener y actualizar sus propias herramientas - sobretodo servicios informáticos interactivos - que necesitará el equipo. Cada equipo tendrá su propio toolsmith, independientemente si hay un servicio común central, su trabajo es tener disponibles las herramientas necesarias o buscadas por su cirujano, por sobre lo que se solicite desde algún otro equipo. Este especialista a menudo debe construir servicios especializados, procedimientos catalogados o macros.

El tester. El cirujano necesita un banco de casos de prueba adecuados para probar tonta piezas particulares que desarrolle como para una prueba completa del sistema o módulo. Por lo tanto, el tester es al mismo tiempo un adversario que elabora los casos de prueba para especificaciones funcionales como también pruebas que sirven para depurar la aplicación en el día a día. También planea secuencias de prueba y establece el andamiaje necesario para pruebas de componentes.

Experto en el lenguaje. En el momento que llegó el lenguaje de programación Algol, la gente comenzó a reconocer que existían ciertas personas que se deleitaban en el dominio de la complejidad de un lenguaje de programación, y estos expertos resultaban ser muy útiles y ampliamente consultados. El talento aquí es bastante diferente al de un cirujano, que es principalmente un diseñador del sistema y que piensa en aspectos funcionales. El experto en el lenguaje conoce varias de manejar el lenguaje de forma ordenada y eficiente para sacar adelante cosas difíciles, oscuras o realizar ciertos trucos. A menudo tendrá que hacer breves investigaciones de buenas prácticas (de dos o tres días). Un experto en lenguaje puede ayudar a un máximo de dos o tres cirujanos. 

Entonces esto responde a la pregunta de cómo las 10 personas podrían contribuir en un sistema de roles bien diferenciado, donde el equipo de programación esté basado en el modelo quirúrgico.

¿Cómo funciona?


El equipo que se acaba de definir coincide con el poema Desiderata en varios puntos. Diez personas, siete de los cuales son profesionales, están trabajando en el problema, pero el sistema es el producto de una mente o dos como mucho pero que actúan como uno animo. (Nota del traductor: no encontré el significado, pero debe ser algo como una "una unidad").
Tenga en cuenta, en particular, las diferencias entre un equipo típico de dos programadores y un equipo del tipo cirujano-copiloto. En primer tipo, en el equipo convencional, los programadores dividen el trabajo y cada uno es responsable del diseño y ejecución de su parte del trabajo. En el equipo quirúrgico, el cirujano y el copiloto son cada uno consciente de todo el diseño y de todo el código. Esto evita problemas tanto logísticos como la asignación de espacios, accesos al disco, etc., como también asegura la integridad conceptual de la obra.

En segundo lugar, en el equipo convencional los programadores son iguales y las inevitables diferencias de juicio deben ser habladas o se verán comprometidas.
Dado que el trabajo y los recursos se dividen, las diferencias en el juicio se limitan a la estrategia global y la interconexión, pero agravadas por las diferencias de intereses, por ejemplo, cuanto buffer se usará en una variable. (Nota del traductor: actualmente sería análogo a definir el largo de una variable en un mapeo de Hibernate o un SP de SQL).
En el equipo quirúrgico, no hay diferencias de intereses, ya que estas diferencias de criterio se resuelven por el cirujano de forma unilateral. Estas dos diferencias: la falta de división del problema y la relación superior-subordinado, hacen que sea posible que el equipo quirúrgico actúe como uno animo.
Sin embargo, la especialización de la función del resto del equipo es la clave de su eficacia, ya que permite un patrón de comunicación radicalmente más simple entre los miembros, que se ve en la figura 3.1.

Fin del capítulo 3.

Bueno, esta fue la traducción, aparte encontré estos interesantes enlaces que apoyan la lectura:


11 comentarios:

  1. Muchas gracias por darte la tarea de traducir cada capítulo :)

    ResponderEliminar
  2. Me parece un gran trabajo. Espero poder leer más capítulos. Gracias!!!

    ResponderEliminar
  3. De nada amigo! Ya estoy trabajando en el capítulo 4to.

    ResponderEliminar
  4. Estoy de vacaciones, así que dentro del mes intentaré subirlo.

    ResponderEliminar
  5. Que onda amigo, muy buen aporte tus tres capítulos...
    Esperemos salgan más capítulos.
    Gracias

    ResponderEliminar
  6. Gracias por transferir conocimiento de alta ingenieria a quienes no dominamos el idioma Ingles.

    Germán Pinzón Galvis
    Bucaramanga - Colombia
    Abril de 2016

    ResponderEliminar
  7. es una lastima que jamas subio las otras partes del libro

    ResponderEliminar
    Respuestas
    1. lo tengo en carpeta, he estado ocupado pero voy a traducirlo pronto :)

      Eliminar