«جستوجو باید سریع و دقیق باشد.» این جمله در جلسات نیازمندیها بارها شنیده میشود و اغلب به همان شکل در بکلاگ مینشیند. ماهها بعد، در جلسه پذیرش، دو تیم با دو تصویر متفاوت از «سریع» و «دقیق» روبهروی هم مینشینند و تحویل معلق میماند. اینجا دقیقاً جایی است که مفهوم Acceptance Criteria از سطح بحث به ابزار کار تبدیل میشود.
پرسش اصلی این مقاله ساده است: مرز «تمامشدن» یک نیاز را چه چیزی تعیین میکند و چه تفاوتی میان آنچه بهعنوان User Story مینویسیم و آنچه بهعنوان معیار پذیرش ثبت میکنیم؟ پاسخ این پرسش، کیفیت جلسات پذیرش، دموها و حتی رابطه تیم با کارفرما را عوض میکند.
تحلیل: سه لایه از نیاز تا معیار پذیرش
مسیر هر قابلیت از سه لایه میگذرد. لایه اول، نیاز واقعی کسبوکار یا کاربر است؛ چیزی که هنوز با زبان فنی گفته نشده. لایه دوم، داستان کاربر (User Story) است: بازگویی کوتاه ارزش از زبان کاربر با قالب آشنا «بهعنوان [نقش] میخواهم [قابلیت] تا [ارزش]». داستان کاربر قرار است گفتوگو را شروع کند، نه جایگزین سند جامع شود؛ به همین دلیل عمداً کوتاه نوشته میشود و جزئیات را عمداً به تعویق میاندازد.
لایه سوم، معیارهای پذیرش (Acceptance Criteria) است: شرطهایی مشخص و قابل راستیآزمایی که تعیین میکنند چه زمانی این داستان از دید مالک محصول پذیرفته میشود. داستان میگوید چه چیزی و برای چه ارزشی ساخته میشود؛ معیار پذیرش میگوید مرز آن کجاست و از کجا میفهمیم به مرز رسیدهایم.
نیازمندی، داستان کاربر و معیار پذیرش چه نسبتی با هم دارند؟
نیازمندی، گزاره کلی به سبک «سیستم باید…» است؛ داستان کاربر همان نیاز را از دریچه انسان و ارزش میبیند؛ و معیار پذیرش آن را به شرطهای کفایت تبدیل میکند. هیچکدام جایگزین دیگری نیست: نیازمندی برای ثبت خواسته، داستان برای ایجاد فهم مشترک و معیار پذیرش برای داوری پایان کار به کار میآید. نکته مهم این است که معیار پذیرش سند جامع نیست؛ پوشش مسیرهای اصلی و شرطهای کفایت است، نه فهرست بیانتهای جزئیات فنی.
یک تمایز دیگر هم لازم است: معیار پذیرش مخصوص همان داستان است، اما تعریف انجامشده (Definition of Done) چکلیست سازمانی برای همه آیتمهاست؛ تستشدن، مستندسازی و آمادگی استقرار. داستانی که همه معیارهای پذیرش را پاس کرده اما از تعریف انجامشده عقب است، هنوز تمام نشده؛ این دو لایه، همدیگر را پوشش میدهند نه اینکه جای هم را بگیرند.
قالب Given-When-Then
یکی از قالبهای رایج نوشتن معیار پذیرش، سهپارهای Given-When-Then است: وضعیت آغازین، کنشی که کاربر انجام میدهد و نتیجهای که باید رخ دهد. مثلاً برای سامانه نوبتدهی یک کلینیک: «با فرض ورود بیمار با کد ملی معتبر، وقتی بازه زمانی خالی را انتخاب و ثبت میکند، آنگاه نوبت در همان نشست تأیید و پیامک اعلام دریافت ارسال میشود.» این قالب برای منطقهای شرطی و مسیرهای چندشاخهای عالی است؛ برای قابلیتهای ساده، فهرست شرطهای ساده هم کفایت میکند و الزامی به پیچاندن کار نیست.
سه مثال تبدیل نیاز مبهم به معیار قابلقبول
جدول زیر نشان میدهد یک جمله مبهم کارفرما چگونه به معیارهای عملیاتی ترجمه میشود:
| نیاز بیانشده کارفرما | مشکل عبارت | معیار پذیرش پیشنهادی |
|---|---|---|
| «جستوجوی مشتری باید سریع باشد» | «سریع» برای هیچکس قابل اندازهگیری نیست و داوری به سلیقه میافتد | جستوجوی نام مشتری روی فهرست نمونهای توافقشده، نتیجه را پیش از تأیید کاربر در همان جلسه نمایش میدهد؛ حالت بدون نتیجه هم پیام راهنمای مناسب دارد |
| «کاربر بتواند فاکتور را اصلاح کند» | محدوده اصلاح، نقشها و وضعیتهای مجاز روشن نیست | کارشناس فروش میتواند تا پیش از تأیید مالی، ردیفها و توضیحات را ویرایش کند؛ پس از تأیید، گزینه ویرایش دیده نمیشود و هر تغییر ثبتشده در تاریخچه فاکتور میماند |
| «کاربر تیکتهایش را دنبال کند» | «دنبالکردن» تعریف روشنی ندارد | کاربر با شماره تیکت وضعیت فعلی را میبیند؛ هر تغییر وضعیت اعلان تولید میکند؛ پاسخ پشتیبان برای کاربر قابل مشاهده است |
در هر سه نمونه، الگو یکی است: از صفتهای ارزیابی به رفتارهای قابل مشاهده و شرطهای مرزی رفتیم. معیار خوب را میتوان در جلسه پذیرش تیک زد، نه تفسیر کرد؛ و همین است که بحثهای بیپایان «به نظرم آماده است» را تمام میکند.
ویژگیهای معیار پذیرش خوب
- قابل آزمون و دودویی؛ یا برقرار است یا نیست، بدون درجهبندی سلیقهای.
- کفایتمحور؛ شرطهای لازم برای پذیرش را میگوید، نه همه جزئیات محصول را.
- پوششدهنده مسیرهای خطا و مرزها، نه فقط مسیر خوشِ کاربر.
- نوشتهشده پیش از توسعه؛ تغییر معیارها بعد از تحویل، جابهجایی تیرانداز است.
- به زبان مشترک ذینفع و تیم؛ جملهای که کارفرما هم بفهمد و تیم هم بتواند برایش راستیآزمایی بسازد.
خطاهای رایج
- نوشتن معیارها بعد از پایان توسعه؛ این کار گفتوگو را به محاکمه تبدیل میکند و اعتماد را میخورد.
- تکرار خودِ داستان در معیارها؛ اگر معیار چیزی اضافه نمیگوید، حذفش بهتر است.
- تبدیل هر داستان به دهها شرط ریز؛ داستان به مشخصات فنی تبدیل میشود و روح چابکی از آن میرود.
- نادیدهگرفتن جنبههای غیرکارکردی مثل کارایی و دسترسپذیری در مواردی که واقعاً مهماند.
- معادلگرفتن معیار پذیرش با مجموعه موارد تست؛ از معیارها تست بیرون میآید، اما نقششان تصمیم پذیرش است، نه پوشش تست.
کاربرد عملی در تیم شما
- در جلسات بهبود بکلاگ، پرسش ثابت بپرسید: «از کجا بفهمیم این داستان تمام شده؟»
- هر معیار را با فعل قابل مشاهده بنویسید: نمایش میدهد، ثبت میکند، اعلان میفرستد.
- برای هر مسیر خوش، دستکم یک مسیر خطا یا مرزی را هم معیار کنید.
- در جلسه پذیرش، معیارها را یکییکی تیک بزنید؛ مورد تأییدنشده به بکلاگ برمیگردد، نه به بحث سلیقه.
- معیارهای تکرارشونده را به الگوی تست تبدیل کنید تا دانش داستانهای قدیمی در قالب خودکار بماند.
نتیجه عملی همه این تحلیل در یک جمله است: داستان کاربر ابزار همفهمی است و معیار پذیرش ابزار داوری؛ تیمی که این دو را جدا میکند، جلسات پذیرش را از میدان بحث به فهرست تیکخوردهها تبدیل کرده است.
نکات کلیدی این مقاله
- داستان کاربر ارزش و دلیل را روایت میکند؛ معیار پذیرش مرز پذیرششدن همان داستان را تعیین میکند.
- مسیر نیاز تا داوری سه لایه دارد: نیازمندی، داستان کاربر و معیار پذیرش، و هر لایه وظیفه متفاوتی دارد.
- معیار پذیرش با تعریف انجامشده یکی نیست؛ اولی برای هر داستان است و دومی برای همه آیتمها.
- معیار خوب دودویی، کفایتمحور و پوششدهنده مسیرهای خطاست و پیش از توسعه نوشته میشود.
- قالب Given-When-Then برای منطقهای شرطی و فهرست شرطهای ساده برای قابلیتهای ساده، هر دو ابزار درستیاند.
سوالات متداول
معیارهای پذیرش را چه کسی مینویسد؟
مالک محصول مسئول نهایی پذیرش آنهاست، اما بهترین نتیجه وقتی حاصل میشود که تیم توسعه در بهبود بکلاگ مشارکت کند؛ چون تیم از منظر پیادهسازی، مرزها و حالتهای فراموششده را زودتر میبیند. نوشتن انحصاری توسط یک نفر، معمولاً به معیارهای ناقص یا ناممکن میرسد.
برای هر داستان کاربر چند معیار لازم است؟
عدد ثابتی وجود ندارد؛ آنچه مهم است کفایت شرطهاست. اگر فهرست معیارها طولانی و ریزتر شد، معمولاً نشانه آن است که داستان بزرگ است و بهتر است بشکند. چند شرط کلیدی که مسیر اصلی و مرزهای مهم را پوشش بدهد، برای بیشتر داستانها کافی است.
آیا معیار پذیرش همان تست پذیرش است؟
نه؛ معیار پذیرش شرط است و تست پذیرش اجرای راستیآزمایی همان شرط. از هر معیار ممکن است یک یا چند تست ساخته شود، اما هدف معیار، تصمیمگیری درباره پذیرش داستان است، نه پوشش کامل سناریوهای تست.
