Riesgos & Estimaciones Predecir lo impredecible Software Craftsman Solution Architect @ AVANADE GitKraken Ambassador Arquitectura de Soluciones Versión 1.0.0, Diciembre de 2024

2 2 Motivo de la elaboración de este documento (1/2) La gestión de riesgos y las estimaciones son componentes esenciales en el desarrollo de software, ya que, cuando se integran adecuadamente, proporcionan una base sólida para la toma de decisiones estratégicas. Dado que el riesgo es una parte inevitable de cualquier empresa, cada decisión implica cierto grado de gestión de riesgos, consciente o inconscientemente. En el ámbito del desarrollo de software, elegir una actividad sobre otra implica manejar riesgos, como la pérdida de cuota de mercado, la insatisfacción del cliente o problemas técnicos. Documentar estos riesgos es un paso crucial para anticipar y mitigar posibles problemas antes de que se materialicen. Este proceso no solo informa al equipo sobre los desafíos potenciales, sino que también prepara el terreno para desarrollar estrategias de respuesta efectivas, asegurando así que todos los miembros del equipo y las partes interesadas estén alineados en cuanto a las expectativas y las medidas a tomar. Una vez que se han identificado y documentado los riesgos, el siguiente paso es realizar estimaciones precisas para la arquitectura del software. La estimación no es un fin en sí mismo, sino una herramienta para alcanzar los objetivos en un entorno incierto y propenso a errores. Estimar permite prever el futuro y tomar decisiones informadas sobre el camino a seguir antes de llegar al punto final. En este sentido, las estimaciones permiten a los equipos de desarrollo hacer elecciones prudentes que favorezcan el éxito del proyecto, definiendo este éxito no por la fidelidad a los planes previos, sino por los resultados deseados alcanzados.

3 3 Motivo de la elaboración de este documento (2/2) La relación entre la documentación de riesgos y las estimaciones es fundamental. Comenzar por identificar los riesgos, incluyendo las suposiciones, proporciona un contexto claro y detallado que alimenta el proceso de estimación. Esto asegura que las proyecciones de tiempo y recursos estén alineadas con los desafíos y limitaciones identificados, facilitando así una planificación más precisa y efectiva. En última instancia, esta integración permite crear una arquitectura de software que no solo cumple con los requisitos funcionales, sino que también es resiliente frente a los riesgos potenciales, optimizando el diseño del sistema para abordar tanto las necesidades actuales como las amenazas futuras. El mayor peligro en tiempos de turbulencia no es la turbulencia en sí, sino actuar con la lógica de ayer. Peter F. Drucker (1909 – 2005) Esta cita me gusta mucho porque refleja la idea de que la incertidumbre puede ser aprovechada estratégicamente. En el contexto de las estimaciones de arquitectura de software, esto implica adoptar enfoques y prácticas que faciliten el manejo eficiente de la variabilidad y los cambios. Por esta razón, a menudo comenzamos con una prueba de concepto, lo que nos permite explorar nuevas ideas, ajustar nuestras estrategias y controlar la incertidumbre o los riesgos antes de comprometernos con un diseño final.

4 4 ¿A quién va dirigido este documento? Este documento está dirigido tanto a quienes están comenzando en el campo de la arquitectura de software como a desarrolladores experimentados. Para los principiantes en arquitectura, ofrece una introducción detallada a los conceptos fundamentales de gestión de riesgos y estimaciones, ayudando a desarrollar las habilidades necesarias para anticipar problemas y planificar soluciones efectivas. Para los desarrolladores con más experiencia, proporciona una comprensión más profunda de cómo las estimaciones precisas y la gestión efectiva de riesgos están interrelacionadas. Además, con esta información podrás comprender por qué muchos proyectos fracasan al intentar predecir lo impredecible. Espero que este documento sirva como una herramienta valiosa para todas aquellas personas que deseen entender cómo estas variables pueden ser determinantes para el éxito de los proyectos de software.

5 5 ¿Cómo está organizado este documento? • Introducción • Gestión de Riesgos ▪ Definición. ▪ Identificación. ▪ Evaluación. ▪ Mitigación. ▪ Monitoreo. • Ejemplo Práctico: Gestionar los Desafíos • Estimaciones en Proyectos de Software ▪ Importancia de las Estimaciones. ▪ Relación entre Estimaciones Precisas y la Gestión Efectiva de Riesgos. ▪ Métodos de Estimación. ▪ Mejores Prácticas. ▪ Asunciones para Controlar los Riesgos. ▪ Roles y Responsabilidades. ▪ Comunicación y Colaboración. ▪ Conclusión. • Ejemplo Práctico: Monte Carlo y ML.NET • Contexto • Reflexiones Finales: Integrando Estrategias para el Éxito

6 6 Introducción (1/10) Desde el punto de vista de la arquitectura del software Importancia de la Gestión de Riesgos y Estimaciones En el ámbito del desarrollo de software, la gestión de riesgos y las estimaciones son pilares esenciales que guían la toma de decisiones informadas. Como arquitecto de software, es crucial prever posibles obstáculos y planificar de manera efectiva para asegurar que el diseño y la implementación del sistema sean robustos y sostenibles. La capacidad de identificar, evaluar y mitigar riesgos permite a los arquitectos crear soluciones que no solo cumplen con los requisitos actuales, sino que también son escalables y adaptativas a cambios futuros. Interrelación entre Riesgos y Estimaciones Los riesgos y las estimaciones están íntimamente ligados y son fundamentales para el éxito de cualquier proyecto de software. Una estimación precisa proporciona una base para identificar áreas de incertidumbre y riesgo, permitiendo a los arquitectos planificar contingencias y asignar recursos de manera eficiente. Por otro lado, una gestión de riesgos efectiva puede influir en la precisión de las estimaciones, ya que permite ajustar los planes en respuesta a eventos imprevistos. Esta sinergia entre riesgos y estimaciones es clave para desarrollar arquitecturas que sean resilientes y capaces de soportar el estrés de un entorno tecnológico en constante evolución.

7 7 Introducción (2/10) En cualquier proyecto de software, todos los roles implicados se ven afectados por diversos riesgos, ya sea de manera directa o indirecta. La capacidad para identificar y mitigar estos riesgos depende en gran medida de la experiencia y la diversidad de roles que una persona haya desempeñado. Cuanta más experiencia tenga una persona en diferentes roles, más capaz será de reconocer tanto riesgos específicos como transversales. Esto no solo mejora su habilidad para gestionar los desafíos en su área de responsabilidad, sino que también le permite contribuir valiosamente al equipo en su conjunto, facilitando una comunicación más efectiva y asegurando una visión integral del proyecto. A continuación, se presenta una tabla que ilustra cómo diferentes roles dentro de un proyecto pueden verse afectados por diversos riesgos: Categoría de Riesgo Ejemplo de Riesgo Roles Afectados Software Diseño del software no alineado con los requisitos del cliente Solution Architect, Developer Falta de escalabilidad en la arquitectura del software Solution Architect Dependencia excesiva de tecnologías específicas Solution Architect, Developer Código de baja calidad que resulta en defectos y errores frecuentes Developer Dificultades para adaptar el software a cambios en los requisitos Developer Falta de pruebas adecuadas que llevan a problemas en la producción Developer

8 8 Categoría de Riesgo Ejemplo de Riesgo Roles Afectados Data e Infraestructura Integración ineficaz con sistemas existentes Enterprise Architect Infraestructura inadecuada para el volumen de datos esperado Enterprise Architect Falta de interoperabilidad entre plataformas Enterprise Architect Seguridad Vulnerabilidades en el diseño que comprometen la seguridad del sistema Technical Architect Falta de protocolos adecuados para la gestión de identidades y accesos Technical Architect Riesgos asociados a la implementación de nuevas tecnologías sin suficiente prueba Technical Architect Gestión de Proyectos Falta de alineación entre el equipo y los objetivos del proyecto Manager Retrasos en el cronograma debido a una planificación ineficaz Manager Problemas de comunicación y coordinación entre equipos Manager Cumplimiento Normativo Incumplimiento de las leyes de protección de datos personales Legal Falta de contratos claros que protejan los derechos de propiedad intelectual Legal Riesgos asociados a la falta de licencias de software adecuadas Legal Financiero Presupuestos insuficientes para completar el proyecto Contabilidad Falta de control sobre los costos y los gastos del proyecto Contabilidad Retrasos en la facturación y cobro a clientes Contabilidad Introducción (3/10)

9 9 Nadie está exento de riesgos, y cada rol tiene la responsabilidad de identificarlos. Aunque, cuanto más bajo estés en la jerarquía, menor es tu responsabilidad en la gestión de ciertos riesgos, es importante reconocer que muchos de estos pueden haberse originado en niveles superiores y eventualmente afectar al desarrollador. Sin embargo, si identificas un riesgo, no debes quedarte callado. A esto lo llamo levantar la mano. Cuanto antes se detecten los riesgos, antes podremos implementar soluciones, lo que resultará en menos inconvenientes tanto para los clientes como para los proveedores. La detección temprana y la comunicación efectiva de los riesgos son cruciales para mitigar su impacto y garantizar el éxito del proyecto. Estos riesgos que has podido levantar, suelen llamarse Riesgos Ocultos. Los riesgos ocultos son aquellos que no se identifican fácilmente durante las fases iniciales de diseño e implementación, pero que pueden tener un impacto significativo en el rendimiento, la escalabilidad y la seguridad del sistema a largo plazo. Estos riesgos son especialmente desafiantes porque suelen emerger cuando el sistema ya está en producción, lo que dificulta su mitigación sin incurrir en costos adicionales o interrupciones en el servicio. Por ejemplo: • Dependencias Subestimadas: Muchas soluciones dependen de componentes externos, como bibliotecas de terceros o servicios de API. Un riesgo oculto surge cuando estas dependencias no se gestionan adecuadamente, ya que cualquier cambio o discontinuidad en ellas puede causar fallos en el sistema. Por ejemplo, si una API externa cambia su estructura sin previo aviso, esto podría interrumpir la funcionalidad del sistema que depende de ella. Introducción (4/10)

10 10 • Cuellos de Botella en el Rendimiento: Durante el diseño inicial, puede que no se consideren adecuadamente las cargas máximas que el sistema debe soportar. Un riesgo oculto común es no identificar cuellos de botella en el rendimiento, que solo se hacen evidentes bajo condiciones de alta demanda. Por ejemplo, una base de datos que no está optimizada para manejar grandes volúmenes de transacciones puede convertirse en un punto crítico que ralentiza toda la aplicación. • Vulnerabilidades de Seguridad No Detectadas: Las amenazas a la seguridad a menudo surgen de vulnerabilidades no identificadas en el código o la configuración del sistema. Un riesgo oculto es la presencia de brechas de seguridad que no se descubrieron durante las pruebas iniciales. Por ejemplo, una configuración incorrecta de los permisos de acceso podría permitir a usuarios no autorizados obtener datos sensibles. • Costos Operativos No Previstos: Algunos riesgos ocultos se manifiestan en forma de costos operativos inesperados. Esto puede incluir gastos relacionados con el mantenimiento de tecnologías obsoletas o la necesidad de escalar rápidamente la infraestructura debido a un crecimiento inesperado del usuario. Por ejemplo, el uso excesivo de servicios en la nube sin una gestión adecuada puede resultar en facturas elevadas e imprevistas. • Dificultades de Integración: La falta de consideración de cómo una nueva solución se integrará con los sistemas existentes puede ser un riesgo oculto significativo. Problemas de interoperabilidad pueden surgir cuando los sistemas no se comunican eficazmente, lo que puede causar interrupciones en el flujo de trabajo. Por ejemplo, una nueva herramienta de gestión de proyectos que no se sincroniza correctamente con el software de colaboración existente podría causar duplicación de esfuerzos y confusión entre los equipos. Introducción (5/10)

11 11 Introducción (6/10) Importancia de la Cultura Organizacional en la Gestión de Riesgos La cultura organizacional desempeña un papel crucial en la gestión efectiva de riesgos y estimaciones dentro del desarrollo de software. Fomentar un ambiente de colaboración y comunicación abierta permite que los equipos identifiquen riesgos de manera temprana y aborden las incertidumbres con mayor precisión. Desde mi punto de vista estos son los 4 pilares fundamentales para el éxito: • Colaboración y Comunicación Abierta: Fomentar un ambiente donde los miembros del equipo compartan libremente sus observaciones facilita la detección temprana de riesgos ocultos, permitiendo soluciones rápidas y efectivas. • Formación Continua: Mantenerse actualizado con las últimas tendencias y prácticas fortalece la capacidad del equipo para anticipar y gestionar riesgos, mejorando tanto las habilidades individuales como colectivas. • Aprendizaje de Proyectos Pasados: Analizar lecciones de proyectos anteriores ayuda a refinar estrategias y estimaciones, fortaleciendo la capacidad del equipo para enfrentar incertidumbres. • Empoderamiento del Equipo: Dar autonomía a los miembros para tomar decisiones y asumir responsabilidades fomenta un sentido de propiedad y compromiso con el éxito del proyecto.

12 12 Introducción (7/10) Relación entre Estimaciones y Gestión de Riesgos Las estimaciones y la gestión de riesgos están intrínsecamente vinculada, ya que una influencia a la otra de manera significativa. Una estimación precisa puede ayudar a identificar áreas de incertidumbre y riesgo, mientras que una gestión de riesgos efectiva puede mejorar la exactitud de las estimaciones al permitir ajustes en los planes en respuesta a eventos imprevistos. A continuación, se presenta una tabla y algunos ejemplos que ilustran esta relación. Ejemplos de cómo los riesgos afectan las estimaciones: Fase del Proyecto Ejemplo de Riesgo Impacto en la Estimación Mitigación (ADRs o Asunciones) Planificación Requisitos incompletos o ambiguos Dificultad para estimar el alcance Utilizar ADRs para documentar decisiones clave y asunciones sobre requisitos Diseño Cambios en la tecnología seleccionada Retrasos en el cronograma Establecer asunciones claras sobre la estabilidad tecnológica y documentar las decisiones de diseño Desarrollo Falta de personal o habilidades Aumento en el tiempo de desarrollo Asumir tiempos de capacitación y documentar planes de contingencia para la falta de personal Pruebas Ambigüedad en los criterios de aceptación Retrasos en la validación Documentar criterios de aceptación claros y considerar ADRs para decisiones de prueba Implementación Problemas de integración Afecta el tiempo de despliegue Asumir riesgos de integración en las estimaciones y mantener registros claros de las dependencias

