Definition of Done یا تعریف انجام شده | مفهومی حیاتی در اجایل

آیا وقتی می‌گوییم «تمام‌ شده است» یعنی واقعاً آن کار به‌طور کامل تمام شده است؟ در چارچوب اجایل که محصول نهایی نه در جعبه‌ای فیزیکی تحویل داده می‌شود و نه پایانی قطعی برای آن وجود دارد، رسیدن به توافق درباره «تعریف انجام شده» یا Definition of Done بسیار حیاتی است.

وقتی تیم‌ها زبان مشترکی برای پایان کار ندارند، سردرگمی، دوباره‌کاری و خروجی‌های ناقص قطعاً اجتناب‌ناپذیر است.

در این مقاله، قدم‌به‌قدم به شما نشان می‌دهیم که DoD چیست و چطور یک تعریف شفاف، کاربردی و مشترک از آن بسازید، تا دیگر کارهای نیمه‌تمام را با خیال راحت «تمام‌شده» صدا نزنید.

تعریف انجام شده یا DoD چیست؟

Definition of Done یا «تعریف انجام شده» که به DoD هم معروف است، یک توافق واضح و مشترک در تیم‌های اجایل و روش اسکرام است.

این تعریف می‌خواهد فراتر از جملاتی مثل «فلان کد را نوشتیم» یا «این بخش روی سیستم من کار می‌کند» باشد. DoD یک چک‌لیست رسمی از معیارهای کیفیت و تکمیل بودن است که هر آیتم از بک لاگ محصول باید برای اینکه «انجام شده» محسوب شوند از آن چک لیست تبعیت کنند.

به طور کلی یک Definition of Done مناسب معمولاً شامل موارد زیر است:

• کد نوشته شده و توسط دیگر اعضا بازبینی شده باشد

• تست های واحد و یکپارچه‌سازی با موفقیت انجام شده باشد

• عملکرد کار خروجی توسط تیم تضمین کیفیت / QA تأیید شده باشد

• فیچر موردنظر در محیط Staging یا آزمایشی مستقر شده باشد

• مستندات کاربر یا یادداشت‌های انتشار به‌روزرسانی شده باشد

• مالک محصول آیتم‌ها را بررسی و تأیید کرده باشد

تفاوت DoD با DoR و AC

شاید الان که متوجه شدید DoD چیست، به نظر برایتان آشنا آمده باشد و احساس کنید این تعریف شباهت زیادی به یکی دیگر از تعاریف اجایل یعنی معیارهای پذیرش / Acceptance Criteria دارد؛ درست است؛ شباهت وجود دارد، اما DoD کلاً با AC تفاوت دارد.

معیارهای پذیرش مربوط به یوزر استوری‌ها هستند و نیازهای عملکردی را تعریف می‌کنند (مثلاً «این فیچر چه کاری باید انجام دهد تا مورد پذیرش ذی‌نفعان قرار گیرد و واقعاً برای محصول سودمند باشد؟»).

همچنین تعریف دیگری نیز وجود دارد به نام «تعریف آماده» یا Definition of Ready که مشخص می‌کند چه زمانی یک آیتم بک‌لاگ آماده شروع‌شدن توسط تیم است.

پس اگر بخواهیم ساده بگوییم:

• Acceptance Criteria یعنی این داستان چه کاری باید برای محصول و مشتری انجام دهد.

• Definition of Ready یعنی چه زمانی می‌توانیم یک آیتم را شروع کنیم.

• Definition of Done یعنی یک کار چه زمانی واقعاً تمام شده است.

اما قبل از اینکه نمونه‌های مختلف از DoD را بررسی کنیم، ببینیم...

چرا Definition of Done مهم است؟

وقتی که در یک تیم توسعه و محصول درک مشترکی از معنای «انجام شده» وجود نداشته باشد، کارهایی که تیم تحویل می‌دهد همواره دارای این ریسک است که یا ناتمام باشند، دقیق نباشند یا دارای مشکلات پنهان باشند. DoD برای همین است که با ارائه‌ یک استاندارد شفاف و درون تیمی، این مشکل را برطرف می‌کند و باعث شفافیت، هماهنگی و پاسخ‌گویی افراد نسبت به خروجی کارها باشد.

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

یک تعریف انجام شده قوی، یک دروازه به کنترل کیفیت باز می‌کند؛ به این معنا که هیچ بخش افزوده‌ای / Increment بدون عبور از حداقل استانداردهای کیفیت به مرحله بعدی نمی‌رود.

این کار در طول زمان بدهی فنی / Technical Debt تیم را به‌شدت کم می‌کند، چون هیچ چیز ناتمامی به آینده موکول نمی‌شود و «سورپرایزهای آخر اسپرینت» یا قبل از انتشار محصول تقریباً حذف می‌شوند.

نحوه اجرای DoD در انواع بخش‌های رایج یک محصول

