المحتوى
- لماذا رشيق تكنولوجيا المعلومات؟
- كيف تتعامل منهجية أجيل مع مشاكل نموذج الشلال؟
- كيف أثرت رشيقة على صناعة تكنولوجيا المعلومات؟
- No Bugs، No Stress - دليلك خطوة بخطوة لإنشاء برامج لتغيير الحياة دون تدمير حياتك
- أسباب BT تحولت إلى ممارسات رشيقة
- سوء إدارة المتطلبات
- سوء تصميم البرمجيات
- قيود التنمية
- ماذا فعلت BT لمعالجة المشكلات المذكورة أعلاه؟
- خاتمة
المصدر: Darkovujic / Dreamstime.com
يبعد:
بالنسبة للكثيرين ، كان نموذج الشلال لتطوير البرمجيات هو المعيار لعقود ، ولكن يتم استبدال هذا الآن بمنهجية Agile الأكثر مرونة.
يمكن أن تؤثر منهجية Agile لتطوير البرمجيات بشكل إيجابي على صناعة تكنولوجيا المعلومات. نتائج قياس منهجية رشيق يمكن قياسها في عدد من الطرق. إن التحول السريع لطلبات تغيير البرامج ، وعدد أقل من الأخطاء ، والقياس الكمي لأداء الفريق ، والاختناقات ، كلها انعكاسات للتنفيذ الناجح لبرنامج Agile. لقياس تأثير Agile بنجاح ، تحتاج المنظمة إلى مقارنة المقاييس المختلفة المتعلقة بالتطوير قبل Agile وما بعد Agile. لا يمكن قياس التأثير الحقيقي لـ Agile بمجرد زيادة الإيرادات أو زيادة عدد الأخطاء التي تم إصلاحها. يجب مراعاة العديد من المعايير الداخلية لفهم التأثير الحقيقي. (لمزيد من المعلومات حول تطوير Agile ، راجع Agile Software Development 101.)
لماذا رشيق تكنولوجيا المعلومات؟
تميل صناعة تكنولوجيا المعلومات إلى ممارسات Agile بشكل رئيسي بسبب قيود نموذج الشلال لتطوير البرمجيات. عمومًا ، لوحظ أن شركات تكنولوجيا المعلومات غير قادرة على الاستجابة لمتطلبات العملاء المتغيرة أو أوضاع السوق أو خفض التكاليف باستخدام نموذج الشلال لتطوير البرمجيات. حتى لو قمنا بموازنة هذا الميل الساحق نحو منهجية Agile واعتبرنا أن بعض الإثارة مجرد ضجيج ، فهناك الكثير من الملاحظات التجريبية ضد نموذج الشلال.
ببساطة ، نموذج الشلال هو نموذج لتطوير البرمجيات حيث يتم العمل بطريقة متسلسلة - مرحلة واحدة تلو الأخرى. هناك خمس مراحل من هذا النموذج: المتطلبات والتصميم والتنفيذ والتحقق والصيانة. عادة ، بعد الانتهاء من مرحلة واحدة ، من الصعب ، إن لم يكن من المستحيل ، إجراء تغييرات على مرحلة سابقة. لذلك ، الافتراض هو أن المتطلبات ثابتة إلى حد كبير. الفرق الرئيسي في نموذج Agile هو الافتراض بأنه لن يكون هناك تغيير في المتطلبات. Agile يفترض أن مواقف العمل سوف تتغير وكذلك المتطلبات. لذلك ، يتم تسليم البرامج في مجموعات أصغر على أجهزة الكمبيوتر الصغيرة ، بينما في نموذج الشلال ، يتم إجراء التسليم أو الإصدار الأول بعد وقت طويل. (لمزيد من المعلومات حول التطوير ، راجع كيف يساعد Apache Spark في تطوير التطبيقات السريعة.)
كان أبرز الانتقادات الموجهة ضد نموذج الشلال هو الافتراض بأنه لن يكون هناك تغيير في المتطلبات. الافتراض ذاته معيب وغير واقعي. على سبيل المثال ، في عام 2001 ، أظهرت دراسة أجريت على 1،027 مشروعًا لتكنولوجيا المعلومات في المملكة المتحدة أن هذا الافتراض كان السبب الوحيد الأكبر لفشل مشروعات تكنولوجيا المعلومات.
في مثال آخر ، أشار كريج لارمان ، مؤلف كتاب "التطوير الرشيق والتكراري: دليل المدير" ، إلى كيف فشل عدد من المشاريع التي نفذتها وزارة الدفاع باستخدام نموذج الشلال في الولايات المتحدة في تحقيق أهدافهم. خلال الثمانينيات والتسعينيات ، طُلب من وزارة الدفاع استخدام نموذج الشلال لمشاريع تطوير البرمجيات الخاصة بها وفقًا للمعايير المنشورة في DoD STD 2167. كشفت إحصائيات مروعة أن 75٪ من مشاريع البرامج هذه لم تستخدم أبدًا. بعد هذا التقرير ، تم إنشاء فريق عمل تحت إشراف الدكتور فريدريك بروكس ، وهو خبير هندسة البرمجيات المعروف. خرجت فرقة العمل بتقرير علق فيه "DoD STD 2167 يحتاج كذلك إلى إصلاح جذري يعكس أفضل الممارسات الحديثة. التطور التطوري هو الأفضل تقنياً ، فهو يوفر الوقت والمال ".
لقد فشلت الافتراضات الأربعة التالية لنموذج الشلال في سيناريوهات العالم الحقيقي:
- المتطلبات المحددة محددة بشكل جيد وبالتالي لن تتغير بشكل كبير.
- حتى لو تغيرت المتطلبات خلال مرحلة التطوير ، فإنها ستكون صغيرة بما يكفي لاستيعابها في دورة التطوير.
- تكامل النظام ، الذي يحدث بعد تسليم البرنامج ، سيتم وفق الخطة.
- سيتم ابتكار البرمجيات والجهد المطلوب للابتكار وفقًا لجدول زمني مخطط له ويمكن التنبؤ به.
كيف تتعامل منهجية أجيل مع مشاكل نموذج الشلال؟
تختلف منهجية أجيل اختلافًا جذريًا عن نموذج الشلال وهذا واضح من افتراضاته:
- لا أحد ، ولا حتى العميل ، يمكنه معرفة أو فهم المتطلبات بشكل كامل. ليس هناك ما يضمن أن المتطلبات لن تتغير.
- قد لا تكون التغييرات المطلوبة صغيرة ويمكن التحكم فيها. في الواقع ، سوف تأتي في أحجام مختلفة وسوف تستمر في المجيء. لذلك ، سيتم تسليم البرنامج بزيادات صغيرة لتتبع التغييرات.
كيف أثرت رشيقة على صناعة تكنولوجيا المعلومات؟
يتم تبني Agile في العديد من الأماكن ، في حين أن الكثير من الشركات تضع خططًا لتبني Agile. على الرغم من أن Agile قامت بالتأكيد بإجراء تغييرات جوهرية على صناعة تكنولوجيا المعلومات ، إلا أن الحقائق والأرقام ما زالت صعبة بعض الشيء. ولكن يمكن فهم تأثير Agile من خلال دراسة حالة شركة بريتش تيليكوم (BT) الواردة أدناه.
No Bugs، No Stress - دليلك خطوة بخطوة لإنشاء برامج لتغيير الحياة دون تدمير حياتك
لا يمكنك تحسين مهارات البرمجة لديك عندما لا يهتم أحد بجودة البرنامج.
أسباب BT تحولت إلى ممارسات رشيقة
بدأت BT في مواجهة عدد من المشكلات مع ممارسات تطوير البرمجيات الخاصة بها في عام 2004. طورت BT عددًا من مشاريع البرامج ، البسيطة والمعقدة. لم تتمكن العديد من مشاريع البرامج من تطوير مخرجات الجودة ضمن الإطار الزمني المتفق عليه. وجدت BT أن المشكلات تكمن في جذورها في نموذج الشلال. لذلك ، لن يساعد تعزيز نموذج الشلال. فيما يلي الأسباب الرئيسية للمشاكل:
سوء إدارة المتطلبات
- لقد تم توفير الكثير من المتطلبات خلال فترة زمنية محدودة للغاية.
- كانت العديد من المتطلبات غير ملائمة لاحتياجات العمل.
- جميعها تقريبًا ، إن لم يكن كل المتطلبات تم تعيينها على أنها ذات أولوية عالية.
- تمثل المتطلبات احتياجات العمل الحالية دون النظر إلى السيناريوهات المستقبلية. ترك ذلك مفتوحًا احتمال حدوث تغييرات في البرامج في المستقبل.
سوء تصميم البرمجيات
- بالنظر إلى العدد الهائل من المتطلبات ، قضى المصممون الكثير من الوقت في محاولة لمعرفة ما تعنيه المتطلبات. بقي القليل من الوقت للتصميم الفعلي.
- انتقل محللو المتطلبات إلى مهام أخرى ، وأخذوا معهم معرفة ضمنية غير مكتوبة.
- العوامل المذكورة أعلاه أدت إلى سوء التصميم. كان على المصممين تقديم ما زال وفقًا للجدول الزمني الأصلي.
قيود التنمية
كان الترميز متسرع وذات جودة رديئة بسبب تصميم البرنامج المعيب. قد يدرك المطورون أن تصميم البرامج الرديء سيؤدي إلى رمز رديء ، ولكن مع ذلك كان يتعين عليهم تقديمه بحلول الجدول الزمني المتفق عليه. سيتم الإبلاغ عن الكثير من الأخطاء أثناء الدمج لأنه لم يتم تشغيل اختبارات الوحدة واختبارات الانحدار.
بحلول وقت نشر البرنامج ، يلاحظ العميل أن المتطلبات قد تغيرت بالفعل وكذلك سيناريو الأعمال. البرنامج لديه أيضا الكثير من المشاكل. على نحو فعال ، أصبح مجهود تطوير البرامج بأكمله مضيعة للوقت.
ماذا فعلت BT لمعالجة المشكلات المذكورة أعلاه؟
أدركت BT أن تعزيز نموذج الشلال لم يكن هو الحل للمشاكل. انها بحاجة الى نهج جديد. لذلك ، قررت تنفيذ نهج رشيق. بموجب النهج الجديد ، تم تحديد الأمور التالية:
- بدلاً من دورة التطوير التي تبلغ مدتها 12 شهرًا ، ستقوم BT بتقديم قطع قابلة للتطبيق من البرمجيات في دورة مدتها 90 يومًا. كانت الفكرة هي التركيز على واحد أو اثنين من مشاكل العمل والهدف من تقديم حل البرمجيات في غضون 90 يوما. تميزت بداية هذه الدورة بمناقشة مكثفة بين مختلف أصحاب المصلحة بحيث تم تحديد المتطلبات وتحليلها وترتيب أولوياتها بشكل واضح.
- كان الهدف هو تقديم قيم أعمال واضحة وملموسة. كان العميل الداخلي تحت الضغط لتوفير متطلبات واضحة. لذلك ، بدلاً من الأهداف الغامضة ، تم منح قصص المستخدمين بمعايير قبول واضحة.
- سيتم اختبار وتوثيق البرنامج الذي سيتم تسليمه بالكامل. سيختبر البرنامج اختبارات تكامل متكررة لتحديد المشكلات مسبقًا.
مع نهج Agile ، يمكن أن تتكيف BT مع المتطلبات المتغيرة أو مواقف العمل بسهولة أكبر. تم تحسين جودة الرمز وتمت معالجة الأخطاء الأساسية في اللحظة الأخيرة.
خاتمة
Agile ، على الرغم من جميع مزاياها والضجيج المحيط بها ، لا تزال في مرحلة لا تتحقق فيها إمكاناتها بالكامل. وذلك لأن الكثير من المنظمات تقوم بتخصيص النهج إلى حد تعديل مبادئه الأصلية. نتيجة لذلك ، يعود نموذج الشلال إلى الخلف في بعض الحالات. بينما سيستمر التخصيص ، من المهم الاحتفاظ بمبادئ Agiles الأساسية. تدعي الكثير من المنظمات أنها رشيقة تمامًا ، لكن لا يزال أمامها طريق ما لتصبح شركة رشيقة حقًا.