¿Qué es el mito del mes del hombre?
Las personas son programadores, el mes es el momento
1 persona durante 10 meses, si equivale a 10 personas durante 1 mes
Esto se llama mito
Escribe al principio
Escuché por primera vez el título de este libro cuando escuché al profesor recomendarlo cuando estaba empezando a aprender los conceptos básicos de Java en mi primer año. En ese momento, también escuché "Pensar en Java" y "Java eficaz". En comparación con estos títulos dominantes de alta gama, "El mito de la luna" se parece más a un libro de cuentos y todavía tiene un color de fantasía. . He leído este libro hace algún tiempo recientemente, y de hecho está contando una historia. Es la historia de una experiencia fallida. No hay fantasía. A través de la experiencia fallida, reflexiono sobre varias situaciones posibles en el progreso del proyecto de software. .
Alguien comentó una vez: Este libro no le enseña qué hacer, pero le enseña lo que no debe hacer. Es básicamente una negación de un pseudo sentido común, en lugar de enseñarle cómo hacer las cosas mejor.
Desde una cara confundida sobre programación y desarrollo de software, hasta ingresar a un puesto de desarrollo después de graduarse.
Desde la perspectiva de un practicante: No es sin razón que un libro de hace 40 años todavía se esté vendiendo bien. Aunque no entiendo de qué estás hablando, parece tener sentido participar realmente en el proceso de desarrollo de software. Como implementador ejecutivo, la experiencia es obviamente diferente. Aquí, compartiré mi comprensión de los capítulos más profundos.
Mito del mes del hombre
-
La falta de un cronograma razonable es la principal razón del retraso del proyecto y tiene un impacto mayor que la suma de todos los demás factores.
¿Qué es un horario razonable? ¿Cómo definir el término "razonable"? En el entorno actual del mercado de rápido desarrollo iterativo, el tiempo es la consideración principal, dejando de lado las cuestiones centrales del proyecto, como la complejidad del sistema y las dificultades técnicas. Creo que no es razonable definir el proyecto desde la perspectiva del tiempo, creo que un buen producto requiere tiempo para moderarse, y trabajar lenta y cuidadosamente. Desde la interacción del usuario y la experiencia del usuario hasta el mantenimiento y la operación de seguimiento, la expansión y la actualización, debe pasar un producto excelente. Si el desarrollo y el uso de una sola vez, creo que el tiempo es de hecho lo más importante, creo que este tipo de situación no está dentro del alcance de la consideración del autor del libro.
La iteración de productos de software se parece más a un proceso desde el balbuceo hasta la edad adulta. El cronograma de tiempo razonable es de 18 años. De esta manera, creo que todos tenemos la respuesta en la mente de si es razonable promover el crecimiento.
-
Una buena cocción requiere tiempo y ciertas tareas no se pueden acelerar sin comprometer los resultados.
Cuando se trata de cocinar, los ingredientes necesarios para platos de alta gama son extremadamente particulares, incluida la cantidad de condimento, el control del calor y el servicio como plato. Estos platos son obras de arte cuidadosamente elaboradas por los chefs. ¿Qué pasa con la creación de obras de arte y no requiere mucho tiempo? Creo que es similar al primer punto aquí, los cuales enfatizan la influencia del tiempo en la calidad del producto.
Hablando de cocinar, aquí hay un jabón en escamas de repollo hervido, un famoso plato de banquete nacional: ¿Es este el repollo que conozco?
-
Todos los programadores son optimistas: "Todo funcionará bien".
En este punto, creo que tengo algo que decir. Como desarrollador, debo tener confianza. El código que escribí está libre de errores. Si no me cree, haga clic en él nuevamente. Eh, ¿por qué está haciendo esto? ¿No debería ser así?
Cambio en línea, 2333, todo funcionará bien. Desde la perspectiva del funcionamiento normal, el problema es que no puedes controlar el funcionamiento del usuario. ¿Puedes controlar tu mente y dejar que el usuario opere de acuerdo con tus ideas? El desarrollo de software en sí mismo es la industria de servicios y nuestros principales clientes son Dios. Puede dejar que Dios vea que este producto está funcionando bien.
El optimismo es deseable. Debes ser optimista. La vida es tan difícil. Si no eres optimista, puedes ser optimista.
En el proceso de desarrollo, los desarrolladores deben considerar el problema desde el punto de vista del usuario, y considerar todo tipo de emergencias que puedan ocurrir y soluciones.
-
Dado que los programadores se desarrollan a través de actividades de pensamiento puro, esperamos que no haya dificultades en el proceso de implementación.
Desarrollo orientado al usuario, los productos se basan en las necesidades comerciales. Con respecto a las necesidades comerciales, creo que la comprensión profunda del negocio es incremental y es imposible comerse a un hombre gordo de un bocado. En el desarrollo y la codificación diarios, puede encontrar estos y otros problemas comerciales, y gradualmente llevar a cabo un llenado comercial incremental. Teniendo en cuenta el ciclo cerrado del negocio en general, basado en el ciclo cerrado del negocio, es necesario considerar si el diseño comercial de un lugar determinado es razonable. La consideración aún no es solo del desarrollador, sino más del usuario.
-
Sin embargo, nuestras propias ideas son defectuosas, por lo que siempre habrá errores.
El plan perfecto se modifica repetidamente, no desde el principio. Dado que el desarrollo de software es una industria de servicios, no siempre puede satisfacer las necesidades crecientes o cambiantes de los usuarios. Es precisamente por esto que es necesario actualizar iterativamente, mejorar gradualmente y avanzar hacia el objetivo de diseñar un software perfecto.
Los defectos mencionados aquí no se limitan a defectos de diseño, defectos de codificación, etc., sino que la manifestación final de los defectos son todos los errores del producto. El desarrollo es demasiado difícil ~~
-
Las técnicas de estimación que rodean la contabilidad de costos confunden la carga de trabajo y el progreso del proyecto.
人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。Creo que este texto en negrita y descolorido es la idea central del capítulo.
Una mujer sólo puede dar a luz a un bebé en diez meses de embarazo ¿Es posible que diez mujeres puedan dar a luz a un bebé en un mes de embarazo?
Un cocinero tarda diez minutos en cocinar un plato de huevos revueltos con tomates ¿Pueden hacerlo diez cocineros en un minuto?
El desarrollo de software es incremental y requiere trabajo previo para impulsar el desarrollo posterior, no basado en el trabajo independiente del personal. Varias personas crean un producto de software juntas, en lugar de que cada individuo haga el suyo y, finalmente, simplemente lo monte.
El mito del mes del hombre con un poco de ironía es similar a la teoría, y realmente existe. Frente a la demanda de costos y ganancias, siempre existirá una contradicción tan irreconciliable. Cómo conciliar la contradicción entre los dos, si me preguntas, no puedo responder, creo que no es solo la falta de experiencia, sino también el desarrollo de software que entiendo que existe en
乌托邦él. Al igual que cuando estábamos en la escuela, los libros eran un canal autorizado para nuestra cognición y comprensión. Hoy, el caleidoscopio de la realidad social no es lo que imaginamos.Todavía es demasiado joven ~~~
-
El desglose de las tareas entre varias personas generará una carga de trabajo de comunicación adicional, capacitación y comunicación mutua.
Este también es un punto débil en el proceso de avance del proyecto Según mi experiencia actual, el costo de la comunicación es demasiado alto y ni siquiera es una exageración.
Es como unas cuantas personas corriendo un maratón juntas. De repente alguien se involucra, pero la ruta no está clara y el avance es lento. Estás a mitad de camino y él está en el punto de partida. En este momento, alguien necesita reducir la velocidad o incluso retirarse para conectarse con los miembros en el punto de partida, y luego continuar dirigiendo a los miembros recién incorporados para que se pongan al día. Sin embargo, el tiempo ha ido pasando ~, el tiempo no esperará a otros.
Cuando se trata de tiempo, realmente se hace eco de la idea central del texto completo.
-
Con respecto al cronograma, mi experiencia es 1/3 de planificación, 1/6 de codificación, 1/4 de prueba de componentes y 1/4 de prueba del sistema.
Aquí me gustaría hablar sobre mis puntos de vista sobre el plan de un tercio:
需求阶段Parte del plan debe incluir la etapa de análisis de requisitos El análisis de requisitos tiene una posición importante en todo el proceso de desarrollo de software y sirve como base para el trabajo previo. Son necesarios un análisis de demanda perfecto y requisitos de aterrizaje de demanda razonables. Como dice el refrán, un buen comienzo es la mitad de la batalla.
Desde el punto de vista del usuario, el desarrollo se lleva a cabo mediante la recopilación de la demanda, el análisis de la demanda, la selección de la demanda y el aterrizaje de la demanda. Este requisito ha surgido de la nada, y el proceso de general a claro es necesario y necesario. Admiro a aquellos que pueden poner ideas en palabras y convertirlas en necesidades reales para el diseño de productos. Estos talentos son pioneros y evangelistas de los productos de software.
-
Como disciplina, carecemos de estimaciones de datos.
La estimación de datos está relacionada con el control y la gestión del progreso general del proyecto, y la importancia de la experiencia aquí es obvia. Experimentado no es lo mismo que nunca experimentado, tal vez la gente haya pisado más fosas de las que tú has comido. La evaluación de la capacidad de la experiencia no se puede cuantificar, pero el producto refleja la manifestación de la capacidad.
Un buen PM tendrá una fuerza invisible para controlar la situación general.
-
No estamos seguros de nuestra tecnología de estimación, por lo que bajo la presión de la administración y los clientes, a menudo nos falta el coraje para perseverar.
El coraje no es algo que pueda tener en el primer "Coraje". El desarrollo de software utópico existe en el papel más que en la realidad. Entonces, frente a la realidad, ¿puede "Courage" darte coraje?
-
Ley de Brooks: Agregar mano de obra a proyectos que están retrasados en el cronograma solo hará que el cronograma se retrase más.
-
La reasignación de tareas en sí y la interrupción del trabajo causada por ella;
-
Capacitar al personal nuevo;
-
Comunicación mutua adicional.
-
Incrementar la carga de trabajo global necesaria para el proyecto desde tres aspectos:
-
para resumir
De hecho, todo lo que se ha dicho es solo la punta del iceberg en el libro. Aunque el contenido en papel es muy conmovedor, todavía es un proceso difícil implementarlo en acción.
¿Por qué es difícil? 试错成本Demasiado alto. Mirando hacia atrás en la historia, el cambio a menudo significa derrocar y reconstruir ¿Quién puede garantizar que la experiencia de los demás también sea aplicable a uno mismo? El autor nos dice que no hagamos esto a través de ejemplos prácticos, pero ¿cuántas personas lo creen? Incluso si lo creen, ¿cuántas personas realmente se preocupan por él y lo practican?
El contenido anterior es puramente personal, por favor no rocíe si no le gusta. Si hay alguna similitud, es usted quien me copió ~~.
Tome las palabras finales del libro como las palabras finales de este intercambio:
El pozo de alquitrán de la ingeniería de software continuará haciendo que las personas sean difíciles e incapaces de liberarse durante mucho tiempo en el futuro. El sistema de software puede ser la cosa más intrincada en la creación humana, y la gente solo puede esperar que la gente explore y pruebe dentro de su capacidad o simplemente más allá de su capacidad. Esta compleja industria necesita: desarrollo continuo; aprender a utilizar elementos más grandes para desarrollar; el mejor uso de nuevas herramientas; la mejor aplicación de métodos de gestión de ingeniería probados; buen juicio propio y la capacidad de hacernos conscientes de nosotros mismos. Insuficiencia: la humildad dada por Dios.