دورة حياة تطوير النظم والمنهجيات

سكرم: الأدوار والفعاليات والمنتجات

18 دقيقة الدرس 5 من 10

سكرم: الأدوار والفعاليات والمنتجات

سكرم هو إطار العمل الأكثر انتشاراً ضمن المنهجيات الرشيقة (Agile) في العالم. ليس عملية جامدة، بل هو إطار عمل تجريبي خفيف الوزن يتعامل مع حالة عدم اليقين، ويستخدم حلقات تغذية راجعة قصيرة لتوجيه المشروع نحو القيمة الفعلية. إن فهم سكرم بعمق أمر لا غنى عنه لكل محلل أنظمة، إذ يحدد الإطار الذي تُنظَّم فيه متطلباتك وتُرتَّب وتُسلَّم ضمن فرق البرمجيات الحديثة.

الأدوار الثلاثة في سكرم

يحدد سكرم ثلاث مسؤوليات محددة. كل شخص في المشروع يندرج ضمن أحد هذه الأدوار — والغموض في الملكية أحد أبرز أسباب الفشل.

مالك المنتج (Product Owner)

مالك المنتج هو الصوت الواحد للجهة التجارية. في مشروع نظام حجز العيادات، قد يكون مالك المنتج مدير العمليات الذي يفهم احتياجات المرضى والقيود التنظيمية وأولويات الإيرادات. تشمل مسؤولياته:

  • امتلاك قائمة أعمال المنتج (Product Backlog) وترتيبها — تحديد ما يُبنى وبأي تسلسل.
  • كتابة قصص المستخدم (User Stories) ومعايير القبول أو اعتمادها، حتى تعرف الفريق متى يكون "الإنجاز" إنجازاً فعلياً.
  • تعظيم القيمة المقدمة في كل سبرينت — بتساؤل دائم: "هل هذا البند سيخدم مرضانا ويجعل العيادة أكثر كفاءة؟"
  • التوافر للإجابة على الأسئلة خلال السبرينت، لا في اجتماعات الحدود فحسب.
رؤية تحليلية: في كثير من المؤسسات، يدعم محلل الأنظمة مالكَ المنتج بإجراء مقابلات أصحاب المصلحة وكتابة معايير القبول التفصيلية وصون التتبعية. مالك المنتج يقدم "الماذا ولماذا"؛ المحلل يضفي الصرامة المنهجية.

سيد سكرم (Scrum Master)

سيد سكرم هو قائد خادم يحمي قدرة الفريق على التسليم. إنه ليس مدير مشروع يصدر أوامر، بل يُزيل العوائق — بيانات اعتماد API معلقة، أو اجتماع يمكن أن يُحسم ببريد إلكتروني، أو خلاف متكرر حول تعريف الإنجاز. في مثال شركة الخدمات اللوجستية، قد يلاحظ سيد سكرم أن فريق التكامل مع المستودعات يسبب دائماً اختناقات في مراجعة السبرينت، فيتفاوض على عقد واجهة مشتركة للحل الدائم.

فريق التطوير (Developers)

الفريق متعدد التخصصات الذي يبني زيادة المنتج. في سكرم، كلمة "مطور" تعني كل من يساهم في الزيادة — محللون، ومختبرون، ومصممو تجربة المستخدم، ومهندسو الخوادم، وخبراء قواعد البيانات. الفريق ذاتي التنظيم: يقرر كيف يحقق هدف السبرينت. الحجم المثالي 3–9 أشخاص؛ فما زاد على ذلك رفع تكاليف التنسيق وأفقد المرونة.

فعاليات سكرم الخمس