13 13 Introducción (8/10) Por eso existen métodos para integrar riesgos y estimaciones: • ADRs (Architectural Decision Records): • Documentar las decisiones arquitectónicas clave junto con las razones y las implicaciones asociadas ayuda a alinear las expectativas y proporciona un marco de referencia para las estimaciones. • Facilita la gestión de riesgos al permitir que todos los miembros del equipo entiendan y acepten las decisiones tomadas. • Asunciones Documentadas: • Las asunciones deben ser registradas claramente al realizar estimaciones, de modo que cualquier cambio en ellas pueda ser rápidamente identificado y abordado. • Ayuda a mitigar riesgos al establecer expectativas claras sobre las variables desconocidas del proyecto. • Estimaciones Basadas en Riesgos: • Incorporar una evaluación de riesgos en el proceso de estimación permite ajustar el tiempo y los recursos asignados según la probabilidad y el impacto de los riesgos identificados. • Esta práctica ayuda a crear un plan más robusto que puede adaptarse a las incertidumbres. • Revisiones Periódicas del Proyecto: • Realizar revisiones regulares de las estimaciones y los riesgos identificados permite detectar desviaciones tempranas y ajustar las estrategias de mitigación. Aquí entramos en la fina barrera entre el manager y la arquitectura. • Promueve la transparencia y mejora la colaboración entre los miembros del equipo.

14 14 Introducción (9/10) Al integrar estos métodos, que he puesto como ejemplos, se pueden mejorar la precisión de sus estimaciones y la eficacia de su gestión de riesgos, asegurando un enfoque más proactivo y adaptativo en el desarrollo de software. Esto no solo contribuye a proyectos más exitosos, sino que también fortalece la resiliencia del equipo frente a las incertidumbres. Con todo lo anterior en mente, es momento de definir qué significa estimar en el contexto del desarrollo de software. Las estimaciones son una herramienta fundamental que permite a los equipos prever los recursos, el tiempo y los costos necesarios para completar un proyecto o tarea específica. Esta previsión es crucial para establecer expectativas realistas con los stakeholders y guiar la asignación de recursos y la planificación estratégica a lo largo de las diferentes fases del proyecto. Nota del autor Como arquitecto de software, he aprendido que la clave para el éxito de cualquier proyecto no solo radica en la tecnología que usamos, sino en cómo anticipamos y gestionamos lo inesperado. A lo largo de mi carrera, he visto cómo una buena estimación puede evitar sorpresas desagradables y cómo la documentación de decisiones puede salvar un proyecto en momentos críticos. Mi consejo para cualquier profesional en este campo es que nunca subestime el poder de la comunicación clara y la planificación consciente. Estos son los verdaderos cimientos sobre los cuales se construyen proyectos de software exitosos y duraderos. Siempre mantengamos el diálogo abierto y nunca dejemos de aprender de cada experiencia, ya que cada proyecto es una oportunidad para mejorar y crecer.

15 15 Introducción (10/10) Las estimaciones pueden variar desde cálculos iniciales de alto nivel hasta evaluaciones detalladas basadas en datos históricos y análisis de riesgos. La incertidumbre es una característica inherente de cualquier proyecto, por lo que las estimaciones deben ser lo suficientemente flexibles como para adaptarse a cambios y ajustes conforme el proyecto avanza. más amplia y bien informada. Importancia de la Precisión en las Estimaciones Una estimación precisa es fundamental porque sirve como base para la gestión de riesgos y la toma de decisiones. Las estimaciones imprecisas pueden llevar a la asignación incorrecta de recursos, incumplimiento de plazos y sobrepaso de presupuestos, comprometiendo el éxito del proyecto. Además, una buena estimación permite identificar áreas de incertidumbre y riesgo desde el principio, facilitando la planificación de contingencias y la gestión proactiva de problemas potenciales. En definitiva, las estimaciones son una herramienta vital para la gestión efectiva de proyectos de software. Al combinar estimaciones bien fundamentadas con una gestión de riesgos rigurosa, los equipos podrán abordar de manera más efectiva las complejidades del desarrollo de software y entregar soluciones exitosas y sostenibles.

16 16 Riesgos (1/26) Definición En el contexto de la arquitectura de software, el riesgo se refiere a la posibilidad de que un evento o condición incierta tenga un impacto negativo en el proyecto o en el sistema en desarrollo. Esto puede incluir problemas técnicos, cambios en los requisitos, o incluso desafíos organizacionales. Los riesgos son inherentes a los proyectos de software debido a la complejidad y la naturaleza dinámica de los sistemas modernos. Como arquitecto/a, es esencial reconocer que cada decisión de diseño puede introducir nuevas incertidumbres y es fundamental identificar estas áreas de riesgo desde las primeras etapas del desarrollo. Es importante destacar que, aunque los riesgos no pueden ser eliminados completamente, pueden ser gestionados y mitigados a través de un enfoque estructurado y proactivo. Esto implica anticiparse a los posibles problemas, evaluar su impacto y probabilidad, y desarrollar estrategias para reducir sus efectos. Para un arquitecto de software, esto significa diseñar sistemas que no solo cumplan con los requisitos funcionales, sino que también incorporen mecanismos para adaptarse y recuperarse de fallos, asegurando así la continuidad y el éxito del proyecto a largo plazo. Nota del autor Yo os voy advirtiendo, entramos en un tema farragoso: los riesgos en el desarrollo de software son como el hielo en un camino; los ves tarde y resbalas. Barry Boehm lo resumió bien: "Si no atacas los riesgos, ellos te atacarán a ti.“ Esto implica que, aunque planifiques y creas tener todo controlado, las variables imprevistas pueden llevar a catastróficos fracasos. O lo que dijo Fred Brooks de forma más directa: "¿Cómo se retrasa un proyecto un año? Un día a la vez.“ El mensaje es claro: no subestimes los riesgos ni te confíes en modelos o planes "perfectos".

17 17 Riesgos (2/26) Todo es más sencillo con un ejemplo y el diagrama adjunto: supongamos que estás desarrollando una aplicación web para comercio electrónico. Durante el proceso de diseño, identificas varios riesgos potenciales. • Inicio: • Comienza el proceso de gestión de riesgos al inicio del proyecto. • Identificación de Riesgos: • Identificas que un riesgo potencial es la posible sobrecarga del servidor durante eventos de ventas del black- friday. • Evaluación de Riesgos: • Evalúas este riesgo en términos de impacto (alto, ya que podría afectar las ventas y la experiencia del usuario) y probabilidad (moderada, basado en eventos pasados). • Decisión: ¿Riesgo Aceptable? • Decides que este riesgo no es aceptable debido a su alto impacto potencial. • Desarrollo de Estrategias de Mitigación: • Desarrollas una estrategia que incluye la implementación de balanceadores de carga y escalado automático de servidores para manejar picos de tráfico. • Implementación de Estrategias: • Implementas estas estrategias en el sistema, configurando los balanceadores de carga y probando el escalado automático. • Monitoreo Continuo: • Monitorizas el sistema para asegurarte de que las estrategias de mitigación son efectivas y el riesgo está controlado.

18 18 Riesgos (3/26) • Revisión y Ajuste: • Revisas el proceso regularmente y ajustas las estrategias según sea necesario, basándote en nuevos datos de tráfico y comportamiento del usuario. • Fin (Opcional): • Puedes cerrar el ciclo si el riesgo está completamente mitigado, aunque generalmente el monitoreo continuo se mantiene durante toda la vida del proyecto. Adicionalmente, para completar el proceso de gestión de riesgos, podrías considerar incluir información adicional y pasos como: • Comunicación del Riesgo: • Asegúrate de que todos los interesados en el proyecto estén informados sobre los riesgos identificados, sus evaluaciones y las estrategias de mitigación. • Plan de Respuesta a Incidentes: • Desarrolla un plan para responder rápidamente si el riesgo se materializa, asegurando que el equipo esté preparado para actuar. • Documentación: • Mantén una documentación detallada de todos los riesgos identificados, evaluaciones, decisiones y estrategias implementadas. Esto es crucial para futuras referencias y auditorías. • Revisiones Post-Mortem: • Después de que un riesgo haya sido gestionado (o no), realiza revisiones post-mortem para aprender de la experiencia y mejorar el proceso para futuros proyectos. Estos elementos adicionales pueden ayudar a fortalecer el enfoque de gestión de riesgos y garantizar que el proyecto de software no solo sea funcional, sino también robusto y resiliente frente a posibles problemas.

19 19 Riesgos (4/26) Los riesgos pueden clasificarse generalmente en dos categorías principales: riesgos funcionales y riesgos técnicos. Ambos tipos de riesgos pueden impactar significativamente el éxito del proyecto, pero lo hacen de maneras diferentes y requieren enfoques distintos para su gestión. Riesgos Funcionales Los riesgos funcionales están relacionados con los requisitos funcionales del sistema. Estos riesgos pueden surgir de: • Cambios en los Requisitos: Los requisitos del sistema pueden cambiar durante el desarrollo, lo que puede llevar a que el sistema no cumpla con las expectativas del cliente o usuario final. • Requisitos No Claros o Ambiguos: La falta de claridad en los requisitos puede resultar en funcionalidades mal implementadas o en el desarrollo de características que no son necesarias. • Conflictos entre Requisitos: Diferentes partes interesadas pueden tener requisitos conflictivos que son difíciles de reconciliar. Relación con la Arquitectura de Software Los riesgos funcionales afectan la arquitectura del software indirectamente, ya que cualquier cambio o malentendido en los requisitos puede requerir modificaciones en el diseño arquitectónico. Una arquitectura bien diseñada debe ser lo suficientemente flexible para adaptarse a cambios en los requisitos sin una reestructuración significativa.

20 20 Riesgos (5/26) Riesgos Técnicos Los riesgos técnicos están relacionados con los aspectos técnicos y de implementación del sistema. Incluyen: • Problemas de Rendimiento: El sistema puede no cumplir con los requisitos de rendimiento bajo ciertas condiciones de carga. • Fallas en la Integración de Componentes: Los diferentes módulos del sistema pueden no integrarse correctamente. • Dependencia de Tecnologías Nuevas o No Probadas: Usar tecnologías nuevas o no probadas puede introducir incertidumbres sobre su funcionamiento y compatibilidad. • Escalabilidad y Mantenibilidad: La arquitectura puede no soportar el crecimiento futuro o ser difícil de mantener. Relación con la Arquitectura de Software Los riesgos técnicos están directamente relacionados con la arquitectura del software, ya que esta define la estructura y los componentes del sistema. Una arquitectura sólida debe abordar estos riesgos mediante el uso de patrones de diseño probados, la evaluación cuidadosa de tecnologías y la planificación para la escalabilidad y mantenibilidad.

21 21 Riesgos (6/26) Impacto en la Arquitectura de Software Ambos tipos de riesgos, funcionales y técnicos, impactan la arquitectura del software, aunque de diferentes maneras. La arquitectura debe ser diseñada para: • Flexibilidad y Adaptabilidad: Permitir cambios en los requisitos funcionales sin necesidad de una reestructuración completa. • Robustez Técnica: Minimizar los riesgos técnicos al utilizar componentes bien entendidos, patrones de diseño apropiados y estrategias de mitigación de riesgos. Consideración de Riesgos Funcionales y Técnicos en la Estimación • Riesgos Funcionales: • Impacto en la Estimación: La falta de claridad o cambios en los requisitos funcionales pueden llevar a subestimaciones o sobreestimaciones. • Mitigación: Para mitigar la falta de información funcional, es común tomar ciertas asunciones durante el proceso de estimación. Estas asunciones deben ser claramente documentadas y comunicadas a todas las partes interesadas. Esto ayuda a gestionar las expectativas y proporciona una base para ajustar la planificación a medida que se clarifican los requisitos.

22 22 Riesgos (7/26) • Riesgos Técnicos: • Impacto en la Estimación: Los riesgos técnicos, como la integración de nuevas tecnologías o problemas de rendimiento, pueden impactar la viabilidad técnica y el cronograma del proyecto. • Mitigación: Identificar y evaluar estos riesgos tempranamente permite desarrollar estrategias de mitigación, como la creación de prototipos, pruebas de concepto, o la selección de tecnologías probadas que minimicen la incertidumbre técnica. Estrategias para Mitigar Riesgos • Asunciones Claras: Documentar las asunciones relacionadas con los requisitos funcionales y técnicos es clave. Esto incluye supuestos sobre cómo se espera que funcione el sistema, las tecnologías que se utilizarán, y cualquier restricción conocida. • Comunicación Continua: Mantener una comunicación abierta y continua con los stakeholders para revisar y ajustar las estimaciones basadas en información más reciente o cambios en el proyecto. • Incrementalidad y Flexibilidad: Adoptar un enfoque incremental y flexible en el desarrollo, como metodologías ágiles, permite ajustar el rumbo del proyecto en respuesta a nueva información o cambios en los requisitos. • Prototipos y Pruebas de Concepto: Utilizar prototipos para validar suposiciones técnicas y funcionales antes de comprometerse completamente con una solución.

