DoD (Definition of Done)
مقدمه
این اولین مقاله من توی ویرگوله و قصد دارم براتون از Definition of Done یا به فارسی تحت الفظی "مفهوم انجام شدن" بگم. این مفهوم بیشتر در دنیای توسعه نرمافزار و از نوع چابک معنی میده و مختصرا میشه اینطوری تعریفش کرد:
تعریف
مجموعهای از ضابطهها، معیارها و استانداردهایی که در توسعه یه محصول باید رعایت بشه تا بشه اون رو عرضه کرد.
بیاید با بررسی یه مشکل بهتر به مفهمومش پی ببریم!
مشکل
زمانی رو تصور کنید که تو یه تیم توسعه نرمافزار، مثلا در نقش یه توسعه دهنده فرانتاند (Front-End)، مشغول هستید و قراره یه ویژگی (Feature) جدید به محصولتون اضافه کنید. انجام این کار به دو نفر محول شده تا به صورت همزمان انجامش بدن و یکی از اون افراد شمایید.
هم تیمی شما صرفا براش مهمه که ویژگی خواسته شده رو توسعه بده و بدون هیچ گونه تستی به محصول اضافش کنه، در واقع رسیدن سر وقت ویژگی رو مهمتر از بررسی فنیش میدونه. اما شما برخلاف همکارتون تمایل دارید که نتنها تستهای فنی بلکه تستهایی فراتر روی چیزی که توسعه دادید انجام بشه. قاعدتا کار شما بیشتر طول میکشه و نتیجه باکیفیتتری هم داره. اینجا دقیقا میشه گفت که مفهوم انجام شدن برای شما و همکارتون به گونههای متفاوتی تعریف شدن!
حالا چه مشکلاتی ممکنه به وجود بیاد؟
زمان انجام کارها: اولین مشکل عدم تطابق زمانی برای انجام یه تسکه. با توجه به این که هر یک از شما دو نفر تسک مشابه رو در زمانهای متفاوتی توسعه دادید، تخمین زمان انجام شدن تسکها رو در ادامه برای سایرین دشوار میکنید.
شفافیت و نتیجه: شما و همکارتون با دو برخورد متفاوت تسک رو انجام دادید، اما هیچ قانونی مشخص نکرده که کدوم برخورد با توجه به شرایط محصول مناسب تره! در نتیجه هیچکدوم از شما نمیدونید که دقیقا چی ازتون خواسته شده و چی باید تحویل بدید!
راه حل
در چنین شرایطی، نیازمند یه استاندارد برای انجام شدن کارها هستیم. این استاندارد باید مشخصا به شما بگه که با توجه به شرایط فعلی محصول یا پروژه، آیا تست کردن لازمه؟ در صورت لزوم، این تستها در چه سطحی باید باشن؟ در چه صورتی شما میتونید بگید که این تسک به درستی انجام شده؟ چه ضوابطی باید رعایت شده باشه تا بشه وضعیت این تسک رو به انجامشده تغییر داد؟ و...
بله! به این استاندارد دقیقا میگن "Definition of Done" یا "DoD".
یک مفهموم در سطوح مختلف
مفهوم انجام شدن میتونه تو سطوح مختلفی تعریف بشه، از یه تیم کوچیک توسعه دهنده که هدفش توسعه محصول درخواست شده از تیم محصول یا مدیر محصوله تا یه تیم تولید محصول که هدفش تولید محصول مورد درخواست سطح بالاتره و تیم توسعه رو هم در بر میگیره، و یا حتی یه سطح بالاتر! چیزی که نهایتا یه مجموعه استارتاپ یا شرکت به دنبال رسیدن بهشه که یه محصول کاملا تست شده از نظر فنی، کاربردی و ظاهریه.
چگونه یک استاندارد تعریف کنیم؟
حالا که با مفهموم DoD آشنا شدیم، باید یاد بگیریم که چطوری DoD برای تیممون تعریف کنیم.
برای تعریف DoD، اول از همه باید به این سوالها پاسخ بدیم:
- در چه صورتی میشه گفت که محصول توسعه داده شده قابل استفاده هست؟
- محصول ما در چه محیطهایی باید به درستی کار کنه؟
- با انجام چه تستهایی میتونیم بگیم که محصولمون آماده برای ارائه هست؟
- چه مستنداتی باید تهیه بشه؟
در ادامه باید به این سوالها دقیقا پاسخ بدیم:
- دقیقا چه تستهایی باید روی محصول انجام بشه؟
- این تستها در چه سطح و عمقی باید انجام بشن؟
- کدوم نتایج از این تستها مقصود هستن؟
حالا که به این سوالها پاسخ دادیم، باید لیستی از این استانداردها که شامل انواع تستها و بررسیها هستن تهیه کنیم و برای توسعه هر ویژگی یا محصولی اونها رو یک به یک رعایت کنیم. به مرور زمان باید سعی کنیم این استانداردها رو دقیق و دقیقتر کنیم و حتی در صورتی که احتیاج به تغییر داشتن تغییرشون بدیم.
خلاصه
مفهوم انجام شدن یه تعریف خیلی موثر در تولید و توسعه نرمافزاره که نتنها باعث نظم بیشتر میشه، بلکه شفافیت رو افزایش میده و همچنین میتونه باعث تصمیمگیری های واقعبینانهتر و برنامهریزی بهتر در فرآیند تولید و توسعه نرمافزار بشه.
مطلبی دیگر از این انتشارات
الگوریتم Bubble Sort یا همون مرتب سازی حبابی
مطلبی دیگر از این انتشارات
ساختار Folder per feature MVVM
مطلبی دیگر از این انتشارات
React Query: Data Magic