البرمجة القصوى أو برمجة إكس بي XP Programming ، هي منهجية جديدة تم تقديمها قبل أعوام قليلة بدلا عن البرمجة التتابعية (waterfall model) ، وتهدف هذه المنهجية إلى تقسيم المتطلبات الخاصة بالأنظمة إلى عدة أقسام وتقسم بيئة العمل لتكون بشكل زوجي وذلك لكي تعالج عدم معرفة العميل بماهية مخرجات النظام وتوقع التغييرات المستمرة على الأنظمة.
الغريب في الأمر، إن معظم مطوري نظم المعلومات خصوصا في الشركات الصغيرة والمتوسطة يستخدمون كثيرا من ممارسات هذا النوع من المنهجيات ولكن بشكل غير واضح. لذلك سأستعرض ممارسات هذه المنهجية لكي تتضح فكرتها.
تتسم منهجية البرمجة القصوى بميزات كثيرة وهي كالتالي:
1- لعبة التخطيط (Planning Game):
هذه واحدة من أهم مميزات البرمجة القصوى ، وتتيح لعبة التخطيط إدخال المستخدم مع المطورين وإعلامه بقيمة كل متطلب من متطلبات النظام وقيمته ، وبناءا على هذه المعلومات يحدد المستخدم المخرجات المهمة للنظام ويرتبهم حسب الأهمية، وبهذا يتضح ما يتطلب عمله من المتطلبات وما يمكن تأجيله لاحقا. ومن خلال ذلك يقوم فريق التطوير بإصدار ما يسمى ببطاقات التطوير (Story Cards) كل واحدة منهم تحتوي على بعض المتطلبات مرتبة حسب الأهمية للمستخدم.
2- إطلاق نسخ صغيرة من النظام (Small Releases):
يقوم فريق التطوير بإطلاق النظام بسرعة إلى السوق مع المتطلبات الأساسية (المتطلبات الدنيا) ومن ثم يقومون بتحديثه بشكل منتظم وذلك بإضافة المتطلبات بشكل متلاحق عن طريق إطلاق نسخ حديثة.
3- بساطة التصميم (Simple Design):
يقوم المطورون الذين يستخدمون البرمجة القصوى في مشاريعهم باستخدام التصميم الأبسط الذي يفي بالغرض المطلوب ولا يبالغون في تحسين التصميم والسبب في ذلك هو تغير متطلبات النظام بشكل كبير وذلك بسبب إطلاق النسخ الصغيرة المتلاحقة.
4- اختبارات مستمرة للتأكد من مطابقة البرنامج (Continuous Tests):
وهذي أيضا واحدة من ابرز المميزات للبرمجة القصوى ، والذي يميزها أن المطور يقوم بكتابة خطة اختبار النظام (Test Plan) قبل القيام ببرمجته وبذلك يسهل عليه تطبيق الاختبارات المطلوبة، الاختبارات وهي على نوعين:
أ- اختبار وحدات النظام (Unit Testing): وهذا هو النوع الأبرز في البرمجة القصوى حيث يقوم المطور بكتابة الاختبار داخل النظام أو استخدام أدوات للاختبار وينفذه عند كل عملية تحديث وذلك للتأكد أن عملية التحديث لم تغير جاهزية الأجزاء القديمة. السبب في استخدام الاختبارات المأتمتة (Automated tests) هو أن المطور إن لم يأتمت الاختبارات سيضطر إلى الاختبار بنفسه مرات عديدة.
ب- اختبار قبول النظام (Acceptance Tests): وهذا الاختبار يتم عن طريق مستخدم النظام ومن خلاله يقوم المستخدم بالمرور على كل أجزاء النظام أو الأجزاء الأهم في النظام لكي يتأكد من مطابقته للمتطلبات الأساسية.
5- الصورة المجازية (Metaphor):
يقوم فريق المطورون بالاتفاق على مسميات موحدة لكي يستطيعون التمييز بين الأشياء الموحدة وكذلك الرموز المعينة ، مثلا تسمية أجزاء من البرنامج بأسماء مختصرة لكي يتخاطبون بها ويفهمون على بعضهم
6- تحسين النظام (Refactoring):
يقوم فريق التطوير بعملية تحسين شفيرة المصدر (Source Code) الخاصة بالنظام وذلك بشكل كبير من خلال المرور على نفس الأسطر خلال عمليات التحديث المتلاحقة. عملية تحسين النظام تسهل قراءة شفيرة المصدر في المستقبل من قبل مطورين لم يشتركوا في تطوير النظام وكذلك قد تكون سببا في تحسين أداء البرنامج
7- المستخدم مع المطورين (On site customer):
ونقصد بكلمة المستخدم هنا هو المستخدم الفعلي للنظام وليس من يدفع فاتورة النظام، وهنا يجب ان يكون المستخدم قريب من المطورين للإجابة عن أي تساؤلات تخطر ببال المطورين
8- البرمجة الثنائية (Pair programming):
ونقصد هنا ان يجلس مطورين على كل جهاز ، الأول يكتب البرنامج المطلوب والآخر يراجع بعينيه كل مايكتبه زميله. وقد اثبتت التجارب ان البرمجة الثنائية تحسن أداء الأنظمة من ناحية الجودة والنوعية وتقلل الأخطاء والثغرات والسبب أنه تتم مراجعة البرنامج خلال كتابته وتصحيح ما يجب ان يصحح.
9- الملكية العامة (Collective ownership):
على عكس تقسيم العمل في البرمجة التتابعية (Waterfall model) تسمح البرمجة القصوى لجميع افراد الفريق المطور للنظام بتعديل أي جزئية في النظام اذا اقتضت الحاجة مما يجعل تعديل أي جزء من النظام عملية خاصة بالجميع وليست خاصة بالأشخاص الذين قاموا بتطوير الجزء الحالي.
10- تكامل مستمر للنظام (Continuous Integrations):
كل التعديلات يتم ادراجها في النظام بشكل يومي وعند كل عملية ادراج يتم اختبار النظام قبل ادراج التعديل وبعد ادراجه مما يعطينا اختبارات للنظام بنسبة 100% وبذلك جودة اعلى للنظام
11- 40 ساعة عمل اسبوعية (40-Hour Work Week):
وخلال هذه الممارسة التي تعتبر من الممارسات البارزة يقوم المبرمج (المطور) بالعمل 40 ساعة اسبوعيا ويمكن أن يعطى خارج دوام لمدة اسبوع كحد اقصى خلال النظام في حالة الضغط. اعطاء اكثر من اسبوع متلاحق كخارج دوام يعمل فيه المبرج يعتبر مشكلة!
12- معايير كتابة النظام (Coding Standards):
يجب استخدام معايير لكتابة النظام كطريقة كتابة المتغيرات، وخلافها. مثال: نظام المشتريات يتفق المبرمجون فيه على الابتداء دائما عند تسمية المتغيرات بـ AS ، AS_id، AS_CodeNumbet، وهكذا…
