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

Lightweight Methodologies

 

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

 

1.    التكيف بدلاً من التكهن

(Adaptive over Predictive)

 

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

 

2.    توجيه الأشخاص بدلاً من توجيه العمليات

(People-Oriented over Process-Oriented)

 

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

 

3.    الاتصال وجهاً لوجه بدلاً من الوثائق

(Face-to-Face Communication over Documentation)

 

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

 

4.    دمج التصميم والإنشاء

(Merging Design & Construction)

 

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

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

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

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

 

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

 

 

5.    قيمة الأفراد

(Value of People)

 

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

 

6.    تعاون العميل بدلاً من مفاوضات التعاقد

(Customer Collaboration over Contract Negotiation)

 

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

 

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

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