Sesión 10 -- 2.4 Análisis y gestión de riesgo.

Sesión 10

Ingeniería de Requerimientos

Dr Héctor Jesús Ponce Castillo.

2. Preparar el escenario para el desarrollo de requerimientos. 2.4 Análisis y gestión de riesgo.

Agenda

Definición de Riesgo Un riesgo es un evento incierto que, si ocurre, afectará el éxito del proyecto de manera negativa o positiva. En el contexto de proyectos de software, los riesgos pueden ser técnicos, operativos, de negocio, de cumplimiento legal o de recursos humanos.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

Fases del Análisis de Riesgos a) Identificación de Riesgos La primera etapa es identificar los riesgos potenciales. Estos pueden surgir de varias fuentes: Requerimientos: Si los requerimientos no están bien definidos, pueden dar lugar a malentendidos que afecten el resultado del proyecto. Técnicos: Nuevas tecnologías o herramientas que el equipo no domina pueden introducir riesgos. Cronograma: Plazos no realistas o dependencias externas. Recursos humanos: Falta de habilidades o experiencia en el equipo. Proveedores o externos: Dependencias de terceros o de proveedores externos.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

Fases del Análisis de Riesgos Técnicas para identificar riesgos: Revisión de documentación: Revisión detallada de los requerimientos, contratos, y otros documentos clave. Entrevistas: Conversaciones con stakeholders clave, expertos en la materia, y miembros del equipo. Lluvia de ideas: Sesiones colaborativas para que el equipo identifique posibles riesgos. Análisis de causa y efecto: Herramientas como el diagrama de Ishikawa pueden ayudar a identificar riesgos estructurales.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

Fases del Análisis de Riesgos b) Análisis Cualitativo de Riesgos Esta fase consiste en evaluar los riesgos identificados en función de dos parámetros principales: Probabilidad de ocurrencia: La probabilidad de que el riesgo ocurra. Impacto: La magnitud del efecto que el riesgo tendría sobre el proyecto si ocurriera. Se puede usar una matriz de riesgos (probabilidad vs. impacto) para priorizarlos. La matriz ayuda a categorizar los riesgos en: Alto riesgo: Alta probabilidad y alto impacto. Moderado: O bien tienen alta probabilidad o alto impacto, pero no ambos. Bajo riesgo: Baja probabilidad y bajo impacto.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

Fases del Análisis de Riesgos c) Análisis Cuantitativo de Riesgos Para los riesgos críticos, se puede realizar un análisis cuantitativo. Esto implica: Estimación numérica de impacto: Traducir el impacto del riesgo en términos financieros o de cronograma. Análisis de simulación (Monte Carlo): Simulación de escenarios futuros para entender el rango de resultados posibles. Árboles de decisión: Herramientas para evaluar diferentes cursos de acción y sus posibles consecuencias.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

Gestión de Riesgos La gestión de riesgos es la creación de estrategias para minimizar la probabilidad de ocurrencia de riesgos o el impacto que estos puedan tener. a) Estrategias de respuesta a riesgos Evitar el riesgo: Modificar el plan del proyecto para eliminar la causa del riesgo. Esto puede implicar, por ejemplo, cambiar una tecnología o ajustar los plazos. Mitigar el riesgo: Reducir la probabilidad o el impacto del riesgo. Esto puede implicar la adopción de soluciones intermedias o la capacitación del equipo. Transferir el riesgo: Pasar la responsabilidad del riesgo a un tercero, como una compañía de seguros o un proveedor externo. Aceptar el riesgo: Cuando los costos de mitigación superan los beneficios, puede optarse por aceptar el riesgo y monitorear su evolución.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

Gestión de Riesgos b) Planes de contingencia Es importante tener planes alternativos para enfrentar riesgos que no pudieron evitarse. Los planes de contingencia son acciones que se activan en caso de que el riesgo ocurra. Estos planes deben estar bien documentados y ser revisados regularmente.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

Monitoreo y Control de Riesgos La gestión de riesgos no es una tarea estática. Los riesgos cambian a lo largo del ciclo de vida del proyecto, por lo que es necesario: Monitoreo continuo: Realizar reuniones periódicas con el equipo para evaluar si han surgido nuevos riesgos o si los riesgos anteriores han cambiado. Reevaluar y actualizar el plan de riesgos: A medida que se avanza en el proyecto, se debe ajustar el plan para reflejar la realidad actual. Registro de incidentes: Mantener un registro de todos los riesgos identificados, sus análisis, respuestas y el estado actual es crucial para poder realizar una correcta gestión de riesgos.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

