Método MoSCoW

El método MoSCoW es una técnica de priorización utilizada en gestión, análisis de negocios , gestión de proyectos y desarrollo de software para llegar a 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 MOSCÚ es un acrónimo derivado de la primera letra de cada una de las cuatro categorías de priorización: M - Debe tener , S - Debería tener , C - Podría tener , W - No tendrá .

Las O intersticiales se añaden para que la palabra sea pronunciable. Si bien las O suelen estar en minúscula para indicar que no representan nada, también se utiliza la letra MOSCOW en mayúsculas. ^{[ cita requerida ]}

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). Su primer uso extensivo fue con el método de desarrollo de sistemas dinámicos (DSDM) ^[2] a partir de 2002.

MoSCoW se utiliza a menudo con timeboxing , donde se fija una fecha límite para que el foco esté en los requisitos más importantes, y se utiliza comúnmente en enfoques de desarrollo de software ágiles como Scrum , desarrollo rápido de aplicaciones (RAD) y DSDM .

Priorización de requisitos

Todos los requisitos son importantes, pero para ofrecer los mayores y más inmediatos beneficios comerciales de forma temprana, se deben priorizar los requisitos. Los desarrolladores intentarán inicialmente ofrecer todos los requisitos Must have , Should have y Could have, pero los requisitos Should y Could serán los primeros en eliminarse si el plazo de entrega parece amenazado.

El significado en inglés sencillo de las categorías de priorización tiene valor para lograr 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 etiquetados como Must have son fundamentales para el cronograma de entrega actual para que sea un éxito. Si no se incluye un solo requisito Must have , la entrega del proyecto debe considerarse un fracaso (nota: los requisitos pueden degradarse de Must have , mediante un acuerdo con todas las partes interesadas relevantes; por ejemplo, cuando se consideren más importantes los nuevos requisitos). MUST también puede considerarse un 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 en el plazo de entrega actual. Si bien los requisitos "Debería tener" pueden ser tan importantes como "Debe tener" , a menudo no son tan críticos en cuanto al tiempo o puede haber otra forma de satisfacer el requisito para que pueda posponerse hasta un plazo de entrega futuro.

Podría haber: Los requisitos etiquetados como Podrían ser necesarios son deseables pero no necesarios y podrían mejorar la experiencia del usuario o la satisfacción del cliente por un pequeño costo de desarrollo. 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 tendrá han sido acordados por las partes interesadas como los elementos menos críticos, de menor recuperación o no apropiados en ese momento. Como resultado, los requisitos No se tendrá no se planifican en el cronograma para el próximo marco de tiempo de entrega. Los requisitos No se tendrá se descartan o se reconsideran para su inclusión en un marco de tiempo posterior. (Nota: ocasionalmente se utiliza el término Me gustaría tener ; sin embargo, ese uso es incorrecto, ya que esta última prioridad indica claramente que algo está fuera del alcance de la entrega). (El BCS en las ediciones 3 y 4 del Libro de análisis empresarial describe "W" como "Quiero tener pero no esta vez")

Variantes

En ocasiones, W se utiliza para significar "deseo" (o " sería" ), es decir, "todavía es posible pero es poco probable que se incluya" (y menos probable que " podría "). Esto se distingue de "X" para "excluido" en el caso de elementos que explícitamente no se incluyen. "Sería" se utiliza para indicar características que no se requieren ahora, pero que se deben considerar en términos arquitectónicos durante el diseño como futuras oportunidades de expansión; esto evita el riesgo de diseños sin futuro que inhibirían la oferta de una característica particular en el futuro.

Uso en el desarrollo de nuevos productos

En el desarrollo de nuevos productos , particularmente aquellos que siguen enfoques de desarrollo de software ágiles, siempre hay más por hacer de lo que el tiempo o los fondos permiten (de ahí la necesidad de priorizar).

Por ejemplo, si un equipo tiene demasiadas epopeyas potenciales (es decir, historias de alto nivel ) para el próximo lanzamiento de su producto, podría usar el método MoSCoW para seleccionar qué epopeyas son Must have , cuáles Should have , y así sucesivamente; el producto mínimo viable (o MVP) serían todas aquellas epopeyas marcadas como Must have . ^[4] A menudo, un equipo encontrará que, incluso después de identificar su MVP, tiene demasiado trabajo para su capacidad esperada. 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 epopeyas en su organización) son Must have , Should have , y así sucesivamente; las características comercializables mínimas (o MMF) serían todas aquellas marcadas como Must have . ^[5] Si hay suficiente capacidad después de seleccionar el MVP o MMF, el equipo podría planificar incluir también elementos Should have e incluso Could have . ^[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 fundamentos sobre cómo clasificar los requisitos en competencia: por qué algo es obligatorio en lugar de debiera . ^[7]^[8]
Ambigüedad sobre el tiempo, especialmente en la categoría No estará disponible : si no estará en este lanzamiento o no estará nunca. ^[7]
Potencial de que el enfoque político se centre en la creación de nuevas características 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 Fast-Track: 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 conjunto de conocimientos sobre análisis empresarial (2.ª edición). Instituto Internacional de Análisis Empresarial. 2009. ISBN 978-0-9811292-1-1.
^ Wernham, Brian (2012). Gestión ágil de proyectos para el gobierno . Maitland y Strong. ISBN 978-0957223400.
^ Davis, Barbee (2012). Prácticas ágiles para proyectos en cascada: procesos cambiantes para obtener ventajas competitivas . Serie de gestión de proyectos profesionales. J. Ross Publishing. ISBN 978-1604270839.
^ Cline, Alan (2015). Desarrollo ágil en el mundo real . Apress. ISBN 978-1484216798.
^ ab Wiegers, Karl; Beatty, Joy (2013). Requisitos de software . Washington, EE. UU.: Microsoft Press. págs. 320–321. ISBN 978-0-7356-7966-5.
^ ab McIntyre, John (20 de octubre de 2016). "Moscú o Kano: ¿cómo se prioriza?". HotPMO! . Consultado el 23 de octubre de 2016 .

Enlaces externos

RFC 2119 (Niveles de requisitos) Esta RFC define los niveles de requisitos que se deben utilizar en la documentación formal. Se utiliza comúnmente en contratos y otra documentación legal. Se indica aquí porque la redacción es similar, pero no necesariamente el significado.
Reglas MoSCoW amortiguadas Este ensayo propone el uso de un conjunto modificado de reglas MoSCoW que logran los objetivos de priorizar los resultados y proporcionar un grado de seguridad en función de la incertidumbre de las estimaciones subyacentes.
Pasos de priorización de MoSCoW y consejos para la priorización siguiendo las reglas DSDM MoSCoW.