این تعریف اتمام (DoD) یک لیست از الزامات است که داستان کاربر باید با آن مطابقت داشته باشد تا تیم بتواند آن را به عنوان کامل اعلام کند.
این معیارهای پذیرش برای داستانهای کاربر شامل مجموعهای از سناریوهای آزمایشی است که الزامات را برآورده میکند تا تأیید کند که آیا نرمافزار بهطور مورد انتظار کار میکند یا خیر.
کی داستان کاربر کامل خواهد شد؟
به عبارت دیگر، برای کامل کردن داستانهای کاربر، باید DOD و معیارهای پذیرش رعایت شوند. افزونههای محصول زمانی کامل در نظر گرفته میشوند که هر دو لیست کامل شده باشند. بنابراین، ما باید دو جنبه از تعریف DoD را تعریف کنیم — معیارهای اتمام و معیارهای پذیرش:

تعریف انجام شده
تعریف انجام شده به صورت یک لیست از موارد ساختار یافته است که هر کدام برای اعتبارسنجی یک داستان یا PBI استفاده میشود و وجود آن برای اطمینان از توافق تیم توسعه در مورد کیفیت کاری که در حال تلاش برای تولید آن هستند، ضروری است. این به عنوان یک چک لیست عمل میکند که برای بررسی هر لیست کارهای محصول مورد (که به آن PBI نیز گفته میشود) یا داستان کاربر برای کامل بودن. موارد در تعریف «انجام شده» به گونهای طراحی شدهاند که برای تمام موارد در لیست کارهای محصول قابل اجرا باشند، نه فقط یک داستان کاربر.
میتوان آن را به صورت زیر خلاصه کرد:
- این اصطلاح بیشتر به افزونه محصول به عنوان یک کل اعمال میشود
- در بیشتر موارد، این اصطلاح به این معنی است که افزونه محصول قابل ارسال است
- این اصطلاح در راهنمای اسکرام تعریف شده است
- به عنوان روشی برای ارتباط بین اعضای تیم استفاده میشود
- کیفیت کلی نرمافزار
- آیا افزونه قابل ارسال است یا خیر
مثال — تعریف انجام شده
- کد بازبینی همتا شده است؟
- کد کامل شده است؟
- کد بازبینی شده است؟
- کد چکاین شده است؟
- آزمونهای واحد قبول شدهاند؟
- آزمونهای عملکردی قبول شدهاند؟
- آزمونهای پذیرش کامل شدهاند؟
- مالک محصول بازبینی و پذیرفته شده است؟
معیارهای پذیرش
داستانهای کاربر یکی از اصلیترین توسعه مصنوعات برای توسعه چابک، اما اسکرام بهطور صریح نیاز به استفاده از داستانهای کاربر یا معیارهای پذیرش ندارد. اگر یک مورد در لیست کارهای محصول به اندازهای بزرگ در نظر گرفته شود که نتوان آن را در یک اسپرینت قرار داد، معمولاً به داستان کاربر و سپس به مجموعهای از وظایف تقسیم میشود همانطور که در شکل نشان داده شده است:

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

This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.