Definition of Done برای خروجی تولیدشده با AI

Definition of Done در Scrum چه می‌گوید؟

Scrum Guide، Definition of Done را commitment مربوط به Increment می‌داند. Increment باید usable و thoroughly verified باشد و کاری که این تعریف را برآورده نمی‌کند، بخشی از Increment محسوب نمی‌شود. اگر Product Backlog Item به Definition of Done نرسیده باشد، نباید released یا حتی در Sprint Review به‌عنوان خروجی Done ارائه شود؛ باید برای آینده دوباره در Product Backlog در نظر گرفته شود.

نکتهٔ مهم این است که Definition of Done گزارش انجام فعالیت نیست. نمی‌گوید چند prompt نوشته شد، چند commit ثبت شد یا مدل چند پاسخ تولید کرد. دربارهٔ state نهایی کار حرف می‌زند: آیا چیزی که تیم ساخته، با معیار کیفیت محصول قابل‌استفاده است؟ مسئولیت رعایت آن هم با Developers است و اگر چند تیم روی یک محصول کار می‌کنند، باید تعریف مشترکی داشته باشند.

چرا خروجی AI تعریف قدیمی را به چالش می‌کشد؟

در کار معمولی، ممکن است بتوانیم با تست، review و acceptance criteria نسبتاً پایدار دربارهٔ تمام‌شدن کار تصمیم بگیریم. در سیستم AI، رفتار خروجی به مدل، نسخهٔ prompt، دادهٔ ورودی، retrieval، ابزارهای متصل، policy، زبان کاربر و حتی تغییر provider وابسته است. بنابراین یک نمونهٔ خوب از پاسخ، به‌تنهایی نشان نمی‌دهد سیستم در حالت‌های دیگر هم قابل‌اعتماد است.

AI همچنین مرز بین تولید و اجرا را کم‌رنگ می‌کند. یک مدل می‌تواند متن بنویسد، کد پیشنهاد دهد، تصمیم را خلاصه کند یا از طریق agent روی یک ابزار اقدام کند. ریسک هرکدام یکسان نیست. اشتباه در draft داخلی ممکن است با یک review ساده اصلاح شود؛ اما اشتباه در تغییر داده، پیام مشتری، توصیهٔ مالی یا انتشار کد، هزینه و مسیر بازگشت متفاوتی دارد.

پس Definition of Done نباید یک چک‌لیست ثابت و بی‌تفاوت به ریسک باشد. باید بگوید این نوع خروجی برای این نوع استفاده، با چه evidenceای قابل‌تحویل است و مرز approval انسانی کجاست.

سه وضعیت را از هم جدا کنیم: Generated، Verified و Done

یکی از ساده‌ترین اصلاحات فرایند این است که خروجی تولیدشده را از خروجی تأییدشده و خروجی Done جدا کنیم. در بسیاری از تیم‌ها همین سه واژه مخلوط می‌شوند و مدل به‌دلیل لحن مطمئنش، مرحلهٔ آخر را شبیه‌سازی می‌کند.

Generated یعنی مدل یک پیشنهاد یا artifact ساخته است. این خروجی می‌تواند ارزشمند باشد، اما هنوز ممکن است فاقد منبع، ناقص، ناسازگار با نیاز یا خطرناک باشد. Verified یعنی خروجی با روش تعریف‌شده بررسی شده است؛ مثلاً تست اجرا شده، claimها به منبع برگشته‌اند یا reviewer واجد شرایط آن را دیده است. Done یعنی علاوه بر verification، شرایط انتشار یا استفادهٔ موردنظر، ownership و مسیر پایش و بازگشت هم آماده است.

این تفکیک برای مدیریت پروژه هم مهم است. اگر تیم ۱۰۰ پاسخ تولید کرده اما فقط ۷۰ پاسخ معیار review را گذرانده‌اند، ظرفیت واقعی تحویل ۱۰۰ نیست. خروجی خام را با Increment قابل‌استفاده در یک ردیف اندازه‌گیری نکنیم.

