---
title: Moscow
localeTitle: Moscú
---
## Moscú

## Método MoSCoW

Uno de los significados de esta palabra es el método MoSCoW, una técnica de priorización utilizada en la gestión, el análisis empresarial, la gestión de proyectos y el desarrollo de software para alcanzar un entendimiento común con las partes interesadas sobre la importancia que asignan a la entrega de cada requisito, también conocido como Priorización de MoSCoW o análisis de MoSCoW.

## Priorización de los requisitos de MoSCoW

Todos los requisitos son importantes, pero se les da prioridad para entregar los mejores y más inmediatos beneficios comerciales. Los desarrolladores inicialmente intentarán entregar todos los requisitos Debe tener, Debería tener y Podría tener, pero los Requisitos Debería y Podría Ser los primeros en eliminarse si la escala de tiempo de entrega parece amenazada.

El significado simple en inglés 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 típicamente como:

## Debe tener
```
Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure. MUST can also be considered an acronym for the Minimum Usable SubseT. 
```

## Debería tener
```
Requirements labeled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must have, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox. 
```

## Podría tener
```
Requirements labeled as Could have are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit. 
```

## No tendra
```
Requirements labeled as Won't have have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won't have requirements are not planned into the schedule for the next delivery timebox. Won't have requirements are either dropped or reconsidered for inclusion in a later timebox. 
```

MoSCoW es un método de grano grueso para priorizar (categorizar) los elementos de la cartera de productos (o requisitos, casos de uso, historias de usuario ... según la metodología utilizada). MoSCoW se usa a menudo con Timeboxing, donde se fija una fecha límite para que la atención se centre en los requisitos más importantes. El término MoSCoW en sí mismo es un acrónimo derivado de la primera letra de cada una de las cuatro categorías de priorización (debe tener, debería tener, podría tener y no tendrá):

*   **Debe tener** : Crítico para el plazo de entrega actual para que sea un éxito. Normalmente es parte del MVP (Producto mínimo viable).
*   **Debería tener** : Importante pero no necesario para la entrega en el plazo de entrega actual.
*   **Podría tener** : deseable pero no necesario, una mejora.
*   **No tendrá** : Elementos menos críticos, de menor rentabilidad, o no apropiados en este momento.

Al establecer prioridades de esta manera, se puede alcanzar una definición común del proyecto y se pueden establecer las expectativas de las partes interesadas en consecuencia. Tenga en cuenta que MoSCoW es un poco relajado acerca de cómo distinguir la categoría de un elemento y cuándo se hará algo, si no en esta caja de tiempo.

#### Más información:

[Wikipedia](https://en.wikipedia.org/wiki/MoSCoW_method)