معرفی رویدادHow to FAIL at AI Transformationدر سه جلسه گذشته، درباره تغییراتی که AI در فرایند توسعه…

جمعه‌ی گذشته در سومین جلسه‌ی AI-Native Engineering درباره‌ی معماری نرم‌افزار و تأثیر ایجنت‌های هوش مصنوعی بر تصمیم‌های معماری گفت‌وگو کردیم.ویدیوی کامل جلسه را در یوتیوب میتوانید مشاهده کنید:🎥 youtu.be/eJLcg3WrJpo

معرفی رویداد 🚀 AI-Native Engineering and the Future of Software Developmentاین بار تمرکز ما روی معماری نرم افزار است؛ اینکه وقتی ایجنت‌ها شروع به نوشتن، تغییر دادن و بازبینی کد می‌کنند، معماری نرم‌افزار چطور باید تغییر کند یا نقش این معماری در بهینه سازی خروجی چیست؟ 📅 تاریخ: جمعه ۲۶ تیرماه🕢 ساعت: ۱۹:۳۰ به وقت تهران🎙️ با حضور: اسد صفری، هادی احمدی و رضا جان‌محمدیاین رویداد آنلاین و رایگان است.لینک ثبت نام: luma.com/fh7ksh44

ویدیوی جلسه دوم AI-Native Engineering منتشر شد.در این گفت‌وگو درباره‌ی Harness Engineering و نقش آن در ساخت Agent هوش مصنوعی قابل‌اعتماد، قابل‌کنترل و هماهنگ با معماری سیستم صحبت کردیم.🎥 ویدیوی کامل: youtu.be/ZpAPYZE9Uhs