23 23 Riesgos (8/26) Nota del autor Cuando estoy en el proceso de estimar un proyecto, he aprendido que no es siempre la mejor estrategia presentar los riesgos directamente al cliente. La palabra "riesgo" puede sonar alarmante y podría hacer que el cliente se sienta inseguro o incluso desanimado respecto al proyecto. En cambio, prefiero hablar de "desafíos" o "consideraciones". Estas palabras son menos intimidantes y más constructivas, lo que ayuda a mantener la confianza del cliente en el proceso. Además, me aseguro de comunicar que hemos asumido ciertas premisas y condiciones iniciales para manejar estos desafíos. De esta manera, el cliente puede ver que tenemos la mayoría de las variables bajo control y que estamos preparados para manejar cualquier cambio o ajuste que pueda surgir durante el desarrollo del proyecto. Esta estrategia no solo ayuda a mantener al cliente tranquilo, sino que también fortalece nuestra relación de confianza, demostrando que somos capaces de gestionar el proyecto de manera competente y proactiva. Una cita que resuena con esa perspectiva es de Winston Churchill: "Un optimista ve una oportunidad en toda calamidad, un pesimista ve una calamidad en toda oportunidad." Destaca la importancia de adoptar una mentalidad positiva para transformar los riesgos en potenciales oportunidades. Y otra que refleja esta idea es de Sun Tzu, quien en "El Arte de la Guerra" dijo: "En medio del caos, también hay oportunidad." Subraya la noción de que, incluso en situaciones difíciles o inciertas, siempre existe la posibilidad de encontrar oportunidades valiosas. Demos la vuelta a los riesgos y convirtámoslos en oportunidades.

24 24 Riesgos (9/26) Identificación Una arquitecta de software tiene la responsabilidad de prever y catalogar posibles riesgos desde las etapas iniciales de un proyecto. Esto es crucial para garantizar que el sistema no solo cumpla con los requisitos actuales, sino que también sea robusto y adaptable frente a futuros desafíos. Aquí te explico cómo puede lograrse esto, incluyendo técnicas psicológicas y empíricas que pueden ayudar en este ámbito: Análisis de Amenazas El análisis de amenazas es una técnica sistemática que permite identificar y evaluar las posibles amenazas a las que un sistema podría estar expuesto. Esto puede incluir amenazas de seguridad, como vulnerabilidades a ataques cibernéticos, así como amenazas operativas, como fallos en la infraestructura. • Modelo STRIDE: Este modelo es útil para categorizar amenazas en términos de Spoofing (suplantación), Tampering (manipulación), Repudiation (repudio), Information disclosure (divulgación de información), Denial of service (denegación de servicio), y Elevation of privilege (elevación de privilegios).

25 25 Riesgos (10/26) Evaluación de Dependencias Tecnológicas Las dependencias tecnológicas pueden ser una fuente significativa de riesgo si no se gestionan adecuadamente. Un arquitecto debe evaluar cómo las tecnologías seleccionadas interactúan entre sí y con el entorno operativo existente. • Análisis de Impacto de Tecnología: Esta técnica implica evaluar cómo la elección de tecnologías afectará al sistema en su totalidad, considerando aspectos como la compatibilidad, la obsolescencia potencial y la curva de aprendizaje necesaria para el equipo. Revisión de la Compatibilidad del Sistema Asegurar que el nuevo sistema sea compatible con el entorno operativo existente es crucial para evitar problemas de integración y operativos. • Pruebas de Compatibilidad: Realizar pruebas en diferentes entornos para asegurar que el sistema funcione correctamente con el hardware y software existente.

26 26 Riesgos (11/26) Identificación Temprana de Riesgos Identificar riesgos de manera temprana permite diseñar soluciones que minimicen la exposición a estos riesgos. • Técnicas de Análisis de Riesgos: Métodos como el análisis FMEA (Failure Mode and Effects Analysis) ayudan a identificar posibles puntos de falla y sus impactos antes de que ocurran. Técnicas Psicológicas y Empíricas • Pensamiento Crítico: Fomentar un entorno de pensamiento crítico donde los arquitectos y el equipo sean incentivados a cuestionar y analizar las decisiones arquitectónicas desde múltiples perspectivas. • Heurísticas y Sesgos Cognitivos: Comprender las heurísticas y sesgos cognitivos que pueden influir en la toma de decisiones ayuda a mitigar el riesgo de decisiones erróneas basadas en suposiciones incorrectas. • Revisión por Pares: Involucrar a otros arquitectos o expertos para revisar las decisiones arquitectónicas puede proporcionar nuevas perspectivas y ayudar a identificar riesgos que una sola persona podría pasar por alto. • Prototipos y Pruebas de Concepto: Crear prototipos para validar ideas y suposiciones antes de implementar una solución completa. Esto permite iterar rápidamente y ajustar el diseño en base a pruebas empíricas.

27 27 Riesgos (12/26) La capacidad de las personas encargadas de la arquitectura del software para prever y gestionar riesgos es fundamental para el éxito de un proyecto. Al aplicar técnicas de análisis de amenazas, evaluar dependencias tecnológicas y utilizar metodologías tanto psicológicas como empíricas, pueden diseñar sistemas que no solo sean seguros y eficientes, sino también adaptables y preparados para el futuro. Esto maximiza la capacidad del sistema para evolucionar de manera segura en un entorno tecnológico en constante cambio. Para proyectos de menor escala, una sola persona puede ser suficiente para manejar estos aspectos. Sin embargo, en iniciativas de mayor envergadura, contar con un equipo es esencial. Al menos, se debe realizar una validación por pares, ya que, aunque puede ser costoso desde una perspectiva empresarial, varios ojos siempre logran mejores resultados. Además, un enfoque colaborativo permite a la empresa proveedora ofrecer un servicio de mayor calidad. Es importante, no obstante, dejar de lado los egos y fomentar un ambiente de trabajo en equipo para lograr el éxito del proyecto. Nota del autor Aunque la diversidad neuronal parece estar de moda, mi experiencia me indica que tiene un valor genuino en la identificación y gestión de riesgos. La diversidad neuronal, que incluye condiciones como el TOC (trastorno obsesivo-compulsivo) y las altas capacidades intelectuales, puede ser un activo valioso en este contexto. Las personas con altas capacidades a menudo tienen una habilidad excepcional para el pensamiento crítico y la resolución de problemas complejos, lo que es crucial para anticipar riesgos potenciales. Por otro lado, aquellos con TOC pueden ofrecer una atención meticulosa a los detalles, fundamental para detectar inconsistencias o vulnerabilidades que podrían pasar desapercibidas. Sin embargo, para maximizar estas fortalezas, es vital crear un entorno de trabajo inclusivo que apoye las necesidades individuales y permita que cada persona contribuya de manera efectiva. Al hacerlo, no solo se fomenta un equipo más cohesionado, sino que también se mejora la capacidad del grupo para identificar y mitigar riesgos de manera proactiva.

28 28 Riesgos (13/26) Evaluación La evaluación de riesgos es un proceso esencial en la arquitectura de software, que implica calcular tanto la probabilidad de ocurrencia como el impacto potencial de cada riesgo identificado. Este proceso es fundamental para asegurar que los sistemas sean robustos y capaces de cumplir con sus objetivos principales sin interrupciones significativas. Desde el punto de vista de la arquitectura de software, la evaluación de riesgos implica considerar cómo cada riesgo podría afectar la integridad, disponibilidad y confidencialidad del sistema. Estos tres aspectos son cruciales para garantizar que el sistema funcione correctamente, proteja los datos sensibles y esté disponible para los usuarios cuando sea necesario. • Integridad: Se refiere a la exactitud y consistencia de los datos y el funcionamiento del sistema. Un riesgo que podría comprometer la integridad incluiría la corrupción de datos o errores en la lógica del sistema. • Disponibilidad: Hace referencia a la capacidad del sistema para estar operativo y accesible cuando se necesite. Los riesgos aquí podrían incluir caídas del servidor, ataques de denegación de servicio o fallos de red. • Confidencialidad: Se centra en proteger la información sensible de accesos no autorizados. Los riesgos relacionados pueden incluir brechas de seguridad o accesos no autorizados a datos confidenciales.

29 29 Riesgos (14/26) Herramientas y Métodos de Evaluación • Matrices de Riesgo Las matrices de riesgo son una herramienta eficaz para priorizar los riesgos más críticos. Al clasificar los riesgos en función de su probabilidad e impacto, los arquitectos pueden identificar cuáles requieren atención inmediata y enfocar sus esfuerzos de mitigación en aquellos que podrían comprometer los objetivos principales del proyecto. • Técnicas Psicológicas • Pensamiento Crítico y Sesgos Cognitivos: Fomentar un entorno que promueva el pensamiento crítico ayuda a los arquitectos a evaluar riesgos de manera más objetiva y a reconocer sesgos cognitivos que podrían influir en sus juicios. Comprender cómo los sesgos pueden afectar la toma de decisiones permite adoptar medidas para mitigarlos. • Toma de Decisiones en Grupo: Involucrar a múltiples partes interesadas en el proceso de evaluación de riesgos puede proporcionar diferentes perspectivas y minimizar el riesgo de decisiones unilaterales. Esto también fomenta una cultura de colaboración y compromiso con los objetivos del proyecto.

30 30 Riesgos (15/26) • Técnicas Empíricas • Análisis de Datos Históricos: Revisar datos de proyectos anteriores puede ofrecer información valiosa sobre riesgos comunes y sus impactos. Esto permite a los arquitectos anticipar problemas similares y aplicar soluciones probadas. • Pruebas de Estrés y Simulaciones: Realizar pruebas de estrés y simulaciones para evaluar cómo el sistema maneja condiciones extremas ayuda a identificar puntos débiles que podrían ser explotados por riesgos potenciales. • Prototipos y Pruebas de Concepto: Desarrollar prototipos y realizar pruebas de concepto puede ser una forma efectiva de validar suposiciones y detectar riesgos antes de que el sistema completo esté implementado. Nota del autor La evaluación de riesgos en la arquitectura de software se beneficia enormemente de técnicas colaborativas y creativas que pueden ser difíciles de implementar de manera individual. Una de estas técnicas es el "brainstorming" en grupo, que fomenta la generación de ideas a partir de las perspectivas y experiencias diversas de los participantes. Esta técnica permite identificar riesgos que podrían no ser evidentes para una sola persona al aprovechar el conocimiento colectivo del equipo. Por otro lado, para aquellos momentos en los que se trabaja en solitario, existen métodos alternativos que pueden ser igualmente efectivos. Un ejemplo clásico es el uso del "patito de goma", donde se explica un problema en voz alta a un objeto inanimado para clarificar el pensamiento y descubrir posibles soluciones o riesgos ocultos. Sin embargo, muchos profesionales han comenzado a utilizar inteligencias artificiales privadas como una forma de realizar este ejercicio. Estas herramientas pueden ofrecer una perspectiva adicional y ayudar a evaluar riesgos de manera más estructurada. Para aquellos que no tienen acceso a una IA privada, una opción es ofuscar la información sensible al utilizar servicios públicos; aun así, mucho cuidado con los NDA.

31 31 Riesgos (16/26) Mitigación La mitigación de riesgos en la arquitectura de software es un proceso crítico que busca minimizar el impacto de eventos adversos mediante la implementación de estrategias efectivas. Esta mitigación implica abordar tanto las causas subyacentes de los riesgos como sus posibles efectos, asegurando que el sistema sea capaz de resistir y recuperarse de interrupciones sin afectar significativamente su operación. A modo de ejemplo, estas podrían ser algunas Estrategias de Mitigación de Riesgos • Patrones de Diseño Resilientes: Estos patrones están diseñados para aumentar la robustez del sistema. Ejemplos incluyen la arquitectura de microservicios, que permite aislar fallos en componentes individuales sin afectar al sistema completo, y el uso de circuit breakers, que previenen que fallos en un servicio se propaguen a otros. • Implementación de Redundancias: La redundancia implica tener sistemas o componentes de respaldo que pueden tomar el control en caso de fallos. Esto puede incluir servidores redundantes, copias de seguridad de datos en múltiples ubicaciones o redes alternativas para asegurar la conectividad. • Procedimientos de Recuperación ante Desastres: Estos procedimientos establecen un plan claro y probado para restaurar el sistema a su estado operativo normal después de un evento disruptivo. Incluyen la realización regular de simulacros de recuperación y la documentación de procesos para asegurar una respuesta rápida y eficaz.

32 32 Riesgos (17/26) Técnicas Psicológicas y Empíricas • Gestión del Estrés y la Toma de Decisiones: Durante situaciones críticas, la capacidad de manejar el estrés y tomar decisiones rápidas y efectivas es vital. Capacitar a los equipos en técnicas de gestión del estrés y en habilidades de toma de decisiones bajo presión puede mejorar significativamente la respuesta a eventos adversos. • Simulación de Escenarios: La simulación de escenarios es una técnica psicológica que ayuda a los equipos a prepararse mentalmente para diversas situaciones de riesgo. Al practicar respuestas a diferentes escenarios, los equipos pueden mejorar su confianza y eficacia en situaciones reales. Como veis, no solo va de automatismos si no de como responden las personas de operaciones ante un riesgo. • Análisis de Datos y Retroalimentación Continua: Implementar un sistema de monitoreo que recoja datos sobre el rendimiento del sistema y los eventos de fallo puede proporcionar información valiosa para ajustar y mejorar las estrategias de mitigación. • Pruebas de Resiliencia: Las pruebas de resiliencia, como las "pruebas de caos", consisten en introducir deliberadamente fallos en el sistema para evaluar su capacidad de recuperación. Esto permite identificar debilidades y ajustar las estrategias de mitigación antes de que ocurran fallos reales.

