Uno de los principales problemas que enfrentan los equipos de desarrollo basasdos en metodologías Agile o SCRUM es conseguir precisión al momento de estimar historias de usuario. Esto porque en no pocas ocasiones las estimaciones se ven afectadas por riesgos e incertidumbres que no fueron contemplados incialmente provocando que no se logre la realización de los compromisos del equipo.

En este artículo describimos un método heurístico (suficientemente preciso) para la determinación del nivel de riesgo que ofrece una historia de usuario y el impacto de ese riesgo en la estimación final de cada historia de usuario.

La historia se desenvuelve más o menos de la siguiente manera: el equipo debe estimar una historia de usuario y «basados en su experiencia previa» se le asigna un puntaje que describe de forma aproximada el esfuerzo, digamos 3 puntos, lo cual se aproxima a realizar las tareas necesarias en un periodo de 2 a 4 días; sin embargo, durante la ejecución de la historia de usuario el equipo se enfrenta a una serie de imprevistos que hacen que le tome 10 días y dan al traste con la realización de sus compromisos en la iteración.

La gran pregunta es ¿Cómo puede el equipo estimar los imprevistos que podrían encontrarse?

Definición heurística de Riesgo

En general se entiende riesgo como una medida subjetiva de probabilidad de que algo adverso suceda.

Podemos simplificar la definición de riesgo mediante el uso de medidas subjetivas como riesgo alto, medio o bajo; asignándole a cada medida una descripción que permita cierto grado de precisión a la hora de evaluar el nivel de riesgo de una historia de usuario.

En el desarrollo de sistemas podemos identificar dos puntos de vista desde los cuales se puede identificar niveles de riesgo: (1) Las dependencias externas (RDE) y (2) los niveles de «maestría procedimental» de las tareas a realizar (RMP).

Riesgo por Dependencias Externas (RDE)

El RDE o riesgo por dependencias externas es el nivel de riesgo al que está expuesta una historia de usuario cuando su ejecución exitosa depende de algún tipo de dependencia externa al equipo de desarrollo.

Así podemos definir un RDE bajo cuando no existen dependencias externas y toda la ejecución de la historia de usuario depende enteramente del equipo de desarrollo.

Hablamos de un RDE medio cuando la ejecución depende de un procedimiento externo conocido. Por ejemplo si para realizar una tarea se necesita la creación de cuentas de acceso por parte del equipo de seguridad de la empresa; y el procedimiento de solicitud, aprobación y realización de la creación de cuentas es expedito y conocido.

Finalmente, podemos referir un RDE alto cuando la realización de la historia de usuario depende de una tarea de mediana o alta complejidad realizada por un equipo externo cuyo tiempo de respuesta es desconocido o conocido pero alto.

Riesgo basado en Maestría Procedimental (RMP)

El RMP o Riesgo basado en Maestría Procedimental se refiere al nivel de riesgo asociado al nivel de conocimiento de los procedimientos que se deben realizar para la ejecución de una historia de usuario.

En primer lugar, un RMP bajo se puede asignar a una historia de usuario donde las tareas a realizar son ampliamente conocidas por el equipo de trabajo; es decir ya se ha realizado antes de forma rutinaria y se cuenta con ejemplos de lo que hay que hacer en diversas otras áreas del proyecto. Un ejemplo escueto de esto sería la creación de una nueva entidad en la base de datos.

En segundo lugar un RMP medio se asigna entonces a una historia de usuario donde las tareas se conocen pero se tiene poca experiencia procedimental. Es decir, se ha hecho pocas veces (una, dos o tres) y no se cuenta con una maestría tangible sobre los procedimientos a realizar.

En tercer lugar un RMP alto se asigna a una historia de usuario donde se desconoce las tareas o procedimientos específicos necesarios, o se conocen pero nunca han sido realizados, o han sido realizados muy pocas veces (dos o menos).

RMP * RDE: Una mezcla sencilla

Podemos realizar una simplificación adecuada asignando a nuestras historias de usuario el riesgo más alto (RMAX) de ambas métricas.

La siguiente tabla (1) ilustra esta mezcla. Nótese que cuando ambos RMP y RPE son definidos como alto riesgo, se considera RMAX como riesgo ultra-alto.

Tabla 1 – RMAX

Ajuste de las Estimaciones

Usualmente las estimaciones de historias de usuario se basan en un sentido de esfuerzo necesario para la ejecución de la historia, determinada por la experiencia del equipo de desarrollo. Generalmente se agregan consideraciones subjetivas de incertidumbre para encarecer o modificar las estimaciones de esfuerzo.

Mediante el método MHER presentado en este artículo se ajustan las estimaciones para asegurar que estas contemplen los niveles de riesgo RMP y RDE asociados.

Una vez definido el nivel de riesgo RMAX estimado de una historia de usuario podemos ajustar las estimaciones de esfuerzo.

Una forma sencilla de hacer esto es estableciendo puntos mínimos para los distintos niveles de riesgo.

La siguiente tabla (2) muestra estos puntos mínimos.

Tabla 2 – Puntos Mínimos

Así, una historia de usuario que el equipo estima en un par de horas de tiempo, que usualmente se traduce en 1 punto, pero para la cual el riesgo por dependencias externas (RDE) es alto, deberá estimarse en 8 puntos o en un caso extremo en 5.

La siguiente figura (1) ilustra de forma resumida el método MHER descrito en este artículo.

Figura 1 – Método MHER Resumido

Mitigación del Riesgo

Una vez ajustada la estimación, vale la pena evaluar posibles acciones para mitigar los riesgos. Estas acciones pueden incluir:

  1. Historias de Investigación (SPIKES): Una de las técnicas comunes en el mundo SCRUM para mitigar el riesgo son las historias de usuario orientadas a aclarar lo que se necesita hacer. Esto es particularmente útil cuando el riesgo elevado es de tipo maestría procedimental (RMP). Este tipo de historias de usuario (SPIKE) nos permite investigar los procedimientos necesarios y adquirir mayor maestría procedimental reduciendo así el nivel riesgo RMP.
  2. Historias de Habilitación (ENABLERS): Una técnica menos común es el uso de historias de habilitación (enablers) para reducir los niveles de riesgo relacionados con dependencias externas (RDE). En general son historias sin puntaje que identifican la necesidad de seguimiento para la ejecución de alguna dependencia externa. Por ejemplo la creación de cuentas de acceso, o de recursos externos.
  3. División de la historia: Ante una historia de 13 puntos, e incluso una de 8 puntos generalmente se pueden identificar oportunidades para dividirlas en historias de usuario más pequeñas. Digamos una de 13 puede dividirse en cinco historias de 3 puntos cada una. Dividir las historias de usuario permite tener historias alcanzables con menor riesgo.

 6,990 total views,  3 views today

0Shares
Última modificación: febrero 7, 2020

Autor

Comentarios

Escribe una respuesta o comentario

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.