تعریف انجام شده باید به‌اندازه‌ای دقیق و شفاف باشد که کیفیت کار را تضمین کند و در عین حال آن‌قدر واقع‌بینانه باشد که تیم بتواند به‌طور مداوم آن را رعایت کند. هرچند ممکن است بسته به نوع محصول، سطح بلوغ تیم و زمینه کاری، شرایط کمی متفاوت باشند، اما می‌خواهیم متداول‌ترین اجزایی را که در یک DoD کامل وجود دارند برای شما شرح دهیم:

DoD برای یک یوزر استوری یا آیتم بک لاگ

در سطح یوزر استوری، انجام شده به این معناست که آیتم توسعه‌یافته تمامی معیارهای فنی و پذیرش را برآورده کرده و آماده ارائه به ذی‌نفعان است. این سطح از انجام‌شدگی روی کیفیت کد، تست‌پذیری، تطابق با نیازهای کاربر و آمادگی برای بازبینی‌های بعدی تمرکز دارد.

استوری‌ای که «Done» تلقی شود، باید توسط تیم توسعه بازبینی، تست و تأیید شده باشد و امکان استقرار آزمایشی آن وجود داشته باشد.

• کد نوشته شده، توسط یک هم‌تیمی بازبینی شده و در شاخه اصلی ادغام شده است.

• تست‌های واحد / Unit Tests نوشته شده و با موفقیت اجرا شده‌اند.

• تست‌های عملکردی یا تست‌های پذیرش انجام شده‌اند.

• کد با موفقیت یکپارچه‌سازی و بیلد شده است.

• قابلیت در محیط آزمایشی یا Staging تست شده است.

• هیچ باگ مهمی باقی نمانده است.

• مالک محصول قابلیت را بررسی و تأیید کرده است.

• دستورالعمل‌های طراحی رابط کاربری/تجربه کاربری رعایت شده‌اند (در صورت وجود).

• مستندات مورد نیاز برای کاربران به‌روزرسانی شده‌اند (در صورت نیاز).

DoD برای یک اینکریمنت اسپرینت

در انتهای هر اسپرینت، مجموع خروجی‌های آماده‌شده به‌صورت یک افزوده / Increment ارائه می‌شود. در این سطح، «Done» یعنی تمامی آیتم‌های تکمیل‌شده در اسپرینت، مطابق با Definition of Done خود عمل کرده‌اند، محصول قابل‌استفاده است و قابلیت دمو کردن و انتشار دارد. یک اینکریمنت واقعی باید کاملاً یکپارچه، تست‌شده و مستند شده باشد.

• تمام آیتم‌ها تعریف انجام شده در سطح داستان را رعایت کرده‌اند.

• تست‌های رگرسیون با موفقیت انجام شده‌اند.

• افزوده یکپارچه‌سازی شده و «قابل‌عرضه» است.

• دمو برای جلسه بازبینی اسپرینت آماده است.

• هرگونه تغییر در زیرساخت یا پیکربندی مستند شده است.

DoD برای یک ریلیز (در صورت تعریف جداگانه)

در سطح ریلیز یا انتشار، «انجام شده» به معنای آمادگی کامل برای استقرار در محیط عملیاتی و استفاده توسط کاربران نهایی است. این سطح نیازمند بررسی‌های دقیق امنیتی، مستندسازی جامع، آماده‌سازی زیرساخت‌های پشتیبانی و برنامه‌ریزی برای بازگشت به نسخه‌های قبل / Rollback است. تمرکز در این مرحله بر روی پایداری و آمادگی برای ارائه نهایی محصول به بازار یا کاربر است.

• یادداشت‌های انتشار / Release Notes نوشته و بررسی شده‌اند.

• بررسی‌های امنیتی یا معیارهای تطابق قانونی انجام شده‌اند.

• فیچر در محیط عملیاتی مستقر شده یا آماده استقرار است.

• سامانه‌های مانیتورینگ و هشداردهی تنظیم شده‌اند (برای سیستم‌های لایو).

• برنامه Rollback آماده شده است (در صورت نیاز).

DoD برای یک فیچر

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

• معیارهای پذیرش برای بخش ضروری از استوری‌ها رعایت شده‌اند.

• در یک بیلد (نسخه کامپایل شده) پایدار و بدون خطا ادغام شده است به محیط بالاتر (مانند UAT یا پیش‌تولید) ارتقا یافته است.

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

• تست‌های عملکردی در سطح فیچر کامل شده‌اند.

• الزامات غیرعملکردی (مانند بازدهی، مقیاس‌پذیری) برآورده شده‌اند.

• استانداردهای قانونی، امنیتی و انطباق رعایت شده‌اند.

• مستندات کاربردی برای کاربران نهایی به‌روز شده‌اند.

DoD برای یک اپیک

