البرمجة المتطرفة

البرمجة المتطرفة — وعادةً تُختصَر إلى XP — هي أكثر أفراد العائلة الرشيقة تطلّبًا. وقد بُني East Agile Tracker لـ XP أولًا؛ وكل شيء آخر يتفرّع منها.

تغطّي هذه الصفحة ما هي XP، ولماذا تنجح، وكيف تمارسها مع الأداة كسطحٍ للتخطيط.

ما هي XP

أنشأ كنت بيك (Kent Beck) البرمجة المتطرفة في أواخر التسعينيات. وصدر الكتاب الأول — Extreme Programming Explained: Embrace Change — عام 1999. وقد بدأت، كأشياء كثيرة، بفريق محبَط يحاول إصدار نظام رواتب في كرايسلر.

رهان XP هو أن الطريقة الصحيحة للتعامل مع عدم اليقين في البرمجيات هي فعل الأشياء الناجحة، وفعلها بتواتر أكبر. اختبار؟ اختبِر طوال الوقت. تكامُل؟ تكامَل كل ساعة. حديث؟ تحدّث باستمرار. تخطيط؟ خطِّط لكل تكرار، وأعِد التخطيط كلما تعلّمت.

“XP منهجية خفيفة الوزن للفرق الصغيرة إلى المتوسطة التي تطوّر برمجيات في مواجهة متطلبات غامضة أو سريعة التغيّر.” — كنت بيك

القيم الخمس

تُسمّي XP خمس قيم يتعلّق بها كل شيء آخر:

1. التواصل — يتحدّث الفريق. يوميًا. عن العمل، والتصميم، والعوائق. وجهًا لوجه عند الإمكان. الصوامع هي العدو.
2. البساطة — افعل أبسط ما قد ينجح. يمكنك إضافة التعقيد لاحقًا إن احتجته فعلًا. وغالبًا لن تحتاجه.
3. التغذية الراجعة — من الكود (الاختبارات)، ومن الفريق (البرمجة الزوجية، والمراجعات)، ومن المستخدم (الإصدارات المتواترة). احصل عليها بسرعة.
4. الشجاعة — قُل الحقيقة عن التقدّم، والتقديرات، والتصميم. تخلّص من الكود الذي لا ينجح. وأعِد هيكلة ما يعيقك.
5. الاحترام — كل فرد في الفريق — والآن، كل وكيل في الفريق — يُسهم بقيمة. عاملوا بعضكم وفقًا لذلك.

الممارسات

تشتهر XP بممارساتها الاثنتي عشرة الأصلية، المنظَّمة في أربعة مجالات:

التخطيط

• لعبة التخطيط — يخطّط الفريق والعميل معًا: ما القادم، وبأي ترتيب، وكم حجم كل قطعة.
• الإصدارات الصغيرة — أصدِر بتواتر. أيامًا، لا أشهرًا. واحصل على تغذية راجعة على شيء ملموس.
• قصص المستخدم — المتطلبات محادثات، تُلتقَط على شكل قصص قصيرة من وجهة نظر المستخدم. “بصفتي مستخدمًا، أريد X، حتى Y.”

التصميم

• التصميم البسيط — أبسط تصميم يجتاز الاختبارات ويعبّر عن كل مفهوم لازم. لا أكثر.
• إعادة الهيكلة — حسِّن تصميم الكود الذي يعمل بالفعل. باستمرار.
• استعارة النظام — قصة مشتركة عن كيفية عمل النظام، تُستخدَم لجعل قرارات التصميم متسقة.

البرمجة

• البرمجة الزوجية — مطوّران، ولوحة مفاتيح واحدة. أحدهما يقود، والآخر يلاحظ. بدِّلا بتواتر.
• الملكية الجماعية للكود — يستطيع أي شخص تحسين أي كود. لا إقطاعيات.
• التكامل المستمر — كامِل واختبِر الكود مرات كثيرة في اليوم. والتقِط الأعطال فورًا.
• معايير الترميز — أسلوب متّفق عليه كي يُقرأ الكود وكأن شخصًا واحدًا كتبه.

