بإنك تتعامل مع قائمة المهام كطابور من شغل صغير وموصوف بوضوح. وكلاء الذكاء الاصطناعي يقدروا ياخدوا التذاكر من قائمة مهام Jira واحدة ورا التانية، ويبنوا كل تغيير على فرع (branch) مستقل ويفتحوا طلب دمج، والأشخاص بيفضلوا ماسكين القرارات المهمة. العامل الحاسم مش الوكيل قد ما هو مدى جاهزية تذاكرك.
ابدأ بترتيب قائمة المهام
الوكلاء مش محتاجين قائمة مهام مثالية، لكن محتاجين تذاكر يقدروا يخلّصوها. لو قسّمت قائمة المهام لأربع مجموعات قبل ما تبدأ، هتتجنب أغلب التشغيلات المهدرة.
| نوع التذكرة | نسلّمها لوكيل؟ | نعمل إيه الأول |
|---|---|---|
| نتيجة واضحة ونطاق صغير وطريقة للتأكد | نعم | سلّمها زي ما هي. |
| فكرة جيدة بس الوصف غامض | لسه | وضّح يعني إيه اكتمال الشغل، وحدّد الجزء المعني من الكود. |
| مهمتين في تذكرة واحدة | لا | قسّمها لتذكرتين. |
| محتاجة قرار في التصميم أو المنتج | لا | خلّي شخص يقرر الأول، وبعدها اكتب القرار على التذكرة. |
Jira ممكن يساعدك تلاقي أول التذاكر المرشحة. لغة الاستعلام الخاصة بيه، JQL، بتسمح لك تحفظ فلتر بيعرض التذاكر حسب الحالة أو التصنيف (label) أو عمرها، زي ما هو موضّح في دليل JQL من Atlassian. ابدأ بفلتر للتذاكر الصغيرة اللي وصفها واضح بالفعل.
شكل التذكرة اللي الوكيل يقدر يخلّصها
ده مثال مكتوب بالطريقة اللي مسؤول المنتج (product owner) بيكتب بيها في Jira. التذكرة صغيرة، وبتحدد يعني إيه اكتمال الشغل، وبتوضّح الشغل فين في الكود.
PAY-214: إضافة تصدير CSV لصفحة الفواتير
النتيجة: مستخدم من فريق المالية يقدر ينزّل قائمة الفواتير بعد الفلترة كملف CSV.
تكتمل لما: الملف يكون فيه نفس أعمدة الجدول، ويلتزم بالفلتر الظاهر على الشاشة، ويكون فيه اختبار بيغطي حالة القائمة الفارغة.
الجزء المعني: صفحة الفواتير والـ API الخاص بيها. خارج النطاق: التصدير لـ PDF.
كتابتها بتاخد حوالي دقيقة. ومن غير آخر ثلاثة سطور، بتبقى من نوع التذاكر اللي الوكيل بيضطر يخمّن فيها، والتخمين هو مصدر إعادة الشغل.
تذكرة واحدة، خطوة بخطوة
دي PAY-214 وهي بتعدّي على المراحل التسعة في مسار عمل Dutopilot: المعماري (architect) والمخطِّط (planner) والمنفِّذ (implementer) والبوابة (gate) وثلاثة مراجعين والمصلِّح الآلي (autofixer) وضمان الجودة (QA). قبل أول مرحلة، الفريق بيحدد نقاط الموافقة البشرية مرة واحدة لكل مشروع، وبعدها التذكرة بتتستلم. وبعد آخر مرحلة، شخص بيطلق الإصدار على بيئة الإنتاج (production).
| الخطوة | الوكيل بيعمل إيه | إنت بتشوف إيه |
|---|---|---|
| قبل المراحل: الاستلام | بيقرا PAY-214 وصفحة التصميم المربوطة بيها، وبيتأكد إن التذكرة جاهزة. | تعليق بيقول إن التذكرة اتستلمت وجاهزة. |
| 1. المعماري (Architect) | بيقترح الملفات اللي هتتغير (صفحة الفواتير والـ endpoint الخاص بالتصدير)، والبيانات هتمشي إزاي، وأي اختبارات تتضاف. | الخطة في شكل تعليق. شخص محدد بيوافق عليها قبل ما أي كود يتكتب. |
| 2. المخطِّط (Planner) | بيحوّل الخطة المعتمدة لقائمة خطوات مرتبة للمنفِّذ. | قائمة الخطوات على التذكرة. |
| 3. المنفِّذ (Implementer) | بيكتب التغيير على فرع مستقل جوه بيئة معزولة (sandbox) مقفولة، وبيفتح طلب دمج. | فرع باسم التذكرة، وطلب دمج مربوط بـ PAY-214. |
| 4. البوابة (Gate) | بتشغّل lint والبناء (build) والاختبارات، وبترجّع حكم واحد مجمّع. | نتيجة فحص واحدة على طلب الدمج بدل إشارات متفرقة. |
| 5 إلى 7. ثلاثة مراجعين | ثلاثة من أعضاء الفريق الافتراضيين في Dutopilot، كل واحد فيهم بيقرا التغيير لوحده. واحد منهم بيلاحظ إن التصدير بيتجاهل الفلتر الظاهر على الشاشة. | تعليقات مراجعة على طلب الدمج، مكتوبة زي ما حد من فريقك هيكتبها. |
| 8. المصلِّح الآلي (Autofixer) | وكيل الإصلاح بياخد التعليق أو سجل الفشل، وبيصلّح الكود، وبعدها البوابة بتشتغل تاني. | commit جديد ونتيجة فحص جديدة. |
| 9. ضمان الجودة (QA) | لما كل الفحوصات تنجح، طلب الدمج بيتدمج تحت حماية الفروع عندك ويوصل لبيئة الاختبار، وهناك مرحلة QA بتختبر النتيجة. | التذكرة بتنتقل لحالة الاختبار عندك. |
| بعد المراحل: الإصدار | بيستنى موافقة شخص، وبعدها بينشر الإصدار من نفس مسار العمل. | طلب موافقة على الإصدار. |
فيه نقطتين بيستنّوا شخص بشكل افتراضي: الخطة والإصدار على الإنتاج. كل اللي بينهم بيشتغل من غير ما حد يتابعه، وكل مرحلة بتكتب على التذكرة، فإنت بتقرا اللي حصل بعدين بدل ما تحضره.
حرّك تذاكر كثيرة في نفس الوقت من غير تصادم
الصعوبة في قائمة مهام كبيرة مش في تذكرة واحدة، لكن في تذاكر كثيرة في نفس الوقت. خصّص لكل تذكرة فرع مستقل، وخلّي التذاكر المعتمدة على غيرها تستنى التذكرة اللي محتاجاها، وحدّد عدد التذاكر اللي بتشتغل مع بعض على قد اللي فريقك يقدر يراجعه. ولو تذكرتين بيعدّلوا نفس الملفات، شغّلهم واحدة بعد التانية.
افترض إن PAY-215 زر تصدير في لوحة التحكم (dashboard) محتاج الـ endpoint من PAY-214. علّمها في Jira إنها blocked by PAY-214، فتستنى، وبعدها تبدأ من كود فيه الـ endpoint بالفعل. أما تذكرتين مالهمش علاقة ببعض، زي تعديل نص وتقرير جديد، فبيشتغلوا جنب بعض من غير ما واحدة تأثر على التانية. وقبل ما تبدأ، كل تذكرة بتجيب أحدث كود من الفرع الرئيسي بنفسها، فمفيش تذكرة بتستنى حد يحدّث فرع بإيده.
اللي بتجهّزه
- اربط مشروع Jira ومنصة استضافة الكود عندك (GitHub أو GitLab أو Bitbucket أو Azure DevOps).
- اختار الجزء اللي هتبدأ بيه من قائمة المهام، مثلًا تصنيف (label) واحد أو فلتر محفوظ.
- حدّد مين بيوافق على الخطة وعلى الإصدار على الإنتاج، وأي أجزاء من الكود محتاجة مراجِع محدد بالاسم.
- اربط اشتراكك الخاص في Claude Code أو Codex أو OpenCode أو Oh My Pi.
أغلب الفرق بتشغّل أول تذكرة خلال أسبوع.
دور Forward Deployed Engineer مع فريقك
كل عميل في Dutopilot بياخد Forward Deployed Engineer (مهندس مخصص يعمل مع فريقك): مهندس من Dutopilot بيشتغل مع فريقك مباشرة، مش طابور دعم فني. هو مش بيكتب كود منتجك، لكن بيخلّي مسار العمل يناسب طريقة شغلك الحالية.
- التهيئة (onboarding): بيربط أدواتك معاك وبيختار أول جزء من قائمة المهام.
- جاهزية التذاكر: بيراجع أول التذاكر مع مسؤول المنتج عندك، وبتتفقوا على نموذج قصير زي اللي فوق.
- الموافقات والبوابات: بيحدد أي خطط وأي أجزاء من الكود محتاجة شخص وأيها مش محتاجة، على حسب طريقة المراجعة الفعلية في فريقك.
- أول تشغيلات: بيتابع معاك أول التذاكر وبيصلّح أي حاجة بتعطّل التشغيل.
- بشكل مستمر: بيراجع معاك التذاكر المتوقفة وملاحظات المراجعة، وبيخفف البوابات أو يشددها حسب اللي بيظهر في السجل.
Dutopilot بيعملها إزاي
Dutopilot بيرتبط بقائمة مهامك في Jira وبيشتغل عليها بمسار من تسع مراحل: بيخطط للتغيير، ويبنيه في بيئة معزولة (sandbox) مقفولة، ويخلّي ثلاثة مراجعين مستقلين يراجعوه، ويشغّل الاختبارات وفحوصات الجودة، ويصلّح اللي بيفشل، وبعدها يدمج لما الموافقات اللي اخترتها تكتمل. كل مرحلة بتتسجّل على التذكرة، فقائمة المهام دائمًا بتوضّح كل تذكرة وصلت لفين.
حماية الفروع (branch protection) والمراجعات المطلوبة عندك بتفضل شغّالة، ومش بنحتفظ أبدًا بنسخة من المستودع (repository) الخاص بيك. وغير Jira، Dutopilot بيشتغل مع Linear وNotion وGitHub Issues وAzure DevOps لإدارة قائمة المهام، ومع Slack. شرح إزاي توصل من تذكرة Jira لحد دمج طلب الدمج بيوريك تذكرة واحدة من أولها لآخرها.
أسباب شائعة لتوقف التشغيل
- مفيش معايير قبول في الوصف، فالوكيل بيضطر يخمّن يعني إيه اكتمال الشغل.
- التذكرة بتجمع مهمتين، فطلب الدمج بيكبر لدرجة تصعّب مراجعته.
- الاختبارات بطيئة أو مش مستقرة، فمفيش حد يقدر يتأكد إن التغيير شغّال.
- مفيش شخص متحدد للموافقة، فطلب الدمج الجاهز بيفضل مستني.
عالج الأسباب دي في قائمة المهام، ونسبة النجاح هتزيد من غير أي تغيير في الوكيل.
فين القرار بيفضل في إيد الأشخاص
- قبل كتابة الكود: شخص بيقرر معمارية أي حاجة جديدة أو فيها مخاطرة.
- عند الدمج: شخص محدد بالاسم بيوافق على التغييرات في الأجزاء الأهم.
- عند الإصدار: الإصدار على الإنتاج بيمشي حسب الإجراءات المعتمدة عندك.
أضف موافقات في أي مكان تاني تحتاجها فيه، واستغنى عنها كل ما الثقة تزيد. شرح إزاي تختار الخطوات اللي محتاجة موافقة بيوضّح إزاي تاخد القرار ده.
الأسئلة الشائعة
هل وكلاء الذكاء الاصطناعي محتاجين قائمة مهام مرتبة؟
لا، بس كل تذكرة الوكيل بيستلمها لازم يكون ليها نتيجة واضحة ونطاق صغير وطريقة تتأكد بيها منها. سيب التذاكر غير الواضحة في قائمة المهام، ورتّبها الأول.
إيه اللي بيحصل لما الوكيل يتعطّل؟
الإعداد السليم بيخلّي الوكيل يوضّح ده على التذكرة ويوقف، بدل ما يخمّن. في Dutopilot التذكرة بتوضّح إيه اللي معطّلها وإيه اللي ممكن شخص يعمله، وأي رد من شخص بيخلّي الشغل يكمّل.
هل نقدر نستخدم اشتراكنا الخاص في الذكاء الاصطناعي؟
نعم. Dutopilot بيشتغل على حسابك الخاص في Claude Code أو Codex أو OpenCode أو Oh My Pi، فأعضاء الفريق الافتراضيون في Dutopilot بيشتغلوا بنفس الشروط والحدود اللي عندك بالفعل.
إمتى أول تذكرة تبدأ تشتغل؟
أغلب الفرق بتشغّل أول تذكرة خلال أسبوع: تربط قائمة المهام والمشروع، وتوجّه Dutopilot لجزء واحد من قائمة المهام، وبعدها توسّع.