المهمة والتذكرة — ما هما، أنظمة التتبع والعمل مع المهام

ما هي المهمة والتذكرة؟

المهمة — وحدة عمل مسجلة في نظام تتبع. تحتوي على وصف وأولوية (Critical, High, Medium, Low) ومنسق وموعد نهائي وحالة. في تطوير التطبيقات، قد تكون المهمة «إضافة شاشة ملف شخصي مع صورة رمزية» أو «تنفيذ ترقيم الصفحات للخلاصة» أو «تحديث targetSdk إلى 35». كل مهمة مرتبطة بمشروع وسباق مطوري (sprint) ومطور أو فريق معين.

التذكرة — كيان أوسع. يمكن أن تكون التذكرة تقرير خطأ («التطبيق يتعطل عند تدوير الشاشة على Android 14») أو طلب ميزة («إضافة دعم الوضع الداكن») أو استفسار دعم فني («إشعار الدفع لا يصل») أو مهمة من المدير («إعداد تقرير معدل الأعطال للشهر»). الحدود بين المهمة والتذكرة غير واضحة: في Jira، يتم دمج كلا المفهومين في Issue. الفرق الرئيسي: المهمة دائماً لها منسق، بينما التذكرة قد تكون طلباً بدون منسق محدد حتى الفرز (triage).

في Scrum وKanban، المهام هي العنصر الرئيسي في backlog. كل مهمة يجب أن تستوفي معايير INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). المهام المستقلة يمكن تنفيذها بأي ترتيب. القابلة للتقدير — يمكن للفريق تقدير الجهد. الصغيرة — تناسب سباقاً واحداً. القابلة للاختبار — لها معايير قبول واضحة. المهام الكبيرة (الملاحم) تُقسّم إلى مهام أصغر حتى تتحقق جميع المعايير.

أنواع المهام في تطوير التطبيقات

Feature — وظيفة جديدة للتطبيق. مثال: «شاشة تسجيل الدخول البيومتري (Face ID / Touch ID)». مهام Feature مرتبطة دائماً بقصة مستخدم ولها معايير قبول. التقدير يكون بنقاط القصة (1, 2, 3, 5, 8, 13). Bug — عيب يُكتشف أثناء التطوير أو الاختبار. أولوية تذكرة الخطأ تُحدد حسب severity (crash → Critical, خطأ واجهة → Medium, خطأ إملائي → Low). في تطوير التطبيقات، معدل الأعطال فوق 0.1% هو خطأ حرج يتطلب إصلاحاً فورياً.

Tech Debt / Chore — مهام تقنية بدون تأثير مرئي على المستخدم: تحديث المكتبات (Dependency Bump) وإعادة الهيكلة (الترحيل من ViewPager إلى ViewPager2) وإعداد CI/CD وكتابة الاختبارات. غالباً ما يتم التقليل من تقدير مهام Tech Debt، على الرغم من أنه وفقاً لـ Stripe 2025، يذهب ما يصل إلى 30% من وقت الفريق المحمول للصيانة وسداد الديون التقنية. تجاهل الديون التقنية يؤدي إلى زيادة الأخطاء وتباطؤ تطوير الميزات الجديدة.

أنواع إضافية: Spike (مهمة بحثية — استكشاف تقنية جديدة، كتابة POC)، Task (أي عمل غير برمجي — توثيق، مراجعة تصميم)، Improvement (تحسين وظيفة موجودة — تحسين وقت تحميل الشاشة). في Jira، يتم تخصيص أنواع issues لكل مشروع. المجموعة القياسية لفريق محمول: Story, Bug, Task, Improvement, Epic. Epic — موضوع كبير يجمع عدة قصص. مثال: «التجارة الإلكترونية: السلة وإتمام الطلب».

دورة حياة المهمة: من الإنشاء إلى الإغلاق

