تخطيط السبرنت بسعتين: فريقك ووكلاء الذكاء الاصطناعي

مخطط سرعة الإنجاز يقول 34، وتوقفت عن تصديقه منذ أسابيع. نصف تلك النقاط أغلقها أشخاص، والنصف الآخر أغلقه وكلاء الذكاء الاصطناعي، ومتوسط مجموعتين لا تجمعهما وحدة قياس واحدة لا يعطيك رقمًا تخطط عليه.

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

لا نقصد بالمسارين هنا dual track agile الذي يفصل الاستكشاف عن التسليم. المقصود سبرنت واحد، بعض تذاكره ينفّذها أشخاص وبعضها ينفّذه وكلاء، ورقم سعة واحد لا يناسب أيًّا من الطرفين. إفصاح: نحن نصنع أداة تتبّع توجّه إليها الفرق وكلاءها، فاقرأ قسم المنتج بهذا الاعتبار.

مجموعتان ومتوسط واحد

سرعة الإنجاز مقياس نافع لأنه يقيس شيئًا بطيء التغير. إنتاجية الفريق تتحرك مع التوظيف والإجازات ومستوى الانتباه، ولذلك تكفي ثلاثة سبرنتات سابقة للتنبؤ بالرابع.

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

امزج الرقمين فيتحرك الناتج لأسباب لا علاقة لها بفريقك. تقرير CircleCI عن حالة تسليم البرمجيات 2026، المبني على 28,738,317 عملية تشغيل في سبتمبر 2025، وجد أن إنتاجية الفريق الوسيط على فروع الميزات ارتفعت 15 بالمئة عن العام السابق، بينما هبطت إنتاجية الفرع الرئيسي 7 بالمئة. إنتاج أكثر ووصول أقل، والأماكن التي يتكدس فيها العمل بحسب التقرير هي المراجعة والتحقق والدمج والمعالجة.

flowchart LR
    H["Human track, in points"] --> R["Review queue"]
    A["Agent track, in tickets"] --> R
    R --> M["Merged to main"]
    R --> B["Bounced back"]
    B --> A

سعة البشر ما زالت تقيس ما كانت تقيسه

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

ما يتغير هو ما تكفّ عن إدخاله. حين تراجع سارة pull request لوكيل مدة ساعتين يوم الأربعاء، تخرج هاتان الساعتان من سعتها بوصفها وقت مراجعة، لكن التذكرة لا تحمل أي نقاط قصص على جانب البشر. تُعدّ مرة واحدة، في المسار الآخر، وبوحدة مختلفة.

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

ما يحدّ مسار الوكلاء هو ساعات المراجعين

اسأل ما الذي يحدّ جانب الوكلاء فتأتيك إجابتان بديهيتان: وقت الوكيل أو إنفاق الرموز (tokens). كلتاهما خاطئة، وإجابة الرموز هي الخطأ الأغلى.

أكثر الأطر المنشورة اكتمالًا في هذا الباب هو Story Points to Tokens لمارسيلو بيرنارديس، بتاريخ 11 فبراير 2026: سعة السبرنت هي الأصغر بين سعة سرعة الإنجاز وميزانية الرموز مقسومة على الرموز لكل نقطة. حساب نظيف وقيد ثانٍ خاطئ، وملاحظته عن التكلفة هي التي تكشفه. عشرون مليون رمز، أي سبرنت كامل بمعدل 500 ألف رمز لكل نقطة قصة، تكلف نحو 233 دولارًا بأسعار Opus، وهو خطأ تقريب أمام ساعات المراجعة التي يبتلعها السبرنت نفسه. ومن يضع السقف على الرموز يضعه على المُدخل الوفير أصلًا.

وفكرة أن سعة المراجعة هي السقف الحقيقي ليست ملاحظتنا. طرحها ريك بوليك في سعة المراجعة هي سقف التسليم الجديد يوم 13 يوليو. ما لم ينشره أحد بعد هو رقم تحمله معك إلى اجتماع التخطيط. وقياسان يعطيانك إياه.

استُخلصت معايير LinearB الهندسية لعام 2026 من 8.1 مليون pull request عبر نحو 4,800 فريق، وهي تضع الطلبات المدعومة بالذكاء الاصطناعي فوق 400 سطر بقليل عند المئين 75، مقابل 157 سطرًا للطلبات بلا مساعدة، ونحو 290 لما ينتجه وكيل بالكامل. وتنتظر هذه الطلبات نحو 1,050 دقيقة قبل أن يلتقطها أحد مقابل 200 تقريبًا، وتُدمج خلال ثلاثين يومًا في 32.7 بالمئة من الحالات مقابل 84.5. أكبر حجمًا، وأبطأ في أن يلتفت إليها أحد، وأقل احتمالًا بكثير للوصول.

