?
مقدمه:
در شرکت های برنامه نویسی با رویکرد اجایل مسملما این واژه زیاد به گوشتان خورده است و حتی ممکن است در تیمی که بوده اید از آن استفاده میکردید ولی تا به حال در مورد چگونگی شکل گرفتن این معیارها و تعریف ها میدانستید؟ یا در جلساتی که تعریف میشوند حضور داشته اید؟ آیا سطوح انجام کار برای شما تعریف شده است؟ و شما اگر به عنوان یک مالک محصول یا توسعه دهنده فعالیت میکنید چه تعریفی از این قسمت برای خود دارید؟ در ادامه میخواهیم کمی شفاف تر کنیم و از روی Case Study های بررسی شده و تجربه شده به شما نشان دهیم که میتواند چقدر منعطف باشد و چه پارامترهایی اجباری است و شما با توجه به اینکه اجایل چارچوبی کاملا منعطف است چقدر میتوانید در آن دست ببرید.
شرایط پذیرش (DoD):
DoD یعنی بتوانیم توسط آن بگوییم کاری انجام شده و قابلیت استفاده دارد و کیفیت آن تضمین شده است حالا اینکه چگونه میتوان با اطمینان این تاییدات داد برمیگردد به نقش هر بخش در DoD.
ممکن است شما یک تیمی داشته باشید که از قسمت های مختلف فنی و غیر فنی مختلفی شکل گرفته باشد (هدف این نیست که Spotify را مثال بزنیم چون کاملا نحوه مدیریت و رشد تیم در Spotify متفاوت است) در نظر بگیرید تیم شما شامل Front-end ، Back-end، QC، QA میشود چگونه برای هر کدام DoD تعریف میکنید و در نهایت میگویید به چه چیزی در تحت چه سنجه ای میگویید انجام شده؟
در استاندارد جهانی برای مراحل مختلف از پیاده سازی تا تست و Deploy نهایی تعریف انجام شده شکل میگیرد. اگر یک اسپرینت را در نظر بگیرید میتوانیم بدین صورت تعریف داشته باشیم:
در استاندارهای جهانی برای مراحل مختلف با وجود تعریف اجایل DOD تعریف میگردد این بدان معناست که ما میتوانیم لیستی جامع از DoD ها داشته باشیم و برای هر قسمت بسته به نیاز از آن استفاده کنیم قرار نیست همه چی در این لیست تیک بخورد بلکه لازمه هر آن چیزی که در اول اسپرینت تعیین شده است محقق شود.
برای نمونه استاندار جهانی برای تیک خوردن DoD کد نویسی :
ü کد مورد بررسی قرار می گیرد
ü کد بررسی می شود
ü کد برای آزمایش محیط استفاده می شود
ü کد/ویژگی از آزمون رگرسیون عبور می کند
ü کد/ویژگی تست دود را پشت سر می گذارد
ü کد مستند است
ü مستندات راهنما به روز شده است
ü ویژگی توسط ذینفعان خوب است
با توجه به ساختار تیم های اجایل عموما Team Leader ها و Scrum Master ها تهیه کننده لیست نهایی و مسئول اشتراک گذاری و بررسی آن هستند؛ ولی برای تعریف لیست باید مشارکتی و با تیم محصول باشد.
**: همچنین چک لیست تهیه شده میتواند برای یک اسپرینت یا میتوان برای مدت چرخه عمر یک محصول استفاده کرد.
یک تعریف کلی که در بیشتر شرکت هایی با متدلوژی اجایل فعالیت میکنند مشترک است:
"زمانی میگیم شرایط DoD محقق شده همه استوری های تعریف شده در یک اسپرینت قابلیت ورژن شدن و به دست مشتری رسیدن را دارا باشند."
تعریف DoD باعث صرفه جویی در زمان و جلوگیری از انجام مجدد کارها میشود چون یک کار براساس چک لیست تمام میشود و قابلیت ارائه را دارد . (جلوگیری از بدیهی فنی)
مزایای DoD:
§ باعث کاهش دوباره کاری
§ باعث مشخص بودن استوری و جلوگیری از گستردگی استوری های کاربری
§ باعث ایجاد کیفیت در کار
§ جلوگیری از ارائه داستان اشتباه به مشتری
§ جلوگیری از بازسازی های مداوم زیرساختی
ارزش DoD را میتوان اینگونه تعریف کرد:
"تعریف DoD باعث صرفه جویی در زمان و جلوگیری از انجام مجدد کارها میشود چون یک کار براساس چک لیست تمام میشود و قابلیت ارائه را دارد . (جلوگیری از بدیهی فنی)"
نقش تیم محصول در تعیین DoD:
برای جلوگیری از بدهی فنی تیم بهتر است تمامی شرایط پذیرش (acceptance criteria) یک استوری توسط مالک محصول قبل آن برآورد شود که نه تیم از لحاظ فکری درگیر باشد و نه در پایان اسپرینت با موضوع بدهی فنی مواجهه شویم. و از طرفی در چک لیست DoD نیز با موفقیت پشت سر بگذارد.
لیست DoD میتواند یک بار تعریف شود و چک لیست متناسب با پروژه باشد ولی هر DoD نیاز به معیارهایی دارد که میگوییم acceptance criteria و خاصا برای هراستوری تعریف میشود.
**: تعریف پذیرش یک استوری باید ساده و کوتاه باشد.
چک لیست DoD باید کوتاه باشد یعنی یک لیست 20 تایی ندهید و انتظار تیک خوردن همه موارد را داشته باشید بلکه مواردی تیک میخورد که لازم باشدو همچنین باید خاصیت تمرکز پذیری را دارا باشد.
DoD ها را با این جمله بسنجید:
"من به عنوان [نوع کاربر] [برخی ویژگی های خاص] را می خواهم تا [برخی از مزایا] دریافت شود."
**: طبق چک لیست ممکن است کاری تمام باشد ولی هیچ گاه در سمت تیم فنی کاری را تمام شده فرض نکنید بلکه تا زمانی که در چرخه محصول هستید باید به توسعه محصول و وابستگی های آن فکر کنید.
معیار های انجام شده یا Acceptance criteria:
o کد نوشته شده است اساسی ترین چیزی که باید تکمیل شود تا هرگونه داستان یا مسئله کاربر "انجام شود".
o کد مستند است در این سطح ، شما به احتمال زیاد می خواهید برخی از اسناد توسعه دهنده را تکمیل کرده و در دسترس قرار دهید. بسته به اندازه پروژه ، ممکن است بخواهید نوعی سند مستند برای راهنمایی برای پشتیبانی (که به سوالات مربوط به انتشار به کاربران پاسخ می دهد) ایجاد کنید.
o بررسی کد تکمیل شد. به عنوان بخشی از اسپرینت خود ، می خواهید کد خود را برای بررسی با معیارهای مشخص (و معیارهای پذیرش) آماده کنید. برای "انجام شدن" ، کد باید توسط تیم شما مورد بررسی قرار گیرد.
o Build در محیط توسعه ساخته شده و به کار گرفته شده است. تعریف شما از انجام شده باید فراتر از محدوده محیط توسعه کد باشد.
با درنظر گرفتن استقرار، به حفظ اجایل بودن تیم خود را حفظ کنید.
o آزمایشات به پایان رسیده است. آیا کار می کند؟ قبل از اتمام کار ، باید مطمئن شوید که برنامه تست های لازم خود را گذرانده است و مطمئن شوید که در این بین هیچ چیز دیگری را تغییر پیدا نکرده است.
o با یک تعریف واضح از انجام ، شما باید اطمینان حاصل کنید که این قوانین در مورد همه کارها یا مسائل قابل اجرا درفریم ورک مورد استفاده شما اعمال میشود. چه انتشار ویژگی مهمی داشته باشید و یا چه رفع باگ فقط تفاوت در نوع اطلاع رسانی به مشتری است ولی حتما چک لیست "انجام شده" شما را بررسی کند.
**: نقطه ای است که خیلی ها fail میشوند.
بهتر است در مواقعی که فشار کاری زیاد است و شما باید به ددلاین مشخص در کمینه ترین زمان ممکن برسید تمرکز خود را برای روی معیارهای انجام استوری به جای DoD بگذارید. هرچند که در این نوع تائید کردن شما باید قسمت به قسمت بررسی کنید و نمیتوانید مجموعه ای ارائه دهید.
ساده ترین مشکلاتی که در صورتی که در تیم برسر وجود DoD ها توافق نکرده باشیم:
بدون تعریف واضح از کار انجام شده ، تیم توسعه شما نمی داند که در حال انجام چه کاری است ، ذینفعان شما در افزایش دامنه نیازهای خود مختارمیشود و نه شما دیگر میتواند از سیستم اولویت بندی استفاده کنید و نه میتوانید توافقی مشترک داشته باشید؛ و کاربران شما به احتمال زیاد با محصولی شلوغ ، گیج کننده و غیرقابل استفاده به پایان رو به رو میشوند.
پیشنهاد میشود که ابتدا از پایان به ابتدای آن بررسی کنید و Workflow آن را رسم کنید یک وضوح کامل از فرآیند ها به شما میدهد، زبان مشترکی ایجاد میکند، کیفیت وانتظارات را متعادل میکند و مهمترین فاکتور از کمال گرایی جلوگیری میکند.
**: اگر برای خود اهداف مشخص را تعیین نکنید تیم به صورت مداوم در حالت بلاکی است و بدیهی فنی زیادی به بار میآورد که بعد از آن باید ابتدا آن بدیهی را پرداخت کنید.
خلاصه ای از مزایای DoD از لحاظ ساختار:
- ایجاد یک درک مشترک از کیفیت و کامل بودن این امر به ویژه در برنامه ریزی اجایل بسیار مهم است.
- ایجاد یک چک لیستی از نیازهای مشتری از قسمت های مختلف محصول این کار باعث میشود در آینده زمان صرفه جویی و جلوگیری از دوباره کاری های خسته کننده شود.
- اطمینان حاصل کنید که در هر اسپرینت محصول در حال تولید الزامات و کیفیت لازم توافق شده را دارا میباشد این کار باعث میشود در نتیجه مشتریان راضی بیشتری داشته باشید.
- اگر درخواستی خارج از برنامه وارد شد به جای اینکه روی تیم فشار بیاورید خیلی محکم آن را به اسپرینت بعدی منتقل کنید.
- تعریف انجام کار و معیارهای پذیرش به مشخص شدن زمان اتمام پروژه کمک میکند.
چه کسی "انجام شده" را برای داستان کاربر/ویژگی/پروژه شما تعریف می کند؟
در حالی که تعریف "انجام شده" باید شامل ورودی تیم محصول ، کنترل کیفیت و ذینفعان مربوطه باشد ، در نهایت این به تیم فنی بستگی دارد که به چه معنا تصمیم می گیرد.
مراحل ارائه لیست DoD:
برای تعریف شرایط پذیرش و انجام شده باید ابتدا مالک محصول لیستی را تهیه کند و در یک جلسه به اعضای تیم بدون حضور اشخاص خارجی ارائه دهد و تیم روی آن به جمع بندی و شفافیت برسد بعد از آن به منظور اطلاع رسانی و همچنین بهبود آن ارسال به واحد های تحت تاثیر صورت بگیرد.
**: همانطور که معیارها و چک لیست DoD را تعیین می کنید ، مطمئن شوید که فقط از جنبه های فنی عقب نشینی کرده و در مورد کل محصول فکر می کنید.
با ذینفعان یا صاحب پروژه صحبت کنید و بپرسید آیا مسائل دیگری وجود دارد که مانع از "افزایش" واقعی این پیشرفت می شود و به آن فکر نمی کنید.
برای تعریف انجام شده مالک محصول به عنوان اولین فردی که دارد تعریف میکند باید در دسترس بودن و دلیل تعریف آن ها مشخص باشد اصل شفافیت و واضح بودن و طبق لیست همه باید متوجه اینکه چرا یک فیچر توسعه اش متوقف شده و یا چرا دارد به سرعت پیشرفت میکند مشخص باشد.
روی لیست معیارها وسواس نداشته باشید:
پیشتر ، ما تعریف انجام شده را "درک مشترک" بین تیم توسعه و مالک محصول نامیده بودیم. اما تعداد زیادی از موارد DoD باعث جلب توجه تیم شما می شود. آنها عوامل مختلف زیادی را در ذهن خود دارند که منجر به یکی از دو نتیجه می شود:
o آنها فقط بر روی زیرمجموعه کوچکی از موارد DoD کار خواهند کرد
o آنها سعی می کنند همه کارها را انجام دهند (و به احتمال زیاد شکست می خورند)
یک قاعده کلی خوب این است که تعریف خود را از انجام شده به عنوان حداقل کار مورد نیاز برای برآوردن سطح کیفی مورد توافق در نظر بگیرید.
معنی کلمه "حق" ممکن است در طول زمان تغییر کند. این بدان معناست که شما باید تعریف خود را از انجام شده در طول زمان مدیریت کرده و آن را مرور کنید تا ببینید آیا می توانید معیارهایی را حذف کنید.
**: در نهایت ، انجام شده همیشه بهتر از کامل است.
اطمینان حاصل کنید که هر وظیفه فردی معیارهای پذیرش خاص خود را دارد
تقریباً در همه موارد ، تعریف انجام شده باید توسط کل تیم اسکرام تعیین شود. در Agile ، تیم شما تنها مسئول تبدیل مطالب عقب افتاده محصول شما به نرم افزارهای اسپرینت و قابل استفاده است.
با این حال ، مشکل این است که بیش از حد روی کار موردنظر تمرکز کنید و اهداف ، نیازها و قراردادهای بزرگتر شرکت خود را فراموش کنید. گاهی اوقات باید تعریف انجام شده را بر اساس ارزشها و اصول اصلی شما بررسی کنید تا مطمئن شوید که هیچ مسأله آشکاری از قلم نمی افتد.
یکی از بهترین ویژگی های Agile این است که به سرعت تیم و محصول اجازه می دهد تا با نیازهای کاربر سازگار شوند. با این حال ، چیزی که به راحتی تغییر نمی کند ، چیزی است که "انجام شده" تلقی می شود.
ممکن است اگر تعریف های چک لیست را تغییر دهید در تیم سردرگمی و اتفاقا بدیهی فنی ایجاد کنید ولی اگر نیاز بود یک عامل مهم را تغییر دهید چه؟
هیچ زمان مشخصی برای ایجاد این چنین تغییرات وجود ندارد ولی در راهنمای اسکرام این گونه میگوید:
"در صورت لزوم در طول هر Sprint Retrospective ، تیم Scrum راه هایی را برای افزایش کیفیت محصول و یا بهبود فرایندهای کاری با اقتباس از تعریف" انجام شده "برنامه ریزی می کند ، که در تضاد با استانداردهای محصول یا سازمان نیست."
یک قاعده خوب این است که در بحث حین انجام کارآماده هرگونه تغییر باشید که میتواند درمرحله برنامه ریزی انجام کار یا در پیش از شروع باشد.
یک دلیل نهایی وجود دارد که باید به تعریف "انجام شده" اهمیت دهید: این باعث ایجاد اعتماد در تیم و کل سازمان می شود. ایجاد یک دیدگاه مشترک ، باز و صادقانه در مورد ظاهر نرم افزار با کیفیت ، همه را در یک جبهه قرار می دهد و از دردسر شنیدن بهانه های مختلف جلوگیری می کند "اما من فکر کردم ما در حال ساخت [X] هستیم!"