• Generated: draft یا پیشنهاد مدل، همراه با وضعیت و منبع اولیهٔ ورودی.
• Verified: خروجی از تست، evaluation یا review متناسب با ریسک عبور کرده است.
• Done: برای use case مشخص قابل‌استفاده است، owner دارد و پایش و rollback آن معلوم است.

لایه‌های یک Definition of Done برای AI

من برای شروع، Definition of Done را به چند لایه تقسیم می‌کنم. لازم نیست همهٔ لایه‌ها برای هر draft یکسان باشند؛ اما تیم باید آگاهانه مشخص کند کدام لایه برای این خروجی لازم نیست و چرا. حذف یک کنترل به‌دلیل کم‌ریسک‌بودن با فراموش‌کردن کنترل فرق دارد.

لایهٔ اول، مسئله و معیار پذیرش است. خروجی باید به یک job، user story یا decision مشخص وصل باشد و معلوم باشد موفقیت آن را چگونه می‌سنجیم. «پاسخ خوب» معیار کافی نیست؛ باید بگوییم پاسخ درست، کامل، قابل‌اقدام یا منطبق با policy یعنی چه.

لایهٔ دوم، صحت و کیفیت است. بسته به محصول، این بخش می‌تواند شامل unit test، integration test، schema validation، بررسی citation، تست زبان، ارزیابی نمونه‌های مرزی و مقایسه با baseline باشد. برای خروجی متنی، grammar تنها معیار کیفیت نیست؛ برای کد هم compile شدن به‌تنهایی کافی نیست.

لایهٔ سوم، safety، privacy و security است. دادهٔ حساس نباید بی‌دلیل وارد prompt یا log شود، ابزارها باید کمترین دسترسی لازم را داشته باشند و مسیر misuse یا prompt injection بررسی شود. اگر خروجی اثر حقوقی، مالی، پزشکی یا انسانی جدی دارد، سطح review باید با همان ریسک تنظیم شود.

لایهٔ چهارم، provenance است. باید بتوانیم نسخهٔ مدل، prompt یا template، زمان تولید، ورودی‌های مهم، منابع retrieval، ابزارهای استفاده‌شده و تغییرهای دستی مهم را تا حدی ثبت کنیم که بازسازی تصمیم ممکن باشد. provenance به معنی ذخیرهٔ بی‌حدوحصر اطلاعات شخصی نیست؛ باید با data minimization همراه باشد.

لایهٔ پنجم، ownership و عملیات است. یک نفر یا نقش مشخص باید بداند چه چیزی را approve می‌کند، چه سیگنالی را بعد از انتشار می‌بیند و در صورت افت کیفیت چه اقدامی انجام می‌دهد. اگر هیچ‌کس owner نیست، output از نظر من Done نشده، حتی اگر تمام تست‌های فنی سبز باشند.

• مسئله، scope و acceptance criteria روشن است.
• تست و evaluation متناسب با use case اجرا شده و نتیجه ثبت شده است.
• خطاهای مهم، حالت‌های مرزی و مسیر fallback بررسی شده‌اند.
• دادهٔ حساس، مجوز ابزار و ریسک misuse کنترل شده است.
• منبع، نسخه و تغییرهای انسانی مهم قابل‌ردگیری هستند.
• reviewer یا approver و مسئول نهایی مشخص است.
• monitoring، alert و rollback یا مسیر اصلاح تعریف شده است.

برای هر نوع خروجی، DoD متفاوت است

یک اشتباه رایج این است که تیم یک Definition of Done را برای همهٔ خروجی‌های AI کپی کند. بهتر است یک baseline سازمانی داشته باشیم و آن را برای نوع artifact و سطح ریسک extension بدهیم.

برای محتوای داخلی، ممکن است شرط اصلی citation، عدم وجود اطلاعات محرمانه، review صاحب موضوع و مشخص‌بودن audience باشد. برای مقالهٔ عمومی، علاوه بر این‌ها باید ادعاهای به‌روز، تاریخ بررسی، لینک منبع اولیه و هماهنگی metadata با متن دیده شود. در هر دو حالت مدل می‌تواند draft بسازد، اما publication هنوز یک تصمیم انسانی است.