لكل فعالية في سكرم حد زمني أقصى ثابت. هذا الحد يخلق الإلحاح ويمنع الإطالة غير المجدية.

  • السبرينت (Sprint) — نبضة قلب سكرم، حصة زمنية مدتها 1–4 أسابيع (عادةً أسبوعان) تُنتج خلالها الفريق زيادة منتج قابلة للإصدار. جميع الفعاليات الأخرى تقع داخل السبرينت.
  • تخطيط السبرينت (Sprint Planning) — يختار الفريق بنوداً من قائمة أعمال المنتج ويلتزم بهدف السبرينت. الحد الزمني: 8 ساعات لسبرينت مدته 4 أسابيع (مع تعديل التناسب). يسأل الفريق: "ما الذي يمكننا تسليمه؟ وكيف سنفعل ذلك؟"
  • سكرم اليومي (Daily Scrum) — مزامنة مدتها 15 دقيقة للمطورين كل يوم عمل. الأسئلة الثلاثة الكلاسيكية: ما الذي فعلته أمس؟ ما الذي سأفعله اليوم؟ هل ثمة عوائق؟ يُيسّره سيد سكرم؛ وهو ليس تقرير حالة للإدارة.
  • مراجعة السبرينت (Sprint Review) — يعرض الفريق الزيادة العاملة على أصحاب المصلحة في نهاية السبرينت. التغذية الراجعة تعود إلى قائمة الأعمال. الحد الزمني: 4 ساعات (سبرينت أسبوعين). في مثال المتجر الإلكتروني، يستعرض الفريق تدفق الدفع الجديد "العنوان المحفوظ" أمام مدير التسويق ومسؤول اللوجستيات.
  • استعراض السبرينت (Sprint Retrospective) — يتأمل الفريق كيف عمل، لا ما بناه. ما الذي سار بشكل جيد؟ ما الذي يجب تحسينه؟ تجربة أو تجربتان ملموستان للسبرينت القادم. الحد الزمني: 3 ساعات. هذه هي محرك التحسين المستمر.

منتجات سكرم الثلاثة

  • قائمة أعمال المنتج (Product Backlog) — قائمة مرتبة بكل ما قد يحتاجه المنتج. كل بند (قصة مستخدم، خلل، مهمة تقنية) يُسمى بند قائمة أعمال المنتج (PBI). مالك المنتج يملكها ويرتبها؛ والفريق يُحسّنها تعاونياً. في نظام العيادة: "بوصفي مريضاً، أريد حجز موعد عبر الإنترنت لتجنب الاتصال في ساعات الذروة" قد تكون PBI رقم 3.
  • قائمة أعمال السبرينت (Sprint Backlog) — المجموعة الفرعية من بنود قائمة أعمال المنتج التي التزم بها الفريق للسبرينت الحالي، مع خطة التسليم (غالباً مهام بـ ≤ 8 ساعات). يملكها المطورون، لا مالك المنتج.
  • الزيادة (Increment) — مجموع كل بنود قائمة الأعمال المكتملة. كل سبرينت يضيف إلى الزيادة. يجب أن تستوفي تعريف الإنجاز (Definition of Done) — مثلاً: "الكود مراجع، الاختبارات الآلية ناجحة، نُشر على بيئة الاختبار، معايير القبول مُتحقق منها." تعريف الإنجاز هو عقد الجودة للفريق.
أفضل الممارسات — تحسين قائمة الأعمال (Backlog Refinement): تعقد كثير من الفرق جلسة "تحسين" في منتصف السبرينت (ليست فعالية رسمية في سكرم لكنها شائعة). يقود المحلل الجلسة: تُقدَّر قصص المستخدم، وتُقسَّم إن كانت كبيرة، وتُوضَّح معايير القبول قبل دخولها السبرينت. هذا يقلل فوضى التخطيط ويمنع سحب قصص غير مكتملة المعالم.

دورة السبرينت — مرئياً

Scrum Sprint Cycle Product Backlog PBI #1 (High) PBI #2 (High) PBI #3 (Med) PBI #4 (Low) Sprint Planning SPRINT (1–2 weeks) Sprint Backlog PBI #1 → tasks PBI #2 → tasks Daily Standup ×10 Daily Scrum 15 min · every day Increment Built Meets Definition of Done Sprint Review Sprint Retro Improve Stakeholder feedback updates backlog Product Owner PO + Team Dev Team (+ Scrum Master) All stakeholders
دورة السبرينت في سكرم: قائمة أعمال المنتج تُغذّي تخطيط السبرينت، والعمل يُنفَّذ داخل السبرينت مع مزامنة يومية، وتعود التغذية الراجعة من المراجعة إلى القائمة.

