AGILE SOFTWARE DEVELOPMENT I:

SOFTWARE CRISISالبرمجيات صناعة تعاني هل

أزمة؟ دعبس من سامح

الفهرس

مدخل•البرمجيات • SOFTWARE CRISISأزمةالمشروعات • فشل و نجاح نسب حول تقارير و دراساتالمشروعات • تعثر تحليلالمشروعات؟ • تفشل أو تتعثر لماذاالمشروعات؟ • تنجح لماذا•!! للطميات الللـ • الصحيح AGILE SOFTWARE DEVELOPMENTالمدخل

مدخل

• YOU HAVE BEEN ILL SERVED BY THE SOFTWARE INDUSTRY FOR 40 YEARS—NOT PURPOSELY, BUT INEXTRICABLY. WE WANT TO RESTORE THE PARTNERSHIP.

مدار • على البرمجيات صناعة تقدمها التي الخدمة سوء من عانينا , 40لقد , لكن و قصد عن ليـس سنة] [ . بتصرف , ذلك لتغيير األوان آن و الواقع هو هذا

شوابَر • منهجية , KEN SCHWABERكِن مؤسسي أحد هو البرمجيات - SCRUMو تطوير إدارة في الشهيرةالـ أحد المرنة 17و البرمجة يسمى لما الرسمي البيان على الموقعين AGILE MANIFESTOرجال

أزمة؟ • في البرمجات صناعة تعيش حقا فهل

البرمجيات SOFTWARE CRISISأزمة

• “ البرمجيات " أزمة مصطلح , SOFTWARE CRISIS ظهر في و الـعشرين القرن ستينات أواخر في , و الناشئة الصناعة منها تعاني التي المشكالت عن للتعبير البرمجيات هندسة علم تأسيس بدايات

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

البرمجيات هزلية – أزمة صورة

تاريخية – أمثلة البرمجيات HALL OF SHAME - أزمة

: http://spectrum.ieee.org/computing/software/why-software-failsالمصدر*

أزمة؟ من تعاني البرمجيات صناعة الزالت فهل

ستانديش مؤسسة سنة STANDISHتقارير 2009حتىالبرمجيات, • صناعة أن يزعمون من يعتمد عادة

تصدره الذي الدوري التقرير على أزمة في تعيشستانديش هي STANDISH GROUPمؤسسة و

حول دورية تقارير تصدر شهيرة بحثية مؤسسةالبرمجيات صناعة

التقارير • نتائج ملخصعام 2009حتى

كتاب, • المصدر BEGINNING APPLICATION LIFECYCLE MANAGEMENT

ستانديش مؤسسة 2009سنة STANDISHتقارير

• : الموعد في التسليم القياس المشروع– ON TIMEمـعايير بميزانية – ON BUDGETااللتزامالمرجوة الخصائـص SCOPEاكتمال

لسنة • التقرير :2009نتائج•44% , , الخصائص = كل توفِّ لم أو لها ُخطط مما أكثر تكلفت أو تسيمها تأخر متعثرة المشاريع من

منها المرجوة•24% , قط = تستخدم لم و ُسلمت أو تسليمها قبل ألغيت فشلت المشاريع من•32% , , المرجوة = بالوظائف و لها المخطط بالتكلفة و موعدها في ُسلمت نجحت المشاريع من

ستانديش مؤسسة STANDISH : 2011- 2015تقارير

•: القياس معاييرالموعد التسليم• فيالمشروع • بميزانية االلتزامالعميل • رضا

السابقة • التقارير عن تغيرت

HTTP://WWW.INFOQ.COM/ARTICLES/STANDISH-CHAOS-2015 :المصدر *

ستانديش تقاريرمؤسسة نتائج على مالحظات

الوقت • مع النتائج في تحسن هناكهي • تقرير آخر في المشروعات نـجاح , 29نسبة , أن% يوحي قد مما جدا ضئيلة نسبة هي و فقط

. بالفعل أزمة في تعيش الصناعة• , فاشلة التطبيقات هذه كل تكون أن يمكن ال و حولنا من شيء كل في التطبيقات نلمس أننا الواقع•. , العملية حياتنا في بأعيننا رأيناه هذا و للمؤسسة بالغة أهمية تمثل و مفيدة أنها إال متعثرة تكون قد المشاريع

• , : أن يظن أن ال كمؤشرات بها يستأنس أن المرء على ينبغي الدراسات هذه مثل مع التعامل في قاعدة , , آليات عن تفصـح ال أنها عن فضال عينات على تعتمد الدراسات هذه مثل فإن الحقيقي الواقع هو هذا

. , ... المؤسسة هذه لتقارير الموجهة االنتقادات من هذه و إلخ النتائج لهذه الوصول كيفية و البحث

. دوبز د مجلة آمبي+ DR. DOBB’Sتقارير مؤسسةAMBYSOFTسوفت

. 2006منذ • , د مجلة تقارير منها ستانديش مؤسسة تقارير دقة عدم تبين أخرى دراسات تظهر بدأتالشهيرة دوبز

المجلة • قراء رأي استطالع نتيجة دورية بصورة تخرج التقارير

:) مجمعة* ) غير التقارير //:مصادر . / /http ambysoft com surveys

