تقديم الصيانة للتطبيقات الرشيقة

بحلول نهاية عام 2022، انتهى 72% من الشركات كانوا يستخدمون Agile لتطوير البرمجيات. ولماذا لا يفعلون ذلك؟ يحل Agile محل العملية المتسلسلة والمجهدة في كثير من الأحيان خطوة بخطوة لتطوير برمجيات الشلال التقليدية. يستخدم مطوري التطبيقات متعددي التخصصات من أقسام تكنولوجيا المعلومات والمستخدمين النهائيين ويسمح لهم بمراجعة التطبيقات وإعادة نشرها بسرعة. وبهذه الروح، بيان أجيل هو عقيدة من أربع نقاط:

يبدو جيدًا: ولكن عند أي نقطة يجب أن تكون هناك خطة، بما في ذلك نهج الصيانة رشيق؟

السعي لتحقيق التحسين رشيق

“هناك الكثير من المنظمات التي تعمل من خلال [Agile] التحول لعدد من السنوات، وأنفقت ملايين الدولارات، ولم تشهد بعد أي فوائد وعدت بها Agile. وأشار سي برايم

مراجعة الأعمال بجامعة هارفارد يعترف بتحديات مماثلة:

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

متعلق ب:الطريق إلى الأمام للتعلم السريع في عالم الذكاء الاصطناعي

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

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

ماذا يعني الحفاظ على رشيقة

في تطوير تطبيق الشلال، يدخل التطبيق في دورة صيانة وتحسين بمجرد نشره في الإنتاج. ومع ظهور تغييرات جديدة، يتم ترميز هذه التغييرات بشكل تسلسلي واختبارها وإدراجها وإعادة اختبارها ثم نشرها. هذا هو نهج تطوير خط تجميع Model T Ford الذي تسعى Agile إلى تجنبه.

متعلق ب:نصائح لجعل إطار عمل Agile الخاص بك أكثر مرونة

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

إليكم السبب:

تحتاج المنظمات إلى الحد من هدر البرمجيات. Zylo، مزود حلول تكنولوجيا المعلومات، يفيد بأن بقدر ما 51% من البرمجيات لا تستخدم في الشركات. كان تقرير Zylo يبحث في البرامج التي تم ترخيصها، لكن مديري تكنولوجيا المعلومات يعرفون أن هدر البرامج ينطبق أيضًا على التطبيقات التي يتم تطويرها داخليًا ثم تقع في حالة عدم الاستخدام.

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

مع Agile، تعتمد منهجية التطوير على تكرار لا نهاية له. لا توجد إرشادات لنقطة النهاية، مثل متى يجب إيقاف تطبيق Agile أو إزالته لعدم الاستخدام. ومع ذلك، يمكن لتطبيقات Agile أيضًا أن تصل إلى “نهاية الطريق” مثل نظيراتها من تطبيقات الشلال.

متعلق ب:إعادة النظر في تأثير الذكاء الاصطناعي على تطوير البرمجيات واختبارها

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

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

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

هل حان الوقت لنقل التطبيق إلى وضع الصيانة، حيث تتم معالجة الأخطاء البرمجية فقط؟

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

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

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

في جوهر الأمر، يؤدي ذلك إلى تحويل تطبيق Agile الأولي إلى تطبيق انحداري والموضوعات إلى إرشادات صيانة برنامج الشلال.

يوفر تركيز Agile على التعاون بين المستخدم وتكنولوجيا المعلومات وأوقات التطوير السريع للسوق إمكانات هائلة للمؤسسات. نعم، سيكون هناك أيضًا وقت ستصل فيه تطبيقات Agile إلى وضع الصيانة.

لم تفكر سوى عدد قليل من المؤسسات في هذا الأمر حتى الآن، ولكن ليس من السابق لأوانه بالنسبة لمدراء تكنولوجيا المعلومات أن يبدأوا بالتحرك.