إدارة الديون الفنية مع DX و AI

كل شركة، كبيرة أو صغيرة، تهتم بالديون الفنية. وتقدر جارتнер أن حوالي 40% من أنظمة البنية التحتية تعاني من هذه المشكلة. وفي استطلاع أجري على مسؤولي تقنية المعلومات من قبل مكينزي، شعر حوالي ثلثهم أن أكثر من 20% من ميزانيتهم الجديدة للمنتجات ذهبت إلى حل مشاكل تتعلق بالديون الفنية. ولكن على عكس ما يعتقد الكثيرون، هذه ليست مشكلة برمجة فقط؛ إنها أيضًا مشكلة تجربة المطور (DX). لأن عندما يضطر المطورون إلى العمل مع هندسة غير كافية، وأدوات قديمة، وعمليات تطوير رديئة، تعاني الإنتاجية والأداء والروح المعنوية.

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

دعم DX

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

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

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

أيضًا، يتوقع IDC أن يستمر سوق اختبار البرمجيات التلقائي القائم على الذكاء الاصطناعي في النمو بمعدل نمو سنوي مركب يبلغ 31.2% حتى عام 2027، لذا تأكد من استخدام هذه التكنولوجيا إلى أقصى حد.

المقاييس و علامات التحذير

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

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

اللعب مع أدوات الذكاء الاصطناعي

يُعتقد أن صعود أدوات الذكاء الاصطناعي سيجعل المطورين والمهندسين أكثر إنتاجية وسيجعل المنتجات تصل بشكل أسرع، ولكن الديون الفنية تبطئ ذلك. دعنا نقول إنك تستخدم أداة مثل GitHub أو Copilot لمساعدتك في تغيير الشفرة، ثم تقدم طلب سحب، ويتطلب CI ساعات ليعود إليك. في غضون ذلك، هل يعمل المطور على شيء آخر؟ يتحقق من البريد الإلكتروني؟ إنه تبديل سياق و قاتل للإنتاجية.

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

هناك حالة لصالح وكلاء الذكاء الاصطناعي مع مهندسين يتصرفون كمنسقين. كشفت دراسة قام بها كابجيميني عن 1,100 مسؤول تنفيذي في الشركات الكبيرة أن 82% يخططون لدمج وكلاء الذكاء الاصطناعي في течение ثلاث سنوات قادمة، وهم يؤثرون بالفعل على مستقبل العمل. قد تكون تنظر إلى تقرير خطأ وترى أنه صغير بدرجة كافية لوكيل الذكاء الاصطناعي لمعالجته من البداية إلى مراجعة الشفرة، مما يوفر وقت فريقك وتحريرهم لمعالجة عمل أكثر تعقيدًا. ومع ذلك، في بعض الأحيان عندما نتبع هذه الأدوات بشكل أعمى، هناك تنازلات التي يصعب على الذكاء الاصطناعي مراعاتها.

هذا هو عندما يصبح الرأي البشري العامل الحاسم.

مواءمة الديون الفنية مع الأهداف

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

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

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

الديون الفنية مع الفوائد

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

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