ينجح تخطيط السبرنت لفريق يجمع الإنسان والوكيل عندما تبني خطتك على طاقة المراجعة، لا على سرعة التنفيذ. فالوكلاء قادرون على حجز المهام وإنجازها بوتيرة تفوق ما يستطيع مراجعوك قبوله، لذا فإن الحد الحقيقي لأي دورة ليس حجم الشيفرة المكتوبة، بل عدد التغييرات المكتملة التي يستطيع شخص واحد فحصها ودمجها. يشرح هذا الدليل منهجية التخطيط خطوة بخطوة، ويسمّي نمط الفشل عند كل خطوة، وينتهي بقائمة تحقق يمكنك تشغيلها قبل سبرنتك القادم.
يفترض التخطيط التقليدي للسبرنت أن المورد النادر هو الساعات التي يملكها المهندسون لكتابة الشيفرة. أضف وكلاء البرمجة إلى المعادلة، وينهار هذا الافتراض. فـ Claude Code وCodex وGemini CLI كلها قادرة على التقاط مهمة وإرجاع تغييرات شغّالة بينما لا تزال أنت تقرأ المهمة السابقة. عندها يتوقف التنفيذ عن كونه عنق الزجاجة، ويحل القبول مكانه.
هذا التحول يقوّض أي خطة عادية من دون ضجيج. تُقدّر دورة من أسبوعين بأيام المطورين، فيلتهم الوكلاء قائمة المهام المتراكمة خلال ثلاثة أيام، وتتكدّس طوابير من التغييرات المنتهية غير المراجَعة خلف شخص أو شخصين فقط يملكان صلاحية قبول الدمج. يبدو السبرنت سريعًا في بدايته، لكنه ينتهي ببطء.
Sharkly هي مساحة العمل التي يجري التخطيط داخل هذا الدليل في محيطها. أنت تملك وكلاء البرمجة بالفعل؛ وSharkly تحوّلهم إلى فريق عبر إبقاء كل مهمة وتقدّمها وعوائقها ونتائجها ومراجعة البشر لها في مكان مشترك واحد بدل أن تتناثر بين الطرفيات. السبرنت في Sharkly هو مجموعة مهام محدّدة زمنيًا يملكها Space واحد. والمنهجية أدناه هي نفسها سواء طبّقتها على سبورة بيضاء أو داخل المنتج، لكن أنماط الفشل تصبح أسهل في الرصد بمجرد أن يعود العمل إلى لوحة مشتركة.
ما الذي يتغيّر عندما يتولى الوكلاء التنفيذ
تخطيط السبرنت لفريق يجمع الإنسان والوكيل هو ممارسة تحديد نطاق الدورة بناءً على حجم العمل المكتمل الذي يستطيع الإنسان مراجعته وقبوله، لا بناءً على حجم الشيفرة التي يمكن للفريق إنتاجها.
الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون التقارير، بينما يحدّد البشر الوجهة ويمنحون الصلاحيات ويقبلون النتيجة. هذا التقسيم هو مشكلة التخطيط بأكملها. فإنتاجية وكلائك مرنة: يمكنك تشغيل ثلاثة أو عشرة. أما إنتاجية المراجعة عندك فثابتة، تحدّدها أعداد الأشخاص القادرين على قراءة الفرق البرمجي وتشغيل التغيير وتقرير ما إذا كان جاهزًا للإطلاق. راجع حسابات طاقة المراجعة لتعرف لماذا لا يعني تضاعف إنتاج الوكلاء خمس مرات أن العمل المُسلَّم سيتضاعف خمس مرات.
لذلك أول رقم تخطط به ليس نقاط القصة، بل خانات المراجعة: عدد المهام المكتملة التي يستطيع كل مراجع قبولها يوميًا، مضروبًا في عدد المراجعين، مضروبًا في أيام الدورة. وكل ما عدا ذلك يجب أن يتّسع تحت هذا السقف.
خطّط للسبرنت خطوة بخطوة
1. حدّد سقف المراجعة أولًا. قدّر عدد المهام المكتملة التي يمكن للمراجع قبولها فعلًا في اليوم؛ فالمراجعة الحقيقية لتغيير غير بسيط تستغرق من 30 إلى 60 دقيقة. ثم اضرب هذا الرقم في عدد المراجعين وفي أيام السبرنت. نمط الفشل: تجاهل هذه الخطوة، فتخطط بناءً على طاقة الوكلاء، وتلتزم بأكثر مما تحتمل، وتنتهي الدورة بطابور مراجعة أطول من السبرنت نفسه.
2. اجعل حجم المهام مناسبًا للمراجعة لا للتنفيذ. قسّم العمل بحيث تُنتج كل مهمة فرقًا برمجيًا يستطيع شخص واحد استيعابه في ذهنه. نمط الفشل: يعيد الوكيل بكل سرور تغييرًا من 2,000 سطر موزّعًا على تسعة ملفات، فلا يستطيع أحد قبوله داخل خانة مراجعة واحدة، فيتعفّن في أسفل اللوحة.
3. اكتب معايير القبول قبل الإسناد. تحتاج كل مهمة تعريفًا قابلًا للاختبار لما يعنيه الإنجاز: ما الذي يجب بناؤه، وكيف يبدو «الصواب»، وما الذي لا يجوز المساس به. نمط الفشل: نطاق غامض يعني أن الوكيل سيخمّن، فيعيده المراجع، وتلتهم المهمة الواحدة خانتي مراجعة.
4. أسند المهمة إلى وكيل واحد أو إلى Crew، بقرار واعٍ. استخدم وكيلًا واحدًا للأعمال الصغيرة محدّدة المعالم. واستخدم Crew عندما يحتاج وكيل قائد إلى تفسير الهدف واستدعاء أعضاء آخرين وإعادة نتائجهم إلى مهمة واحدة. نمط الفشل: الاستعانة بـ Crew في عمل تافه يضيف أجزاء متحركة عليك مراجعتها لاحقًا.
5. ضع سقفًا للعمل الجاري. حدّد عدد المهام التي يمكن أن تبقى في عمود «قيد المراجعة»، على غرار طريقة عمل حدود العمل الجاري في كانبان. نمط الفشل: لا سقف، فيغرق الوكلاء عمود المراجعة أسرع مما يفرغه البشر؛ ويظل عنق الزجاجة خفيًا حتى اليوم الأخير.
6. اترك هامشًا احتياطيًا. خصّص خانات مراجعة لإعادة العمل ولطلبات التغيير التي ستعيدها. نمط الفشل: تخطّط حتى 100%، فلا تجد الجولة الأولى من «يرجى الإصلاح» أي مكان تصل إليه.
متى تتوقف جداول البيانات أو أنظمة التذاكر وحدها عن التوسّع
يمكنك إدارة السبرنت الأول في جدول بيانات. ورقة فيها مهام، وعمود للمسؤول، وعمود للحالة. ويظل الأمر متماسكًا ما دام شخص واحد يشغّل وكيلين على مستودع واحد.
لكنه يفقد جدواه في اللحظة التي ينفصل فيها التنفيذ عن التتبّع. فتشغيل الوكيل والفرق البرمجي ومخرجات الاختبارات والنقاش كلها تعيش في طرفية، بينما يحتفظ جدول البيانات بحالة «قيد التنفيذ» عتيقة. إما أن يحدّث أحدهم الصف يدويًا، أو لا يحدّثه أحد. أضف وكيلًا ثالثًا على مستودع ثانٍ، وستنحرف اللوحة عن الواقع خلال يوم واحد. وحينها لن تستطيع الإجابة عن السؤال الواحد الذي يعتمد عليه التخطيط: ما الذي اكتمل، وما الذي ينتظرني؟
لوحة المهام المصمّمة لهذا الغرض تُبقي التنفيذ والسجل معًا. فالعمل والتقدّم والعوائق والنتائج تعود إلى المهمة بدل أن تختفي في جلسات خاصة. في Sharkly، يحجز الوكيل مهمة جاهزة، ويعمل داخل worktree معزول حتى لا تتضارب التغييرات المتوازية، ثم يعود ملخّص تغييره ونتائج التحقق والقيود المعروفة إلى الخط الزمني للمهمة ليقرّر إنسان قبولها أو إعادتها. هذا هو الفرق بين حالة تصونها أنت وحالة تصون نفسها. كما يمنح ذلك جلسة تخطيطك القادمة بيانات حقيقية: ما العمل الذي أنجزه الوكلاء في الدورة الماضية، وأين ذهب وقت المراجعة.
حدّ صريح: إذا كنت تشغّل وكيلًا واحدًا على مستودع واحد وتراجع أولًا بأول، فلست بحاجة إلى لوحة مهام ولا إلى Sharkly. تكفيك طرفية واحدة وقائمة تحقق. لكن المعادلة تتغير عندما تخطط عبر عدة وكلاء أو مهام أو مستودعات أو أشخاص، وهذه بالتحديد هي اللحظة التي يتحول فيها جدول البيانات إلى وظيفة ثانية. Sharkly مبنية لهذه الحالة الثانية؛ نزّلها عندما يبدأ جدول البيانات في الكذب عليك.
قائمة تحقق تشغّلها قبل سبرنتك القادم
شغّل هذه القائمة قبل أن تلتزم بالخطة:
- [ ] حسبت سقف المراجعة (عدد المراجعين × القبولات في اليوم × الأيام) وتعاملت معه باعتباره الطاقة الحقيقية للسبرنت.
- [ ] كل مهمة صغيرة بما يكفي لمراجعتها داخل خانة واحدة.
- [ ] لكل مهمة معايير قبول قابلة للاختبار وحدود واضحة لما «لا يجوز المساس به».
- [ ] كل مهمة مسندة إلى وكيل واحد أو إلى Crew بقرار واعٍ، لا تلقائيًا.
- [ ] يوجد سقف للعمل الجاري على عمود «قيد المراجعة».
- [ ] هامش محجوز لإعادة العمل ولطلبات التغيير.
- [ ] إنسان هو من يملك قرار الدمج والإطلاق لكل مهمة.
- [ ] التقدّم والعوائق والنتائج تعود إلى لوحة مشتركة، لا إلى طرفيات خاصة.
إذا أتممت الثمانية كلها، بقي تنفيذ الوكلاء داخل خطة يستطيع الفريق إنجازها. وإن فوّتت الأول، فلن تنقذك البقية.
الأسئلة الشائعة
هل يظل تخطيط السبرنت مفيدًا عندما يكتب الوكلاء معظم الشيفرة؟ نعم، لكن القيد يتغيّر مكانه. فالسبرنت يتوقف عن كونه وعاءً لساعات الهندسة ويصبح وعاءً للمراجعة والقبول. خطّط للدورة بناءً على حجم العمل المكتمل الذي يستطيع البشر فحصه، وسيملأ الوكلاء ما تبقّى. يظل دليل Scrum هو من يعرّف الطقس نفسه؛ والحساب الوحيد الذي يتغيّر هو حساب الطاقة.
كيف أقدّر الطاقة اللازمة لفريق يجمع الإنسان والوكيل؟ ابدأ من المراجعين، لا من الوكلاء. احسب المهام المكتملة التي يستطيع شخص واحد قبولها بصدق في اليوم، ثم اضربها في عدد المراجعين وأيام السبرنت. عدد الوكلاء لا يهم إلا إلى أن يتجاوز هذا السقف؛ وبعد تجاوزه، لا يفعل المزيد منهم سوى تكبير الطابور.
هل ينبغي للوكلاء اختيار مهامهم بأنفسهم خلال السبرنت؟ دعهم يحجزون المهام الجاهزة التي تحمل معايير القبول أصلًا، حتى يمضي العمل المتوازي بلا موزّع مهام. وأبقِ البشر على الوجهة والصلاحية والدمج. فذلك يضع الإنسان في الحلقة حيث تلزم الحكمة، ويجعل الأمر تلقائيًا في كل ما عدا ذلك.
كيف يختلف هذا عن إدارة المشاريع المعتادة؟ الطقوس تبدو متشابهة، أما عنق الزجاجة فلا. إدارة مشاريع وكلاء الذكاء الاصطناعي تخطط بناءً على إنتاجية المراجعة وعزل التغييرات بدلًا من توفّر المطورين، لأن التنفيذ لم يعد المورد النادر.
هل أحتاج أداة جديدة، أم يكفي أن أوسّع Jira؟ يمكنك الإبقاء على النظام الذي يفهمه فريقك بالفعل. الفجوة أن أدوات التذاكر تتبّع حالة يكتبها إنسان، لا تنفيذًا تشغّله آلة. راجع بدائل Jira لفرق الإنسان والوكلاء لتعرف من أين تبدأ هذه الفجوة في الإضرار.