مجلة 2007سنة ACMدراسة

قاربت • المشروعات نجاح % !!!!67نسبة

: كتاب* BEGINNING APPLICATION LIFECYCLE MANAGEMENTالمصدر

سنة - ستانديش تقرير المشروعات تعثر 2013تحليل

• : أستطع لم إذا مستفاد درس , فركز المطلوب كل إنهاء

أهم هذه% 20على مناألكثر, عادة فإنها المطلوبات

خالل من% 80استخداماالوقت!

مجلة – دراسة المشروعات تعثر 2007سنة ACMتحليل

الميزانية • تجاوز %13نسبةالتسليم • موعد تجاوز %20نسبةالمطلوبة • الخصائص في النقص %7نسبة

حسابية* متوسطات : كتاب* BEGINNING APPLICATION LIFECYCLE MANAGEMENTالمصدر

تفشل؟ أو المشروعات تتعثر لماذا

THE MYTHICAL MAN-MONTHالبرمجيات • أزمة يناقش الكتابسنة • األول المشكالت 1975اإلصدار من كثير من تعاني الصناعة زالت ال و م

!! ذكرها التي•: , ويكيبيديا على ملخصه قراءة األقل على أو القراءة يستحق الكتاب

://HTTPS . . / / _ _ -EN WIKIPEDIA ORG WIKI THE MYTHICAL MAN MONTHالفصل قراءة !19و الكتاب, من األول اإلصدار ملخص فإنه

الكالسيكية البرمجيات أزمة 1تجليات

الناس • و الوقت تبادلية THE MYTHICAL MAN-MONTHخرافةتأخرا • ستزيده المتأخر للمشروع أفراد إضافةفي • يولد !9الطفل , الوالدة عن المسئولين النساء عدد عن النظر بغض أشهر

التصور • تماسك أو األنظمة CONCEPTUAL INTEGRITYوحدة تصميم في االعتبارات أهم•CODING STANDARDS? – UNIFIED TOOLSET - CONSISTENT USABLE USER INTERFACES... - إلخالتحديث • و الصيانة صعوبة إلى يؤدي التصور وحدة عدم

الثاني • النظام SECOND SYSTEM EFFECTتأثير• ! وقعت! التي األخطاء كل تالفي ستحاول ألنك اإلطالق على األخطر هو النوع نفس من بتصميمه تقوم نظام ثاني انتبه

, الالزم عن زائدة هندسته نظاما النتيجة ستكون و األول النظام في !OVER-ENGINEEREDفيها

الكالسيكية البرمجيات أزمة 2تجليات

بابل • BABEL SYNDROMEمتالزمةالتواصل • ضعف هو الكبيرة المشروعات لفشل األسباب أهم التنسيق COMMUNICATIONأحد بالتالي ORGANIZATIONو

التغير • THE ONLY CONSTANCY IS CHANGE ITSELFثبات• , , له استعد و نفسك أهّل لكن و محالة ال قادم فإنه قدومه عدم تتوقع أو التغير تحارب ال• , , , , ذلك كل ربما و االستخدام صعب سيكون ربما بطيئا سيكون ربما ضخما سيكون ربما سيفشل غالبا نظام المقترح أول