33 33 Riesgos (18/26) Pero desde mi punto de vista una parte crucial de este proceso es entender la diferencia entre enfoques proactivos y reactivos, y cómo ambos pueden integrarse para mejorar la gestión de riesgos. Enfoque Proactivo La proactividad en la gestión de riesgos implica anticiparse a los posibles problemas antes de que ocurran. Este enfoque se centra en la prevención y en la preparación, asegurando que se disponga de estrategias y recursos para abordar los riesgos potenciales de manera efectiva. Un buen arquitecto debe ser proactivo y haber planteado desde el principio arquitecturas que puedan adoptar este enfoque, aunque lógicamente existirán siempre acciones reactivas, no se puede tener todo controlado, como veremos en el siguiente punto. • Análisis de Riesgos Previo: Realizar un análisis exhaustivo de riesgos al inicio del proyecto ayuda a identificar posibles amenazas y planificar en consecuencia. Esto incluye la recopilación y análisis de datos históricos, la identificación de patrones y la evaluación de la probabilidad e impacto de cada riesgo. • Desarrollo de Estrategias de Mitigación: Con la información recopilada, se pueden desarrollar estrategias de mitigación específicas para cada riesgo identificado. Esto podría incluir la implementación de patrones de diseño resilientes, como la arquitectura de microservicios, y la creación de redundancias para asegurar la continuidad del servicio.

34 34 Riesgos (19/26) • Simulacros y Pruebas: La realización regular de simulacros de recuperación y pruebas de estrés prepara al equipo y al sistema para manejar situaciones adversas. Practicar escenarios de riesgo ayuda a mejorar la confianza y la habilidad del equipo para responder de manera efectiva. Enfoque Reactivo Por otro lado, la reactividad se refiere a la capacidad de responder eficazmente cuando ocurre un evento adverso. Aunque la proactividad es clave, no todos los riesgos pueden preverse, por lo que es igualmente importante estar preparado para reaccionar adecuadamente. • Monitoreo Continuo: Un sistema de monitoreo eficaz proporciona alertas tempranas sobre cualquier anomalía o fallo, permitiendo al equipo responder rápidamente. La recolección continua de datos sobre el rendimiento del sistema ayuda a ajustar y mejorar las estrategias de mitigación de manera dinámica. • Adaptación Rápida: La capacidad de adaptarse rápidamente a nuevas circunstancias es esencial. Esto implica tener procedimientos claros de recuperación ante desastres y la habilidad de modificar estrategias en tiempo real según sea necesario. • Retroalimentación y Mejora Continua: Después de un evento adverso, es fundamental realizar una revisión detallada para entender qué sucedió y cómo se manejó. Esta retroalimentación permite refinar las estrategias de mitigación y mejorar la preparación para futuros eventos.

35 35 Riesgos (20/26) Integración de Proactividad y Reactividad La combinación de enfoques proactivos y reactivos proporciona una estrategia de mitigación de riesgos más completa. Al anticiparse a los riesgos y estar preparados para responder eficazmente cuando ocurren, los equipos pueden asegurar que la arquitectura del software sea robusta y adaptable, minimizando interrupciones y manteniendo la confianza del usuario. Este equilibrio es crucial para manejar la incertidumbre y garantizar el éxito a largo plazo de los sistemas de software. Ejemplo de Proactividad y Reactividad en Software con Mitigación de Riesgos • Proactividad → Diseño Modular y Desacoplado. Mitigación de Riesgos: Al anticipar cambios futuros, el diseño modular reduce el riesgo de fallos generalizados. Si se introduce un error en una nueva funcionalidad, el impacto se aísla a un solo módulo, minimizando el riesgo de que el fallo afecte al sistema completo. • Reactividad → Manejo de Excepciones y Errores. Mitigación de Riesgos: Implementar un sistema de logging y alertas para las excepciones permite identificar rápidamente la causa raíz de un error. Esto permite mitigar el riesgo de pérdida de datos o de servicios críticos, ya que las respuestas pueden ser rápidas y efectivas. Ejemplo de Proactividad y Reactividad en Datos con Mitigación de Riesgos • Proactividad → Modelo de Datos Flexible. Mitigación de Riesgos: Un modelo de datos flexible mitiga el riesgo de rigidez en el sistema, permitiendo adaptaciones rápidas a cambios en los requisitos de negocio sin comprometer la integridad de los datos o la continuidad del servicio. • Reactividad → Monitoreo y Respuesta a Anomalías. Mitigación de Riesgos: Al detectar anomalías en tiempo real, se mitiga el riesgo de que problemas de datos pasen desapercibidos y causen daños mayores. La capacidad de reaccionar rápidamente a las alertas de anomalías permite la intervención temprana, evitando la corrupción de datos y pérdidas significativas.

36 36 Riesgos (21/26) Ejemplo de Proactividad y Reactividad en Infraestructura con Mitigación de Riesgos • Proactividad → Infraestructura como Código (IaC)- Mitigación de Riesgos. La IaC minimiza el riesgo de errores humanos en la configuración manual y asegura que los entornos sean replicables y consistentes. Esto reduce el riesgo de fallos operativos debidos a configuraciones incorrectas. • Reactividad → Escalado Automático. Mitigación de Riesgos: Las políticas de escalado automático mitigan el riesgo de indisponibilidad del sistema durante picos de carga inesperados. Al escalar automáticamente, se asegura que el sistema mantenga su rendimiento y disponibilidad, reduciendo el riesgo de pérdida de clientes o ingresos. Integración de Mitigación de Riesgos en Proactividad y Reactividad La clave para una mitigación de riesgos efectiva en la arquitectura de software es la integración de prácticas proactivas y reactivas. La proactividad asegura que el sistema esté diseñado desde el principio para minimizar riesgos, mientras que la reactividad garantiza que el sistema pueda adaptarse y responder a problemas que no pudieron ser anticipados. Al adoptar un enfoque balanceado, las organizaciones pueden proteger sus sistemas contra una amplia gama de riesgos, asegurando robustez, fiabilidad y continuidad operativa. Este enfoque integral no solo mejora la resiliencia del sistema, sino que también aumenta la confianza de los stakeholders en la capacidad del sistema para manejar situaciones adversas.

37 37 Riesgos (22/26) Monitoreo Dado que los riesgos pueden evolucionar a lo largo del ciclo de vida de un proyecto, es crucial que los arquitectos de software mantengan un monitoreo continuo de los riesgos identificados y de cualquier nuevo riesgo que pueda surgir. Este enfoque proactivo y reactivo permite ajustar las estrategias de mitigación para asegurar que la arquitectura del sistema siga siendo robusta y adaptable en un entorno en constante cambio. Monitoreo Continuo de Riesgos Revisión Regular de Métricas del Sistema: • Proactividad: Establecer un conjunto de métricas clave que reflejen la salud y el rendimiento del sistema es fundamental. Estas métricas pueden incluir tiempos de respuesta, tasas de error, uso de recursos y niveles de tráfico. Revisarlas regularmente ayuda a anticipar problemas antes de que se conviertan en críticos, lo que permite planificar mejoras de manera preventiva. • Reactividad: Cuando las métricas indican una anomalía o un problema, la capacidad de respuesta rápida es esencial. Esto implica tener sistemas de alertas que notifiquen inmediatamente a los equipos, permitiendo una intervención rápida para mitigar cualquier impacto negativo.

38 38 Riesgos (23/26) Pruebas de Carga y Estrés: • Proactividad: Realizar pruebas de carga y estrés de manera periódica permite evaluar cómo el sistema maneja condiciones extremas y anticipar problemas antes de que ocurran en un entorno de producción. Al identificar cuellos de botella de manera anticipada, se pueden implementar mejoras antes de que los usuarios finales experimenten problemas. • Reactividad: En caso de que las pruebas revelen vulnerabilidades o fallos, una respuesta rápida para ajustar configuraciones y optimizar recursos es crucial. Esto asegura que el sistema esté siempre preparado para condiciones de carga variables. Actualización de Planes de Mitigación: • Proactividad: A medida que se identifican nuevos riesgos o cambian las condiciones del entorno, es vital actualizar los planes de mitigación. Esto implica ajustar las estrategias existentes y, si es necesario, desarrollar nuevas soluciones para abordar riesgos emergentes antes de que se conviertan en problemas reales. • Reactividad: Cuando un riesgo se materializa, la habilidad de rápidamente implementar un plan de mitigación actualizado minimiza el impacto. Esto requiere que los equipos estén bien entrenados y que los procesos de actualización de planes sean ágiles.

39 39 Riesgos (24/26) Técnicas Psicológicas y Empíricas • Cultura de Vigilancia y Adaptación (proactividad): Fomentar una cultura de vigilancia constante y disposición para adaptarse es crucial. Esto implica capacitar a los equipos para estar atentos a las señales de advertencia y fomentar un entorno donde se valore la comunicación abierta sobre posibles problemas o riesgos. • Mindfulness y Atención Plena (reactividad): La práctica de mindfulness ayuda a los equipos a mantener la concentración y la calma en situaciones de alta presión, mejorando la capacidad de detectar y responder a los riesgos de manera efectiva. Análisis Predictivo (proactividad): Utilizar técnicas de análisis predictivo puede proporcionar una visión anticipada de cómo podrían evolucionar los riesgos. Al analizar datos históricos y patrones de comportamiento, se pueden predecir posibles problemas y prepararse para ellos. • Retrospectivas y Aprendizaje Continuo (reactividad): Realizar retrospectivas regulares permite a los equipos reflexionar sobre experiencias pasadas, identificar lecciones aprendidas y aplicarlas a futuras evaluaciones de riesgo. Este proceso de aprendizaje continuo mejora la capacidad de respuesta del equipo ante nuevos desafíos. El monitoreo continuo de riesgos es un componente esencial para mantener la resiliencia de la arquitectura de software. Al integrar prácticas proactivas, como la revisión de métricas y el análisis predictivo, junto con enfoques reactivos, como la implementación rápida de planes de mitigación y la respuesta a alertas de anomalías, los arquitectos pueden asegurar que el sistema siga siendo robusto y adaptable frente a cambios constantes. Este enfoque balanceado no solo protege la integridad del sistema, sino que también fomenta una cultura de mejora continua y adaptación dentro de la organización.

40 40 Riesgos (25/26) Al adoptar una estrategia que equilibre la proactividad y la reactividad, las organizaciones están mejor equipadas para enfrentar tanto los riesgos anticipados como los imprevistos. La proactividad permite preparar el terreno para futuros desafíos, mientras que la reactividad asegura que, cuando surjan problemas, se puedan abordar de manera eficaz y eficiente. Este enfoque integral es vital en un entorno tecnológico que evoluciona rápidamente, donde la capacidad para adaptarse y responder a nuevas circunstancias puede ser la diferencia entre el éxito y el fracaso. Al combinar técnicas psicológicas y empíricas con un monitoreo continuo y una actualización constante de estrategias, los equipos pueden mantener la resiliencia y la sostenibilidad del sistema a lo largo de su ciclo de vida. Nota del autor Al diseñar la arquitectura de software, me aseguro de aplicar patrones tanto de infraestructura como de datos y software. Casi todo ya está inventado, y seguir buenas prácticas nos proporciona opciones claras de mitigación de riesgos. No se trata de reinventar la rueda, sino de mantener todo lo más sencillo posible. Esto facilita el trabajo a cualquier persona que se integre al proyecto después de mí y evita la generación de riesgos que difícilmente se puedan mitigar si se ignoran estos estándares. De lo contrario, llega el momento en que toca refactorizar y desechar todo porque no se pensó de manera evolutiva en la arquitectura. Y para finalizar, existe un riesgo ampliamente reconocido que no puedo dejar de mencionar: al intentar acelerar un proyecto de software retrasado mediante la incorporación de más personal, se puede generar el efecto opuesto al deseado. Este fenómeno, conocido como la Ley de Brooks, indica que añadir más personas a un proyecto en demora puede aumentar la complejidad y la necesidad de comunicación, lo que a menudo resulta en mayores retrasos. A pesar de estar bien documentada, esta lección sigue siendo frecuentemente ignorada, causando que los proyectos se retrasen aún más. Es crucial identificar y mitigar este riesgo desde el principio.

41 41 Riesgos (26/26) De ahora en adelante: consideraciones o desafíos

42 42 Ejemplo Práctico: Gestionar los Desafíos (1/4) e2e Os presento un ejemplo práctico y completo de gestión de riesgos (permitirme que use esta palabra prohibida) en un proyecto de desarrollo de software end-to-end. Supongamos que estás desarrollando una aplicación móvil de comercio electrónico. Aquí te muestro cómo podrías gestionar los riesgos desde el inicio hasta la finalización del proyecto. Fase 1: Iniciación del Proyecto Identificación de Riesgos: • Riesgo Técnico: La aplicación podría no ser compatible con las últimas versiones de los sistemas operativos móviles. • Riesgo de Requisitos: Cambios en los requisitos del cliente a mitad del desarrollo. • Riesgo de Seguridad: Posibles vulnerabilidades en la gestión de datos personales. Estrategias de Mitigación: • Compatibilidad: Implementar pruebas de compatibilidad desde el inicio y usar herramientas de desarrollo multiplataforma. • Gestión de Cambios: Establecer un proceso claro para la gestión de cambios de requisitos, incluyendo revisiones y aprobaciones. • Seguridad: Realizar análisis de seguridad desde las primeras etapas del desarrollo y aplicar prácticas de codificación segura.

43 43 Ejemplo Práctico: Gestionar los Desafíos (2/4) Fase 2: Planificación Evaluación de Riesgos: • Impacto y Probabilidad: Evaluar la gravedad y la probabilidad de cada riesgo identificado. • Priorización: Utilizar una matriz de riesgos para priorizar la atención en los riesgos más críticos. Planificación de Contingencias: • Plan de Contingencia para Cambios de Requisitos: Asignar un porcentaje del tiempo y presupuesto del proyecto para gestionar cambios imprevistos. • Plan de Respuesta a Incidentes de Seguridad: Implementar un protocolo de respuesta rápida para mitigar cualquier violación de seguridad. Fase 3: Desarrollo Monitoreo de Riesgos: • Revisiones Regulares: Implementar revisiones de riesgos semanales para evaluar nuevos riesgos o cambios en los existentes. • Pruebas de Integración Continua: Realizar pruebas automáticas cada vez que se integre un nuevo componente al sistema.

