بک‌لاگ ریفاینمنت و هوش مصنوعی: چه چیزی واقعاً تغییر می‌کند

بررسی کاربردی اینکه چگونه هوش مصنوعی بک‌لاگ ریفاینمنت را تغییر می‌دهد: چه چیزی سریع‌تر می‌شود، کجا ریسک‌ها ظاهر می‌شوند، زمان تیم چگونه بازتوزیع می‌شود و چه چیزی باید به‌صورت دستی بررسی شود.

26 Mar 2026 · 06:54 UTC24 دقیقه مطالعه

Telegram اصلی

این اولین مقاله از مجموعه‌ای است درباره اینکه چگونه هوش مصنوعی جلسات کلاسیک تیم توسعهٔ میان‌وظیفه‌ای را تغییر می‌دهد. در ادامه با Backlog Refinementشروع می‌کنم و در مطالب بعدی به‌طور جداگانه Planning، Daily، Review، Retrospective را بررسی خواهم کرد و سپس همه را در یک مقالهٔ مروری نهایی جمع‌بندی می‌کنم.

فوراً چارچوب را روشن کنم: در ادامه منظور من از refinement یک جلسهٔ منظم تیمی و رویهٔ شفاف‌سازی آیتم‌های بک‌لاگ است، نه لزوماً یک رویداد رسمی جداگانهٔ اسکرام. این نکته برای دقت اصطلاحات مهم است: در Scrum Guide 2020 (RU PDF) refinement به‌عنوان یک فعالیت مستمر توصیف شده است، نه به‌عنوان یک رویداد مستقل. در نسخهٔ روسی Scrum Guide 2020 این ایده مستقیماً بیان شده است: شفاف‌سازی Product Backlog فعالیتی دائمی برای افزودن جزئیات، ترتیب و اندازه است.

Backlog Refinement یکی از نخستین جاهایی است که هوش مصنوعی شروع به آوردن سود کاملاً ملموس برای تیم می‌کند. این ابزار کمک می‌کند زمینه سریع‌تر جمع‌آوری شود، پیش‌نویس صورت‌بندی مسئله آماده شود، پیش‌نویس معیارهای پذیرش به‌سرعت تولید شود، موارد مشابه پیدا شوند و فهرست پرسش‌های باز تدوین شود. این ادعا در کارهای کاربردی‌تر نیز پشتیبانی می‌شود: برای مثال، در LLM-Assisted Requirements Engineering in Agile MDD تولید معیارهای پذیرش به‌طور جداگانه اعتبارسنجی شد، و در مطالعهٔ موردی صنعتی Acceptance Test Generation with Large Language Models کاربران اشاره کردند که سناریوهای هوش مصنوعی به کشف مواردی کمک می‌کرد که پیش‌تر از قلم افتاده بودند. اما دقیقاً به همین دلیل است که در اینجا افتادن در دام بسیار آسان است: اشتباه گرفتن یک پیش‌نویس خوب‌قالب‌بندی‌شده با یک وظیفهٔ واقعاً روشن.

به نظر من، هوش مصنوعی refinement را به این معنا ساده نمی‌کند که تیم اکنون باید کمتر فکر کند. بلکه گران‌ترین کار دستی پیرامون آن را ارزان‌تر می‌کند — جست‌وجو، خلاصه‌سازی، بسته‌بندی و تجزیهٔ اولیه. و این یعنی ارزش خود بحث تیمی از بین نمی‌رود، بلکه جابه‌جا می‌شود: زمان کمتری صرف ساختن چیزی شبیه به یک وظیفه از دل آشفتگی می‌شود و زمان بیشتری صرف فهمیدن این می‌شود که آیا اصلاً می‌توان آن را به کار گرفت یا نه.

«هوش مصنوعی خودِ توافق تیم را سریع‌تر نمی‌کند، بلکه آماده‌سازی مواد برای آن را سریع‌تر می‌کند»

چرا تغییرات دقیقاً در Backlog Refinement نخست از همه احساس می‌شوند

اگر به آیین‌های معمول تیمی و جلسات در عمل Agile نگاه کنیم، refinement یکی از حساس‌ترین آن‌ها به ظهور هوش مصنوعی است. دلیل نسبتاً ساده است: پیرامون refinement از دیرباز روتین فکری دستی زیادی وجود داشته است. باید زمینهٔ پراکنده از اسناد، تیکت‌های قدیمی، مکالمات و حافظهٔ افراد جمع‌آوری شود. باید یک ایدهٔ خام کسب‌وکار به یک آیتم بک‌لاگ قابل‌فهم تبدیل شود. باید مسئلهٔ کسب‌وکار، سناریو، معیارهای پذیرش، محدودیت‌ها، پرسش‌های باز، وابستگی‌ها و موارد مرزی احتمالی صورت‌بندی شود.

هوش مصنوعی دقیقاً در همین لایه به‌خوبی نفوذ می‌کند. این با نحوهٔ بحث امروز دربارهٔ کاربرد LLM در مهندسی نیازمندی‌ها نیز همخوانی دارد: مدل‌ها در خلاصه‌سازی، ساختاردهی اولیهٔ نیازمندی‌ها، تولید پیش‌نویس و پشتیبانی از آماده‌سازی تحلیلی قوی‌اند، اما در جایی که دقت دامنه‌ای، ردیابی‌پذیری و مسئولیت تصمیم‌های نهایی لازم است ضعیف‌ترند. به این معنا، refinement واقعاً یکی از نخستین فرایندهایی است که در آن سود هوش مصنوعی سریع احساس می‌شود و محدودیت‌های قابلیت اطمینان آن تقریباً بلافاصله آشکار می‌شود. این موضوع در مرور Challenges in applying large language models to requirements engineering tasks، در مرور نظام‌مند تازهٔ Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Reviewو در کار کاربردی‌تر LLM-Assisted Requirements Engineering in Agile MDDبه‌خوبی بیان شده است.

تیم آیتم بک‌لاگ را با کمک هوش مصنوعی و مصنوعات Agile تحلیل می‌کند — هوش مصنوعی آماده‌سازی برای refinement را به‌خوبی سریع می‌کند، اما جای بررسی جمعی معنا را نمی‌گیرد.

