البرمجة المتناهية

Extreme Programming

 

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

قدمت البرمجة المتناهية (وتعرف أيضاً اختصراً بـ XP ) للجمهور لأول مرة في عام 1999م حين أصدر كينت بك (Kent Beck) كتابه "معانقة التغيير؛ شرح البرمجة المتناهية" Extreme Programming Explained; Embrace Change .

 

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

وتقدم البرمجة المتناهية أيضاً هيكلاً لسير عملية التطوير يقوم على نفس الفكرة التي يقوم عليها نموذج التطوير بالإضافة.

 

وقبل أن استطرد في الحديث عن مزايا وعيوب البرمجة المتناهية دعنا أولاً نلقي نظرة أعمق على أفكار هذا الأسلوب.

 

كما أسلفت تسعى البرمجة المتناهية لجمع جميع من لهم علاقة بالمشروع في مكان واحد (بما فيهم العميل وبعض المستخدمين) وتعرف عدداً من الممارسات التي يفترض بأعضاء الفريق تطبيقها وهي:

 

1.    لعبة التخطيط (Planning Game)

تعتمد عملية التخطيط في البرمجة المتناهية على الإجابة على سؤالين محددين هما: ما الذي سيتم إنجازه خلال فترة محددة من الوقت؟ وما الذي يجب فعله بعد نهاية هذه الفترة؟ وبعبارة أخرى تقوم عملية التخطيط على استمرار دولاب العمل في المشروع باعتبار الوضع الحالي والحالي فقط دون النظر إلى الاحتياجات المستقبلية وتقرير ما الذي يجب فعله الآن وما هي الخطوة التالية. وتقوم البرمجة المتناهية بذلك عن طريق مفتاحين رئيسيين هما:

o       تخطيط الإصدارة (Release Planning): حيث يقوم العميل بتحديد الخصائص المطلوبة في الإصدارة الجديدة ويقوم الفريق بتقييمها وتحديد الجهد المطلوب لتنفيذها.

o       تخطيط الدورة التكرارية (Iteration Planning): حيث يقوم الفريق بتخطيط العمل بحيث يكون بإمكانهم إنتاج إصدارة جديدة صالحة للعمل كل دورة تكرارية وتستمر الدورة عادة ما بين أسبوعين إلى شهر واحد.

 

2.    الإصدارات الصغيرة (Small Releases)

يقوم فريق العمل بإنتاج نظام صغير في البداية ثم يتم تحديثه وتطويره مرة بعد أخرى في دورات متتابعة قصيرة المدى

 

3.    الكناية (Metaphor)

يستخدم الفريق نوع من الكناية أو الاستعارة للأسماء والصفات من الحياة الطبيعية كنوع من التشبيه لوصف النظام بحيث يكون من السهل على العميل تخيل أسلوب عمل النظام والتفاعل مع فريق العمل وفي نفس الوقت يمثل هذا الإيحاء صورة أبسط يمكن لفريق العمل نفسه تخيلها في المواقف المعقدة فمثلاً يمكننا وصف نظام إدارة الملفات والأدلة (Files & Directories) على أنه دولاب يحتوي عدد من الأدراج وكل درج يحتوي مجموعة أخرى من الأدراج والأوراق وهكذا بحيث يمكننا أثناء العمل والنقاش الاستعاضة عن كلمة دليل بكلمة درج بحيث يكون التخيل والاستيعاب أسهل وهكذا.

 

4.    التصميم البسيط (Simple Design)

يجب أن يكون النظام المصمم أبسط ما يمكن لتلبية الاحتياجات الحالية دون أي بناء إضافي من أجل المستقبل.

 

 

5.    إعادة التصنيع (Re-Factoring)

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

 

6.    الاختبار (Testing)

تنظر البرمجة المتناهية لعملية التطوير على أنها مقادة بالاختبارات بما يعني أن الاختبارات التي سيتم تطبيقها على الكود للتأكد من استيفائه للمتطلبات يتم كتابتها أولاً وبناء عليها يتم كتابة الكود.

 

7.    البرمجة المزدوجة (Pair Programming)

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

 

8.    الملكية الجماعية (Collective Ownership)

الكود ملك لجميع أفراد الفريق ويمكن لأي شخص أن يقوم بالتغيير في أي جزء من الكود في أي وقت أو بمعنى آخر لا يوجد تقسيم لملكية الكود بين أفراد الفريق.

 

9.    المكاملة المستمرة (Continuous Integration)

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

 

10. وجود العميل في الموقع (On-site Customer)

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

 

11. معايير التكويد (Code Standards)

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

 

12. الأسبوع 40 ساعة (40-Hour week)

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

 

13. مكان العمل  المفتوح (Open Workspace)

تفضل البرمجة المتناهية أن يكون العمل في مكان واسع مجهز بمقصورات للعمل فيها وأن يتمركز المبرمجون في أزواج في وسط هذه القاعة.

 

