تعریف کار انجام شده یا Definition Of Done

اجایل شو به شما می گوید:

 DOD لیستی است که «اطمینان» می دهد آنچه که ما در Sprint توسعه دادیم در واقع «انجام شده است» یا نه. همچنین، نشان می دهد که محصول ساخته شده هیچ "کار انجام نشده" ندارد و آماده تحویل (delivery) است. اگر تیم های اسکرام، یک محصول عملکرد مشخص برای ارائه  یا به اصطلاح بهتر  "potentially shippable product" توسعه داده باشند یا تولید کرده باشند، باید یک «تعریف برای آن کار  داشته باشند که نشان دهنده به انجام رسیدن آن باشد» یا به اصطلاح “DOD”  برای آن تعریف شده باشد و  مورد توافق همه نیز باشد.

نکته : عبارت potentially shippable product (محصول بالقوه قابل حمل) در ترجمه فارسی معنی گنگ و غیر قابل فهمی دارد اما در ادامه آن را برای شما شفاف توضیح می دهم:

  "potentially shippable product" یعنی چه ؟

در فرایند توسعه نرم‌افزار، اسکرام (Scrum) یک چارچوب مدیریت پروژه است که بر اساس اصول تعیین شده و به صورت چرخه‌های تکراری (iteration) کار می‌کند. در این چارچوب، مفهوم "Potentially Shippable Product" یا "محصول قابل ارائه به مشتری" یک مفهوم کلیدی است.

خیلی ها با فهموم Shippable Product یا ترجمه عبارت نامفهوم "محصول قابل حمل" مشکل دارند و برای آنها قابل درک نیست، اما در اجایل شو می‌خواهیم این مفهوم را برای شما روشن کنیم:

"Potentially Shippable Product" به معنای این است که تا پایان هر تکرار یا ایتریشن (سیکل کوتاه مدت توسعه یا همان اسپرینت)، محصول نهایی تا حدی آماده و کامل شده باشد که بتوان آن را به مشتری ارائه داد تا ازش استفاده کند. به عبارت دیگر، تیم توسعه در پایان هر iteration قادر به ارائه یک نسخه از محصول است که به اندازه کافی تست شده و قابل عرضه  به مشتری است.

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

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

تعریف انجام شده لیستی از انواع کارهایی است که تیم باید قبل از اینکه اعلام کند کار قابل تحویل است آنها را ارزیابی کرده و تیک آن موارد را بزند تا تسک ها با موفقیت به پایان برسد و بسته شود.

DoD ها به  متغیر هایی مانند زیر وابسته است:

ماهیت محصول در حال توسعه
فناوری هایی که برای توسعه آن استفاده می شود
فرهنگ و ساختار سازمانی که در حال ساخت محصول است
موانع موجود که بر روند توسعه  تأثیر می گذارد و ...

چند مدل DOD داریم ؟

تعریف کار انجام شده یا (DoD) در اسکرام می‌تواند متفاوت باشد، اما مهم است که مطمئن شوید که تعریف اولیه Done قبل از اولین Sprint توافق شده باشد. طبق گفته Scrum Alliance، سه نوع مختلف DoD وجود دارد که در زیر به آنها اشاره شده است.

DoD برای یک ویژگی ( یوزر استوری یا موارد عقب مانده بکلاگ محصول)
DoD برای اسپرینت (sprint)
DoD برای انتشار (release)

اعضای تیم از DoD ها به عنوان یک ابزار خوب جهت گزارش استفاده می کنند زیرا مشخص می کند که " آن ویژگی واقعا انجام شده است" یا نه.

در زیر چند نمونه از لیست «تعریف انجام شده» آمده است:

DoD برای یک ویژگی User Story یا آیتم های بکلاگ محصول:

1. توضیح کارکرد: باید وظایف و عملکرد مورد انتظار از ویژگی مشخص شده باشد.
2. تست‌پذیری: باید معیارهای کنترل و ارزیابی تست‌های لازم جهت تضمین عملکرد صحیح ویژگی ذکر شده باشد.
3. مستندسازی: هر تغییر یا اضافه‌کردن ویژگی باید مستندات مربوط به آن به‌روز شده باشد.
4. کد نویسی قابل تحویل: کد منبع باید بر اساس استانداردهای نوشته‌شدن کد و توابع متناظر با ویژگی به کار گرفته شده باشد.
5. انتقال‌پذیری: ویژگی باید به سایر بخش‌ها یا ویژگی‌ها تأثیر منفی نگذارد و با بخش‌های دیگر سیستم تعامل صحیح داشته باشد.

