تهذيب المهام في تطوير التطبيقات المحمولة: المفهوم والأهداف وعملية التنفيذ

ما هو تهذيب المهام؟

تهذيب backlog (التنقية) هو عملية تحضير مهام Product Backlog للسباقات المستقبلية. إنه اجتماع حيث يقوم Product Owner وفريق التطوير بمراجعة المهام: توضيح المتطلبات، إضافة معايير القبول، تقدير التعقيد، تحديد التبعيات والمخاطر. لا يوجد حدث إلزامي يسمى «التهذيب» في Scrum Guide — إنها ممارسة إضافية تتبناها فرق Scrum لتقليل عدم اليقين في تخطيط السباق. التكرار الموصى به هو مرة واحدة لكل سباق، بمدة لا تتجاوز 60 دقيقة.

مصطلح «التهذيب» يعكس الجوهر: الفريق «يمشط» backlog، ويزيل المهام القديمة، ويوضح الغامضة، ويقسم الكبيرة جداً. في تطوير التطبيقات المحمولة، يعتبر التهذيب مهماً بشكل خاص بسبب خصوصية المنصة: مهمة Android قد تختلف في تعقيدها عن نسخة iOS، ويجب مراعاة targetSdk وcompileSdk والتوافق مع مستويات API. بدون تهذيب، يتحول تخطيط السباق إلى فوضى — يرى الفريق المهام لأول مرة ولا يستطيع تقديرها، مما يؤدي إلى عدم القدرة على التنبؤ وتأخير المواعيد النهائية.

نتيجة التهذيب هي عدة مهام جاهزة لتخطيط السباق: لها وصف ومعايير قبول وتقدير وتتوافق مع تعريف الاستعداد. يجب على Product Owner تهذيب المهام حسب ترتيب الأولوية: الأقرب للسباق الحالي — الأكثر تفصيلاً. المهام التي تبعد 3–4 سباقات — فقط على مستوى الملحمة. تقنية التنقية التدريجية (Progressive Refinement): كلما اقتربت المهمة من السباق، كلما كان وصفها أكثر تفصيلاً. لمهام السباق الحالي — تنقية كاملة (معايير القبول، تصميم، مواصفات API). لمهام تبعد سباقين — مستوى القصة (قصة مستخدم بدون تفاصيل تنفيذ). لمهام تبعد 3+ سباقات — مستوى الملحمة (فقط الاسم والقيمة التجارية).

تعريف الاستعداد: متى تكون المهمة جاهزة للسباق

تعريف الاستعداد (Definition of Ready — DoR) هو قائمة مرجعية للمعايير التي يجب أن تستوفيها المهمة قبل إدراجها في Sprint Backlog. DoR هو عقد بين Product Owner والفريق: يضمن PO توفر جميع المعلومات اللازمة للتطوير، ويضمن الفريق أنه يمكنه تقدير المهمة وإكمالها. DoR ليس عالمياً — كل فريق يحدد مجموعة معاييره الخاصة. بدون DoR، قد تدخل المهمة السباق بمتطلبات غير واضحة، مما يؤدي إلى إعادة العمل وتأخير المواعيد النهائية.

DoR النموذجي لتطوير التطبيقات المحمولة: 1) معايير القبول موصوفة (تنسيق Given-When-Then). 2) نموذج التصميم جاهز في Figma (لمهام واجهة المستخدم) بجميع الحالات: افتراضي، تحميل، خطأ، حالة فارغة. 3) مواصفات API معتمدة (OpenAPI/Swagger، أمثلة الطلبات والردود). 4) يوجد تقدير بنقاط القصة. 5) تم تحديد التبعيات للمهام الأخرى. 6) المهمة لا تعتمد على مكونات خارجية غير مكتملة. 7) خصوصية التطبيقات المحمولة: تحديد إصدارات نظام التشغيل المستهدفة، الحاجة إلى feature flag، دعم مستويات API القديمة.

تقنيات تقدير المهام

Planning Poker هي أكثر تقنيات التقدير شيوعاً في التهذيب. يحصل كل مطور على مجموعة بطاقات بأرقام فيبوناتشي (1، 2، 3، 5، 8، 13، 21). يعرض PO مهمة ويشرحها. بعد المناقشة، يظهر الجميع بطاقتهم في نفس الوقت. إذا اختلفت التقديرات بشكل كبير (مثلاً 3 و13)، يشرح المطورون أسبابهم ثم يصوتون مرة أخرى. تتكرر التكرارات حتى الوصول إلى توافق في الآراء. الهدف من Planning Poker ليس التقدير الدقيق، بل كشف الاختلافات في فهم المهمة.