Open (To Do) — المهمة منشأة لكن لم تبدأ. تحتوي على وصف ومعايير قبول وأولوية. في هذه الحالة، يجب أن تمر المهمة بالتنقية (grooming) قبل دخول السباق. In Progress — بدأ المطور العمل. في تطوير التطبيقات، من المهم ربط الالتزامات (commits) وطلبات السحب (pull requests) بالمهمة: في Jira عبر Smart Commits (APP-123 #comment fix bug)، في GitHub/GitLab عبر كلمات مفتاحية في وصف PR (Closes APP-123).

In Review — أُرسل الكود للمراجعة. الفحوصات التلقائية: CI (Gradle build, lint, unit tests)، SonarQube (جودة الكود)، Danger (changelog, tests). لا يمكن للمطور أخذ المهمة التالية بينما الحالية في Review — هذا يمنع تعدد المهام. QA / Testing — يختبر المختبِر على أجهزة حقيقية (Android — إصدارات نظام تشغيل وأحجام شاشة مختلفة، iOS — موديلات iPhone مختلفة). إذا وُجدت أخطاء، تعود المهمة إلى In Progress مع تعليق.

Done (Closed) — اكتملت المهمة: دُمج الكود في main/master، اختُبر، جاهز للإصدار. بعض الفرق تضيف حالة Deployed — تصل المهمة للمستخدم فقط بعد نشر البناء في المتاجر. من المهم إغلاق المهام بتعليق عن النتيجة: أي إصدار، أي PR، أي مقاييس تغيرت. وفقاً لـ Linear (2025)، الفرق التي تغلق المهام مع وصف النتيجة أقل عرضة بنسبة 40% للعودة لنفس المهام.

قد تشمل دورة الحياة حالة Blocked — لا يمكن إكمال المهمة بسبب اعتماد خارجي (انتظار تصميم، رد من الخلفية، موافقة المدير). المهام المحظورة يجب أن تحتوي على تعليق مع السبب وتاريخ المراجعة التالية. المراجعة الأسبوعية للمهام المحظورة تساعد في تحديد التأخيرات النظامية في عملية التطوير. العوائق التي تدوم أكثر من أسبوعين تتطلب التصعيد لمستوى مدير المنتج.

أنظمة تتبع المهام

Jira — المعيار الصناعي للفرق من 10 أشخاص فأكثر. يدعم لوحات Scrum وKanban والتخصيص المتقدم لسير العمل والحقول المخصصة والأتمتة والتكامل مع Bitbucket/GitHub. العيوب: مفرط للفرق الصغيرة، واجهة بطيئة، تكوين معقد. للمشاريع المحمولة، يتم تخصيص Jira باستخدام: إضافة الحقول الخاصة بالتطبيقات (Platform, OS version, Device model)، والتكامل مع TestFlight وFirebase Test Lab، وأتمتة بناء الإصدارات. Jira هي الخيار للمشاريع المؤسسية ذات العمليات البيروقراطية.

Linear — أداة تتبع حديثة لفرق المنتجات. واجهة سريعة، دعم من الدرجة الأولى لاختصارات لوحة المفاتيح، Cycle مدمج (مشابه للسباق)، تكامل مع GitHub وSlack. المزايا: إنشاء سريع للمهام عبر CMD+K، توزيع تلقائي على المراحل (Triaged → Backlog → Upcoming → Current → Completed)، توثيق وخرائط طريق مدمجة. Linear يُختار من قبل الشركات الناشئة وفرق المنتجات التي تقدر السرعة. في 2025، 40% من المشاريع المحمولة الجديدة تستخدم Linear.

Trello — لوحة kanban بسيطة للفرق الصغيرة (2–5 أشخاص). بطاقات مع قوائم تحقق وتسميات ومواعيد نهائية. العيب: لا يوجد سباقات، تحليلات محدودة، صعوبة في التوسع. YouGile — النظير الروسي لـ Trello مع لوحات kanban ودردشة ومكالمات فيديو. Asana — أداة تتبع تركز على المشاريع والجداول الزمنية. اختيار أداة التتبع يعتمد على حجم الفريق والميزانية والتفضيلات: Jira للمؤسسات، Linear لفرق المنتجات، Trello/YouGile للشركات الناشئة. مهم: يجب أن تكون الأداة موحدة للفريق بأكمله — المصممون والمطورون ومراقبو الجودة والمديرون يعملون في نظام واحد.

أفضل الممارسات لإدارة المهام

اكتب معايير القبول — يجب أن تكون معايير القبول محددة وقابلة للتحقق. سيء: «شاشة تسجيل الدخول تعمل». جيد: «يدخل المستخدم البريد الإلكتروني وكلمة المرور، يضغط تسجيل الدخول. إذا كانت البيانات صحيحة — الانتقال للشاشة الرئيسية. إذا غير صحيحة — عرض خطأ «بريد إلكتروني أو كلمة مرور غير صالحة»». معايير القبول (AC) هي العقد بين المطور والمختبِر ومدير المنتج. بدون AC، لا تستوفي المهمة Definition of Ready (DoR) ولا يجب أن تدخل سباقاً.

اربط كل شيء. الالتزامات وطلبات السحب وحالات الاختبار ونماذج التصميم (Figma) ونقاشات Slack — كل شيء يجب ربطه بالمهمة. في Jira، يتم ذلك عبر روابط في التعليقات؛ في Linear، عبر الربط التلقائي لـ PR. قاعدة النقرة الواحدة: من المهمة إلى التصميم/الكود/الاختبارات — لا أكثر من نقرة واحدة. يفتح المطور المهمة ويرى فوراً النموذج في Figma ورابط PR وحالات الاختبار. هذا يسرع دمج أعضاء الفريق الجدد بنسبة 30% وفقاً لـ Linear (2025).

لا تنشئ مهاماً وهمية. مهمة بدون وصف وبدون AC وبدون أولوية هي نفاية. إذا لم يتذكر أحد في الاجتماع اليومي لماذا أُنشئت المهمة — يجب حذفها أو توضيحها. قاعدة 48 ساعة: إذا كانت المهمة في حالة In Progress بدون نشاط لمدة 48 ساعة، يجب على المطور ترك تعليق عن أسباب التأخير. وفقاً لـ Jira (2025)، 60% من المهام الخاملة لأكثر من 3 أيام تُغلق في النهاية بدون إنجاز.

تقسيم المهام: الملاحم وقصص المستخدم والمهام الفرعية

الملحمة (Epic) — منطقة وظيفية كبيرة تجمع عدة قصص. مثال: «توجيه المستخدم» يشمل «شاشة الترحيب» و«اختيار الاهتمامات» و«تحميل الصورة الرمزية» و«إعدادات الإشعارات». قصة المستخدم (User Story) — مهمة من منظور المستخدم. الصيغة: «بصفتي [دور]، أريد [إجراء] لكي [قيمة]». مثال: «بصفتي مستخدماً، أريد تسجيل الدخول بالبيومتري لعدم إدخال كلمة المرور كل مرة». قصص المستخدم يكتبها مدير المنتج أو مالك المنتج.

المهمة الفرعية (Sub-task) — تقسيم العمل التقني داخل Story / Task. مثال لـ Story «شاشة الملف الشخصي»: المهمة الفرعية 1: بناء الواجهة (XML / SwiftUI)، المهمة الفرعية 2: الاتصال بـ ViewModel، المهمة الفرعية 3: كتابة Unit Tests، المهمة الفرعية 4: Snapshot Tests، المهمة الفرعية 5: UI Tests (Espresso / XCUITest). قاعدة التقسيم: كل مهمة فرعية تُنجز في 1–2 أيام. إذا قدر المطور مهمة فرعية أطول — قسّم أكثر. المهام الفرعية هي تقنية داخلية للفريق، ليست مرئية في backlog المنتج. مجموع تقديرات المهام الفرعية لا يساوي بالضرورة تقدير Story الأم (جزء من العمل هو التواصل ومراجعة الكود والاختبار).

هرم التقسيم: Epic (ربع / نصف سنة) → Feature / Story (Sprint) → Task (1–3 أيام) → Sub-task (عدة ساعات). تقنية INVEST تساعد في التحقق من جودة التقسيم. إذا كانت المهمة غير مستقلة (تعتمد على أخرى) — هذا يشير إلى تقسيم غير صحيح. إذا كانت المهمة غير صغيرة (أكثر من 8 نقاط قصة) — تحتاج لتقسيم إضافي. النمط الشائع: Epic → 5–15 Stories → كل Story → 3–8 Sub-tasks. التقدير النهائي للملحمة = مجموع تقديرات Stories، لكن السباق الأول يعطي عادة هامش خطأ 20–30% في التقديرات.

الأخطاء الشائعة عند العمل مع المهام

الخطأ 1: المهام كبيرة جداً. مهمة تستغرق أسبوعين هي ملحمة تحتاج للتقسيم. لا يمكن دمج المهام الكبيرة في التتبع اليومي، فهي تظل في In Progress لأسابيع. القاعدة: الحد الأقصى للمهمة — 2–3 أيام عمل. كل ما هو أكبر يجب تقسيمه. أثر جانبي: يشعر المطور بالتقدم بإغلاق 2–3 مهام في الأسبوع بدلاً من مهمة عملاقة واحدة. هذا يعزز التحفيز وقابلية التنبؤ بالجدول الزمني.

الخطأ 2: عدم وجود معايير القبول. طبق المطور الميزة، واختبرها المختبِر — كل شيء جيد. المدير: «أين زر التحرير؟» — «لم يكن مكتوباً في المهمة». بدون AC، يفهم كل طرف المهمة بشكل مختلف. النتيجة: إعادة عمل، صراعات، مواعيد نهائية ضائعة. AC هو عقد: إذا لم يكن للمهمة معايير، فهي غير جاهزة للسباق. في التنقية، أول شيء يُفحص هو وجود AC. إذا كانت AC مفقودة، تُعاد المهمة لمدير المنتج للتنقيح.

الخطأ 3: نسيان الديون التقنية. الفريق يعمل فقط على مهام Feature سباقاً بعد سباق. بعد ستة أشهر: البناء يستغرق 15 دقيقة، Gradle متأخر 3 إصدارات رئيسية، الاختبارات تفشل في CI بسبب الإهمال. الحل: تخصيص 20% من وقت الفريق للديون التقنية (ممارسة Google SRE «ميزانية الأخطاء المستندة إلى SLO»). أنشئ مهمة Tech Debt واحدة على الأقل لكل سباق Features. النسبة: كل 3 مهام Feature — مهمة Tech Debt أو Bug واحدة. هذا يمنع تراكم الديون التقنية ويحافظ على سرعة التطوير.