أما جانب المراجع فلم يتحرك منذ عشرين عامًا. ما زال عرض SmartBear لدراسة Cisco يضع السقف عند 200 إلى 400 سطر في الجلسة الواحدة، وبما لا يتجاوز 60 دقيقة متصلة، مع هبوط حاد في كثافة اكتشاف العيوب بعد 500 سطر في الساعة. أي أن pull request من 400 سطر ينتجه وكيل هو جلسة مراجعة كاملة.

الحساب بالأرقام

reviewers = 2                # people who will really review
review_hours_per_day = 2.5   # protected time, not spare time
sprint_days = 10
hours_per_agent_pr = 1.25    # 60 min of inspection + 15 min of everything else
utilisation = 0.7            # past 85 percent the queue bites

budget = reviewers * review_hours_per_day * sprint_days / hours_per_agent_pr * utilisation
print(round(budget))         # 28 agent pull requests
print(round(budget * 0.5))   # 14 in the first sprint

الستون دقيقة هي سقف SmartBear للجلسة الواحدة. أما ربع الساعة الإضافي فهو الجزء الذي لا يحسب له أحد حسابًا: كتابة التعليقات، واستعادة السياق الذي فقدته، وتصفح النسخة الثانية. وإن كان مراجعوك صادقين، فهو أكثر من ربع ساعة.

ونسبة 0.7 ليست حذرًا لذاته. مقالة بوليك تشير إلى سلوك الطوابير الذي يعرفه كل من عمل في التشغيل: زمن الانتظار المتوقع يتناسب مع نسبة الاستغلال مقسومة على واحد ناقص نسبة الاستغلال. عند 70 بالمئة يبقى لديك هامش، وتكلفك المفاجأة قليلًا. وعند 85 يبدأ الطابور يعضّ. وعند 95، على حد تعبيره، لا يتدهور زمن الانتظار بل ينفجر.

	مسار البشر	مسار الوكلاء
القيد	الانتباه، والساعات المتبقية بعد الاجتماعات	ساعات المراجعة التي تستطيع حمايتها
الوحدة	نقاط أو ساعات	تذاكر قادرة على اجتياز المراجعة
مصدر القراءة	سرعة الإنجاز عبر ثلاثة سبرنتات	ما دُمج من طلبات الوكلاء، لا ما فُتح منها
صورة الفشل	التزام زائد يظهر في الجلسة الاستعادية	طابور ممتلئ يوقف المسارين معًا

ماذا يوضع على اللوحة في السبرنت الأول

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

سمِّ المراجع لكل تذكرة وكيل أثناء التخطيط، لا عند ظهور pull request جاهز. المراجع بلا اسم هو الطريقة التي يتكوّن بها طابور، بهدوء، قبل حلول الأربعاء.

جودة التذكرة تحرّك هذا الحساب أكثر من أي شيء آخر هنا. التذكرة الغامضة تكلّف عدة جولات مراجعة لأن المراجع ينتهي به الأمر إلى كتابة المواصفة في التعليقات، فتشتري بالساعة نفسها عملًا أقل. وإن كانت تذاكر وكلائك ترتد مرتين في المتوسط، فميزانيتك الحقيقية نصف ما طبعه السكربت، وهذا ما يجعل كتابة تذكرة يستطيع الوكيل إنهاءها أرخص رافعة لديك.

سؤالان في اجتماع التخطيط بدل سؤال واحد

كان الاجتماع القديم يسأل: ماذا يتسع له الوقت؟ اسأل سؤالين بالترتيب، وأعطِ الثاني قوة ملزمة.

ما الذي يتسع له الفريق؟ سعة البشر كما كانت تمامًا، على التذاكر التي تحمل اسم شخص.

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

وما يسقط خارج القطع يبقى في الباكلوج. ولا تسلّمه إلى شخص جائزةَ ترضية، فالتذكرة المكتوبة لوكيل غالبًا ما تكون بالشكل الخطأ بالنسبة لإنسان.

حين يفيض مسار الوكلاء على مسارك

العلامة المميزة عمود مراجعة لا يفرغ بينما يستمر كل ما قبله في الحركة. الإسنادات تخرج كالمعتاد، والجلسات تُفتح، وعمر الطابور يرتفع.

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

