---
title: Moscow
localeTitle: موسكو
---
## موسكو

## طريقة MoSCoW

أحد معاني هذه الكلمة هو طريقة MoSCoW - وهي تقنية تحديد الأولويات المستخدمة في الإدارة ، وتحليل الأعمال ، وإدارة المشاريع ، وتطوير البرمجيات للوصول إلى فهم مشترك مع أصحاب المصلحة حول الأهمية التي يضعونها في تقديم كل متطلبات - والمعروف أيضًا باسم تحديد أولويات MoSCoW أو تحليل MoSCoW.

## تحديد أولويات متطلبات MoSCoW

جميع المتطلبات مهمة ، ولكن يتم تحديد أولوياتها لتقديم أكبر فوائد الأعمال وأقربها في وقت مبكر. سيحاول المطورون في البداية تقديم كل ما يجب أن يكون ، ويجب أن يكون لديه ، ويمكن أن يكون لديه متطلبات ، لكن متطلبات Should و Could ستكون أول من يتم إزالته إذا كان الجدول الزمني للتسليم يبدو مهددًا.

إن لمعنى اللغة الإنجليزية البسيط لفئات الأولويات قيمة في حث العملاء على فهم تأثير تحديد الأولوية بشكل أفضل ، مقارنة بالبدائل مثل High، Medium و Low.

يتم فهم الفئات عادة على النحو التالي:

## يجب ان يملك

 `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. 
` 

## يجب ان

 `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. 
` 

## قد يكون له

 `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. 
` 

## لن يكون

 `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 طريقة حبيبية خشنة لتحديد أولويات (تصنيف) عناصر تراكم المنتجات (أو المتطلبات ، حالات الاستخدام ، قصص المستخدمين ... حسب المنهجية المستخدمة). وكثيرا ما يستخدم MoSCoW مع timeboxing ، حيث يتم تحديد موعد نهائي بحيث يكون التركيز على أهم المتطلبات. مصطلح MoSCoW نفسه هو اختصار مستمد من الحرف الأول من كل فئة من فئات الأربع (يجب أن يكون ، يجب أن يكون ، قد يكون ، ولن يكون):

*   **يجب أن يكون** : حاسمة إلى timebox التسليم الحالي من أجل أن يكون ناجحا. وهو عادة جزء من MVP (منتج قابل للتطبيق بحد أدنى).
*   **يجب أن يكون** : مهم ولكنه غير ضروري للتسليم في timebox التسليم الحالي.
*   **يمكن أن يكون** : من المرغوب فيه ولكن ليس من الضروري ، وهو تحسن.
*   **لن يكون لديك** : العناصر الأقل حرجًا أو أقل الاسترداد أو غير مناسبة في الوقت الحالي.

من خلال تحديد الأولويات بهذه الطريقة ، يمكن الوصول إلى تعريف مشترك للمشروع وتعيين توقعات أصحاب المصلحة وفقًا لذلك. لاحظ أن MoSCoW هو قليل التراخي حول كيفية التمييز بين فئة عنصر وعندما يتم القيام بشيء ما ، إن لم يكن في هذا timebox.

#### معلومات اكثر:

[ويكيبيديا](https://en.wikipedia.org/wiki/MoSCoW_method)