El autor Frederick Brooks en su libro "The Mythical Man-Month" (1975), aborda muchos de los problemas comunes en el desarrollo de software y en los ámbitos de trabajo relacionados con él. Brooks identifica varias falacias que suelen existir en estos entornos, que son:
Falacia del optimismo de creer que todo irá bien: “todo irá bien, es decir, que cada tarea tomará solo el tiempo que ‘debería’ tomar” según lo planificado y se suele planificar considerando que todo irá bien, que lo que se pensó que se debería hacer es lo que realmente se hace, que se estimó lo correcto, que la gente estima bien, no se enferma ni se muere ni que existen las crisis económicas. Brooks argumenta que los desarrolladores y gerentes de proyectos tienden a ser optimistas por naturaleza y tienden a subestimar la cantidad de tiempo y recursos que se necesitan para completar una tarea de software. Esto a menudo lleva a que se establezcan plazos poco realistas y se ignoren los posibles retrasos y problemas técnicos que pueden surgir durante el desarrollo.
Promesas condescendientes: Creer que las estimaciones derivadas de deseos son cumplibles es una falacia. Los cronogramas falsos para coincidir con la fecha deseada del cliente es mucho más común en nuestra disciplina que en cualquier otra parte de la ingeniería.
Falacia de la programación: La idea de que la programación es la principal tarea en el desarrollo de software y que todo lo demás es secundario. Esto lleva a la falsa idea de que “La productividad se mide en horas de programación”. No se puede estimar el esfuerzo total de un proyecto estimando el tiempo de codificación y extrapolándolo a las demás tareas. Tampoco sirve extrapolar la construcción de pequeños sistemas a proyectos de sistemas más complejos. El incremento en el esfuerzo es una potencia del tamaño del proyecto. Tampoco se puede medir la productividad en horas de programación. Hay estudios que dicen que los programadores sólo dedican el 50% de su tiempo a la programación y el resto a otras tareas. Cuando se asigna ese otro 50% a programar más código se termina generando carry-over por sobrecarga y se hace más ineficiente el trabajo del equipo.
Falacia del hombre-mes: La creencia de que se puede acelerar el desarrollo de un proyecto de software simplemente agregando más programadores al equipo. Esta falacia está relacionada a “Medir recursos humanos en función de hora y personas”, el hombre mes. Como si el progreso variara, igual que el costo, como el producto del número de hombres y el número de meses, considerando que las personas y los meses son intercambiables. Como si se pudiera tener un parto en un mes asignando nueve mujeres como recursos humanos.
Falacia de la panacea: La creencia de que existe una única solución perfecta para cualquier problema de software, y que es posible encontrarla con suficiente tiempo y esfuerzo.
Falacia del segundo sistema: La creencia de que, tras completar un primer sistema, el desarrollo del segundo sistema será más fácil y rápido, porque se tiene más experiencia.
Falacia de la depuración: La creencia de que la depuración de software es un proceso sistemático y predecible que se puede planificar y ejecutar con facilidad.
Promediar la productividad individual: Se suele creer que los desarrolladores pueden rendir individualmente con poca variabilidad. Sin embargo, los rendimientos son muy dispares,10:1 en mediciones de productividad y un increíble 5:1 en velocidad.
Los equipos grandes son productivos: La falacia de “con más personas se produce más”. Sin embargo en informática no es realmente así o por lo menos no para todo proyecto. Lo ideal del pequeño equipo fuerte, por común el consenso no debería exceder las 10 personas. Por eficiencia e “integridad conceptual”, uno prefiere unas pocas mentes buenas haciendo diseño y construcción.
El testing no es importante: Hay un pensamiento recurrente en el desarrollo de software: ”sabemos que la calidad es importante, pero cuesta tiempo y dinero —demasiado tiempo y dinero— lograr el nivel de calidad en el software que en realidad queremos”. Por lo general se subestima el testing estimando y dedicando poco esfuerzo y que a la larga trae costos por mala calidad, deuda técnica, poca mantenibilidad e impacto negativo en el negocio. De todos modos hacer testing es costoso y se piensa que no hacerlo reduce costos. Pues, merece la pena construir código de apoyo para la depuración, que puede llegar a ser el 50% del código a depurar, es costoso. Pero no hacer testing es más costoso.
Brooks argumenta que estas falacias son peligrosas y que los gerentes de proyectos y los desarrolladores de software deben ser conscientes de ellas para evitar cometer errores costosos y perjudicar el éxito del proyecto o la organización.
Referencias:
https://www.gestionenti.com/post/el-adi%C3%B3s-a-un-grande-se-nos-fue-frederick-p-brooks
http://tratandodeentenderlo.blogspot.com/2011/03/mythical-man-month.html
No hay comentarios:
Publicar un comentario