وبلاگ
بازطراحی فرآیند تحویل نرم‌افزار در عصر هوش مصنوعی عامل‌محور
نحوه‌ی به‌کارگیری هوش مصنوعی عامل‌محور در توسعه‌ی نرم‌افزار، نشانه‌ای از تحولی بسیار بزرگ در مدل تحویل نرم‌افزار سازمان‌هاست.
ساعت نه صبح است. مالک محصول وارد سامانه می‌شود تا پیشرفت شبانه‌ی راهکاری را که تیمش روی آن کار می‌کند بررسی کند. او می‌بیند یکی از قابلیت‌ها از مرحله‌ی «الزامات ساختاریافته» به مرحله‌ی «کد آزمایش‌شده» رسیده است. موارد حاشیه‌ای مشخص شده‌اند، وابستگی‌های معماری اعتبارسنجی شده‌اند، و خلاصه‌ای کوتاه از نکات مهم و تصمیم‌های هنوز نهایی‌نشده ارائه می‌دهد.
هیچ‌کس تا دیروقت کار نکرده؛ عامل‌های هوش مصنوعی شب را کار کرده‌اند.
در اواسط صبح، تیم انسانی مشغول بررسی خروجی‌ها، اصلاح ریل‌های ایمنی (guardrails) و اولویت‌بندی مجدد بک‌لاگ است. تا عصر، ورودی‌های ساختاریافته‌ی بعدی برای عامل‌ها آماده می‌شود تا در چرخه‌ی شبانه‌ی دیگری روی آن‌ها کار کنند.
این الگوی کاری ۲۴ساعته دیگر یک ایده‌ی نظری نیست. سازمان‌های پیشرو در حال بازطراحی فرآیند تحویل نرم‌افزار خود حول محور اجرای بی‌وقفه هستند. اگرچه این مدل هنوز به سرعت در حال تحول است، چندین شرکت هم‌اکنون شاهد بهبود سه تا پنج برابری بهره‌وری، همراه با کاهش ۶۰ درصدی اندازه‌ی تیم‌ها هستند. نکته‌ی مهم این‌جاست که این سازمان‌ها این دستاوردها را صرفاً با استقرار عامل‌های هوش مصنوعی به دست نیاورده‌اند، بلکه با بازطراحی کامل مدل عملیاتی خود، به‌گونه‌ای که انسان‌ها و عامل‌ها بتوانند ۲۴ ساعته با یکدیگر همکاری کنند، بدست آورده اند.
اسپرینت ۲۴ساعته: طراحی برای توان عملیاتی مستمر
شرکت‌های پیشرو در حال گذار به مدل «اسپرینت روزانه» هستند؛ مدلی که قضاوت انسانی را با اجرای شبانه‌ی عامل‌ها ترکیب می‌کند و در مقایسه با چرخه‌ی معمول دوهفته‌ایِ اسپرینت‌ها، کاهش چشمگیری در طول چرخه ایجاد می‌کند.
در طول روز، نیروی انسانی بر بررسی خروجی‌ها، رفع ابهامات، تقویت ریل‌های ایمنی معماری و هم‌راستاسازی ذی‌نفعان متمرکز می‌شود. نقش انسان‌ها به‌تدریج از «تولید محصولات کاری» به «نظارت و بهبود سامانه‌ای که این محصولات را تولید می‌کند» تغییر می‌یابد.
در طول شب، عامل‌ها کارهای ساختاریافته را در مقیاس بزرگ اجرا می‌کنند: غنی‌سازی الزامات، اعتبارسنجی معماری، تولید و آزمایش کد، و بسته‌بندی خروجی‌ها برای بازبینی.
طبق برنامه‌ی زمانی معرفی‌شده در گزارش، شیفت شبانه ۱۶ ساعت طول می‌کشد و توسط یک «کارخانه‌ی ایجنت‌ها» هدایت می‌شود، در حالی‌که شیفت روزانه ۸ ساعت است و انسان‌ها با پشتیبانی عامل‌ها فعالیت می‌کنند.
در شیفت شبانه، عامل‌ها:
- الزامات کسب‌وکار را برای قابلیت‌های درخواستی تولید می‌کنند.
- وضعیت معماری موجود را بررسی و ساختار لازم برای پیاده‌سازی را طراحی می‌کنند.
- نسخه‌ی اولیه‌ی قابلیت‌ها را می‌سازند و می‌آزمایند.
- گزارشی از نتایج آزمون‌ها و توصیه‌ها برای انسان‌ها تهیه می‌کنند.
در شیفت روزانه، انسان‌ها:
- خروجی عامل‌ها را در برابر انتظارات و معیارهای پذیرش بررسی می‌کنند.
- جلسات کار مشترک بر مسیرهای کد حساس و ردیابی هوش مصنوعی برگزار می‌کنند.
- هماهنگی میان‌بخشی (مثلاً با واحدهای حقوقی و انطباق) انجام می‌دهند.
- کدهای ضعیف را بازآرایی و اصلاح می‌کنند.
- ریل‌های ایمنی و استانداردهای کیفیت را برای زمینه، مهارت‌ها، دستورها و گردش‌کارها بازبینی می‌کنند و «کارخانه» را دوباره اجرا می‌کنند.
- ورودی‌ها و دستورالعمل‌های شیفت شبانه‌ی بعدی را تنظیم می‌کنند.
این مدل تنها زمانی کار می‌کند که چهار بنیان عملیاتی فراهم باشد:
نخست، کسب‌وکار باید چشم‌اندازی روشن از آنچه باید ساخته شود در اختیار داشته باشد — برای نمونه یک نقشه‌راه محصول یا یک استاندارد مرجع — تا بتواند الزامات تولیدشده توسط عامل‌ها را از نظر کیفیت و هم‌راستایی با آن چشم‌انداز ارزیابی کند.
دوم، محیط فناوری زیربنایی باید استاندارد و یکدست باشد، برای مثال با استفاده از چارچوب‌های مشترک و معماری‌های ماژولار، تا راهکارها مقیاس‌پذیر باشند و اجزا به‌جای بازآفرینی مکرر، در پروژه‌های مختلف بازاستفاده شوند.
سوم، مسیر از الزامات تا کد از ساختاری استاندارد پیروی کند و عامل‌ها بتوانند ورودی‌ها را به‌درستی تفسیر کرده و خروجی‌های قابل‌پیش‌بینی در پروژه‌های گوناگون تولید کنند.
چهارم، ذی‌نفعان کلیدی باید در طول کل زنجیره‌ی ارزش درگیر و ثابت باقی بمانند تا از ناهم‌راستایی و بازکاری مداوم جلوگیری شود. بدون این سطح از انسجام و شفافیت، خروجی عامل‌ها پراکنده و غیرقابل‌اعتماد خواهد بود.
نتیجه‌ی کلیدی: تحویل ۲۴ساعته دست‌یافتنی است، اما تنها با انضباط معماری و گردش‌کارهای استانداردشده‌ای که به عامل‌ها امکان می‌دهد در مقیاس بزرگ و به‌شکل قابل‌اتکا عمل کنند.
گسترش خودکارسازی برای حذف واسطه‌های انسانی میان مراحل
خودکارسازی سنتیِ یکپارچه‌سازی و تحویل پیوسته (CI/CD) عمدتاً بر آزمایش و استقرار متمرکز بوده است. هرچند هزینه‌های این حوزه متغیر است، تجربه‌ی نویسندگان گزارش نشان می‌دهد این هزینه‌ها می‌تواند تا ۳۰ درصد از کل هزینه‌ی فناوری را در بر بگیرد. بخش عمده‌ی تلاش‌ها، که در بازه‌ی میان تدوین الزامات تا کدنویسی متمرکز شده، همچنان دستی و وابسته به تفسیر انسانی باقی می‌ماند؛ همین‌جاست که اصطکاک انباشته می‌شود و ارزش‌آفرینی به سقف خود می‌رسد.
در بیشتر سازمان‌ها، الزامات، استانداردها، مشخصات معماری و داستان‌های کاربری در قالب اسناد و ابزارهای پراکنده و ناهماهنگ نگهداری می‌شوند. هر انتقال میان این اسناد، ابهامی تازه به وجود می‌آورد؛ انسان‌ها بارها مجبورند نیت اصلی را از یک محصول کاری به محصول دیگر ترجمه کنند.
مدل عامل‌محور این اصطکاک را با ساختاردهی محصولات کاری برای انتقال مستقیم ماشین‌به‌ماشین از میان برمی‌دارد. توصیف‌های عملکردی، الزامات غیرعملکردی، ریل‌های ایمنی، نمودارهای توالی و مخازن کد، همگی در قالب‌های استاندارد و قابل‌خوانش برای ماشین کدگذاری می‌شوند. بدین ترتیب، کل خط تولید می‌تواند در بازه‌ای چند ساعته و سرتاسری اجرا شود، در حالی‌که دخالت انسان‌ها فقط در نقاط بازبینیِ از پیش تعیین‌شده رخ می‌دهد، نه در نقش واسطه‌های مکرر میان مراحل.
در پایپ‌لاین خودکار توصیف‌شده در گزارش:
- بخش الزامات شامل تولید و غنی‌سازی جریان فرآیند و تدوین الزامات دقیق کسب‌وکار است.
- بخش طراحی شامل ایجاد طراحی سطح بالا (با در نظر گرفتن امنیت، عملیات و استثناها)، طراحی سطح پایین، و اعتبارسنجی طراحی در برابر جریان فرآیند و معماری هدف است.
- بخش کد/آزمون شامل توسعه‌ی سرویس‌های خرد اعتبارسنجی و تبدیل، و تیم آزمون واحد است.
- بخش استقرار با همان زیرساخت سنتی CI/CD انجام می‌شود.
طبق داده‌ای که در گزارش (بر پایه‌ی یک تحلیل صنعتی و بررسی تکمیلی مک‌کینزی) آمده، مراحل الزامات، طراحی، کدنویسی و آزمون در مجموع ۷۰ درصد از هزینه‌ی فناوری را تشکیل می‌دهند، در حالی‌که استقرار تنها ۳۰ درصد باقی‌مانده را در بر می‌گیرد. به همین دلیل است که تمرکز اصلی خودکارسازی عامل‌محور باید روی همین ۷۰ درصد باشد، نه صرفاً روی استقرار که مدت‌هاست خودکار شده است.
نتیجه‌ی کلیدی: مقیاس‌پذیریِ هوش مصنوعی مستلزم به‌کارگیری اصول مهندسی در سامانه‌ی توسعه است؛ به‌گونه‌ای که فرآیند تکرارپذیر شود و انتقال‌های میان مراحل به‌طور کامل خودکار گردند.
ایجاد زیرساخت دانش برای رهاسازی استقلال عامل‌ها
برای تولید نتایج دقیق، «agent factory» به زمینه (context) و حافظه‌ی سازمانی نیاز دارند. شرکت‌های پیشرو در حال ساخت گراف‌های دانش هستند که در سراسر چرخه‌ی عمر توسعه‌ی نرم‌افزار (SDLC)، به‌عنوان یک لایه‌ی حافظه‌ی هوش مصنوعی برای هر حوزه عمل می‌کنند. این گراف‌ها عناصری را که عامل‌ها برای درک آن‌ها نیاز دارند به هم متصل می‌کنند؛ از جمله بازخورد مشتریان، تصمیمات معماری، اسناد طراحی، تیکت‌ها، فعالیت‌های گیت‌هاب، گزارش‌های حوادث و قواعد انطباقیِ خلاصه‌شده. نتیجه، سامانه‌ای است که از نظر معنایی به هم پیوسته است؛ یعنی راهی برای آنکه عامل‌ها بفهمند داده‌ها چه معنایی دارند تا بتوانند وظایف خود را بهتر انجام دهند.
تأثیر این رویکرد بنیادین است. پرسش‌هایی که پیش‌تر نیازمند هفته‌ها مصاحبه با چندین کارشناس حوزه (SME) بود، اکنون در عرض چند دقیقه توسط یک «librarian agent» و با استناد به حافظه‌ی سازمانیِ ساختاریافته پاسخ داده می‌شود. هر تصمیمی قابل‌ردیابی می‌شود؛ اگر ذی‌نفعی بپرسد چرا قابلیتی از اولویت خارج شده، پاسخ را می‌توان مستقیماً به منبع آن، مانند داده‌های نظرسنجی مشتریان یا تحلیل‌های استفاده، پیوند داد. به این ترتیب، دانش ضمنی و پراکنده به دانشی صریح و قابل‌توضیح تبدیل می‌شود که هم زمان آماده‌سازی اعضای جدید تیم را کاهش می‌دهد و هم حاکمیت سازمانی را تقویت می‌کند.
نکته‌ی مهم این است که این کار نباید با یک تلاش کلانِ آنتولوژیک — یعنی طراحیِ از پیش و از بالا به پایینِ کل نقشه‌ی مفهومی دانش سازمان — آغاز شود. به جای آن، گراف دانش باید به‌صورت ارگانیک حول حوزه‌های اولویت‌دار و برنامه‌های فعال رشد کند و به‌مرور ارزش انباشته کند. با گسترش این گراف، دانش به زیرساخت تولید تبدیل می‌شود، نه صرفاً مستندسازی ایستا، و به منبعی پایدار برای مزیت رقابتی بدل می‌گردد.
نتیجه‌ی کلیدی: دانش ساختاریافته و به‌هم‌پیوسته، بنیان استقلال عامل‌هاست. معماری دانش را باید به‌عنوان زیرساخت راهبردی در نظر گرفت.
ثبت ارزش: کوچک‌سازی تیم‌ها و بازطراحی سبد پروژه‌ها
چرخه‌ی عمر عامل‌محور می‌تواند به‌طور چشمگیری بهره‌وری را افزایش دهد، چراکه تیم‌های کوچک‌تر اکنون می‌توانند حجم کار بیشتری انجام دهند. پیاده‌سازی‌های اولیه نشان می‌دهد تیم‌های بزرگ‌تر با ۸ تا ۱۲ نیروی تمام‌وقت (FTE) می‌توانند جای خود را به گروه‌های کوچک‌تری از متخصصان بسیار ماهر بدهند که بر اجرای مبتنی بر عامل نظارت می‌کنند. نتیجه، کوتاه‌شدن زمان‌بندی پروژه‌ها و کاهش هزینه یا افزایش ظرفیت است.
طبق داده‌های ارائه‌شده در گزارش، مدل کنونی تحویل نرم‌افزار به‌طور میانگین به حدود ۱۰۰ نیروی تمام‌وقت در قالب ۱۰ تیم ۸ تا ۱۲نفره و ۲۰۰ نفر-سال (معادل ۲۴ ماه) نیاز دارد. در مقابل، چرخه‌ی عمر عامل‌محور همین حجم کار را با حدود ۶۰ نیروی تمام‌وقت، در قالب ۱۶ تیم ۳ تا ۴نفره و در حدود ۱۰۰ نفر-سال (معادل ۱۸ ماه) انجام می‌دهد؛ یعنی کاهشی نزدیک به ۵۰ درصد در کل تلاش (بر حسب نفر-سال) و کاهشی نزدیک به ۶۰ درصد در میانگین اندازه‌ی تیم.
ترکیب تیم نیز تغییر می‌کند. در مدل فعلی، هر تیم معمولاً از مالک محصول، تحلیل‌گر کسب‌وکار، رهبر فنی، چند مهندس نرم‌افزار و آزمون‌کننده تشکیل شده است. در مدل عامل‌محور، نقش مالک محصول و رهبر فنی باقی می‌ماند، اما تحلیل‌گر کسب‌وکار و آزمون‌کننده حذف می‌شوند و جای چند مهندس نرم‌افزار را یک «مهندس مجهز به هوش مصنوعی» می‌گیرد که مسئولیت هدایت، بازبینی و نظارت بر خروجی عامل‌ها را برعهده دارد.
برای ثبت این ارزش، سازمان‌ها باید بر سه اولویت تمرکز کنند:
نخست، بازآموزی نیروی انسانی. در حالی‌که یک تیم مرکزی باید مهارت توسعه و نگهداری «agent factory» را داشته باشد (با تضمین استانداردسازی، انطباق و بهترین شیوه‌ها)، مهندسان نرم‌افزار در سراسر سازمان باید مهارت‌های قضاوت، بازبینی کد و نظارت را برای مدیریت عامل‌هایی که با آن‌ها کار می‌کنند توسعه دهند. نقش‌ها از هماهنگی و آزمون دستی به سمت انسجام معماری، مدل‌سازی حوزه‌ای و نظارت بر هوش مصنوعی تغییر می‌کند.
دوم، اطمینان از اینکه نقش‌های «حلقه‌ی بیرونی» — یعنی افراد پشتیبانی و انطباق در حوزه‌های ریسک، حقوقی، آزمون و تدارکات — بخشی از تلاش توسعه‌ی عامل‌محور باشند. چرخه‌ی عمر سریع‌تر بدون این هماهنگی، به پیشرفت سریع‌تر منجر نمی‌شود. عامل‌ها و خودکارسازی (برای نمونه از طریق «سیاست به‌مثابه‌ی کد») می‌توانند کمک کنند که این کنترل‌ها به گلوگاه تبدیل نشوند و در عوض کیفیت، سازگاری، کامل‌بودن و قابلیت ردیابی را بهبود بخشند. این کنترل‌ها باید از ابتدا در طراحی گنجانده شوند، نه اینکه در پایان فرآیند به‌عنوان یک دروازه‌بان عمل کنند.
سوم، بازطراحیِ نحوه‌ی تخصیص ظرفیت، به‌گونه‌ای که بهبودهای بهره‌وری به ارزش تازه تبدیل شوند. ظرفیت آزادشده اغلب برای شتاب‌بخشیدن به نقشه‌راه‌ها، نوسازی پلتفرم‌ها یا راه‌اندازی محصولات جدید بازسرمایه‌گذاری می‌شود.
نتیجه‌ی کلیدی: دستاوردهای بهره‌وری را می‌توان به تغییرات ساختاریِ سبد پروژه‌ها تبدیل کرد. اندازه‌ی تیم‌ها را تغییر دهید و ظرفیت را آگاهانه بازتخصیص دهید تا ارزش کامل آن به دست آید.
از کجا باید آغاز کرد
تحول باید از جایی آغاز شود که بیشترین تأثیر را دارد. در بیشتر سازمان‌های فناوری، تعداد محدودی از برنامه‌های بزرگ، بخش عمده‌ی کل هزینه را تشکیل می‌دهند. هدف‌گیریِ این ابتکارها — چه تلاش‌های نوسازی سامانه‌های قدیمی، چه بازسازیِ سامانه‌های موجود بر بستری جدید (brownfield)، و چه راه‌اندازی محصولات کاملاً جدید — تأثیر مشهود را به حداکثر می‌رساند و یادگیری را تسریع می‌کند.
همان‌طور که عامل‌ها اجرا را در مقیاس بزرگ به عهده می‌گیرند و کدی مستحکم و به‌طور مداوم امن تولید می‌کنند، نقش انسان‌ها در معماری، قضاوت محصول و طراحی سامانه متمرکز خواهد شد؛ به‌گونه‌ای که دانش نهادی و انسجام فنی به عوامل تمایزدهنده‌ی تعیین‌کننده بدل می‌شوند. سازمان‌هایی که ساخت این قابلیت‌ها را به‌عنوان بخشی از تلاشی گسترده‌تر برای بازطراحیِ مدل عملیاتی خود آغاز می‌کنند، تنها سریع‌تر حرکت نخواهند کرد؛ آن‌ها نحوه‌ی ارزش‌آفرینیِ نرم‌افزار را از نو تعریف خواهند کرد.