Diferencias en la priorización de requisitos entre Waterfall y Scrum

El proceso de desarrollo de software predominante antes de que Agile apareciera en escena era el proceso Waterfall. Scrum es el proceso ágil más popular. Intentaré enumerar algunas diferencias clave entre Waterfall y Scrum, tal como las veo:

1. La compensación entre costo y beneficio es un aspecto clave de Agile : en el proceso ágil, los equipos estiman el tamaño de la historia en puntos de historia y esto le da al propietario del producto la oportunidad de priorizarlos conociendo su costo relativo. En Waterfall, rara vez, si es que alguna, se estiman los requisitos individuales. En cualquier caso, apenas hay oportunidad para una discusión de compensación de costo vs beneficio.

2. En Agile, los requisitos siguen cambiando : en Waterfall, es muy difícil cambiar los requisitos: debe pasar por un doloroso proceso de control de cambios. Agile acepta requisitos cambiantes. Como se puede ver en la Guía de Scrum :

   El Product Backlog es dinámico; cambia constantemente para identificar lo que el producto necesita para ser apropiado, competitivo y útil.

3. En Waterfall, los requisitos generalmente se agrupan en 3 o 4 cubos : Algunas personas los agrupan en Alto, Medio y Bajo, otros usan el método MoSCoW . Pero en Agile todas las historias se enumeran en orden de serie. Esto ayuda al equipo de desarrollo a avanzar en la lista.

4. Agile tiene una única autoridad para priorizar : Agile nombra al Product Owner como la única autoridad para priorizar. En Waterfall no existe tal autoridad designada. A menudo es una decisión del comité.

5. Muchos equipos ágiles utilizan la noción de un MVP : muchos equipos ágiles crean un subconjunto de requisitos en un MVP (producto mínimo viable). El MVP a menudo se implementa en una población de usuarios de muestra para obtener comentarios tempranos.

Sin respuesta canónica

No hay una respuesta verdaderamente canónica a esta pregunta. En general, la forma en que se prioriza el trabajo es específica de los objetivos comerciales de la organización, la asignación de productos de trabajo a fechas de publicación específicas y las dependencias de los paquetes de trabajo. Esto suele ser cierto ya sea que la metodología sea ágil o no.

La visión pragmática

Pragmáticamente, las metodologías ágiles generalmente siguen un esquema de priorización ordinal o basado en colas en el que cualquier flujo de trabajo dado tiene una (y solo una) "prioridad n.° 1" en un momento dado. Esto contrasta con muchas metodologías tradicionales en las que no se aplica un orden estricto de prioridades.

Los proyectos no ágiles suelen utilizar un sistema basado en cronogramas basado en objetivos de entrega definidos por la administración, y los cronogramas se basan con frecuencia en cálculos de valor ganado o valor actual neto. En el mundo real, esto a menudo da como resultado muchos requisitos competitivos, todos los cuales son "prioridades principales" indiferenciadas para el negocio. Sin embargo, su millaje ciertamente puede variar.

Técnicas de muestra

Independientemente de la metodología, la priorización puede utilizar cualquier cantidad de técnicas, limitadas en gran medida por su imaginación organizacional. Algunos ejemplos incluyen:

• Ponderación relativa
• Camino critico
• Vanhoucke, M. y Demeulemeester, EL (2003). La aplicación de técnicas de programación de proyectos en un entorno de la vida real. Revista de gestión de proyectos, 34(1), 30–42.

Muchas técnicas no son inherentemente ágiles o no ágiles. Algunos funcionan bien cuando se usan juntos, y la mayoría están diseñados para respaldar el proceso de planificación del proyecto en lugar de reemplazarlo. Una vez más, su millaje puede variar.

Para priorizar tareas es necesario conocer algunas técnicas:

1. MOSCÚ
   ¿Qué debe, debería, podría y no quiere?
2. Funciones comercializables mínimas Las
   funciones se descomponen en las unidades comercializables más pequeñas de valor comercial útil entregable, con el fin de encajar en iteraciones cortas y garantizar la funcionalidad crítica que se implementa primero.
3. Retorno de la inversión (ROI)
   Demuestra cuánto retorno obtiene una organización al invertir en porcentaje
4. Tasa Interna de Retorno
   Una forma de expresar la ganancia como una tasa de interés ganada.

Y hay muchos otros, pero creo que estos son los más importantes.

Pero el cliente suele hacer la priorización.

La diferencia entre Agile y el enfoque tradicional es que en Agile el cliente hace la priorización ya que debe ver el resultado muy pronto, pero en los proyectos tradicionales ve el resultado al final, por lo que no necesita preocuparse por la secuencia de las tareas.

Impulsado técnicamente vs Impulsado por el valor

A menudo es cierto que en cascada, los requisitos simplemente están dentro o fuera del alcance, y el cliente no obtiene nada hasta que se completa. Pero el trabajo a menudo todavía se prioriza porque sucede en serie. En este caso, los requisitos pueden priorizarse puramente desde una perspectiva técnica: mirando todo el proyecto, ¿cuál es la forma más eficiente de proceder? y/o ¿cuál es la forma menos arriesgada de proceder?

En Agile, la priorización está impulsada por el valor y los lanzamientos incrementales a menudo van al cliente. Si bien las consideraciones técnicas y de riesgo deben discutirse con el cliente para que pueda tomar decisiones informadas, la priorización del valor para el cliente generalmente no se verá como la priorización técnicamente sensata. Entonces, por ejemplo, a menudo puede darse el caso de que alguna infraestructura mínima se realice temprano, para admitir características relativamente simples pero muy valiosas; y que luego se elimine y se reemplace con una infraestructura más robusta para admitir características más complejas pero menos valiosas.