Biblia de la ingeniería blanda: "El mes del hombre mítico"

Fred Brooks fue uno de los primeros en el mundo en recibir un doctorado en informática, ganó el premio más importante en el campo de la informática: el "Premio Turing" en 1999 y también ganó el Premio Nacional de Tecnología en 1985. Ha trabajado para la Agencia Nacional de Ciencia y Tecnología de Estados Unidos y el Consejo de Ciencia y Tecnología de Defensa.

Por casualidad, vi el libro "The Mythical Man-Month", que analiza principalmente algunos conceptos básicos de la ingeniería de software, como la gestión de proyectos, la complejidad del software, el trabajo en equipo y la planificación del cronograma. Este libro presenta muchos principios clásicos de desarrollo de software, algunos de los cuales son famosos como "No Silver Bullet" y "Surgical Operation Team" y se han denominado clásicos hasta ahora. Posteriormente, compiló los artículos y publicó estos clásicos del "Mythical Man-Month".

fondo

A finales de 1961, IBM planeó implementar un gran proyecto llamado "Proyecto de computadora electrónica del sistema 360", que requirió una inversión de alrededor de 5 mil millones de dólares estadounidenses. Sin embargo, este proyecto enfrentó mayores desafíos, principalmente centrados en el lado del software. El objetivo de IBM era garantizar que todo el software se ejecutara en sus computadoras de la serie 360, una filosofía que causó gran confusión entre los ingenieros de software.

Para lograr este objetivo, IBM tuvo que invertir muchos recursos, que excedieron el costo de la investigación y el desarrollo de hardware. Más de 2.000 ingenieros de software trabajaron en el proyecto y gastaron más de 500 millones de dólares en financiación, una cifra sin precedentes. La parte de software del proyecto resultó ser un gran desafío, pero el firme compromiso de IBM de garantizar que sus computadoras de la serie 360 ​​pudieran soportar una amplia gama de aplicaciones tuvo un profundo impacto en la industria informática en ese momento.

Al desarrollar el proyecto de computadora electrónica del sistema 360, debido a la falta de experiencia en el desarrollo de software a gran escala, el equipo de desarrollo cayó en uno de los dilemas de desarrollo de software más difíciles de la historia y, finalmente, no pudo realizar completamente la visión original.

Cuando se propuso por primera vez el plan para desarrollar este nuevo sistema operativo, Frederick Brooks (Frederick Brooks) fue uno de los más acérrimos opositores, porque creía que el proyecto era demasiado difícil para ser práctico. Al final, sin embargo, aceptó la gran tarea.

Brooks escribió más tarde un libro llamado "The Mythical Man-Month" (El mes del hombre mítico) basado en la experiencia de esta tarea de desarrollo de la Biblia". En este libro, comparte ideas y lecciones sobre el desarrollo de software, destacando los desafíos en la gestión de recursos humanos y el proceso de desarrollo de software. Este libro ha tenido un profundo impacto en la comprensión de la complejidad y los problemas de gestión en la ingeniería de software y se ha convertido en una referencia importante en el campo del desarrollo de software.

Percepción y cosecha

El desarrollo de software es un proyecto enorme y extremadamente complejo. Normalmente, trabajamos en este tipo de proyectos en equipo, ya que ayuda a mejorar la eficiencia y ahorra tiempo. Sin embargo, con el aumento de participantes en proyectos y el refinamiento de la división del trabajo, la necesidad de comunicación entre personas aumenta exponencialmente. Pronto descubrirá que el tiempo dedicado a la comunicación supera gradualmente el tiempo ahorrado por la división del trabajo. En definitiva, a medida que aumenta el número de participantes, la situación no es más favorable, sino más caótica.

Grupo Quirúrgico

Entre ellos, el autor analiza cómo formar un equipo en el tercer capítulo. Brooks compara un buen equipo de desarrollo de software con un equipo quirúrgico y define el papel de cada miembro del equipo de desarrollo en consecuencia. En un equipo existen múltiples roles:

• El papel del programador jefe se puede comparar con el de un cirujano: es personalmente responsable de formular especificaciones técnicas funcionales y de rendimiento, programar, escribir código fuente, realizar pruebas y redactar documentación técnica.

• Los ayudantes actúan como respaldo del cirujano y pueden realizar cualquiera de sus trabajos. La función principal del diputado es proporcionar ideas de diseño, debates y evaluaciones. El teniente a menudo habla en nombre de su grupo en discusiones destacadas y de interfaz con otros equipos.

• El papel del administrador es el de un gerente profesional responsable de las finanzas, el personal, los arreglos del lugar de trabajo y el equipo. Los administradores actúan como punto de contacto con otros departamentos administrativos de la organización.

• Las responsabilidades del editor incluyen el análisis y la reorganización basándose en el borrador o la descripción oral del cirujano, proporcionando información de referencia diversa y citas bibliográficas, supervisando el proceso de generación de documentos y manteniendo múltiples versiones.

• El equipo necesita dos secretarias, una como administradora y otra como editora. La secretaria del administrador es responsable de la coordinación y coherencia del proyecto, no de la documentación del producto. La secretaria del editor asiste al editor.

• El personal del programa es responsable de mantener registros técnicos de todos los equipos en la biblioteca de productos de programación. Reciben formación de secretaría y asumen la responsabilidad administrativa de documentos codificados por máquina y legibles por humanos.