refinement پیش از هوش مصنوعی چگونه بود

اگر ساده کنیم، refinement پیش از هوش مصنوعی بسیار اوقات فرایند مونتاژ دستی فهم بود. در بک‌لاگ نه یک وظیفهٔ آماده، بلکه بیشتر یک قصد کسب‌وکار می‌افتاد: بهبود onboarding، افزودن یادآوری‌ها، دادن گزارش جدید به مدیر، کاهش تعداد درخواست‌های معوق. پس از آن، مالک محصول، تحلیلگر یا یکی از لیدها شروع به جمع‌آوری دستی زمینه می‌کرد: درخواست‌های قدیمی مشتریان، قابلیت‌های مشابه، محدودیت‌های معماری فعلی، وضعیت‌های فعال، اعلان‌های موجود، الگوهای UI و هر چیز دیگری که می‌توانست به‌طور ناگهانی در میانهٔ بحث سر برآورد.

سپس همان فرد یا چند نفر به صورت دستی تلاش می‌کردند آنچه جمع‌آوری شده را به اولین پیش‌نویس تبدیل کنند: مسئله کسب‌وکار را فرموله کنند، سناریو را توصیف کنند، معیارهای پذیرش را بنویسند، سؤالات باز را بیرون بکشند و محدودیت‌های احتمالی را مشخص کنند. اما حتی اگر چنین پیش‌نویسی از قبل وجود داشت، جلسه باز هم اغلب صرف بالا آوردن زمینه در ذهن کل تیم می‌شد. مالک محصول دوباره توضیح می‌داد که کسب‌وکار چه می‌خواهد، تحلیلگر می‌گفت چه چیزهایی تاکنون روشن شده، توسعه‌دهندگان محدودیت‌های معماری را مطرح می‌کردند، QA سناریوهای مرزی را بیرون می‌کشید، طراح و فرانت‌اند درباره اینکه آیا صفحه‌ای جداگانه لازم است و اصلاً کجا قرار می‌گیرد بحث می‌کردند.

همان کیس: بدون AI و با AI

برای اینکه در سطح فرمول‌های کلی نمانیم، یک کیس مشخص را در نظر می‌گیرم. محصول — یک پلتفرم LMS B2B برای آموزش سازمانی است. مشتریان بزرگ برای کارمندان دوره‌های اجباری در زمینه compliance، امنیت و مقررات داخلی تعیین می‌کنند. از سمت کسب‌وکار درخواستی می‌آید: باید یادآوری‌های خودکار ایمیلی برای کارمندانی که دوره اجباری را تا مهلت مقرر تکمیل نکرده‌اند اضافه شود.

در نگاه اول این یک وظیفه ساده درباره ارسال ایمیل به نظر می‌رسد. اما از همان گام‌های اول مشخص می‌شود که در واقع اینجا انشعاب‌های زیادی وجود دارد: دقیقاً چه کسی را باید تکمیل‌نکرده در نظر گرفت، چه زمانی یادآوری‌ها ارسال شوند، چگونه ارسال‌ها را از تکرار حذف کرد، چگونه این توسط مشتری تنظیم می‌شود، آیا لاگ ارسال‌ها لازم است، با time zone چه کرد، از کدام زبان ایمیل استفاده کرد و آیا باید کاربران archived و غیرفعال حذف شوند.

در حالت بدون AI، تیم عمدتاً از طریق آماده‌سازی دستی طولانی و گفت‌وگوی حجیم در خود جلسه به این سؤالات می‌رسید. ابتدا مالک محصول زمینه مشتری را مطرح می‌کرد. سپس تحلیلگر دستی در مواد داخلی می‌گشت: درخواست‌های مشابه قدیمی را جستجو می‌کرد، سرویس اعلان‌ها را بررسی می‌کرد، وضعیت‌های فعلی assignmentها، وجود وظایف زمان‌بند، فیلدهای تنظیمات زبان و منطقه زمانی را بررسی می‌کرد. همین‌جا محدودیت‌های واقعی بیرون می‌آمدند: در سیستم قالب‌های ایمیل وجود دارد، اما فقط برای ایمیل‌های تراکنشی؛ منطقه زمانی در سطح مشتری ذخیره می‌شود نه کاربر؛ لاگ ارسال وجود ندارد؛ مدل جداگانه‌ای برای یادآوری‌ها هم در محصول نیست.

پس از آن تحلیلگر به صورت دستی اولین پیش‌نویس مشخصات را جمع‌آوری می‌کرد، اما آن هم نابالغ می‌ماند. مثلاً ممکن بود در آن وضعیت‌های دقیقی که باید بر اساس آن‌ها یادآوری ارسال شود، منطق حذف تکرار، حداقل دامنه کار برای UI، fallback زبان یا مرزهای نسخه اول ثبت نشده باشد. و در خود refinement تیم وظیفه را حین گفت‌وگو تکمیل می‌کرد. دقیقاً همان‌جا روشن می‌شد که یادآوری‌ها فقط برای دوره‌های اجباری لازم است، که وضعیت‌های not_started و in_progress مناسب هستند، اما expired بهتر است در نسخه اول گرفته نشود، که بدون ژورنال ارسال‌ها پشتیبانی و تیم همراهی مشتریان به سرعت در سؤالات غرق می‌شوند، و بدون محافظت جداگانه در اجرای مجدد وظایف زمان‌بند تکرارها رخ می‌دهد.

در حالت با AI، همان کیس متفاوت به نظر می‌رسد. مالک محصول خلاصه‌ای از تیم همراهی مشتریان، آخرین تماس‌های مشتری و درخواست خام اولیه را در AI بارگذاری می‌کند. AI به سرعت دردهای مشتری را گروه‌بندی می‌کند، انتظارات تکراری را برجسته می‌کند و به شکل‌دهی صورت‌بندی مسئله کمک می‌کند. تحلیلگر از AI می‌خواهد همه چیز مرتبط با جریان‌های اعلان، وضعیت‌های تخصیص، وظایف زمان‌بند، تنظیمات زبان، منطقه زمانی و وظایف مشابه در Jira را بیرون بکشد. بک‌اند از قبل توضیح معماری فعلی اعلان‌ها را از AI عبور می‌دهد و می‌خواهد رویکرد فنی پیشنهاد دهد. فرانت‌اند و طراح به سرعت بررسی می‌کنند که منطقی‌تر است تنظیمات و تاریخچه ارسال‌ها کجا جاسازی شوند. QA فهرست اولیه موارد مرزی و ریسک‌های زمانی را بیرون می‌کشد.