DoD برای اسپرینت (Sprint):

1. کامل بودن ایتریشن: تمامی ویژگی‌ها یا موارد کاری مورد برنامه‌ریزی برای این ایتریشن باید به صورت کامل پیاده‌سازی و آماده به تست باشند.
2. تست واحد: تست‌های واحد بر روی کد نوشته‌شده باید با موفقیت عبور شده باشند.
3. کارایی مناسب: کارکرد ویژگی‌ها باید با توجه به نیازهای عملیاتی به صورت مناسب و بدون مشکل اجرا شود.
4. رفع باگ‌ها: هر باگ یا خطای کد باید حل شده و کد بر طبق تغییرات انجام شده بررسی شده باشد.
5. مستندسازی ایتریشن: هر ایتریشن باید دارای مستنداتی باشد که تغییرات اعمال شده، باگ‌ها رفع شده، ویژگی‌ها اضافه شده، و سایر تغییرات ذکر شده باشند.

DoD برای انتشار (Release):

1. تست یکپارچه: تمامی اجزاء و ویژگی‌های اضافه شده باید به صورت یکپارچه تست شده و در محیط انتشار موفقیت‌آمیز باشند.
2. مستندسازی نهایی: تمامی تغییرات به صورت کامل و جامع مستند شده و مستندات نهایی همراه با نسخه انتشار دیگر بخش‌ها تحویل داده شده باشند.
3. آمادگی عملیاتی: سیستم باید به طور کامل برای عملیات آماده شده باشد و تمامی نقاط پشتیبانی و نگهداری تعریف شده باشند.
4. تست‌های نهایی: تست‌های نهایی بر روی محصول باید به صورت کامل و با موفقیت اجرا شده و نتایج آنها باید ارزیابی شده باشند.
5. رسمی‌سازی انتشار: انتشار باید به صورت رسمی اعلام و به مشتریان و سایر ذینفعان اطلاع‌رسانی شود.

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

به عنوان مثال، تست چیست؟

تست واحد  (Unit Testing) ، تست یکپارچه سازی (Integration testing) ، تست سیستم، تست پلت فرم و بسیاری از انواع تست های دیگر برای محصول مورد نیاز چیست؟ آیا همه انواع آزمایش در DOD گنجانده شده است؟

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

تیم‌های اسکرام باید این اطمینان را داشته باشند که هر چیزی که می‌سازند با بهترین کیفیت ارائه می شود و قابل حمل (Shippable) و قابل انتشار است. این یک «تعریف انجام شده» DoD قوی است.

Definition of Done  Vs  Acceptance criteria

تفاوت معیار انجام شده در مقابل معیار پذیرش 

Acceptance Criteria (معیارهای قابل قبول) و Definition of Done (تعریف کار انجام شده) هر دو مفاهیم مهم در فرایند توسعه نرم‌افزار هستند، اما هرکدام وظایف و اهداف متفاوتی را در مراحل مختلف توسعه تعیین می‌کنند.

Acceptance Criteria:

• اجرایی بودن برای مشتری: Acceptance Criteria مرتبط با یک User Story خاص است و معیارهایی است که توسط Product Owner (مالک محصول) تعریف می‌شود. این معیارها نشان‌دهندهٔ اهداف ویژگی یا موضوع کاری هستند و مشخص می‌کنند که ویژگی به درستی کار می‌کند یا خیر.
• تمرکز بر مشتری: معیارهای قابل قبول اصطلاحاً به "چرا" و "چگونه" یک ویژگی می‌پردازند و بیشتر به توضیح نیازهای مشتری متمرکز هستند.

Definition of Done (DoD):

• پایان یافتن توسعه: DoD به معنای معیارهایی است که یک وظیفه (مثل یک User Story یا یک Task) باید برآورده کند تا به عنوان "یک ویژگی قابل کار کرد" در نظر گرفته شود.
• تمرکز بر فرآیند توسعه: این مفهوم به طور کلی بیان می‌کند که یک کار توسط تیم توسعه چه چیزهایی را باید داشته باشد تا به عنوان تمام شده شناخته شود. این معیارها معمولاً بر روی ابعاد مختلف مانند تست، مستندسازی، کیفیت کد، و سایر موارد متمرکز هستند.

