¿En qué se diferencia la gestión de riesgos en el desarrollo ágil de la gestión de riesgos en el modelo en cascada?

Como otros han mencionado, Agile modifica la gestión de riesgos en comparación con Waterfall. Un proyecto bien administrado incluirá la observación de riesgos fuera del alcance del proyecto, y estos deben manejarse más o menos de la misma manera.

Hay áreas de riesgo que la metodología Agile debería ayudar a mitigar.

• Tiempo de comercialización/Error de programación: en un proyecto en cascada, pueden pasar meses o años antes de su lanzamiento. Con Agile deberías tener algo que se pueda lanzar cada pocas semanas.
• Riesgo presupuestario: los proyectos en cascada tienden a tener un riesgo presupuestario significativo, ya que el plazo de entrega es muy largo y las estimaciones a menudo no son precisas. Si bien es posible que el costo de un proyecto ágil no se calcule mejor, es más fácil administrar el presupuesto.
• Costo de cancelación: si un proyecto de cascada se cancela tarde, puede haber costos significativos sin producto. La metodología en cascada puede retrasar significativamente el descubrimiento de que un proyecto no es práctico. Un proyecto ágil cancelado debería producir alguna funcionalidad si se ha ejecutado durante un período de tiempo prolongado.
• Desplazamiento del alcance: los proyectos en cascada tienden a encontrarse con problemas de desplazamiento del alcance a medida que se agregan requisitos perdidos al proyecto sin eliminar otros requisitos. Los proyectos ágiles deben agregar los requisitos perdidos a la cartera de pedidos, eliminar los requisitos de menor valor y eliminar los requisitos innecesarios.
• Error de requisito: los proyectos en cascada especifican los requisitos mucho antes de que se entreguen. Un requisito incorrecto puede generar costos significativos antes de que se descubra y más costos al corregir o eliminar el requisito. Agile desarrolla el requisito cuando se implementa, proporcionando mucha más visibilidad y un marco de tiempo más corto para aumentar los costos.
• Riesgo tecnológico: los proyectos en cascada pueden especificar tecnología no probada y pueden pasar varios meses antes de que se descubran los problemas con la tecnología. Los proyectos ágiles deben reducir el período de tiempo antes de que se detecten los problemas y simplificar la adaptación.
• Riesgo de seguridad: los proyectos Waterfall no proporcionan un producto cuya seguridad se pueda probar hasta bien avanzados los proyectos. Los proyectos ágiles produjeron productos comprobables cada pocas semanas. Si se descubren problemas de seguridad, es posible abordarlos en las primeras etapas de un proyecto ágil. Si es necesario, un proyecto ágil puede adaptar su proceso para tratar los problemas de seguridad descubiertos.

EDITAR: me perdí el riesgo de los requisitos chapados en oro. Es mucho más fácil finalizar un proyecto Agile cuando se ha desarrollado suficiente funcionalidad.

Tiene razón al decir que la gestión de riesgos generalmente no se aborda explícitamente en los proyectos Agile. Es decir, los diseñadores de procesos pretendían que los riesgos típicos del proyecto se abordaran a través de las prácticas descritas en el proceso. Como resultado, los equipos ágiles tradicionalmente no utilizan ningún tipo de enfoque de gestión de riesgos intencional. Esto funciona para muchos equipos y muchos proyectos, pero descubrí que ignorar el riesgo es una gran oportunidad perdida y tiende a aumentar los costos del proyecto al aprender a través del fracaso. Además, muchos proyectos son lo suficientemente diferentes del escenario 'ideal' para un proceso que vale la pena ser escéptico sobre la gestión de riesgos implícita.

Hay un gran informe de experiencia publicado en la conferencia XP2008 ( Gestión de riesgos explícitos en procesos ágiles por Nelson, Taran e Hinojosa ) que describe el éxito de un equipo que incorporó el paradigma de gestión continua de riesgos del SEI (Software Engineering Institute) con programación extrema. Un equipo anterior de XP en el que estuve tuvo un éxito similar.