اینجا معمولاً یک سؤال طبیعی پیش می‌آید: اگر AI چیزی را از دست داده باشد چه؟ اصلاً چقدر می‌توان به چنین خلاصه کوتاهی اعتماد کرد، خصوصاً وقتی پایگاه منابع بزرگ است؟ پژوهش‌ها و کیس‌های عملی اینجا تصویر نسبتاً واقع‌بینانه‌ای ارائه می‌دهند: LLMها واقعاً می‌توانند تولید داستان‌های کاربر، پیش‌نویس معیارهای پذیرش و مشخصات اولیه را سرعت ببخشند، اما کیفیت نتیجه به شدت به زمینه ورودی، دامنه و بررسی انسانی بعدی بستگی دارد. بنابراین مفید است کارهای کاربردی‌تری مانند AI-Generated User Stories: Are They Good Enough? و LLM-Assisted Requirements Engineering in Agile MDDرا هم در نظر داشت: آن‌ها به خوبی نشان می‌دهند که تولید پیش‌نویس قوی و آمادگی برای توسعه یک چیز نیستند.

بر اساس تجربه‌ی من با Cursor، در سناریوهای کاربردی به‌ندرت شک می‌کنم که مدل بتواند اولین گذر لازم را روی حجم بزرگی از منابع جمع‌آوری کند. چیز مهم‌تر چیز دیگری است: اینکه چقدر خوب مسئله را صورت‌بندی کرده‌ام، چه محدودیت‌هایی گذاشته‌ام، چه پرسش‌های روشن‌کننده‌ای توانسته‌ام اضافه کنم و دقیقاً چگونه بررسی نتیجه را سازماندهی کرده‌ام. وقتی شک دارم، سعی نمی‌کنم آن را با پرسش «به AI اعتماد دارم یا نه» حل کنم — فقط درخواست را دقیق‌تر می‌کنم، می‌خواهم منابع جداگانه نشان داده شوند، نقاط بحث‌برانگیز جدا شوند، واقعیت‌ها و فرض‌ها تفکیک شوند یا پاسخ با چارچوب دیگری بازسازی شود. از این نظر کار با AI بسیار شبیه کوچینگ است: مهارت پرسیدن پرسش‌های دقیق مفید است، پرسش‌هایی که فقط تولید را راه نمی‌اندازند بلکه تفکر مدل را در جهت درست هدایت می‌کنند.

این البته تجربه‌ی شخصی من است، نه یک قاعده‌ی جهانی. ممکن است جداگانه مطلب دیگری دقیقاً درباره‌ی اعتماد به AI، کیفیت پرسش‌های روشن‌کننده و بررسی کنترل‌شده‌ی نتیجه بنویسم. برای refinement این اهمیت ویژه‌ای دارد: هرچه پایگاه منابع بزرگ‌تر و خلاصه‌ی کوتاه قانع‌کننده‌تر باشد، خطر اشتباه گرفتن آماده‌سازی قوی با درکِ از پیش بررسی‌شده بیشتر می‌شود.

«هرچه پایگاه منابع بزرگ‌تر و خلاصه‌ی کوتاه قانع‌کننده‌تر باشد، خطر اشتباه گرفتن آماده‌سازی قوی با درکِ از پیش بررسی‌شده بیشتر می‌شود»

در نتیجه تیم به refinement نه با یک ایده‌ی خام، بلکه با پیش‌نویس نسبتاً قوی می‌آید: پیش‌نویس داستان کاربر، پیش‌نویس معیارهای پذیرش، پرسش‌های باز، فهرست ریسک‌ها، رویکرد فنی مقدماتی و پیشنهاد UI وجود دارد. بنابراین خود جلسه کوتاه‌تر و موضوع‌محورتر می‌شود. تیم دیگر زمان زیادی را صرف بالا آوردن زمینه‌ی پایه نمی‌کند و عمدتاً درباره‌ی نقاط بحث‌برانگیز گفتگو می‌کند: آیا expiredرا شامل شود، آیا منطقه‌ی زمانی جداگانه برای هر کاربر ساخته شود، آیا در اولین انتشار به گزارش ارسال‌ها نیاز است، آیا به تریگرهای ثابت بسنده شود، چگونه از تکرارها محافظت شود و مرزهای نسخه‌ی اول چه باشد.

پیشرفت تیم در چیست؟

وقتی تیم تازه شروع به استفاده از AI می‌کند، عمدتاً به‌عنوان تولیدکننده‌ی سریع اولین پیش‌نویس کار می‌کند. اما با بلوغ، گام منطقی بعدی این است که از کار فقط با مدل عمومی دست بردارد و به‌تدریج آنچه را قبلاً فقط در حافظه‌ی افراد بود به زمینه‌ی کنترل‌شده‌ی تیم منتقل کند. این می‌تواند شامل اصول محصول، الگوهای معیارهای پذیرش، دلایل مکرر رد شدن مسئله در refinement، موارد مرزی معمول، محدودیت‌های معماری، مجموعه‌ای از پرسش‌های روشن‌کننده‌ی استاندارد، مقررات داخلی سازمان، Definition of Ready و Definition of Done در سطح سازمان و تیم، و همچنین نمونه‌های راه‌حل‌های خوب برای موارد مشابه باشد.

آن‌گاه کیفیت اولین پیش‌نویس واقعاً شروع به رشد می‌کند. نه به این دلیل که مدل ناگهان «خودش دامنه را فهمید»، بلکه به این دلیل که تیم یاد گرفته الگوهای تفکر، محدودیت‌های داخلی و قواعد بررسی خود را به‌صورت سیستماتیک در آن تخلیه کند. و اینجا refinement نه‌تنها محل بررسی مسئله، بلکه محلی می‌شود که تیم به‌تدریج لایه‌ی AI خودش را آموزش می‌دهد.

