lunes, 3 de octubre de 2016

SCRUM: Gestión Ágil de Riesgos - Modelo

Este post fue origen de datos para que pudiera dar una charla de gestión de riesgos y quería compartirlo con ustedes...
 DevOps Journey LATAM, 02/12/2016, Hotel Atton el bosque. Agile Risk Management in devops Context.

Gestión Ágil de Riesgos


Si bien la gestión de riesgos no es parte de scrum y un facilitador no se encarga de la gestión al modo tradicional como la gestión de riesgos, sí debería velar por mitigar los problemas que surjan en el proyecto y apoyar, en consecuencia, a la gestión de riesgos. En este sentido, no solo se encargaría de ayudar a desbloquear issues y reducir impedimentos para que el sistema de trabajo fluya en el procesamiento de PBIs (Product Backlog Items), sino que también puede preocuparse de prever issues para anticiparse a los problemas y controlar así, de antemano y en la medida de lo posible, los riesgos asociados a bloqueos del flujo de trabajo que atentan contra los objetivos del proyecto.
fig.1: Diagrama riesgos vs problemas.

Lo difícil es lograr una gestión de riesgos ágil en vez de una gestión pesada, dificultosa y que demande mucho esfuerzo de gestión. En esta vía, es preferible mantener un simple registro de riesgos con información concisa. Los datos principales a registrar de un riesgo, además de su nombre, pueden ser: descripción, probabilidad (probability), impacto (severity), criticidad (criticality), acciones de mitigación, dueño y estado.
fig.2: estado de riesgos.

Algo simple que se puede lograr trabajando con criticidad es usar tres valores en la probabilidad de ocurrencia y en el impacto (1, 2 y 3). El impacto representa la severidad de la ocurrencia de un problema asociado al riesgo o el tiempo perdido (size of loss). Por otro lado, la criticidad representa la prioridad del riesgo o el grado en que ese riesgo afecta negativamente al proyecto (exposure). El mismo será resultado del producto entre la probabilidad y el impacto. En consecuencia, la criticidad podría ser: 1, 2, 3, 4, 6, 9.

Las herramientas gráficas que se pueden usar para dar visibilidad de los riesgos son: a) la “matriz de riesgos”; b) el “histórico de criticidad”; c) o el gráfico de curva de riesgo quemado (Risk Burn-down Chart).

La gestión de riesgos no es independiente de la gestión de impedimento o de problemas o “issues”. Muchos de los problemas surgidos en el proyecto están asociados a riesgos identificados. Por tal motivo, la gestión de riesgos es útil, porque podemos mitigar los problemas de antemano. Por dicha razón, puede ser valioso llevar un registro de los issues y su relación con los riesgos. Siempre sin perder de vista no caer en el énfasis de la documentación ni en el afán de reportar. Se debe buscar la simplicidad y el foco en el flujo de trabajo sin impedimentos.

Las herramientas gráficas útiles para dicha gestión son: “Tablero de Obstáculos” (obstacle board) o el calendario de issues (Issues calendars).

Referencia:

Risk Management in Agile, Satheesh Thekku Veethil, Scrum Alliance Org., 3 May 2013

Managing Risk on Agile Projects with the Risk Burndown Chart by Mike Cohn. Mountain goat software, April 8, 2010.

1 comentario:

  1. "...la gestión de riesgos en Scrum es otro reto para manejar en empresas con CMMI, pues la identificación y registro de los riesgos no es algo explicito dentro de las prácticas de Scrum sino que es una práctica continua que identifica los riesgos a través de las reuniones diarias y que se gestionan a través de las acciones tomadas para eliminar los impedimentos. Un equipo Scrum observado percibe que la mitigación del riesgo no tiene un dueño, el consultor comenta que en equipos autogestionados no hay dueño de nada, sino la sinergia de un equipo." Caso de estudio sobre apropiación de Scrum en empresas que han adoptado CMMI, Proyecto de grado para optar al título de magíster en ingeniería, Silvia Isabel Lozano Argel, Universidad EAFIT, Escuela de Ingeniería, 2013.

    ResponderEliminar