Método MoSCoW

El método MoSCoW es una técnica de priorización. Se utiliza en el desarrollo de software , la gestión, el análisis empresarial y la gestión de proyectos para lograr un entendimiento común con las partes interesadas sobre la importancia que le dan a la entrega de cada requisito ; también se conoce como priorización MoSCoW o análisis MoSCoW .

El término MOSCOW en sí es un acrónimo derivado de la primera letra de cada una de las cuatro categorías de priorización: M - Imprescindible , S - Debería tener , C - Podría tener , W - No tendrá .

Las letras O intersticiales se añaden para que la palabra sea pronunciable. Si bien las O suelen escribirse en minúscula para indicar que no representan nada, también se utiliza la palabra MOSCOW escrita en mayúsculas.

Fondo

Este método de priorización fue desarrollado por Dai Clegg ^{[ 1 ]} en 1994 para su uso en el desarrollo rápido de aplicaciones (RAD). Se utilizó ampliamente por primera vez con el método de desarrollo de sistemas dinámicos (DSDM) ^{[ 2 ]} a partir de 2002.

MoSCoW se usa a menudo con la técnica de timeboxing , donde se fija una fecha límite para que la atención se centre en los requisitos más importantes, y se usa comúnmente en enfoques de desarrollo de software ágil como Scrum , desarrollo rápido de aplicaciones (RAD) y DSDM .

Priorización de requisitos

Todos los requisitos son importantes; sin embargo, para obtener los mayores beneficios empresariales de forma inmediata, es fundamental priorizarlos. Inicialmente, los desarrolladores intentarán cumplir con todos los requisitos obligatorios , deseables y opcionales, pero los requisitos deseables y opcionales serán los primeros en eliminarse si el plazo de entrega se ve comprometido.

El significado sencillo de las categorías de priorización tiene valor para que los clientes comprendan mejor el impacto de establecer una prioridad, en comparación con alternativas como Alta , Media y Baja .

Las categorías se entienden normalmente como: ^{[ 3 ]}

Debe tener: Los requisitos marcados como "Imprescindibles" son fundamentales para el éxito del proyecto dentro del plazo establecido. Si falta incluso un solo requisito imprescindible , la entrega del proyecto se considerará un fracaso (nota: los requisitos pueden ser reclasificados como imprescindibles con el acuerdo de todas las partes interesadas; por ejemplo, cuando se consideran más importantes los nuevos requisitos). "Imprescindible" también puede interpretarse como el acrónimo de "Subconjunto Mínimo Utilizable".

Debería haber: Los requisitos etiquetados como " Debería tener" son importantes, pero no necesarios para la entrega dentro del plazo actual. Si bien los requisitos "Debería tener" pueden ser tan importantes como los "Debe tener" , a menudo no son tan críticos en cuanto al tiempo, o puede haber otra forma de satisfacer el requisito, de modo que se pueda posponer hasta un plazo de entrega futuro.

Podría haber: Los requisitos marcados como " Podrían tener" son deseables, pero no necesarios, y podrían mejorar la experiencia del usuario o la satisfacción del cliente con un coste de desarrollo mínimo. Por lo general, se incluirán si el tiempo y los recursos lo permiten.

No lo tendré (esta vez): Los requisitos etiquetados como " No se incluirán" han sido acordados por las partes interesadas como los menos críticos, los de menor rentabilidad o los que no son apropiados en ese momento. Por lo tanto, los requisitos "No se incluirán" no se planifican en el cronograma del siguiente período de entrega. Estos requisitos se descartan o se reconsideran para su inclusión en un período posterior. (Nota: ocasionalmente se utiliza el término " Nos gustaría tener" ; sin embargo, este uso es incorrecto, ya que esta última prioridad indica claramente que algo está fuera del alcance de la entrega). (En las ediciones 3 y 4 del Libro de Análisis de Negocios, la "W" significa "Nos gustaría tener, pero no en esta ocasión").

Variantes

A veces, W se usa para significar deseo (o podría ), es decir, todavía posible pero improbable que se incluya (y menos probable que podría ). Esto se distingue de X, que significa excluido , para elementos que no se incluyen explícitamente. Se usa para indicar características que no son necesarias ahora, pero que deberían considerarse en términos arquitectónicos durante el diseño como oportunidades de expansión futuras; esto evita el riesgo de diseños sin futuro que impedirían que una característica en particular se ofreciera en el futuro.

Uso en el desarrollo de nuevos productos

En el desarrollo de nuevos productos , especialmente en aquellos que siguen metodologías ágiles de desarrollo de software , siempre hay más cosas que hacer de las que el tiempo o la financiación permiten (de ahí la necesidad de priorizar).