چه چیزی بر حسب نقش‌ها تغییر می‌کند

در ادامه مفید است نه‌تنها به نقش‌ها به‌عنوان کارکردهای انتزاعی، بلکه به اقدامات مشخص در مورد شبیه‌سازی‌شده با یادآوری‌های دوره‌های اجباری نگاه کنید. دقیقاً این‌گونه است که تفاوت بین حالت بدون AI و با AI واقعاً محسوس می‌شود.

نقش	بدون AI	با AI
مالک محصول	زمینه‌ی مشتری را دستی بالا می‌آورد، درخواست‌های تیم پشتیبانی مشتری را جمع می‌کند، مسئله‌ی کسب‌وکار را دوباره در جلسه توضیح می‌دهد.	ورودی بی‌نام آماده می‌کند، از AI می‌خواهد دردهای مشتری را گروه‌بندی کند، پیش‌نویس صورت‌بندی مسئله و فهرست تصمیم‌های محصولی بحث‌برانگیز را به جلسه می‌آورد.
تحلیلگر کسب‌وکار	موارد مشابه را جستجو می‌کند، وضعیت‌ها، محدودیت‌ها، وابستگی‌ها را دستی جمع می‌کند و سپس همه را در اولین پیش‌نویس صورت‌بندی بازنویسی می‌کند.	درخواست به AI را بر اساس منابع سازماندهی می‌کند، خلاصه‌ی کوتاه را با منابع تطبیق می‌دهد، معیارهای پذیرش را ویرایش می‌کند، پرسش‌های باز و آنچه مدل ممکن است از دست داده باشد را ثبت می‌کند.
توسعه‌دهنده‌ی بک‌اند	اغلب برای اولین بار در refinement عمیقاً در مسئله فرو می‌رود، محدودیت‌های سرویس اعلان و ریسک‌های تکرار را در همان حین بحث بالا می‌آورد.	پیش از جلسه اولین گذر روی گزینه‌های فنی را دریافت می‌کند، از پیش حذف تکرار، وظایف زمان‌بند، audit trail و مرزهای نسخه‌ی اول را بررسی می‌کند.
توسعه‌دهنده‌ی فرانت‌اند	در جلسه همراه با طراح سعی می‌کند بفهمد آیا صفحه‌ی جداگانه لازم است، تنظیمات کجا باشند و چه چیزی واقعاً در UI حداقلی قرار می‌گیرد.	پیش از جلسه پیش‌نویس AI از جاسازی UI را می‌بیند، از پیش نقاط بحث‌برانگیز درباره‌ی تنظیمات، حالت‌ها و محدودیت‌های رابط را علامت می‌زند.
مهندس کیفیت / QA	عمدتاً در جلسه وارد می‌شود، سناریوهای منفی، تداخل‌های وضعیت و ریسک‌های زمانی را در همان گفتگوی عمومی بیرون می‌کشد.	پیش از جلسه فهرست شروع موارد مرزی را دریافت می‌کند، بررسی می‌کند که AI تکرارها، مناطق زمانی، سناریوهای fallback زبانی و استثناهای وضعیت کاربران را از دست نداده باشد.
طراح UX/UI	در حین بحث مسئله را می‌فهمد و در جا تخمین می‌زند آیا صفحه‌ی جدید، بلوک تنظیمات یا تاریخچه‌ی ارسال‌ها لازم است.	به‌سرعت چند گزینه از رویکرد UI را همراه با فرانت‌اند تست می‌کند و با پیشنهادی معنادار می‌آید، نه از صفر.
اسکرام مستر	اعضا را جمع می‌کند، زمان‌بندی را حفظ می‌کند، کمک می‌کند در بالا بردن آشفتهٔ زمینه گم نشوند و وقتی بحث پراکنده می‌شود تیم را به اصل موضوع برمی‌گرداند.	زمان کمتری صرف مکانیک سازمانی و هم‌ترازی زمینهٔ پایه می‌کند و بیشتر صرف تسهیل تصمیم‌های بحث‌برانگیز، ثبت پرسش‌های باز و کنترل کیفیت بحث می‌کند.

مزایا، ریسک‌ها و زمان آزادشده

فایدهٔ AI در refinement کاملاً محسوس است. زمینه سریع‌تر جمع می‌شود، پیش‌نویس کار سریع‌تر پدید می‌آید، شروع بحث ساده‌تر است و نتایج بهتر بسته‌بندی می‌شوند. اما دقیقاً در refinement ریسک‌های AI هم خیلی زود بروز می‌کنند. آشکارترین ریسک، وضوح کاذب است. AI می‌تواند آیتم‌های backlog مرتبی بسازد که از نظر بصری و ساختاری خوب به نظر می‌رسند. به همین دلیل تیم راحت‌تر خود را با این حس فریب می‌دهد که کار уже فهمیده شده، در حالی که هنوز شکاف‌های محصولی و فنی در آن باقی است.

اینجا مفید است چیزها را با نام واقعی‌شان صدا کنیم. اول، سوگیری اتوماسیون و وابستگی بیش‌ازحد است — تمایل به پذیرش خیلی مشتاقانهٔ توصیهٔ سیستم و گذار از بررسی فعال به پایش منفعل‌تر. در پروفایل NIST برای هوش مصنوعی مولد این مستقیماً به‌عنوان اعتماد بیش‌ازحد به سیستم‌های AI توصیف شده، و در پژوهش تجربی Automation Bias in AI-Decision Support: Results from an Empirical Study نشان داده شده که سودمندی ادراک‌شدهٔ بالای سیستم می‌تواند موافقت کاذب با خطاهای آن را افزایش دهد، در حالی که کیفیت آموزش کاربران احتمال چنین اثری را کاهش می‌دهد. دوم، توهم مدل است — نتیجه‌ای باورپذیر اما تأییدنشده با منابع. برای refinement این به‌ویژه حیاتی است، چون AI تقریباً همیشه از طریق خلاصه‌سازی اسناد، تیکت‌ها و مکاتبات کار می‌کند، و بنابراین ریسک نه‌تنها در «پیش‌نویس زیبا اما ساختگی معیارهای پذیرش» است، بلکه در تحریف خاموش زمینهٔ اصلی هم هست. دقیقاً به همین دلیل در refinement، AI بیشتر در واقعیت‌های زمینه اشتباه می‌کند تا در سبک متن — و این ریسک به‌خوبی در کار On Faithfulness and Factuality in Abstractive Summarizationتوصیف شده است. پادزهر عملی اینجا نسبتاً ساده است: از مدل بخواهیم واقعیت‌ها را از فرضیه‌ها جدا کند، ارجاع به منابع را الزامی کنیم و خلاصهٔ کوتاه را طوری بسازیم که بتوان سریع آن را به اسناد، تیکت‌ها و تصمیم‌های تیم بازگرداند.