التجريبي: = المشروع فكرة لالستبدال جاهزا نظاما ابن , PILOT PROJECTالقديم : قد. و بالتدريج النظام ابن الجديد المقترحالتجريبية النسخ اآلن BETA VERSIONSصارت شائعة

فضية • رصاـصة توجد NO SILVER BULLETال•] [ , األصلية الفكرة من تصرف و بتبسيط المشكالت كل يناسب واحد حل أو سحرية حلول توجد ال

الكالسيكية البرمجيات أزمة 3تجليات

البرمجية • !: SOFTWARE BUGSاألخطاء واّلدة •FIXING A DEFECT HAS A SUBSTANTIAL (20 TO 50 PERCENT) CHANCE OF INTRODUCING ANOTHER .عند

( , من كبيرة احتمالية هناك فإن ما برمجي خطأ !50إلى 20تصحيح أخرى%( أخطاء الستحداثالمراجعة • اختبارات أن التأكد من ! ] REGRESSION TESTSالبد هذا الحظ برمجي لخطأ تصحيح كل بعد صحيح بشكل تعمل

سنة [!!!1975الكالمالكوارث • واحدة: HATCHING CATASTROPHESتفريخ دفعة ليس و بالتدريج تحدث الكوارث

• , : حالة تقارير و قرار اتخذا منها يلزم استثنائية معلومات المعلومات من لنوعين يحتاج مدير و STATUS REPORTSكل للمتابعة. للمشكالت المبكر اإلنذار

• , التالوم من الخالية اآلمنة , BLAME-FREEالبيئة أوال, ) سيخبرك يخف لم إن انسيابي بشكل المعلومات تدفق و الشفافية تضمنبأول!(

التسليم • مواعيد تحديد هو الصحيحة الحالة معرفة لضمان شيء . DEADLINESأفضل المستمرة المتابعة و بها االلتزام محاولة و. التسليم موعد نحو للتقدم

البرمجيات فشل أسبابالواقعية • غير أو الغامضة األهدافالمطلوبة • الموارد تقدير في الخطأمستمر • بشكل المشروع حالة متابعة POOR REPORTING OF PROJECT STATUSعدمالمخاطر • إدارة في الفشلالتواصل • POOR COMMUNICATIONضعفناضجة • غير تقنيات على IMMATURE TECHNOLOGIESاالعتمادالمشروع • تعقيدات إدارة في الفشلالتطوير • في المتقنة غير أو السيئة HACKING-DRIVEN DEVELOPMENTالممارساتاإلداري • الفقر أو الضعفالمصلحة • أصحاب المتعارضة STAKEHOLDERSسياساتالسوق • ضغط

. , , تنظيمية و إدارية و فنية مجتمعة أسباب لعدة إنما واحد لسبب عادة الفشل يحدث ال : HTTP://SPECTRUM.IEEE.ORG/COMPUTING/SOFTWARE/WHY-SOFTWARE-FAILSالمصدر*

المشروعات؟ تنجح لماذا

المشروع حجم 1تأثيرمجلة • أجرتها التي الدراسة ACMفي

THE IMPACT OFبـعنوان 2007سنة SIZE AND VOLATILITY ON IT

PROJECT PERFORMANCE• , فرص زادت المشروع حجم زاد كلما

فشله أو تعثره• . فيه المبذول بالمجهود الحجم قياس

األشهر = × عدد األشخاص عدد المجهود

المشروع حجم 2تأثير

ستانديتش • مؤسسة تقرير STANDISHفيCHAOS REPORT 2015لسنة

لسنة • المشروع حجم قياس مـعيار أعلم السنة, 20015 معيار يعتبر 2013لكن كان

من أقل تتكلف التي مليون 1المشروعات , من أكثر تتكلف التي و صغيرة 10دوالر

ـكبيرة دوالر مليونhttp//:المصدر: . . / / - -2015www infoq com articles standish chaos

المشروع مواصفات تعقد REQUIREMENTSتأثيرCOMPLEXITY

•. تعقده مع يزيد المشروع فشل أو تعثر احتمال أن إلى يشير السابق التقرير نفس

المشروع تنفيذ زمن تأثيرمجلة • أجرتها التي الدراسة سنة ACMفي

THE IMPACT OF SIZEبعنوان 2007AND VOLATILITY ON IT PROJECT

PERFORMANCEفرص • زادت المشروع تنفيذ زمن زاد كلما

فشله و تعثرهمن • أكثر المشروع زمن كان تزيد 18إذا

! جدا الفشل احتمالية

الفريق حجم تأثيرمجلة • أجرتها التي الدراسة سنة ACMفي

THE IMPACT OF SIZE ANDبعنوان 2007VOLATILITY ON IT PROJECT

PERFORMANCEعن • الفريق حجم زاد احتمالية, 20إذا زادت

جدا فشله و تعثرهمن • متقاربة 20أقل التعثر احتمالية تقريبافريدريك • قاله ما مع متوافقة النتائج هذه

كتابه في -THE MYTHICAL MANبروكسMONTH سنة للمشوع: 1974من أفراد إضافة

! تأخرا إال تزيده لن المتأخر

الرؤية وضوح تأثير

المتطلبات • في التغير مع طرديا تتناسب الفشل و التـعثر احتمالية أن ذكرت السابقة الدراسة نفسREQUIREMENTS CHANGING

• : كتاب الدراسة BEGINNING APPLICATION LIFECYCLE MANAGEMENTمصدر

المتبعة المنهجية PROCESS 1تأثيرستانديتش • مؤسسة تقرير

STANDISH CHAOS REPORT 2015لسنة

المتبعة المنهجية PROCESS 2تأثير• + . سنة سوفت آمبي مؤسسة دوبز د مجلة تقرير

2013) بتصرف )المرنة • المنهجات باتباع أعلى النجاح احتماليات

AGILE التقليدية المنهجيات TRADITIONALـمناالرتجالية AD-HOCأو

المنهجات • باتباع أقل الفشل و التعثر احتمالياتالمنهجيات AGILEالمرنة من

االرتجالية TRADITIONALالتقليدية -ADأوHOC

http://www.ambysoft.com/surveys/success2013.htmlالمصدر:

! للطميات ال

المرنة • البرمجة حركة ظهور قبل مخدومة تكن لم البرمجيات صناعة أن AGILE SOFTWAREاالدعاءDEVELOPMENT! خاطيء – - لكنـه و شائع مدخل العرض بداية في قدمنا كما

•! , جديدة قديمة مشكالت ـمن تخلو لم إن و حقيقية أزمة من تعاني ال البرمجيات صناعة أن تبين اإلحصاءات•: النجاح أسباب أهم خالصة

مصري !! – • مثل سكر« تاكل نملة »عيشقصير – – • زمن صغير فريق صغير المشروع

•GO AGILE!• , , هذه العام االتجاه فهي الخاطيء المدخل غير من لكن و بالفعل المرنة البرمجة حركة نجاح تبين اإلحصاءات

األيام...

المرنة؟ البرمجة أساليب شيوع مدى 1ما• . مع دوبز د مجلة تجريه الذي االستبيان نتيجة

لسنة سوفت آمبي 2014مؤسسة

HTTP//:المصدر: •. . / /WWW AMBYSOFT COM SURVEYS S

2014 2.TATEOFITUNION Q HTML

المرنة؟ البرمجة أساليب شيوع مدى 2مافورستر • مؤسسة نشرتها دراسة :2011سنة FORRESTERفي بعنوان

WATER-SCRUM-FALL IS THE REALITY OF AGILE FOR MOST ORGANIZATIONS TODAYالخالصة: •

• , خالصة ليست لكنها شائعة المرنة البرمجة AGILE IS POPULAR BUT NOT PUREأساليب• : الدراسة عليه أطلقت ما هو شيوعا المناهج و WATER-SCRUM-FALLأكثر التقليدية األساليب من هجين هي و

سقرام سيئا SCRUMأسلوب أو حسنا ليس هذا و

تبنتها التي المؤسسات في المرنة البرمجة تطبيق تأثير• . مع دوبز د مجلة تجريه الذي االستبيان نتيجة

لسنة سوفت آمبي 2014مؤسسة

HTTP//:المصدر: •. . / /WWW AMBYSOFT COM SURVEYS S

2014 2.TATEOFITUNION Q HTML

#EndOfText ;-)