فرض کنید جلسه برنامهریزی اسپرینت (Sprint Planning) است و یک داستان کاربر (User Story) درباره «افزودن کد تخفیف به سبد خرید» روی میز همه است. تحلیلگر میگوید این کار از هفته پیش توضیح داده شده و باید همین حالا وارد اسپرینت شود؛ یکی از توسعهدهندهها یادآوری میکند که هنوز هیچکس نگفته این کد روی کدام گروه از محصولات اعمال میشود و سناریوی ترکیب چند تخفیف چه بایدهایی دارد. چند دقیقه بعد بحث عوض میشود: عضو دیگری از تیم میپرسد وقتی این قابلیت «تمام» شود، یعنی دقیقاً چه؟ تست خودکار لازم است یا دستی کافی است؟ مستندات کاربر هم بخشی از کار است یا نه؟
این دو پرسش ظاهراً ساده، دو مفهوم بنیادین تیمهای چابک را به هم گره میزنند: تعریف آمادهبودن (Definition of Ready) برای ورودی کار و تعریف انجامشدگی (Definition of Done) برای خروجی آن. هر دو نوعی «قرارداد کیفیت» میان اعضای تیماند، اما در دو جهت مخالف کار میکنند؛ یکی تصمیم میگیرد چه چیزی اجازه ورود به چرخه کار را پیدا کند و دیگری تصمیم میگیرد چه چیزی اجازه خروج از آن را. در این مقاله این دو مفهوم را از هم جدا میکنیم، تفاوتهایشان را در جدولی فشرده میبینیم و با یک مثال پیاده میشویم.
دو دروازه کیفیت در دو سر جریان کار
در چارچوب اسکرام (Scrum) آیتمهای بکلاگ (Backlog) مسیری یکطرفه را طی میکنند: انتخاب در برنامهریزی، ساخت در اسپرینت (Sprint) و تحویل در پایان آن. Definition of Ready دروازه ورودی این مسیر است و Definition of Done دروازه خروجی آن. اگر اولی را جدی نگیریم، تیم در میانه کار با داستانهای مبهم و ناقص دستوپنجه نرم میکند و اگر دومی را جدی نگیریم، کارهای نیمهتمام با برچسب «تمام» تحویل کاربر میشوند.
Definition of Ready؛ چه زمانی یک کار شروعشدنی است؟
تعریف آمادهبودن مجموعه معیارهایی است که تیم برای آنها توافق کرده تا بگوید یک آیتم بکلاگ کافی روشن، کوچک و قابل تخمین است و میتواند وارد اسپرینت شود. معیارهای رایج اینها هستند: ارزش کار برای کاربر و کسبوکار بیان شده باشد، معیارهای پذیرش (Acceptance Criteria) نوشته شده باشد، وابستگیها مشخص باشند و اندازه کار در ظرفیت یک اسپرینت جا شود.
نکته مهم این است که Ready یک وضعیت مطلق نیست؛ قراردادی محلی میان همین تیم است. آیتمی که برای تیم باتجربهای «آماده» حساب میشود، ممکن است برای تیم تازهکار به جزئیات بیشتری نیاز داشته باشد. به همین دلیل این تعریف را نباید از تیمی به تیم دیگر کپی کرد.
Definition of Done؛ چه زمانی یک کار واقعاً تمام است؟
تعریف انجامشدگی فهرست مشترکی از شروط کیفیت است که به همه آیتمهای کار یکسان اعمال میشود: کد بازبینیشده در فرایند بازبینی کد (Code Review)، تستهای لازم پاسشده، ادغامشده با شاخه اصلی، بدون نقص شناختهشده و در صورت نیاز مستندسازیشده. وقتی کسی میگوید «این کار تمام شد»، در واقع ادعا میکند همه این شروط برقرارند، نه فقط اینکه کد نوشته شده است.
وجه تمایز مهم DoD با معیارهای پذیرش اینجاست: معیارهای پذیرش از داستانی به داستان دیگر عوض میشوند، اما DoD ثابت است و به کل محصول نگاه میکند. معیار پذیرش میگوید «کاربر باید تخفیف را در مبلغ نهایی سفارش ببیند»؛ DoD میگوید «هیچ کدی بدون تست و بازبینی به شاخه اصلی راه پیدا نمیکند».
تفاوت بنیادی: زمان اعمال، جهت نگاه و مالکیت
دو تعریف را میتوان از سه زاویه از هم جدا کرد. زاویه اول زمان اعمال است: Ready پیش از شروع کار بررسی میشود و مانع ورود کار مبهم به اسپرینت میگردد؛ Done در پایان کار بررسی میشود و مانع خروج کار ناقص به دست کاربر است. زاویه دوم جهت نگاه است: Ready کیفیت ورودی فرایند را میسازد و Done کیفیت خروجی آن را.
زاویه سوم مالکیت است: مسئول اصلی آماده نگهداشتن آیتمها، مالک محصول (Product Owner) است که با کمک صاحبان دانش، سؤالهای بیپاسخ را پیش از برنامهریزی میبندد؛ اما تعریف انجامشدگی حاصل توافق کل تیم توسعه است و به همه آیتمها یکسان اعمال میشود. به همین دلیل نمیتوان برای آیتمی خاص، Done را سادهتر کرد؛ تنها چیزی که در این حالت واقعاً میشود این است که آن آیتم هنوز تمام نشده است.
جدول مقایسه در یک نگاه
| معیار | Definition of Ready | Definition of Done |
|---|---|---|
| زمان اعمال | پیش از ورود آیتم به اسپرینت | پیش از اعلام پایان کار و تحویل |
| هدف اصلی | پیشگیری از شروع کار مبهم و ناقص | پیشگیری از تحویل کار نیمهتمام و بیکیفیت |
| جهت نگاه | ورودی فرایند توسعه | خروجی فرایند توسعه |
| مسئول اصلی | مالک محصول و صاحبان دانش | کل تیم توسعه |
| دامنه | از داستانی به داستان دیگر کمی متغیر | یکسان برای همه آیتمهای محصول |
| ارتباط با کیفیت | کیفیت نیازمندی و شفافیت | کیفیت محصول نهایی |
| پیامد نقض | توقف در میانه کار و اتلاف ظرفیت اسپرینت | بدهی فنی، خطا در محیط عملیاتی و اعتماد ازدسترفته |
پیوند این دو دروازه را هم نباید نادیده گرفت: هرچه تعریف آمادهبودن دقیقتر باشد، رسیدن به تعریف انجامشدگی کمدردتر میشود؛ چون بخش عمده سؤالهای تیم پیش از شروع کار پاسخ گرفته است.
مثال کاربردی: قابلیت کد تخفیف در فروشگاه اینترنتی
فرض کنید تیم اجایل (Agile) یک محصول دیجیتال، فروشگاه اینترنتی متوسطی را توسعه میدهد و مالک محصول، قابلیت «کد تخفیف» را به بکلاگ اضافه میکند. در جلسه پالایش بکلاگ (Backlog Refinement)، تیم این آیتم را با چکلیست Ready میسنجد و میبیند سناریوی ترکیب تخفیف با فروش ویژه تعریف نشده است. مالک محصول این بخش را پیش از برنامهریزی تکمیل میکند و آیتم با معیارهای پذیرش روشن وارد اسپرینت بعدی میشود.
دو هفته بعد، توسعهدهندهای مدعی است کار تمام است و کارت را از ستون «در حال انجام» خارج میکند. اما در بررسی نهایی مشخص میشود تست خودکار برای حالت انقضای کد نوشته نشده و این حالت در DoD تیم جزو شروط است. کار به عقب برمیگردد و یک روز دیگر طول میکشد؛ هزینه این بازگشت کوچک است، اما همین سازوکار است که از تحویل قابلیتی بیتست به هزاران کاربر جلوگیری میکند.
خطاهای رایج در استفاده از دو تعریف
- تبدیل Ready به سد بوروکراتیک: وقتی چکلیست آمادهبودن دهها بند داشته باشد، پالایش بکلاگ به جلسه فرمنویسی تبدیل میشود و سرعت تیم پایین میآید. یک تعریف آمادهبودن سالم معمولاً چند بند کوتاه دارد.
- کپیکردن DoD از تیم دیگر: شروط کیفیت به پلتفرم، ریسک محصول و الزامات سازمان وابستهاند؛ فهرستی که برای تیمی متناسب است، ممکن است برای تیم دیگری یا سنگین باشد یا فاصلههای مهمی داشته باشد.
- جابهجاکردن خط Done برای آیتمهای عجولانه: وقتی زمان کم میآید، وسوسه میشویم تست را «بعداً انجام میدهیم» و کار را تمامشده اعلام کنیم. هر بار که این اتفاق بیفتد، اعتبار کل قرارداد تیمی زیر سؤال میرود و مرز «تمامشده» کمکم بیمعنا میشود.
- اشتباهگرفتن معیار پذیرش با DoD: معیارهای پذیرش مخصوص هر داستاناند و رفتار قابلیت را مشخص میکنند؛ افزودن آنها به DoD یا برعکس، هر دو را بیاثر میکند.
کاربرد عملی: چگونه دو قرارداد خود را بنویسیم؟
برای شروع، در یک کارگاه کوتاه از اعضای تیم بپرسید آخرین بار چه چیزی باعث شد کار نیمهکاره رها شود یا با تأخیر به عقب برگردد؛ پاسخها مواد خام Ready و Done شما هستند. فهرست را کوتاه نگه دارید، هر بند را با فعل قابلبررسی بنویسید و اجازه دهید خودِ تیم مالک متن باشد، نه فرایندی که از بیرون تحمیل شده است.
سپس این دو تعریف را زنده نگه دارید: در جلسه بازنگری (Retrospective) هر چند اسپرینت یکبار بپرسید کدام بندها واقعاً بررسی میشوند و کدام فقط روی کاغذ ماندهاند. اگر معیاری مدام نقض میشود، یا واقعبینانهاش کنید یا حذفش کنید؛ قراردادی که همه میدانند اجرا نمیشود، بدتر از نبود قرارداد است.
نکات کلیدی این مقاله
- Definition of Ready دروازه ورود کار به اسپرینت است و Definition of Done دروازه خروج آن؛ اولی کیفیت نیازمندی را میسازد و دومی کیفیت محصول را.
- هر دو «قرارداد تیمی» هستند و باید کوتاه، قابلبررسی و متناسب با همان تیم نوشته شوند، نه کپیشده از الگوی دیگران.
- معیارهای پذیرش مخصوص هر داستان کاربر است و نباید با DoD یکسان فرض شود؛ یکی رفتار قابلیت را تعریف میکند و دیگری شروط فرایندی همه کارها را.
- نقض مکرر هر کدام از دو تعریف نشانه مشکل جدیتری است: یا در برنامهریزی یا در تعهد به کیفیت؛ هر دو باید در جلسه بازنگری دیده شوند.
سوالات متداول
آیا Definition of Ready در راهنمای رسمی اسکرام الزامی است؟
خیر؛ راهنمای اسکرام این مفهوم را الزامی نمیکند و در عمل یک توافق تیمی محسوب میشود. بسیاری از تیمهای باتجربه بهجای چکلیست سنگین، به همین توافقهای کوتاه اتکا میکنند تا انعطاف چارچوب اسکرام از بین نرود.
میتوان Ready را برای کارهای اکتشافی کنار گذاشت؟
برای کارهای اکتشافی و آزمایشی معمولاً معیارهای سبکتری تعریف میشود؛ چون هدفشان پاسخگرفتن به یک سؤال است، نه تحویل قابلیت. اما حتی در این حالت بهتر است تیم بداند چه خروجی مشخصی از آن کار انتظار دارد تا اسپرینت به بازهای باز و بدون پایان تبدیل نشود.
اگر تیمی DoD نداشته باشد چه اتفاقی میافتد؟
هر عضو تیم معنای شخصی خودش از «تمامشده» را به کار میبرد و نتیجه، محصولی پر از کارهای نیمهتمام میشود: کد بیتست، مستندات جاافتاده و خطاهایی که در محیط عملیاتی خودشان را نشان میدهند. نبود DoD یعنی حذف تعریف کیفیت نیست؛ یعنی انتخاب یک تعریف نانوشته و غیرقابلبحث.