یک لایهٔ ریسک دیگر هم وجود دارد — داده. در مورد بالا AI با درخواست‌های مشتری، توصیف‌های داخلی سیستم و سیگنال‌های کاربر کار می‌کند. بنابراین مهم است که تیم از پیش توافق کند چه چیزی اصلاً می‌تواند به مدل داده شود و چه چیزی نه. برای generative AI ریسک فقط به prompt محدود نمی‌شود: داده‌های شخصی می‌توانند در ورودی، در خروجی و حتی از طریق memorization/regurgitation مدل ظاهر شوند. بنابراین اگر در کار داده‌های شخصی یا زمینهٔ حساس مشتری وجود دارد، اصول پایهٔ بهداشت داده باید الزامی باشند: کمینه‌سازی حجم داده در promptها، بی‌نام‌سازی ورودی در حد امکان، وارد نکردن خروجی خام بدون فیلتر به مدل، درک صریح هدف پردازش و پذیرش نکردن ادعاهای ارائه‌دهنده مانند «ما داده‌های شخصی را پردازش نمی‌کنیم» یا «مدل ناشناس است» بدون کنترل‌های سازمانی و فنی قابل‌راستی‌آزمایی. جداگانه مفید است که از پیش مبنای قانونی پردازش، مجموعهٔ حداقلی لازم از فیلدها، نقش‌ها و مسئولیت‌ها در فرایند، و در جایی که کاربرد دارد، الزامات اطلاع‌رسانی به افراد موضوع داده را تثبیت کنیم. اگر سناریو شامل داده‌های شخصی است و مقیاس یا ریسک‌ها قابل‌توجه‌اند، منطقی است که از پیش ارزیابی کنیم آیا DPIA لازم است و آن تصمیم را جداگانه ثبت کنیم. در زمینهٔ اروپایی این به‌خوبی با اصول GDPR Article 5، با توصیه‌های عملی CNIL по AI system developmentو همچنین با EDPS guidance on Generative AI و EDPB Opinion 28/2024هم‌راستا است.

و اینجا پرسش مهم دیگری پیش می‌آید: زمان آزادشدهٔ متخصصان کجا می‌رود. ساده‌ترین گزینه این است که بخواهیم حتی کارهای بیشتری در آن جا دهیم. گزینهٔ بالغ‌تر این است که این صرفه‌جویی را در کیفیت تصمیم‌ها، کاهش بدهی فنی، توسعهٔ قالب‌های داخلی، آموزش، مستندسازی و دست‌کم مدیریت بهتر توجه تیم سرمایه‌گذاری کنیم. در مقالهٔ مروری پایانی این مجموعه جداگانه توضیح خواهم داد که AI نه‌تنها فرایند، بلکه فرهنگ استفاده از زمان تیم را هم تغییر می‌دهد.

هزینه‌های پنهان جدیدی که نمی‌توان نادیده گرفت

برای اینکه بحث دربارهٔ بهره‌وری بیش از حد صاف به نظر نرسد، مهم است روی دیگر را هم اضافه کنیم: AI به‌ندرت «صرفه‌جویی خالص» بدون انواع جدیدی از کار می‌دهد. بخشی از زمان اکنون صرف آماده‌سازی داده، تنظیم دسترسی به منابع، نگهداری promptها و قالب‌ها، بررسی منابع، مستندسازی تصمیم‌ها و بازبینی انسانی می‌شود. این نگاه به‌خوبی با شیوه‌های risk management برای generative AI هم‌راستا است: برای مثال، профиль NIST для генеративного ИИ فقط بر مزایای اتوماسیون تأکید نمی‌کند، بلکه بر ضرورت نظارت، مستندسازی و کنترل مدیریتی نیز تأکید دارد.

برآورد سناریویی трудозатрат بر یک Backlog Refinement (سناریویی)

در ادامه — نه «میانگین دمای بازار»، بلکه یک مدل سناریویی از همان Backlog Refinement برای همان تیم هفت‌نفره: PO، BA، بک‌اند، فرانت‌اند، QA، طراح و اسکرام‌مستر. این برآورد یک آیتم بزرگ یا به‌طور محسوس مبهم بک‌لاگ است، نه یک استوری کوچک و خوب‌فهم. ارزش این اعداد در دقت تا دقیقه نیست، بلکه در مقایسه ساختار هزینه‌هاست: زمان پیش‌تر کجا می‌رفت و اکنون کجا می‌رود.

در ادامه دقیقاً سخن از نفر-ساعت به‌ازای یک آیتم بزرگ بک‌لاگ است — آماده‌سازی، بحث و اصلاح کوتاه پس از جلسه — نه مدت خود جلسه به‌عنوان چنین. خود جلسه هم معمولاً کوتاه‌تر می‌شود، اما بخشی از کار صرفاً به آماده‌سازی ناهمگام، اجراهای شفاف‌ساز و بررسی دستی الزامی منتقل می‌شود.

یادداشت بر محاسبه трудозатрат: از نظر تاریخی در Scrum Guide 2017 (RU PDF) refinement نیز به‌عنوان ongoing process توصیف می‌شد و در آنجا معیاری وجود داشت که معمولاً بیش از ۱۰٪ ظرفیت در دسترس تیم توسعه را اشغال نمی‌کند. در Scrum Guide 2020 (RU PDF) این معیار دیگر وجود ندارد، بنابراین جدول زیر را بهتر است نه به‌عنوان یک استاندارد، بلکه به‌عنوان یک مدل سناریویی برای مقایسه دو حالت کار خواند.

