La principal diferencia entre el ingeniero de software y el artesano, artista o aficionado que desarrolla software por placer es la consciencia que el ingeniero tiene del impacto económico de sus decisiones. Un ingeniero de software no decide refactorizar toda la base de código del producto por capricho, no decide cambiar el framework o tecnología por seguir la última tendencia en boga. Un ingeniero sopesa el costo y el beneficio, protegiendo en todo momento la inversión.
La ingeniería busca satisfacer unas necesidades de acuerdo a un presupuesto, en un plazo determinado y con una calidad objetivo. El “triángulo de gestión” establece que la calidad se deriva de las siguientes restricciones: alcance, plazos y presupuesto. De esta forma, si se desea mantener la calidad constante, un cambio en una restricción implica cambios en las otras, por ejemplo, si se desea reducir el coste habrá que reducir el alcance o aumentar los plazos.
Sin embargo, la “Ley de Brooks”, corrige el triángulo de gestión en los proyectos de software.
💬 Lo que un programador hace en un mes, dos programadores lo pueden hacer en dos meses
Ley de Brooks
Fred Brooks señala que incluir más trabajadores en los proyectos de software aumenta la complejidad de la gestión y hace crecer geométricamente los flujos de comunicación necesarios para el traspaso de conocimiento. Por otro lado, ciertas tareas no pueden “paralelizarse”. Añadir más programadores a un proyecto no adelantará su finalización, probablemente lo retrase aún más. Resulta impensable que un editor proponga a un escritor añadir más escritores al “equipo” con el objetivo de acortar los plazos de publicación de su nueva novela. El esfuerzo que supone alinear a los escritores en el estilo narrativo o la trama de la novela, hace inviable este tipo de soluciones. Cuando el producto requiere de esfuerzo intelectual o creativo por parte del equipo de desarrollo, añadir más miembros al equipo no tiene por qué acortar los plazos.
El coste de un proyecto de software es principalmente las horas invertidas por el equipo de desarrollo, según Brooks, aumentar el número de trabajadores no acortará los plazos. De esta forma el triángulo de gestión es corregido por Brooks. De este modo, acortar los plazos de entrega, solo es posible reduciendo el alcance.
El ingeniero de software debe ser consciente del impacto económico que sus decisiones tienen sobre el producto software protegiendo en todo momento la inversión.
💬 [...] Alguien tiene que pagar por todo esto. El desarrollador de software no puede desconocer el riesgo económico que puede implicar un gran "éxito” técnico. Asegúrese de que está aportando valor de negocio: cumple con los objetivos del negocio y atiende las necesidades del negocio [...]
Kent Beck, Extreme Programming Explained
Las decisiones a tomar en ingeniería del software deben encaminarse a proteger una inversión. El objetivo es hacer esa inversión lo más beneficiosa posible, generando el máximo valor cuanto antes, mitigando los riesgos que surjan, controlando el coste y evitando endeudarse en exceso.
Existen algunas métricas que ayudan a medir el valor, como el KPI, Key Performance Indicator. Estas métricas proporcionan una cantidad importante y valorable de información que ayuda en la toma de decisiones. Un KPI es una cuantificación de un desafío importante de negocio, un valor numérico en el que subyace la importancia de la conexión entre este y los retos de negocio.
La naturaleza intangible del producto software hace que no sea necesario la provisión de materias primas para su construcción. Los costes del producto software es prácticamente la suma del coste del tiempo de trabajo que los diferentes técnicos han invertido durante su construcción. Además del coste del tiempo puede añadirse al cálculo la amortización de hardware (estaciones de trabajo, servidores, etc.) y el precio de las licencias de herramientas utilizadas por los técnicos (Sistemas de control de versiones, plataformas de integración continua, etc.), aunque estos costes suelen ser despreciables en comparación del coste del tiempo del trabajo en proyectos de cierta envergadura.
En los 80s y 90s se popularizó un modelo de gestión de costes denominado COCOMO. El Modelo Constructivo de Costos (COCOMO, por su acrónimo del inglés) es un modelo matemático de base empírica, derivado de la experiencia, utilizado para estimación de costes. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado. Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, en su libro "Software Engineering Economics". La utilización del número de líneas de código como uno de los parámetros, así como la complejidad de los cálculos, ha hecho disminuir su influencia. Actualmente apenas es utilizado, en su lugar se utiliza el “juicio del experto” o los costes reales derivados de la construcción de otro producto software de naturaleza similar como principal criterio a la hora de estimar el coste. El “juicio del experto” no hace referencia necesariamente a una persona, es habitual que la valoración sea realizada por el equipo técnico de desarrollo.
El esfuerzo de desarrollo puede ser medido con “puntos función” o con “puntos historia”:
Los Puntos Función son una métrica que pretende establecer el tamaño en función de la complejidad de los requisitos. Es habitualmente utilizada en la visión predictiva. Es necesario requisitos muy detallados para poder extraer todos los parámetros necesarios para calcular los “puntos función” (existe una fórmula predefinida).
Los Puntos Historia son una métrica para establecer el “tamaño” de una Historia de Usuario (HU) en función del esfuerzo. Una HU de dos Puntos Historia se estima que requerirá el doble de esfuerzo que una HU de un único Punto Historia. Los Puntos Historia se obtienen a partir de la propia experiencia del equipo de desarrollo. La estimación de los puntos de historia es realizada por el propio equipo durante el planning meeting, habitualmente a través de una liturgia conocida como “planning poker”.
🔎 El Planning Poker es una técnica ampliamente utilizada para la estimación de coste. El planning poker ayuda al equipo de desarrollo a alcanzar un consenso. Cada miembro del equipo posee una baraja de cartas. Las cartas del mazo están numeradas siguiendo la secuencia de fibonacci: 1, 2, 3, 5, 8, 13, 21, 34, 55, etc. Los miembros del equipo muestran simultáneamente su estimación mostrando la carta elegida. La carta más repetida será la estimación acordada por el equipo. El planning poker elimina el efecto ancla, sesgo cognitivo que describe la tendencia humana a otorgar demasiado valor a la primera información recibida. La secuencia de fibonacci refleja cómo la incertidumbre crece a medida que la estimación es mayor, de esta manera, cuando la tarea es pequeña la estimación del coste es “fina” (1, 2, 3, 5, 8), en cambio cuando la tarea es grande la estimación del coste es “gruesa” (34, 55, 89, 144).
La deuda es el coste futuro, el esfuerzo pospuesto. En 1992, Ward Cunningham, firmante del Manifiesto Ágil, introdujo la metáfora de la deuda técnica para explicar a roles no técnicos la importancia de la recodificación sistemática de código heredado. El término deuda técnica surge de una analogía entre un desarrollo de software y la petición de un crédito financiero. De igual forma que un crédito permite obtener liquidez a corto plazo a costa del pago de futuros intereses, las carencias introducidas durante el desarrollo del software proporcionan un beneficio a corto plazo (la entrega a tiempo de una versión del software) pero en un futuro requerirán gastar el tiempo inicialmente ahorrado sumado a un esfuerzo extra (los intereses), es decir, dichas carencias generarán una deuda técnica con los mismos aspectos negativos que los intereses del crédito financiero solicitado.
La refactorización es la modificación en el código del producto que no implica cambio funcional alguno. El objetivo de estas refactorizaciones no es entregar más valor al cliente, sino hacer el software más fácil de mantener y evolucionar reduciendo de esta forma la “deuda técnica” que suele acumularse con el aumento de líneas de código. Las refactorizaciones del producto software pretenden el último término abaratar los costes de evolución y mantenimiento reduciendo los futuros “intereses”.
La deuda no es negativa en sí misma, la deuda permite financiar el desarrollo entregando valor “cuanto antes”. Sin embargo, la premura por realizar ciertos desarrollos puede llevar a los programadores a desplegar en producción código de baja calidad, código difícil de entender cuya evolución y mantenimiento requiere de mucho esfuerzo. Esta deuda comenzará a resultar problemática cuando sea necesario modificar el código, por ejemplo, si se desea cambiar la funcionalidad ofrecida por el software, es en ese momento cuando la deuda comenzará a cobrarse intereses.
El riesgo es la posibilidad de ser expuesto a una circunstancia adversa o no deseada. En la visión predictiva es fundamental la gestión activa del riesgo. Es imprescindible identificar los riesgos, analizarlos y definir el plan de acción en cada caso. El análisis del riesgo suele basarse en una matriz donde medir la gravedad del impacto y la probabilidad de que el riesgo se materialice. El plan de riesgos y la matriz impacto/probabilidad suelen documentarse en una hoja de cálculo.
En la visión adaptativa la gestión del riesgo no requiere la generación de tantos artefactos. La propia naturaleza del método de construcción implica la mitigación o reducción de riesgo. La visión adaptativa es segura “por definición”. Las iteraciones cortas y las entregas incrementales del producto permiten detectar y corregir de forma temprana si el producto no satisface las necesidades del cliente. La construcción basada en pruebas automatizadas reduce los errores en el software. Las metodologías ágiles se fundamentan, no en la construcción rápida, sino en la construcción “segura”, minimizando los riesgos.
🔎 Un factor clave en la Gestión de Riesgos es el conocido Cono de Incertidumbre: Al comienzo de un proyecto de ingeniería de software el grado de incertidumbre es máximo. A medida que se avanza en el proyecto la incertidumbre comienza a despejarse. Sin embargo, la gestión del proyecto puede hacer que la mayor parte de las decisiones se tomen al comienzo del proyecto, cuando mayor es la incertidumbre. Esto inevitablemente hará crecer los riesgos. Una forma de mitigar estos efectos es posponer decisiones que impliquen un fuerte compromiso funcional y técnico, para a medida que la incertidumbre se disipa, ir aumentando el grado de compromiso y acoplamiento con la solución propuesta.
Tras los cuatro valores descritos, los firmantes redactaron los doce principios que de ellos se derivan. Estos doce principios subrayan la importancia de entregar con frecuencia software que funciona, aceptar los cambios, la excelencia técnica y el desarrollo sostenido.
El manifiesto propone una nueva forma de construir software, sustituyendo la visión predictiva, por otra visión adaptativa. La visión adaptativa “abraza el cambio”, elimina los silos de especialistas y busca la excelencia técnica.
La matriz Valor vs Coste es un elemento básico de la priorización de productos, es simple y eficaz. Es suficiente con estimar para cada nueva funcionalidad a incorporar al producto software su valor (impacto) y su coste (esfuerzo). De este modo cada funcionalidad queda representada por un punto en el diagrama valor vs coste. Es sencillo evaluar qué funcionalidades deben incorporarse al producto y cuales deben descartarse. Aquellas funcionalidades que aporten mucho valor con poco coste deben desarrollarse. Por el contrario, aquellas funcionalidades que no aporten valor y que impliquen un gran esfuerzo de desarrollo no deben desarrollarse.
En 1979, los psicólogos del comportamiento Daniel Kahneman y Amos Tversky describieron el fenómeno que llamaron falacia de la planificación. Demostraron que las personas y los equipos son habitualmente demasiado optimistas sobre cuánto tiempo les llevará completar una tarea futura, subestimando el tiempo real requerido para hacerlo. En 2003, Kahneman y Lovallo ampliaron la definición de falacia de planificación para incluir la tendencia a subestimar el tiempo, los costos y los riesgos de acciones futuras y al mismo tiempo sobreestimar los beneficios de las mismas acciones. Este comportamiento humano puede tenerse en cuenta para corregir los pesos relativos del coste y el valor de la matriz.
Estas matrices de valor ayudan a mitigar un problema habitual de la industria: la sobreingeniería. La sobreingeniería consiste en dar soluciones técnicas muy buenas a problemas inexistentes. Suele venir acompañada de un incremento en la complejidad del software sin aumentar el valor contraprestado. La sobreingeniería prescinde del punto de vista económico a la hora de tomar decisiones relativas a la construcción del software.
Tanto la ley de brooks, como la matriz valor vs coste, son reglas heurísticas, han sido deducidas a partir de percepciones y experiencias obtenidos en la realización de múltiples proyectos. Estas leyes, reglas y técnicas no surgieron de un modelo científico, sino de la intuición. La formulación de estas “leyes” suponen el fundamento cualitativo para las metodologías y prácticas utilizadas en la ingeniería del software.
🔎 El Modelo Estándar de la física de partículas predijo la masa del bosón Z en 91,1874 GeV. El gran colisionador de electrones y protones del CERN midió el decaimiento de los bosones Z en exactamente 91,1876 ± 0,0021 GeV. Nunca antes en la historia de la humanidad una medida experimental había sido predicha con tal nivel de exactitud.
La Ingeniería del Software no hace uso del método científico. Las leyes heurísticas utilizadas en la construcción del software no tienen la capacidad de predicción de las leyes derivadas de las teorías científicas, sin embargo, aún sin esta capacidad de predicción estas “leyes” ofrecen soluciones pragmáticas a problemas recurrentes en la industria.
Las leyes heurísticas no son exclusivas de la ingeniería del software. En la teoría de organización industrial son bien conocidas otras leyes heurísticas como por ejemplo el Principio de Incompetencia de Peter, “En una jerarquía todo empleado tiende a ascender hasta su nivel de incompetencia” o la Primera Ley de Parkinson, “El trabajo se expande hasta llenar todo el tiempo disponible para su realización”.
Referencias:
• K.Beck; "Extreme Programming Explained", Addison-Wesley Professional, 1999
• F.Brooks; "The Mythical Man-Month: Essays on Software Engineering", Addison-Wesley, 1975
• R.C. Martin "Arquitectura Limpia", Anaya, 2018
• J. Palacio; "Flexibilidad con Scrum", 2008.
• H. Kniberg; "SCRUM y XP desde las trincheras", InfoQ, 2007
• R.Jeffries; "The Nature of Software Development", Pragmatic Bookshelf, 2015
• I. Sommerville; “Ingeniería del Software”, Addison Wesley, 2005
• R. Pressman; “Ingeniería del Software: Un enfoque práctico”; McGraw-Hill, 2005.
• B. W. Boehm, "Software Engineering Economics", Prentice Hall,1981
• L. Artola, “Software Economics”, LeanPub, 2020
• T. Winters y H. Wright, “Software Engineering at Google”, O’Reilly, 2020
• J.Garzas; https://www.javiergarzas.com/