أساليب الجيل الجديد لإدارة تطوير البرمجيات

https://drive.google.com/file/d/0B5zxZ0A1AI-XMjB2aEN1c3lZV28/view

هذا المقال جزء من كتيب إطلالة على نماذج إدارة تطوير البرمجيات (22 صفحة)




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

** المدرسة التقليدية

تصميم كوبر التفاعلي Cooper Interactive Design

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

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

والآن دعنا نلقي نظرة قريبة على أسلوب كوبر, حيث يقوم هذا الأسلوب على مبدأ تحليل كل احتياجات المستخدم تماماً من خلال عدة طرق من بينها دراسة كيفية تفاعل المستخدم المتوقع مع النظام الذي يعمل من خلاله. ويمر هذا الأسلوب بالمراحل التالية:
Cooper Interactive Design
وكما يبدو من الشكل أعلاه فإن هذه المراحل تتم بالتسلسل، ولا يبدأ العمل في مرحلة من المراحل حتى تكون المرحلة التي قبلها قد تمت وفيما يلي عرض سريع لهذه المراحل:

1. مرحلة الأبحاث (Research):
من خلال هذه المرحلة يسعى فريق العمل إلى تكوين فكرة واضحة عن احتياجات المستخدم وطبيعة النظام المطلوب تصميمه وتجميع أكبر قدر ممكن من المعلومات من خلال :
  • المقابلات مع كل من له علاقة بالنظام من الأفراد.
  • مراجعة المقالات والتقارير والمواد المقروءة أو المرئية والتي لها علاقة بالنظام
  • ملاحظة المستخدمين المتوقعين للنظام و تحليل سلوكهم في العمل والتفاعل معه 
2. مرحلة وضع النماذج (Modelling):
في هذه المرحلة وباستخدام المعلومات التي تم جمعها في المرحلة الأولى يتم وضع النماذج التي تصف طبيعة العمل وطبيعة الأنشطة والتفاعلات التي تتم فيه وتحديد العناصر التي تقوم بهذه الأنشطة أو تتأثر بها سواء كانت عناصر بشرية أو غيرها. 

3. مرحلة تعريف المتطلبات (Requirements Definition):
بناء على النماذج التي نحصل عليها في المرحلة الثانية يتم تحديد المستوى الأعلى من المتطلبات التي يحتاجها مستخدمو النظام وذلك من خلال بناء سيناريوهات للتفاعلات الممكنة داخل النظام وبناء قوائم بطبيعة البيانات والمعلومات التي يحتاجها كل عنصر من عناصر النظام, وكذلك تحديد الوظائف التي تحتاج هذه العناصر للقيام بها, مع ملاحظة العوامل البيئية والإمكانيات الشخصية لعناصر النظام وكذلك الأهداف التجارية للمنشأة.

4. مرحلة تعريف إطار العمل (Framework Definition):
في هذه المرحلة يقوم فريق عمل كوبر ببناء مسارات للنظام أقرب ما تكون للطبيعية (طبيعية تعني كما تتم في النظام على أرض الواقع) ومن خلالها يقومون بتعريف الميزات والوسائل التي تمكن كل عنصر من عناصر النظام من تحقيق متطلباته بيسر وسهولة. ليخرجوا في النهاية برؤية واضحة للتصميم.

5. مرحلة التصميم (Design):
في خلال هذه المرحلة يقوم فريق العمل بملء الفراغات الموجودة في الرؤية التي خرجوا بها من إطار العمل وذلك بالدخول في أعمق تفاصيل التصميم ليخرجوا في النهاية بتصميم نهائي للمنتج يحدد جميع مواصفاته الفنية والوظائف التي يقوم بها وكيفية استخدام النظام بالأسلوب الأمثل وتحديد دقيق لمكونات شاشات العمل التي يتعامل من خلالها المستخدمون مع النظام.

6. مرحلة دعم التطوير (Development Support):
في هذه المرحلة يقوم فريق عمل كوبر بتوفير الدعم والاستشارات للفريق الذي يقوم بتنفيذ المشروع فعلياً من خلال التصميمات التي قدمها فريق كوبر. وبعبارة أخرى فإن هذه المرحلة هي المرحلة المقابلة لمرحلة التنفيذ والاختبار في نموذج شلال المياه إلا أن فريق كوبر فعلياً لا يقوم بتنفيذ المشروع وإنما يقوم فريق آخر بتنفيذ التصميمات التي يقدمها فريق كوبر.

** مدرسة الأساليب الخفيفة

عائلة كوبرن البلورية Cockburn`s Crystal Family

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

تتم عملية تحديد الطريقة التي سيتم اتباعها من قبل الفريق عن طريق تحديد ثلاثة عناصر رئيسية للمشروع هي:

1. كم الاتصالات المطلوب إدارته (وهو ما يرادف عدد أفراد الفريق)

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

3. أولويات المشروع (بعض المشروعات تكون أولوياتها الانتهاء من المنتج في توقيت معين من أجل ظروف التسويق والبعض الآخر تكون أولوياتها المحافظة على مستوى معين من الأداء من أجل تجنب المسائلات القانونية)

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

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

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

* المصدر المفتوح Open Source

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

* أسلوب كوود للتطوير المسير بالمزايا Coad’s Feature Driven Development

طور هذا الأسلوب واحد ممن اعتبروا لفترة طويلة أحد الموجهين الروحيين للبرمجة بالكائنات (Object Oriented Programming) وهو بيتر كوود. ويعتمد أسلوب كوود على الدورات القصيرة في عملية التطوير والتي تستمر كل منها لمدة أسبوعين. ويقوم أسلوبه على خمسة عمليات رئيسية ثلاثة منها تتم في بداية المشروع وهي:

1. تطوير النموذج العام
2. بناء قائمة المزايا أو الوظائف المطلوب توفرها في النظام
3. التخطيط بناء على المزايا

أما الاثنتان الباقيتان فتنفذان مرة بعد أخرى مع كل دورة من دورات العمل وهما:
4. التصميم المسير بالمزايا
5. البناء المسير بالمزايا

ومن خلال قوائم المزايا يقوم المبرمجون ببناء المزايا المطلوبة باستخدام أسلوب البرمجة بالكائنات.

* أسلوب سكرم Scrum

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

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

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

Scrum Development

ويقسم العمل في هذا الأسلوب إلى 3 مراحل أساسية هي:

1. مرحلة التحضير وتسمى مرحلة ما قبل اللعب (Pregame)
2. مرحلة العمل وتسمى مرحلة اللعب (Game)
3. مرحلة النهاية وتسمى مرحلة ما بعد اللعب (Post-game)


ويعطينا الشكل التالي فكرة أوضح عن هذه المراحل.

Scrum Development Stages

1- مرحلة التحضير (Pregame)

تشمل هذه المرحلة طورين هما:

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

2- مرحلة التطوير (Game)

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

  • التطوير (Develop): تحديد التغييرات التي يجب تطبيقها من أجل تطبيق المتطلبات المتراكمة وتشكيلها على شكل حزم أو كما يمكن أن نسميها عبوات. ثم يقوم الفريق بفك هذه الحزم والقيام بعمليات التحليل والتصميم والتطوير والتنفيذ والاختبار والتوثيق. وتشمل هذه العملية أيضاً عمليات الاستكشاف.
  • التغليف (Wrap): وتشمل هذه المهمة إعادة تغليف أو حزم العبوات وتكوين ملفات قابلة للتنفيذ من هذه العبوات وتحديد كيفية استيفاء هذه الحزم للمتطلبات. (حتى لا يحدث اختلاط في ذهن القارئ أرجو أن يلاحظ أن العبوات أو الحزم التي نتحدث عنها ليست أجسام مادية ملموسة وإنما هي نوع من التقسيم المنطقي للعمل).
  • المراجعة (Review): حيث تجتمع فرق العمل لتقديم أعمالها ومراجعة مدى التقدم في العمل وعرض المشاكل والاستفسارات وحلها ومراجعة المخاطر وتحديد ردود الأفعال المناسبة تجاهها وكذلك إضافة مهام جديدة لقوائم العمل المتراكم عند الضرورة.
  • التسوية (Adjusting): وهي عملية إعادة ترتيب البيانات والمعلومات التي تم جمعها أثناء اجتماعات المراجعة وتجهيزها للاستفادة منها وتتضمن مثل هذه المعلومات وجهات النظر المختلفة والخصائص الجديدة المقترحة ...الخ.

Scrum Race or Concurrent Engineering
3- مرحلة النهاية (Post-game)

وتشمل هذه المرحلة القيام بعمليات التشطيب (Closure) للمنتج مثل إعداد الوثائق والقيام بالاختبارات النهائية وأخيراً عملية الإصدار نفسها أو التسليم. ويعرّف أسلوب سكرم 6 أدوار رئيسية هي:

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

مالك المنتج (Product Owner): 
يعتبر مالك المنتج هو المسؤول رسمياً عن المشروع من ناحية الإدارة والتحكم واتخاذ القرارات فيما يتعلق بتحديد بنود قائمة العمل المتراكم في المنتج. ويتم اختيار مالك المنتج بالاتفاق بين قائد الأسلوب والإدارة والعميل. وهو من يأخذ القرارات النهائية بشأن المزايا التي يجب أن يتضمنها المنتج. وبأسلوب أبسط يمكن اعتباره المفوض من قبل جميع الأطراف لاتخاذ القرارات فيما يتعلق بالإمكانيات والمزايا التي يفترض أن تتوفر في المنتج.

فريق سكرم (Scrum Team): 
ويتشكل من أعضاء فريق المشروع الذي له الصلاحيات الضرورية لاتخاذ الإجراءات وتنظيم أنفسهم وطريقة عملهم لتحقيق أهداف السباق (عملية التطوير أو Sprint). ويمكن اعتبارهم في أغلب الأحيان المنفذين الفعليين للمشروع.

العميل (Customer): 
يعتبر العميل جزءاً من فريق العمل خصوصاً في مراحل التحضير وإعداد قائمة العمل المتراكم في المنتج.

المستخدم (User): 
يعتبر المستخدم أيضاً جزءاً من العمل وذلك على وجه الخصوص في المرحلة الأخيرة عند التسليم والاختبار.

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


 * العملية الموحدة المعقولة Rational Unified Process

تم تطوير هذه العملية خصيصاً لتكون مكملة للغة النمذجة الموحدة (UML) في تصميم النظم باستخدام البرمجة بالكائنات (OOP). وقد صممت على الأسلوب التكراري (Iterative Approach) وتؤكد بشدة على تكوين وتعديل النماذج المصممة بواسطة لغة النمذجة الموحدة بدلاً من الوثائق الورقية المطولة التي تحدد تفاصيل المتطلبات والتصميم في محاولة لتخفيف العبء الإضافي الناتج عن تكوين واستخدام الوثائق التقليدية. كما تركز على توجيه العملية ككل من خلال ما يسمى مخططات حالات الاستعمال (Use Case Diagrams) والتي يتم تكوينها باستخدام لغة النمذجة الموحدة. وعلى الرغم من تركيزها على أسلوب البرمجة بالكائنات فإنها لا تستبعد بالضرورة استخدام الأساليب الأخرى ولكن مع مراعاة أن لغة النمذجة الموحدة صممت أساساً لخدمة البرمجة بالكائنات. 

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


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

أما الأطوار الأربعة فهي:

1. طور الابتداء (Inception Phase)
يتم تأسيس حالة العمل للمشروع وتحديد مجاله وتشمل حالة العمل معايير النجاح والمخاطرة وتوقع للموارد المطلوبة وخطة للطور تحدد معلمات الطريق الأساسية (Milestones) ويعد تطوير نموذج أولي (Prototype) للمشروع أمراً طبيعياً في هذا الطور. ومن خلال هذا الطور يتم بناء النماذج الأساسية التي توضح طبيعة الاستخدامات المتوقعة للنظام والعناصر التي ستتفاعل من خلال النظام أو معه وكذلك حالات الاستعمال الأساسية والحرجة. ومع نهاية هذا الطور تكون الصورة أصبحت أوضح وتوفرت لدينا معلومات كافية لاتخاذ القرار بشأن تطوير النظام بشكله الكامل أو التوقف في المشروع.

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

3. طور البناء (Construction Phase)
في هذا الطور يتم تحديد بقية حالات الاستخدام والمتطلبات واستكمال النظام وبناء جميع عناصره المختلفة وينتج عن هذا الطور إصدار النسخ التجريبية أو كما اصطلح على تسميتها الإصدارات ألفا وبيتا (Alpha, Beta Versions) وأي إصدارات اختباريه أخرى.

4. طور الانتقال (Transition Phase)
وفيه يتم نقل النظام إلى مستخدميه الحقيقيين من خلال عملية الإصدار والمتابعة واستقبال ردود الأفعال على المنتج لتحديد مدى الحاجة للدخول في دورة تطوير جديدة من عدمها.

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

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

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


RUP Phases

RUP Processes

 * البرمجة المتناهية Extreme Programming

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

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

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

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

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

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

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

- تخطيط الإصدارة (Release Planning): حيث يقوم العميل بتحديد الخصائص المطلوبة في الإصدارة الجديدة ويقوم الفريق بتقييمها وتحديد الجهد المطلوب لتنفيذها.
- تخطيط الدورة التكرارية (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)

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

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


 XP Processes Flow

XP Processes Flow

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

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

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


أساليب الجيل الجديد لإدارة تطوير البرمجيات أساليب الجيل الجديد لإدارة تطوير البرمجيات Reviewed by Ammar Moussa on 2:30 ص Rating: 5