وانتبه لما تفرضه لوحتك فعليًا، ولوحتنا منها. رقم WIP لكل عمود في إعدادات المشروع عندنا يُحفظ ويُعاد عرضه عليك، ولا شيء يستهلكه. ومفتاح WIP على اللوحة يحتسب مقابل حدّ افتراضي ثابت لكل فئة بدل ذلك الرقم، أربع مهام قيد التنفيذ وثلاث قيد المراجعة، ويلوّن عنوان العمود حين يتجاوزه. ولا واحد منهما يرفض بطاقة. القاعدة التي ترفض النقل فعلًا هي قائمة الانتقالات المسموحة على الحالة.

ما يستحق أن يظهر في التقرير، وما يجب أن يختفي منه

توقف عن عرض رقم سرعة إنجاز يخلط المسارين، وتوقف عن عرض ساعات الوكلاء أو عدد الرموز بوصفها مخرجات، لأنها تقيس المُدخل الذي لا ينقصك. ولا تبنِ لوحة ترتيب لكل شخص، ولا حتى للوكلاء. أول رد فعل على لوحة الترتيب هو التقدير الدفاعي، وعندها يصير كل مُدخل في حساب سعتك بلا قيمة.

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

ما يفعله المنتج هنا، وما لا يفعله

التخطيط بمسارين ممارسة تشغّلها بحقول عادية. لا يوجد مخطط سعة في Taskfolk، ولا موازنة موارد، ولا جدولة تلقائية.

السبرنتات تعمل بالتوازي، فيمكن لمسار وكلاء محكوم بالمراجعة أن يكون سبرنتًا مستقلًا بتواريخه، وتتبع سرعة الإنجاز ومخطط العمل المتبقي وحدة التقدير المحددة في المشروع.

وعمل الوكلاء قابل للعدّ لأن الوكيل الموصول عضو حقيقي في مساحة العمل بمعرّف مستخدم خاص به، لا روبوت يستعير معرّفك. وعرضٌ محفوظ مُصفّى على ذلك المُسند إليه هو مسار وكلائك، والتصفية نفسها استدعاء API واحد.

BASE=https://taskfolk.ai/api/v1/workspaces/acme
curl -H "Authorization: Bearer $TASKFOLK_KEY" \
  "$BASE/projects/WEB/issues?assignee=$AGENT&sprint=$SPRINT&status=in_review"

auth = {"Authorization": f"Bearer {os.environ['TASKFOLK_KEY']}"}
r = requests.get(f"{BASE}/projects/WEB/issues", headers=auth,
                 params={"assignee": agent, "sprint": sprint, "status": "in_review"})
print(len(r.json()["data"]))

{ "data": [ { "key": "WEB-142", "status": "in_review", "sprint_id": "0198f2b0-8c11-..." } ] }

والجلسات هي ما يبقي العدّ صادقًا. إسناد مهمة إلى وكيل ينشئ جلسة معلقة قبل أن يستيقظ الوكيل، ويُحفظ عليها رابط pull request، فتكون الجلسات قيد المراجعة هي عمق طابورك.

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

وتكلفة الوكلاء تتجمّع يوميًا وبحسب النموذج على نافذة 7 أو 30 أو 90 يومًا، وتراكميًا لكل وكيل، لكنها لا تتجمّع لكل سبرنت أبدًا. وكل رقم فيها يبلّغ عنه الوكيل نفسه: نحن نرسل المُحفّز ونخزّن السجل، ولا نشغّل النموذج مطلقًا، ولهذا فإن تكلفة الوكيل لكل مهمة موضوع قائم بذاته.

الأداة	نموذج سعة البشر	التحكم بإنتاجية الوكلاء
‏Jira على خطتي Premium وEnterprise	سعة الفريق وسرعة الإنجاز داخل Plans، ووحدة التقدير قابلة للتغيير	لا شيء
‏Azure Boards	ساعات أو أيام لكل شخص يوميًا، وأيام إجازة، وتقسيم بحسب النشاط	لا شيء
‏Linear	لا شيء	منصة وكلاء من خطة Free، وجلسات برمجة على Business
‏Taskfolk	لا شيء. تبويب السعة يسرد العمل المفتوح لكل مُسند إليه	جلسات لكل مهمة، وعروض محفوظة لكل وكيل، وتجميعات للتكلفة

تم التحقق في 26 يوليو 2026. تبقي Jira السعة خلف Premium، وAzure Boards يملك النموذج الأغنى ولا يطلب أكثر من صلاحية Basic. ولا يقدّم أي منهما نموذجًا للوكلاء، ولا نحن.

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