سكرم عملياً — سبرينت في نظام حجز العيادات

تخيّل السبرينت الرابع لمشروع نظام حجز عيادات. مالك المنتج رتّب ثلاث قصص في أعلى قائمة الأعمال:

  1. بوصفي مريضاً، أريد تلقي تأكيد برسالة نصية حتى أعلم أن حجزي مؤكد. (8 نقاط)
  2. بوصفي موظف استقبال، أريد رؤية جميع المواعيد لطبيب على تقويم يومي. (5 نقاط)
  3. بوصفي مشرفاً، أريد إلغاء مواعيد متعددة دفعةً واحدة للتعامل مع غياب الأطباء. (13 نقطة)

خلال تخطيط السبرينت، طاقة الفريق 18 نقطة. يقبلون القصتين 1 و2، ويأخذون النصف الأول من القصة 3 (واجهة المستخدم فقط — 8 نقاط معدّلة)، ويشكّلون هدف السبرينت: "يتلقى المرضى تأكيدات الحجز ويستطيع موظفو الاستقبال عرض الجداول اليومية."

يكشف كل سكرم يومي عن عائق: بيانات اعتماد بوابة الرسائل القصيرة معلقة بسبب قسم تقنية المعلومات. يصعّد سيد سكرم الأمر إلى مدير تقنية المعلومات — يُحلّ العائق بحلول اليوم الثالث. في مراجعة السبرينت، يرى مدير العيادة تأكيد الرسالة النصية يعمل على هاتف حقيقي ويطلب على الفور خيار واتساب — يُنشأ بند جديد في قائمة الأعمال ويُحسَّن لسبرينت مستقبلي.

فخ شائع — "سكرم لكن...": تتبنى كثير من الفرق سكرم بشكل انتقائي: "نطبق سكرم لكننا نتخطى الاستعراض" أو "سكرم لكن مالك المنتج يحضر المراجعة فحسب." هذه الإغفالات تدمر حلقات التغذية الراجعة التي تجعل سكرم يعمل. الاستعراض المُهمَل يعني أن المشكلات المتكررة لا تُحلّ أبداً. ومالك المنتج شبه الغائب يعني انجراف قائمة الأعمال عن واقع العمل.

دور المحلل داخل سكرم

يعمل محللو الأنظمة عادةً كجزء من فريق التطوير أو بشراكة وثيقة مع مالك المنتج. الأنشطة التحليلية الرئيسية مرتبطة بفعاليات سكرم:

  • بين السبرينتات (التحسين): كتابة قصص المستخدم، وتعريف معايير القبول، وتحديد التبعيات، وتقسيم الملاحم (Epics) الكبيرة إلى قصص بحجم السبرينت.
  • تخطيط السبرينت: توضيح المتطلبات وحل الغموض حتى يتمكن الفريق من التقدير بثقة.
  • خلال السبرينت: الإجابة على أسئلة التوضيح، والتحقق من التطبيقات الجارية في مقابل المتطلبات، وتحديث نماذج العمليات مع اتخاذ قرارات التصميم.
  • مراجعة السبرينت: رصد ردود فعل أصحاب المصلحة، والتقاط التغذية الراجعة، وترجمتها إلى بنود جديدة أو معدّلة في قائمة الأعمال.
  • الاستعراض: التأمل في جودة المتطلبات — هل كانت القصص واضحة كفايةً؟ هل تسببت التوضيحات المتأخرة في إعادة عمل؟
نصيحة — الأصدقاء الثلاثة (Three Amigos): قبل دخول قصة ما إلى سبرينت، نظّم جلسة قصيرة "ثلاثة أصدقاء": مالك المنتج (المنظور التجاري)، ومطور (المنظور التقني)، ومختبِر (منظور الجودة) يتناولون القصة معاً. المفاهيم الخاطئة التي تُكتشف هنا لا تُكلّف شيئاً؛ أما في مرحلة الاختبار فتُكلّف أياماً.