44 44 Ejemplo Práctico: Gestionar los Desafíos (3/4) Gestión de Riesgos Ocultos: • Evaluación de Dependencias: Revisar regularmente las bibliotecas y servicios de terceros para identificar posibles problemas de compatibilidad o seguridad. • Simulación de Carga: Realizar pruebas de carga para identificar cuellos de botella en el rendimiento. Fase 4: Implementación Ejecución de Estrategias de Mitigación: • Despliegue Gradual: Implementar la aplicación en fases para controlar mejor los riesgos y obtener retroalimentación temprana. • Redundancia de Sistemas: Asegurar que haya redundancia en los servidores y bases de datos para evitar caídas del sistema. Revisión y Ajuste: • Evaluación Post-Despliegue: Realizar una revisión exhaustiva para identificar cualquier riesgo que se haya materializado y ajustar las estrategias de mitigación en consecuencia. • Documentación de Lecciones Aprendidas: Documentar los riesgos encontrados y las soluciones implementadas para mejorar futuros proyectos.

45 45 Ejemplo Práctico: Gestionar los Desafíos (4/4) Fase 5: Mantenimiento Monitoreo Continuo: • Actualizaciones de Seguridad: Mantener las actualizaciones de seguridad y parches al día para proteger contra nuevas vulnerabilidades. • Revisión de Métricas: Revisar regularmente las métricas de rendimiento y seguridad para identificar posibles riesgos emergentes. Mejora Continua: • Feedback de Usuarios: Recoger feedback de los usuarios para identificar áreas de mejora en la aplicación. • Adaptación a Cambios del Mercado: Mantenerse informado sobre cambios en el mercado o nuevas regulaciones que puedan afectar el proyecto. Nota del autor En mi experiencia, la mejora continua y el agilismo son esenciales para una gestión efectiva de riesgos en proyectos de software. La mejora continua permite a los equipos identificar y abordar riesgos de manera proactiva, aprendiendo de errores pasados para evitar su repetición. El agilismo, con su enfoque en ciclos cortos de entrega y retroalimentación constante, facilita la detección temprana de riesgos y la implementación rápida de estrategias de mitigación. Juntos, estos enfoques crean un entorno donde los riesgos se gestionan de manera dinámica y eficiente, minimizando su impacto potencial en el proyecto.

46 46 Estimaciones (1/36) La Importancia de las Estimaciones Son fundamentales para planificar, tomar decisiones informadas y gestionar recursos, tiempo y presupuesto de manera efectiva. Una estimación precisa y bien fundamentada no solo establece las expectativas del proyecto, sino que también facilita una gestión de riesgos efectiva al anticipar y mitigar posibles desviaciones. Las Estimaciones ayudan a: Planificación de Recursos • Determinación de Necesidades: Las estimaciones permiten determinar qué recursos son necesarios en cada etapa del proyecto, incluyendo la cantidad de personal, las habilidades específicas requeridas y las herramientas o tecnologías a utilizar. • Disponibilidad y Asignación Efectiva: Una estimación precisa asegura que los recursos estén disponibles cuando se necesiten, evitando retrasos costosos y garantizando que el personal esté correctamente asignado a las tareas según sus habilidades. Planificación de Recursos Gestión del Tiempo Presupuestos y Costos

47 47 Estimaciones (2/36) Gestión del Tiempo • Desarrollo de Cronogramas Realistas: Estimar el tiempo necesario para completar cada tarea es esencial para desarrollar un cronograma realista. Esto implica identificar el camino crítico, gestionar dependencias entre tareas y establecer hitos clave. • Cumplimiento de Plazos: Las estimaciones ayudan a mantener el proyecto en marcha, asegurando que se cumplan los plazos establecidos y se minimicen las interrupciones. Presupuesto y Costos • Asignación de Presupuesto Adecuado: Las estimaciones financieras permiten asignar un presupuesto adecuado para cada fase del proyecto, incluyendo costos de personal, licencias de software, infraestructura y otros gastos operativos. • Viabilidad Financiera: Un presupuesto bien estimado ayuda a evitar sobrecostos y asegura la viabilidad financiera del proyecto.

48 48 Estimaciones (3/36) Relación entre Estimaciones Precisas y la Gestión Efectiva de Riesgos Identificación de Riesgos Potenciales • Detección de Discrepancias: Estimaciones precisas ayudan a identificar discrepancias entre los recursos disponibles y los requeridos, o entre el tiempo planificado y el necesario, que son indicativos de riesgos potenciales, como incumplimiento de plazos o exceso de presupuesto. Mitigación Proactiva • Anticipación de Problemas: Con estimaciones precisas, los equipos pueden anticipar cuellos de botella y otros problemas antes de que ocurran, implementando medidas preventivas. • Reasignación de Recursos: Si se estima que una tarea crítica tomará más tiempo del esperado, se pueden reasignar recursos adicionales para asegurar su finalización a tiempo.

49 49 Estimaciones (4/36) Ajuste de Estrategias de Mitigación • Reevaluación Continua: A medida que el proyecto avanza, las estimaciones iniciales pueden requerir ajustes debido a cambios en el alcance o nueva información, permitiendo ajustar las estrategias de mitigación de riesgos. Mejora Continua • Aprendizaje de Experiencias Pasadas: Las lecciones aprendidas de las estimaciones pasadas proporcionan información valiosa para mejorar la precisión de futuras estimaciones, fomentando una cultura de mejora continua y reduciendo la incertidumbre. Las estimaciones son una piedra angular en la planificación y ejecución de proyectos de software. No solo facilitan la gestión eficiente de recursos, tiempo y presupuesto, sino que también son fundamentales para una gestión de riesgos efectiva. Proporcionan una visión clara y realista del proyecto, permitiendo a los equipos tomar decisiones informadas, anticiparse a los desafíos y asegurar el éxito del proyecto. Además, el uso de técnicas (que veremos más adelante) en la arquitectura del software puede mejorar significativamente la precisión de las estimaciones, facilitando una colaboración más efectiva y una planificación más estratégica. Al integrar estas prácticas en el ciclo de vida del proyecto, los equipos pueden mejorar continuamente sus procesos y minimizar la incertidumbre, lo que lleva a proyectos más exitosos y sostenibles.

50 50 Estimaciones (5/36) Métodos de Estimación Existen varios métodos de estimación, con sus propias ventajas y limitaciones. A continuación, los tres enfoques comunes: Estimación Comparativa • Uso de Proyectos Anteriores como Referencia: • Este método se basa en la experiencia de proyectos previos similares para estimar el esfuerzo, el tiempo y el costo del proyecto actual. Al comparar el nuevo proyecto con proyectos anteriores que comparten características similares, como el tamaño, la complejidad o el dominio, se pueden realizar estimaciones más fundamentadas. • Ventajas: • Rapidez: Al aprovechar datos históricos, las estimaciones pueden generarse rápidamente sin necesidad de un análisis exhaustivo desde cero. • Contexto Realista: Ofrece una visión más realista basada en experiencias pasadas, lo que puede ser más convincente para las partes interesadas. • Limitaciones: • Dependencia de Datos Históricos: Requiere un historial de proyectos bien documentado y comparable, lo cual no siempre está disponible. • Variabilidad del Proyecto: Las diferencias específicas entre proyectos pueden llevar a estimaciones inexactas si no se consideran adecuadamente.

51 51 Estimaciones (6/36) Estimación Basada en Modelos • Uso de Modelos Matemáticos para Estimar Tamaño y Esfuerzo: • Este enfoque utiliza modelos matemáticos y estadísticos para estimar el tamaño y el esfuerzo del proyecto. Los modelos pueden basarse en métricas como líneas de código (LOC) o puntos de función, que cuantifican el tamaño del software. • Técnicas como Puntos de Función: • Puntos de Función: Esta técnica mide la funcionalidad del software desde la perspectiva del usuario final, considerando entradas, salidas, consultas, archivos e interfaces externas. Es particularmente útil para estimar el tamaño de proyectos orientados a datos o transacciones. • Ventajas: Proporciona una medida objetiva y estandarizada que es independiente de la tecnología utilizada. • Limitaciones: Requiere un análisis detallado de los requisitos y puede ser complejo de aplicar en etapas tempranas del proyecto. Nota del autor Personalmente, el uso de métricas como las Líneas de Código (LOC) no me parece ni interesante ni decisivo. Aunque históricamente se han utilizado como una métrica básica, considero que son demasiado dependientes del lenguaje de programación y la habilidad del desarrollador, lo que las hace imprecisas y propensas a generar falsas correlaciones entre tamaño y esfuerzo. Además, enfocarse en LOC puede incentivar prácticas ineficientes como la producción de código innecesariamente extenso. Tom DeMarco, reconocido autor, expresó una crítica similar en su clásico "Controlling Software Projects": "You can't control what you can't measure, but not everything that can be measured is worth controlling."(No puedes controlar lo que no puedes medir, pero no todo lo que puede medirse vale la pena controlar). DeMarco destaca que métricas como LOC pueden ser un indicador fácil de medir, pero no necesariamente útil o relevante para los objetivos del proyecto. La funcionalidad, calidad, y experiencia del usuario son aspectos más críticos que no se reflejan en la simple cuenta de líneas de código.

52 52 Estimaciones (7/36) Estimación por Descomposición • Desglosar el Proyecto en Tareas Más Pequeñas y Manejables: • Este método implica dividir el proyecto en componentes o tareas más pequeñas, estimando cada una por separado (es buena idea usar el método de los pesos) y luego sumando las estimaciones para obtener una visión completa del proyecto. • Beneficios: • Mayor Precisión: Las estimaciones para tareas más pequeñas tienden a ser más precisas, ya que es más fácil evaluar el esfuerzo necesario para completar componentes específicos. • Facilita la Asignación de Recursos: Permite una asignación más detallada de recursos, ya que se entiende mejor qué se necesita en cada etapa. • Retos: • Desglose Incompleto: Si el desglose no es lo suficientemente detallado, se pueden pasar por alto tareas importantes, lo que lleva a subestimaciones. • Consumo de Tiempo: La descomposición y estimación detallada puede ser un proceso largo y laborioso, especialmente para proyectos grandes y complejos. Cada método de estimación tiene su lugar y aplicabilidad dependiendo de las características del proyecto y de la experiencia del equipo. Muchas veces, se utilizan enfoques híbridos, combinando varios métodos para mejorar la precisión de las estimaciones. La elección del método adecuado es crucial para una planificación efectiva y una gestión

53 53 Estimaciones (8/36) Además de los métodos de estimación anteriores, existen otras técnicas que se utilizan en la planificación y ejecución de proyectos de software. A continuación, te presento algunas de ellas: Estimación Delphi • Proceso Iterativo: Un grupo de expertos realiza estimaciones de forma anónima. Después de cada ronda, los resultados se comparten con el grupo y se discuten, permitiendo ajustes en las estimaciones hasta alcanzar un consenso. • Ventajas: Reduce el sesgo individual y promueve la discusión colaborativa para mejorar la precisión. • Limitaciones: Puede ser un proceso lento y requiere la participación de expertos con experiencia relevante. Método de COCOMO (Constructive Cost Model) • Modelo Algorítmico: Utiliza una fórmula basada en el tamaño del software (en líneas de código o puntos de función) y factores de coste para estimar el esfuerzo, el tiempo y el personal necesario. • Ventajas: Basado en datos históricos y permite una adaptación a diferentes tipos de proyectos. • Limitaciones: Requiere la calibración del modelo con datos relevantes para obtener estimaciones precisas.

54 54 Estimaciones (9/36) Estimación por Juicio de Expertos • Opinión Informada: Utiliza la experiencia y el conocimiento de expertos en el dominio para proporcionar estimaciones basadas en su juicio. • Ventajas: Puede ser rápido y aprovechar la experiencia acumulada. • Limitaciones: Subjetivo y puede estar influenciado por el sesgo personal o falta de datos objetivos. Simulación de Monte Carlo • Análisis Estadístico: Utiliza simulaciones para modelar el comportamiento incierto de las variables de entrada y generar una distribución de posibles resultados. • Ventajas: Proporciona un rango de estimaciones y probabilidades, lo que ayuda en la gestión de riesgos. • Limitaciones: Requiere un conocimiento detallado de las distribuciones de probabilidad de las variables de entrada.

55 55 Nota del autor Debo mencionar que, aunque estoy familiarizado con los modelos de estimación como Monte Carlo y COCOMO, no tengo experiencia práctica en su aplicación en el desarrollo de software. Sin embargo, cuento con experiencia en el ámbito estadístico, lo que me permite comprender cómo estos modelos pueden ser útiles para prever costos y tiempos basados en datos históricos y simulaciones. En este contexto, intentaré mostrar cómo enfoques como Monte Carlo y herramientas como ML.NET pueden aportar valor. Ejemplo personal que realicé en la época del boom de Facebook usando Monte Carlo: Contexto: Se deseaba estimar el tiempo de desarrollo para una nueva aplicación de Facebook que permitiera crear y compartir eventos. Paso 1: Identificación de Variables Clave: Interfaz de usuario, Integración con la API de Facebook y Pruebas más correcciones. Paso 2: Asignación de Distribuciones de Probabilidad: • Interfaz de usuario: Normal (media: 4 semanas, desviación estándar: 1 semana) • Integración con API: Triangular (mínimo: 1 semana, más probable: 2 semanas, máximo: 4 semanas) • Pruebas y correcciones: Uniforme (2 a 5 semanas) Paso 3: Simulación de Monte Carlo: Ejecutar miles de iteraciones seleccionando valores aleatorios para cada variable según su distribución y suma los tiempos. Paso 4: Análisis de Resultados: La simulación muestra, por ejemplo, un 90% de probabilidad de completar el desarrollo en 10 a 15 semanas. Paso 5: Toma de Decisiones: Usa los resultados para ajustar recursos o cronogramas y mitigar riesgos. Por otro lado, he tenido la oportunidad de utilizar el método Delphi en estudios estadísticos (vida real), donde ha demostrado ser una herramienta valiosa. Por ejemplo, en el pasado, coordiné un panel de expertos para estimar las tendencias futuras del mercado tecnológico. Utilizamos el método Delphi para reunir opiniones de manera anónima, permitiendo a cada experto revisar y ajustar sus estimaciones en rondas sucesivas tras recibir retroalimentación del grupo. Este enfoque colaborativo no solo mejoró la precisión de nuestras previsiones, sino que también fomentó un consenso bien fundamentado entre los participantes. Esta experiencia me ha mostrado el poder del método Delphi para sintetizar el conocimiento colectivo en situaciones de alta incertidumbre. Estimaciones (10/36)

