project management - steps - ¿Cuánto del mes Mythical Man todavía se aplica?
project management steps (15)
Este libro fue escrito en la era de los sistemas para compartir el tiempo, la programación de procedimientos y aproximadamente 30 años menos en la experiencia de ingeniería de software. Con la mejora de cosas como las bibliotecas existentes, los idiomas de nivel superior, IDES y la cantidad de documentación y ejemplos disponibles en Internet, ¿cuánto del libro sigue siendo cierto?
Aunque puedo creer que agregar nuevas personas a un proyecto puede ralentizarlo inicialmente, creo que cosas como la prueba unitaria, la separación de preocupaciones y otras formas de automatización y mejoras de diseño permitirían a los nuevos miembros de un equipo volverse productivos más rápido de lo que se suponía en el libro, suponiendo que el proyecto tenía una buena documentación de diseño y procesos en su lugar.
No tengo experiencia en proyectos grandes o con equipos grandes, por lo que estoy interesado en saber qué piensan aquellos de ustedes que tienen experiencias con ellos. editar: Me preguntaba si las nuevas herramientas de comunicación como Wikis, mensajería instantánea e Internet en general disminuían el tiempo dedicado a la comunicación. Con base en las respuestas de everyones, diría que cualquier aumento en la eficiencia de las comunicaciones se ha visto compensado por una mayor complejidad.
¿No es como preguntar si el Arte de la Guerra de Sun Tzu todavía es aplicable a la guerra ya que tenemos equipos modernos?
Ciertamente creo que cosas como "No Silver Bullet" son tan aplicables hoy como lo eran hace décadas, especialmente a medida que vemos que más y más jóvenes entran a la industria y piensan que x es la última y más grande lengua / tecnología asesina y todas las demás tecnologías morirá por eso.
De acuerdo, las referencias a Ada o compartir computadoras son anticuadas, pero el concepto de dificultades accidentales y esenciales, compra contra construcción, cómo el código es complejo por definición, porque no repetimos partes, y todos los otros temas teóricos todavía son completamente precisos y relevante.
El otro argumento de por qué TMMM es relevante es que, en realidad, no se trata de software en sí, sino de cómo los programadores hacen las cosas. De esta manera, es difícil que se vuelva obsoleta.
Considero que este es uno de los libros de "lectura obligatoria" para cualquiera que desee comprender el proceso de desarrollo de software.
El Mes del Hombre Mítico es una lectura muy anticuada, pero las verdades centrales todavía se aplican. Sure Brooks habla sobre la necesidad de una secretaria que claramente no es cierta hoy en día y su concepto de un equipo quirúrgico no funciona bien, pero la mayor parte del libro sigue siendo precisa. Su idea de que los requisitos de comunicación aumentan junto con el tamaño del equipo sigue siendo cierto. Su observación de que agregar personas a un proyecto tardío lo hace más tarde ha surgido de muchos proyectos. Las pruebas unitarias ayudan un poco, pero no impiden que uno malinterprete el código o haga muchas preguntas. Sin Silver Bullet también sigue resistiendo el paso del tiempo.
El libro todavía tiene cosas que contarnos, y por mi parte, he experimentado los problemas de comunicación que conlleva el aumento del tamaño del equipo. Debe tener en cuenta que las pruebas unitarias, la separación de preocupaciones, etc. no son conceptos nuevos.
Sin embargo, algunas cosas no han resistido la prueba del tiempo. No creo que escribir diagramas de flujo ASCII en su código sea una buena idea, y el enfoque del "equipo quirúrgico" sugerido ha sido probado por varias personas (Charles Simony en MS, el más famoso) y no funcionó muy bien.
La demanda de personal de desarrollo ha crecido rápidamente durante los últimos 40 años, y esta necesidad no se detendrá. Dado que la tasa de gente inteligente (ver Joel "inteligente y hacer las cosas") en la población sigue siendo la misma, educar a más y más desarrolladores cada año significa que la inteligencia promedio de un desarrollador es cada vez menor.
Hace 40 años, los semidioses se convirtieron en desarrolladores; Hace 20 años, era un trabajo para personas inteligentes, mientras que ahora, cuando miro a los jóvenes estudiantes de CS en mi Alma Mater, parece que se están llevando a todos los que saben lo que es una computadora.
Esto no significa que se avecina un desastre: el mundo occidental sigue importando gente inteligente (o tercerizando el trabajo) de mercados emergentes o países del tercer mundo. Las nuevas herramientas de desarrollo facilitan el desarrollo de buenas aplicaciones. Esos factores parecen neutralizarse mutuamente, haciendo que MM-M sea eterno.
La idea no es que "los equipos grandes no funcionen", es que "echarle gente / dinero al problema no es la respuesta". Cosas como pruebas unitarias, separación de preocupaciones, etc. están haciendo otras cosas en lugar de solo echar a las personas al problema. Estas otras cosas le permiten agregar cuidadosamente a más personas en el lugar correcto para acelerar las cosas. En todo caso, los puntos que haces respaldan las ideas del libro.
Lea TMM como un libro que describe un problema, quizás EL problema, en la ingeniería de software: ¡no es la tecnología, es la gente! Todas las mejoras que mencionas provienen de esa realización central. Están todos en su lugar para resolver los problemas que Brooks planteó. Este es el libro que estoy seguro de que Kent Beck y Ward Cunningham y Alister Cockburn y Martin Fowler leyeron, tomaron en serio y luego comenzaron a elaborar sus balas de plata.
Los dos famosos escritos de Brooks, "No Silver Bullet" y "The Mythical Man-Month" son explicaciones de las limitaciones fundamentales, en los lenguajes de programación y la gestión de proyectos, respectivamente.
Si bien es cierto que algunos de los capítulos un poco más allá de la mitad de TMMM tratan demasiado con la tecnología de la época, los capítulos restantes siguen siendo tan relevantes hoy como lo fueron cuando se escribieron.
En TMMM, Brooks sigue una técnica de "delinear el problema", "mostrar algunos comienzos en falso" y "proponer mi propia solución". Algunos comentaristas anteriores han señalado que sus propias soluciones pueden considerarse obsoletas en este momento, pero su descripción concisa de los problemas inherentes a los grandes proyectos hace que valga la pena leer el libro.
Uno de los temas que sigue volviendo es la sobrecarga de las comunicaciones como un factor limitante para los equipos grandes. Como experimento de pensamiento, considere el efecto de Internet como un medio de comunicación para programadores y el catalizador que ha sido para grandes proyectos de código abierto.
Personalmente, leería el libro solo para la sección "Las alegrías del arte". Nunca he leído nada que describa tan elegantemente qué programación se siente mejor. (Si tiene curiosidad, está en la página 7 y se puede ver en la función "¡Mira dentro!" De amazon.com)
Los dos que me vienen a la mente son: "la versión 2" todavía se aplica y también "agregar más personas no necesariamente más rápido".
Spolsky discute la "versión 2" a su manera. No recuerdo si él específicamente vincula a MMM pero es muy similar en concepto.
La comunicación se ha vuelto mucho más eficiente que cuando se identificó MMM, sin embargo, creo que es todo proporcional. Se necesita mucho más para preparar la producción de software que cuando se escribió MMM.
Alguien dijo que todo en informática se descubrió en 1960 y desde entonces todo ha sido derivado.
Los factores sociales todavía están presentes, porque los humanos somos esencialmente las mismas bestias que éramos hace 50 años.
Los ejemplos técnicos son casi completamente obsoletos, y solo tienen sentido cuando piensas en el sistema 0.034 MIPS / 360 de 1964. Cuando solo tienes 8 KB de memoria, lo que sugiere que el usuario debe ser responsable de manejar los años bisiestos, en lugar de desperdiciar 26 bytes de memoria del sistema (como Brooks lo hizo) tiene sentido, pero hoy parece francamente tonto. No conozco ningún sistema tan pequeño hoy en día: su teléfono es miles de veces más potente que el sistema OS / 360 más potente. Hoy sabemos mucho más sobre la usabilidad y la interacción humano-computadora, y hacer que el usuario sea responsable de esa categoría de cosas es una locura.
Si piensas en un proyecto grande que es tarde, entonces es más probable que esté en modo crisis / pánico, ya que con la mayoría de las cosas en este modo, la mejor respuesta es un plan medio decente, simplemente tirar más recursos en una crisis no resuelve cualquier cosa que no sea un desperdicio de recursos y comprenda el problema.
No hay sustituto para la programación (planificación) y la gestión decente.
Al igual que con la mayoría de estas "frases únicas" o "reglas de oro", considérelas como más pautas (con contexto) que en piedra.
Todavía es tan cierto hoy como el día en que fue escrito. Esto se debe a que se trata fundamentalmente de la comunicación entre las personas que trabajan en el mismo proyecto, y ninguno de los avances de los últimos 30 años ha cambiado sustancialmente eso.
Por supuesto, hemos aprendido mucho en esos 30 años, pero todas las mejoras en nuestras herramientas y nuestra comprensión han sido incrementales, de acuerdo con la predicción de Brooks "sin balas de plata".
Todo ello. El simple hecho es que los proyectos de software no son triviales; construimos nuestro propio conocimiento de dominio, realmente, directamente en nuestras soluciones. La transferencia de conocimiento del dominio es costosa, tanto para el transferidor como para el receptor de la transferencia; esto no ha cambiado Y yo, por mi parte, creo que nunca lo hará, no importa cuáles sean las prácticas y herramientas utilizadas. Las cosas pueden mejorar marginalmente, pero el simple hecho es que la enseñanza y el aprendizaje son cosas costosas y difíciles, y simplemente no hay forma de evitarlas.
Un programador ahora puede escribir más código / construir más software de lo que un programador podría en aquel entonces, pero agregar el segundo desarrollador no va a producir el doble.
Si / cuando entro en un proyecto con una buena documentación de diseño y procesos implementados, le informaré si eso mejora algo.