تو مقاله قبلی راجع به تعریف کار انجام شده با هم صحبت کردیم و اهمیت و نقش اون در اسپرینت رویو رو با هم مرور کردیم. اما یه DoD خوب باید چه اجزایی داشته باشه و یا چه مواردی رو در بر بگیره، چیزی هست که تو این مقاله بهش می پردازم و سعی می کنم با ارایه مثال تصویر بهتری از DoD رو بتونم ارایه بدم.
اگه بخوایم DoD رو تو یه جمله تعریف کنیم باید بگیم درک مشترک اعضای تیم از تکمیل بودن خروجی ای که باید در یک اسپرینت قابل ارایه و استفاده باشه.
بدون تعریف واضح از کار انجام شده، تیم توسعه نمیدونه در حال انجام چه کاری است، ذی نفعان در افزایش دامنه مختار میشن و کاربران هم به احتمال زیاد با محصولی شلوغ، گیج کننده و غیرقابل استفاده رو به رو میشن؛ در حقیقت بدون DoD ما تصوری از این که کار کی به پایان میرسه نداریم.
بدون داشتن یک هدف مشخص، کارهای ناتمام به راحتی روی هم انباشته می شوند و در نهایت با یک "بدهی کاری" مواجه میشیم که باید پیش از اسپرینت های بعدی اون ها رو تموم کنیم و بنابراین سرعت حرکت رو پایین میاره.
از طرف دیگه، تعریف واضح انجام شده (DoD) یکی از مهمترین عناصر توسعه محصول چابک است. اگر هدف Agile ریلیس نرم افزارهای قابل استفاده هست، باید قبل از شروع به کار بدونیم که چطور به نظر میرسه.
تعریف کار انجام شده باید در ابتدای پروژه توسط "تیم اسکرام" به بحث گذاشته شده باشه و مورد موافقت قرار گرفته باشه تا نسخه های افزایشی (فرآورده های) آتی قابل ریلیس باشن؛ در این جا "Done" میتونه معنی تمام شدن برنامه نویسی، تست کردن، استقرار، مستند سازی، و یا هر ترکیبی از این ها باشه.
برای حرکت رو به جلوی تیم، رسیدن به اهداف، و انتشار نرم افزار قابل استفاده، ما نیاز داریم که به طور دقیق بدونیم کجای توسعه نرم افزار و همین طور کجای هدف مون هستیم. این همون جایی که "تعریف کار انجام شده" وارد بازی میشه.
تفاوت عمده ای که بین این دو تا هست اینه که AC برای هر User Story، Feature و یا Issue منحصر به فرد هست ولی DoD برای تمامی آن چه که تیم توسعه در یک اسپرینت باید ارایه کنه یکسان هست.
معمولا تعریف کار انجام شده (تکمیل شده) شامل اجزای زیر هست:
حالا با یه مثال ببینیم دنبال چی می گردیم (البته این مثال حداقل هایی هست که با بلوغ تیم توسعه و محصول میشه تقویتش کرد و برای رسیدن به محصول با کیفیت تر ازش بهره برد)؟
به طور معمول ما انتظار داریم که DoD از طرف سازمان ابلاغ شده باشه که این به عنوان حداقل هست و تیم توسعه میتونه مواردی رو بهش اضافه کنه تا اون رو برای پروژه مناسب تر کنه. اگه توی سازمان اصلا DoD وجود نداشته باشه کل موضوعات از سمت تیم توسعه مشخص میشه.
افراد اغلب ایده های متفاوتی از آنچه باید انجام شود دارند، و واقعا این که بتونیم همه اعضای تیم رو روی این موضوع هماهنگ کنیم خیلی سخته، اما حتی دشوارتر از تصمیم گیری در مورد تعریف انجام شده، متعهد موندن افراد نسبت به قرارداد هست!
برای ایجاد این تعهد باید همه اعضای تیم رو درگیر فرآیند تعیین تعریف کار انجام شده کنیم و بعد نیازمندی ها رو شفاف، قابل انجام، و همیشه در دسترس کنیم.
شرکت های مختلف و تیم های توسعه تصمیم می گیرند که معنی "انجام شده" برای آنها چیه؟ با این حال، تو بیشتر موارد، "انجام شده" به همان قانون طلایی برمی گردد: کد آنچه را که باید انجام دهد انجام دهد و هیچ چیز دیگری را در این فرآیند نقض نکند.
از اون جایی که تو مقاله قبلی هم راجع به این موضوع صحبت کرده بودم، تو این مقاله خواستم کمی بیشتر با هم در مورد اهمیت DoD و اجزای اون صحبت کنیم و امیدوارم که تونسته باشم برای درک بهتر این موضوع کمک کنم؛ در همین راستا از شما هم درخواست می کنم تا دیدگاه تون در این خصوص رو با من به اشتراک بزارین تا من هم بتونم به درک مناسب تری از مطلب برسم.
