Acceptance Criteria چیست و چرا مهم است؟

Acceptance Criteria (معیار پذیرش) جزئیاتی است که به تیم کمک می‌کند بفهمد آیا یک آیتم بک‌لاگ — غالباً یک User Story — درست و کامل انجام شده است. شکلش می‌تواند مثال، قاعده، تست، یا یادداشت کوتاه باشد؛ مهم فهم مشترک است: وقتی این‌ها درست باشند، آیتم از نظر پذیرش این داستان تمام است.

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

Scrum Guide واژهٔ Acceptance Criteria را به‌عنوان عنصر اجباری تعریف نمی‌کند؛ اما Definition of Done را به‌عنوان توصیف رسمی کیفیت Increment می‌آورد. در عمل، AC معمولاً در سطح آیتم است و Done در سطح استاندارد کیفیت همهٔ Increment. این مقاله هر دو را متمایز و مکمل می‌کند. منبع توضیح AC در بستر User Story: راهنمای Mountain Goat Software.

پاسخ کوتاه

Acceptance Criteria همان Confirmation در سه‌گانهٔ Card / Conversation / Confirmation است: توافق قابل بررسی دربارهٔ آنچه باید برای «پذیرفته شدن این داستان» درست باشد. مهم است چون ابهام را کم می‌کند، تست را هدایت می‌کند، دامنه را محدود می‌کند، و از تمام‌شدن ظاهری بدون ارزش جلوگیری می‌کند.

AC جایگزین گفت‌وگو نیست و جایگزین Definition of Done هم نیست. AC می‌گوید این قابلیت خاص چه رفتارهایی باید داشته باشد؛ Done می‌گوید هر Increment از نظر کیفیت محصول چه استانداردی را باید پاس کند (تست خودکار، مرور، امنیت پایه، و غیره).

مثالهای ملموس

راهنمای User Stories مثالهایی از معیار پذیرش می‌آورد. نمونهٔ همایش:

داستان: به‌عنوان شرکت‌کننده می‌توانم نشست‌ها را در برنامهٔ شخصی ذخیره کنم تا برنامه‌ام را بچینم.

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

نمونهٔ فروشگاهی:

• مشتری بتواند سفارش‌های قبلی را ببیند.
• بتواند همهٔ اقلام موجود از یک سفارش قبلی را به سبد اضافه کند.
• اقلام ناموجود نشان داده شوند ولی خودکار اضافه نشوند.
• قبل از تسویه بتواند تعداد را تنظیم کند.

ببینید AC به‌جای «داشبورد زیبا» رفتار قابل مشاهده و قابل آزمون می‌نویسد. تیم هنوز آزادی طراحی UI دارد؛ مرز قبول مشخص است.

چرا مهم است؟ — پنج اثر عملی

1. کاهش بازکاری: اختلاف فهم قبل از ساخت بزرگ دیده می‌شود.
2. هدایت تست: تستر و توسعه‌دهنده سناریوهای یکسانی را هدف می‌گیرند.
3. محدود کردن دامنه: چه چیزی عمداً خارج از این داستان است روشن می‌شود.
4. توانمندسازی PO و ذی‌نفع: پذیرش بر اساس چک‌لیست، نه حس لحظه‌ای در Demo.
5. پشتیبانی از empiricism: نتیجهٔ Sprint شفاف‌تر بازرسی می‌شود.

در تیم‌های برون‌سپاری‌شده، AC ضعیف منبع اصلی اختلاف قرارداد است. در تیم داخلی، منبع اصلی «چرا دوباره نوشتیم؟» است.

تفاوت Acceptance Criteria و Definition of Done

طبق Scrum Guide، کار بخشی از Increment نیست مگر اینکه Definition of Done را برآورده کند. اگر آیتمی Done را پاس نکند، نمی‌تواند منتشر شود یا حتی در Sprint Review ارائه شود؛ به Product Backlog برمی‌گردد. AC ممکن است پاس شده باشد ولی Done نه — مثلاً رفتار درست است اما تست خودکار یا مرور امنیتی Done شما ناقص است. برعکسش هم خطرناک است: Done عمومی سبز، اما رفتار خاص داستان با انتظار PO نمی‌خواند چون AC نبود.

چطور AC خوب بنویسیم

اصول عملی:

• رفتار قابل مشاهده بنویسید نه معماری داخلی («کاربر می‌تواند X» به‌جای «جدول Y ساخته شود»).
• مسیر خوشحال و حداقل یک لبه یا خطا را پوشش دهید وقتی ریسک بالاست.
• قابل آزمون باشد: بله/خیر یا مثال مشخص.
• کوتاه و کافی: رمان ننویسید؛ گفت‌وگو را بکشید روی کاغذ.
• دامنهٔ خارج را وقتی ابهام رایج است صریح کنید («در این داستان اعلان ایمیل نیست»).

فرمت‌ها: لیست قواعد، مثالهای Given/When/Then، یا ترکیب. Guide فرمت اجباری ندارد؛ Mountain Goat هم می‌گوید شکل کمتر از فهم مشترک اهمیت دارد.

چه کسی می‌نویسد و چه وقت؟

ایدهٔ اولیه را PO، تحلیل‌گر یا حتی ذی‌نفع می‌تواند پیشنهاد دهد؛ اما Developers و تسترها باید در شکل‌گیری مشارکت کنند چون لبه‌ها و امکان‌پذیری را می‌بینند. جزئیات کامل لازم نیست روز اول ورود به بک‌لاگ باشد؛ قبل از ورود جدی به Sprint باید به‌اندازهٔ کافی روشن باشد که تیم بداند تمام‌شدن یعنی چه.

Refinement جای طبیعی رشد AC است. اگر Planning پر از اختراع معیار از صفر شد، refinement کافی نبوده است.

AC در برابر تست پذیرش و خودکارسازی

معیار پذیرش می‌تواند مستقیم به تست پذیرش دستی یا خودکار تبدیل شود، اما یکی نیستند. AC توافق محصولی است؛ تست اجرای آن توافق است. الزام اینکه هر AC از روز اول خودکار باشد برای تیم کوچک ممکن است سنگین باشد. ترتیب عقلانی: اول AC روشن، بعد تست‌های حیاتی مسیر پول/داده، بعد گسترش خودکارسازی.

مراقب ACهایی باشید که فقط UI را قفل می‌کنند («دکمه آبی در گوشهٔ راست»). رفتار و نتیجه را مشخص کنید؛ جزئیات بصری را به طراحی بسپارید مگر برند یا دسترس‌پذیری الزام قطعی داشته باشد.

اشتباه‌های رایج

• نوشتن AC بعد از Demo برای توجیه آنچه ساخته شده.
• معیارهای مبهم: «کاربرپسند باشد»، «سریع باشد» بدون عدد یا مثال.
• صدها معیار برای یک داستان — نشانهٔ داستان بیش‌ازحد بزرگ.
• قاطی کردن AC با تسک‌های پیاده‌سازی.
• نادیده گرفتن Done و فکر کردن که تیک سبز AC برای انتشار کافی است.
• تحمیل AC بدون Conversation با کسانی که می‌سازند و می‌آزمایند.

الگوی مینیمال برای تیم کوچک

1. برای هر آیتمی که این Sprint لمس می‌شود، ۳ تا ۷ معیار پذیرش بنویسید.
2. یک تعریف Done کوتاه تیمی داشته باشید (حتی پنج خط).
3. در Review، AC را بلند چک کنید نه فقط اسلاید.
4. هر بار سوءتفاهم تکراری دیدید، همان لبه را به قالب AC یا به Done ارتقا دهید.

این الگو بدون ابزار گران کار می‌کند. وقتی مقیاس بالا رفت، همان ACها می‌توانند وارد تست خودکار و Definition of Ready غیررسمی شوند — بدون اینکه آیین جدید جایگزین فهم شود.

پیوند با برون‌سپاری و قرارداد

اگر کار را به تیم خارجی می‌سپارید، User Story بدون AC دعوت به اختلاف است. حداقل: داستان، AC، و Done توافق‌شده برای Incrementهای تحویلی. تغییر AC وسط Sprint ممکن است؛ اما باید آگاهانه با اثر روی Sprint Goal مذاکره شود — نه با پیام شبانهٔ بدون ردپا.

جمع‌بندی برای تصمیم