توضیح جداگانه مهم است: ستون «با AI» در زیر در حال حاضر شامل کار جدید پایه‌ای است که بدون آن این سناریو کار نمی‌کند — آماده‌سازی داده‌های ورودی، درخواست‌های شفاف‌ساز، بررسی اولیه خلاصه کوتاه، راستی‌آزمایی نقاط بحث‌برانگیز و حداقل بررسی انسانی. یعنی سود نهایی در جدول «خام» نیست — صرفه‌جویی پیش از لحاظ کردن هزینه‌های جدید — بلکه برآورد سناریویی واقع‌بینانه‌تری پس از لحاظ کردن پایه‌ای آن‌هاست.

برای اینکه این برآورد قابل بازتولید باشد، راحت است که آن را با یک طرح ساده محاسبه کرد: T_AI = T_base × ((1 − p) + p × s) + o، که در آن T_base — زمان بدون AI، p — سهم کار قابل تسریع، s — ضریب تسریع در این بخش، و o — کار جدید برای آماده‌سازی داده‌ها، درخواست‌های شفاف‌ساز و بررسی نتیجه.

در ادامه — یک مثال کالیبره‌شده دقیقاً برای همین سناریوی پایه. وظیفه آن اثبات یک هنجار جهانی نیست، بلکه نشان دادن این است که چگونه همان مدل می‌تواند اعداد جدول را برای یک مورد مشخص بازتولید کند. در یک تیم واقعی بهتر است چنین پارامترهایی را بر اساس ۳–۵ Backlog Refinement آخر کالیبره کرد و سپس دامنه خود را به دست آورد.

# Calibrated to reproduce the table (base scenario)
# T_ai = T_base * ((1 - p) + p * s) + o
roles = {
    "PO": {"T_base": 4.5, "p": 0.75, "s": 0.20, "o": 0.7},
    "BA": {"T_base": 10.0, "p": 0.70, "s": 0.20, "o": 0.6},
    "BE": {"T_base": 3.5, "p": 0.75, "s": 0.20, "o": 0.6},
    "FE": {"T_base": 3.0, "p": 0.75, "s": 0.20, "o": 0.3},
    "QA": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "UX": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "SM": {"T_base": 2.5, "p": 0.50, "s": 0.20, "o": 0.0},
}

def t_ai(x):
    return x["T_base"] * ((1 - x["p"]) + x["p"] * x["s"]) + x["o"]

total_base = sum(r["T_base"] for r in roles.values())
total_ai = sum(t_ai(r) for r in roles.values())

print("Total base:", round(total_base, 1))
print("Total AI:", round(total_ai, 1))
print("Gain:", round(total_base - total_ai, 1))

for role, x in roles.items():
    print(role, round(t_ai(x), 1))

نقش	بدون AI	با AI (با لحاظ کار جدید)	چه چیزی تغییر می‌کند
مالک محصول	۴.۵ ساعت	۲.۵ ساعت	سریع‌تر زمینه مشتری را جمع می‌کند، اما بخشی از زمان را صرف آماده‌سازی ورودی و درخواست‌های شفاف‌ساز می‌کند
تحلیلگر کسب‌وکار	۱۰ ساعت	۵ ساعت	جست‌وجو و بازنویسی دستی کمتر، راستی‌آزمایی، ویرایش و بررسی بیشتر اینکه AI چیز مهمی را از دست نداده باشد
توسعه‌دهنده بک‌اند	۳.۵ ساعت	۲ ساعت	سریع‌تر اولین تحلیل فنی را به دست می‌آورد، اما به‌طور جداگانه محدودیت‌های معماری و ریسک تکرار را بررسی می‌کند
توسعه‌دهنده فرانت‌اند	۳ ساعت	۱.۵ ساعت	سریع‌تر یکپارچه‌سازی UI و تنظیمات را برآورد می‌کند، در عین حال زودتر در بررسی نقاط بحث‌برانگیز درگیر می‌شود
مهندس کیفیت / مهندس QA	۳ ساعت	۲ ساعت	زودتر موارد مرزی و ریسک‌های زمانی را به دست می‌آورد، اما بیشتر در بررسی موارد ازقلم‌افتاده و سناریوهای منفی درگیر می‌شود
طراح UX/UI	۳ ساعت	۲ ساعت	سریع‌تر اولین نسخه رویکرد UI را جمع می‌کند و از پیش گزینه‌های اضافی رابط را حذف می‌کند
اسکرام‌مستر	۲.۵ ساعت	۱.۵ ساعت	زمان کمتر برای هم‌راستاسازی سازمانی زمینه، زمان بیشتر برای تسهیل تصمیم‌ها و ثبت پرسش‌های باز
مجموع	۲۹.۵ ساعت	۱۶.۵ ساعت	سود سناریویی — حدود ۱۳ نفر-ساعت در یک چنین Backlog Refinement، پس از لحاظ کردن کار جدید پایه

دامنه سناریو: سود چگونه می‌تواند تغییر کند

سناریو	بدون AI	با AI	سود خالص	چه زمانی چنین می‌شود
محتاطانه	۲۴–۲۸ ساعت	۱۸–۲۱ ساعت	۴–۱۰ ساعت	منابع ناقص‌اند، بررسی دستی زیاد است، تیم تازه در حال ساختن الگوهای کار با AI است.
پایه	۲۸–۳۲ ساعت	۱۵–۱۸ ساعت	۱۰–۱۵ ساعت	مورد مدل‌سازی‌شده تقریباً این‌گونه است: AI آماده‌سازی را خوب تسریع می‌کند، اما کار جدید برای راستی‌آزمایی در حال حاضر لحاظ شده است.
قوی	۳۰–۳۶ ساعت	۱۴–۱۷ ساعت	۱۳–۱۹ ساعت	تیم منابع خوب، الگوهای تکرارپذیر و قواعد روشن بهداشت داده و بررسی دستی دارد.

چه کار جدیدی در حال حاضر در سناریوی با AI لحاظ شده است