El Papel del Scrum Master y del Líder de Proyecto en la Gestión de Riesgos Como Scrum Master y líder en desarrollo de software, su papel en la gestión de riesgos incluye: Facilitar la comunicación entre los equipos: Asegurarse de que todos los miembros del equipo estén al tanto de los riesgos y las estrategias para mitigarlos. Monitorear la progresión: A través de eventos de Scrum, como las Daily Standups o Sprint Reviews, el Scrum Master puede detectar posibles riesgos. Priorizar los riesgos más críticos: En el backlog del proyecto, los riesgos deben estar bien priorizados para ser tratados con antelación. Asegurar que las soluciones de mitigación se implementen: Supervisar la ejecución de las respuestas a los riesgos.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en una sesión JAD Participación limitada o desinteresada de los stakeholders Riesgo: Los stakeholders clave pueden no participar activamente o asistir a las sesiones, lo que puede resultar en la falta de claridad en los requerimientos del sistema. Impacto: Si no se obtiene información precisa de todas las partes interesadas, el proyecto puede comenzar con suposiciones incorrectas o requerimientos incompletos. Mitigación: Programar las sesiones con suficiente antelación, asegurarse de que los stakeholders comprendan la importancia de su participación y mantener el enfoque en temas de interés para ellos.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en una sesión JAD Conflictos entre los stakeholders Riesgo: Los participantes de diferentes departamentos o áreas de la empresa pueden tener expectativas o prioridades contradictorias, lo que puede llevar a desacuerdos sobre los requerimientos del sistema. Impacto: Los conflictos no resueltos pueden retrasar la definición de los requerimientos o resultar en un sistema que no satisfaga a todos los usuarios. Mitigación: Facilitar la sesión JAD con un moderador neutral (como un Scrum Master) para mediar en las discusiones y buscar un consenso entre las partes.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en una sesión JAD Requerimientos mal definidos o ambiguos Riesgo: Las descripciones de los requerimientos pueden ser vagas o abiertas a interpretaciones diferentes, lo que puede conducir a malentendidos en la fase de desarrollo. Impacto: La ambigüedad en los requerimientos puede causar que el equipo de desarrollo construya una solución que no satisfaga las necesidades del negocio. Mitigación: Asegurarse de que todos los requerimientos estén documentados claramente, utilizar ejemplos concretos y prototipos durante la sesión para validar la comprensión.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en una sesión JAD Demasiado enfoque en detalles técnicos Riesgo: Los desarrolladores o ingenieros pueden llevar la discusión hacia detalles técnicos antes de que se haya definido claramente el alcance del sistema, lo que desvía el enfoque del negocio. Impacto: Puede ocurrir que se invierta tiempo discutiendo soluciones tecnológicas antes de entender completamente los requerimientos del negocio, lo que puede resultar en soluciones que no satisfagan los objetivos. Mitigación: Enfocar las discusiones en los requerimientos del negocio, manteniendo los detalles técnicos para una fase posterior. Un moderador puede ayudar a redirigir las conversaciones si es necesario.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en una sesión JAD Duración excesiva de las sesiones Riesgo: Las sesiones JAD pueden alargarse demasiado si no se controlan bien, lo que puede agotar a los participantes y reducir la productividad y la calidad de las decisiones. Impacto: El cansancio o la falta de concentración puede afectar la calidad de las decisiones y generar errores en la definición de los requerimientos. Mitigación: Definir una agenda clara y un cronograma ajustado para cada sesión JAD. Hacer pausas y dividir las sesiones en bloques manejables para evitar la fatiga mental.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en una Daily Standups, Sprint Planning, Sprint Review y Sprint Retrospective Falta de preparación en la Daily Standup Riesgo: Los miembros del equipo llegan a la Daily Standup sin haber reflexionado previamente sobre su progreso, lo que puede hacer que la reunión se prolongue innecesariamente o que no sea útil. Impacto: La falta de preparación puede llevar a una reunión ineficaz, en la que no se identifican problemas o bloqueos oportunamente, afectando la planificación del sprint. Mitigación: Reforzar la importancia de que cada miembro del equipo llegue preparado para responder las tres preguntas clave: ¿Qué hice ayer?, ¿Qué voy a hacer hoy? y ¿Tengo algún bloqueo?. Mantener las reuniones breves y estructuradas.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en una Daily Standups, Sprint Planning, Sprint Review y Sprint Retrospective Dominación de la conversación por un miembro del equipo Riesgo: Uno o dos miembros del equipo acaparan la discusión durante las reuniones, lo que impide que otros expresen sus opiniones o compartan problemas importantes. Impacto: Esto puede llevar a decisiones desequilibradas o a la falta de visibilidad sobre problemas que afectan a otros miembros del equipo, comprometiendo la colaboración. Mitigación: Como Scrum Master, moderar las reuniones para garantizar que todos los miembros tengan la oportunidad de participar de manera equitativa. Fomentar un ambiente donde cada persona se sienta cómoda para hablar.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en una Daily Standups, Sprint Planning, Sprint Review y Sprint Retrospective Problemas no detectados o ignorados Riesgo: En la Daily Standup, algunos miembros del equipo pueden ocultar problemas o bloqueos, ya sea por miedo a las repercusiones o por la esperanza de resolverlos por su cuenta. Impacto: Si los problemas no se identifican y abordan a tiempo, pueden causar retrasos en el sprint y aumentar el riesgo de no cumplir con los compromisos. Mitigación: Crear una cultura de transparencia en la que se valore la honestidad. El Scrum Master debe fomentar un ambiente en el que los problemas puedan discutirse abiertamente sin repercusiones negativas.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en una Daily Standups, Sprint Planning, Sprint Review y Sprint Retrospective Desviación del enfoque durante el Sprint Planning Riesgo: Durante el Sprint Planning, el equipo puede desviarse del tema principal y comenzar a discutir detalles técnicos o tareas no relacionadas, lo que alarga la reunión y dificulta la planificación adecuada del sprint. Impacto: Esto puede resultar en una mala estimación de las tareas y compromisos no realistas para el sprint, lo que lleva a una entrega insatisfactoria o incompleta. Mitigación: El Scrum Master debe mantener la reunión enfocada en los objetivos del sprint y los elementos del backlog a priorizar. Utilizar herramientas como una agenda clara y timeboxing para evitar discusiones fuera de contexto.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en una Daily Standups, Sprint Planning, Sprint Review y Sprint Retrospective Falta de compromiso con las acciones de mejora en la Retrospectiva Riesgo: En la Sprint Retrospective, el equipo identifica áreas de mejora, pero no se compromete completamente con la implementación de esas acciones, lo que resulta en la repetición de los mismos errores o problemas. Impacto: La falta de mejora continua puede llevar a una baja moral en el equipo y la repetición de problemas en futuros sprints, afectando la productividad y la calidad del producto. Mitigación: Asegurarse de que las acciones de mejora se prioricen, asignen responsabilidades claras y se incluyan en el backlog del siguiente sprint. Monitorear y hacer seguimiento del progreso de las acciones en cada retrospectiva.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en la documentación de requisitos. Requisitos incompletos o mal definidos Riesgo: Los requisitos pueden no estar completamente definidos o pueden ser ambiguos, lo que genera confusión sobre lo que realmente se debe desarrollar. Impacto: Si los requisitos son incompletos o vagos, el equipo de desarrollo podría construir algo que no cumpla con las expectativas del cliente, lo que lleva a reprocesos y costos adicionales. Mitigación: Asegurarse de que los requisitos se documenten de manera exhaustiva. Realizar entrevistas detalladas, sesiones JAD, y talleres con stakeholders para extraer todos los detalles. Revisar y validar los requisitos con los usuarios finales antes de proceder con el desarrollo.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en la documentación de requisitos. Cambios frecuentes en los requisitos Riesgo: Los stakeholders cambian sus expectativas o requisitos durante el desarrollo sin un proceso adecuado de control de cambios. Impacto: Los cambios no controlados pueden causar retrasos significativos, aumentar los costos y afectar la calidad del producto final. Mitigación: Implementar un proceso formal de control de cambios. Utilizar herramientas de gestión de requisitos y asegurarse de que todos los cambios sean revisados y aprobados por el equipo de desarrollo y los stakeholders antes de ser implementados.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en la documentación de requisitos. Falta de involucramiento de los stakeholders Riesgo: Los stakeholders clave no se involucran lo suficiente durante la fase de recopilación y documentación de requisitos, lo que puede resultar en una comprensión limitada de sus necesidades reales. Impacto: La falta de involucramiento puede llevar a la creación de un sistema que no satisface completamente las expectativas del cliente o no resuelve los problemas clave que pretendía abordar. Mitigación: Establecer una comunicación constante y clara con los stakeholders desde el inicio del proyecto. Involucrarlos en revisiones periódicas y en la aprobación de los documentos de requisitos. El Scrum Master o el Product Owner deben facilitar esta interacción.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en la documentación de requisitos. Falta de priorización de los requisitos Riesgo: No priorizar adecuadamente los requisitos puede llevar a que se desarrollen características menos importantes mientras que las funcionalidades críticas no reciben la atención necesaria. Impacto: Esto puede generar un producto que no cumple con los objetivos del negocio en el tiempo o dentro del presupuesto establecido, causando insatisfacción en el cliente. Mitigación: Utilizar técnicas de priorización de requisitos como MoSCoW (Must have, Should have, Could have, Won’t have) o la matriz de priorización basada en valor de negocio y esfuerzo. Asegurarse de que los stakeholders y el equipo estén alineados en las prioridades.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en la documentación de requisitos. Inconsistencias o contradicciones en los requisitos Riesgo: Los requisitos documentados pueden ser inconsistentes entre sí o contradictorios, lo que puede llevar a confusiones durante la fase de diseño y desarrollo. Impacto: La falta de coherencia puede resultar en un sistema que no funciona correctamente, problemas de integración entre módulos y confusión general entre los miembros del equipo de desarrollo. Mitigación: Revisar cuidadosamente los requisitos antes de aprobarlos. Realizar revisiones cruzadas y asegurarse de que haya una trazabilidad completa de los requisitos desde el nivel de negocio hasta el nivel técnico. Las herramientas de gestión de requisitos pueden ayudar a mantener la coherencia.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en la trazabilidad de los requerimientos. Pérdida de visibilidad de los cambios en los requerimientos Riesgo: Durante el ciclo de vida del proyecto, los requerimientos pueden cambiar, y si esos cambios no se registran correctamente, se pierde la visibilidad de la evolución de dichos requerimientos. Impacto: La falta de seguimiento de los cambios puede causar confusión en el equipo, lo que lleva a la implementación de funcionalidades que no reflejan las necesidades actuales del cliente o que introducen errores. Mitigación: Implementar una herramienta de gestión de requerimientos que permita registrar y rastrear todas las modificaciones, además de mantener una auditoría de los cambios y notificar al equipo cada vez que se realicen actualizaciones.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en la trazabilidad de los requerimientos. Falta de herramientas o procesos de trazabilidad adecuados Riesgo: La trazabilidad manual o la ausencia de herramientas adecuadas puede llevar a la falta de un seguimiento efectivo de los requerimientos a lo largo del proyecto. Impacto: Sin una herramienta adecuada, es difícil asegurarse de que todos los requerimientos estén siendo implementados y probados correctamente, lo que podría resultar en funcionalidades incompletas o defectuosas. Mitigación: Implementar herramientas específicas para la trazabilidad de requerimientos, como Jira, IBM DOORS, o similares, que permitan rastrear los requerimientos desde la fase de planificación hasta la entrega y las pruebas.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en la trazabilidad de los requerimientos. Inconsistencia entre requerimientos y entregables Riesgo: Puede ocurrir que los entregables no cumplan con todos los requerimientos o que el equipo no esté alineado sobre qué requerimientos se están cubriendo en una versión específica del producto. Impacto: Esto puede llevar a entregas que no cumplen con las expectativas del cliente, causando retrasos o la necesidad de retrabajos significativos. Mitigación: Realizar revisiones periódicas para garantizar que los entregables están alineados con los requerimientos establecidos. Asegurar que la trazabilidad cubra todas las etapas del proyecto, incluyendo la implementación y las pruebas, para verificar que se están cumpliendo los requisitos.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en la trazabilidad de los requerimientos. Trazabilidad incompleta de los requerimientos Riesgo: No todos los requerimientos están completamente trazados desde la fase de definición hasta las pruebas y entrega, lo que genera huecos en el seguimiento y en la validación de la implementación. Impacto: Los requerimientos no rastreados podrían pasarse por alto durante la fase de desarrollo o prueba, resultando en funcionalidades omitidas o implementadas incorrectamente. Mitigación: Establecer un proceso claro de trazabilidad que cubra todas las etapas del ciclo de vida de los requerimientos. Realizar revisiones de trazabilidad de manera frecuente para asegurarse de que todos los requerimientos tienen una relación clara con su implementación y pruebas.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

5 Riesgos que pueden suceder en la trazabilidad de los requerimientos. Desalineación entre requerimientos y casos de prueba Riesgo: Los casos de prueba pueden no estar alineados correctamente con los requerimientos, lo que genera una brecha entre lo que se desarrolla y lo que se prueba, afectando la calidad del producto final. Impacto: Esto puede resultar en que ciertos requerimientos no se validen adecuadamente, lo que lleva a que errores o faltantes en las funcionalidades no sean detectados hasta fases avanzadas del proyecto. Mitigación: Asegurarse de que cada requerimiento tiene casos de prueba asociados que verifiquen su correcta implementación. Usar herramientas de trazabilidad que permitan mapear los requerimientos directamente a los casos de prueba y validaciones correspondientes.

2.4 Análisis y gestión de riesgo.

Dr Héctor Jesús Ponce Castillo.

Dr Héctor Jesús Ponce Castillo.

¿ Dudas ?

Dr Héctor Jesús Ponce Castillo.

Gracias