Acceptance Criteria توافق قابل بررسی برای تمام‌شدن یک آیتم است و بخش Confirmation داستان‌ها را زنده می‌کند. اهمیتش در کم‌کردن ابهام، هدایت آزمون، و حفظ دامنه است. آن را کنار Definition of Done بگذارید: یکی رفتار این قابلیت را می‌سنجد، دیگری کیفیت Increment را.

اگر فقط یک عادت این هفته می‌سازید: هیچ داستانی بدون دست‌کم سه معیار پذیرش وارد کار فعال نشود، و در Review همان سه را با صدای بلند علامت بزنید.

الگوی نوشتن AC در ۳۰ دقیقه

1. داستان را بلند بخوانید و who/what/why را تأیید کنید.
2. ۵ دقیقه مسیر خوشحال را به ۲–۴ معیار تبدیل کنید.
3. ۵ دقیقه بپرسید «چه چیزی معمولاً می‌شکند؟» و یک یا دو لبه اضافه کنید.
4. ۵ دقیقه دامنهٔ خارج را بنویسید اگر لازم است.
5. ۵ دقیقه با Developer/تستر بپرسید کدام معیار مبهم یا غیرقابل‌آزمون است و اصلاح کنید.
6. ۵ دقیقه روی تعریف Done تیمی مرور کنید که با AC قاطی نشده باشد.

اگر ۳۰ دقیقه برای یک داستان کافی نبود، داستان احتمالاً Epic پنهان است و باید شکسته شود.

نمونهٔ AC ضعیف در برابر قوی

ربط AC به Incremental delivery

وقتی ACها درست نوشته شوند، تیم می‌تواند برش نازک‌تری از ارزش را Done کند و در Review نشان دهد. وقتی ACها همه‌چیزخواه باشند، Sprint به پروژهٔ کوچک تبدیل می‌شود و یادگیری عقب می‌افتد. هنر این است که AC همان Sprint را سخت‌گیر و همان محصول را بلندپرواز نگه دارد — با شکستن داستان، نه با پایین آوردن کیفیت.

در پایان، AC خوب قرارداد احترام‌آمیز بین محصول و مهندسی است: محصول می‌گوید چه چیزی پذیرفتنی است؛ مهندسی می‌گوید چگونه با Done به آن برسد؛ هر دو در Conversation مسئولیت ابهام را می‌پذیرند.

AC در قرارداد تحویل مرحله‌ای

برای پروژه‌های قیمت‌ثابت مرحله‌ای، هر مرحله باید Incremental با ACهای از پیش‌توافق‌شده بسته شود. تغییر AC معادل تغییر محدوده است و باید ثبت شود. این کار هم مشتری را از غافلگیری حفظ می‌کند هم تیم را از «همین را هم اضافه کنید»های بی‌پایان. Scrum لغت جادویی قرارداد نیست؛ AC و Done زبان قابل‌اجرای قراردادند.

چک‌لیست کیفیت AC قبل از Planning

• آیا هر معیار بدون باز کردن کد قابل تأیید است؟
• آیا حداقل یک مسیر غیرخوشحال پوشش داده شده اگر ریسک دارد؟
• آیا عدد یا مثال مبهم («سریع»، «کامل») باقی مانده؟
• آیا AC به تسک پیاده‌سازی تبدیل نشده؟
• آیا با Definition of Done همپوشانی گیج‌کننده ندارد؟
• آیا داستان هنوز بعد از افزودن AC به‌اندازهٔ Sprint است؟

اگر بیش از دو مورد قرمز است، داستان را به Planning نبرید. هزینهٔ یک refinement اضافه کمتر از یک Sprint مبهم است.

جمع‌بندی پیوند ۰۶۳ و ۰۶۴

User Story بدون Confirmation ناقص است؛ Confirmation بدون داستان/آیتم روشن به فهرست تست یتیم تبدیل می‌شود. با هم، شفافیت سطح آیتم را می‌سازند و در کنار Done شفافیت سطح Increment را. این همان زیرساختی است که Review را از تئاتر به بازرسی واقعی تبدیل می‌کند.

منابع و مراجع

• Mountain Goat Software — User Stories (acceptance criteria as confirmation) — https://www.mountaingoatsoftware.com/agile/user-stories
• The 2020 Scrum Guide™ — Increment; Definition of Done; Product Backlog refinement — https://scrumguides.org/scrum-guide.html