اکسپتنس کریتریا ( Acceptance Criteria ) یا معیارهای پذیرش

هنگامی که در حال ساختن یا توسعه یک محصول هستید، چه محصول شما نرم افزار باشد یا یک کمپین بازاریابی یا چیز دیگری، چگونه متوجه می شوید که آنچه ساخته اید انتظارات مشتری شما را برآورده می کند؟

معیار پذیرش ( Acceptance Criteria ): شرایط لازم برای پذیرش کاری که انجام داده‌اید توسط مشتری، مالک محصول یا ذینفعان مورد نیاز است.

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

ویژگی معیارهای پذیرش مؤثر چیست؟

معیارهای پذیرش باید قابل آزمایش باشند (Testable) : از آنجایی که این الزامات به مهندسان شما کمک می کند، باید آزمایش آنها آسان باشد. و نتایج این آزمایشات نباید جایی برای تفسیر باقی بگذارد. آزمایش‌ها باید نتایج مستقیم بله/خیر یا قبولی/عدم شکست را نشان دهند.

معیارها باید واضح و مختصر باشند (Clear & Concise) : شما در اینجا اسناد جامع نمی نویسید. معیارهای خود را تا حد امکان ساده و سرراست نگه دارید.

همه باید معیارهای پذیرش شما را درک کنند (Everyone must understand) : اگر توسعه دهندگان شما نتوانند معیارهای شما را درک کنند، معیارهای شما بی فایده است. اگر در مورد واضح بودن چیزی مطمئن نیستید، زمانی را برای سوال کردن و انجام تنظیمات اختصاص دهید تا زمانی که همه چیز روشن شود.

معیارهای پذیرش باید دیدگاه کاربر را ارائه دهد (Provide user perspective) : معیارهای پذیرش وسیله ای برای بررسی مشکل از دیدگاه مشتری است و باید در زمینه تجربه یک کاربر واقعی نوشته شود.

معیارهای پذیرش بر "چگونه" به یک راه حل می رسیم و یا "چگونه" چیزی ساخته شده است تمرکز نمی کنند. در عوض، آن‌ها «چیزی» از کاری را که انجام می‌دهید، روشن می‌کنند. به عنوان مثال، معیارها ممکن است اینگونه باشد: کاربران می توانند در هنگام تسویه حساب با Google Pay یا Apple Pay پرداخت کنند. روحیه معیارهای پذیرش این نیست که به شما بگوید چگونه این کار را انجام دهید.
به عنوان مثال:
*یک پلاگین وردپرس را نصب کنید که به شما امکان می دهد یک صفحه پرداخت ایجاد کنید.
* یا HTML بنویسید که امکان پرداخت با Apple Pay یا Google Pay را فراهم کند.

این اظهارات به نحوه انجام کار می پردازد نه شرایط پذیرش کار.

تفاوت بین معیار پذیرش و داستان کاربر چیست؟

برای بسیاری از تیم‌های اسکرام، یک داستان کاربر ( User story ) کوچک‌ترین بخش کار در توسعه محصول است که معمولاً بر روی یک آیتم از بک لاگ محصول بیان می‌شود. تیم شما ممکن است از چیزی غیر از داستانهای کاربر برای تعریف مشکل یا هدف کاربر استفاده کند، و شما مجبور نیستید از داستان های کاربر برای نوشتن معیار پذیرش استفاده کنید. معیار پذیرش با داستان کاربر یکسان نیست. در عوض، آنها مکمل یکدیگر هستند. داستان کاربر شرح مختصری از نیازهای مشتری شما است که از دیدگاه آنها نوشته شده است. هدف یا مشکل آنها را که در تلاش برای حل آن هستند توضیح می دهد. معیار پذیرش این است که برای حل مشکل یا رسیدن به هدف چه باید کرد. به این ترتیب، داستان کاربر «چرایی» کار را توصیف می‌کند، در حالی که معیارهای پذیرش «چگونگی» را توصیف می‌کنند.

چه کسی باید معیار پذیرش را بنویسد؟

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

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

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

• گفتگو با مشتریان یا کاربران
• گفتگو با ذینفعان
• در طول اصلاح اسکرام
• در طول برنامه ریزی اسکرام اسپرینت
• در طول فعالیت های مدیریت بک لاگ محصول
• در طوفان فکری تیمی
• پس از ارزیابی بازخورد مشتری یا کاربر نهایی

چه زمانی باید معیار پذیرش را بنویسید؟

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

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

نحوه نوشتن معیارهای پذیرش

هیچ راه درست یا غلط واحدی برای نوشتن معیارهای پذیرش برای داستان کاربر وجود ندارد. در نهایت، شما باید قالب و روشی را برای ایجاد معیارهای پذیرش ایجاد کنید که به طور مداوم برای تیم شما کار کند. اگر در این زمینه تازه کار هستید، کمی منتظر آزمون و خطا باشید. اکثر سازمان ها از یکی از دو فرمت برای معیارهای پذیرش خود استفاده می کنند:

1. معیارهای پذیرش Given/When/Then

سبک Given/When/Then الزامات داستان کاربر مشابه قالب بندی سنتی برای خود داستان های کاربر است. داستان کاربر استاندارد از این الگو پیروی می کند: "به عنوان یک (کاربر مورد نظر)، من می خواهم (عملی که قصد دارم)، به طوری که (هدف/نتیجه اقدام)." معیارهای پذیرش کاربر در قالب Given/When/Then از این الگو پیروی می کند: «سناریو: (سناریو را توضیح دهید). با توجه به (چگونه کارها شروع می شوند)، زمانی که (اقدام انجام شده)، سپس (نتیجه اقدام).

2. معیارهای پذیرش Verification List

قالب بندی نیازهای داستان کاربری خود به عنوان یک چک لیست یکی دیگر از گزینه های قابل اجرا است. همچنین بسیار ساده است. شما به سادگی به عنوان یک تیم کار می کنید تا لیستی از عبارات pass/fail را تعریف کنید که عملکرد باید مطابق با آن باشد تا کامل علامت گذاری شود.در پایان روز، قالب معیارهای پذیرش شما به اندازه عملی بودن آن مهم نیست. اگر تیم شما آن را درک کند و بتواند از آن استفاده کند، موفق شده‌اید معیارهای پذیرش مؤثری را ایجاد کنید. فرقی نمی کند که فرمت به چه شکل باشد.

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

ممنونم از زمانی که برای خواندن این مقاله گذاشتید.

منابع:

https://resources.scrumalliance.org/Article/need-know-acceptance-criteria

https://www.productplan.com/glossary/acceptance-criteria/

https://www.businessanalysisexperts.com/writing-acceptance-criteria-agile-user-story/