برای کد، DoD معمولاً به build، test، lint، review، security scan، migration safety و قابلیت rollback نیاز دارد. یک agent می‌تواند branch یا pull request آماده کند، اما merge شدن نباید نتیجهٔ ضمنی تولید کد باشد. برای تصمیم‌یار، trace کردن منبع، نمایش uncertainty و امکان اعتراض یا escalation اهمیت بیشتری دارد.

برای agentی که اقدام بیرونی انجام می‌دهد، approval boundary مهم‌تر می‌شود. خواندن داده، پیشنهاد action و اجرای action سه مجوز جدا هستند. ممکن است مدل اجازهٔ ساختن draft داشته باشد اما اجازهٔ ارسال، حذف یا تغییر دائمی بدون confirmation نداشته باشد.

• Text و content: منبع، صحت claim، tone، privacy و review صاحب موضوع.
• Code: تست، امنیت، review، سازگاری و rollback.
• Decision support: evidence، uncertainty، توضیح‌پذیری و امکان اعتراض.
• Autonomous action: scope مجوز، approval، audit log و مسیر توقف.

Evaluation را به جای «به‌نظر خوب می‌آید» قرار دهیم

مستندات رسمی OpenAI، evaluation را برای آزمودن خروجی مدل در برابر معیارهای style و content و برای مقایسهٔ عملکرد هنگام تغییر prompt یا مدل ضروری می‌داند. فرایند پیشنهادی ساده است: task را دقیق تعریف کنیم، با ورودی‌های آزمایشی اجرا کنیم، نتیجه را تحلیل کنیم و تکرار کنیم. این منطق به BDD نزدیک است؛ ابتدا رفتار مورد انتظار را توضیح می‌دهیم و سپس آن را می‌سنجیم.

برای Definition of Done، این یعنی حداقل یک مجموعهٔ نمونهٔ نماینده داشته باشیم؛ نه فقط مثال‌های آسانی که مدل روی آن‌ها خوب جواب می‌دهد. نمونه‌ها باید happy path، edge case، ورودی بد، زبان و context واقعی، و failure caseهای قبلی را پوشش دهند. اگر معیار pass/fail را قبل از دیدن خروجی تعریف نکنیم، احتمال دارد نتیجه را با سلیقهٔ لحظه‌ای توجیه کنیم.

برای تیم کوچک، evaluation لازم نیست از روز اول یک پلتفرم بزرگ باشد. یک فایل versioned با ورودی، خروجی مورد انتظار، rubric و نتیجهٔ review می‌تواند شروع باشد. وقتی prompt، مدل یا retrieval تغییر کرد، همان نمونه‌ها را دوباره اجرا کنیم و regression را ببینیم. هدف عددسازی نیست؛ هدف این است که تغییر را با evidence مقایسه کنیم.

• هدف خروجی را در یک جملهٔ قابل‌سنجش بنویسید.
• نمونه‌های واقعی و failure caseهای قبلی را جمع کنید.
• grader یا rubric را پیش از بررسی خروجی تعیین کنید.
• نتیجه را با baseline مقایسه کنید، نه با impression شخصی.
• eval را بعد از تغییر مدل، prompt، داده یا ابزار تکرار کنید.
• موارد مبهم را برای review انسانی نگه دارید و آن‌ها را به pass قطعی تبدیل نکنید.

چه چیزهایی را خودکار کنیم و چه چیزهایی را نه؟

هدف DoD حذف review انسانی نیست؛ هدف این است که review انسانی وقتش را روی judgment مصرف کند، نه روی کنترل‌های مکانیکی. هرجا می‌توانیم یک شرط را deterministic کنیم، آن را در pipeline بگذاریم. هرجا تصمیم به context، ریسک یا مسئولیت نیاز دارد، آن را به انسان بسپاریم و از مدل فقط evidence و پیشنهاد بخواهیم.

در یک pipeline محتوا، می‌توانیم schema، وجود title و description، لینک‌های شکسته، تکرار slug، citationهای خالی، طول غیرعادی و محتوای ممنوع را خودکار بررسی کنیم. اما اینکه claim برای انتشار کافی است، منبع واقعاً قابل‌اعتماد است یا tone با برند و مخاطب می‌خواند، هنوز نیازمند review است.

