چه چیزی توسعه نرم افزار را محدود می کند؟ چرا تیم‌ها و سازمان‌ها نمی‌توانند برنامه‌ای را که می‌توانند رویای آن را بسازند و از مزایای بهره‌وری روزافزون بهره ببرند؟ البته موانع فنی وجود دارد. فناوری موجود ممکن است نتواند قابلیت های مورد نیاز را ارائه دهد. همانطور که ساخت گیج کننده مراکز داده نشان می دهد، در دسترس بودن چرخه های محاسباتی نیز یک عامل محدود کننده است. همچنین محدودیت های پهنای باند وجود دارد. «سرعت‌ها و کانال‌هایی» که میزان تراکنش و ارتباط را تعیین می‌کنند. با این حال، عوامل محدود کننده واقعی در توسعه نرم افزار مانند بسیاری از رشته های تخصصی دیگر هستند: زمان، هزینه و تخصص.
توسعه نرم افزار زمان می برد، نیاز به تخصص دارد و هزینه دارد. دستمزد برنامه نویسان ماهر ناچیز نیست و حتی زمانی که یک شرکت توانایی پرداخت هزینه برای بهترین برنامه نویسان و معماران نرم افزار را دارد، ابتدا باید آنها را پیدا و استخدام کند، هزینه دیگری. زیرساختی که آنها برای توسعه، آزمایش و ارائه نرم افزار نیاز دارند، از محاسبات ابری گرفته تا ذخیره سازی داده تا انتقال، یکی دیگر از موارد مهم بودجه است.
ذینفعان می‌توانند برنامه‌های جدید را در طول روز تجسم کنند، اما عوامل بازدارنده قدرتمند هستند و تلاش‌های توسعه را کنترل می‌کنند، حتی آن‌هایی که مزایای بالقوه قابل‌توجهی دارند. هر تلاش نرم افزاری تا حدی یک آزمایش است، زیرا مهندسان تلاش می کنند تا سیستمی را ترکیب کنند که با دیدگاه سهامداران مطابقت داشته باشد. حتی در یک چرخه دو هفته‌ای سرعت، پروژه‌های بزرگ می‌توانند ماه‌ها توسعه پیدا کنند، با چندین ایست بازرسی که نیاز به بررسی و پذیرش دارند، که اغلب منجر به کوچه‌های کور و بن‌بست‌های قابل توجهی می‌شود. مرتب سازی ایده های توسعه به طور پیش فرض انجام می شود. کسب‌وکارها نمی‌توانند به‌طور بی‌پایان هر ایده اپلیکیشن جدیدی را که به ذهنشان خطور می‌کند، آزمایش کنند.
چگونه هوش مصنوعی SDLC را تغییر می دهد
یا می توانند؟ آیا ظهور توسعه نرم‌افزاری با قابلیت هوش مصنوعی، اسکریپت را بر روی محدودیت‌های آشنا تغییر می‌دهد و چرخه‌های عمر و رویکردهای توسعه جدید را می‌طلبد؟ وقتی تخصص بین کدنویس‌های انسانی و همکارانشان در هوش مصنوعی به اشتراک گذاشته می‌شود، زمانی که نمونه‌های اولیه را می‌توان به سرعت و ارزان به‌طور انبوه تولید کرد، آیا این کار موانع توسعه اپلیکیشن‌های فراوان را کاهش می‌دهد؟ یا اینکه گلوگاه به سادگی از مجموعه ای از محدودیت ها به دیگری تغییر می کند، محدودیت هایی که نه بر اساس فناوری یا هزینه بلکه بر اساس توجه و قضاوت انسان است؟
یکی از ایده‌های اساسی توسعه نرم‌افزار مدرن، نقش مالک محصول است که به‌طور خاص طراحی شده است تا مسئولیت بیان نیازمندی‌های محصول (به عنوان داستان‌های کاربران در پس‌آلود) و هدایت توسعه مداوم را با پذیرش یا رد ویژگی‌ها و عملکردها در حین تکامل تدریجی آنها داشته باشد. این نقش حیاتی مشکل سازترین فعالیت کل چرخه توسعه را بر عهده می گیرد: ارتباط انتظارات از کاربران نهایی محصول به طراحان و توسعه دهندگان آن. نقش مالک محصول به عنوان کانالی برای انتقال هدف و انتظارات در هر دو جهت، از کاربر تا توسعه‌دهنده و بالعکس، مستلزم تسلط در هر دو حوزه و هر دو واژگان، و همچنین درک نگرانی‌ها و محدودیت‌های هر یک است.
حالا بیایید به نقش مالک محصول در فروشگاه توسعه خیالی خود با هوش مصنوعی نگاه کنیم. محدودیت تجربه کدنویسی کاهش یافته است. همکار کد هوش مصنوعی ما می‌تواند یک نمونه اولیه را از روی مشخصات خام یا درخواست‌ها، بر اساس توضیحات مالک محصول و با هدایت یک کدگذار انسانی طراحی و برنامه‌ریزی کند. برخی از محدودیت‌های هزینه نیز کاهش یافته است زیرا شرکت ترکیب تیم خود را تغییر می‌دهد تا استعدادهای برنامه‌نویسی سطح بالا و مهارت‌های همکاری بیشتر در هوش مصنوعی را شامل شود. با آنلاین شدن نسل بعدی مراکز داده، هزینه های محاسباتی نیز ممکن است به دلیل فشارهای رقابتی کاهش یابد. مدل‌های جدید هوش مصنوعی نیز هزینه‌های استنتاج را کاهش می‌دهند.
به طور خلاصه، تولید چندین نسخه از یک نمونه اولیه کار برای ارزیابی صاحب محصول تقریباً رایگان شده است. وقتی توسعه نمونه‌های اولیه به اندازه‌ای کامل باشد که امکان ارزیابی رایگان و تقریباً آنی باشد، محدودیت‌ها از بین نمی‌روند. مهاجرت می کنند محدودیت محدود کننده اکنون توجه صاحب محصول است، ارزیاب مجاز نرم افزار فراوان تولید شده توسط کارخانه نرم افزاری مجهز به هوش مصنوعی. در توسعه نرم افزار، “مرد در حلقه” متولی اصلی هدف پروژه، ارتباط دهنده و مترجم اصلی و تصمیم گیرنده برای پیشرفت و موفقیت محصول است.
توجه مسئولانه
اصطلاح “انسان در حلقه” به خلاصه ای استاندارد برای درگیر نگه داشتن انسان در فرآیندهای خودکار تبدیل شده است و به یک گردش کار اشاره می کند: هوش مصنوعی یک فرآیند یا دستور را اجرا می کند، یک نتیجه را برمی گرداند و انسانی با دانش دامنه آن را از نظر دقت یا ایمنی بررسی می کند. در بسیاری از موارد، فرد برای اطمینان از انطباق در آنجا حضور دارد و هدف، چرخه ای از بررسی کنترل ها و تعادل ها است.
نقش مالکیت محصول جدیدی که ما متصور هستیم، نقش کنترل و تعادل نیست. این درب تصمیم گیری است که تعیین می کند آیا شرکت از محصول سود می برد یا خیر. پذیرش یا رد یک ویژگی یک قضاوت است، و قضاوت مستلزم ارزیابی فعال است: مقایسه افزایش با چشم انداز محصول، وزن کردن معاوضه هایی که عقب ماندگی ثبت نمی کند، با اختیار و تخصص در این زمینه برای نه گفتن در مواقع ضروری. آن را «ملاحظه مسئولانه» بنامید: اعمال قضاوت تجاری توسط یک ارزیاب با اختیار، اختیار و اطمینان برای پذیرش یا رد محصول ارائه شده.
مسئولیت پذیری هرگز نامحدود نبوده است، حتی در SDLC سنتی. این به ندرت محدودیت الزام آور بود، زیرا هزینه و زمان توسعه، صف مواردی را که نیاز به قضاوت هدفمند دارند، محدود می کرد. یک اسپرینت دو هفته ای یک سرعت قابل پیش بینی را ایجاد کرد تا صاحب محصول بتواند به طور واقع بینانه در مورد هر تصمیم فکر کند.
یک فروشگاه توسعه مجهز به هوش مصنوعی این ریتم را فشرده می کند. اگر نمونه‌های اولیه روزانه یا به صورت دسته‌ای از انواع مختلف به‌طور هم‌زمان وارد شوند، مسئولیت مالک محصول ثابت می‌ماند، اما ظرفیت آنها برای اعمال آن با حجمی که به آن نیاز دارد، نمی‌شود.
چرا فقط سریعتر مرور نمی کنید؟
پاسخ واضح به چرخه ساخت فشرده، چرخه بررسی فشرده است. اگر نمونه های اولیه روزانه وارد می شوند، آهنگ مالک محصول را نیز به یک روز منتقل کنید. به نظر می رسد ریاضی کار می کند: زمان کمتر برای هر ویژگی، ویژگی های بیشتر در هفته، اما بررسی به نسبت کاهش می یابد، بنابراین نسبت قضاوت به امتیاز ثابت می ماند.
اون ریاضی اشتباهه فرض بر این است که کیفیت تصمیم بدون در نظر گرفتن دفعات ارزیابی محصول، ثابت باقی می ماند، اما قضاوت با تکرار بدتر می شود، به گونه ای که زمان بررسی آن را در بر نمی گیرد. صاحب محصول از نظر فنی می تواند به طور نامحدود از طریق بررسی روزانه انجام شود. آنچه ابتدا بدتر می شود، تقویم آنها نیست، بلکه کیفیت قضاوتی است که برای هر تصمیمی استفاده می کنند.
این خستگی تصمیم است و به ندرت خود را نشان می دهد. هیچ کس نمی گوید “من آنقدر خسته هستم که نمی توانم به درستی از این موضوع قدردانی کنم.” آنها فقط سریعتر شروع به بله گفتن می کنند.
ولوم یک حالت شکست دوم مستقل از خستگی ایجاد می کند. هنگامی که نمونه های اولیه به اندازه کافی ارزان هستند که بتوان تعداد زیادی از آنها را تولید کرد، تعداد بیشتری از آنها برای یک مجموعه ثابت توجه رقابت می کنند. یک گزینه صیقلی و آسان برای ارزیابی، توجه را به یک پیشنهاد دشوارتر و سازگارتر جلب می کند، فقط به این دلیل که قضاوت سریعتر است، نه به این دلیل که مهمتر است. فراوانی فقط از ارزیاب مالیات نمی گیرد. می تواند بی سر و صدا چیزی را که به طور جدی ارزش دارد، دوباره تنظیم کند.
محدودیت واقعی کارخانه
تصور یک فروشگاه توسعه مجهز به هوش مصنوعی به عنوان یک کارخانه وسوسه انگیز است: اعلان های خام وارد می شوند، نرم افزار تمام شده منتشر می شود، تنها با محاسبات و تخیل محدود می شود. اما کارخانه توان عملیاتی را بدون گلوگاه فرض می‌کند و این یک گلوگاه ثابت دارد. هر محصولی که توسط کارخانه تولید می شود باید از طریق انسانی بگذرد که تصمیم می گیرد آیا شایسته حضور در محصول است یا خیر. این راه حل را نمی توان به روشی که کد زیر می تواند ساخته، موازی یا شتاب داد.
هر فروشگاه توسعه‌دهنده‌ای که به دنبال سرعت مبتنی بر هوش مصنوعی است، باید سؤال سخت‌تری نسبت به «چقدر سریع می‌توانیم بسازیم» بپرسد. بپرسید چه کسی تصمیم می‌گیرد چه چیزی بسازد، چه تعداد تصمیم از آنها خواسته می‌شود در این هفته بگیرند و آیا کسی هنوز کیفیت آن تصمیم‌ها را بررسی می‌کند یا خیر. کارخانه‌ای که سریعتر از چیزی که قضاوتش می‌تواند تولید کند، سرعتش را افزایش نمی‌دهد. ریسک را به میزان موفقیت خود انباشته می کند.
