یووال یرت
(ایالات متحده
عناوین اصلی مقاله
خلاصه چند نکتهای از مقاله
۱. مشکل اصلی
- هوش مصنوعی سرعت کدنویسی را افزایش داده، اما سرعت بازبینی (Code Review) همان باقی مانده است
- نتیجه: صفهای طولانی Pull Request، تأییدیههای سطحی، و بار سنگین روی تعداد معدودی از متخصصان که سیستم را عمیقاً میشناسند
- این نشانه شکست AI نیست، بلکه نشانه جابهجایی گلوگاه است
۲. راهحل کلیدی: نظریه محدودیتها (TOC)
۵ مرحله تمرکز:
مرحله اقدام عملی ۱. شناسایی با معیارهای جریان (WIP، زمان چرخه، نمودار جریان تجمعی) تشخیص دهید که آیا واقعاً بازبینی گلوگاه است یا مرحلهای دیگر ۲. استفاده بهینه بسته بازبینی کامل تهیه کنید (هدف، اسپک، ریسکها، شواهد تست، مسیر پیشنهادی بازبینی)؛ از AI برای پیشبازبینی استفاده کنید؛ تغییرات را کوچکتر کنید ۳. تبعیت کردن وقتی صف بازبینی پر شد، شروع کارهای جدید را متوقف کنید؛ نیروی انسانی و AI را به سمت پایاندهی و بازبینی هدایت کنید ۴. ارتقا دادن اگر بعد از مراحل قبل همچنان گلوگاه است، ظرفیت بازبینی را اضافه کنید (آموزش، جفتبرنامهنویسی، مرزهای مالکیت واضحتر) – فقط اگر باعث افزایش توان عملیاتی کسبوکار شود ۵. تکرار بعد از بهبود بازبینی، گلوگاه بعدی (استقرار، اعتبارسنجی، پذیرش مشتری) را شناسایی و دوباره مراحل را تکرار کنید
۳. اشتباهات رایج
- ❌ اندازهگیری سرعت تولید کد توسط AI (چون این بخش قبلاً سریع شده)
- ❌ تمرکز روی چرخهی حیات داستانها در جیرا (که حالا خیلی سریع هستند)
- ❌ اشتباه گرفتن صف PR با جریان ارزش (ممکن است PR سریع شود اما ویژگی هفتهها برای استقرار معطل بماند)
- ❌ توسعه مبتنی بر اسپک (SDD) اگر کنترل نشود، موجودی بیشتری دور گلوگاه ایجاد میکند
۴. اقدامات عملی پیشنهادی
- بسته بازبینی کامل تحویل دهید: هدف، اسپک تأییدشده، نقشه تغییرات، ریسکها، شواهد تست، محدودیتها
- از AI بخواهید پیشبازبینی از جنبههای امنیت، معماری، تست، و سازگاری انجام دهد
- برنامه را قبل از دیف بازبینی کنید – قضاوت انسانی را به ابتدای کار بیاورید، نه پایان
- WIP را محدود کنید – وقتی به حد مجاز رسیدید، شروع متوقف شود
- جریان ویژگی را از ابتدا تا انتها اندازهگیری کنید، نه فقط کدنویسی را
۵. پیام نهایی
هدف، ادغام سریعتر کد AI نیست. هدف، رساندن ویژگیهای درست از ایده به تأثیر تأییدشده، بدون دفن کردن بهترین افراد در صف بازبینی است.
AI گلوگاه را حذف نکرده، بلکه گلوگاه بعدی را واضحتر نشان داده است – و این فرصتی برای بهبود سیستم است، نه یک مشکل شکستخورده.
چگونه تیمها باید گلوگاه بازبینی کد ناشی از توسعه با هوش مصنوعی را برطرف کنند؟
توسعه با کمک هوش مصنوعی، نرخ ورود درخواستهای ادغام (Pull Request) را سریعتر از توان بازبینی بسیاری از تیمها افزایش میدهد. نتیجه قابلپیشبینی است: صفهای بازبینی در حال رشد، دستههای بزرگتر، تأییدیههای کلیشهای (Rubber-stamped approvals)، و بار شناختی بیشتر بر روی تعداد کمی از افرادی متمرکز میشود که سیستم را بهطور عمیق درک میکنند. این نشانهای نیست که توسعه با هوش مصنوعی شکست خورده است. این نشانهای است که محدودیت (Constraint) جابهجا شده است.
پاسخ عملی این است که جریان ویژگیها یا اسپکها (Specs) را از ایده تا اعتبارسنجی مدیریت کنیم، نه فقط سرعت انجام تسکهای کدنویسی را. سپس نظریه محدودیتها (Theory of Constraints) را به کار گیریم: بازبینی را به عنوان محدودیت فعلی شناسایی کنید، هر تغییر را برای بازبینی آسانتر کنید، شروع کارهای جدید را تابع ظرفیت بازبینی کنید، تنها زمانی ظرفیت بازبینی را اضافه کنید که بازبینی بهتر باعث افزایش توان عملیاتی (Throughput) کسبوکار شود، و زمانی که گلوگاه دوباره جابهجا شد، این مراحل را تکرار کنید. توسعه مبتنی بر اسپک (Spec-driven development) زمانی کمک میکند که بسته بازبینی (Review packet) را بهبود بخشد و جهتگیری اشتباه را قبل از وجود کد، شناسایی کند. زمانی که صرفاً کارهای دقیقتری را برای بررسی توسط انسان تولید کند، آسیبزننده است.
کدنویسی سریعتر، سوال را تغییر میدهد
اخیراً یکی از بنیانگذاران سوال مفیدی را در یک بحث در مورد توسعه مبتنی بر اسپک در ردیت مطرح کرد. توسعه با کمک هوش مصنوعی میتواند به افراد کمک کند تا سریعتر حرکت کنند، اما چه کسی اطمینان حاصل میکند که آن تغییرات با محصول سازگار است، از ایجاد مشکلات در جای دیگر جلوگیری میکند، بازبینی معناداری را دریافت میکند و انتشار آن ایمن است؟
این کار اغلب بر عهده همان چند نفر میافتد: بنیانگذار، مدیر فناوری اطلاعات (CTO)، مهندس ارشد، معمار، متخصص امنیت، یا هر کسی که به خاطر میآورد چرا یک بخش عجیب از سیستم وجود دارد. هوش مصنوعی میتواند ظرفیت کدنویسی را بدون افزایش توجه، زمینه یا قضاوت موجود از سوی آن افراد، افزایش دهد. تیم میتواند ده برابر کد بیشتری تولید کند. نمیتواند ده برابر بازبینی قابلاعتماد از شخصی که شش سال را صرف یادگیری نقاط آسیبپذیر سیستم کرده است، تولید کند.
من این نگرانی را در گفتگو با سازمانهای مهندسی در مقیاس بزرگ و افرادی که در اکوسیستم تحویل/استقرار پیوسته (CI/CD) کار میکنند، میشنوم. من همچنین این الگو را هنگام بررسی مخازن داخلی و عمومی میبینم: تغییرات بیشتر با کمک عاملها (Agent-assisted changes) میتواند یک گلوگاه واقعی در بازبینی درخواستهای ادغام (PR) ایجاد کند.
یک تیم با این روش پاسخ میدهد که هر تغییری را تا حد امکان برای بازبینی آسان میکند. آنها در حال ساخت چیزی هستند که من آن را بسته بازبینی “کامل” مینامم. بازبین نباید هدف را بازسازی کند، اسپک مربوطه را جستجو کند، حدس بزند چه چیزی تغییر کرده است، ریسک را تشخیص دهد، کشف کند که چگونه تست شده است، و سپس تصمیم بگیرد که چه چیزی شایسته توجه دقیق است. تغییر با همان زمینهای که از قبل جمعآوری شده است، ارائه میشود.
این یک حرکت هوشمندانه است. اما این تنها یک حرکت درون یک مسئله بزرگتر مدیریت محدودیت است.
جریان ویژگیها را اندازهگیری کنید، نه سرعت کدنویسی را
اولین اشتباه، اندازهگیری بخشی است که هوش مصنوعی قبلاً آن را سریع کرده است. اگر زمان “شروع عامل” تا “تولید کد” را ردیابی کنید، ثابت خواهید کرد که هوش مصنوعی به سرعت کد تولید میکند. این اطلاعات بسیار کمی در مورد اینکه آیا محصول سریعتر در حال حرکت است یا ایمنتر میشود، به شما میدهد.
من ترجیح میدهم جریان ویژگیها یا اسپکها را مدیریت کنم. این ارتفاع مفیدی برای دیدن این است که آیا سرعت جدید مهندسی تحویل را بهبود میبخشد یا صرفاً صف دیگری را تغذیه میکند.
یک جریان کاری سبک ممکن است به این شکل باشد:
- تفکر و ایدهپردازی (Thinking and ideation)
- کشف و کاهش ریسک، در صورت نیاز (Discovery and de-risking, when needed)
- مشخصسازی، ساخت و تست (Specify, build, and test)
- بازبینی (Review)
- استقرار (Deploy)
- اعتبارسنجی و تنظیم (Validate and tweak)
این پاسخ معیارهای من در آن بحث بود، که برای خوانایی کمی ویرایش شده است:
من پیشنهاد میکنم یک تعریف از جریان کاری داشته باشید که به شما امکان دهد ببینید هر اسپک چه مقدار زمان را در هر بخش اصلی فرآیند میگذراند: تفکر و ایدهپردازی؛ کشف و کاهش ریسک در صورت نیاز؛ مشخصسازی، ساخت و تست، احتمالاً به عنوان یک مسیر؛ بازبینی؛ استقرار؛ و اعتبارسنجی یا تنظیم.
این بزرگترین شکافی است که هنگام بررسی اکثر مخازن، یا حتی جیرا و لینیر میبینم. مردم بر چرخه حیات داستانها (Stories) تمرکز میکنند، که اکنون آنقدر سریع حرکت میکنند که ردیابی آنها جالب نیست. آنها بر جریان ویژگیها از ابتدا تا انتها تمرکز نمیکنند.
زمان چرخه (Cycle time) یا زمان جریان (Flow time) را از ابتدا تا انتها اندازهگیری کنید، نه فقط برای مشخصسازی و ساخت. به دنبال ناهنجاریها باشید. به نمودار جریان تجمعی (Cumulative flow diagram) نگاه کنید تا زمانهای چرخه داخلی در بخشهای مختلف، بار کلی و کار در حال انجام (WIP)، و گلوگاههای در حال ظهور در بخشهای خاص را درک کنید.
یک نمای کانبان توسعه مبتنی بر اسپک (SDD Kanban view) این جریان را قابل مشاهده میسازد. به جای اینکه درخواست ادغام (Pull request) را به عنوان واحد اصلی کار در نظر بگیرید، هر ویژگی یا اسپک در حال تحول را روی تخته قرار دهید و آن را از قصد تا اعتبارسنجی دنبال کنید. نشان دهید که اسپک در حال ظهور است، عاملها در حال ساخت هستند، به تصمیمات یا بازبینی انسانی نیاز است، استقرار در انتظار است، و اعتبارسنجی حلقه را نبسته است. من این دیدگاه را با جزئیات بیشتر در مقاله “آیا توسعه مبتنی بر اسپک گامی به جلو یا عقب برای توسعه محصول است؟” توضیح میدهم.
یک تخته کانبان SDD و نمای جریان تجمعی که نشان میدهد کار ویژگی و اسپک قبل از بازبینی کد انباشته میشود.
برچسبهای دقیق کمتر از مرزها اهمیت دارند. شما میخواهید ببینید که یک تغییر معنادار چه مقدار زمان را در هر بخش اصلی میگذراند، چه مقدار کار فعال است، و کار در کجا انباشته میشود. اکثر تحلیلهای مخزن بر روی کامیتها، شاخهها، درخواستهای ادغام و موارد (Issues) متمرکز هستند. اکثر تنظیمات جیرا یا لینیر بر چرخه حیات داستانها متمرکز هستند. این دیدگاهها میتوانند سفر سرتاسری ویژگی را از دست بدهند، به ویژه زمانی که هوش مصنوعی داستانها و تسکهای کدنویسی را آنقدر سریع میکند که جالب نباشند.
تخته یک نمای عملیاتی مشترک به تیم میدهد. WIP نشان میدهد کدام مرحله موجودی انباشته میکند. سن آیتم کار نشان میدهد کدام ویژگی یا اسپک از حرکت بازمانده است، حتی اگر عاملها هنوز در حال تولید مصنوعات (Artifacts) در اطراف آن باشند. نشانگرهای مسدود شده (Blocked markers) تصمیمات از دست رفته، وابستگیهای متخصص، یا محیطهای در دسترس نبودن را نشان میدهند. یک نمودار جریان تجمعی نشان میدهد که آیا باند بازبینی در طول زمان در حال گسترش است یا خیر. این سیگنالها با هم به تشخیص یک صف پرسروصدا از محدودیتی که واقعاً جریان سرتاسری را محدود میکند، کمک میکنند.
زمان چرخه (cycle time) را در کل جریان اندازهگیری کنید، نه فقط مشخصسازی-ساخت-تست را. اگر پیادهسازیهای تکمیل شده سریعتر از تغییرات بازبینی شده، مستقر شده یا اعتبارسنجی شده انباشته میشوند، نمای کانبان SDD به شما میگوید کجا را بررسی کنید. سپس از مراحل خروجی و اعتبارسنجی برای تأیید اینکه آیا پاک کردن آن صف، توان عملیاتی کسبوکار را بهبود میبخشد یا صرفاً موجودی بیشتری را به پاییندست منتقل میکند، استفاده کنید.
سیگنالهای سطح درخواست ادغام (PR-level signals) هنوز مفید هستند. اندازه صف بازبینی، زمان تا اولین بازبینی معنادار، سن PR، اندازه دسته (Batch size)، بازکاری (Rework) پس از بازبینی، و تمرکز بر روی چند بازبین میتوانند به توضیح گلوگاه کمک کنند. اما صف را با جریان ارزش (Value stream) اشتباه نگیرید. یک تیم میتواند PRها را سریعتر جابجا کند در حالی که ویژگیها همچنان منتظر استقرار، پذیرش یا شواهد هستند.
این معیارها به طور مستقیم به پنج مرحله تمرکز (Five focusing steps) مرتبط میشوند:
- شناسایی (Identify): زمان چرخه سرتاسری، WIP، سن آیتم کار، زمان در سطح مرحله، و نمودار جریان تجمعی نشان میدهند که کار در کجا انباشته میشود و کدام مرحله توان عملیاتی ویژگی را محدود میکند.
- استفاده بهینه (Exploit): زمان بازبینی، اندازه دسته، بازکاری، و زمان تا اولین بازخورد معنادار نشان میدهند که آیا بستههای بازبینی، تغییرات کوچکتر، و پیشبازبینی عامل (Agent pre-review) توجه محدود بازبین را مؤثرتر میکند.
- تبعیت کردن (Subordinate): WIP قبل از بازبینی، نرخ ورود در مقابل نرخ خروج، و سن اسپکهای در انتظار به تیم میگویند که چه زمانی شروع به کار را متوقف کرده و ظرفیت را به سمت پایاندهی هدایت کند.
- ارتقا دادن (Elevate): توان عملیاتی سرتاسری و زمان چرخه پاییندست نشان میدهد که آیا افزودن ظرفیت بازبینی، ارزش تأییدشده بیشتری تولید میکند یا صرفاً صف را به استقرار یا پذیرش منتقل میکند.
- تکرار (Repeat): همان نمای کانبان و جریان تجمعی نشان میدهد که انباشتگی بعد از بهبود بازبینی در کجا ظاهر میشود.
پنج مرحله تمرکز را برای بازبینی کد اعمال کنید
نظریه محدودیتها (Theory of Constraints) به تیمها یک راه عملی برای پاسخدهی میدهد بدون اینکه این موضوع را به یک برنامه ابزار هوش مصنوعی دیگر تبدیل کند. پنج مرحله تمرکز عبارتند از: شناسایی، استفاده بهینه، تبعیت کردن، ارتقا دادن و تکرار. در اینجا نحوه اعمال آنها زمانی که بازبینی انسانی کد به محدودیت تبدیل میشود، آورده شده است.
نمودار پنج مرحله تمرکز نظریه محدودیتها اعمال شده بر گلوگاه بازبینی در توسعه با هوش مصنوعی.
۱. محدودیت واقعی را شناسایی کنید
با جریان شروع کنید، نه با نظرات. آیا بازبینی کد واقعاً تغییرات تکمیل شده و با ارزش را محدود میکند؟ یا صرفاً بلندترین شکایت است؟
محدودیت واقعی را با استفاده از WIP سرتاسری، سن، زمان چرخه و جریان تجمعی به جای سرعت محلی کدنویسی شناسایی کنید.
از نمای کانبان SDD برای جستجوی کار انباشته شده قبل از بازبینی، ویژگیها و اسپکهای کهنه شده، PRهای در انتظار بر روی همان متخصصان، یا میانبرهای بازبینی که بعداً به صورت بازکاری و ریسک تولید ظاهر میشوند، استفاده کنید. نرخ ورود را با نرخ خروج مقایسه کنید. اگر عاملها و توسعهدهندگان تغییرات را سریعتر از توان بازبینها برای درک و پاکسازی آنها باز میکنند، بازبینی یک محدودیت محتمل است.
سپس زوم به بیرون کنید. اگر کد بازبینی شده سه هفته دیگر برای استقرار منتظر بماند، بازبینی ممکن است محدودیت سیستم نباشد. اگر ویژگیهای منتشر شده بلااستفاده بمانند، پذیرش ممکن است محدودیت باشد. اگر تیم ایدههای ضعیفتأیید شدهای را میسازد، قضاوت محصول ممکن است محدودیت باشد، حتی اگر درد ابتدا در صف PR ظاهر شود.
به همین دلیل است که جریان در سطح ویژگی اهمیت دارد. محدودیت، بخشی است که توان عملیاتی سرتاسری را محدود میکند، نه لزوماً شلوغترین مرحله.
۲. از محدودیت بازبینی استفاده بهینه کنید
“استفاده بهینه” زمانی که محدودیت یک شخص است، خشن به نظر میرسد. هدف این نیست که بازبینی بیشتری از کسی بگیریم. هدف این است که از توجه محدود بازبین به بهترین شکل ممکن استفاده کنیم.
با دستور به عاملهای کدنویسی خود مبنی بر اینکه قابلیت بازبینی انسانی یک محدودیت طراحی است، از محدودیت بازبینی استفاده بهینه کنید. تا زمانی که درخواست ادغام وجود دارد صبر نکنید. از عامل بخواهید کل تغییر را برای بازبینی که زمان محدودی دارد و در پیادهسازی شرکت نداشته است، بهینه کند.
یک بسته بازبینی مفید ممکن است شامل موارد زیر باشد:
- هدف و دلیل کاربری یا تجاری تغییر
- اسپک یا سند تصمیم تأیید شده
- یک نقشه کوتاه از آنچه تغییر کرده و آنچه عمداً تغییر نکرده است
- پرریسکترین بخشها و مفروضات
- شواهد تست و سناریوهای مهم
- اسکرینشاتها، ردپاها (Traces) یا رفتار قبل و بعد در صورت مفید بودن
- محدودیتهای شناخته شده و کارهای بعدی
- یک مسیر پیشنهادی برای بازبینی از میان فایلها
اینجا جایی است که توسعه مبتنی بر اسپک میتواند ارزش خود را نشان دهد. اسپک بخشی از رابط بازبینی میشود. چیزی مفیدتر از یک دیف (Diff) به بازبین میدهد: هدف، محدودیتها، معیارهای پذیرش (Acceptance criteria)، و تصمیماتی که کد قرار است بیان کند.
عاملها همچنین میتوانند یک پیشبازبینی از چندین دیدگاه انجام دهند: صحت، امنیت، معماری، تستها، کد تکراری (Duplication)، سازگاری با عقب (Backwards compatibility)، و هماهنگی با اسپک. آنها میتوانند تغییرات تولید شده یا مکانیکی را خلاصه کرده و بخشهایی را که نیاز به قضاوت انسانی دارند، علامتگذاری کنند. هدف جایگزینی بازبین مسئول با مدل دیگری نیست. هدف این است که از صرف توجه محدود انسانی بر روی کاری که یک ماشین به اندازه کافی خوب میتواند قبل از شروع بازبینی انجام دهد، جلوگیری کنیم.
دستههای کوچک نیز مهم هستند. یک درخواست ادغام ۴۰۰۰ خطی با مستندات زیبا، هنوز یک درخواست ادغام ۴۰۰۰ خطی است. قابلیت بازبینی توسط معماری، تقسیمبندی (Slicing)، نامگذاری، طراحی تست، و دنباله تغییرات شکل میگیرد، نه تنها با کیفیت خلاصه.
۳. همه چیز را تابع بازبینی کنید
این مرحلهای است که اکثر تیمها از آن صرفنظر میکنند.
شروعهای جدید را با محدود کردن WIP و تغییر جهت افراد و عاملها به سمت پایاندهی، تابع محدودیت بازبینی کنید.
هنگامی که بازبینی محدودیت شد، بقیه سیستم باید به گونهای عمل کند که به بازبینی در تولید ارزش تکمیل شده بیشتر کمک کند. این ممکن است به این معنی باشد که عاملها از توکنهای بیشتری برای ایجاد تستهای بهتر، توضیحات واضحتر، کامیتهای کوچکتر و بستههای بازبینی قویتر استفاده کنند، به جای شروع یک ویژگی دیگر. کارایی محلی هوش مصنوعی بیربط است اگر بار روی مرحله محدود شده را افزایش دهد.
همچنین ممکن است به معنای محدود کردن تعداد اسپکها یا درخواستهای ادغام در انتظار بازبینی باشد. وقتی به آن حد رسیدید، شروع را متوقف کرده و پایاندهی را آغاز کنید. ظرفیت انسانی را از مشخصسازی و ساخت کار جدید به سمت بازبینی، برنامهنویسی جفتی (Pairing)، تست، یا کمک به تقسیم تغییرات پرریسک تغییر دهید. اجازه ندهید هر جفت توسعهدهنده-عامل به تولید ادامه دهد چون مسیر محلی آنها در دسترس است.
تبعیت بیشتر به بالادست نیز میرسد. اطمینان حاصل کنید که تیم روی ویژگیهای صحیح کار میکند و تا حد امکان مفروضات پرریسک را بدون کد تست میکند. هر ویژگی کمارزشی که به بازبینی میرسد، همان توجه محدود یک ویژگی باارزش را مصرف میکند. وقتی بازبینی محدود است، اولویتبندی ضعیف بسیار پرهزینه میشود.
اینجا همچنین جایی است که SDD میتواند اشتباه پیش رود. اگر توسعه مبتنی بر اسپک اسپکهای بیشتر، اجرای موازی عاملهای بیشتر، و شاخههای تکمیل شده بیشتری در انتظار تأیید تولید کند، موجودی اطراف محدودیت را افزایش میدهد. یک جریان کاری خوب SDD باید WIP را کنترل کند، مفروضات را زودتر آشکار کند، و بازبینی را آسانتر کند. نباید به یک کارخانه ویژگی سریعتر با مارکداون زیباتر تبدیل شود.
۴. ظرفیت بازبینی را با دقت ارتقا دهید
پس از اینکه قابلیت بازبینی را بهبود بخشیدید، اندازه دسته را کاهش دادید، بررسیهای خودکار مناسب را انجام دادید، و شروعهای جدید را تابع ظرفیت بازبینی کردید، ممکن است بازبینی همچنان محدودیت باشد. اکنون ارتقای آن را در نظر بگیرید.
از طریق آموزش، برنامهنویسی جفتی، خودکارسازی، مرزهای مالکیت، و جداسازی (Decoupling) زمانی که توان عملیاتی کسبوکار را بهبود میبخشد، ظرفیت بازبینی را ارتقا دهید.
ارتقا ممکن است به معنای افزودن بازبینهای بیشتر، پرورش افراد بیشتری که معماری را درک میکنند، ایجاد مرزهای مالکیت واضحتر، بهبود محیطهای تست، تغییر معماری برای کاهش وابستگی (Coupling)، یا رزرو ظرفیت بازبینی صریح باشد. برنامهنویسی جفتی و توسعه مشارکتی ممکن است نیاز به یک بازبینی جداگانه و دیرهنگام برای کارهای حساس را کاهش دهد، زیرا درک در حین شکلگیری تغییر ایجاد میشود.
اما افزودن ظرفیت بازبینی به طور خودکار یک سرمایهگذاری خوب نیست. بپرسید آیا پاک کردن بازبینیهای بیشتر، توان عملیاتی کسبوکار را افزایش میدهد. اگر محدودیت بعدی استقرار، پذیرش، اعتبارسنجی مشتری، یا تصمیمگیری است، ممکن است به سادگی موجودی بیشتری را به پاییندست منتقل کنید.
محدودیت را زمانی مقیاس کنید که ظرفیت اضافی به نتایج مفیدتر، ایمنتر و تأییدشدهتری تبدیل شود. به خاطر آزاردهنده بودن صف، آن را مقیاس نکنید.
۵. زمانی که گلوگاه جابهجا شد، تکرار کنید
اگر تیم بازبینی را بهبود بخشد، محدودیت جابهجا خواهد شد. این موفقیت است، نه شکست.
هنگامی که گلوگاه از بازبینی کد به استقرار، اعتبارسنجی، پذیرش یا مرحله دیگر منتقل شد، مراحل تمرکز را تکرار کنید.
ممکن است کشف کنید که استقرار اکنون مرحله کند است. یا اینکه سازمان میتواند به سرعت استقرار دهد اما نمیتواند اعتبارسنجی کند که آیا تغییرات مهم بودهاند. شاید کشف محصول نتواند فرصتهای باارزش و بهخوبی شکلگرفته به اندازه کافی فراهم کند. شاید یک مرز معماری به ایجاد وابستگیهای بازبینی بین تیمی ادامه دهد. شاید مشتریان نتوانند سرعت تغییر را جذب کنند.
به جریان برگردید. محدودیت جدید را شناسایی کنید. همان مراحل را دوباره اعمال کنید.
توسعه با هوش مصنوعی به تغییر ظرفیت نسبی بخشهای مختلف سیستم ادامه خواهد داد. یک فرآیند ایستا به سرعت کهنه میشود. قابلیتی که شما نیاز دارید، یک فرآیند بازبینی کد بهینهسازی شده دائمی نیست. این عادت دیدن و مدیریت یک محدودیت در حال حرکت است.
قبل از Diff، برنامه را بازبینی کنید
یک پاسخ در بحث ردیت این نکته را صریحاً بیان کرد: بازبینی برنامه قبل از تولید کد، تنها راه حل این مشکل است زیرا دیف خیلی دیر است. من این را مطلق نمیدانم، اما جهت درستی دارد.
باارزشترین بازبینی اغلب قبل از اینکه Agent هزاران خط قابل قبول تولید کرده باشد، اتفاق میافتد. هدف، مرزها، ریسکها، معیارهای پذیرش، جهت معماری و رویکرد اعتبارسنجی را بازبینی کنید. ایده اشتباه، برش بیش از حد بزرگ، محدودیت از دست رفته، یا وابستگی خطرناک را زمانی که هنوز تغییر آن ارزان است، شناسایی کنید.
این نیازی به مشخصات اولیه عظیم ندارد. اسپک باید به اندازه کافی برای ریسک و برگشتپذیری تصمیم، دقیق باشد. یک تغییر کوچک و قابل برگشت ممکن است به یک هدف کوتاه و چند مثال نیاز داشته باشد. یک مهاجرت حساس ممکن است به یک برنامه دقیق، ناورداهای صریح (Explicit invariants)، تفکر درباره بازگشت به حالت قبل (Rollback)، و دروازههای بازبینی قبل از اجرای پیادهسازی نیاز داشته باشد.
نکته این است که بدون بازگشت به مدل آبشاری (Waterfall)، قضاوت انسانی را زودتر به کار بگیرید. اسپکها باید با یادگیری تیم تکامل یابند. عاملها باید تصمیمات و عدم قطعیت را حین کار آشکار کنند. بازبینی باید در نقاط تصمیمگیری معنادار اتفاق بیفتد، نه فقط پس از اینکه کد “تمام” شد.
یک پرامپت برای امتحان با زمینه خودتان
سعی کنید از هوش مصنوعی خود بپرسید:
چگونه پنج مرحله تمرکز نظریه محدودیتها را برای گلوگاه بازبینی کد ناشی از توسعه با هوش مصنوعی اعمال میکنید؟
سپس زمینه واقعی به آن بدهید. جریان کاری ویژگی، صف بازبینی، WIP، تفکیک زمان چرخه، الگوهای اندازه و سن PR، وابستگیهای متخصص، جریان استقرار، و نحوه اعتبارسنجی ارزش پس از انتشار را شرح دهید. فرآیند SDD فعلی و یک نمونه از بسته بازبینی را نیز شامل کنید.
پاسخ عمومی معقول خواهد بود. پاسخ مفید زمانی شروع میشود که هوش مصنوعی بتواند سیستم واقعی شما را ببیند.
هدف واقعی بازبینی سریعتر نیست
اگر توسعه با هوش مصنوعی بازبینی کد را دردناک کرده است، این درد را به عنوان یک مشکل بهرهوری بازبین درمان نکنید. صف چیزی در مورد سیستم به شما میگوید. کد سریعتر از توان جذب قضاوت مورد اعتماد در حال رسیدن است.
کار را برای بازبینی آسانتر کنید. از اسپکها برای انتقال قصد استفاده کنید. اجازه دهید عاملها آمادهسازی و پیشبازبینی بیشتری انجام دهند. کار در انتظار در محدودیت را محدود کنید. توجه انسانی را از شروعهای جدید به پایاندهی معطوف کنید. تنها زمانی ظرفیت اضافه کنید که جریان نتایج باارزش را بهبود بخشد.
و به اندازهگیری در سطح بالاتر از PR ادامه دهید. هدف این نیست که کد تولید شده توسط هوش مصنوعی را سریعتر ادغام کنید. هدف این است که ویژگیهای مناسب را از ایده به تأثیر تأیید شده، بدون اینکه بهترین افراد خود را در صف بازبینی مدفون کنید، برسانید.
هوش مصنوعی گلوگاه را حذف نکرد. این باعث شد که گلوگاه بعدی راحتتر دیده شود.
یووال یرت به رهبران محصول و فناوری کمک میکند تا از تئاتر چابک به سمت تحویل مبتنی بر شواهد و نتیجهگرا حرکت کنند. او مسیر چابکی دهها سازمان را شکل داده و بر چارچوبهای مورد استفاده در سراسر صنعت تأثیر گذاشته است.
لغات تخصصی متداول با اسکرام و مدیریت چابک (عیناً از متن):
- Pull Request (PR): درخواست ادغام
- Rubber-stamped approvals: تأییدیههای کلیشهای / تأییدیههای سطحی
- Constraint: محدودیت
- Theory of Constraints: نظریه محدودیتها
- Throughput: توان عملیاتی
- Spec-driven development (SDD): توسعه مبتنی بر اسپک / توسعه مبتنی بر مشخصات
- Review packet: بسته بازبینی
- CI/CD ecosystem: اکوسیستم تحویل/استقرار پیوسته
- Agent-assisted changes: تغییرات با کمک عاملها
- Feature flow: جریان ویژگیها
- Cycle time: زمان چرخه
- Flow time: زمان جریان
- Work in Progress (WIP): کار در حال انجام
- Cumulative flow diagram: نمودار جریان تجمعی
- SDD Kanban view: نمای کانبان توسعه مبتنی بر اسپک
- Artifacts: مصنوعات (خروجیهای فرآیند)
- Blocked markers: نشانگرهای مسدود شده
- Batch size: اندازه دسته
- Rework: بازکاری / کار دوباره
- Value stream: جریان ارزش
- Five focusing steps: پنج مرحله تمرکز
- Identify: شناسایی
- Exploit: استفاده بهینه
- Subordinate: تبعیت کردن
- Elevate: ارتقا دادن
- Repeat: تکرار
- Agent pre-review: پیشبازبینی عامل
- Acceptance criteria: معیارهای پذیرش
- Diff: دیف (نمایش تفاوت کد)
- Duplication: کد تکراری
- Backwards compatibility: سازگاری با عقب
- Slicing: تقسیمبندی
- Pairing: برنامهنویسی جفتی
- Decoupling: جداسازی / کاهش وابستگی
- Coupling: وابستگی
- Explicit invariants: ناورداهای صریح
- Rollback: بازگشت به حالت قبل
- Waterfall: مدل آبشاری
- Stories: داستانها (در اسکرام)
- Issues: موارد / موضوعات
- Kanban: کانبان
- Agile: چابک
- Scrum: اسکرام
دیدگاهتان را بنویسید