«این کار تمومه!» جایی است که بحث شروع میشود، نه تمام. توسعهدهنده میگوید کد آماده است، اما هنوز تست نشده، مرور نشده و مستند نشده است. نتیجه، کارهایی است که «تمامشده» نامیده میشوند اما واقعاً قابل تحویل نیستند و بعداً مثل بومرنگ برمیگردند — با بهره و هزینهٔ بسیار بالاتر.
این ابهام فقط یک بحث زبانی نیست؛ یک خطای سیستمی است. وقتی هر کس در ذهن خودش تعریف متفاوتی از «انجام شد» دارد، برنامهریزی، گزارش پیشرفت و حتی اعتماد ذینفعان به تیم، همگی روی شن روان بنا شدهاند.
راهحل، یک تعریف مشترک و روشن از «انجام شدن» است: Definition of Done. در این مقاله میبینید DoD چیست، تعریف دقیق آن در Scrum چیست، چه فرقی با معیار پذیرش دارد، چطور برای تیم خودتان بسازید و چه اشتباههایی آن را بیاثر میکند.
Definition of Done چیست؟ (پاسخ سریع)
Definition of Done (تعریف انجامشدن) توصیف رسمی و مشترک از وضعیتی است که یک آیتم وقتی به معیارهای کیفی لازم رسید باید داشته باشد. به بیان ساده، یک چکلیست توافقشده است که مشخص میکند یک کار چه زمانی واقعاً «تمامشده» حساب میشود.
تعریف دقیق بر اساس راهنمای Scrum
در راهنمای Scrum، Definition of Done جایگاه مشخص و مهمی دارد:
- توصیف رسمی از وضعیت Increment: DoD مشخص میکند که افزایش (Increment) محصول چه زمانی به معیارهای کیفی لازم رسیده است.
- لحظهٔ تولد Increment: بهمحض اینکه یک آیتم بکلاگ محصول، DoD را برآورده کند، یک Increment متولد میشود.
- ایجاد شفافیت: DoD به همه میگوید «انجامشده» دقیقاً یعنی چه.
- استاندارد سازمانی: اگر سازمان برای همهٔ تیمها یک حداقل DoD تعریف کرده باشد، همهٔ تیمهای Scrum باید دستکم آن را رعایت کنند.
- تعهد تیم توسعه: تیم توسعه باید به این تعریف پایبند باشد و کار ناقص را «انجامشده» اعلام نکند.
نکتهٔ کلیدی: DoD یک «قرارداد کیفیت» است که قبل از شروع کار روشن میکند معیار تحویل چیست، نه یک چکلیست تشریفاتی که در پایان کار تیک میخورد.
همین امروز به دوایتیفای بپیوندید
پروژهها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفتها و گزارشهای تیم در یک محیط یکپارچه. ساختهشده برای شرکتها، استارتاپها و تیمهای دورکار — با راهاندازی چنددقیقهای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
تفاوت DoD و Acceptance Criteria
این دو مفهوم مرتبط اما متفاوتاند و نباید اشتباه شوند:
| معیار | Acceptance Criteria | Definition of Done |
|---|---|---|
| دامنه | مخصوص یک داستان کاربر | عمومی برای همهٔ کارها |
| سؤال | این کار درست است؟ | این کار «تمام» است؟ |
| مثال | «گزارش باید فیلتر تاریخ داشته باشد» | «تست شده، مرور شده، مستند شده» |
| سطح جزئیات | مشخص به یک قابلیت | کلی و قابل اعمال به همه |
به بیان ساده: معیار پذیرش میگوید کار «درست» ساخته شده؛ DoD میگوید کار «کامل» تحویل شده است. یک کار میتواند معیار پذیرشش را برآورده کند اما هنوز DoD را نه (مثلاً کد کار میکند اما تست نشده).
نمونهٔ چکلیست DoD برای تیم Scrum
یک DoD معمولی میتواند این موارد را داشته باشد:
- کد نوشته و با استانداردهای تیم هماهنگ است.
- تستهای واحد نوشته و همه سبز است.
- توسط یک عضو دیگر تیم مرور (Code Review) شده است.
- روی محیط تست استقرار یافته و بررسی شده است.
- مستندات لازم بهروز شده است.
- هیچ باگ بحرانی باز ندارد.
- معیار پذیرش داستان برآورده شده است.
- بهروزرسانی در ابزار مدیریت کار ثبت شده است.
این چکلیست باید متناسب با تیم و محصول شما تنظیم شود؛ نمونهٔ بالا فقط نقطهٔ شروع است. برای یک تیم تولید محتوا، DoD ممکن است شامل «ویرایش نهایی و انتشار و لینکسازی» باشد؛ برای یک تیم سختافزار، «تست ایمنی و تأیید نهایی».
چرا DoD مهم است؟
- شفافیت: همهٔ تیم و ذینفعان از قبل میدانند «تمامشده» یعنی چه.
- کیفیت: کار نیمهکاره نمیتواند از سد چکلیست عبور کند.
- تخمین دقیقتر: وقتی DoD روشن باشد، اندازهٔ واقعی کار بهتر برآورد میشود.
- کاهش دوبارهکاری: کارهایی که واقعاً کامل میشوند، کمتر برمیگردند.
- گزارش پیشرفت صادقانه: بدون DoD، «انجامشده» عددی گمراهکننده است.
مثال عددی ۱: هزینهٔ کارِ بدون DoD
تیمی بدون DoD، قابلیت «ورود کاربر» را تمامشده اعلام میکند چون کدش کار میکند. اما تست نشده، روی محیط اصلی نیست و مستند نشده. یک هفته بعد، باگی از همان قابلیت پیدا میشود. فرض کنید رفع آن باگ ۲ روز کاری و جابجایی تیم ۴ نفره هزینه داشته باشد؛ یعنی حدود ۸ نفرروز تلفشده که با یک DoD ساده — «تستشده و مرورشده و مستقر» — از ابتدا قابل پیشگیری بود.
مثال عددی ۲: تخمین ناقص بدون DoD
اگر DoD شامل «تست و مستندسازی» نباشد، تیم برای تخمین یک داستان فقط زمان کدنویسی را در نظر میگیرد — مثلاً ۵ Story Point. اما در عمل، تست و مستندسازی ۲ واحد دیگر زمان میبرد. نتیجه: سرعت واقعی تیم کمتر از چیزی که برآورد شده ظاهر میشود و برنامهریزی اسپرینت مدام از واقعیت عقب میماند. با DoD کامل، تخمین از ابتدا واقعبینانه میشود.
مثال عددی ۳: گزارش پیشرفت گمراهکننده
فرض کنید در یک اسپرینت، تیم ۱۰ داستان را «انجامشده» علامت میزند، اما ۶ تای آنها هنوز تست نشدهاند. گزارش اسپرینت میگوید «۱۰۰٪ کامل»، اما واقعیت این است که فقط ۴ داستان قابل تحویلاند. ذینفعان بر اساس عدد اشتباه برنامهریزی میکنند و در اسپرینت بعد، نیمی از ظرفیت تیم صرف تکمیل همان ۶ کار «انجامشده» میشود. DoD این تحریف را از ریشه حذف میکند.
چطور یک DoD خوب بسازیم؟
- با مشارکت کل تیم بسازید: تیمی که خودش تعریف را ساخته، به آن متعهد میماند.
- کوتاه و قابل بررسی نگه دارید: هر مورد باید با «بله/خیر» قابل پاسخ باشد.
- از حداقل شروع کنید و تدریجی سختگیرانهترش کنید: با بلوغ تیم، کیفیت هم باید بالا برود.
- به چکلیست تسک وصل کنید: تا هنگام بستن کار، قابل بررسی باشد.
- در رترو مرورش کنید: DoD کهنه میتواند جلوی بهبود را بگیرد.
مزایا و Trade-off تعریف DoD
مزایا:
- شفافیت و همزبانشدن تیم دربارهٔ «انجامشده».
- کیفیت بالاتر و دوبارهکاری کمتر.
- تخمین و گزارش پیشرفت دقیقتر.
Trade-off و محدودیتها:
- DoD خیلی سختگیرانه میتواند سرعت تحویل را کم کند و تیم را فرسوده کند.
- DoD خیلی سبک، ارزشش را از دست میدهد.
- نیاز به بازبینی دورهای دارد؛ DoD کهنه میتواند جلوی بهبود را بگیرد.
- برای تیمهای خیلی کوچک یا کارهای غیررسمی، ممکن است سربار اداری اضافه ایجاد کند.
اشتباهات رایج
- نداشتن DoD: تعریف «انجام شد» در ذهن هر کس متفاوت است.
- DoD غیرواقعی و حجیم: چکلیستی که هیچکس نمیتواند تکمیل کند، بیاثر میشود.
- DoD ثابت و کهنه: DoD باید با رشد تیم و محصول تکامل یابد.
- خلط با معیار پذیرش: این دو جای یکدیگر را نمیگیرند؛ هر دو لازماند.
- DoD فقط در کاغذ: تعریف نوشتهشده اما در لحظهٔ بستن کار رعایت نمیشود.
- تحمیل از بالا بدون مشارکت تیم: DoDای که تیم در ساختش نقشی نداشته، بهسختی پذیرفته میشود.
جدول: نشانههای یک DoD خوب در برابر DoD ضعیف
| نشانه | DoD خوب | DoD ضعیف |
|---|---|---|
| طول | کوتاه و قابل بررسی | بلند و غیرقابل انجام |
| منشأ | توافق تیم | تحمیل از بالا |
| تکامل | در رترو بازبینی میشود | سالها دستنخورده |
| اجرا | به چکلیست تسک وصل است | فقط در سند نوشته شده |
| نتیجه | کار ناقص بسته نمیشود | «انجام شد» غیرواقعی |
نکات کاربردی
- نکته مهم: DoD را با مشارکت کل تیم بسازید؛ تیمی که خودش تعریف را ساخته، به آن متعهد میماند.
- ترفند کاربردی: DoD را کوتاه و قابل بررسی نگه دارید؛ هر مورد باید با «بله/خیر» قابل پاسخ باشد.
- ترفند کاربردی دوم: DoD را در رترو مرور و بهتدریج سختگیرانهتر کنید؛ با بلوغ تیم، کیفیت هم باید بالا برود.
- اشتباه رایج: علامتزدن «انجام شد» قبل از تکمیل چکلیست؛ ابزار باید این را یادآوری کند.
- قبل از شروع این را بدانید: DoD را در ابزار مدیریت کار به چکلیست تسک وصل کنید تا هنگام بستن کار، قابل بررسی باشد.
DoD در برابر Definition of Ready
این دو تعریف را نباید اشتباه گرفت. Definition of Ready شرایطی است که یک آیتم باید قبل از ورود به اسپرینت داشته باشد — یعنی «این کار آمادهٔ شروع است؟». Definition of Done شرایطی است که برای «تمامشدن» باید برآورده شود — یعنی «این کار قابل تحویل است؟».
یک داستان خوب تعریفشده، هم Ready است (ورودی پاک دارد) و هم پس از کار، Done میشود (خروجی پاک دارد). این دو مثل دو دروازه در ابتدا و انتهای هر آیتم کار میکنند.
نمونهٔ DoD برای تیمهای غیرنرمافزاری
DoD فقط برای تیمهای برنامهنویسی نیست. چند نمونه از حوزههای دیگر:
- تیم تولید محتوا: متن نوشته، ویرایش و بازبینی شده، تصویر و Alt آن آماده است، در سیستم انتشار بارگذاری شده و لینکسازی انجام شده است.
- تیم طراحی: فایل نهایی تأیید شده، نسخهٔ وب و موبایل آماده است، فایل منبع در مخزن مشترک ذخیره شده و به تیم اجرا تحویل شده است.
- تیم پشتیبانی: پاسخ به مشتری ارسال شده، سند راهنما بهروز شده و اگر تکرار شود، یک تسک بهبود ثبت شده است.
در همهٔ اینها یک اصل مشترک است: «تمامشده» یعنی قابل تحویل به مرحلهٔ بعد، نه فقط «کار خودم را کردم».
چطور DoD را با بلوغ تیم تکامل دهیم؟
DoD نباید یکبار برای همیشه نوشته شود. یک مسیر طبیعی تکامل:
- شروع: موارد پایه — «کد نوشته و توسط خودم تست شده».
- بلوغ اولیه: افزودن «مرور توسط همتیمی» و «استقرار روی محیط تست».
- بلوغ بالا: افزودن «تست خودکار»، «پوشش تست مشخص» و «نظارت پس از انتشار».
قاعدهٔ طلایی: هر بار که تیم در رترو یک مشکل کیفیت را پیدا میکند، بپرسید «کدام مادهٔ DoD میتوانست جلوی این را بگیرد؟» و همان را اضافه کنید. به این ترتیب DoD بهجای یک سند ثابت، به «حافظهٔ کیفیت» تیم تبدیل میشود.
مثال عددی چهارم: اثر DoD بر دوبارهکاری اسپرینت
تیمی در سه اسپرینت پیاپی بدون DoD سختگیرانه کار میکند. در هر اسپرینت از ۲۰ آیتمِ «انجامشده»، بهطور میانگین ۶ آیتم برمیگردد چون تست یا مرورشان کامل نبوده است. یعنی ۳۰٪ ظرفیت اسپرینت بعد صرف دوبارهکاری میشود. بعد از معرفی DoD کامل (تست + مرور + استقرار)، این نرخ به حدود ۱۰٪ میرسد. بهعبارتدیگر، از هر ۲۰ کار، فقط ۲ کار برمیگردد — و تیم عملاً ۴ آیتم ظرفیت خالص در هر اسپرینت به دست میآورد، بدون اینکه حتی یک ساعت بیشتر کار کند.
دوایتفای و Definition of Done
DoD وقتی اثر واقعی دارد که هنگام بستن هر کار قابل بررسی باشد. در دوایتفای میتوانید DoD را بهصورت چکلیست در هر تسک ثبت کنید، وضعیتهای QC و کنترل کیفیت را تعریف کنید و مطمئن شوید هیچ کاری بدون برآوردهشدن چکلیست «انجام شد» نمیشود؛ به این ترتیب تعریف «تمامشده» فقط روی کاغذ نمیماند و در عمل اجرا میشود.
سوالات متداول
جمعبندی
Definition of Done، تعریف مشترک «تمام شدن» است که جلوی کارهای نیمهکارهٔ «انجامشده» را میگیرد. آن را با مشارکت تیم بسازید، کوتاه و قابل بررسی نگه دارید، در رترو تکاملش دهید و به چکلیست تسکها در ابزار مدیریت کار وصل کنید. با یک DoD روشن، دیگر هیچکس دربارهٔ «تمومه؟» بحث نمیکند و گزارش پیشرفتتان بالاخره صادق است.
اگر موضوع Definition of Done برایتان مفید بود، پیشنهاد میکنیم عوامل حیاتی موفقیت (CSF) و مدیریت پروژه های فناوری اطلاعات را هم بخوانید.
همین امروز به دوایتیفای بپیوندید
پروژهها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفتها و گزارشهای تیم در یک محیط یکپارچه. ساختهشده برای شرکتها، استارتاپها و تیمهای دورکار — با راهاندازی چنددقیقهای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
