Acceptance Criteria | معیار پذیرش

معیار پذیرش شرایط مشخص و آزمون‌پذیری است که یک ویژگی باید داشته باشد تا کامل شمرده شود. برخلاف آرزوهای مبهم، هر معیار باید بتواند پاس یا رد شود. «فرم باید ساده باشد» معیار نیست؛ «با ورودی معتبر ارسال می‌شود و برای فیلد نامعتبر خطای سطح‌فیلد نشان می‌دهد» معیار است. این وضوح اختلاف معنای «تمام شد» بین طراحی، توسعه، محصول و ذی‌نفع را قبل از ساخت گران، ارزان حل می‌کند.

شکاف معنایی «Done» کجا درد می‌سازد

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

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

دو قالب رایج نوشتن

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

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

تفاوت با تعریف انجام‌شده

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

تیم بالغ هر دو را نگه می‌دارد و مرزشان را آموزش می‌دهد. معیار پذیرش دربارهٔ رفتار کاربر و پیامد کسب‌وکار است؛ تعریف انجام‌شده دربارهٔ استاندارد کیفیت تحویل.

چه کسی می‌نویسد و چه کسی صیقل می‌دهد

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

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

سناریوهای مثبت، منفی و لبه

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

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

اعتبارسنجی قبل از توسعه و استفاده در پذیرش

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

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

خطاهای رایج نوشتن معیار

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

درمان این‌ها بازنویسی از منظر کاربر و پیامد، نگهداری معیار به‌عنوان سند زنده در طول کشف، و تبدیل کیفیت‌های ذهنی به نشانه‌های قابل مشاهده است؛ مثلاً «پاسخ زیر دو ثانیه در شرایط شبکهٔ تعریف‌شده» به‌جای «سریع».

اثر معیار خوب روی سرعت واقعی تیم

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

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

نمونهٔ بازنویسی از مبهم به آزمون‌پذیر

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

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