«انجام شد» اگر تعریف مشترک نداشته باشد، وضعیت نیست؛ برداشت شخصی است. یک نفر پایان را تحویل پیشنویس میداند و دیگری انتشار، کنترل کیفیت و ثبت مستندات را. Definition of Done یا DoD در Scrum استاندارد کیفیت مشترکی است که شفاف میکند چه زمانی یک Increment واقعاً قابل استفاده و قابل بازرسی است.
Definition of Done در Scrum دقیقاً چیست؟
در راهنمای رسمی Scrum، DoD توصیف رسمی وضعیت Increment پس از برآوردهشدن معیارهای کیفیت محصول است. وقتی یک Product Backlog Item با DoD سازگار شود، بخشی از Increment به وجود میآید. کاری که DoD را برآورده نکرده نمیتواند بهعنوان Increment در Sprint Review ارائه یا منتشر شود.
DoD چه مسئلهای را حل میکند؟
- برداشت مشترک از حداقل کیفیت میسازد.
- کار پنهانِ تست، بازبینی، یکپارچهسازی یا مستندسازی را آشکار میکند.
- شمارش کار ناقص بهعنوان خروجی را کاهش میدهد.
- برآورد ظرفیت را به کل مسیر تحویل نزدیکتر میکند.
- بازبینی و بهبود استاندارد کیفیت را ممکن میسازد.
DoD کیفیت را «تضمین» نمیکند؛ استانداردی قابل بررسی برای آن میسازد.
تفاوت DoD و معیار پذیرش
DoD حداقل کیفیت مشترکی است که به Increment و کارهای مربوط اعمال میشود؛ مانند یکپارچهشدن، عبور کنترلهای لازم و آمادهبودن برای استفاده. معیار پذیرش شرایط خاص همان آیتم را توصیف میکند؛ مثلاً کاربر بتواند با ایمیل معتبر رمز را بازیابی کند. یک آیتم برای Done بودن باید هم معیارهای خاص خود و هم DoD مرتبط را برآورده کند.
DoD با چکلیست اجرای وظیفه یکی نیست
چکلیست میتواند مراحل پیشنهادی انجام کار را بگوید؛ DoD وضعیت و کیفیت خروجی را میسنجد. «جلسه برگزار شد» یا «سه ساعت کار شد» بهتنهایی معیار Done نیست، مگر اینکه خودِ رویداد خروجی مورد انتظار باشد. معیار را تا حد ممکن بر چیزی بنویسید که بتوان دید یا آزمود.
DoD با معیار انتشار فرق دارد
در Scrum، Increment میتواند پیش از پایان Sprint تحویل شود و Sprint Review دروازه انتشار نیست. سازمان ممکن است علاوه بر DoD، کنترلهای انتشار یا عملیاتی جدا داشته باشد. اگر یک الزام همیشه برای قابل استفاده بودن محصول لازم است، پنهانکردن آن بعد از «Done» شفافیت را کم میکند؛ جای درست آن را با تیم و استاندارد سازمان تعیین کنید.
از مسیر واقعی تحویل شروع کنید
- یک آیتم اخیراً تحویلشده را انتخاب کنید.
- همه کارهای لازم تا قابل استفادهشدن آن را فهرست کنید.
- الزامهای سازمانی، امنیتی، حقوقی و فنی را جدا کنید.
- موارد مشترک همه آیتمها را از معیارهای خاص همان آیتم تفکیک کنید.
- حداقل استانداردی را انتخاب کنید که تیم واقعاً میتواند هر بار اجرا کند.
یک معیار خوب چگونه نوشته میشود؟
معیار باید روشن، دودویی یا قابل اثبات و مرتبط با کیفیت/قابلیت استفاده باشد. «کیفیت خوب است» مبهم است؛ «بازبینی همتا ثبت شده و آزمونهای توافقشده عبور کردهاند» قابل بررسیتر است. مالک شواهد و محل ثبت آن را مشخص کنید، اما DoD را به سند طولانی غیرقابل اجرا تبدیل نکنید.
نمونه برای تیم نرمافزار
- تغییر در شاخه اصلی یکپارچه شده است.
- آزمونهای توافقشده عبور کردهاند و خطای بحرانی باز وجود ندارد.
- بازبینی کد یا تغییر طبق سیاست تیم ثبت شده است.
- مستندات کاربر/عملیات در صورت اثرپذیری بهروز شدهاند.
- تغییر در محیط هدف قابل استقرار یا استفاده است.
- الزامهای امنیت، حریم خصوصی و دسترسپذیری مرتبط بررسی شدهاند.
این فقط نمونه است؛ درصد پوشش، سطح خطا و کنترل لازم باید از محصول، ریسک و استاندارد سازمان بیاید.
نمونه برای تیم محتوا
- هدف، مخاطب و منبع ادعاهای حساس روشناند.
- ویرایش زبانی و بازبینی تخصصی لازم انجام شده است.
- لینکها، عنوان، توضیح و تصویر بررسی شدهاند.
- مجوز دارایی و اطلاعات شخصی کنترل شدهاند.
- نسخه نهایی در محل انتشار/تحویل ثبت شده است.
در تیم غیرScrum بهتر است این را «چکلیست کیفیت مشترک» بنامید تا واژه رسمی DoD را بدون چارچوب آن مبهم نکنید.
استاندارد سازمانی و چند تیم
اگر سازمان استاندارد DoD دارد، تیم باید حداقل آن را رعایت کند و میتواند معیارهای سختگیرانهتری اضافه کند. اگر چند Scrum Team روی یک محصول کار میکنند، باید DoD مشترکی داشته باشند که Increment یکپارچه را قابل فهم کند. معیارهای متناقض، وضعیت محصول را غیرشفاف میکنند.
DoD را در برنامهریزی ظرفیت وارد کنید
زمان تست، بازبینی، مستندسازی و یکپارچهسازی بخشی از کار است. اگر تیم فقط زمان ساخت اولیه را برنامهریزی کند، آیتمها در پایان صف میکشند. از مرز پروژه، عملیات و اقدام برای مشخصکردن مسئولیتهای تکراری و تحویل استفاده کنید.
اگر معیار برآورده نشد چه کنیم؟
وضعیت را Done نکنید. بخش باقیمانده را پنهان یا به «بعداً» منتقل نکنید مگر تصمیم و ریسک آن شفاف باشد و وضعیت همچنان ناتمام بماند. برای رخداد استثنایی، صاحب اختیار باید تصمیم را ثبت کند؛ استثنا نباید تعریف را بیمعنا سازد.
DoD را چگونه رشد دهیم؟
از حداقل قابل اجرا شروع کنید و در بازبینی دورهای، خطاهای فراری، دوبارهکاری و تغییر استاندارد سازمان را بررسی کنید. افزودن معیار باید همراه با ظرفیت یا اتوماسیون لازم باشد. حذف معیار نیز باید با شواهد و ارزیابی ریسک انجام شود. مرور را میتوان کنار بازبینی سیستم وظایف قرار داد.
خطاهای رایج
- نوشتن معیارهای مبهم مانند «با کیفیت» یا «کامل»
- مخلوطکردن معیار خاص آیتم با استاندارد مشترک
- افزودن فهرستی که تیم در هر Increment توان اجرای آن را ندارد
- Done کردن کار با تست، بازبینی یا مستنداتِ وعدهدادهشده برای بعد
- استفاده از DoD برای کنترل فرد، نه شفافیت محصول
منابع مرجع
راهنمای رسمی Scrum ۲۰۲۰ DoD را تعهد مربوط به Increment و معیار رسمی کیفیت آن تعریف میکند و تکلیف استاندارد سازمانی/چندتیمی را توضیح میدهد. واژهنامه Agile Alliance مزایا و دامهایی مانند وسواس در فهرست و نیاز به معیارهای خاص هر آیتم را جمعبندی میکند. برای اجرای رسمی Scrum، متن Scrum Guide مرجع اصلی است.
جمعبندی
Definition of Done یک قرارداد کیفیت مشترک برای Increment است، نه مترادف «کار کردم» یا فهرست معیار خاص هر آیتم. مسیر واقعی تحویل و استاندارد سازمان را بررسی، معیارهای قابل اثبات بنویسید، کل کار لازم را در ظرفیت ببینید و وضعیت ناتمام را صادقانه نگه دارید.
سؤالات متداول
چه کسی DoD را تعیین میکند؟
اگر استاندارد سازمانی وجود دارد، حداقل را تعیین میکند؛ در غیر این صورت Scrum Team متناسب با محصول آن را میسازد. چند تیم روی یک محصول باید تعریف مشترک داشته باشند.
آیا Product Owner کار را Done اعلام میکند؟
Done بودن از انطباق Increment با DoD میآید، نه صرفاً تأیید یک فرد. Product Owner درباره ارزش و Product Backlog مسئولیت دارد.
آیا DoD باید برای همه آیتمها یکسان باشد؟
استاندارد مشترک بر Increment اعمال میشود؛ هر آیتم میتواند معیار پذیرش خاص دیگری نیز داشته باشد.
آیا میتوان DoD را تغییر داد؟
بله، با رشد تیم و استانداردها میتواند سختگیرانهتر یا دقیقتر شود. تغییر باید شفاف، قابل اجرا و مبتنی بر ریسک/یادگیری باشد.
اگر تیم Scrum نیست، استفاده از DoD اشتباه است؟
میتوان اصلِ معیار کیفیت مشترک را بهکار برد، اما بهتر است نام و دامنه را روشن کنید و ادعا نکنید صرف داشتن این چکلیست یعنی تیم Scrum اجرا میکند.
