در صنعت موسیقی این یک اصل است که که ساده‌ترین راه برای خراب کردن یک آهنگ، ادامه کار بر روی آن است. دانستن اینکه چه زمانی یک کار هنری انجام می‌شود ذهنی است و تعریف آن اغلب دشوار است. اما این مورد نمی‌تواند در مورد پروژه شما صدق کند. بدون یک تعریف مشخص از مراحل انجام پروژه، تیم توسعه شما نمی‌داند که دقیقا در حال کار برای چه هستند، ذینفعان شما در گسترش دامنه کار آزاد نخواهند بود و به احتمال زیاد کاربران شما با محصولی شلوغ، گیج کننده و غیرقابل استفاده مواجه می‌شوند.
به بیان دیگر، یک تعریف واضح از موارد قابل انجام (DoD یا definition of done) یکی از مهمترین عناصر توسعه مدیریت چابک (Agile) و متد اسکرام (Scrum) است. به طور مثال اگر هدف پروژه شما، تولید نرم‌افزارهای قابل استفاده است، پس قبل از شروع کار باید بدانید که این کار به چه شکل انجام خواهد شد.
تعریف انجام شده (DoD) چیست؟
برای اینکه تیم شما به جلو حرکت کند، باید اهداف شما را مد نظر قرار دهد و محصولات قابل استفاده را به مشتری تحویل دهد، باید دقیقا بدانید که در فرآیند کسب و کار شما اوضاع چگونه پیش می‌رود و اهداف دقیقا چه نتایجی را متحمل می‌شوند. اینجاست که تعریف کار انجام شده یا DoD وارد بازی می‌شود.
طبق نظر Scrum.org، تعریف انجام شده درک مشترکی از انتظاراتی است که اسپرینت‌های فعلی باید برآورده کنند تا در اختیار کاربران قرار گیرد. به عبارت دیگر، تیم شما در تلاش است تا با اسپرینت‌های فعلی به کدام سطح کیفی برسد؟ شاید مهمتر این باشد که بپرسید، چگونه آن را اندازه‌گیری می‌کنید؟
اهداف تعریف انجام شده چیست؟
با در نظر گرفت معنایی که از این مفهوم ذکر شد، می‌توانیم اهداف تعریف انجام شده را به صورت زیر بیان کنیم:
ایجاد یک درک مشترک در مورد کیفیت و کامل بودن تیم.
این امر به ویژه در فرآیند برنامه‌ریزی اهداف بسیار مهم است زیرا شما باید بدانید برای چه هدفی کار می‌کنید.
ارائه چک لیست معیارها برای بررسی داستان‌های کاربران.
این می‌تواند در آینده یک صرفه‌جویی بزرگ باشد زیرا کار برای تأمین نیازهای کاربر، نیازی به انجام مجدد یا به روزرسانی نخواهد داشت.
اطمینان از سطح کیفی کار که باید مطابق با بودجه باشد.
این مهم نه تنها همه را راضی نگه می‌دارد، بلکه از شما در برابر مشکلات احتمالی محافظت می‌کند. اگر درخواستی خارج از تعریف انجام شده در مسیر شما باشد، تعیین انتظارات و انتقال یا تغییر آن، بسیار آسان‌تر خواهد بود.
بیشتر از همه، تعریف انجام شده به شما امکان می‌دهد در کنار تیم خود، کاری را به درستی انجام داده، به پایان برساند و حتی ادامه دهد. تعریف واضح X انجام شده روی نقشه، گنج شماست. بدون آن هیچ تصوری از زمان مناسب برای توقف یا ادامه مسیر نخواهید داشت. بدون ارسال هدف مشخص، کارهای ناتمام به راحتی انباشته می‌شوند و در آخر با یک دسته “بدهی کار (work debt)” روبرو می‌شوید که قبل از حرکت به جلو، باید بازپرداخت شود.
تعریف انجام شده در مقابل معیارهای پذیرش (acceptance criteria)
جایی که مردم اغلب گیج می‌شوند آنجاست که فکر می‌کنند تعریف آنها از موضوع انجام شده یک مسئله کنترل کیفیت است و یک مسئله مدیریت پروژه نیست. چرا فقط از معیارهای پذیرش خود برای تعیین زمان انجام “یک پروژه” استفاده نمی‌کنید؟ در حالی که هم معیارهای پذیرش و هم تعریف شما از انجام به شما کمک می‌کند تا مشخص کنید که کدام قطعه از پروژه شما به پایان رسیده است، اما تفاوت‌های اساسی در نحوه و امکان استفاده این این دو نیز وجود دارد.
یک روش ساده برای تمایز این دو مورد این است که جهانی بودن تعریف انجام شده را در نظر بگیرید. این مربوط به هر چیزی است که تیم مهندسی شما در اسپرینت فعلی حمل می‌کند. از طرف دیگر، معیارهای پذیرش منحصر به داستان کاربر (User Story)، ویژگی یا مسئله مورد بحث است. در اصل باید توجه کنید که این مورد ممکن است در عمل چگونه باشد.
یکی از رایج‌ترین مناطقی که تعریف انجام شده در آن استفاده خواهد شد، هنگام ارسال داستان کاربر است. به عنوان یک یادآوری سریع، داستان کاربر یک شرح مختصر، ساده از دیدگاه کاربران و مشتریان است. مثلا:
“به عنوان [نوع کاربر] من [برخی ویژگی‌های خاص] را می‌خواهم تا [برخی از مزایا] را دریافت کنم.”
نکته مهم
برای اینکه داستان کاربر “تمام شده” شناخته شود، باید تعدادی از موارد را بررسی کنید:
- آزمون واحد: قبول شد
- کدهای لازم: بررسی شد
- معیارهای پذیرش برای هر موضوع: برآورده شد
- تست‌های عملکردی: قبول شد
- الزامات غیر عملکردی: برآورده شد
- صاحب محصول داستان کاربر را: می‌پذیرد
فقط هنگامی که همه این معیارها برآورده شدند، می‌توان داستان کاربر را “انجام شده” نامید. با این حال، برای رسیدن به آن، هر موضوع باید از معیارهای پذیرش فردی خود، برخوردار باشد.
اینها را لایه‌های مختلف ویژگی پروژه بدانید. تعریف انجام شده برای تمام داستان‌های کاربر در اسپرینت شما اعمال می‌شود، در حالی که هر یک معیارهای پذیرش منحصر به فرد خود را دارند که باید برای تصویب ارسال شوند.
۵ مرحله در تعریف انجام شده
افراد اغلب ایده‌های مختلفی درباره کارهایی که باید انجام شود، دارند و همیشه قرار دادن کل تیم شما در یک سطح، کار ساده‌ای نیست. اما حتی دشوارتر از تصمیم‌گیری در مورد تعریف انجام شده، مسئولیت دادن به افراد متفاوت در یک گروه است. بنابراین چگونه می‌توانید اطمینان حاصل کنید که تیم شما DoD و معیارهای پذیرش مورد توافق خود را رعایت می‌کند؟
این کار با درگیر کردن کل تیم شما در روند کار و سپس روشن کردن نیازها، عملی بودن اهداف و همیشه در دسترس بودن مدیریت، شروع می‌شود.
در مورد تعریف خود به صورت تیمی تصمیم بگیرید.
چه کسی “مورد قابل انجام” را برای داستان کاربر/ ویژگی/ پروژه شما تعریف می‌کند؟ در حالی که تعریف “انجام شده” باید شامل ورودی از تیم محصول، کنترل کیفیت و ذینفعان مربوطه باشد، اما در نهایت به تیم فنی بستگی دارد که معنی آن را تعیین کنند.
با این حال، این باید یک روند مشترک باشد. بدون ورودی از تیم‌های دیگر، پشتیبانی مورد نیاز برای ارسال یک ویژگی را دریافت نخواهید کرد. شما همچنین درگیر معامله با ذینفعانی خواهید بود که انتظارات متفاوتی دارند یا در دلیل عدم ارسال یک ویژگی، گیج شده‌اند.
برای کمک به این مهم، ضروری است که تعریف شما از انجام شده، برای همه در دسترس باشد و اینکه چرا این مواردی است که شما انتخاب کرده‌اید، باید شفافیت داشته باشند. به این ترتیب، همه می‌دانند که چرا یک نسخه یا ویژگی متوقف شده است و برای پیشبرد آن چه باید کرد.
نتیجه سخن
یک دلیل نهایی وجود دارد که شما باید به تعریف انجام شده اهمیت دهید: این باعث ایجاد اعتماد در سراسر تیم و کل سازمان شما می‌شود. دیدگاه مشترک، باز و صادقانه نسبت به پروژه با کیفیت، همه اعضای را در یک سطح آگاهی قرار می‌دهد.