الاختبار

• التطوير الموجَّه بالاختبار (TDD) — اكتب الاختبار الفاشل أولًا، ثم الكود الذي يجعله ينجح.
• اختبارات القبول — يحدّد العميل، بالكود أو بصيغة قابلة للتنفيذ، ما معنى “منجَز” لكل قصة.

لماذا تنجح XP

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

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

وهي أيضًا تتعلّق بـ الشجاعة والاحترام. لا يمكنك ممارسة XP إلا في فريق يثق أفراده ببعضهم بما يكفي ليكونوا مخطئين بصوت مرتفع.

نموذج القصة المنضبط

يُرسّخ East Agile Tracker نظرية محددة في التخطيط. عامِل هذا القسم بوصفه دليل التشغيل لـسبب بدوّ نموذج البيانات على هذه الهيئة — ودليلًا ميدانيًا لما يجب فعله (وما لا يجب) عمليًا.

لماذا تهمّ أنواع القصص الأربعة

كل شيء قصة، لكن هناك أربعة أنواع، والتمييز بينها هو جوهر الفكرة كلها:

• الميزات تحمل نقاطًا وهي الشيء الوحيد الذي “يُحتسَب” في السرعة. هذا يدفعك إلى تقطيع العمل إلى قيمة يلاحظها المستخدم.
• العلل بلا نقاط (صفر). لا تكسب العيوب رصيدًا، ما يجعل تكلفة إعادة العمل ظاهرة بدلًا من أن تُكافأ.
• أعمال الصيانة أيضًا بلا نقاط — عمل ضروري بلا قيمة مباشرة للمستخدم (بنية تحتية، وإعادة هيكلة، وإعداد). إبقاؤها على الصفر يضغط على الفريق لدمجها ضمن الميزات حيثما أمكن كي يبقى تأطير القيمة صادقًا.
• الإصدارات علامات بصفر نقطة تُستخدَم لتثبيت المعالم والسماح للأداة بتوقّع تاريخ.

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

قائمة الأعمال المرتَّبة الواحدة

ثلاث مناطق، قاعدة واحدة.

• Icebox هو مجمَّع الأفكار غير المرتَّبة بالأولوية.
• Backlog قائمة مرتَّبة بدقة، بأولوية واحدة — بلا تعادل، بلا “P1/P1/P1”.
• منطقة Current تحوي التكرار (أو التكرارات) النشطة.

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

التخطيط التلقائي المدفوع بالسرعة

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

• أنت تُقدِّر الميزات فقط، باستخدام نقاط نسبية (فيبوناتشي 1/2/3/5/8 أو مقياسنا الأضيق 0/1/2/3)، لا ساعات. التقدير محادثة حجم، لا وعد.
• أنت لا تتلاعب بالسرعة. تضخيم النقاط كي “تبدو سريعًا”، أو إعطاء نقاط لأعمال الصيانة، يكسر التوقّع الذي يجعل النظام كله صادقًا. السرعة أداة قياس، ولا تعبث بأداتك الخاصة.

العائد هو أن توقّع تاريخ الإصدار يصبح عملية حساب لا مفاوضة، وتتحوّل المحادثة مع أصحاب المصلحة من “هل يمكنك الالتزام بإنجاز X بحلول الجمعة” إلى “بالسرعة الحالية، يصل هذا الإصدار قرابة التاريخ Y — وها هي مقايضة النطاق/التاريخ.”

دورة حياة القصة وحلقة القبول

آلة الحالات هي Start → Finish → Deliver → Accept / Reject. الحالة الحاسمة هي Deliver: يضع المهندس علامة “مُسلَّمة” على القصة، لكنها ليست منجَزة حتى يقبلها مالك المنتج صراحةً مقابل معايير القبول الخاصة بها — أو يرفضها، فيُعيدها. هذا يُرسّخ حلقة تغذية راجعة من العميل في كل قصة على حدة بدلًا من تأجيل القبول إلى عرض نهاية السبرنت.