56 56 Estimaciones (11/36) Y luego están los framework o marcos de referencia ISO/IEC 12207 y TOGAF, que no son métodos de estimación en sí mismos, pero pueden contribuir indirectamente a mejorar la estimación en proyectos de software de las siguientes maneras: • Estructuración de Procesos (ISO/IEC 12207): Este estándar integra las actividades de estimación en el ciclo de vida del proyecto, facilitando la recopilación de datos históricos para mejorar futuras estimaciones. • Estándares y Consistencia (TOGAF): Proporciona un enfoque estandarizado para la arquitectura empresarial, asegurando un lenguaje común y una metodología uniforme para realizar estimaciones coherentes. • Alineación Estratégica: Ambos marcos alinean los proyectos de software con los objetivos estratégicos, permitiendo establecer estimaciones que reflejen adecuadamente los recursos y el esfuerzo necesarios. • Mejora Continua (ISO/IEC 12207): Fomenta la evaluación y ajuste de prácticas de estimación, refinando técnicas para reducir incertidumbres en futuros proyectos. • Gestión de Riesgos (TOGAF): Incluye la gestión de riesgos para identificar y mitigar factores que puedan afectar las estimaciones, mejorando su precisión y fiabilidad. Aunque estos marcos no proporcionan técnicas específicas de estimación, crean un entorno organizacional y de procesos que apoya y mejora la capacidad de estimar de manera más precisa y eficiente en proyectos de software.

57 57 Estimaciones (12/36) Actualmente, me atrevo a decir, que uno de los enfoques más novedosos y emergentes en estimación es el uso de aprendizaje automático (machine learning - ML) y análisis de datos avanzados. Aquí te explico cómo funciona: Estimación Basada en Aprendizaje Automático 1. Recolección de Datos: Se recopilan grandes volúmenes de datos históricos de proyectos de software, incluyendo tiempos de desarrollo, costos, complejidad, tamaño del equipo, y tecnologías utilizadas. 2. Entrenamiento de Modelos: Se utilizan algoritmos de aprendizaje automático para entrenar modelos predictivos con estos datos. Los modelos identifican patrones y relaciones complejas que influyen en la duración y costo de los proyectos. 3. Predicción: Para un nuevo proyecto, se ingresan características relevantes (como tipo de aplicación, lenguajes de programación, y tamaño del equipo) en el modelo, que genera estimaciones basadas en patrones aprendidos. 4. Retroalimentación Continua: A medida que se completan más proyectos, los datos se utilizan para refinar y mejorar continuamente la precisión de los modelos.

58 58 Estimaciones (13/36) Ventajas del Enfoque de Aprendizaje Automático • Precisión Mejorada: Puede ofrecer estimaciones más precisas al aprovechar grandes volúmenes de datos y detectar patrones no evidentes para los humanos. • Adaptabilidad: Se adapta rápidamente a nuevas tecnologías y cambios en las prácticas de desarrollo. • Automatización: Reduce la dependencia de la subjetividad humana y agiliza el proceso de estimación. Consideraciones • Aunque prometedor, este enfoque requiere una cantidad significativa de datos de calidad. • Y para que veáis que no me lo estoy inventado, ya existen algunos artículos como este en la red: Applying Machine Learning to Estimate the Effort and Duration of Individual Tasks in Software Projects. Nota del autor En mi experiencia, los enfoques top-down y bottom-up se complementan eficazmente en la estimación de proyectos de software. Comienzo con el enfoque top-down para establecer una visión general y rápida del proyecto, utilizando datos de proyectos anteriores o modelos matemáticos para obtener estimaciones iniciales. Luego, aplico el enfoque bottom-up para desglosar el proyecto en tareas más pequeñas y ajustar las estimaciones con detalles concretos, lo que permite una mayor precisión. Esta combinación es especialmente útil al integrarse con métodos de estimación clásicos, como la comparativa, la basada en modelos y la descomposición, logrando así un equilibrio entre la visión general y el análisis detallado para mejorar la planificación y ejecución del proyecto.

59 59 Otra idea fundamental del libro es: "The cone of uncertainty narrows as a project progresses" (El cono de incertidumbre se reduce a medida que avanza el proyecto). Este principio enfatiza que, al inicio de un proyecto, las estimaciones son menos precisas debido a las muchas incógnitas presentes. Sin embargo, a medida que el proyecto avanza y se obtiene más información, las estimaciones pueden ajustarse con mayor precisión. Un ejemplo claro es la métrica de un equipo Agile a la hora de estimar. Finalmente, una de mis frases favoritas del libro es: "If a project has never been done before, why should it be easy to estimate?" (Si un proyecto nunca se ha hecho antes, ¿por qué debería ser fácil estimarlo?). Esta frase refleja, de manera irónica, la expectativa poco realista de que los equipos de desarrollo puedan generar estimaciones precisas para proyectos que, por definición, están llenos de incertidumbre y novedades. Estimaciones (14/36) Recomiendo encarecidamente la lectura de "Software Estimation: Demystifying the Black Art" de Steve McConnell, un libro que ofrece ideas valiosas sobre la estimación en proyectos de software. Una de las frases más destacadas es: "Estimations are not commitments" (Las estimaciones no son compromisos). Esta afirmación subraya la importancia de diferenciar entre estimar el esfuerzo o tiempo necesario para completar un proyecto y comprometerse a un plazo fijo. Las estimaciones son proyecciones basadas en datos y están sujetas a incertidumbre, mientras que los compromisos deben considerar factores adicionales, como márgenes de seguridad y planificación estratégica.

60 60 Estimaciones (15/36) Mejores Prácticas La estimación eficaz es un proceso iterativo y adaptativo que evoluciona a lo largo del ciclo de vida del proyecto. Implementar mejores prácticas en la estimación no solo mejora la precisión, sino que también facilita la toma de decisiones informadas y la gestión proactiva del proyecto. La Importancia de la Recalibración de Estimaciones a Medida que se Obtiene Más Información • Iteración Continua: A medida que se avanza en el proyecto, se obtiene más información y claridad sobre los requisitos, las limitaciones y el progreso real. Es fundamental recalibrar las estimaciones regularmente para reflejar esta nueva información. Esto puede incluir ajustes en el tiempo, el costo y los recursos necesarios. • Adaptación a Cambios: Los proyectos de software a menudo experimentan cambios, ya sea en los requisitos del cliente, el entorno tecnológico o las prioridades del negocio. Recalibrar las estimaciones permite a los equipos adaptarse a estos cambios de manera ágil, minimizando el riesgo de desviaciones significativas del plan original. • Mejora de la Precisión: Las estimaciones iniciales suelen estar basadas en supuestos y datos limitados. A medida que el proyecto progresa, los datos reales y las lecciones aprendidas permiten ajustar las estimaciones para mejorar su precisión, lo que a su vez facilita una mejor planificación y gestión. • Comunicación con las Partes Interesadas: Recalibrar las estimaciones también implica comunicar estos cambios a las partes interesadas relevantes, asegurando que todos tengan expectativas realistas y estén alineados con los objetivos actualizados del proyecto.

61 61 Estimaciones (16/36) Uso de Estimaciones como Hipótesis para Guiar Decisiones y Ajustes en el Proyecto • Hipótesis de Trabajo: Las estimaciones deben verse como hipótesis iniciales que guían la planificación y ejecución del proyecto. Esta mentalidad permite a los equipos ser más flexibles y receptivos a nuevas informaciones y cambios en el contexto del proyecto. • Base para la Toma de Decisiones: Las estimaciones proporcionan un marco para evaluar diferentes escenarios y tomar decisiones informadas sobre la asignación de recursos, la priorización de tareas y la gestión de riesgos. Por ejemplo, si una estimación sugiere que una tarea crítica puede retrasarse, se pueden explorar opciones como la reasignación de recursos o el ajuste del cronograma. • Facilitación de Ajustes Estratégicos: Utilizar estimaciones como hipótesis permite a los equipos realizar ajustes estratégicos en el proyecto, como cambiar el enfoque a componentes de mayor valor o modificar el alcance para cumplir con restricciones de tiempo o presupuesto. • Promoción de una Cultura de Aprendizaje: Al tratar las estimaciones como hipótesis, los equipos fomentan una cultura de aprendizaje continuo, donde se valoran las iteraciones, los experimentos y las mejoras continuas. Esto ayuda a construir un ciclo de retroalimentación positivo que mejora la calidad del proyecto a lo largo del tiempo.

62 62 Estimaciones (17/36) Técnicas en el Ámbito de la Arquitectura del Software En el ámbito de la arquitectura del software, existen varias técnicas que pueden ayudar a mejorar la estimación y la planificación: • Modelado de Arquitectura: Utilizar diagramas de arquitectura, como los diagramas de bloques o los modelos UML, puede ayudar a visualizar la estructura del sistema y las interacciones entre componentes. Esto facilita la identificación de áreas complejas que pueden requerir más tiempo y recursos. • Análisis de Puntos de Función: Esta técnica permite estimar el tamaño del software basándose en la cantidad de funcionalidades que el sistema debe proporcionar. Se analizan las entradas, salidas, consultas y archivos, lo que ayuda a generar estimaciones más precisas del esfuerzo necesario. • Descomposición de Tareas: Dividir el proyecto en componentes más pequeños y manejables puede facilitar la estimación. Al descomponer el sistema en módulos o servicios, es posible realizar estimaciones más detalladas y precisas de cada parte, lo que ayuda a reducir la incertidumbre. • Técnicas de Estimación Ágil: Métodos como el Planning Poker o el uso de historias de usuario y puntos de historia permiten a los equipos de desarrollo estimar de manera colaborativa y rápida. Estas técnicas fomentan la discusión y el consenso, mejorando la precisión de las estimaciones.

63 63 Estimaciones (18/36) • Prototipado y Pruebas de Concepto: Crear prototipos o pruebas de concepto puede ayudar a validar ideas y reducir la incertidumbre en etapas tempranas del desarrollo. Esto proporciona datos más concretos para ajustar las estimaciones y tomar decisiones informadas. • Revisión de Proyectos Anteriores: Analizar proyectos previos similares puede ofrecer información valiosa sobre desafíos comunes y tiempos de desarrollo, permitiendo una estimación basada en experiencias pasadas.

64 64 Estimaciones (19/36) Uso de la Gestión del Cambio Nota del autor Es crucial prestar atención a los temas legales relacionados con la gestión del cambio, especialmente cuando se trata de contratos entre clientes y proveedores. Los cambios en los servicios o productos acordados pueden dar lugar a penalizaciones si no se gestionan adecuadamente conforme a los términos contractuales. Ejemplo: Supongamos que una empresa proveedora de software se compromete a entregar actualizaciones mensuales a su cliente. Si, debido a un cambio en sus procesos internos, la empresa decide modificar la frecuencia de las actualizaciones sin consultar al cliente o sin su consentimiento, esto podría constituir un incumplimiento del contrato. En tal caso, el cliente podría imponer penalizaciones financieras estipuladas en el acuerdo original o, en el peor de los casos, rescindir el contrato. Por lo tanto, es esencial que cualquier cambio propuesto sea comunicado y acordado formalmente con el cliente para evitar posibles sanciones.

65 65 Estimaciones (20/36) Uso “Fishbone diagram" o "Ishikawa diagram“ El diagrama de espina de pescado es una herramienta valiosa para las estimaciones de software por varias razones: • Identificación Estructurada de Factores: El diagrama ayuda a identificar y categorizar de forma sistemática todos los factores que pueden influir en la precisión de las estimaciones, como requisitos, recursos, tiempo y costos. Esto garantiza que no se pasen por alto elementos cruciales. • Análisis de Causas y Efectos: Facilita el análisis de las relaciones causa-efecto entre diferentes factores y cómo estos pueden afectar el resultado final de un proyecto. Esto es esencial para entender qué puede estar causando desviaciones en las estimaciones. • Colaboración y Comunicación: Al ser visual y fácil de entender, el diagrama fomenta la colaboración entre los miembros del equipo, stakeholders y otras partes interesadas. Todos pueden ver y discutir los mismos factores, lo que mejora la comunicación y el entendimiento mutuo. • Prevención de Problemas: Al visualizar todas las posibles causas de problemas, el equipo puede tomar medidas preventivas para abordar los riesgos antes de que afecten el proyecto, como asignar recursos adicionales o ajustar los plazos. • Mejora Continua: Utilizar el diagrama de espina de pescado para revisitar y analizar proyectos pasados permite al equipo aprender de experiencias anteriores, mejorando las prácticas de estimación para futuros proyectos. • Flexibilidad y Adaptación: El diagrama se puede adaptar a diferentes contextos y proyectos, permitiendo que se ajuste a las necesidades específicas de cada estimación, lo que lo hace una herramienta versátil en la gestión de proyectos de software.

66 66 Estimaciones (21/36)

67 67 Estimaciones (22/36) Uso del diagrama de Gantt o PERT/CPM para planificar calendarios

