Por lo general, en un proceso ágil como Scrum, no hacemos un análisis inicial como en el modelo de cascada. Cómo identificar el riesgo del proyecto en un proceso ágil.
No estoy de acuerdo con la afirmación de que en SCRUM el análisis de riesgos no se realiza por adelantado.
Qué pasa --
Análisis de riesgo cuando se prepara y estima una historia durante la planificación de SPRINT --->
Considerar y tener en cuenta los riesgos (y considerar la mitigación: ¿nuevas historias?, "la historia es demasiado grande y arriesgada: desglosarla", "no hay prueba para detectar la regresión; no puedo comprometerme con esta historia a menos que se escriban pruebas de regresión", etc. etc.) ¿cuándo se arregla la historia?
¿Considerar y tener en cuenta los riesgos cuando se estiman los puntos de la historia?
¡No creo que uno esté implementando SCRUM correctamente si el análisis de riesgos formal no es parte del proceso de planificación de SPRINT! Estaría muy nervioso como PM, si no se analizan los riesgos, se discuten y se proponen mitigaciones antes de enviar una historia a la junta
El hecho de que el software se desarrolle utilizando Agile no significa que no pueda haber un esfuerzo de gestión de proyectos paralelo, lo que probablemente generará spam en varios sprints.
Independientemente de la metodología de desarrollo que esté utilizando, existe una serie de riesgos que se pueden conocer de antemano. Estos deben ser identificados y mitigados. Durante el proyecto es probable que se identifiquen riesgos adicionales.
Muchos de los riesgos son bastante estándar y tienen soluciones conocidas. Es importante identificarlos y poner prácticas de mitigación en los lugares. Aquí hay una lista de algunos de los riesgos que puede considerar.
Hay riesgos adicionales específicos del proyecto que deben tratarse proyecto por proyecto. Éstos incluyen:
El problema no es que la gestión de riesgos no se realice por adelantado en los procesos de desarrollo de software Agile. El problema es que la gestión de riesgos no se hace de forma explícita , es decir, la gestión de riesgos está implícita en los procesos ágiles, por lo que los equipos no tienen la misma noción de gestión de riesgos que espera la gestión de proyectos tradicional. Esto no quiere decir que la gestión de riesgos explícita y ágil no puedan trabajar juntas.
El paradigma de Gestión Continua de Riesgos de SEI encaja muy bien con los procesos ágiles. La mejor manera que conozco de combinar CRM con Agile es realizar un "mini" taller de evaluación de riesgos de software utilizando el cuestionario basado en la taxonomía de riesgos de SEI como guía. Los mini-SRE tardan desde unas pocas horas hasta un día en completarse y no solo enseñan a un equipo lo que necesitan saber para identificar y gestionar riesgos, sino que también crean la acumulación de riesgos inicial necesaria para avanzar con otras partes de los procesos Agile. Tal taller debería ocurrir durante Sprint 0 y actuar como una guía para ayudar al cliente a decidir en qué cosas trabajar primero y otras cosas que no son de desarrollo en las que el equipo debería estar trabajando.
Estoy de acuerdo en que Scrum no habla explícitamente sobre la evaluación de riesgos como lo hace Waterfall.
Sin embargo, hay una serie de oportunidades para manejar el riesgo dentro del marco de scrum. Comenzando con el ejercicio de refinamiento de la cartera de pedidos. Me gusta usar BDD para esta parte, y donde las áreas son particularmente complejas, use un formato de 3 amigos para comprender el enfoque correcto.
De esta manera, la mayoría de los riesgos se identifican antes de la planificación del sprint. Incluso si los riesgos se descubren durante la planificación del sprint o incluso durante el sprint, Scrum permite repensar los objetivos del sprint y volver a colocar las historias en la cartera de pedidos para un mayor refinamiento.
El refinamiento de la cartera de pedidos alberga efectivamente el trabajo de análisis y priorización de una manera más iterativa que el análisis inicial que se ve en cascada.
Como puede ver, la gestión de riesgos y el análisis profundo están presentes, pero se realizan en fragmentos de trabajo más pequeños a medida que avanzan otras áreas de funcionalidad.
Esto conduce a un diseño de solución "evolutivo", ya que pueden surgir cosas que conduzcan a cambios en la implementación existente, por lo que existe una compensación entre el impulso y la parálisis del análisis.
Depende de lo que esté construyendo, pero la mayoría de la gente prefiere el impulso.
Debido a la naturaleza de las metodologías ágiles, los riesgos no se identifican desde el principio, como en el modelo en cascada, sino que la identificación y mitigación de riesgos se lleva a cabo a lo largo del proceso . Como están tan incorporados en las ceremonias que realiza en Agile, como el scrum diario, es posible que no le parezca que se lleva a cabo un análisis de riesgos. Por supuesto, esto es lo que hace que el método ágil sea mucho más adaptable que el método en cascada.
En términos de riesgos, hay riesgos que se pueden identificar como riesgos generales en cualquier proyecto que emprenda, mientras que otros riesgos son más específicos del proyecto en sí . Son estos últimos los que se identifican y reducen tan bien cuando se usa Agile.
"Agile" es un conjunto de valores y principios, no un marco. Por lo tanto, me referiré específicamente al marco Scrum como una línea de base razonable, con el entendimiento de que otros marcos ágiles a menudo aprovechan Scrum o contienen enfoques similares que son al menos comparables.
El riesgo del proyecto y la gestión del riesgo no están excluidos de ninguna metodología ágil. Por lo general, no existe un requisito explícito para un registro de riesgos por separado, o un mandato para los elementos relacionados con el riesgo en la cartera de productos. Dicho esto, los principios y la teoría detrás de marcos como Scrum hacen que la gestión de riesgos sea una actividad continua que forma parte de numerosos eventos y artefactos , por lo que solo necesita replantear cómo ve la gestión de riesgos en un contexto ágil.
La noción de un registro de riesgos por adelantado es que ya ha definido todo el trabajo y, por lo tanto, conoce todos los riesgos potenciales. Esto suele ser una falacia en la práctica, pero sigue siendo la base para suponer que puede hacer un registro de riesgos por adelantado.
Los marcos ágiles como Scrum se basan en la planificación justo a tiempo y el diseño emergente. El marco dice específicamente:
El proceso emergente y el trabajo deben ser visibles tanto para quienes realizan el trabajo como para quienes lo reciben. Con Scrum, las decisiones importantes se basan en el estado percibido de sus tres artefactos formales. Los artefactos que tienen poca transparencia pueden conducir a decisiones que disminuyen el valor y aumentan el riesgo.
Además, el Product Backlog suele ser una fuente implícita de seguimiento de riesgos, que se puede hacer explícito convirtiéndolo en un atributo de dominio que se incluye en los elementos del Product Backlog.
El refinamiento de la cartera de productos es el acto de desglosar y definir aún más los elementos de la cartera de productos en elementos más pequeños y precisos. Esta es una actividad continua para agregar detalles, como una descripción, orden y tamaño. Los atributos a menudo varían con el dominio del trabajo.
La conclusión clave es que los riesgos a menudo se identifican durante el Refinamiento del Backlog, la Planificación de Sprint, los picos de historias, las Retrospectivas de Sprint y otras actividades dentro de Scrum. Por ejemplo:
En otras palabras, no es que los riesgos no se aborden. Simplemente se abordan todo el tiempo durante todo el proceso. La principal diferencia con las metodologías más tradicionales es que la gestión de riesgos es parte del marco continuo y los procesos de mejora continua, en lugar de una actividad única o inicial. Además, dado que Scrum es iterativo, emergente y se enfoca en la planificación justo a tiempo, los riesgos generalmente se abordan en el último momento responsable en lugar de todos a la vez. Hay muchas razones para esto, pero la más importante es que un principio central de los marcos ágiles es optimizar el trabajo innecesario:
La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Abordar los riesgos que quizás nunca entren en el alcance, o que puedan resolverse u obviarse antes de que afecten el proyecto de alguna manera, es un beneficio clave de la agilidad. En términos más simples, no perder tiempo identificando riesgos que (todavía, o posiblemente nunca) necesitan ser identificados o gestionados es una pérdida de tiempo, y Scrum específicamente optimiza eso al promover un enfoque justo a tiempo para la gestión de riesgos. .
Todas las metodologías ágiles, especialmente scrum, tienen principios y valores fundamentales que, si se siguen debidamente, mitigarán los riesgos futuros. El enfoque iterativo y la transparencia ayudarán a darse cuenta de cualquier riesgo asociado con el proyecto. Una de las ceremonias de Scrum, que es Daily Stand-up, ayuda a darse cuenta de cualquier escalada o posibles riesgos que puedan resultar de esto. En resumen, las metodologías ágiles, si se adoptan, mitigarán los riesgos en su proyecto.
asolanki