در یک pipeline کد، build، test، lint و اسکن آسیب‌پذیری می‌توانند gate خودکار باشند. اما merge کردن، قبول کردن تغییر معماری، release migration یا تصمیم دربارهٔ ریسک کسب‌وکار، باید owner انسانی داشته باشد. سبزشدن pipeline یعنی شروط تعریف‌شده پاس شده‌اند، نه اینکه تمام واقعیت محصول خوب است.

• خودکار کنید: تست تکراری، validation، بررسی schema، اجرای eval، ثبت نسخه و ساخت گزارش evidence.
• پیشنهاد بگیرید: اولویت failure case، خلاصهٔ diff، سؤال‌های باز و مسیرهای احتمالی اصلاح.
• واگذار نکنید: approval نهایی، تصمیم safety، claim حقوقی یا مالی، انتشار عمومی و ownership خطا.

DoD نباید جلوی جریان Agile را بگیرد

ترس معمول این است که افزودن evaluation، provenance و review تیم را کند کند. این نگرانی واقعی است، اما پاسخ آن حذف quality gate نیست. باید سطح کنترل را با ریسک و مرحلهٔ lifecycle تنظیم کنیم. یک draft برای آزمایش داخلی می‌تواند DoD سبک‌تری داشته باشد؛ خروجی production یا action برگشت‌ناپذیر به کنترل قوی‌تری نیاز دارد.

برای اینکه DoD به bureaucracy تبدیل نشود، هر شرط باید با یک failure mode مشخص توجیه شود. اگر نمی‌دانیم یک checkbox چه خطری را کم می‌کند، احتمالاً یا باید حذف شود یا بازنویسی شود. از طرف دیگر، اگر یک کنترل مرتباً failure پیدا می‌کند، آن را به backlog بهبود سیستم تبدیل کنیم؛ نباید هر بار همان خطا را با قهرمانی reviewer جبران کنیم.

اثر AI بر Agile در اینجا روشن است: مدل ظرفیت تولید را بالا می‌برد، بنابراین bottleneck می‌تواند به review، تست، تصمیم و release منتقل شود. DoD خوب این bottleneck را پنهان نمی‌کند؛ آن را قابل‌مشاهده می‌کند تا تیم ظرفیت review و automation را هم برنامه‌ریزی کند. خروجی بیشتر بدون ظرفیت verification، فقط صف بزرگ‌تری از draftها می‌سازد.

• برای prototype، شرط‌های ضروری را نگه دارید و ریسک را صریح ثبت کنید.
• برای production، معیارهای reliability، privacy، monitoring و rollback را اضافه کنید.
• در Sprint Planning، ظرفیت evaluation و human review را کنار ظرفیت build ببینید.
• اگر review صف شده، علت را پیدا کنید: scope، ابزار، داده، rubric یا ownership؟
• DoD را با failureهای واقعی هر چند Sprint بازبینی کنید.

یک قالب عملی برای Definition of Done

قالب زیر را می‌توان برای یک قابلیت یا workflow مشخص در ticket، pull request یا decision record گذاشت. قرار نیست همهٔ خط‌ها برای همهٔ پروژه‌ها اجباری باشند؛ مهم این است که انتخاب‌ها visible و قابل‌بحث باشند.

نمونهٔ من برای یک قابلیت AI این است: «این خروجی فقط وقتی Done است که هدف و audience آن روشن باشد، acceptance criteria را پاس کند، با مجموعهٔ eval نسخه‌دار نسبت به baseline افت معنادار نداشته باشد، دادهٔ حساس و مجوز ابزار کنترل شده باشد، source و نسخهٔ مدل و prompt ثبت شده باشد، reviewer مشخص آن را تأیید کرده باشد و برای failure بعد از انتشار، monitoring و مسیر rollback وجود داشته باشد.»

اگر شرطی به‌دلیل low-risk بودن حذف می‌شود، همان تصمیم را ثبت کنید. شفافیت دربارهٔ یک کنترل حذف‌شده از وانمودکردن به پوشش کامل بهتر است. همچنین DoD را با Definition of Ready یا فهرست کارهای توسعه قاطی نکنیم؛ یکی دربارهٔ آمادگی شروع است و دیگری دربارهٔ کیفیت Increment نهایی.