68 68 Estimaciones (23/36) Post-Mortem El análisis post-mortem, o lecciones aprendidas, es una práctica valiosa para mejorar las estimaciones en proyectos futuros por varias razones: • Identificación de Errores Pasados: Permite identificar errores o desviaciones en las estimaciones originales y comprender por qué ocurrieron. Esto ayuda a evitar cometer los mismos errores en futuros proyectos. • Reconocimiento de Factores Exitosos: Además de los errores, el análisis post-mortem también destaca lo que se hizo bien. Comprender qué factores contribuyeron al éxito puede ayudar a replicar estas prácticas en estimaciones futuras. • Mejora Continua: El análisis proporciona una oportunidad para refinar y mejorar continuamente el proceso de estimación. Con cada proyecto, el equipo puede ajustar sus métodos y técnicas para ser más precisos. • Fomento de la Transparencia y la Colaboración: Involucrar a todo el equipo en el análisis post-mortem promueve la transparencia y la colaboración. Cada miembro puede aportar su perspectiva, lo que enriquece el entendimiento colectivo sobre el proceso de estimación. • Documentación de Conocimientos: Las lecciones aprendidas se documentan para referencia futura, creando un valioso recurso de conocimiento dentro de la organización que puede ser consultado al planificar nuevos proyectos. • Gestión de Riesgos: Al identificar patrones comunes de problemas o riesgos, el equipo puede anticiparse mejor a estos en proyectos futuros y planificar estrategias de mitigación más efectivas. • Feedback para Mejora de Herramientas: Si se utilizan herramientas o técnicas específicas para las estimaciones, el análisis post-mortem puede proporcionar feedback sobre su efectividad y posibles mejoras.

69 69 Estimaciones (24/36) Ejemplo con diagrama de Ishikawa: • Objetivo del Proyecto: Desarrollar una aplicación móvil para gestionar tareas personales. • Resultado del Proyecto: El proyecto se completó, pero se entregó dos semanas después de la fecha prevista y con un 10% más de presupuesto. Análisis de Causas Identificadas: • Factores Humanos: • Comunicación insuficiente: Hubo falta de comunicación clara entre los desarrolladores y el equipo de diseño, lo que llevó a malentendidos y retrasos. • Capacitación inadecuada: Algunos desarrolladores no estaban completamente familiarizados con las nuevas tecnologías utilizadas, lo que resultó en errores en el código.

70 70 Estimaciones (25/36) • Factores Técnicos: • Herramientas inadecuadas: Las herramientas utilizadas para el desarrollo no eran las más adecuadas para el tipo de aplicación, lo que ralentizó el proceso. • Problemas de integración: La integración de diferentes módulos del software presentó problemas, lo que llevó a funcionalidades incompletas. • Factores de Requisitos: • Cambio de requisitos: Los cambios frecuentes en los requisitos del cliente provocaron retrasos. • Requisitos poco claros: Algunos requisitos no estaban bien definidos desde el principio, lo que llevó a malentendidos sobre lo que debía desarrollarse. • Factores de Gestión: • Estimaciones inexactas: Las estimaciones iniciales de tiempo y costo fueron demasiado optimistas. • Falta de seguimiento: No se realizaron suficientes revisiones de progreso, lo que permitió que los problemas se acumularan sin ser detectados a tiempo. • Lecciones Aprendidas: • Mejorar la comunicación: Implementar reuniones regulares de sincronización entre equipos y mejorar los canales de comunicación. • Capacitación continua: Asegurarse de que todo el equipo esté debidamente capacitado en las herramientas y tecnologías utilizadas. • Selección adecuada de herramientas: Evaluar y seleccionar cuidadosamente las herramientas de desarrollo para asegurarse de que sean las más adecuadas para el proyecto. • Gestión efectiva de requisitos: Establecer un proceso más sólido para la gestión de cambios en los requisitos y asegurar que todos los requisitos estén claramente documentados. • Revisión y seguimiento continuos: Realizar revisiones periódicas del progreso del proyecto para identificar y mitigar problemas temprano.

71 71 Estimaciones (26/36) Asunciones para Controlar los Riesgos Las asunciones son supuestos que ayudan a identificar y gestionar posibles riesgos durante las fases de preventa y ejecución. Estas deben documentarse cuidadosamente y validarse con el cliente y los stakeholders clave. Aquí se incluyen ejemplos y su relación con el control de riesgos: Asunciones sobre Alcance El alcance acordado durante la fase de preventa será respetado y no sufrirá cambios significativos sin un proceso formal de gestión de cambios. • Riesgo asociado: Incrementos no controlados del alcance (scope creep). • Mitigación: Implementar un proceso de aprobación formal para nuevos requisitos en proyectos fixed-price. Asunciones sobre Recursos Los recursos asignados estarán disponibles durante todo el proyecto según el cronograma acordado. • Riesgo asociado: Falta de disponibilidad o rotación del personal clave. • Mitigación: Tener un plan de respaldo con recursos alternativos y mantener documentación detallada para garantizar la continuidad. Asunciones sobre Tiempo y Cronogramas El cliente proporcionará respuestas, aprobaciones y accesos necesarios dentro de los tiempos comprometidos. • Riesgo asociado: Retrasos en aprobaciones o información que bloqueen el desarrollo. • Mitigación: Definir plazos claros para entregas y aprobaciones en el contrato y realizar un seguimiento activo.

72 72 Estimaciones (27/36) Asunciones sobre Requisitos y Complejidad Técnica Todos los requisitos funcionales y no funcionales han sido debidamente documentados y entendidos en la fase de preventa. • Riesgo asociado: Subestimación de la complejidad técnica. • Mitigación: Realizar una validación técnica temprana con el equipo de desarrollo y los arquitectos antes de cerrar las estimaciones. Asunciones sobre Tecnología Las tecnologías seleccionadas estarán disponibles, son compatibles y han sido probadas en proyectos similares. • Riesgo asociado: Problemas de integración o falta de experiencia del equipo con las herramientas seleccionadas. • Mitigación: Hacer una prueba de concepto (PoC) para tecnologías críticas antes de comprometer el diseño final. Asunciones sobre Presupuesto El presupuesto inicial incluye un margen para absorber pequeñas desviaciones imprevistas. • Riesgo asociado: Sobrecostos por actividades no contempladas. • Mitigación: Documentar un margen de contingencia en el presupuesto y realizar revisiones frecuentes de costos. Asunciones sobre Factores Externos No habrá cambios significativos en el entorno regulatorio, económico o en las dependencias externas (proveedores, licencias, etc.). • Riesgo asociado: Impactos inesperados debido a factores externos. • Mitigación: Monitorear el entorno y contar con planes alternativos para eventos de alto impacto.

73 73 Estimaciones (28/36) Validación y Gestión de Asunciones • Documentar: Todas las asunciones deben quedar registradas en el plan del proyecto. • Revisar regularmente: Durante las revisiones de proyecto, validar si las asunciones siguen siendo válidas. • Comunicar: Asegurar que tanto el cliente como los equipos internos comprendan estas asunciones y sus implicaciones. • Plan B: Desarrollar estrategias de mitigación para las asunciones más críticas.

74 74 Estimaciones (29/36) Roles y Responsabilidades Solution Architect • En Preventa: • Responsabilidades: • Diseñar la arquitectura general del sistema para cumplir con los requisitos funcionales y no funcionales planteados por el cliente. • Garantizar que la solución sea escalable, sostenible y alineada con estándares de calidad. • Identificar riesgos de alto nivel (e.g., tecnológicos, de integración) y plantear mitigaciones iniciales. • Estimación: • Evaluar la viabilidad técnica de los requisitos principales. • Definir esfuerzos aproximados de alto nivel junto con el Technical Architect, basándose en experiencias previas y complejidad general. • En Desarrollo: • Responsabilidades: • Validar que la arquitectura implementada cumpla con los lineamientos iniciales definidos. • Resolver dudas relacionadas con la visión global de la solución. • Estimación: • Refinar estimaciones conforme se esclarecen los detalles técnicos, en colaboración con el Technical Architect y los desarrolladores.

75 75 Estimaciones (30/36) Technical Architect • En Preventa: • Responsabilidades: • Traducir las acciones definidas por Solution Architect en componentes técnicos y tecnologías específicas. • Identificar posibles limitaciones técnicas y anticipar problemas de integración. • Estimación: • Realizar estimaciones detalladas de las tareas técnicas principales basándose en patrones conocidos y métricas. • Colaborar con los desarrolladores para confirmar las complejidades específicas de ciertos módulos. • En Desarrollo: • Responsabilidades: • Supervisar las implementaciones técnicas para asegurar el cumplimiento de los estándares definidos. • Resolver problemas técnicos complejos durante la ejecución. • Estimación: • Revisar y ajustar estimaciones conforme el equipo avanza, identificando posibles sobrecostos o desviaciones. Nota del autor Desde mi perspectiva, los arquitectos de soluciones deberían tener un equilibrio del 50% entre habilidades de negocio y habilidades técnicas (como infraestructura, inteligencia artificial, datos, etc.). Sin embargo, a menudo sucede que ese 50% técnico se basa más en teorías que en experiencia práctica en proyectos reales. Es importante tratar de evitar estos perfiles teóricos, ya que su falta de experiencia práctica puede causar numerosos problemas en el desarrollo y la implementación de aplicaciones.

76 76 Estimaciones (31/36) Project Manager (PM) • En Preventa: • Responsabilidades: • Garantizar que las expectativas del cliente sean claras y estén alineadas con los recursos disponibles. • Coordinar la creación de cronogramas y establecer los entregables principales. • Estimación: • Utilizar técnicas como el análisis de tres puntos o Delphi para obtener consensos sobre tiempos y costos. • Documentar las suposiciones clave y márgenes de error en las estimaciones iniciales. • En Desarrollo: • Responsabilidades: • Supervisar el cumplimiento del alcance, tiempo y presupuesto definidos. • Facilitar la comunicación entre el cliente y el equipo técnico. • Estimación: • Actualizar cronogramas basándose en el progreso real del equipo y las desviaciones detectadas. • Monitorear la utilización de recursos para evitar sobrecostos. Nota del autor Es fundamental que no solo el gerente de proyectos (PM), sino también el equipo de arquitectura, trabajen en conjunto para garantizar que las expectativas del cliente sean claras y estén alineadas con los recursos disponibles. La arquitectura desempeña un papel crucial en la traducción de las necesidades del cliente en soluciones técnicas viables, asegurándose de que lo que se promete es realmente alcanzable con los recursos y el tiempo disponibles. Recuerdo un proyecto, el cliente esperaba desarrollar una aplicación móvil con avanzadas características de realidad aumentada y personalización en tiempo real, pero su presupuesto y tiempo disponibles no lo permitían. El equipo de arquitectura trabajó para ajustar esas expectativas, proponiendo una solución más sencilla y escalonada que cumplía con las necesidades críticas y era técnicamente viable.

77 77 Estimaciones (32/36) Developers • En Preventa: • Responsabilidades: • Participar en sesiones de estimación para aportar detalles sobre la complejidad técnica y riesgos asociados a ciertas tareas. • Estimación: • Usar técnicas como Planning Poker para proporcionar esfuerzos iniciales en puntos de historia o similares. • En Desarrollo: • Responsabilidades: • Implementar los módulos asignados, asegurándose de cumplir con los lineamientos técnicos y funcionales. • Participar en pruebas de calidad y revisiones de código. • Estimación: • Refinar las estimaciones conforme se detallen las historias de usuario o tareas. • Considerar riesgos técnicos o dependencias que puedan incrementar el esfuerzo. Nota del autor En mi experiencia, en un entorno de producto, los desarrolladores se apoyan tanto en las métricas de agile como en el conocimiento previo para la planificación y mejora continua. En cambio, en consultoría, especialmente en proyectos nuevos, las cosas se complican y no se puede ser tan preciso debido a la falta de antecedentes específicos. Por eso, en muchas entrevistas, cuando te encuentras con una persona que ha trabajado previamente en el cliente, las cosas suelen acelerarse mucho, aunque esto es más común en escenarios de body shopping que en otras consultoras que no practican este enfoque. Sin embargo, si en una entrevista te preguntan mucho sobre lo que hacías en ese cliente y te piden detalles muy concretos, puede ser una señal de alerta (body shopping), ya que podrías estar siendo considerado para el mismo cliente nuevamente, lo cual podría ser bueno o malo dependiendo de tu experiencia previa allí.

78 78 Estimaciones (33/36) Conclusión A través de algunas frases famosas al respecto: • La estimación es más arte que ciencia, y el juicio experto juega un papel crucial. Es un concepto comúnmente mencionado en el contexto de la gestión de proyectos y desarrollo de software. Aunque no está atribuida a un autor en particular, refleja ideas ampliamente discutidas por expertos como Fred Brooks en su libro The Mythical Man-Month o en metodologías ágiles donde la experiencia del equipo se considera clave en la planificación y estimación. • La medición no requiere precisión perfecta, solo necesita ser mejor que la incertidumbre. Douglas Hubbard, autor de How to Measure Anything. • Sin estimaciones, no hay control. Sin control, no hay éxito. Tom DeMarco, experto en gestión de proyectos. Y mi conclusión personal sería que: La estimación no es solo un cálculo, es una danza meticulosa entre números y posibilidades, donde cada paso se apoya en la lógica y cada pausa en la experiencia acumulada.

79 79 Estimaciones (34/36) Comunicación y Colaboración La comunicación y la colaboración son pilares fundamentales para lograr estimaciones precisas y efectivas en proyectos de software. Cuando los equipos trabajan de manera abierta y transparente, se minimizan los malentendidos y se maximizan las oportunidades de identificar riesgos y mitigarlos de forma temprana. Además, considerar las perspectivas de todas las partes interesadas asegura que las estimaciones sean realistas y alineadas con los objetivos del proyecto. Fomentar la Comunicación Clara entre Equipos • Intercambio de Información: Establecer canales efectivos para compartir información crítica sobre requisitos, dependencias y restricciones. Esto evita omisiones y malentendidos que pueden comprometer las estimaciones. • Reuniones de Sincronización: Realizar reuniones regulares, como las dailys en metodologías ágiles, ayuda a mantener la alineación del equipo y a ajustar las estimaciones basándose en los últimos avances y desafíos. • Colaboración Interfuncional: Impulsar la interacción entre desarrolladores, analistas, testers y diseñadores garantiza que se consideren todos los aspectos técnicos y funcionales del proyecto en las estimaciones. • Uso de Herramientas de Colaboración: Herramientas digitales, como plataformas de gestión de proyectos, fomentan la transparencia y acceso en tiempo real a información clave, mejorando la precisión de las previsiones.