Por ejemplo, si un equipo tiene demasiadas épicas potenciales (es decir, historias de alto nivel ) para la próxima versión de su producto, podría usar el método MoSCoW para seleccionar qué épicas son imprescindibles , cuáles deberían serlo , etc.; el producto mínimo viable (o MVP) serían todas aquellas épicas marcadas como imprescindibles . ^{[ 4 ]} A menudo, un equipo descubrirá que, incluso después de identificar su MVP, tiene demasiado trabajo para su capacidad prevista. En tales casos, el equipo podría usar el método MoSCoW para seleccionar qué características (o historias, si ese es el subconjunto de épicas en su organización) son imprescindibles , recomendables , etc.; las características mínimas comercializables (o MMF) serían todas aquellas marcadas como imprescindibles . ^{[ 5 ]} Si hay suficiente capacidad después de seleccionar el MVP o MMF, el equipo podría planificar incluir también elementos recomendables e incluso opcionales . ^{[ 6 ]}

Crítica

Las críticas al método MoSCoW incluyen:

No ayuda a decidir entre múltiples requisitos dentro de la misma prioridad.
Falta de razonamiento sobre cómo clasificar los requisitos contrapuestos: por qué algo es obligatorio en lugar de recomendable . ^{[ 7 ]}^{[ 8 ]}
Ambigüedad respecto a los plazos, especialmente en la categoría " No estará disponible" : si no estará en esta versión o nunca. ^{[ 7 ]}
Potencial de enfoque político en el desarrollo de nuevas funcionalidades en lugar de mejoras técnicas (como la refactorización). ^{[ 8 ]}

Otros métodos

Otros métodos utilizados para la priorización de productos incluyen:

Método de priorización del modelo Kano

Referencias

↑ Clegg, Dai; Barker, Richard (1994). Método de casos de vía rápida: un enfoque RAD . Addison-Wesley. ISBN 978-0-201-62432-8.
↑ Bittner, Kurt; Spence, Ian (30 de agosto de 2002). Modelado de casos de uso . Addison-Wesley Professional. ISBN 978-0-201-70913-1.
↑ "Análisis MoSCoW (6.1.5.2)". Guía del Cuerpo de Conocimientos de Análisis de Negocios (2.ª ed.). Instituto Internacional de Análisis de Negocios. 2009. ISBN 978-0-9811292-1-1.
↑ Wernham, Brian (2012). Gestión ágil de proyectos para el gobierno . Maitland and Strong. ISBN 978-0957223400.
↑ Davis, Barbee (2012). Prácticas ágiles para proyectos en cascada: Transformación de procesos para obtener una ventaja competitiva . Serie de profesionales de la gestión de proyectos. J. Ross Publishing. ISBN 978-1604270839.
↑ Cline, Alan (2015). Desarrollo ágil en el mundo real . Apress. ISBN 978-1484216798.
1 2 Wiegers, Karl; Beatty, Joy (2013). Requisitos de software . Washington, EE. UU.: Microsoft Press. págs. 320–321 . ISBN 978-0-7356-7966-5.
1 2 McIntyre, John (20 de octubre de 2016). "Moscú o Kano: ¿cómo priorizar?" . HotPMO! . Recuperado el 23 de octubre de 2016 .

Enlaces externos

RFC 2119 (Niveles de Requisitos) Este RFC define los niveles de requisitos que se utilizarán en la documentación formal. Se usa comúnmente en contratos y otros documentos legales. Se menciona aquí porque la redacción es similar, pero no necesariamente el significado.
Reglas MoSCoW con margen de seguridad Este ensayo propone el uso de un conjunto modificado de reglas MoSCoW que logran los objetivos de priorizar los entregables y proporcionar un grado de seguridad en función de la incertidumbre de las estimaciones subyacentes.
Pasos y consejos para la priorización según las reglas DSDM MoSCoW.

[1] Clegg, Dai; Barker, Richard (1994). Método de casos de vía rápida: un enfoque RAD . Addison-Wesley. ISBN 978-0-201-62432-8.

[2] Bittner, Kurt; Spence, Ian (30 de agosto de 2002). Modelado de casos de uso . Addison-Wesley Professional. ISBN 978-0-201-70913-1.

[3] "Análisis MoSCoW (6.1.5.2)". Guía del Cuerpo de Conocimientos de Análisis de Negocios (2.ª ed.). Instituto Internacional de Análisis de Negocios. 2009. ISBN 978-0-9811292-1-1.

[4] Wernham, Brian (2012). Gestión ágil de proyectos para el gobierno . Maitland and Strong. ISBN 978-0957223400.

[5] Davis, Barbee (2012). Prácticas ágiles para proyectos en cascada: Transformación de procesos para obtener una ventaja competitiva . Serie de profesionales de la gestión de proyectos. J. Ross Publishing. ISBN 978-1604270839.

[6] Cline, Alan (2015). Desarrollo ágil en el mundo real . Apress. ISBN 978-1484216798.

[:0-7] 1 2 Wiegers, Karl; Beatty, Joy (2013). Requisitos de software . Washington, EE. UU.: Microsoft Press. págs. 320–321 . ISBN 978-0-7356-7966-5.

[:1-8] 1 2 McIntyre, John (20 de octubre de 2016). "Moscú o Kano: ¿cómo priorizar?" . HotPMO! . Recuperado el 23 de octubre de 2016 .

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]