• Use case و سطح ریسک: این خروجی برای چه تصمیم یا کاری است؟
• Acceptance: چه چیزی باید درست، کامل، قابل‌اقدام یا منطبق با policy باشد؟
• Evidence: کدام test، eval، منبع یا review این را نشان می‌دهد؟
• Provenance: مدل، prompt، داده، ابزار و زمان چگونه ثبت می‌شوند؟
• Ownership: چه کسی approve می‌کند و چه کسی پاسخ‌گوی خطا است؟
• Operations: چه چیزی monitor می‌شود و در failure چه چیزی برمی‌گردد؟

بعد از انتشار، Done پایان کار نیست

در production، خروجی AI ممکن است با تغییر داده، رفتار کاربر، نسخهٔ provider یا context کسب‌وکار افت کند. مستندات رسمی OpenAI برای رفتن به production بر مدیریت نسخهٔ داده و مدل، monitoring عملکرد در طول زمان، deployment کنترل‌شده، هزینه، rate limit، security و safety تأکید می‌کند. بنابراین DoD باید یک شرط پس از انتشار هم داشته باشد، حتی اگر ساده باشد.

برای یک تیم کوچک، چند سیگنال عملی کافی است: نرخ fallback، نرخ اصلاح انسانی، complaint یا گزارش خطا، latency، هزینهٔ هر درخواست، pass rate ارزیابی دوره‌ای و تعداد actionهایی که به escalation رسیده‌اند. این‌ها به‌تنهایی کیفیت کامل را اندازه نمی‌گیرند، اما به تیم می‌گویند کجا باید inspect کند. اگر threshold مهمی شکسته شد، rollout را متوقف یا feature را به حالت محدود برگردانیم.

این نگاه باعث می‌شود release را یک اتفاق یک‌باره نبینیم. Done به معنی آماده‌بودن برای استفاده در شرایط تعریف‌شده است، نه تضمین اینکه سیستم برای همیشه بی‌خطا خواهد ماند. owner باید بعد از انتشار هم وجود داشته باشد و learning را به نسخهٔ بعدی DoD برگرداند.

• یک baseline و threshold ساده برای کیفیت، هزینه و latency داشته باشید.
• failure case و اصلاح انسانی را به مجموعهٔ eval برگردانید.
• برای افت مهم کیفیت یا افزایش ریسک، kill switch یا fallback تعریف کنید.
• تغییر مدل، prompt، retrieval و policy را به‌عنوان change قابل‌بررسی ثبت کنید.
• DoD را پس از incident یا تغییر مهم محصول بازنویسی کنید.

اثر این تعریف بر مدیریت پروژه و تصمیم محصول

وقتی DoD خروجی AI را دقیق می‌کند، برآورد پروژه هم واقع‌بینانه‌تر می‌شود. زمان ساخت prompt یا اتصال API تنها بخشی از کار است. جمع‌آوری نمونه، طراحی rubric، اجرای eval، review، حفاظت از داده، instrumentation، monitoring و مسیر rollback هم باید در scope دیده شوند. این همان بخشی است که در پروژه‌های AI معمولاً invisible می‌ماند و بعداً به rework و تأخیر تبدیل می‌شود.

از نگاه Product Owner، Definition of Done کمک می‌کند وعدهٔ «قابلیت AI داریم» به سؤال‌های قابل‌تصمیم تبدیل شود: برای چه user و چه سطح خطایی؟ با چه evidenceای؟ چه چیزی هنوز human-only است؟ اگر quality افت کرد، چه چیزی را متوقف می‌کنیم؟ از نگاه Scrum Master یا مدیر پروژه، این تعریف visibility واقعی‌تری از bottleneck می‌دهد؛ شاید مشکل تیم کمبود Developer نباشد و کمبود reviewer یا دادهٔ ارزیابی باشد.