این روزها، در حالی که بسیاری از مردم ما در ایران درگیر ابتدایی‌ترین مسائل زیرساختی هستیم، از قطعی و اختلال طولانی اینترنت گرفته تا تغییر ناخواسته پارادایم از «توسعه و پیشرفت» به «بقا و زنده ماندن»، دنیای نرم‌افزار در دنیا با سرعتی عجیب در حال تغییر است.مسئله فقط این نیست که ابزارهای جدیدی آمده‌اند. تغییر عمیق‌تر از این حرف‌هاست. ما در حال ورود به دوره‌ای هستیم که به آن AI-native Engineering می‌گویند؛ یعنی مهندسی نرم‌افزاری که از ابتدا با حضور ایجنت های هوش مصنوعی طراحی می‌شود، نه این‌که AI فقط یک ابزار کمکی کنار تیم باشد.در این مدل جدید، بخش زیادی از کدنویسی، تست، بازبینی، مستندسازی و حتی طراحی فنی می‌تواند توسط ایجنت‌های هوش مصنوعی انجام شود. بعضی تیم‌ها حتی دارند به سناریوهایی نزدیک می‌شوند که تقریباً تمام تولید کد توسط AI انجام می‌شود و نقش انسان بیشتر به سمت تعریف مسئله، تصمیم‌گیری، قضاوت، کنترل کیفیت و هدایت سیستم حرکت می‌کند.برای صنعت نرم‌افزار ایران، این می‌تواند یکی از بزرگ‌ترین شکاف‌های تاریخی با جریان اصلی دنیا باشد. چون وقتی ما هنوز برای اتصال پایدار، دسترسی به ابزارها، پرداخت بین‌المللی، زیرساخت و حتی تمرکز ذهنی می‌جنگیم، آن طرف دنیا بحث از این است که «اگر AI کد می‌نویسد، پس کار اصلی تیم‌های محصول و مهندسی چه می‌شود؟»یکی از ترندهایی که در همین فضا جدی‌تر شده، مفهومی است به نام Spec-Driven Development یا توسعه مبتنی بر اسپک.اما این یعنی چه؟ و چرا برای جامعه نرم افزار و اجایل مهم است؟ایده‌اش در ظاهر ساده است:به‌جای این‌که سریع برویم سراغ کدنویسی و بعداً تلاش کنیم بفهمیم دقیقاً چه ساخته‌ایم، اول نیت، رفتار مورد انتظار، محدودیت‌ها، سناریوها و معیار پذیرش را روشن می‌کنیم. بعد از آن، AI یا تیم توسعه بر اساس همان اسپک شروع به تولید کد، تست و تسک‌های اجرایی می‌کند.اما این فقط یک اسم جدید برای مستندسازی قدیمی نیست.در روش‌های سنتی، خیلی وقت‌ها داکیومنت نوشته می‌شد، بعد در یک فولدر گم می‌شد، و تیم در عمل با برداشت‌های شخصی جلو می‌رفت. در SDD، اسپک قرار است یک فایل تزئینی نباشد؛ قرار است «منبع اصلی قابل اعتماد» باشد. یعنی همان چیزی که محصول، طراحی، معماری، کد و تست باید مدام به آن برگردند.اهمیت این موضوع با AI بیشتر شده است. چون AI می‌تواند خیلی سریع کد تولید کند، اما اگر مسئله مبهم باشد، خروجی هم فقط سریع‌تر اشتباه خواهد شد. سرعت بدون وضوح، لزوماً چابکی نیست؛ گاهی فقط تولید سریع‌تر ابهام است.برای جامعه چابک این نکته مهمی است. ما سال‌ها درباره user story، acceptance criteria، refinement، alignment و shared understanding صحبت کرده‌ایم. SDD در بهترین حالت ادامه همان گفت‌وگوست، اما در دنیایی که AI هم وارد تیم شده. یعنی دیگر فقط انسان‌ها نیاز به فهم مشترک ندارند؛ ابزارهای AI هم باید از یک کانتکست شفاف و ساختارمند تغذیه شوند.یک مثال ساده:فرض کنید می‌خواهیم قابلیت «لغو سفارش» را بسازیم. در حالت معمول ممکن است یک نفر بگوید: «کاربر باید بتواند سفارش را لغو کند.» اما این کافی نیست. تا چه زمانی؟ قبل از ارسال؟ بعد از پرداخت؟ پول چطور برمی‌گردد؟ اگر سفارش بخشی از یک بسته باشد چه؟ پیامی که به کاربر نشان میدهیم چیست؟ وضعیت سفارش در سیستم‌های دیگر چه می‌شود؟در SDD، این سؤال‌ها باید زودتر روشن شوند. نه برای سنگین‌کردن فرایند، بلکه برای کم‌کردن دوباره‌کاری، سوءتفاهم و خروجی‌های نصفه‌نیمه.البته SDD قرار نیست جای گفت‌وگوی واقعی با کاربر، رویکرد محصولی، طراحی خوب یا مهندسی حرفه‌ای را بگیرد. یک اسپک بد، فقط باعث می‌شود AI با اعتمادبه‌نفس بیشتری چیز اشتباهی بسازد. حتی با اسپک خوب هم باید خروجی بررسی شود، تست شود و با واقعیت کسب‌وکار سنجیده شود.به نظرم نگاه بالغ به SDD این است:نه بازگشت به waterfall است، نه جادوی AI.بلکه تلاشی است برای این‌که در عصر AI، «نیت انسانی» گم نشود.در آینده نزدیک، شاید بخش زیادی یا حتی تمام کد را AI بنویسد. اما این‌که چه چیزی باید ساخته شود، چرا باید ساخته شود، برای چه کسی ارزش دارد، و چه چیزی قابل قبول است، هنوز مسئولیت تیم محصول و تیم توسعه است.پس شاید جمله کلیدی این باشد:در دنیای AI-native، مزیت تیم‌ها فقط سرعت تولید کد نیست؛ کیفیتِ بیان مسئله است.