Al incorporar prácticas de gestión de riesgos en equipos ágiles, descubrí que hay algunas cosas clave que se deben tener en cuenta (algunas de ellas se resumen en el documento de referencia):

• Recuerde que los equipos ágiles son democráticos y autoorganizados. Debe haber un rol de "administrador de riesgos" designado, pero la responsabilidad de identificar y priorizar los riesgos recae en el equipo. El administrador de riesgos es realmente solo un habilitador y facilitador.
• Mantener público el registro de riesgos. Los wikis funcionan bien para esto al igual que otros medios.
• Centrarse en las prácticas que proporcionan el máximo valor. En mi experiencia, el uso de la votación múltiple para priorizar los riesgos es tan efectivo como la clasificación por exposición , lleva mucho menos tiempo y es una actividad inclusiva (buena para los equipos ágiles).
• Utilice el taller de evaluación de riesgos de equipos mini-pequeños en lugar del taller completo del SEI. La versión mini tarda un día o menos, mientras que la versión completa requiere unos 5 días. Si su equipo está bien versado en la gestión de riesgos, puede realizar talleres aún más ligeros y seguir siendo eficaz.

El pensamiento actual en la comunidad Agile es que la gestión de riesgos es importante. La mayoría de los líderes de pensamiento Agile se han esforzado por hablar sobre la importancia de la gestión de riesgos con respecto a la agilidad. Dicho esto, no he visto mucho trabajo realizado para hacer que la gestión de riesgos sea más accesible para los profesionales ágiles y todavía hay una gran cantidad de literatura popular disponible que ignora por completo el tema.

¿Eso significa que durante el ciclo de vida de un proyecto Agile, no hay planificación de riesgos?

Cuando la gente dice que se gestiona de forma implícita, es de esperar que se refiera a que se gestiona de forma continua a lo largo del proyecto. Esto se hace analizando los riesgos en la planificación de sprints, retrospectivas, etc. El Scrum Master también tiene un papel importante en la eliminación de riesgos/impedimentos.

Continuando con Scrum como ejemplo, no prescribe explícitamente cómo se gestiona el riesgo. Sin embargo, Scrum es un marco y no una metodología de gestión de proyectos en toda regla: debe definir cómo gestionar los riesgos según sus necesidades. De hecho, no es raro que los propietarios de productos y los equipos mantengan listas de riesgos que se evalúan continuamente.

No soy un experto en Agile, pero creo que dos de las cosas que pueden hacer que parezca que no se hace una planificación de riesgos son el lenguaje y cómo se hace en la práctica.

Para el lenguaje, veo que la mayoría de los practicantes ágiles y las referencias se refieren a "impedimentos" en lugar de riesgos. Realmente es lo mismo, pero puede crear la ilusión de que no se hace la gestión de riesgos, cuando en realidad, los impedimentos/riesgos se discuten todos los días.

En el lado de la práctica, en un escenario de proyecto típico (en cascada), hará una planificación de riesgos por adelantado, principalmente porque tiene un proyecto de mayor duración y está buscando potencial en todo el proyecto. riesgos Por lo tanto, podría estar tratando de identificar los riesgos que pueden ocurrir dentro de 6 a 8 meses. Además, es posible que esté tratando con proveedores externos (piezas que se fabrican o entregas) que conllevan otro tipo de riesgo y están un poco más adelante. Entonces usted hace la identificación, planificación y gestión de 'riesgos'.

En un entorno ágil, este tipo específico de gestión de riesgos no siempre es necesario debido a los procesos utilizados. En un sprint de 2 a 4 semanas, tendrá un marco de tiempo más corto para mirar. Además, si está haciendo algún tipo de variación de Scrum, entonces puede tener reuniones diarias de pie, donde los riesgos pueden/se discutirán diariamente. En un tipo de proyecto más grande, estos solo pueden revisarse/actualizarse durante las reuniones de estado semanales.