DoR یا Definition Of Ready چیست؟

در اجایل شو به شما خواهیم گفت DoR یا همان Definition Of Ready  یعنی چه و چه تفاوتی با DoD دارد.

همان طور که میدانید، در اسکرام مجموعه‌ای از توافق‌نامه‌هایی وجود دارد که به شما اطلاع می‌دهد که یک داستان کاربر (User Story) واقعاً انجام شده است، و تمام فعالیت‌های ضروری کامل شده‌اند یا نه، که از آن تحت عنوان Done نام می بردیم. اما تعریف Ready مفهوم بسیار متفاوتی است. در واقع تعریف Ready مجموعه ای از توافقات است که به شما می گوید چه زمانی یک کار(Task) برای شروع آماده است. به طور دقیق تر، "اگر بگوییم شرایط و موارد لازم برای شروع چیزی خوب و کافی است".

 برای مثال، DoR مواردی هست که با وجود آنها یا رعایت آنها می گوییم یک داستان کاربر (User Story) آماده است تا وارد یک اسپرینت شود، یا زمانی که همه شرایط برای شروع یک اسپرینت (Sprint) در تیم مناسب است.

یک «Ready» ساده می تواند به شکل زیر باشد :

در واقع  Ready مرتبط با داستان کاربر (User Story) است که لزوماً  دو موارد زیر را باید داشته باشد:

- یک روایت شفاف داشته باشد
- مواردی از معیار  پذیرش (Acceptance criteria) داشته باشد

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

چرا باید Definition Of Ready داشته باشیم ؟

"تعریف آماده" (Definition of Ready) مربوط به داستان کاربر (User Story) است، جایی که داستان کاربر (User Story) آماده است که به یک اسپرینت (زمان محدودی که تیم برای توسعه و ارائه ویژگی‌های نرم‌افزار دارد) برده شود. نیازی به این نیست که "100٪ تعریف شده" باشد صرفا تمامی شرایط پذیرش را پوشش دهد. با این حال، باید "به اندازه کافی آماده باشد"،یعنی فقط زمانی که تیم اطمینان حاصل کند که می‌تواند داستان کاربر (User Story) را با موفقیت ارائه دهد.

در واقع، "تعریف آماده" به تیم کمک می‌کند تا مطمئن شود داستان کاربر (User Story) به حد کافی آماده و مشخص شده است تا بتواند به اسپرینت اضافه شود و تیم بتواند آن را با موفقیت انجام دهد. این به معنای این است که داستان کاربر (User Story) به اندازه کافی واضح و قابل اجرا باشد و تیم مطمئن باشد که می‌تواند آن را به خوبی پیاده‌سازی کند.

اگر هر داستان کاربر با تعریف آماده قبل از جلسه برنامه ریزی اسپرینت مطابقت داشته باشد، به صرفه جویی در زمان کمک خواهد کرد. اما کار بر روی داستان کاربر در طول جلسه برنامه ریزی اسپرینت (sprint planning) و رساندن آن به وضعیت " آماده (Ready) " نیز خوب و قابل قبول است.

چگونه یک Definition Of Ready بنویسیم ؟

تعریف آماده(Definition of Ready) کمک زیادی به یک User Story خوب می کند. همچنین بسیار مرتبط با مفهومی است که قبلاً در فصل داستان های کاربر User Stories در مورد آن بحث کرده ایم.

در ادامه اجایل شو یک متد کاربردی برای نوشتن یک Ready و استوری خوب معرفی می کند که نشان می دهد چه ویژگی هایی باید داشته باشد :

متد INVEST

I - مستقل باشد (Independent)

N - قابل مذاکره باشد (Negotiable)

V - با ارزش باشد (Valuable)

E - قابل تخمین باشد (Estimable)

S - کوچک باشد (Small)

T - قابل آزمایش باشد (Testable)

یک تیم وقتی User Story هایی را که با این معیارها مطابقت نداشته باشد به عقب می اندازد. در حالی که این معیارها برای "آماده" بودن یک User Story ضروری هستند، اما به تنهایی ممکن است کافی نباشند. بنابراین چندین عامل دیگر نیز باید در نظر گرفته شود درست مانند DoR.