تحجيم التيشيرت (T-Shirt Sizing) هي تقنية مبسطة للتقدير السريع: XS (1 SP)، S (2)، M (3)، L (5)، XL (8)، XXL (13). مناسبة للفرز الأولي للـ backlog عندما يكون هناك مهام كثيرة وتحتاج إلى ترتيب تقريبي للحجم. بعد تحجيم التيشيرت، يتم تقدير أكثر دقة عبر Planning Poker لمهام السباق التالي. التقدير بالتقارب (Affinity Estimation) هو تقنية فرز جماعي حيث تُرتب المهام على طاولة من الأبسط إلى الأكثر تعقيداً بدون استخدام أرقام، ثم تُجمع في مجموعات، وكل مجموعة تحصل على تقدير.

في تطوير التطبيقات المحمولة، يجب أن يأخذ التقدير في الاعتبار تعقيد المنصة. قد تُقدر مهمة Android بـ 5 SP بينما نفس المهمة لنظام iOS قد تكون 3 SP (أو العكس). هذا طبيعي: المنصات المختلفة لها تعقيد تنفيذ مختلف. نصيحة: قدر كل منصة على حدة إذا كان الفريق متعدد المنصات. استخدم مقياساً نسبياً: مهمة أساسية (مثلاً شاشة مع نص وزر) = 1 SP. كل شيء آخر نسبي إليها. وفقاً لـ Scrum.org (2025)، بعد 3–4 سباقات، تصل دقة تقدير الفريق إلى ±20% من التعقيد الفعلي.

التحليل: كيفية تقسيم المهام الكبيرة

المهام الأكبر من 8 SP يجب تحليلها إلى مهام أصغر. لا يمكن إكمال المهام الكبيرة في سباق واحد، ويصعب تقديرها، ولا تعطي إحساساً بالتقدم. تقنيات التحليل: تقسيم المهمة حسب الطبقات الأفقية (UI → ViewModel → Repository → Network/DB) أو حسب الشرائح الرأسية (ميزة: شاشة كاملة). التحليل الأفقي مناسب أكثر لتطوير التطبيقات المحمولة: مهمة فرعية 1 — تخطيط واجهة المستخدم (XML/Jetpack Compose/SwiftUI)، مهمة فرعية 2 — ViewModel + State، مهمة فرعية 3 — Repository + Network، مهمة فرعية 4 — اختبارات الوحدة.

التحليل الرأسي — تقسيم قصص المستخدم إلى قصص أصغر ذات قيمة مستقلة. مثال: ملحمة «سلة التسوق» → قصة 1 «إضافة منتج إلى السلة»، قصة 2 «عرض السلة»، قصة 3 «إزالة منتج من السلة»، قصة 4 «إتمام الطلب». كل قصة لها قيمتها التجارية الخاصة ويمكن إصدارها بشكل مستقل. SPoK (نقاط القصة على Kano): رتب القصص حسب القيمة التجارية (Must-have، Should-have، Could-have) ونفذها بترتيب القيمة.

قائمة التحقق من التحليل في التهذيب: 1) هل المهمة أكبر من 8 SP؟ → حلل. 2) هل معايير القبول محددة؟ → إذا لا، أضفها. 3) هل تعتمد على مهام أخرى؟ → حدد وسجل التبعيات. 4) هل تحتوي على عدم يقين؟ → أضف Spike (بحث) قبل المهمة الرئيسية. 5) هل التصميم مطلوب؟ → تحقق من جاهزية النماذج. قاعدة INVEST: Independent (مستقلة عن الآخرين)، Negotiable (قابلة للنقاش)، Valuable (ذات قيمة للأعمال)، Estimable (قابلة للتقدير)، Small (صغيرة)، Testable (قابلة للاختبار). إذا لم تستوفِ المهمة INVEST، فهي غير جاهزة للسباق.

عملية التهذيب: خطوة بخطوة

الخطوة 1: الإحماء (5 دقائق). يذكر Scrum Master الفريق بهدف التهذيب وDoR. ينظر الفريق إلى اللوحة، ويظهر PO المهام التي ستتم مناقشتها. الخطوة 2: مراجعة المهام (30 دقيقة). يقدم PO المهام بالتسلسل من نهاية السباق الحالي وبداية السباق التالي. لكل مهمة: الاسم والوصف ومعايير القبول (إن وجدت) ورابط التصميم ومواصفات API. يطرح الفريق أسئلة توضيحية: «هل هناك نموذج للحالة الفارغة؟«، «ما هي طريقة HTTP؟«، «ما هو minimum deployment target لنظام iOS؟«.

الخطوة 3: التقدير (15 دقيقة). يقدر الفريق المهمة عبر Planning Poker أو T-Shirt Sizing. إذا كان الاختلاف أكبر من 2 SP — يناقشون الأسباب ويصوتون مرة أخرى. قاعدة: إذا تعذر تقدير المهمة (متطلبات غير واضحة، لا يوجد تصميم) — تُعاد إلى PO للتوضيح وستعود إلى التهذيب التالي مع الإيضاحات. لا تقدر المهام ذات المجهولية — سيؤدي ذلك حتماً إلى أخطاء في السباق. الخطوة 4: تسجيل النتائج (10 دقائق). يسجل PO التقديرات في Jira/Linear، ويحدث وصف المهمة ويحدد الأولويات.