دیدگاه من این است که AI مفهوم Done را بی‌اعتبار نکرده؛ آن را جدی‌تر کرده است. هرچه تولید آسان‌تر شود، تفاوت بین artifact زیاد و value قابل‌اعتماد مهم‌تر می‌شود. تیمی که این تفاوت را در فرایندش ثبت می‌کند، هم سریع‌تر یاد می‌گیرد و هم کمتر گرفتار سرعت نمایشی می‌شود.

چک‌لیست کوتاه پیش از اعلام Done

• می‌دانیم این خروجی دقیقاً کدام مسئله و کدام کاربر را حل می‌کند.
• معیار پذیرش را قبل از دیدن خروجی نوشته‌ایم.
• نمونه‌های نماینده و failure caseها بررسی شده‌اند.
• تست یا evaluation با نتیجهٔ قابل‌ردگیری اجرا شده است.
• منبع، نسخه و تغییرهای مهم انسانی مشخص است.
• دادهٔ حساس، مجوز ابزار و مسیر misuse بررسی شده است.
• reviewer و owner نهایی نام‌گذاری شده‌اند.
• می‌دانیم بعد از انتشار چه چیزی را monitor می‌کنیم.
• fallback، escalation یا rollback برای failure مهم وجود دارد.
• اگر یک شرط را حذف کرده‌ایم، دلیل و ریسک آن ثبت شده است.

جمع‌بندی

واقعیت عمومی: Scrum Guide، Definition of Done را توصیف رسمی کیفیت لازم برای Increment می‌داند و کاری را که به آن نرسیده، بخشی از Increment قابل‌ارائه حساب نمی‌کند. مستندات رسمی OpenAI هم evaluation را برای مقایسهٔ رفتار مدل با معیارهای مشخص و کشف regression هنگام تغییر prompt یا مدل توصیه می‌کند و برای production به versioning، monitoring، security، safety و مدیریت هزینه اشاره دارد.

تحلیل من: در محصول AI، Generated فقط شروع کار است. Definition of Done باید بین draft، خروجی verified و Increment قابل‌استفاده فرق بگذارد و علاوه بر تست، provenance، review انسانی، ownership و rollback را ببیند. این کار قرار نیست تیم را با فرم‌های بیشتر متوقف کند؛ قرار است هزینهٔ پنهان review و rework را زودتر visible کند.

پیشنهاد حکیم: برای یک workflow کوچک شروع کنید، baseline و ده‌ها failure case نسازید؛ با چند نمونهٔ واقعی، یک rubric روشن، یک owner و یک مسیر توقف آغاز کنید. سپس هر incident و هر تغییر مدل یا prompt را به DoD و eval برگردانید. خروجی AI زمانی واقعاً ارزشمند است که تیم بتواند با مسئولیت آن را استفاده کند، نه فقط با هیجان آن را تولید کند.

منابع اولیه برای بررسی

Scrum Guide نسخهٔ HTML برای تعریف Increment، Definition of Done، usability، verification، transparency و مسئولیت Developers: https://scrumguides.org/scrum-guide.html — بررسی‌شده در 2026-09-15.

راهنمای رسمی OpenAI دربارهٔ Evals برای تعریف task، اجرای eval با test input، تحلیل نتیجه و iteration هنگام بهبود prompt یا مقایسهٔ مدل: https://developers.openai.com/api/docs/guides/evals — بررسی‌شده در 2026-09-15.

راهنمای رسمی OpenAI دربارهٔ Production Best Practices برای versioning داده و مدل، monitoring، deployment، هزینه، security، safety و production readiness: https://developers.openai.com/api/docs/guides/production-best-practices — بررسی‌شده در 2026-09-15.

مرز شواهد و تحلیل

تعریف‌های Scrum و پیشنهادهای فنی مربوط به evaluation و production از منابع اولیهٔ بالا گرفته شده‌اند. این منابع تضمین نمی‌کنند که هر مدل یا workflow برای هر تیم عملکرد یکسانی داشته باشد. تفکیک Generated، Verified و Done، قالب لایه‌ای، چک‌لیست، مدل ownership و تحلیل اثر AI بر Agile، کیفیت محصول و مدیریت پروژه دیدگاه امین رضا سیدآبادی است و باید با ریسک، داده و ابزارهای واقعی هر تیم تطبیق داده شود.