¿Cómo debemos aplicar la priorización de MoSCoW a los requisitos de nuestro proyecto?

TL; DR

El método MoSCoW proporciona un marco para priorizar en función de la clasificación de elementos por categorías. Está destinado a ser flexible, por lo que debe personalizarlo para su proyecto. Puede ajustar las definiciones y los criterios para cada nivel según sea necesario, y puede o no necesitar hacer una distinción entre las funciones Debería tener y Podría tener . Sin embargo, lo más seguro es que necesite mantener una distinción entre Debe tener , No tendrá y cualquier función que sea hasta cierto punto opcional.

Priorización y Alcance

La página a la que se vinculó en su pregunta original contiene definiciones de muestra y criterios de filtrado para cada nivel. No repetiré su explicación perfectamente útil, pero tal vez sea más claro si lo considera como un ejercicio de alcance.

1. Las características imprescindibles son parte del producto mínimo viable y deben permanecer dentro del alcance .
2. Las características que no tendrá (esta vez) están explícitamente fuera del alcance del proyecto actual, pero podrían revisarse en proyectos futuros.
3. Las características Debería tener/Podría tener están en el alcance, pero se pueden modificar o eliminar durante el ciclo de vida del proyecto porque no son esenciales para el producto mínimo viable.

Definiciones y criterios de filtrado para cada nivel

La página a la que se vinculó en su pregunta original contiene definiciones de muestra para cada uno de los niveles. Además, la sección 10.3 contiene orientación sobre cómo definir cada nivel para su proyecto específico y cómo determinar la categorización. Dice, en parte:

Antes de la captura de requisitos, es necesario acordar con la empresa las definiciones de debe tener, debería tener, podría tener y no tendrá. Algunos ejemplos se describen arriba. Sin embargo, la definición de Must Have no es negociable. Cualquier requisito definido como Must Have tendrá un impacto crítico en el éxito del proyecto. El Gerente de Proyecto o el Analista de Negocios debe desafiar los requisitos si no son Obligaciones Obvias; Depende del Business Visionary o su Business Ambassador empoderado demostrar que un requisito es imprescindible. Si él / ella no puede, es un debería tener en el mejor de los casos.

Dicho de otro modo, cada proyecto debe:

1. Realice el ejercicio de definir cada nivel según se aplique al proyecto actual. Las definiciones pueden variar entre organizaciones, e incluso entre proyectos dentro de una sola organización, a menos que la organización haya creado un estándar interno.
2. Haga que las partes interesadas justifiquen cada categorización, especialmente la categoría Debe tener, en función de sus impulsores comerciales. Esto variará según los objetivos del proyecto y debe evaluarse dentro del contexto del estatuto del proyecto.

Creo que los necesitas a todos para tener una conversación. Primero, categoriza todos los requisitos y luego revisa el resultado y ve qué se puede mover hacia abajo en la lista. Después de un par de iteraciones, tendrá una pirámide de requisitos: debe en la parte superior, no tendrá en la parte inferior. Usará sus recursos en la parte superior y traerá el resto a la próxima discusión.

Tenga en cuenta que la categorización se puede hacer a corto y largo plazo. Por ejemplo, algo ahora puede caer en lo que podría tener ahora (una infraestructura de AWS en lugar de una solución de rack), pero puede convertirse en algo imprescindible en breve: aumento en la base de clientes, necesidad de escalabilidad.

Me estoy preparando para el AEC y el CSM, y probablemente ayudaría si lo ve desde una perspectiva Agile más amplia.

El dominio uno de las prácticas ágiles es la entrega impulsada por el valor. Las "Prácticas para la Entrega de Impulso de Valor" incluyen:

• Evaluación del valor
• Valor de planificación
• Valor de la entrega
• y así...

La planificación del valor implica la "priorización valorada por el cliente" con la intención de obtener primero los productos o características de mayor valor para el cliente. MoSCoW es solo una de las muchas opciones disponibles para usted.

Como alguien ya explicó, es poner su requisito en cubos, o la forma en que el libro le gusta decir "Agrupaciones de afinidad" en función exactamente de esas características:

• Debe tener
• Debería tener
• Podría tener
• Me gustaría tener (pero no esta vez).

¡¡¡Simplemente depende de ti después de eso!!! Otros esquemas de priorización de valor para el cliente que podría usar incluyen:

• Esquemas simples ("prioridad 1", "prioridad 2", etc.);
• Dinero de monopolio (presupuesto del proyecto representado con dinero ficticio y los clientes asignan una parte de esa cantidad fija a las funciones que más desean);
• método de 100 puntos (Dean Leffingwell y Don Widrig);
• Análisis de Kano (método de Noriaki Kano para agrupar en Excitadores, Satisfactorios, Insatisfactorios e Indiferentes).

Entonces, nuevamente, depende de usted cómo lo ejecuta y tiene más que MoSCoW para elegir. :-)