چی باید بسازم تا مشتری آن را دوست داشته باشد؟ ایده خوب از کجا بیاورم؟ هر فناوری جدیدی که فراگیر می‌شود، امکان‌هایی را پدید می‌آورد که تا پیش از آن، دور از ذهن بودند. به روزی فکر کنید که اینترنت پرسرعت هنوز به خانه‌هایمان نرسیده بود؛ در آن دوران، ایده‌هایی مانند یوتیوب یا نتفلیکس به سختی قابل تصور بودند. اما با فراگیر شدن و ارزان شدن آن، بستری برای خلق ایده‌هایی فراهم شد که جهان را تغییر دادند.امروز، ما در آستانه‌ی یک تحول مشابه ایستاده‌ایم. هوش مصنوعی (Generative AI) دیگر یک مفهوم تخصصی و دور از دسترس نیست؛ ابزاری است که به صورت گسترده در اختیار عموم قرار گرفته است. گفته می‌شود همین امروز بیش از نیمی از محتوای تولید شده در لینکدین، با هوش مصنوعی است. امروز حتی کاربرانی که تخصص بالایی ندارند، با استفاده از این ابزارها به سادگی متن، تصویر، ویدیو و حتی کد تولید می‌کنند.اما بیایید یک قدم به عقب برگردیم و به پیامدهای این ماجرا فکر کنیم.تولید، به شدت ارزان و در دسترس همگان شده است. این یعنی حجم تولیدات دیجیتال به شکلی انفجاری در حال افزایش است. اما آیا در سمت مصرف‌کننده، اشتیاق و توجه کافی برای این حجم از تولیدات وجود دارد؟ واقعیت این است که این فراوانی، بیش از آنکه برای مخاطب جذاب باشد، برای تولیدکننده وسوسه‌انگیز است. این «کالایی شدنِ» تولید، باعث شده محصولات دیجیتال به صورت فله‌ای و بدون توجه به نیاز واقعی کاربر ساخته شوند.به عبارت دیگر، چالش اصلی تغییر کرده است. اگر در گذشته مشکل این بود که «ایده‌ای دارم اما نمی‌دانم چطور آن را بسازم»، امروز مشکل این است که «می‌توانم هر چیزی بسازم، اما نمی‌دانم چه چیزی ارزش ساختن دارد» یا «محصولات زیادی ساخته‌ام، اما کسی از آن‌ها استقبال نمی‌کند».درست همین‌جاست که نقش «مدیریت محصول»، به خصوص با رویکرد «چابک» (Agile)، حیاتی می‌شود. مدیریت محصول چابک، که بر پایه‌ی دریافت بازخورد سریع از کاربر بنا شده، به دو پرسش کلیدی این دوران پاسخ می‌دهد: «چه چیزی بسازیم؟» و مهم‌تر از آن، «چرا؟»این مهارت، امروز بیش از هر زمان دیگری اهمیت دارد. زیرا اگر این مهارت در کنار سرعت بالای تولید با هوش مصنوعی قرار نگیرد، نتیجه‌ای جز تولید انبوه «زباله‌های دیجیتال» نخواهد داشت.اگر این چالش برای شما هم جذاب و مهم است، پیشنهاد می‌کنیم در کارگاه «مدیریت محصول چابک» شرکت کنید. در این دوره، به طور عمیق به این موضوع و راهکارهای مقابله با آن خواهیم پرداخت.

جواب درست به سوال: «کِی این پروژه تمام می‌شود؟»به عنوان یک Agile Delivery Manager یا اسکرام مستر یا مدیر پروژه، شما با یک سؤال همیشگی و کلیدی سر و کار دارید: « این کار یا پروژه کِی تمام می‌شود؟»اولین چیزی که معمولا به ذهن همه ما میرسد این است که: حجم کار باقی مانده در بک لاگ محصول را بر میانگین velocity تقسیم کنیم و یک تاریخ قطعی ارائه می‌دهیم. مثلا: «بر اساس میانگین ۲۰ story point در هر اسپرینت، این پروژه ۱۰۰ پوینتی در ۵ اسپرینت تمام می‌شود.» و درست در همین لحظه، واقعیت از راه می‌رسد. یک برنامه نویس کلیدی بیمار می‌شود. یک باگ غیرمنتظره خودش را نشان می‌دهد. یکی از نیازمندی‌ها پیچیده‌تر از چیزی بود که فکر می‌کردیم. ناگهان، پیش‌بینی «۵ اسپرینتی» ما، بیشتر شبیه یک حدس خوش‌بینانه به نظر می‌رسد تا یک تخمین مبتنی بر داده که حالا باید پاسخگوی آن نیز باشیم.مشکل اینجاست که تخمین تک‌نقطه‌ای (single-point estimate) اکثرا به ما دروغ می‌گویند. این نوع تخمین زدن، مهم‌ترین واقعیت کار ما را نادیده می‌گیرد: تغییرپذیری .اما اگر راه بهتری وجود داشته باشد چه؟ ادامه مطلب در لین لینک