La gestión del riesgo se refiere a reducir la probabilidad e impacto de los eventos adversos en un proyecto. El desarrollo Ágil de software, debido a su carácter iterativo, implícitamente hace que la gestión del riesgo forme parte del ciclo de vida del proyecto. Los miembros de la comunidad Ágil discutieron si es necesaria la gestión del riesgo explícita, la capacidad de Scrum para gestionar todos los tipos de riesgo y que debería hacer la gestión de riesgos.
Michele Sliger sugiere que en el desarrollo de software Ágil el riesgo se gestiona todo el tiempo: en parte en el Scrum diario, en las reuniones de planificación de cada iteración, en las reuniones de planificación de release, y también en las reuniones de revisión y retrospectiva. Sin embargo, ella sugiere un enfoque estructurado para la gestión de riesgo. Los pasos incluyen:
Identificación de riesgos - todo el equipo hace este ejercicio en forma iterativa. Los resultados se registran en una pizarra blanca o en rotafolios.
Análisis de Riesgos – en el análisis cualitativo se usa el juicio, la intuición y la experiencia para determinar los riesgos y las posibles pérdidas. En proyectos ágiles los ciclos de desarrollo son cortos y con constantes revisiones, lo que hace que esto sea posible y eficaz. Esto es diferente en los proyectos tradicionales en los que el análisis cuantitativo se realiza y los números se asignan a los daños que puedan producirse.
Planificación de Respuesta al Riesgo - todo el equipo participa en el desarrollo de opciones y acciones para reducir las amenazas.
Control y Monitoreo del Riesgo – el riesgo es objeto de seguimiento, y al final de cada iteración se discuten las estrategias de Control. Los riesgos también se monitorean diariamente mediante el uso de radiadores de información.
Ron Jeffries señala que los riesgos no son temas bloqueados, sino que está en lista que mira el ScrumMater, como una nota de las cosas podrían ir mal. Según él, los riesgos se pueden dar de diversas formas, como contenido no realizado, tecnología nueva o desconocida, equipos geográficamente dispersos, la interdependencia con otro proyecto, etc. Un equipo de Scrum puede ordenar historias por valor y riesgo y trabajar en las historias de mayor riesgo para identificarlos correctamente y mitigarlos. El riesgo debe añadirse como una historia en el backlog y tenidos en cuenta.
Michael James sugiere que en un proceso de desarrollo de software como Scrum se encarga del riesgo a principios de ciclo de vida del proyecto. Ofrece diversas vías como el Scrum diario, revisiones de sprint, etc donde los riesgos pueden ser presentados y resueltos. Según Michael, Scrum no requiere que se cree un registro de riesgos, sin embargo, los riesgos pueden ser gestionados por el equipo de forma periódica.
En una nota diferente, algunos seguidores de las metodologías ágiles creen que Scrum no puede ayudar con los riesgos que son externos al proyecto. Scrum puede ayudar con riesgos relacionados con el cambio en los requisitos, la falta de comunicación y bajo rendimiento de los miembros del equipo. Sin embargo, los riesgos que son externos al proyecto necesitan más que Scrum para se resuelvan.
Paul Hudson se hizo eco de ideas similares en el grupo de desarrollo de Scrum. Sugirió que aunque Scrum puede manejar la mayoría de los riesgos en un proyecto, los riesgos que no se pueden manejar a nivel del equipo no se pueden manejar con Scrum. Dio ejemplos de algunos riesgos, como la falta de comprensión de Scrum del cliente, productos de terceros que no funcionan como se esperaba, factores externos de los cuales el proyecto depende y que pueden no ocurrir en el tiempo, la pérdida o corrupción de los datos en los sistemas del equipo, el cliente no logra tener un representante, los clientes tienen agendas personales que entran en conflicto con los objetivos del proyecto, etc.
Otra cuestión muy debatida en la comunidad es "¿Quién debe ser responsable de la gestión del riesgo?". De acuerdo con Michele Sliger, todo el equipo de Scrum posee la gestión del riesgo y son responsables de mitigarlos juntos.
En un debate sobre el grupo de Desarrollo de Scrum, Ron Jeffries sugiere que en los "términos de Scrum" es responsabilidad del dueño del producto gestionar el riesgo. Algunos miembros están de acuerdo con Ron que el dueño del producto es la mejor persona para decidir qué riesgos deben mitigarse, ya que es el que mejor entiende el negocio. El dueño del producto puede tomar los aportes de todos los miembros del equipo, pero la responsabilidad final recae en él. Peter Stevens agregó "Como jefe que paga las cuentas, el dueño del producto está directamente interesado en la mitigación del riesgo. El ScrumMaster y el equipo debería / ayudará al dueño del producto a la óptima priorización del backlog. Pero como el retorno de la inversión es responsabilidad del dueño del producto y la consecuencia de este riesgo es costo, la responsabilidad final del riesgo es del dueño del producto".
Otros miembros del grupo sugiere que la gestión del riesgo es una responsabilidad del equipo y todos en el equipo de Scrum tiene que trabajar en forma colaborativa para resolverlos.
Por lo tanto hay una diferencia de opinión sobre si todos los riesgos pueden gestionarse con Scrum o si los riesgos deben ser administrados explícitamente. La mayoría de los miembros de la comunidad Ágil están de acuerdo en que los riesgos relacionados con el proyecto se pueden manejar bien con Scrum. Sin embargo, hay una desconexión cuando los riesgos son externos al proyecto. Del mismo modo, no hay consenso en quien es el responsable de la gestión del riesgo. Para muchos todo parece indicar que la responsabilidad de la gestión del riesgo la tiene que llevar el dueño del producto, sin embargo algunos agilistas creen que el riesgo debe ser administrado por el equipo en su conjunto.
Traducido de InfoQ