جدول زیر سود نهایی جدول اول را نقض نمی‌کند. این جدول صرفاً روشن می‌کند که بخشی از زمان صرفه‌جویی‌شده به‌واسطه کدام اقدامات جدید به فرایند بازمی‌گردد — و چرا حتی پس از آن، اثر خالص همچنان محسوس می‌ماند.

حوزه جدید کار	چه چیزی با AI ظاهر می‌شود	چرا لازم است
آماده‌سازی داده‌های ورودی	پاک‌سازی، ناشناس‌سازی، خلاصه‌سازی زمینه لازم	تا مدل را با داده‌های بی‌ارزش پر نکنیم و داده‌های اضافی را وارد نکنیم
درخواست‌های شفاف‌ساز	اجراهای مکرر، شفاف‌سازی چارچوب پاسخ، درخواست تفکیک واقعیت‌ها از فرضیات	تا اولین پاسخ زیبا را به‌عنوان درک نهایی نپذیریم
تنظیم الگوها	پرامپت‌ها، الگوهای شرح کار، قواعد قالب نتیجه	تا AI یک پیش‌نویس مفید و تکرارپذیر ارائه دهد، نه متن تصادفی
بررسی واقعیت‌ها	بررسی پیوندها به منابع، اصطلاحات، وضعیت‌ها و محدودیت‌ها	تا توهم‌زایی مدل و وضوح کاذب پیش از جلسه گرفته شود
مستندسازی اعتماد	ثبت اینکه دقیقاً چه چیزی به‌صورت دستی بررسی شده و چرا می‌توان به نتیجه اعتماد کرد	تا تیم مسئولیت را با یک پیش‌نویس زیبا جایگزین نکند

تفاوت‌ها بر اساس مراحل

مرحله	بدون AI	با AI
جمع‌آوری زمینه پیش از جلسه	جست‌وجوی دستی طولانی در اسناد، تیکت‌ها و حافظه افراد	اولین گذر بر منابع و خلاصه کوتاه به‌طور محسوسی سریع‌تر انجام می‌شود
پیش‌نویس شرح کار	دستی نوشته می‌شود و اغلب خام می‌ماند	یک پیش‌نویس قوی وجود دارد که تیم می‌تواند آن را نقد و اصلاح کند
خودِ Backlog Refinement	زمان زیادی صرف هم‌راستاسازی درک مشترک می‌شود	تمرکز به سمت تصمیم‌های بحث‌برانگیز، وابستگی‌ها و مرزهای نسخه اول جابه‌جا می‌شود
تکمیل پس از جلسه	اغلب باید شرح کار تقریباً از نو بازنویسی شود	نتایج از قبل به‌خوبی بسته‌بندی شده‌اند و به بازکاری دستی کمتری نیاز دارند

چک‌لیست کیفیت آماده‌سازی AI برای refinement

مهم: این Definition of Ready یک رویه داخلی تیم است، نه بخشی از Scrum Guide. اینجا به‌عنوان محافظی در برابر وضوح کاذب، جاافتادگی‌ها و مسئولیت مبهم در آماده‌سازی AI لازم است.

Definition of Ready برای پیش‌نویس AI

واقعیت‌ها از فرضیات جدا شده‌اند: تیم می‌داند چه چیزی از منابع گرفته شده و چه چیزی توسط مدل پیشنهاد شده است.

برای ادعاهای کلیدی محصولی و فنی، پیوند یا اشاره‌های روشن به منابع وجود دارد.

پرسش‌های باز زیر متن مرتب پنهان نشده‌اند، بلکه به‌صراحت مطرح شده‌اند.

اصطلاحات دامنه، وضعیت‌ها، محدودیت‌ها، نقش‌ها و وابستگی‌ها بررسی شده‌اند.

برای هر ادعای کلیدی، سطح شواهد روشن است: واقعیت از منبع، فرضیه کاری یا فرض مدل.

موارد مرزی، سناریوهای منفی و ریسک‌های زمانی به‌طور جداگانه بررسی شده‌اند.

روشن است که چه داده‌هایی نباید به مدل داده می‌شد و چه اقدامات بهداشت داده اعمال شده است.

برای انواع ادعاها مالکان بررسی تعیین شده‌اند: منطق کسب‌وکار، امکان‌سنجی معماری، آزمون‌پذیری و کار با داده.

تیم توافق کرده است که پیش‌نویس AI ماده خام برای بحث است، نه یک کار تقریباً آماده.

برای اینکه این چک‌لیست بیش از حد انتزاعی نماند، این‌گونه در مورد ما با یادآوری‌های ایمیلی به نظر می‌رسید:

AI پیشنهاد می‌کند وضعیت‌های not_started، in_progress و expired گنجانده شوند — تیم به‌صراحت علامت می‌زند که expired فعلاً یک فرضیه است، نه یک قاعده تأییدشده برای نسخه اول.
در خلاصه کوتاه گفته شده که اعلان‌ها باید بر اساس منطقه زمانی کاربر ارسال شوند — بک‌اند این را با منابع تطبیق می‌دهد و تأیید می‌کند که در سیستم فعلی منطقه زمانی فقط در سطح کلاینت ذخیره می‌شود و گذارهای میان مناطق زمانی و DST باید جداگانه بررسی شوند.
AI تاریخچه ارسال‌ها را به‌عنوان بخش «بدیهی» راه‌حل اضافه کرده است — مالک محصول و BA جداگانه تصمیم می‌گیرند که این بخش الزامی نسخه اول است یا بهبود نسخه بعدی، چون اینجا مسئله ممیزی و بار پشتیبانی هم مطرح است.
QA نه فقط فهرستی از موارد مرزی، بلکه یک وظیفه مشخص دریافت می‌کند تا تکرارها هنگام اجرای مجدد وظایف زمان‌بند، سناریوهای fallback زبانی، استثناهای کاربران archived و غیرفعال‌شده و سناریوهای منفی پیرامون مهلت‌ها را بررسی کند.
بک‌اند جداگانه محدودیت‌های نرخ، throttling، قابلیت تحویل و رفتار سیستم در ارسال‌های مکرر و خطاهای ارائه‌دهنده را بررسی می‌کند.
PO و BA additionally سیاست اعلان‌ها را اعتبارسنجی می‌کنند: به چه کسی می‌توان یادآوری فرستاد، کجا opt-out یا استثناهای مشتری لازم است، و چه چیزی رفتار مجاز برای دوره‌های الزامی محسوب می‌شود.