درواقع هر تیم تعریف خود را از Ready خواهد داشت. این تا حد زیادی به اعضا تیم و زمینه فعالیت آنها بستگی دارد.

مثال زیر میتواند تصویر واضحی از یک DoR در ذهن شما بوجود بیاورد:

داستان باید دقیقاً در قالب «داستان کاربر User Story » نوشته شود.
معیارهای پذیرش باید توسط تیم درک شود.
یک تیم باید بتواند داستان را تخمین بزند.
تیم باید نحوه ارائه نسخه نمایشی از ویژگی ها را بداند.
معیارهای عملکرد باید توسط تیم درک شود.

موارد فوق، به تیم توسعه در درک اطلاعات مورد نیاز برای یک داستان خاص کمک می کند. همچنین فرصتی برای به چالش کشیدن مالک محصول(PO)  است تا در غیاب آن فرایند توسعه برای تیم امکان پذیر باشد.

مراحل توسعه "تعریف آماده" (Definition of Ready)

تعریف آماده (DoR) نباید ثابت باقی بماند. بلکه باید با تکامل تیم از نظر رشد و توسعه رشد کند.

سرعت کار
درک و فهم از اینکه "چه چیزی" یک داستان کاربر خوب را می سازد.
شما می توانید همان اطلاعات را از طریق جلسات backlog grooming و برنامه ریزی بک لاگ (backlog planning)  تهیه کنید. همچنین تعریف آماده(DoR) از طریق بررسی در جلسات گذشته نگر (sprint retrospectives) بهبود پیدا کرده و به روز خواهد شد.

نمونه هایی از تعریف آماده (Definition of Ready):

در این بخش، دو نمونه جداگانه از Definition of Ready را نشان خواهیم داد. این به شما کمک می کند تا با توجه به الزامات، یک تعریف مناسب از Ready ایجاد کنید.

DOR برای یک  user story:
- داستان کاربر به خوبی تعریف شده باشد
- معیارهای پذیرش(Acceptance criteria) داستان کاربر تعریف شده باشد
- اندازه داستان کاربر توسط تیم تحویل قابل فهم و قابل تخمین باشد 
- تیم اسکرام مصنوعات تجربه کاربری را پذیرفته باشد
- معیارهای عملکرد مشخص باشد
- شخصی که داستان کاربر را می پذیرد مشخص شده باشد
- یک تیم قادر باشد داستان کاربر را "دمو" کند.

DOR برای یک  Sprint :
 

بکلاگ اسپرینت اولویت بندی شده باشد

نقص‌ها، داستان‌های کاربر(user stories) و سایر کارهایی که تیم متعهد به انجام آن شده است، در بک لاگ اسپرینت موجود باشد
هیچ  کار پنهانی باقی نمانده باشد
همه اعضای تیم ظرفیت فردی خود را برای اسپرینت محاسبه کرده باشند
            تمام وقت در پروژه = X ساعت در روز.

همه داستان های کاربران با DoR مطابقت داشته باشند.

مالک محصول می توانند از Definition of Ready به عنوان راهنما در هنگام آماده شدن داستان های کاربر برای اسپرینت های آتی استفاده کند. یک تیم، از DoR به عنوان یک چک لیست استفاده می کند تا مطمئن شود که شانس موفقیت بیشتری در ارائه داستان کاربر تکمیل شده وجود دارد یا خیر، و اینکه قبل از شروع به ارائه داستان کاربر، به اندازه کافی درباره ساختن داستان کاربر هم اندیشی شده است !؟

 بنابراین ، Definition of Ready تمرکز را در جلسات grooming و دیگر فعالیت‌های برنامه‌ریزی آینده بازمی‌گرداند.

در آخر تعریف Ready برای به حداقل رساندن کار های تکراری (Rework) در داستان کاربر (user stories) کمک می کند.
 

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

ترجمه: علی امینی