وصف مرحلة بأنها «البرمجة اكتملت» لا يوضح ماذا ستراجع قبل اعتمادها في جدول دفعات المشروع. هل المتاح شاشات، أم وظيفة تعمل ببيانات اختبار، أم إصدار منشور مع دليل تشغيل؟ اربط اسم المرحلة بمخرج ونسخة واختبار ومسؤول مراجعة، حتى يصبح النقاش قابلًا للفهم من الطرفين.
هذا إطار تقني وتجاري لتنظيم أدلة التسليم، لا صياغة عقد أو حكم باستحقاق مبلغ. تحدد الاتفاقات الفعلية والمراجعة المناسبة شروط الدفع والمواعيد والآثار القانونية. لا نقترح هنا نسب دفعات أو ميزانية نموذجية؛ نوضح المعلومات التي تساعدك على مناقشة كل مرحلة بوضوح.
سمِّ ما يستطيع فريقك مراجعته
في مثال افتراضي، يطور فريق بوابة داخلية لطلب أدوات الموظفين. قد تشمل مرحلة تعريف المسار والأدوار، وأخرى تشغيل الطلب والموافقة في المعاينة، ثم تجهيز الإصدار والتدريب والإطلاق ضمن نطاق محدد. لا يلزم أن تتبع كل المشاريع هذا التقسيم؛ المهم أن تكون نهاية كل مرحلة مفهومة ولها دليل.
لا تجعل الموعد وحده وصف المخرج، ولا تعتبر عدد الملفات أو الأسطر نسبة إنجاز موثوقة. اطلب تحديد الوظيفة التي يمكن تجربتها والمدخلات التي وفرتها شركتك وما لم يكتمل بعد. إذا كان مخرج المرحلة تحليلًا أو تصميمًا، فسمه بذلك بدل وصفه كبرنامج جاهز للاستخدام.
مصفوفة تسليم تناقش بجوار جدول الدفعات
| مرحلة للمثال | دليل يرفق بها | سؤال قبل المراجعة |
|---|---|---|
| تثبيت المسار. | نطاق وأدوار وحالات قبول مع نسخة معروفة. | هل القرارات المعلقة ظاهرة ولها مسؤول؟ |
| نسخة معاينة. | مرجع إصدار وبيئة وحسابات تجريبية ونتائج المسار. | هل القبول لوظيفة كاملة أم جزء معلن فقط؟ |
| جاهزية الإطلاق. | خطة نشر وتشغيل وتدريب وملاحظات متبقية حسب النطاق. | هل اكتملت مدخلات العميل واعتماديات الطرف الآخر؟ |
| تحقق بعد التفعيل. | النسخة الفعلية وفحص الوظائف ودليل تسليم المتابعة. | هل ما اختبرناه هو ما يعمل في البيئة المقصودة؟ |
المصفوفة نموذج نقاش، ولا تنشئ التزام دفع أو اشتراطًا موحدًا. أضف المراجع والمراجعَ له وتاريخ تقديم الدليل وخطوة معالجة الملاحظات وفق اتفاقكم. يمكن أن يحتاج المشروع مخرجات مختلفة تمامًا، لكن يجب ألا يترك اسم عام مثل «مرحلة نهائية» محتواها للتخمين.
فرّق بين اكتمال العمل ومشاهدة عرض
يشرح دليل Scrum أن تعريف الاكتمال يتيح فهمًا مشتركًا للعمل الذي استوفى مقاييس الجودة. نستفيد من وضوح التعريف، دون تحويل كل دورة تطوير إلى فاتورة أو فرض Scrum على المشروع. كما لا يحدد الدليل شروط القبول التجاري أو ما يجب دفعه في عقدك.
في بوابة الأدوات، جرب طلبًا يوافق عليه الدور المخول، وآخر ناقص البيانات، ومحاولة اعتماد من مستخدم غير مخول. سجل النتائج وما لم تشمله التجربة. عرض فيديو لمستخدم واحد قد يفيد الشرح، لكنه لا يغني عن تمكين المراجع من فحص الحالات التي اتفقتم على قبولها.
اربط الدليل بنسخة حتى لا تتحرك نقطة المقارنة
توضح وثائق GitHub أن الإصدار يمكن أن يجمع ملاحظات وحزمة ويرتبط بعلامة في تاريخ المصدر. سواء استخدمتم هذه الأداة أم غيرها، اطلب مرجعًا يحدد النسخة التي يخصها الاختبار. لا تفترض أن وجود إصدار في المستودع يثبت نشره على الإنتاج أو نجاح كل اختبار.
إذا تغيرت النسخة أثناء المراجعة، فليظهر ما تغير وما يحتاج إعادة فحص. وميز حساب المعاينة عن البيئة الحية وبيانات الاختبار عن البيانات الفعلية. هذه التفاصيل تساعد على تفسير خلاف «كان يعمل في العرض» دون تبادل اتهامات أو اعتماد نتيجة تخص إصدارًا آخر.
أظهر الاستثناءات بدل إغلاقها ضمنيًا
قد يبقى تعديل نص، أو عيب في مسار أساسي، أو اعتماد خارجي لم يصل. صنف كل ملاحظة بمرجع وأثر ومسؤول وخطوة تالية، ووضح ما الذي يعتبره الطرفان مانعًا ضمن الترتيب المتفق عليه. قبول استثناء تشغيلي ينبغي أن يكون قرارًا ظاهرًا، لا نتيجة نسيان صف في ملف المتابعة.
إذا طلبت وظيفة جديدة أثناء مراجعة المرحلة، فارجع إلى ورقة أثر التغيير لتفصلها عن تصحيح السلوك المتفق عليه. ويشرح دليل المتطلبات كتابة شروط الوظيفة من البداية؛ أما هذه المصفوفة فتجمع دليل تسليم المرحلة وتاريخه وحدوده.
حدد كذلك من يوفر الحسابات والعينات ووقت المراجعة، وكيف يسجل تعذر فحص بند بسبب مدخل مفقود، دون افتراض أن الصمت قبول. عند مناقشة مشروع أو فريق برمجي مع نكست ويف، أرفق المصفوفة لتصبح مراحل العرض أوضح، ثم راجع شروطها التجارية والقانونية في الاتفاق المناسب.
المراجع وحدود الإطار
فُتح دليل Scrum لعام 2020 وشرح إصدارات GitHub في 4 نوفمبر 2026. المثال والمصفوفة أصليان، دون توصية بنسبة دفع أو تفسير ملزم للعقود. استعان إعداد النص بالذكاء الاصطناعي مع مراجعة المعلومات والترجمة.
