¿Cómo afectan los plazos ajustados y la presión de programación al TCO y al tiempo de entrega?

El padre de un amigo, que es gerente de ingeniería de software, dijo enfáticamente: "La causa número uno de los excesos de programación es la presión de programación".

¿Dónde se encuentra la investigación? ¿Es estimulante una cantidad moderada de presión de programación, o el gerente que mencioné es correcto o incorrecto, o se trata de "cuanta más presión de programación tenga, mayor será el tiempo de entrega y más TCO?" ¿Es una de esas cosas donde idealmente la ingeniería de software funcionaría sin programar la presión, pero prácticamente tenemos que trabajar con limitaciones de situaciones del mundo real?

Cualquier enlace a la literatura de ingeniería de software sería apreciado.

La causa número uno de los excesos de programación es la presión de programación.

Estoy en desacuerdo. La causa número uno de los excesos de programación es un horario que no refleja la realidad, y de una manera demasiado optimista. La naturaleza humana dicta que cierta presión de programación es una necesidad absoluta. Solo un par de problemas que surgen sin cierta presión de programación son problemas interesantes y "lo mejor es enemigo de lo suficientemente bueno". Nosotros, los técnicos, preferiríamos trabajar en los problemas que nos interesan en lugar del problema que debe resolverse para que el producto salga por la puerta. Elimine los plazos (también conocido como presión de programación) y trabajaremos en esos problemas interesantes, en detrimento del producto.

Otro problema es que el producto debe ser "lo suficientemente bueno". No necesita ser perfecto. Los ingenieros y científicos ven los supuestos simplificadores que no son del todo válidos en algunos casos especiales. Los diseñadores gráficos ven problemas de alias que son invisibles para todos los demás. Los programadores ven verrugas en sus arquitecturas que tienen cero impacto en el comportamiento del producto. "Lo mejor es enemigo de lo suficientemente bueno", lo que significa que a veces tenemos que vivir con esos problemas que no son realmente problemas.

La falta de presión de programación conducirá a un producto con un costo de propiedad muy alto. Lo que causa los excesos son los malos horarios. Esto puede venir en una variedad de formas. Es necesario subestimar el esfuerzo, no tener en cuenta las dependencias y agregar personas a un proyecto que ya está retrasado. Sólo para nombrar unos pocos.

El tiempo, la calidad, los recursos y la cantidad de funciones están todos conectados. Puede arreglar cualquiera de ellos y obtener el último como resultado de su proceso de programación.

La forma en que se formula su pregunta implica que el tiempo es su variable, y las otras tres (la calidad, los recursos y la cantidad de características) son todas fijas. La pregunta puede beneficiarse al cambiar un poco la perspectiva al fijar el tiempo ^* y dejar que la calidad flote.

Ahora su pregunta es la siguiente: "¿Las restricciones de tiempo afectan negativamente la calidad"? La respuesta a esta pregunta es un rotundo "Sí": la investigación confirma que a las personas les va peor bajo la presión de los problemas relacionados con las matemáticas ^** que no han practicado ampliamente antes (es decir, lo han intentado cincuenta veces o más), por lo que el padre de su amigo tiene razón.

^** Aquí hay una suposición implícita de que la programación es similar a hacer matemáticas; Creo que esta suposición es justa.

Cuanta más presión de programación tenga, mayor será el tiempo de entrega y más TCO?

Bueno, cualquier programación realizada por el gerente sin discutirlo con el líder técnico es propensa a eso. Es muy obvio que la programación o las estimaciones que NO están basadas en hechos son propensas al fracaso .

Además, los gerentes que evitan la programación basada en evidencia también se están moviendo hacia el próximo fracaso de su proyecto. Hay varios estudios sobre este tema y la programación basada en métricas es la forma correcta de seguir.

Programación de derecha a izquierda.

Alguien en la gerencia siempre piensa que son Steve Jobs con su famosa zona de distorsión de la realidad. Hasta que alguien en el desarrollo de productos los eduque, los gerentes no técnicos a menudo pueden tener una visión sobre la programación que es tan sofisticada como la primera película francesa "Le voyage dans la lune" ("Un viaje a la luna") era para la ciencia de los cohetes.

El problema ha estado presente por un tiempo. Fred Brooks habla sobre la estimación sin tripas en Mythical Man-Month . Barry Boehm habla de ello en sus propuestas para un enfoque de gestión de Theory-W . Más recientemente, Steve McConnell (autor de Code Complete ) enfoca el concepto de negociación de principios en "Cómo defender un programa impopular" .

Agile empuja el alcance de los proyectos a un lugar donde sea altamente visible. El Manifiesto Ágil llama a la "colaboración del cliente sobre la negociación del contrato". También, espero, empodera a las personas responsables. El juego de planificación evita que los interesados ​​no técnicos coaccionen a los desarrolladores con las promesas que hicieron hace mucho tiempo que han sido invadidas por cambios en los requisitos o nuevos descubrimientos.

Si su organización rechaza ágil, existen excelentes métodos relacionados con la calibración de estimaciones para volver a ajustar un cronograma basado en el valor ganado . No creo que el valor ganado haga un gran trabajo con algunos de los problemas reales con la predicción, pero puede ayudar a disipar las ilusiones sobre la velocidad de los proyectos y la arpa en las estimaciones que tenemos como hechos.

