چی باید بسازم تا مشتری آن را دوست داشته باشد؟ ایده خوب از کجا بیاورم؟ هر فناوری جدیدی که فراگیر می‌…

معرفی رویدادHow to FAIL at AI Transformationدر سه جلسه گذشته، درباره تغییراتی که AI در فرایند توسعه نرم‌افزار، Harness Engineering و معماری نرم‌افزار ایجاد می‌کند صحبت کردیم.در جلسه چهارم، کمی از سطح کد و تیم فاصله می‌گیریم و به تصویر بزرگ‌تری نگاه می‌کنیم: این بار تمرکز ما روی تحول هوش مصنوعی در سازمان‌هاست؛ اینکه چرا بسیاری از پروژه‌های AI با وجود پایلوت‌های امیدوارکننده، به مقیاس و ارزش واقعی نمی‌رسند و انتخاب مسئله، داده، فرایندها، سنجه‌ها، فرهنگ سازمانی و حاکمیت چه نقشی در موفقیت یا شکست آن‌ها دارند.📅 تاریخ: جمعه ۳۰ مرداد🕢 ساعت: ۱۹:۳۰ به‌وقت ایران🎙️ با حضور: اسد صفری و ابراهیم نبیئی، مدیر ارشد فناوری گروه علی‌بابااین رویداد آنلاین و رایگان است.لینک ثبت‌نام:luma.com/ox3xuv0a

جمعه‌ی گذشته در سومین جلسه‌ی 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، مزیت تیم‌ها فقط سرعت تولید کد نیست؛ کیفیتِ بیان مسئله است.

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