معايير القبول تخصّ القصة قبل بدئها، ويُفضَّل أن تكون بصيغة Given/When/Then كي تنطبق مباشرةً على اختبارات القبول. وINVEST هو محكّ السلامة لمعرفة ما إذا كانت القصة مصاغة جيدًا:

• Independent (مستقلة) — يمكن إصدارها دون قصص أخرى.
• Negotiable (قابلة للتفاوض) — تلتقط القصد، لا مواصفة مجمَّدة.
• Valuable (ذات قيمة) — لمستخدم أو صاحب مصلحة.
• Estimable (قابلة للتقدير) — يستطيع الفريق تحجيمها.
• Small (صغيرة) — تتسع بارتياح في تكرار.
• Testable (قابلة للاختبار) — لها معايير قبول يمكن تطبيقها.

الإيقاع

طقوس التخطيط خفيفة ومنتظمة:

• اجتماع تخطيط تكرار أسبوعي لإعطاء نقاط للقصص الجديدة وتثبيت معايير القبول في قمة قائمة الأعمال.
• اجتماع يومي قصير يركّز على التدفق والعوائق.
• مراجعة استعادية لكل تكرار لضبط العملية.

التكرارات عادةً أسبوع أو أسبوعان — قصيرة بما يكفي ليكون اكتشاف تقدير سيّئ رخيصًا.

الممارسات الهندسية التي تجعل التخطيط ينجح

التخطيط على طراز الأداة هو النصف المرئي من XP؛ وينهار دون النصف الهندسي.

• الاختبار أولًا / TDD ومجموعة اختبارات قبول حقيقية هما ما يجعل “مُسلَّمة” تعني شيئًا.
• التكامل المستمر والإصدارات الصغيرة المتواترة يُبقيان زمن الدورة قصيرًا كي تكون السرعة مستقرة لا متعرّجة.
• البرمجة الزوجية (أو المراجعة القوية) تُبقي العمل قيد التنفيذ منخفضًا — أنجِز قبل أن تبدأ — وهي أكبر رافعة منفردة على زمن الدورة.
• مالك منتج متاح هو ما يمنع حلقة القبول/الرفض من التعثّر.

الأنماط المعادية التي يجب مراقبتها

الإخفاقات المتكرّرة:

• معاملة قائمة الأعمال كموقف سيارات بدل ترتيب أولوية حقيقي.
• إعطاء نقاط للعلل وأعمال الصيانة لجعل السرعة تبدو أفضل.
• حمل قصص ضخمة لا يمكن إنجازها في تكرار. قسِّمها حتى تصبح كل واحدة قابلة للتسليم على نحوٍ مستقل.
• ترك القصص تتكدّس في Delivered لأن لا أحد يقبل.

أي من هذه يُعيد بهدوء نظامًا تجريبيًا إلى تخطيطٍ قائم على الأماني. لا تستطيع الأداة منعك من فعلها؛ تستطيع فقط جعلها ظاهرة. انظر إلى عمود Delivered في نهاية كل تكرار — إن كان ينمو، فتلك إشارتك.

XP مع East Agile Tracker

الأداة هي سطح التخطيط الذي تمنّته فرق XP منذ أيام Pivotal Tracker. وكل مفهوم ينطبق مباشرةً:

قصص المستخدم ← القصص

قصص مستخدم XP هي قصص East Agile Tracker. اكتبها بالنوع Feature. استخدم الوصف للمحادثة؛ واستخدم التعليقات للنقاش المستمر. ومعايير القبول تخصّ الوصف.

لعبة التخطيط ← اللوحة

لعبة التخطيط في XP محادثة بين الأعمال والفريق حول الأولوية والحجم. في East Agile Tracker:

1. يكتب شخص المنتج القصص في Backlog ويرتّبها حسب الأولوية.
2. يُقدِّر الفريق الميزات بالنقاط (مقياس فيبوناتشي أو East Agile).
3. يخطّط النظام للتكرارات تلقائيًا من السرعة.
4. يبدأ الفريق القصص من قمة عمود Current.

هذا كل شيء. تعيش “اللعبة” في المحادثة؛ والأداة تحتفظ بالنتيجة فحسب.

الإصدارات الصغيرة ← الإصدارات (نوع القصة)

تقول XP أصدِر بتواتر. Release أحد أنواع القصص الأربعة في East Agile Tracker. أنشئ إصدارًا لكل معلَم تسليم؛ واسحبه إلى التكرار الذي يُصدَر فيه. تتخطّى الإصدارات Started/Finished/Delivered وتنتقل مباشرةً إلى Accepted عند الإصدار.

التكامل المستمر ← آلة حالات القصة

آلة الحالات ليست تكاملًا مستمرًا بحدّ ذاته — ذلك نظام البناء لديك — لكن مسار Finished → Delivered → Accepted يحاكي حلقة قبول العميل التي تصفها XP. أنجِز العمل، وسلِّمه إلى العميل، واقبله حين يتأكد أنه عامل.

السرعة ← “طقس الأمس”

تسمّيها XP طقس الأمس: كمّ ما أنجزته في التكرار الماضي هو أفضل تنبّؤ بكمّ ما ستنجزه في هذا التكرار. يحسب East Agile Tracker السرعة تلقائيًا — متوسط التكرارات الأخيرة، باستراتيجية قابلة للضبط — ويستخدمها للتخطيط التلقائي لسعة التكرار التالي.

اختبارات القبول ← المراجعات

تنطبق مراجعات القصص في الأداة على القبول. أسنِد مراجِعًا (العميل، أو مالك المنتج، أو حتى وكيلًا يتصرف كأحدهما). يوافق أو يرفض. والرفض يُعيد القصة إلى Started.

البرمجة الزوجية ← الملكية المشتركة

تتزاوج فرق XP على الكود. في الأداة، يظهر هذا بصورة عدة مالكين على قصة. أسنِد كلا الزوجين إلى القصة؛ يظهر الاسمان كلاهما على البطاقة.

XP مع الوكلاء — الممارسة الجديدة

كُتبت XP قبل أن يستطيع وكلاء الذكاء الاصطناعي الإسهام في البرمجيات على نحوٍ ذي معنى. ونرى أن هذا أهمّ تحديث لـ XP منذ خمسة وعشرين عامًا.

في ممارستنا — وما بُنيت له الأداة — الوكيل عضو في فريق XP له اسم. له دوره الخاص، وشريكه الزوجي الخاص (بشري أو وكيل)، وسجل تدقيقه الخاص. ويستطيع فعل أي شيء يستطيع عضو بشري فعله في سطح التخطيط: التقدير، وملكية القصص، والتعليق، والنقل، وقبول المراجعات.

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

نحن لا نضع الوكلاء داخل الأداة يقومون بالبرمجة. بل نمنح سطح التخطيط للبشر والوكلاء يعملون معًا. أنت تُحضِر وكيل البرمجة — Claude Code، أو Codex، أو وكيلك الخاص — وتوصِله بالأداة عبر واجهة برمجة التطبيقات. يتولّى الوكيل القصص، ويقوم بالعمل، ويعلّق، وينقل. وأنت تراجع الأثر وتقبل.

هذا هو التخطيط الرشيق الشامل. إنها XP، بالفريق الذي تملكه فعلًا.

قراءات إضافية

• Extreme Programming Explained — كتاب كنت بيك التأسيسي، 1999.
• بيان الرشاقة — حيث بدأت العائلة.
• التطوير الرشيق — الصورة الأوسع.
• تعليمات التشغيل — دليل عملي للأداة.
• دليل واجهة برمجة التطبيقات — توصيل وكيل البرمجة لديك.