Existen algunas leyes que se utilizan para determinar cuándo es prudente y cuándo no el incorporar más recursos a un proyecto de desarrollo de software o de implementación de sistemas de nivel medio, alto o complejo y que se encuentren ya en ejecución.
Naturalmente, han sido postuladas en diversas épocas y por ende no son norma infalible, pues el desarrollo de sistemas es cambiante y tiende a ir constantemente de la mano con la tecnología de su época.
La primera de las leyes que quisiera exponer es la Ley de Brooks, que establece:
“añadir más efectivos a un proyecto de software en retraso, lo retrasará más”
Fred Brooks lo ejemplificó de manera sagaz indicando que el mismo principio es el que aplica a que nueve mujeres no pueden tener un bebé en un mes.
Ahora, ¿cómo se puede aplicar en el campo del desarrollo de software convencional?
En dos de los proyectos que trabajé, un Sistema Transaccional de Ventas para una multinacional de distribución de productos alimenticios para generar reportes de gestión y servir de interfaz entre los dispositivos móviles de venta (handhelds) y un backend en AS400, y un Sistema de Análisis y Gestión de Tráfico Publicitario y Mercadeo Directo para Agencias de Publicidad, siendo sistemas que competen a un giro de negocio especializado (no es el caso de un sistema de facturación y de punto de venta para tiendas o almacenes, por ejemplo, que tiende a ser muy común), más allá del perfil técnico y del conocimiento de las herramientas de desarrollo (IDE, Lenguaje y plataforma, Sistemas Operativos y Gestores y/o Manejadores de Bases de Datos, generadores de reportes, etc.), el principal inconveniente es el conocimiento en sí de los requerimientos del negocio, las limitantes y la cultura organizacional que lo impulsa.
Así se llega a tener que el éxito de la etapa de desarrollo e implementación depende fundamentalmente de un dimensionamiento correcto del recurso en la etapa de análisis y diseño. Superada esta etapa, más vale asumir el retraso de no considerarlo al inicio y no magnificar la problemática incorporando recurso cuya curva de aprendizaje solo impactará más aún en tiempo.
En muchos casos prácticos tampoco es viable aplicar el triángulo de hierro (tiempo – recursos – alcance del proyecto), ya que para tareas completamente serializadas será imposible reducir el tiempo incrementando el personal.
Sin embargo, existe una etapa donde la ley de Brooks no es aplicable, y si lo es la ley de Linus para encontrar errores. Esta cobra vigencia en la etapa de pruebas.
Linus Torvalds postuló que:
Dado un número suficientemente elevado de ojos, todos los errores se convierten en obvios
Incorporar más recursos en esta etapa (testers) y más aún de otras áreas que ni siquiera tenían nociones básica o conocimientos del funcionamiento del sistema resulta útil para encontrar vulnerabilidades inimaginables, que por otra parte suelen resultar de una manipulación ilógica por parte del usuario final.
Aún así, habrá cosas que se escapen, pero se mitigará el porcentaje de excepciones no controladas.
Quizá este postulado que enunciaré pueda también algún día comprobarse como una de las leyes de la Informática, la Ley de Lau:
Para todo esfuerzo de la ingeniería con la finalidad de automatizar un sistema y dotarlo de inteligencia artificial, existirá siempre un usuario final tal que su estupidez natural se imponga y predomine el colapso.
Fallo de Sistema
Puzzle Bobble
Karate Blazers
Puzzle De Bloques
Magical Cat Adventure