والآن دعنا نتفحص قليلاً كيف تنظم البرمجة المتناهية عمليات التطوير. يعرض الشكل أدناه مخططاً مبسطاً لسير العمليات في البرمجة المتناهية ويقدم الشكل الذي يليه عرضاً أكثر احترافاً.

مخطط مبسط لسير العمليات في البرمجة المتناهية

 

مخطط سير العمليات في البرمجة المتناهية

 

 

تمر عملية التطوير بـ 6 أطوار تبدأ بطور الاستكشاف (Exploration Phase) ومن خلاله يقوم العميل بكتابة بطاقات الروايات أو القصص التي تشرح المزايا التي يرغب بوجودها في الإصدارة الابتدائية. وتحتوي كل بطاقة على ميزة واحدة من المزايا المطلوبة. وفي نفس الوقت يسعى الفريق أثناء هذه المرحلة للتأقلم مع التقنيات المتوقع استخدامها ويقوم بتكوين بعض النماذج الأولية للنظام باستخدام تقنيات مختلفة لتقرير أنسب التقنيات والهياكل البنائية الممكن استخدامها لإنشاء النظام.

يلي هذا الطور طور التخطيط (Planning Phase) ومن خلاله يقوم الفريق بتحديد أولويات الروايات واختيار تلك التي سيتم تضمينها في أول إصدارة صغيرة , ويقوم أعضاء الفريق أيضاً بتوقع أو تقدير لحجم الجهد المطلوب لتنفيذ هذه الروايات ووضع جدول للعمل بناء على ذلك.

ثم يأتي دور طور دورات ما قبل الإصدار (Iterations to Release Phase) ومن خلاله يتم تقسيم الجدول الذي أعد في طور التخطيط إلى دورات قصيرة كل منها ما بين أسبوعين إلى أربعة يتم من خلالها تنفيذ المزايا المطلوبة. ومع بداية كل دورة يحدد العميل الميزات التي يريد العمل فيها خلال الدورة ومع نهايتها يتم تطبيق اختبارات القبول التي يحددها العميل. وبانتهاء آخر دورة يكون النظام جاهزاً للإنتاج. وهنا يحين الدور على طور الإنتاج (Production Phase) ومن خلاله يقوم الفريق بالمزيد من الاختبارات الإضافية وقياس أداء النظام وذلك قبل أن تصبح الإصدارة جاهزة لتسليمها إلى العميل.

والآن بعد أن تسلم العميل المنتج وبدأ باستعماله يصبح من الضروري أن يقوم الفريق بعمليات الصيانة وحل المشاكل التي تظهر في الإصدارة التي يستعملها العميل إلى أن يتم إطلاق الإصدارة الجديدة والتي يبدأ العمل فيها بالعودة إلى البداية مجدداً ويسمى هذا الطور بطور الصيانة (Maintenance Phase) وفي الواقع أن هذا الطور يمكن اعتباره موازياً لجميع الأطوار السابقة ابتداء من تسلم العميل للإصدارة الأولى.

وأخيراً وبعد أن ينتهي الفريق من تحقيق جميع رغبات العميل ولا يعود لدى العميل مزيد من المتطلبات أو الروايات التي تحتاج إلى معالجة يحين طور الموت (Death Phase) وفيه تتم معالجة أي مشاكل تتعلق بالكفاءة والأداء في النظام وإعداد أية وثائق مطلوبة عن النظام بعد أن تكون عملية التطوير قد توقفت.

 

 

الأدوار والمسؤوليات

تعرف البرمجة المتناهية مجموعة من الأدوار لأعضاء الفريق كالتالي:

·        المبرمجون (Programmers)

ويقومون بكتابة الاختبارات والأكواد.

 

·        العميل (Customer)

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

 

·        المختبر (Tester)

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

 

·        المتتبع (Tracker)

ويقوم المتتبع بتقديم التغذية العكسية لأفراد الفريق, فهو يتتبع تقديرات المجهود ويقيس مدى دقتها ويزود أعضاء الفريق بالتغذية العكسية عنها من أجل تحسين التوقعات في المستقبل. كما يقوم بتتبع التقدم في العمل في دورات التطوير وتحديد ما إذا كان من الممكن استيفاء المتطلبات المستهدفة في هذه الدورات في ظل الموارد المتوفرة سواء المادية أو المعنوية أم أن هناك حاجة للتغيير.

 

·        المدرب (Coach)

المدرب أو قائد الفريق وهو المسؤول عن العملية ككل وعن توجيه أعضاء الفريق لأداء العمل بالشكل المناسب.

 

·        المستشارون (Consultants)

وهم أفراد من خارج الفريق يقدمون الاستشارات والنصائح لحل المشكلات التي تواجه أعضاء الفريق في استخدام التقنيات المختلفة.

 