نتائج التهذيب: 3–7 مهام جاهزة تماماً لتخطيط السباق (مع DoR والتقدير والتصميم وAPI). يحدث PO backlog: يزيل المهام القديمة، يدمج المكررة، ويضبط الأولويات. مهم: التهذيب لا ينهي عمل PO — بين جلسات التهذيب، يجب على PO تحضير المهام التالية. الوتيرة الموصى بها: يحضر PO 3–4 مهام للتهذيب ويعمل الفريق عليها. إذا كان هناك أكثر من 50 مهمة في backlog، يجب على PO إجراء تحديد الأولويات (MoSCoW أو Weighted Shortest Job First) قبل التهذيب.

الفرق بين التهذيب وتخطيط السباق

التهذيب — هو تحضير. لا توجد التزامات — المهمة يتم توضيحها وتقديرها فقط. تخطيط السباق — هو التزام. يختار الفريق المهام من تلك المحضرة في التهذيب ويلتزم بإكمالها خلال السباق. الاختلافات الرئيسية: التهذيب غير مرتبط بسباق محدد (تنقية backlog بشكل عام)، لا يوجد هدف سباق أثناء التهذيب، ويمكن إجراء التهذيب في أي وقت خلال السباق. تخطيط السباق — بدقة في بداية السباق ويؤدي دائماً إلى هدف سباق.

في التهذيب، المهام تُقدر فقط، لكن لا تُؤخذ إلى السباق. في التخطيط، المهام تُختار من المجموعة المحضرة. بدون التهذيب، يستغرق تخطيط السباق 6–8 ساعات (بدلاً من 4)، لأن الفريق يرى المهام لأول مرة ولا يستطيع تقديرها بسرعة. قاعدة 80/20: 80% من المهام في تخطيط السباق يجب أن تكون جاهزة تماماً (مرت بالتهذيب)، 20% قد تكون جديدة (أخطاء عاجلة، إصلاحات سريعة). إذا كانت في التخطيط أكثر من 20% من المهام غير مقدرة — كان التهذيب غير كافٍ.

أخطاء التهذيب النموذجية

الخطأ 1: التهذيب مرة في الشهر. يراكم الفريق مهام 3–4 سباقات ويحاول تنقية كل شيء في ساعتين. النتيجة: نصف المهام تبقى غير مقدرة، والتخطيط يستغرق اليوم بأكمله. الحل: يجب أن يكون التهذيب منتظماً — مرة لكل سباق، 60 دقيقة. إذا كان هناك مهام كثيرة — أضف جلسة تهذيب ثانية في منتصف السباق. الأفضل تهذيب مهام أقل ولكن بجودة عالية من تهذيب كثير ولكن سطحي. الوتيرة: 3–5 مهام لكل جلسة تهذيب، كل منها تحصل على مناقشة وتقدير كاملين.

الخطأ 2: التقدير بدون سياق. يقدم PO مهمة «تنفيذ شاشة سلة التسوق» بدون تصميم وبدون API وبدون معايير قبول. يقدر الفريق «بالعين» — 13 SP. في التخطيط يتبين أنها في الواقع 5 SP (لأن الشاشة بسيطة). الحل: لا تُقدر المهمة إذا لم يكن هناك تصميم أو API. يجب على PO تحضير المواد قبل التهذيب. قاعدة: «لا نموذج — لا تقدير». الاستثناء: مهام Spike — بحث عدم اليقين، تُقدر بشكل منفصل بدون تصميم (2–5 SP حسب تعقيد البحث).

الخطأ 3: يتحول التهذيب إلى تخطيط. يبدأ الفريق بتوزيع المهام على الأفراد ومناقشة من سيفعل ماذا. الحل: ذكرهم بأن التهذيب للتوضيح وليس للتوزيع. التوزيع — في Daily بعد بدء السباق. التهذيب يجيب على سؤال «ماذا نفعل؟«، التخطيط — «متى نفعله؟«، Daily — «من يفعله؟«. خلط هذه الأسئلة في اجتماع واحد يقلل فعالية كل منها. يجب على Scrum Master إيقاف مناقشة التخطيط وإعادة توجيه التركيز إلى توضيح المهمة.

الخطأ 4: تجاهل الديون التقنية. في التهذيب تتم مناقشة الميزات الجديدة فقط، ويتم تجاهل المهام التقنية. بعد 3–4 سباقات، تتراكم الديون التقنية إلى مستوى حرج. الحل: في كل تهذيب، يجب تقدير مهمة تقنية واحدة على الأقل. النسبة: لكل 3 ميزات → مهمة تقنية واحدة. استخدم مقياس Tech Debt Ratio: نسبة المهام التقنية إلى مهام الميزات في السباق. القيمة المستهدفة: 0.25–0.3 (25–30% من الوقت على الديون التقنية). إذا كانت النسبة أقل من 0.2 — ستنخفض سرعة التطوير في السباقات التالية.