.

Adaptación del Alcance en Scrum Agile

boceto-proyecto

La principal diferencia entra la gestión del alcance de un proyecto Agile y uno tradicional, es que en la gestión tradicional el alcance se define y acuerda por adelantado, antes de iniciar el diseño y la construcción/implementación.

En los proyectos ágiles, sólo una parte del alcance se define desde el principio, tanto como sea necesario para llevar a cabo las primeras iteraciones, por lo que empezamos a diseñar y construir la solución con el alcance incompleto.

Mientras que desarrollamos la iteración, vamos añadiendo nuevos elementos al Backlog de Producto y refinando los ya existentes, en base a la retroalimentación que recibimos de los clientes y la mejor comprensión que vamos teniendo del proyecto conforme este avanza. Esta es, como ya hemos comentado, una de las principales características de un ciclo de vida de adaptativo.

El Backlog de Producto es nuestro aliado.

El Backlog de Producto es un concepto dinámico en el que almacenamos los artículos (historias de usuario) pendientes de desarrollar. Así que; Cuando hemos terminado con un artículo, lo sacamos del Backlog de Producto.

Al seleccionar el número de elementos del Backlog de Producto que se desarrollarán en la próxima iteración, los sacamos del Backlog de Producto y los trasladamos al Backlog de la iteración (Backlog del Sprint en caso de utilizar Scrum);

Si un artículo no se ha completado al finalizar la iteración, lo ponemos de nuevo en el Backlog de Producto, incluso si está en curso.

Por lo general asignamos un valor de negocio a cada elemento del Backlog de Producto y ordenamos la lista en función de dicho valor, de mayor a menor: los artículos con más valor se colocan en la parte superior. Cuando iniciemos una nueva iteración comenzaremos escogiendo los productos de la parte superior del Backlog de Producto, lo que significa que siempre desarrollamos primero los elementos que tienen más valor de negocio. De esta manera logramos mantenemos enfocados en el valor y en las necesidades del negocio.

Algunos marcos ágiles utilizan métodos como la técnica de priorización MoSCoW en lugar, o en combinación, con la asignación de valores de negocios para ordenar los elementos del Backlog.

El Backlog de Producto es la herramienta principal de planificación en la mayoría de marcos Ágiles. Comprende, de manera sencilla,  el alcance del proyecto, una estimación del tiempo, los recursos, riesgos, y el plan de calidad.

Requerimientos funcionales vs. No funcionales

Cada elemento del Backlog de Producto contiene un requisito (requerimiento o parte) de la solución final, preferiblemente en forma de historia de usuario. El manejo de los requerimientos no funcionales, plantean a menudo un problema ya que son de naturaleza técnica; si bien las historias de usuario, como ya hemos explicado,  deben ser de carácter no técnico.

Los ejemplos que hemos planteado anteriormente son todos características funcionales. Sin embargo otros requisitos, como los de rendimiento y seguridad, son ejemplos de requerimientos no funcionales.

Las requerimientos no funcionales aplican a casi todas los requerimientos funcionales. Por ejemplo, si consideramos el rendimiento hay consideraciones de rendimiento en cada característica funcional;

“Cómo usuario de la tienda de moda virtual quiero filtrar los artículos que me interesan por talla, para ver solo aquellos que estén disponibles en mi talla”. Hasta aquí, aquí sería la parte “funcional”. La clave está en que al realizar esta simple búsqueda, no esperamos que realizarla vaya a llevarnos dos minutos, esperamos hacerlo en un tiempo determinado (velocidad) y con una seguridad mínima, ambos son ejemplos de requerimientos “no funcionales”.

La solución pasa por incluir los requisitos no funcionales en la “Definición de Completo” (DoD). La Definición de Completo es un concepto que contiene todas las cosas que debemos hacer o tener en cuenta para considerar una historia de usuario cómo “completa”. Los procesos de desarrollo, criterios de calidad, normas de codificación, y las características no funcionales son todas partes de la Definición de Completo, en ingles Definition of Done (DoD) .

Cuando desarrollemos cualquier historia de usuario, tendremos que compararla con los requisitos no funcionales mencionados en la definición de completo, y no los consideraremos como “completos”, a menos que cumplan con todos ellos. Esto es lo que se suele conocerse como criterios de aceptación en entornos tradicionales y es una parte de la planificación de la calidad.

Algunos requisitos no funcionales podrían ser aplicables sólo a algunas historias de usuario, y no sería apropiado incluirlos en la definición de “completo”. En dicho caso, simplemente lo añadiríamos a la historia de usuario por la parte de detrás de la tarjeta.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  miguel

Dirección proyectos TI y #ecommerce bajo Prince2 o Scrum . Usabilidad, Conversión, Seo, AdWords, Marketing online, Analítica. Consultor y desarrollador.

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR