 |
المنهجيات الرشيقة و اثباتهاالنمذجة الرشيقة: ما مقدار الادلة التي تحتاجها في رأيك؟ سكوت امبلر .
فبراير 2002 | |
|
التجربة خير برهان |
إن تبنّي ثم اخضاع عمليات برمجية معينة (Software Process) لإحتياجات فريق العمل لديك هو قرار مهم و صعب، و له تأثير على نجاح مشروعك البرمجي. فستواجه ما لا يحصى من الخيارات، تتدرّج من المناهج المقيدة مثل العمليات الموحدة من راشيونال "روب" Rational Unified Process (RUP) و عمليات "أوبن" OPEN إلى مناهج البرمجيات الرشيقة agile مثل البرمجة المتطرفة "اكس بي" Extreme Programming (XP), و "سكروم" SCRUM و المنهجبة الحيوية لتطوير النظم Dynamic System Development Methodology (DSDM). العديد من المواد كتبت حول هذه المنهجيات، و لكن السؤال هنا كيف يمكنك أن تقرر أيا من هذه المنهجيات سوف تناسبك؟ و خاصة كيف يمكنك أن تحدد ما إذا كانت منهجية التطوير الرشيقة سوف تصلح في بيئة العمل لديك. إذا ما قضيت و قتا على الشبكة مطالعا لما له علاقة بالعمليات في مصادر مثل القوائم البريدية في مجموعات "ياهوو" Yahoo! أو منتديات comp,object فغالبا ما تلاحظ الممسك العام الذي يأخذه النقاد على المنهجيات الرشيقة طافيا على السطح و هو:" أين الاثبات؟"، يبدو هذا سؤالا معقولا، لأن العديد من المطوّرين يريدون تأكيدا على أن هذه الاتجاهات الجديدة صالحة للعمل على أرض الواقع. عموما، أشعر بأن هؤلاء الناس يطرحون أسئلة في غير موقعها لعدة أسباب: على الباحثين عن الإثبات أن يتذكّروا، أولا و قبل كل شيء، أن منهجيات تطوير البرمجبات الرشيقة لا زالت جديدة:
لأن المناهج الرشيقة لا زالت جديدة، فهي ببساطة لم يتح الوقت الكافي لإثبات أنها صالحة للعمل في حالات واسعة التعدد. بالتأكيد، لكل منهجية دليل شيّق لكفائتها، لكن إثباتات إحصائية مبنية على دراسات مفصلة لم تظهر بعد، و غالبا ما ستتأخر هذه الاثباتات لعدة سنوات أخرى. بعض نتائج الأبحاث - مثال ذلك، جدوى البرمجة الزوجية pair programming-- تم إختبارها بالتفصيل، كما أن عناصر الإتجاهات الخاصة بالمعاودة و التزايد iterative and incremental أصبحت معروفة. عموما، علينا الانتظار بعض الشيء لحين ظهور المقاييس المتعلقة بالمناهج الرشيقة لتطوير البرمجيات. من المتجاهلين إلى المخترعينبغض النظر عن جاذبية الجدوى "الموثقة"، فليس من الواقعية أن نطلب "إثباتا" على أن منهج ما صالح للعمل قبل أن تتاح له فرصة العمل. في كتابه، "عبور الفجوة"Crossing the Chasm (Harper Business, 1999)، وصف المستشار الإداري جيفري مولر "Geoffrey Moore" خمس فئات من متبني التقنية: "المخترعون"، الذين يلاحقون المفاهيم الجديدة بقوة؛ "السابقون بالتبني"، الذين يلاحقون المفاهيم الجديدة مبكرا في دورتها الحياتية؛ "الأغلبية الأولى"، الذين ينتظرون مراقبين قبل أن يقوموا بالاستثمار في مفاهيم جديدة؛ "الأغلبية المتأخرة"، الذين يقلقون على قدرتهم على التعامل مع مفهوم جديد ينبغي تبنيه؛ و "المتجاهلون"، الذين ببساطة يرفضون التعامل مع أية مفاهيم جديدة. الناس الذين يتطابقون مع صورة المخترعين أو المتبنين الأوائل نجدهم يستمتعون بقراءة صفحة شبكية WEB أو كتاب يصف التقنيات الرشيقة؛ هم سيفكرون في المفاهيم الجديدة ومن تم يطوّعونها لبيئتهم. نحن الآن في هذه المرحلة من الدورة الحياتية حيث تقف معظم التقنيات الرشيقة. و هذا النوع من المؤسسات هي الأكثر تقبلا لتبني هذه التقنيات الجديدة. الأغلبية الأولى لا زالت تنتظر أدلة ناقدة و كافية قبل أن تقوم بقفزتها نحو التطوير الرشيق للبرمجيات. عندما يظهر مثل هذا الاثبات في مؤتمر مثل XP 2002 و XP/Agile Universe ، فأنا أتوقع أن المزيد من هذه المجموعات ستقوم بقفزتها خلال السنة القادمة أو نحو ذلك. للأسف، فإن السؤال "أين الإثبات؟" عادة ما تسأله المؤسسات التي ينطبق عليها وصف الأغلبية المتأخرة إن لم يكن المتجاهلة. ولأنه من الواضح أن التقنيات الرشيقة لم تصل بعد لهذه المرحلة، فأنا أعتقد أن هذا السؤال ببساطة ليس عادلا. عموما، وبما أن هذه المؤسسات لم يسبق لها و أن كانت على "الحافة الدامية" للإختراع فستجد نفسها مرتاحة مع مثل هذا النموذج من التعامل "راقب و انتظر". تحديد المعيارأخشى ان الدلال المفرط قد افسدنا: فالجهود السابقة في ميدان مقاييس البرمجة جعلت من معايير الصلاحية عالية جدا. في كتابه، (التقييم، الإختبارات القياسية و أصلح الممارسات في البرمجة Software Assessments, Benchmarks, and Best Practices (Addison-Wesley, 2000) قدّم كابرس جونز Capers Jones رئيس مركز مركز أبحاث الانتاجية البرمجية، وفرة من المعلومات تم تجميعها خلال عقود تتعلق بأساليب وتقنيات بناء البرمجيات. في الجدول 5.4 من هذا الكتاب قام جونز بتوثيق مدى فاعلية مجموعة من فنيّات التطوير. و بمعامل ضبط يبلغ 350% ، تم تصنيف تقنية إعادة استخدام المخرجات عالية الجودة على أنها "الأكثر فعالية"، بينما كان لأدوات تقدير الجودة معامل بلغ 19%، و لإستخدام طرق الفحص العادية معامل 15%. في الجدول 5.5 تم عرض العوامل ذات التأثير السلبي. فمثلا، مساحات المكاتب المزدحمة تؤثر بنسبة -27% من عملية الضبط، غياب مشاركة الزبون يشكل -13% كعنصر ضبط، والتباعد الجغرافي يؤثر سلبا بنسبة 24%. كما تشير هذه الإحصائيات، فإن أصلح و أسوأ العمليات الحالية تم اختبارها بالتفصيل، لكن نتائج التقنيات الجديدة المقترحة مثل معاودة التنقيح refactoring و التواجد المشترك مع الزبائن لم يتم تحليلها بصورة كافية. و مما زاد الأمر سوءا، أن معظم منظري المنهجبات الرشيقة هم ممارسون منهمكون في مشاريع برمجية لا تتاح لهم فسحة من الوقت لقضائه في دراسات نظرية. ربما سيمضى وقت طويل حتى نرى دراسات رشيقة تحاكي تحليلات جونز للتقنيات التقليدية. قد لا يكون واضحا ما الذي تبقّى و يجب اثباته. في
الفصل 3 من كتابه المنتظر، مجتمعات تطوير البرامج الرشيقة Agile Software
Development Ecosystems (Addison-Wesley,
2002)، لاحظ جيم هايسميث Jim Highsmith: ربما كانت نوايا الباحثين عن الاثبات ليست سليمة. هل هم فعلا حريصون على إيجاد عمليات ناجعة، أم فقط يبحثون عن سبب للتقليل من شأن اتجاه غير مرتاحين له؟ هل هم واقعيين بما يكفي لكي يدركوا انه لا توجد عمليات برمجية كاملة- بأنه لا توجد أية رصاصة فضية= حل نهائي يمكن البحث عنه؟ هل هم حقا مهتمون لإثبات أن شيئا ما صالح للعمل، أو هل هم ببساطة يبحثون عن تأكيد لوجود أمان محسوس؟ حتى الآن، شواهد نقدية مهمة تشير إلى صلاحية التقنيات الرشيقة في تطوير البرمجيات، يوجد القليل جدا من الاثباتات الإحصائية المعتمدة- و لن يتغيّر الحال في المنظور القريب. إذا كانت الشواهد النقدية غبر كافية، فان عمليات تطوير البرمجيات الرشيقة ليست من أجلك .. بعد! أودّ أن أشكر: David M. Rubin، Tim Bond، Dale Emery، Remy Fannader، Adam Geras، Michael Krige، Rob Lineberger، Ed Manley و Dave Thomas من أجل ملاحظاتهم القيّمة . سكوت و. امبلر Scott W. Ambler
| |
|
| ||
