DoR (Definition of Ready)
در توسعه نرمافزار با متودولوژی Agile، قبل از این که یک آیتم بکلاگ محصول (Product Backlog Item یا PBI) بتونه برای توسعه انتخاب بشه باید شاخص هایی رو رعایت کنه که این دسته از شاخص ها رو با اسم Definition of Ready یا به اختصار DoR میشناسیم. DoR ابزار مفیدیه برای اطمینان از اینکه یک PBI به خوبی درک شده، اندازه مشخص و درست داره و میتونه به طور موثر پیاده سازی شه. در واقع هدف از ارائه مفهوم DoR رسیدن به یک درک مشترک از «آماده» بودن یک PBI برای شروع فرآیند اجراست.
تو این مقاله مفاهیم DoR رو بررسی میکنیم و به اهمیت اون تو متودولوژی Agile میپردازیم.
مفهوم DoR شامل چه مواردی میشود؟
معمولا مواردی که برای تعریف شاخص های DoR در نظر گرفته میشه شامل از این دسته هاست:
- ملاک پذیرش: یه PBI باید معیارهای پذیرش مختصر، واضح و قابل اندازهگیری داشته باشه. در این صورت میشه تا حد خوبی موارد مورد نیاز برای توسعه اون رو تخمین زد.
- تخمین اندازه: با تخمین اندازه یک PBI میشه از به اندازه کافی کوچک بودنش برای قرار گرفتن توی اسپرینت مطمئن شد.
- وابستگی: قبل از انتخاب یه PBI برای توسعه، باید وابستگی های اون PBI، به PBI ها یا تیم های دیگه مشخص و برطرف بشه.
- داستان کاربر (user story): یه PBI باید به صورت یک داستان از زبان کاربر نقل شه تا مشخص بشیم چه ارزشی برای کاربر خلق میکنه.
- اولویت: PBI ها باید با توجه به ارزش تجاری و فوریت اجرا اولویت بندی بشن.
چرا تعریف و اجرای DoR مهمه؟
با تعیین شاخص های DoR برای یک تیم، میتونیم تضمین کنیم که اون تیم درک مشترکی از آماده بودن یک PBI برای شروع فرآیند توسعه داره. این درک مشترک علاوه بر کم کردن درگیریها، مشکلات و تأخیرهای معمول در فرآیند توسعه، به تیم کمک میکنه که فرآیند توسعه کارآمدتر و موثرتری داشته باشه. با درک درست اندازه یک PBI تیم میتونه به شکل درستتری برای اون برنامه ریزی کنه، مدیریت حجم کاری تیم بهتر انجام میشه و در نتیجه تیم به تعهدات خودش بهتر عمل میکنه.
یکی از مهمترین عوامل ایجاد تأخیر در فرآیند توسعه، وابستگی ها هستن. با شناسایی و حل وابستگی ها قبل از شروع توسعه، تیم میتونه از تأخیرهایی که ممکنه در طول توسعه رخ بده، جلوگیری کنه تا وظایف تیم هم در طول اسپرینت کامل انجام بشه.
مثالی از شاخص های DoR
در ادامه یکی از معروف ترین دسته از شاخص های DoR رو معرفی میکنیم که به شاخص INVEST هم معروفه:
- عدم وابستگی (Independent): یک PBI باید خودکفا باشه. یعنی بدون هیچگونه وابستگی به بخش دیگهای بتونه به مرحله توسعه برسه.
- قابل مذاکره (Negotiable): نحوه پیاده سازی یک PBI باید قابل بحث باشه تا بشه بهینهترش کرد.
- ارزشمندی (Valuable): تقریبا مهمترین اولویت برای یک PBI ارزشمندی اون برای مشتریها و سرمایهگذارهاست.
- قابل تخمین (Estimable): اندازه و حجم کار یه PBI باید قابل تخمین باشه تا بشه براش برنامهریزی کرد.
- کوچک (Small): یک PBI باید به قدری کوچک باشه که بشه تخمین خوبی برای مدت زمان و حجم کار مورد نیازش زد. معمولا هرچه PBI ها بزرگتر باشن، تخمینی که براشون در نظر گرفته میشه دقت کمتری داره!
- قابلیت تست (Testable): برای هر PBI باید یک سری معیارهای پذیرش (Acceptance Criteria) تعریف بشه که بعد از انجامش توسط همون معیارها بتونیم کیفیت اون رو بسنجیم.
نتیجه گیری
قرارداد کردن یک سری موارد و شاخص ها با عنوان تعریف آماده بودن برای یک PBI علاوه بر سنجیدن ارزش پیاده سازی، با یکسان کردن درک کل تیم از اون PBI کمک میکنه درک درست تری از وظایف و کارهای لازم برای توسعه داشته باشیم و با برنامه ریزی درستتر و دقیقتر میتونیم تیم منظمتر و کارآمد تری بسازیم.
مطلبی دیگر از این انتشارات
React Query: Data Magic
مطلبی دیگر از این انتشارات
مدیریت زمان، چرا و چگونه؟
مطلبی دیگر از این انتشارات
بررسی الگوریتم مرتب سازی Selection Sort