«این کار تمام شد؟» سؤال سادهای است که در تیمها جوابهای متفاوت میگیرد. توسعهدهنده میگوید «کدش آماده است»، تستر میگوید «هنوز یک حالت را چک نکردهام» و صاحب محصول میگوید «این چیزی که میخواستم نیست». ریشهٔ این اختلاف، نبود یک تعریف روشن از «انجام شدن» است.
معیار پذیرش همین ابهام را از بین میبرد. در این مقاله میبینید Acceptance Criteria چیست، چه فرقی با Definition of Done دارد، چطور با یک قالب ساده آن را بنویسید و چه اشتباهاتی را باید از آن دوری کنید.
Acceptance Criteria چیست؟ (پاسخ سریع)
معیار پذیرش (Acceptance Criteria) مجموعهای از شرایط مشخص و قابل آزمایش است که یک داستان کاربر یا تسک باید برآورده کند تا مشتری یا صاحب محصول آن را بپذیرد و «انجامشده» اعلام کند. هر معیار باید بهوضوح «قبول» یا «رد» شود.
فرق معیار پذیرش با Definition of Done چیست؟
این دو مفهوم در Agile اغلب اشتباه گرفته میشوند، اما سطحشان فرق دارد:
| معیار | Acceptance Criteria | Definition of Done |
|---|---|---|
| دامنه | مخصوص یک داستان یا تسک مشخص | برای همهٔ کارهای تیم یکسان است |
| سؤالش | «این کار که تمام شد، چه شکلی است؟» | «تیم چه وقتی میگوید یک کار واقعاً تمام است؟» |
| مثال | «فیلتر تاریخ باید در گزارش کار کند» | «کد باید تست شده و مستند باشد» |
| تغییر | در هر داستان متفاوت | تقریباً ثابت برای کل تیم |
به زبان ساده: معیار پذیرش میگوید «این کارِ خاص چه وقتی انجامشده حساب میشود»؛ Definition of Done میگوید «تیم ما اصولاً چه معیارهای کلیای برای تمامشدن دارد». هر دو لازماند و مکمل هم کار میکنند.
همین امروز به دوایتیفای بپیوندید
پروژهها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفتها و گزارشهای تیم در یک محیط یکپارچه. ساختهشده برای شرکتها، استارتاپها و تیمهای دورکار — با راهاندازی چنددقیقهای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
تفاوت User Story و Acceptance Criteria
این دو مفهوم مکملاند اما یکی نیستند:
| مورد | User Story | Acceptance Criteria |
|---|---|---|
| هدف | گفتن «چه چیزی» و «چرا» | گفتن «چطور بفهمیم انجام شده» |
| ماهیت | توصیفی و باز | عینی و قابل آزمایش |
| مثال | «میخواهم گزارش هفتگی بگیرم» | «گزارش باید فیلتر تاریخ داشته باشد» |
قانون: داستان کاربر میگوید چه چیزی لازم است؛ معیار پذیرش میگوید چه زمانی میتوان آن را «تمامشده» دانست.
قالب نوشتن معیار پذیرش: Given/When/Then
رایجترین و کاربردیترین قالب، قالب سهبخشی است:
- Given (با فرض): وضعیت اولیه چیست؟
- When (وقتی): چه عملی انجام میشود؟
- Then (آنگاه): چه نتیجهای انتظار میرود؟
مثال کامل
برای داستان «بهعنوان کاربر، میخواهم رمز عبورم را تغییر دهم»:
> Given: کاربر وارد حسابش شده و در صفحهٔ تغییر رمز است > When: رمز جدید را وارد و تأیید میکند > Then: رمز ذخیره میشود و پیام موفقیت نمایش داده میشود
و یک معیار دیگر:
> Given: کاربر در صفحهٔ تغییر رمز است > When: رمز جدید را کمتر از ۸ کاراکتر وارد میکند > Then: پیام خطای «رمز باید حداقل ۸ کاراکتر باشد» نمایش داده میشود
ویژگیهای یک معیار پذیرش خوب
| ویژگی | معنی |
|---|---|
| مشخص | بدون ابهام؛ هر کس بخواند یک برداشت داشته باشد |
| قابل آزمایش | بتوان با «بله/خیر» آن را تأیید یا رد کرد |
| مستقل از راهحل | بگوید «چه نتیجهای»، نه «با چه تکنولوژی» |
| واقعبینانه | در محدودهٔ داستان کاربر باشد |
مثالهای واقعی معیار پذیرش
مثال ۱ — صفحهٔ جستجو: > Given: کاربر در صفحهٔ اصلی است > When: کلمهٔ کلیدی را در جستجو وارد میکند > Then: نتایج مرتبط در کمتر از ۲ ثانیه نمایش داده میشود
مثال ۲ — سبد خرید: > Given: کاربر یک کالا را به سبد اضافه کرده است > When: تعداد را به ۳ تغییر میدهد > Then: جمع کل سبد بهروزرسانی میشود و هزینهٔ ۳ واحد را نشان میدهد
مثال ۳ — داشبورد تیم: > Given: مدیر وارد داشبورد میشود > When: فیلتر «این هفته» را انتخاب میکند > Then: فقط تسکهای با مهلت در این هفته نمایش داده میشوند
مثال عددی: یک معیار خوب چطور بحث را تمام میکند؟
بگذارید اثر یک معیار پذیرش خوب را با عدد نشان بدهیم. فرض کنید تیم روی «صفحهٔ جستجو» کار میکند و دو حالت داریم:
حالت بدون معیار مشخص: توسعهدهنده میگوید «جستجو کار میکند». تستر میگوید «در ۵۰۰۰ رکورد، کند است». صاحب محصول میگوید «ترتیب نتایج درست نیست». نتیجه: ۳ دور دوبارهکاری و حدود ۴ روز زمان اضافه.
حالت با معیار مشخص:
- جستجو باید در کمتر از ۲ ثانیه پاسخ دهد (با ۱۰۰۰ رکورد).
- نتایج باید بر اساس مرتبطبودن مرتب شوند.
- اگر نتیجهای نبود، پیام «نتیجهای یافت نشد» نمایش داده شود.
حالا همه از قبل میدانند «انجام شد» یعنی چه. تستر دقیقاً میداند چه چیزی را چک کند و صاحب محصول معیار عینی برای قبول/رد دارد. نتیجه: صفر دوبارهکاری دربارهٔ «تمام شد یا نه».
مزایای نوشتن معیار پذیرش
- پایاندادن به بحث «انجام شد»: همه از قبل میدانند معیار چیست.
- کاهش دوبارهکاری: تیم از اول درست میفهمد چه چیزی تحویل دهد.
- تست سادهتر: تستر دقیقاً میداند چه چیزی را چک کند.
- تخمین بهتر: با معیار روشن، اندازهٔ کار بهتر تخمین زده میشود.
محدودیتها و Trade-off معیار پذیرش
معیار پذیرش هم بیاشکال نیست؛ به این نکتهها توجه کنید:
- خطر معیارهای خیلی زیاد: اگر برای یک داستان دهها معیار بنویسید، عملاً داستان را به چند کار تقسیم نکردهاید و اندازهاش را بزرگ نگه داشتهاید.
- خطر معیارهای سختگیرانهٔ زودهنگام: در پروژههای اکتشافی که خودِ کار هنوز روشن نیست، معیار خیلی دقیق ممکن است خلاقیت تیم را محدود کند.
- خطر نوشتن معیار بعد از کار: معیاری که بعد از اتمام نوشته شود، به «توجیه کار انجامشده» تبدیل میشود، نه تعریف واقعی آن.
اشتباهات رایج در نوشتن معیار پذیرش
- نوشتن جزئیات فنی راهحل: «با استفاده از جدول فلان در دیتابیس…» معیار پذیرش نیست؛ تسک فنی است.
- معیار مبهم: «صفحه باید سریع باشد» — سریع یعنی چند ثانیه؟
- معیار خیلی زیاد: دهها معیار برای یک داستان، یعنی داستان خیلی بزرگ است.
- تکرار خود داستان: معیار باید مشخص کند «انجام شد» یعنی چه، نه اینکه داستان را تکرار کند.
- معیار غیرقابل آزمایش: شرطی که نتوان بهصورت بله/خیر آن را چک کرد.
نکات کاربردی
- نکته مهم: معیار پذیرش را قبل از شروع کار بنویسید و با تیم و صاحب محصول توافق کنید.
- ترفند کاربردی: هر معیار را با Given/When/Then بنویسید تا خودش قابل آزمایش شود.
- اشتباه رایج: نوشتن معیار بعد از اتمام کار؛ در این حالت معیار، توجیه کار انجامشده میشود، نه تعریف واقعی آن.
- قبل از شروع این را بدانید: معیار پذیرش را در چکلیست همان تسک ثبت کنید تا در لحظهٔ تحویل، قابل بررسی باشد.
دوایتفای و معیار پذیرش
معیار پذیرش باید کنار خودِ کار زندگی کند، نه در یک سند جدا که کسی نمیخواند. در دوایتفای میتوانید برای هر داستان کاربر یا تسک، چکلیست و توضیحات بگذارید، معیار پذیرش را بهصورت موارد قابل تیکزدن بنویسید و با کنترل کیفیت (QC) و وضعیت «انجام شد» (DOD) مطمئن شوید هر کار فقط با برآوردهشدن معیارها بسته میشود.
سوالات متداول
جمعبندی
معیار پذیرش، تعریف روشنِ «انجام شد» است. آن را با قالب Given/When/Then، مشخص و قابل آزمایش بنویسید، از جزئیات فنی راهحل دوری کنید و قبل از شروع کار با تیم توافق کنید. وقتی معیار پذیرش کنار خودِ کار ثبت شود، بحث «تمومه؟» برای همیشه تمام میشود.
اگر موضوع Acceptance Criteria برایتان مفید بود، پیشنهاد میکنیم بهترین نرم افزارهای مدیریت پروژه و برنامهریزی شخصی؛ راهکاری برای افزایش بهرهوری فردی و تیمی و مدیریت پروژه های سازمانی را هم بخوانید.
همین امروز به دوایتیفای بپیوندید
پروژهها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفتها و گزارشهای تیم در یک محیط یکپارچه. ساختهشده برای شرکتها، استارتاپها و تیمهای دورکار — با راهاندازی چنددقیقهای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