80 80 Estimaciones (35/36) Consideración de las Necesidades y Expectativas de las Partes Interesadas • Identificación de Stakeholders: Es vital identificar desde el inicio a todas las partes afectadas por el proyecto: cliente, usuarios finales, equipo técnico, gerentes y otros departamentos implicados. • Recopilación de Requisitos y Expectativas: Involucrar activamente a los stakeholders en esta fase asegura que las estimaciones reflejen sus objetivos y prioridades, reduciendo riesgos de malentendidos. • Gestión de Expectativas: Las estimaciones deben comunicarse de manera honesta y realista, explicando incertidumbres, supuestos y posibles variaciones de tiempo, costo o alcance. • Retroalimentación Continua: Establecer un ciclo de retroalimentación con las partes interesadas permite ajustar las estimaciones y el enfoque del proyecto conforme evolucionan las prioridades. No pretendo profundizar en este tema, ya que abarca áreas amplias que incluyen negociación, gestión de conflictos, y otras habilidades transversales o soft skills en las que no soy el más indicado para ofrecer orientación. Mi enfoque ha sido intencionalmente técnico, orientado hacia la importancia de la comunicación y la colaboración en el ámbito de la arquitectura de software. Por eso os recomiendo una serie de libro; seguramente alguno de ellos ya lo habrás leído: • "Peopleware: Productive Projects and Teams", Tom DeMarco y Timothy Lister. Por qué es relevante: Este clásico analiza cómo los factores humanos influyen en los proyectos de software. Aunque no es puramente técnico, ofrece excelentes ideas sobre cómo fomentar la comunicación y colaboración efectiva dentro de los equipos, incluyendo cómo superar barreras organizacionales.

81 81 Estimaciones (36/36) • "Accelerate: The Science of Lean Software and DevOps", Nicole Forsgren, Jez Humble, Gene Kim. Por qué es relevante: Este libro se centra en la mejora del rendimiento de equipos de software a través de prácticas ágiles y DevOps. Incluye secciones sobre cómo la colaboración y la comunicación efectiva entre equipos técnicos y no técnicos son fundamentales para el éxito. • "The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win", Gene Kim, Kevin Behr, George Spafford. Por qué es relevante: Este libro en formato de novela ofrece lecciones sobre cómo mejorar la comunicación y el trabajo colaborativo en proyectos de TI. Es especialmente útil para entender los desafíos de comunicación entre equipos de negocio, desarrollo y operaciones. Existe versión en español • "Team Topologies: Organizing Business and Technology Teams for Fast Flow", Matthew Skelton y Manuel Pais. Por qué es relevante: Este libro explora cómo estructurar equipos técnicos y fomentar una comunicación eficaz entre ellos para lograr mejores resultados en proyectos de software. También abarca cómo las interacciones y dependencias entre equipos afectan la productividad y el flujo de trabajo. • "Debugging Teams: Better Productivity Through Collaboration", Brian W. Fitzpatrick y Ben Collins-Sussman. Por qué es relevante: Este libro está orientado específicamente a equipos de desarrollo de software y se centra en cómo fomentar una cultura de colaboración, evitar conflictos y construir una comunicación efectiva. • " Conversaciones Cruciales: Herramientas para comunicar mejor cuando más se necesita", Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler. Por qué es relevante: Aunque no está orientado exclusivamente al software, es una excelente guía para manejar conversaciones importantes y difíciles, una habilidad crucial para líderes técnicos y equipos en proyectos complejos. He visto que ya va por la tercera edición, yo tengo una de hace más de 10 años, tendré que leer la nueva revisión.

82 82 Ejemplo Práctico: Monte Carlo y ML.NET (1/7) Técnicas avanzadas: Uso de ML.NET y el Algoritmo de Monte Carlo para Estimaciones de Software El objetivo de combinar ML.NET y Monte Carlo es realizar estimaciones más precisas y manejar la incertidumbre inherente en proyectos de software. Este enfoque permite usar datos históricos para entrenar un modelo predictivo (con ML.NET) y luego aplicar simulaciones de Monte Carlo para explorar posibles escenarios y rangos de resultados. Parte Teórica • ML.NET para Estimaciones de Software • ML.NET es una biblioteca de aprendizaje automático que se utiliza para entrenar modelos predictivos, como regresiones lineales o no lineales. • Aplicación en estimaciones de software: ML.NET puede ayudarte a construir un modelo basado en datos históricos de proyectos, como tamaño, complejidad técnica, experiencia del equipo, etc., para predecir métricas como tiempo estimado o esfuerzo. • Simulación de Monte Carlo • Qué hace: Es una técnica estadística que permite modelar incertidumbres al generar valores aleatorios basados en distribuciones de probabilidad. • Aplicación en estimaciones: Con Monte Carlo, puedes simular miles de iteraciones usando el modelo entrenado para predecir los resultados bajo diferentes escenarios (valores aleatorios para las variables).

83 83 Ejemplo Práctico: Monte Carlo y ML.NET (2/7) Ejemplo Práctico Preparación del Proyecto • Crea un proyecto de consola en .NET: dotnet new console -n SoftwareEstimation cd SoftwareEstimation • Instala la librería de ML.NET: dotnet add package Microsoft.ML • Agregar biblioteca adicional (opcional para CSV si no deseas manejarlo manualmente): dotnet add package CsvHelper

84 84 Ejemplo Práctico: Monte Carlo y ML.NET (3/7) Entra en Visual Studio • Crea un archiv llamado projects.csv: Complexity,Size,TeamExperience,Effort 3.0,100,2,200 2.5,80,3,180 4.0,120,1,250 3.5,110,2,220 • Codigo en Program.cs:

85 85 Ejemplo Práctico: Monte Carlo y ML.NET (4/7)

86 86 Ejemplo Práctico: Monte Carlo y ML.NET (5/7)

87 87 Ejemplo Práctico: Monte Carlo y ML.NET (6/7) Ejecución del proyecto • Ejecutamos el programa: dotnet run • Resultados esperados: • El programa mostrará: • Promedio estimado: El esfuerzo promedio según el modelo. • Percentil 5% y 95%: Valores que delimitan el rango probable del esfuerzo.

88 88 Ejemplo Práctico: Monte Carlo y ML.NET (7/7) Ejemplo Práctico Extensión • Si quieres usar redes neuronales en lugar de regresión lineal, cambia el entrenador en el pipeline por FastTree o cualquier otro modelo soportado por ML.NET. • Puedes generar visualizaciones gráficas exportando los datos simulados a un archivo y usando herramientas como Python o Excel o usar todo el proyecto con Jupyter notebooks. Este enfoque combina lo mejor de ML.NET y Monte Carlo para crear una herramienta robusta de estimación de software. Y si quieres profundizar más en estos temas: MCMC, Monte-Carlo Methods and Stochastic Processes From Linear to Non-Linear y https://risk-engineering.org/. Nota del autor Estadística descriptiva, análisis multivariante y redes neuronales fueron asignaturas que estudié en la Diplomatura de Estadística hace ya bastante tiempo. Por ello, la era de la inteligencia artificial, las simulaciones, etc., no me toma por sorpresa. Creo que estas son herramientas que pueden realizar un alto porcentaje del trabajo, siempre bajo la supervisión crítica de un humano. También puedes bajarte este monográfico de ML.NET: Machine Learning para desarrolladores de .NET

89 89 Contexto (1/4) La relación entre estimaciones, riesgos y contexto es fundamental en el diseño y desarrollo de arquitecturas de software. Estos tres elementos interactúan constantemente y determinan en gran medida el éxito de un proyecto. Estimaciones Las estimaciones son predicciones sobre el esfuerzo, tiempo y recursos necesarios para implementar una solución arquitectónica. En arquitectura de software, las estimaciones se usan para planificar iteraciones, asignar recursos y definir expectativas con las partes interesadas. Sin embargo, las estimaciones son inherentemente inciertas. Factores como requisitos mal definidos, tecnologías nuevas o falta de experiencia del equipo pueden aumentar el margen de error. Por ello, es crucial que las estimaciones se hagan considerando los riesgos y el contexto del proyecto. Riesgos Los riesgos son posibles eventos o circunstancias que pueden afectar negativamente un proyecto. En el contexto de arquitectura de software, los riesgos pueden incluir: • Riesgos técnicos: Tecnologías inmaduras, incompatibilidades o falta de pruebas. • Riesgos de alcance: Cambios frecuentes en los requisitos o falta de claridad en las necesidades del cliente. • Riesgos operativos: Problemas con la capacidad del equipo, falta de habilidades necesarias o restricciones presupuestarias. La identificación y evaluación temprana de riesgos ayudan a ajustar las estimaciones y priorizar tareas críticas. Por ejemplo, un alto riesgo técnico podría requerir la realización de pruebas de concepto antes de comprometerse con una solución.

90 90 Contexto (2/4) Contexto El contexto engloba los factores específicos del proyecto, como los objetivos de negocio, restricciones técnicas, políticas organizativas y características del equipo. Entender el contexto permite que las estimaciones y la gestión de riesgos sean más precisas y realistas. Por ejemplo: • Un equipo con experiencia en una tecnología específica puede mitigar riesgos asociados a su implementación. • En un entorno altamente regulado, las estimaciones deben incluir el tiempo necesario para cumplir con normativas. Interacción entre los elementos • Las estimaciones dependen del contexto: Conocer el entorno permite realizar predicciones más informadas. • Los riesgos afectan a las estimaciones: Identificar riesgos tempranamente ayuda a ajustar márgenes de tiempo y costo. • El contexto influye en los riesgos: Factores específicos del proyecto pueden aumentar o mitigar ciertos riesgos.

91 91 Contexto (3/4) Por tanto • Contexto: Es el entorno general que engloba todo. Define las condiciones bajo las cuales se realizan las estimaciones y se gestionan los riesgos. Es el marco en el que el proyecto existe. • Riesgos: Dentro del contexto, los riesgos representan los desafíos y las incertidumbres específicas que deben manejarse. Están influenciados por el contexto y, a su vez, afectan la calidad de las estimaciones. • Estimaciones: Son el resultado más específico e inmediato, ya que se ven directamente influenciadas tanto por el contexto como por los riesgos. Contexto Riesgos Estimaciones

92 92 Contexto (4/4) Aspecto SDLC ALM PDLC Alcance Desarrollo de software Desarrollo, operación y mantenimiento de aplicaciones Ciclo de vida completo del producto Enfoque Fases técnicas del desarrollo Gestión integral de aplicaciones Perspectiva de negocio y producto Duración Generalmente finita Continua (mientras la aplicación esté activa) Desde la idea hasta el retiro Estimaciones clave • Desarrollo: tiempo para cada fase del ciclo (análisis, diseño, implementación, pruebas y despliegue). • Recursos: cantidad de desarrolladores, testers, etc. Tecnología: impacto de herramientas y lenguajes utilizados. • Riesgos: impacto del cambio de requisitos. • Mantenimiento: tiempo y costo de soporte técnico. Actualizaciones: esfuerzo para nuevas versiones y parches. • Escalabilidad: esfuerzo necesario para manejar un crecimiento en usuarios o datos. • Integraciones: impacto de integrar la aplicación con otras soluciones existentes. • Investigación: tiempo para estudios de mercado y viabilidad técnica. • Desarrollo: esfuerzo para integrar software, hardware y UX. Iteración: costo y tiempo para prototipos, pruebas de usuario y retroalimentación. • Comercialización: esfuerzo para el lanzamiento y posicionamiento del producto. • Retiro: planificación del fin de vida del producto. Asociado a los distintos frameworks Más información en “Diferencia entre: SDLC, ALM y PDLC”.

93 93 Reflexiones Finales (1/2) Integrando Estrategias para el Éxito • Adaptabilidad y Evolución: La naturaleza dinámica de la tecnología y los negocios exige que las prácticas de estimación y gestión de riesgos sean flexibles y capaces de adaptarse rápidamente a cambios inesperados. Los equipos deben estar preparados para iterar y ajustar sus planes a medida que surgen nuevas informaciones o circunstancias. • Colaboración Multidisciplinar: Fomentar un entorno de trabajo donde se valoren las contribuciones de profesionales de diferentes disciplinas es clave. La diversidad de perspectivas enriquece el proceso de toma de decisiones y mejora la identificación y mitigación de riesgos. • Aprendizaje Continuo: Cada proyecto ofrece lecciones valiosas que deben ser capturadas y aplicadas en futuros esfuerzos. Las organizaciones que adoptan una cultura de mejora continua están mejor equipadas para enfrentar desafíos y aprovechar oportunidades. • Herramientas Avanzadas y Tecnología: El uso de herramientas avanzadas, como el aprendizaje automático y las simulaciones, puede mejorar significativamente la precisión de las estimaciones y la gestión de riesgos. Sin embargo, estas herramientas deben ser implementadas con un entendimiento claro de sus capacidades y limitaciones. • Comunicación Clara y Efectiva: La claridad en la comunicación con todas las partes interesadas es fundamental para alinear expectativas y asegurar que las decisiones se tomen con base en información precisa y compartida.

94 94 Reflexiones Finales (2/2) • Consideraciones Éticas y Legales: No se debe pasar por alto el impacto de las decisiones tecnológicas en el entorno legal y ético. Es importante asegurarse de que todas las prácticas cumplan con las regulaciones pertinentes y que se actúe con responsabilidad social. En última instancia, el éxito en el desarrollo de software no se mide solo por la entrega de una solución funcional, sino también por su capacidad para adaptarse, crecer y aportar valor continuo a sus usuarios y stakeholders. Al integrar de manera efectiva las estrategias de estimación, gestión de riesgos y consideración del contexto, los equipos pueden no solo cumplir sus objetivos inmediatos, sino también establecer una base sólida para el futuro. Espero que este documento te haya proporcionado una comprensión más profunda y herramientas prácticas para abordar los complejos desafíos del desarrollo de software.