تفاوت اصلی:

• تمرکز بر مشتری در Acceptance Criteria و تمرکز بر فرآیند در Definition of Done: Acceptance Criteria بیشتر در راستای ارضای نیازهای مشتری تعریف می‌شوند، در حالی‌که Definition of Done بیشتر مربوط به فرآیند توسعه و کیفیت کار تیم است.

در نتیجه، Acceptance Criteria بر روی اطمینان حاصل از ارضای نیازهای مشتری تمرکز دارند، در حالی‌که Definition of Done بر روی اطمینان از اجرای صحیح و کیفیت کار تیم توسعه تأکید دارد.

در اسکرام، Acceptance Criteria به معنای معیارهای قابل قبول برای یک User Story یا یک موضوع کاری (Backlog Item) است. این معیارها توضیح می‌دهند که چگونه ویژگی یا موضوع کاری باید برای مشتری یا Product Owner قابل قبول و اجرایی باشد. Acceptance Criteria معیارهایی هستند که اگر یک User Story همگی این موارد را برآورده کند، آن User Story به عنوان "تمام شده" (Done) در نظر گرفته می‌شود.

مثال:

User Story: به عنوان یک کاربر، می‌خواهم بتوانم به صورت آنلاین فاکتورهای خود را مشاهده کنم.

Acceptance Criteria:

1. ورود به سیستم: کاربر باید قادر به ورود به سیستم با نام کاربری و رمز عبور خود باشد.
2. لیست فاکتورها: باید یک لیست از فاکتورهای مرتبط با حساب کاربری کاربر نمایش داده شود.
3. اطلاعات فاکتور: با کلیک بر روی هر فاکتور، جزئیات آن فاکتور از جمله موارد مثل مبلغ، تاریخ صدور و موارد مرتبط باید نمایش داده شود.
4. فیلتر و جستجو: باید قابلیت فیلتر و جستجو بر اساس شماره فاکتور یا تاریخ صدور وجود داشته باشد.
5. واکنش سریع: اطلاعات باید به سرعت و بدون تأخیر قابل نمایش باشند.

این معیارها به توسعه‌دهندگان و تسترها کمک می‌کنند تا بفهمند چه چیزی برای این User Story مورد انتظار است و چگونه مشتری تعریف می‌کند که ویژگی به درستی کار می‌کند.

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

بنابراین، هر عنوان از Backlog محصول دارای مجموعه مناسبی از معیارهای پذیرش است. DoD در طول Sprint به افزایش محصول که هنوز ساخته نشده است اعمال می شود. افزایش محصول چیزی نیست جز مجموعه ای از اقلام عقب مانده محصول و هر مورد عقب مانده محصول باید با چک لیست تعریف انجام شده مطابقت داشته باشد.

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

تفاوت  Done  و  Done-Done

برخی از تیم ها مفهوم "Done-Done" را در مقابل "Done" پذیرفته اند. Done-Done قرار است از برخی جهات بیشتر از Done انجام شود. تیم ها از این اصطلاح استفاده می کنند تا بیان کنند که کار انجام شده در طول اسپرینت واقعاً بطور 100% تضمین شده بصورت کامل بدون هیچ مشکلی تکمیل و انجام شده است. کار به حدی انجام می شود که مشتری می تواند از آن استفاده کند در اینجاست که می گوییم آن مورد از بکلاگ یک (محصول بالقوه قابل حمل) یا shippable product است .

تیم‌های اسکرام که از "Done-Done" برای بیان این جمله استفاده می‌کنند که «به همان اندازه که آماده بودیم کار انجام دادیم!» اما واقعیت این است که تیم‌های اسکرام که عملکرد خوبی دارند، برای نمایش عملکرد خود به این دو مفهوم نیاز ندارند. برای چنین تیم‌هایی «انجام شد»"Done" واقعاً به معنای «انجام شد»"Done" است.

اجایل شو پیشنهاد می کند مطلب مرتبط با داستان کاربر user story را نیز بخوانید.

مترجم و نویسنده: علی امینی