تفاوت DoD، DoR و Acceptance Criteria

ابتدا می‌خواستم در سه مقاله جدا این سه مفهوم رو توضیح بدم اما به نظرم اگر این سه مفهوم رو در کنار هم و با مقایسه‌ی با هم توضیح بدیم درکش خیلی ساده‌تره.

Acceptance Criteria

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

معیارهای پذیرش چطور کمک می‌کند؟

• شفاف کردن User Story برای طرفین ( مالک محصول، تیم فنی و ذینفعان)
• مبنایی برای نگارش و انجام Acceptance Testing
• کمک به Planning و Estimation دقیق‌تر
• تشریح Negative Scenarios و نحوه‌ی مواجهه سیستم با آن

انواع قالب‌های نگارش معیارهای پذیرش:

• الگوی Given/When/Then (GWT)

این الگو از فریمورک Behavior-driven development (BDD) نشات گرفته و با ارائه‌ی یک ساختار ثابت به QAها کمک می‌کند که زمان درک Use Case و Test Case را کاهش دهند زیرا رفتار سیستم از قبل توضیح داده شده است.

نمونه:

من به عنوان کاربر می‌خواهم زمانی که درخواست تسویه حساب ‌می‌کنم آنگاه درخواست تسویه من ثبت شده و یک شماره پیگیری و زمان حدودی واریز وجه به من اعلام و پیامک شود.

• الگوی چک لیست

هر چند که الگوی GWT ساختارمند و کمک کننده است بسیاری از مواقع نوشتن آن بسیار سخت، زمانبر و در مواردی نشدنی است در نتیجه استفاده از چک لیست می‌تواند بسیار کمک کننده باشد.

نمونه:

✅ محصول نهایی کاملا Responsive باشد.
✅ فیلدهایی که یک عدد از کاربر می‌گیرند با تمامی کیبوردهای انگلیسی، فارسی و عربی کار کنند اما اطلاعات به انگلیسی در دیتابیس قرار گیرد.
✅ داده‌های مربوطه به Google analytics ارسال شود.

• الگوی سفارشی

الگوهای GWT و Checklist قالب‌های مرسوم‌تری هستند اما اگر قالب بخصوصی با محصول و تیم شما سازگار است از امتحان کردن آن نترسید.

با وجود اینکه PO معمولا مسئول AC است اما از آنجایی که در نهایت برنامه‌نویس مسئول کدنویسی و (Quality Assurance (QA مسئول تست بر اساس این Acceptance criteria است بهتر است تا جای ممکن از کمک آنها هم استفاده کرد. به هر حال هر کدام زاویه نگاهی دارند که کمک می‌کند PBI کمتر دچار رفت و برگشت به تیم فنی شود. AC را می‌توان در جلسات مختص بحث در مورد داستان کاربر بعد از Sprint Planning کامل‌تر کرد.

Definition of Done

مفهوم DoD یک داکیومنت معمولا به شکل چک لیست است که مشخص می‌کند یک (PBI) Product backlog item چه زمانی تمام شده اطلاق می‌شود. DoD را می‌توان یک لیست عمومی از Acceptance Criteria ها در نظر گرفت که برای جلوگیری از تکرار و فراموشی موارد آن، آنها را در DoD قرار می‌دهیم که برای تمامی PBI ها لحاظ شود.

مفهوم Done در DoD یعنی هیچ کار دیگری برای deliver کردن داستان کاربر نیاز نیست انجام شود و کد آماده‌ی دلیور کردن است. (لازم نیست حتما دلیور شده باشد) در نتیجه اگر تیم توسعه بگوید کار تمام شده است فقط تست آن مانده است یا فقط مرج نشده است یا ... این به معنی اتمام کار نیست.

نمونه:

✅ تمامی تست‌های نرم‌افزاری مثل End to end testing (E2E testing)، Unit testing و ... پاس شده باشد.
✅ کد Refactor و Review شده باشد.
✅ کد با برنچ اصلی Integrate شده باشد.
✅ توضیح تغییرات این نسخه در Git شفاف و کامل نوشته شده باشد.
✅ Internal QA testing انجام شده باشد.
✅ در صورت امکان User Acceptance Testing (UAT) توسط Stakeholder انجام شده باشد.
✅ اگر نیار به تغییرات دیتابیسی است تغییرات آماده انجام باشد.
✅ تایید Product owner را برای رفتن به Production داشته باشد.
✅ داکیومنت‌های مورد نیاز جلسه Sprint Review (Demo) آماده شده باشد.

نکته‌ی مهم در مورد این چک لیست اینه که به مرور تکمیل می‌شه و در انواع جلسات اسکرام به خصوص Retrospective Meeting بسته به تجربه‌ و آموخته‌های تیم توسعه مواردی به این لیست اضافه یا کم می‌شه.

Definition of Ready

مفهوم DoR یک داکیومنت معمولا به شکل چک لیست است که کارهایی که باید قبل از شروع کدنویسی تیم توسعه برای یک PBI انجام شود را مشخص می‌کند. DoR به زبان ساده یک چک لیست است که مشخص می‌کند آیا یک PBI آماده شروع در اسپرینت است یا نه. DoR را به تعبیری می‌توان DoD مالک محصول در نظر گرفت به این معنی که تیم توسعه تنها زمانی یک PBI را می‌پذیرد که کار PO به طور کامل Done شده باشد و هیچ اما یا فقط ی باقی نمانده باشد.

برعکس DoD و AC مفهوم DoR در دستورالعمل اسکرام نیامده است و به مرور برخی افراد و تیم‌ها این مفهوم را به صلاحدید خود توسعه داده‌اند و برخی هم با آن زاویه دارند و مخالف اجرای آن هستند.

نمونه:

✅ تمامی Dependency های User story شناسایی و تکمیل شده باشد.
✅ تخمین حجم کار User Story به اجماع PO و Dev team رسیده باشد.
✅ User Story می‌بایست INVEST و قابل اجرا در یک اسپرینت باشد.
✅ معیار پذیرش (AC) آماده شده باشد.
✅ دیزاین صفحات نهایی شده باشد.
✅ Flow بین صفحات مشخص باشد.
✅ اگر برای Launch یا Rollback دستورالعمل، ملاحظات یا پیش‌نیاز و پس‌نیازی وجود دارد داکیومنت شده باشد.
✅ Performance Indicators های مهم برای اندازه‌گیری موفقیت این PBI مشخص و اندازه‌گیری شده باشد.
✅ سطح دسترسی Access-control list مشخص باشد.

مشابه DoD این چک لیست هم به مرور تکمیل می‌شه و در انواع جلسات اسکرام بسته به تجربه‌ و آموخته‌های تیم توسعه مواردی به این لیست اضافه یا کم می‌شه.

نکته کلیدی:

مفهوم Acceptance Criteria که به اختصار به آن AC هم می گوییم یک چک لیست منحصر به فرد برای هر آیتم بک لاگ است که قرار است وارد اسپرینت شود در حالی که DoD و DoR یک چک لیست عمومی است که بر روی تمامی آیتم‌ها بررسی می‌شود.