برای چنین موردی، جداگانه پرداختن به دو نکته عملی که اغلب نزدیک به تولید مطرح می‌شوند نیز مفید است: قابلیت تحویل به‌سرعت به بار پشتیبانی و تیم پشتیبانی مشتری تبدیل می‌شود اگر تشخیص درستی برای «چرا ایمیل نرسید» وجود نداشته باشد، و quiet hours و بازه‌های تقویمی اغلب نه «گزینه اضافی»، بلکه یک الزام سازمانی مشتری از آب درمی‌آیند.

چه کسی چه چیزی را به‌صورت دستی بررسی می‌کند

چه چیزی را بررسی می‌کنیم	مالک	نمونه در مورد LMS
هدف و سیاست محصولی	PO و BA	به چه کسی و چه زمانی یادآوری فرستاده شود، چه استثناهایی مجاز است، و مرزهای نسخه اول کجا هستند.
درستی قواعد و وضعیت‌ها	BA	کدام وضعیت‌ها «تکمیل نکرده» محسوب می‌شوند، با `expired` چه باید کرد و کجا این موضوع از منابع تأیید شده است.
محدودیت‌های معماری	توسعه‌دهنده بک‌اند	حذف تکرار، وظایف زمان‌بند، idempotency، گزارش ممیزی، محدودیت‌های نرخ و رفتار در ارسال‌های مکرر.
مرزهای UI نسخه اول	توسعه‌دهنده فرانت‌اند و طراح UX/UI	تنظیمات کجا قرار دارند، آیا صفحه تاریخچه جداگانه لازم است و کدام سناریوهای رابط کاربری واقعاً در نسخه اول هستند.
سناریوهای منفی و زمانی	مهندس کیفیت / مهندس QA	DST، مناطق زمانی، سناریوهای fallback زبانی، استثناهای کاربران archived و غیرفعال‌شده، و همچنین تکرارها هنگام اجرای مجدد وظایف زمان‌بند.
تسهیل تصمیم‌ها و پرسش‌های باز	اسکرام مستر	چه چیزی قبلاً تصمیم‌گیری شده، چه چیزی همچنان محل بحث است و کجا تیم باید سازش آگاهانه بپذیرد.
بهداشت داده و مجاز بودن داده	PO/BA و در صورت وجود، امنیت یا DPO	چه چیزی می‌توان به مدل داد، چه چیزی باید ناشناس شود و چه بررسی‌هایی پیش از اجرای آماده‌سازی AI الزامی است.

چه چیزی را به تیم توصیه می‌کنم

اینکه پیش‌نویس AI را فقط به این دلیل که خوب به نظر می‌رسد، کار آماده ندانیم.
به‌صراحت توافق کنید که تیم موظف است کدام بخش‌های زمینه را پیش از جلسه به‌صورت دستی بررسی کند و کدام را در خود جلسه.
به‌تدریج الگوهای محصولی و فرایندی خودتان را به لایهٔ هوش مصنوعی تیمی منتقل کنید، نه اینکه فقط از چت عمومی «همان‌طور که هست» استفاده کنید.
ریفاینمنت را صرفاً به این دلیل که آماده‌سازی سریع‌تر شده، به‌صورت مکانیکی کوتاه نکنید.
آگاهانه تصمیم بگیرید زمان آزادشده کجا صرف شود: کیفیت، آموزش، مستندسازی، بدهی فنی یا بازیابی توجه تیم.

جدا از این، مهم است محدودیت‌های کاربرد این سناریو را به یاد داشته باشید. اثر هوش مصنوعی بسته به بلوغ مستندات، دسترسی به منابع داخلی، پیچیدگی دامنهٔ محصول و میزان توانایی تیم در تبدیل دانش ضمنی به زمینهٔ تکرارپذیر بسیار متفاوت خواهد بود. جایی که داده‌های اولیه ضعیف‌اند، هوش مصنوعی می‌تواند بسته‌بندی را تسریع کند، اما لزوماً کیفیت تصمیم‌ها را بهتر نمی‌کند.

نتیجه‌گیری

اگر بخواهم خیلی خلاصه بگویم، اصلی‌ترین اثر هوش مصنوعی برای ریفاینمنت را این‌طور صورت‌بندی می‌کنم: هوش مصنوعی خودِ توافق تیم را تسریع نمی‌کند، بلکه آماده‌سازی مواد برای آن را تسریع می‌کند. به همین دلیل است که ریفاینمنت در ورودی سریع‌تر می‌شود: زمینه سریع‌تر جمع می‌شود، پیش‌نویس سریع‌تر پدید می‌آید، پرسش‌ها و ریسک‌های پایه سریع‌تر شناسایی می‌شوند و نتایج سریع‌تر بسته‌بندی می‌شوند.

اما این ریفاینمنت را به‌طور خودکار ساده‌تر نمی‌کند. چون به‌محض اینکه هزینهٔ آماده‌سازی کاهش می‌یابد، ارزش کاری که هوش مصنوعی هنوز واقعاً خوب انجام نمی‌دهد بیشتر می‌شود: درک دامنه، احساس محدودیت‌های واقعی، تشخیص شفافیت کاذب، برخورد محتاطانه با داده‌ها و کمک به تیم برای رسیدن به سازش‌های آگاهانه.

بنابراین بهترین راه نگاه به هوش مصنوعی در ریفاینمنت این است: بخشی از کار دستی گران‌قیمت پیرامون این عمل را حذف می‌کند، اما بررسی انسانی معنا را حتی مهم‌تر می‌کند. هرچه تولید آیتم‌های بک‌لاگ ساده‌تر شده، فهم این مهم‌تر شده که کدام‌یک واقعاً آمادهٔ بحث است و کدام فقط خوب به نظر می‌رسد. و در مقاله‌های بعدی این مجموعه جالب خواهد بود ببینیم این تغییر نه‌تنها بر فرایند، بلکه بر فرهنگ استفاده از زمان تیم چه تأثیری می‌گذارد.

منابع و مراجع

← همه جستارها