یک اپیک معمولاً به یک هدف راهبردی بزرگ یا یک نیاز اساسی بازار در سطح سازمانی مرتبط است. در این سطح، «انجام شده» الزاماً به معنای کامل‌شدن تمام استوری‌ها یا فیچرها نیست، بلکه یعنی ارزش مورد انتظار از اپیک حاصل شده است.

• الزامات غیرعملکردی (در کل فیچرها) بررسی و تأیید شده‌اند.

• یکپارچگی کامل از ابتدا تا انتها بررسی و تأیید شده است.

• تست‌های رگرسیون در مقیاس کامل انجام شده‌اند.

• به محیط تولید ارتقا یافته یا آماده استقرار در تولید است.

• انتظارات مشخص بازار یا مشتری را برآورده کرده است.

• در گزارش‌دهی‌ها به نتایج راهبردی حاصل شده اشاره شده است.

قدم‌های ساخت یک DoD

مسلماً جزئیات ساخت یک DoD بسته به تیم و پروژه متفاوت است، اما فرایند کلی معمولاً چیزی شبیه به الگوی زیر است:

1. با یک تیم مناسب همکاری کنید

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

بنابراین، افرادی را دخیل کنید که نظر آن‌ها برای تعریف انجام شده اهمیت دارد:

هر عضو تیم با دانشی که از حوزه کاری خود دارد، می‌تواند به تعریف معیارهای مناسب برای آن حوزه کمک کند. اگر افراد اشتباهی در این فرایند حضور داشته باشند یا افراد کلیدی نادیده گرفته شوند، DoD نهایی ناقص یا بی‌کیفیت می‌شود.

2. معیارها را تعیین کنید

شاید مهم‌ترین بخش، مشخص‌کردن معیارهای ارزیابی باشد. این معیارها باید به‌صورت مشخص، قابل‌اندازه‌گیری، قابل‌دستیابی، مرتبط و محدود به زمان (SMART) باشند.

برای مثال:

به‌جای گفتن «تمام کدها تست شده‌اند»، بگویید: «تمام کدها از طریق تست‌های واحد، یکپارچه و End-to-End بررسی شده‌اند.»

به‌جای گفتن «مستندات آماده است»، بگویید: «تمام مستندات به‌روز شده‌اند و کاربران نهایی به‌راحتی می‌توانند راهنمای استفاده را پیدا کنند.»

3. یک چک لیست بسازید

هرچند ممکن است DoD بیشتر به پروژه‌های بزرگ مربوط شود، اما تیم‌هایی که روی تسک‌های کوچک یا باگ‌ها کار می‌کنند نیز می‌توانند از همین اصول استفاده کرده و چک‌لیست ساده‌تری برای بررسی تکمیل بودن کارهای خود تهیه کنند.

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

4. معیارهای پذیرش را به یوزر استوری‌ها اختصاص دهید

معیارهای پذیرش یا Acceptance Criteria به شرایطی گفته می‌شود که یک یوزر استوری باید داشته باشد تا از نظر مشتری قابل‌قبول باشد. این معیارها با DoD متفاوت هستند؛ زیرا به سطح داستان‌ها یا ویژگی‌های خاص مربوط می‌شوند، نه به اینکریمنت محصول.

مثلاً برای استوری زیر:

«به‌عنوان یک کاربر، می‌خواهم بتوانم محصول مورد نظرم را از طریق فیلد جستجو پیدا کنم.»

معیارهای پذیرش ممکن است شامل موارد زیر باشند:

• فیلد جستجو در نوار ابزار بالای صفحه قرار دارد.

• پس از کلیک روی دکمه «جستجو»، عملیات جستجو شروع می‌شود.

• متن خاکستری پیش‌فرض در فیلد جستجو نوشته شده: «دنبال چی می‌گردی؟»

5. DoD ها را بازنگری و به‌روزرسانی کنید

DoD یک سند ثابت نیست. هر باگ یا خطایی که در طول اسپرینت یافت شود، احتمال دارد نتیجه تعریف ناقص یک DoD باشد. بنابراین DoD ها باید به‌صورت منظم به‌روزرسانی شوند تا از تکرار یک خطا جلوگیری شود.

بازنگری DoD را در جلسات Sprint Review انجام دهید و فرصت‌هایی برای پیشنهاد برخی تغییرات در طول جلسه Refinement نیز فراهم کنید.

در نهایت

با هم دیدیم که وقتی می‌گفتیم کاری «تمام شده»، واقعاً تمام نشده بود! در دنیای اجایل، «تمام شده» باید معنای دقیقی داشته باشد. وقتی تیم‌ها درک یکسانی از «تعریف تمام شده» یا Definition of Done نداشته باشند، پروژه‌ها پر از سردرگمی و دوباره‌کاری می‌شود. در این مطلب گفتیم که DoD چیست و چطور یک تعریف شفاف و کاربردی بسازیم که هیچ کار نیمه‌تمامی را «تمام‌شده» صدا نزنیم.