Hay un dicho que dice que cuanto antes comience a codificar, más tardará. La presión del horario puede tener el efecto de forzar el cambio de metodología. A veces es de cascada a "código como el infierno". Esto puede tener un impacto negativo en la calidad, por no mencionar la moral cuando los trabajadores no pueden hacer lo mejor y sus compañeros y futuros mantenedores los ven en su peor momento, no en su mejor momento. En un entorno como este, cierto grado del caos puede controlarse con control de fuente, creación y prueba diaria (o integración continua y prueba de unidad), revisiones de código, utilizando un equipo experimentado y altamente calificado, resistiendo la tentación de agregar personal tarde el proyecto, y el viejo standby, horas extras.

Otras veces, el cambio de metodología puede ser de cascada a incremental iterativo. Mi experiencia ha sido que la administración tardó en adoptar a Agile. Pero luego, después de un tiempo, hubo una nueva administración que fue más solidaria con Agile. Time boxing puede ser como presupuestar: puede obligarnos a pensar en el mejor uso de un recurso limitado. Scrum tiene dos cuadros de tiempo: uno es diario para comentarios entre los miembros del equipo, el otro es mensual para el sprint a través de la lista de grabación.

Licencia Creative Commons: consulte http://en.wikipedia.org/wiki/File:Scrum_process.svg

No necesita literatura de ingeniería de software. Probabilidad conceptual y estadísticas, de pregrado, es todo lo que necesitas.

Una estimación es solo eso, una estimación. No es preciso, no está garantizado. Para cualquier estimación, hay alguna probabilidad de que lo supere o lo golpee en la nariz, y cierta probabilidad de que lo supere.

Probabilidad 101: p (underrun o hit exactamente) + p (overrun) = 100%.

Un horario basado en una estimación tiene exactamente las mismas características.

No se puede eliminar la incertidumbre por completo. SIEMPRE habrá alguna probabilidad de desbordamiento. Puede ser pequeño, la probabilidad de que Irán destruya su edificio de oficinas, pero todavía está allí. Lo mejor que puede hacer es mirar TODO y reducir la incertidumbre tanto como pueda. Una vez que haya hecho eso, tendrá suerte, si tiene suerte, tendrá un horario con poca incertidumbre y un 50% de probabilidad en cada lado.

Ahora, piénselo: si aplica el cronograma, la probabilidad de que no se ejecute correctamente o se cumpla exactamente el cronograma disminuye. El total todavía tiene que sumar el 100%. ¿A dónde va esa probabilidad? Respuesta, entra en la probabilidad de desbordamiento.

General Dynamics / Fort Worth Division aprendió esto de la manera difícil. Hicieron su estimación inicial para el desarrollo de F-16C / D, y lo enviaron a la cadena alimentaria. Alguien más alto cortó arbitrariamente un año y lo envió a la Fuerza Aérea. Como resultado directo, GD / FW se retrasó un año en la prueba de vuelo, y la Fuerza Aérea NO estaba contenta. (Tenga en cuenta que "un año de retraso" estaba de acuerdo con el cronograma revisado, lo que significa que el cronograma original era DERECHO AL OBJETIVO).

Creo que una cierta presión en un proyecto está bien porque ayuda a mantener el enfoque.

Sin embargo, si la presión no es realista, o si la comunicación entre la gerencia y el personal técnico no funciona correctamente, sí, existe el riesgo de que la presión de programación resulte en mala calidad y / o entrega tardía.

Un desarrollador experimentado sabrá que no se espera que él / ella produzca la solución perfecta, sino más bien una solución que sea lo suficientemente buena . Entonces, la estimación dada por dicho desarrollador ya reflejará su comprensión de lo que es lo suficientemente bueno para un proyecto en particular.

Existen muchos factores que influyen en la definición de lo suficientemente bueno.

Por ejemplo, ¿cuántos meses dura el proyecto? Si el proyecto dura un año, puede escribir un prototipo de ese módulo particularmente difícil con bastante rapidez al comienzo del proyecto y luego tiene varios meses para probarlo y depurarlo como una actividad paralela para el desarrollo de otros módulos más rutinarios. (Puede dejar que el módulo madure durante varios meses hasta que sea lo suficientemente bueno como para no tener que intentarlo desde el principio). Creo que esta estrategia es muy efectiva, pero necesita un gerente que confíe en usted y le permita Mantenga un proyecto abierto durante meses. Otro administrador (desconfiado) podría presionarlo para que termine ese módulo lo antes posible (no importa si tendrá que arreglarlo más tarde y si este enfoque finalmente le costará mucho más tiempo en total).

Otro ejemplo: el proyecto es para un producto que solo tendrá una versión. Luego, puede intentar hacerlo rápidamente y confiar en pruebas exhaustivas para asegurarse de que el producto funcione como se espera ( lo suficientemente rápido y sucio ). Por otro lado, si el producto va a tener dos o tres lanzamientos, mejor dedique algún tiempo a diseñarlo, para evitar una extensa reescritura del código para lanzamientos posteriores. (En este caso, rápido y sucio no es lo suficientemente bueno porque el tiempo total de desarrollo durante las tres versiones es mayor).

En pocas palabras, creo que la mala comunicación entre la gerencia y el personal técnico y la falta de una comprensión común de lo que es lo suficientemente bueno para el proyecto en cuestión puede conducir a una presión de programación excesiva, lo que resulta en mala calidad / entrega tardía.

Nunca hay tiempo suficiente para hacerlo correctamente la primera vez, pero siempre hay tiempo suficiente para arreglarlo más tarde.