Realmente es algo de lo que todavía no se habla mucho dentro de las metodologías ágiles, no existe ningun template o framework oficial. En las metodologías clásicas tipo PMI, se presta mucha atención a los riesgos, ocupando una de las áreas de conocimiento del PMBOK. Al comienzo del proyecto se listan los riesgos, se discuten con el equipo y otros interesados, se le asigna una probabilidad y un impacto, se calcula la severidad, se acepta el riesgo o se prepara un plan de mitigación si vale la pena. Lamentablemente, este plan queda generalmente abandonado cuando se está acercando la fecha de entrega del proyecto y el ritmo de trabajo aumenta. El PM es el dueño de la administración de riesgos en el proyecto y tiene que dedicarle esfuerzo y tiempo al control y monitoreo de estos.
En Scrum, parte de la administración de riesgos es implícita, dentro del framework: Al usar Sprints cortos, realizar reuniones y revisiones periódicas, mantener comunicaciones más eficientes y manejar a un equipo autoadministrado trabajando cerca con el cliente, priorizando, inspeccionando y adaptándose a los cambios y a nueva información. Sin embargo no todo está contemplado por las prácticas de scrum, el mismo Ken Schwaber lo reconoce: “Scrum purposefully has many gaps, holes, and bare spots where you are required to use best practices – such as risk management.”. Hay ciertos riesgos que son externos al proyecto, y que deben ser administrados por el equipo. Alguno de estos son:
- Riesgos políticos involucrados en la relación del equipo con el product owner, y de la posición e influencia de esta persona dentro de la organización.
- Riesgos financieros y legales.
- Riesgos de trabajar con otras empresas y de tercerizar.
- Factores de infraestructura y medio ambiente del equipo de trabajo.
- Riesgos de integración e interdependencia con otros proyectos, conflictos de recursos.
- Distribución o implementación del producto
Para cerrar este artículo, podemos concluir que se necesita administración de riesgos en proyectos manejados por Scrum, enfocados más afuera que adentro, ya que Scrum ayuda a minimizar riesgos de alcance, calendario y calidad mediante sus principios y prácticas. Scrum es ingenuo en asumir que el desarrollo de software se hace en un vacío, sin que nada pueda afectar al proyecto fuera del equipo. Aunque asumamos que el equipo trabaja correctamente con riesgos técnicos y que otros riesgos inmediatos de calendario se contienen trabajando incrementalmente y utilizando buenas practicas, hay que monitorear y administrar riesgos y problemas fuera del desarrollo del producto. El correcto manejo de estos riesgos externos puede hacer la diferencia entre un éxito y un fracaso.
Fuentes: La fuente principal que nutre este artículo es el blog Building Real Software de Jim Bird. Luego también saque información de Thushara Wijewardena en el blog Projectized y de Agile101. Estos dos últimos proponen un acercamiento ágil de la administración de riesgos, les recomiendo que le pequen una mirada.
No hay comentarios.:
Publicar un comentario