·        المدير (Manger or Big Boss)

وهو المسؤول عن اتخاذ القرارات بشكل أساسي وصاحب الكلمة العليا فيها وعادة يعود إليه اختيار أعضاء الفريق ومدربهم.

 

والآن دعنا نتأمل قليلاً ما الذي تقدمه لنا البرمجة المتناهية وما هو الثمن؟

 

بداية انصبت كثير من الانتقادات للبرمجة المتناهية على عدم مناسبتها للأنظمة الكبيرة ولكن دعنا نبدأ أولاً ببعض إيجابياتها, فقد أظهرت بعض الدراسات ارتفاعاً كبيراً في مستوى الإبداع والابتكار أثناء العمل تعدى في بعض الأحيان نسبة 300% كما أكدت معظم الدراسات حتى الآن على ارتفاع إنتاجية الفرق التي تتبع البرمجة المتناهية. وكذلك أبدى العملاء رضا أكبر عن البرامج التي استلموها نتيجة لوجودهم ضمن الفريق وقيامهم بأنفسهم بإدارة الجزء الذي يهمهم من العمل كما أن وجود العميل في وسط الفريق أثبت أنه طريقة فعالة لتوفير الوقت من خلال سرعة الاستجابة للاستفسارات التي تظهر أثناء العمل. كما أبدت البرمجة المتناهية قدرة كبيرة على الاستجابة للتغيرات في المتطلبات والتقنيات أثناء عملية التطوير إلى جانب توفيرها لجزء قابل للاستخدام من المنتج في وقت مبكر من عملية التطوير. كما أن أسلوب العمل فيها يوفر منهجية للمراجعة المستمرة للنظام وتحسينه. أضف إلى ذلك ارتفاع مستوى الرضا بين أعضاء فريق العمل عن ظروف العمل وارتفاع معنوياتهم وحماسهم للعمل. حتى الآن كل هذا رائع ولكن.... دوما نصطدم بهذه الكلمة " لكن" , على كل لا بأس لنتحمل الصدمة ولنرى ما وراءها, فقد أثبتت الدراسات أيضاً صعوبة التطبيق الكامل للبرمجة المتناهية إما لاحتياجها إلى مستوى عالي من الاحتراف والخبرة وإما لغياب العملية الواضحة فالإجراءات متروكة حرة بشكل كبير قد يقود في حالة عدم وجود إدارة متمكنة للفريق إلى الفوضى بدلاً من تحقيق النجاح. وكل النجاحات التي نسبت إليها حتى الآن هي نجاحات جزئية وحسب علمي فحتى الآن لم تظهر دراسة واحدة تؤكد نجاح التطبيق الكامل لكل أسس البرمجة المتناهية بصورتها الحالية. ولعل ذلك يرجع أيضاً إلا أنه حتى مع ارتفاع مستوى الخبرة والاحتراف لأعضاء الفريق فما لم توجد قيود واضحة للعمل فإن الأعضاء يطبقون ما يحبون من ممارسات ويهملون البقية. (هل يا ترى سنصل إلى أن البيروقراطية أمر لا مفر منه؟ أتمنى أن لا يحدث ذلك) . وأظهرت الدراسات أيضاً أن وجود المقاومة للتطبيق من بعض أعضاء الفريق أو الجهات الإدارية يجعل احتمال فشل المشروع أكبر من نجاحه (أعتقد أن هذا أمر طبيعي ولكن البرمجة المتناهية تظهر حساسية إضافية تجاهه). وكذلك فإنه على الرغم من الارتفاع في جودة الكود المكتوب من خلال البرمجة الزوجية والتوجيه بكتابة الاختبارات أولاً إلا أنها أيضاً تعود وتخفض هذه الجودة من خلال تركيزها على الكود كأساس للعمل بدلاً من التصميم بل وينظر البعض إليها بعدسة أكثر قتامة على أنها توفر الوقت في التصميم لتلقي به في الاختبارات وذلك أن التصميم الجيد يوفر جزءاً كبيراً من المشاكل. والبرمجة الزوجية في حد ذاتها أمر مختلف على فاعليته فليس كل المبرمجين قادرين على العمل في أزواج فكثيرين يجدون صعوبة كبيرة في التقيد بسرعة محددة للتفكير مع الشريك أثناء العمل رغم أن فكرة المشاركة في الأفكار في حد ذاتها تعتبر رائعة بالنسبة لهم ولكنهم يرونها كالملح في الطعام إن زاد عن حده انقلب إلى ضده. وحتى الدراسات تباينت آراؤها حول فاعلية البرمجة الزوجية فمنها من أظهر لها تأثيراً إيجابياً ومنها من أظهر العكس وهو ما يعطينا فكرة عن مدى تباين نجاح الفكرة من مشروع لآخر وبيئة لأخرى وطبعاً من أفراد لآخرين.

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

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

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