Al especializar a los programadores, los programadores pueden deshacerse del tedioso papeleo y, al mismo tiempo, pueden organizar este trabajo para garantizar la calidad y fortalecer el activo más valioso del equipo: el producto del trabajo .

ninguna bala de plata

El término "bala de plata" proviene de leyendas medievales europeas, como muchos de ustedes sabrán por la película Underworld. Se refiere a criaturas como los hombres lobo que no pueden morir con balas comunes, solo las balas de plata pueden destruirlos.

Más tarde, el término "bala de plata" se utilizó metafóricamente para describir métodos que eran particularmente efectivos y parecían resolver problemas. Posteriormente, se utilizó mucho para referirse a aquellos métodos que pueden resolver problemas rápidamente, un poco como la "medicina milagrosa" que se vende en las calles. "Medicina milagrosa" se refiere a aquellos medicamentos que pretenden curar todas las enfermedades, pero que obviamente son poco realistas y, por lo general, engañosos.

Por lo tanto, no se menciona ninguna solución milagrosa en el libro, lo que significa que la ingeniería de software es un sistema extremadamente complejo y no existe ningún método de efectos especiales que pueda mejorar la eficiencia para siempre. Lo mismo ocurre con todas las cosas complejas, ya sea iniciar un negocio, trabajar en un proyecto o criar hijos. Los problemas que enfrentamos son únicos, los recursos para resolverlos son únicos y las oportunidades son únicas.

Por lo tanto, los solucionadores de problemas realmente buenos nunca buscan una solución única, simplemente se integran en un sistema único que es bueno para definir claramente un problema y luego resolverlo de manera iterativa .

Durante este proceso, recuerde siempre que "no existe una solución milagrosa en este mundo".

Cuantificación del riesgo y valor.

Las percepciones sobre el valor de un proyecto suelen ser mucho más pobres que sus riesgos. Cuantificar el riesgo es inherentemente desafiante, y cuantificar el valor es aún más difícil. Parece que la cuantificación del valor suele dejarse en manos del cliente, como menciona el libro. A menudo nos olvidamos de cuantificar el valor por las siguientes razones: el proyecto es demasiado pequeño y no estamos seguros de cómo hacerlo; desarrollo futuro; este sistema es solo para reemplazar el sistema existente; la orden la emite el superior, solo necesitamos ejecutarlo; la incertidumbre de los beneficios es demasiado grande para que podamos estar seguros; el cliente dijo: "Créame, vale la pena realizar este proyecto"; los datos de ganancias en sí tampoco son confiables.

¡Soy profundamente consciente de que el riesgo del proyecto debe coincidir con su valor! ¡La cuantificación del valor y el riesgo debería ser igualmente importante y debería expresarse con la misma precisión! Si no se puede entender claramente el valor del proyecto, no tiene sentido centrarse simplemente en el riesgo, porque no podemos determinar si vale la pena correr tal riesgo, ¡el riesgo y el valor están interrelacionados! ¡El riesgo corresponde al valor y el valor esperado coincide con el costo esperado!

Pruebas e integración

Un diseño cuidadoso y detallado no sólo hace que un producto sea más fácil de usar, sino que también facilita el desarrollo con menos errores. Muchos casos de fallo se deben enteramente a aspectos del producto que no están definidos con precisión. Antes de escribir cualquier código, la especificación debe enviarse a un grupo de pruebas externo para examinar su integridad y claridad. Los desarrolladores no pueden hacer este trabajo solos. El diseño de arriba hacia abajo con refinamiento incremental es una de las metodologías de desarrollo de software más importantes y lo sigue siendo hoy en día, ya sea para proyectos de software grandes o pequeños. Un excelente diseño de arriba hacia abajo puede reducir los errores y el riesgo de fallas de cuatro maneras. En primer lugar, una estructura clara facilita la descripción precisa de los requisitos y la funcionalidad del módulo. En segundo lugar, la división de módulos y la independencia entre módulos pueden evitar o reducir errores a nivel del sistema. En tercer lugar, la supresión o el aplazamiento de detalles ayuda a identificar los defectos estructurales más fácilmente. En cuarto lugar, el diseño se puede probar en cada etapa, de modo que las pruebas puedan comenzar antes y la atención se pueda centrar gradualmente en diferentes niveles. El diseño de arriba hacia abajo no excluye la regresión y, si es necesario, uno debe atreverse a derrocar el diseño de nivel superior y empezar de nuevo.

En la programación estructurada, la estructura de control de un programa consta únicamente de un conjunto determinado de bloques de código rectores. Las pruebas del sistema deben comenzar después de que se hayan realizado todas las pruebas unitarias, agregando solo un componente a la vez. Es necesario y valioso construir un banco de pruebas, incluida la creación de código de prueba. Alguien tiene que ser responsable del control y la documentación de cambios y versiones. Los miembros del equipo deben trabajar con un repositorio de desarrollo controlado y la importancia de la gestión de la configuración es evidente, incluso para el desarrollo en solitario.

por fin

Muchas partes del artículo están estrechamente relacionadas con nuestros programadores. Este libro afecta no solo nuestro desarrollo diario, sino incluso nuestra vida. Es realmente inspirador.

adjunto

Si también te gusta este libro, puedes comprarlo a través del siguiente enlace.
El enlace de compra del Mes del Hombre Mítico