شروع با “تعریف انجام شده” – Definition of Done

شما چطور تعیین می کنید “عاری از نقص” چیست؟ از آنجا که این برای هر محصول متفاوت است و ممکن است با گذشت زمان تغییر کند شما نیاز به تمرکز بر کیفیت و انعکاس کیفیت در “تعریف انجام شده” (Definition of Done) دارید.در نهایت این تیم توسعه شماست که مسئولیت تولید فرآورده های تکمیل شده از نرم افزار را به عهده دارد. فرآورده های تکمیل شده. به معنای واقعی تکمیل شده.تیم توسعه شما باید تصمیم بگیرد که تکمیل شده چیست. آنها باید لیستی از مواردی را تهیه کنند که برای هر فرآورده یا خروجی قابل ارائه نرم افزاری که تولید می کنند صادق باشد. نرم افزار در حال اجرا مختص یک PBI نیست؛ بدون توجه به هر آیتم از بک لاگ محصول در تحویل نهایی اعمال می شود. نه فقط برای هر آیتم از بک لاگ محصول.“فرآورده مورد نظر بدون در نظر گرفتن اینکه آیا مالک محصول (Product Owner) تصمیم به انتشار آن را در بازار داشته باشد یا خیر، باید در شرایط قابل استفاده باشد.“اگر شما حداقل هر ۳۰ روز یک بار نتوانید نرم افزارهای در حال اجرا به بازار ارائه دهید، پس با هرگونه تعریفی شما هنوز در حال اجرای Scrum نیستید. از آنجا که تیم های اسکرام حرفه ای نرم افزاری را تولید می کنند که کار می کند ، توقف کنید، یک نرم افزار را تولید کنید که مطابق با تعریف شما از در حال اجرا (DoD) باشد و سپس بخش بندی دوره های تکرار (Sprinting) را شروع کنید و مقصود خود را با “کار” مداوم و بر روی حداقل یک قاعده منظم، بررسی و مرور کنید.تعریف انجام شده (DoD) چیست؟شما باید از جایی شروع کنید و بیشتر اوقات ما یک محصول کامل شده و نهایی نداریم. یا به ما یک محصول موجود تحویل داده می شود، یا ما تیمی هستیم که آن را ساخته و به اسکرام سوئیچ می کنیم. از هر کجا که محصول شما سرچشمه گرفته باشد، کد و در نتیجه محصول، در حال حاضر نرم افزار اجرایی نیست. وقتی تعریفی از معنی “در حال اجرا” ندارید چگونه می توانید تعریفی از “تکمیل شده” داشته باشید؟ در نتیجه چه کاری انجام می دهید؟قبل از اینکه یک خط کد را قطع کنید باید تصمیم بگیرید که چه چیزی برای محصول و شرکت شما به معنی “انجام شده” است. قطعا این مفهوم در مورد ساختن سیستم عامل برای دستگاه های تنظیم کننده ضربان قلب با ایجاد یک پورتال تجارت الکترونیک بسیار متفاوت خواهد بود. در اینجا به بیان برخی از ویژگی های DoD می پردازیم:یک چک لیست کوتاه و قابل اندازه گیری – سعی کنید مواردی را در تعریف تکمیل شده (DoD) خود داشته باشید که قابل اندازه گیری باشد، تا بتوانید نتیجه را ترجیحاً به صورت خودکار آزمایش کنید.بازتاب های قابل ارائه – اگرچه ممکن است محصول خود را به بازار ارائه نکرده باشید، (اگرچه ما آن را توصیه می کنیم) شما باید این حق انتخاب را داشته باشید. مالک محصول شما باید بتواند در جلسه Sprint Review اعلام کند: “این عالی است … بیایید آن را منتشر کنیم.”باقی نماندن کارهای متعاقب – برای ارائه محصول شما به بازار نباید دیگر به کارهای دیگری نیاز باشد. هر کار اضافی بدان معنی است که شما در حالت “تکمیل شده” نیستید و برای دوره های تکرار بعدی از ظرفیت مالکان محصولات فاصله می گیرد. در حالت ایده آل ، شما یک فرایند کاملاً خودکار برای تحویل نرم افزار دارید و هرگز برای تحویل از تکرارهای با کارهای مبهم استفاده نکنید.چک لیست کوتاه و قابل اندازه گیری شما که بازتاب های قابل ارائه را در خود جای می دهد و نتیجه کار دیگری برای تحویل کالای شما نیست، لازم است تعریف شود. از دید من بهترین راه برای این کار، داشتن یک جلسه ساده سازی DoD برای تیم Scrum (مالک محصول به اضافه تیم توسعه) است. بدون تعریف Done ما درک نمی کنیم که نرم افزار در حال اجرا چیست و بدون نرم افزار در حال اجرا نمی توانیم تحویل قابل پیش بینی داشته باشیم. مالک محصول شما نمی تواند یک آیتم از بک لاگ محصول را رد کند، فقط به این دلیل که فرآورده کار می کند یا خیر.اولین تعریف من از “انجام شده” (DoD)تعریف شما از “تکمیل شده” بطور جادویی ظاهر نمی شود و نرم افزار شما بطور اتفاقی با این تعریف مطابقت پیدا نمی کند. سازگاری نرم افزار با تعریف خود از کار انجام شده کار سختی است و اگرچه تعریف شما از انجام شده باید به صورت ارگانیک رشد کند، اما ابتدا باید دانه ای را ایجاد کنید که بتوانید آن را خلق کنید.من توصیه می کنم که یک کارگاه آموزشی را با کل تیم Scrum و احتمالاً برخی دیگر از متخصصین حوزه انجام دهید. اگر مراحل دیگری نیز وجود دارد که نرم افزار شما پس از اتمام کار تیم توسعه باید آن ها را طی کند، برای شرکت در کارگاه به نمایندگان آن مراحل احتیاج دارید. صرف نظر از نوع محصولتان، شما به تخصص های زیر در مورد نمایندگان احتیاج دارید. کد ، تست ، امنیت ، UX ، UI ، معماری و غیره. ممکن است این مهارت را در تیم خود داشته باشید یا شاید لازم باشد یک متخصص از سازمان خود یا حتی خارج از آن برای سازمان خود بیاورید.برخی از نمونه مواردی که می توانید تعریف خود را از تکمیل شده بیان کنید:فرآورده، بررسی های SonarQube (یک سری بررسی های خودکار کدها) را بدون هیچگونه خطای بحرانی با موفقیت می گذراند – کارهای شما به مرور زمان افزایش خواهد یافت، بنابراین شاید نیاز باشد که بگویید “کدها بررسی های SonarQube را با کمتر از ۵۰ خطای بحرانی پشت سر بگذارند” و سپس به مرور زمان روی آن کار کنید.Coverage Coverage Coverage همان حالت باقی می ماند یا بالاتر می رود – نگاه کردن به یک اندازه گیری خاص ، مانند ۹۰٪ ، پوشش کدها شنوایی خوانده شده است و هیچ چیزی از کیفیت کد به شما نمی گوید. با این حال ، ممکن است نظارت و اندازه گیری برای تغییرات منفی در پوشش کد سودمند باشد ، و ما همیشه از شیوه های TDD طرفداری می کنیم.فرآورده مطابق با استانداردهای مهندسی است – شما باید قوانینی را برای نامگذاری متدها، تستها، متغیرها و همه چیز فی ما بین آن ها در نظر بگیرید. در ابتدا با کم شروع کرده و به مرور زمان به آن اضافه کنید. استانداردهای توافق شده خود را در سندی (wiki) به هم ارتباط داده و به طور مداوم قوانین خود را بهبود و گسترش دهید. در صورت امکان این عملیات را خودکار سازی کنید.معیارهای پذیرش برای قبول کردن فرآورده – اطمینان حاصل کردن از اینکه شما به حداقل معیارهای تعیین شده دست یابید، یک هدف قابل ستایش است و خودکار سازی آن ها با روش های ATDD حتی با ارزش تر است.تست های پذیرش برای فرآورده خودکار هستند – اطمینان حاصل کنید که تمام تست های خود را به صورت خودکار انجام می دهید. اگر فکر می کنید چیزی خراب خواهد شد، پس باید آزمایش و بررسی آن را انجام دهید.بررسی های امنیتی روی فرآورده پشت سر گذاشته می شوند – از یک ابزار خودکار به عنوان بخشی از ساختار خود استفاده کنید و آسیب پذیری های امنیتی شناخته شده را بررسی کنید. شما تمام مسائل امنیتی خود را نخواهید یافت، اما حداقل کارهایی نکنید که می دانیم منعکس کننده ضعف امنیتی هستند.فرآورده مطابق با استانداردهای UX توافق شده است – مجدداً یک صفحه wiki داشته باشید و مطمئن شوید که آن را دوبار بررسی کرده اید. اگر از ورودی DoD خودکار استفاده نمی کنید، باید بصورت تیمی موافقت کنید که معیارها را رعایت کرده باشید.فرآورده با اصول معماری توافق شده مطابقت دارد – ویکی برای این کار خارق العاده است، اما آنچه را می توانید خودکار کنید.هرچقدر هم که تعریف Done را خوب و جامع ارائه دهید بعید است که محصول شما در حال حاضر معیارها را برآورده کند. شما هنوز در حال اجرای اسکرام نیستید. قبل از شروع به اسپرینت سازی، باید اطمینان حاصل کنید که پیشرفت فعلی شما با تعریف جدید Done شما مطابقت دارد. روی کیفیت تمرکز کنید ، این همان چیزی است که تیم توسعه مسئولیت آن را بر عهده دارد و مطمئن شوید که پیشرفت شما قبل از شروع کار با آن نوار کیفیت جدید مطابقت دارد. فرآورده بعدی فقط می تواند به کیفیت تمام کارهایی که قبلاً انجام شده اند افزوده شود.یک خروجی قابل اجرا از نرم افزار تولید کنید که مطابق با تعریف شما از “انجام شده” باشد و سپس اسپرینت سازی را شروع کنید. نگه داشتن نرم افزار در وضعیت در حال اجرا، به یک سیستم کنترل منبع مدرن نیاز دارد که امکانات شما را برای اجرای شیوه های خوب DevOps فراهم می کند.تعریفتان از “انجام شده” (DoD) را رشد دهیداین بسیار مهم است که کیفیت همیشه در حال بهبود است و این بدان معناست که شما نیاز دارید که حداقل در یک تعریف منظم روی Definition of Done تأمل کنید. در اسکرام، این ریتم توسط طول اسپرینت شما تعریف می شود و شما یک لحظه Kaizen در Sprint Retrospective دارید. این بدان معنی نیست که شما همیشه در مورد DoD خود تأمل نمی کنید، شما به طور مداوم تأمل می کنید که آیا میزان درآمد شما در حال حاضر با DoD شما مطابقت دارد و یا اینکه برای رسیدن به آنجا چه کارهایی باید انجام دهید. شما همیشه باید در مورد اینکه آیا DoD شما متناسب با نیازهای شما هست، تأمل کنید. اگر تیم توسعه شما می داند که چیزی از DoD در نیمه راه اسپرینت وجود دارد ، آنها باید رو به جلو حرکت کنند و آن را اضافه کنند. مطمئن شوید که آنها هدف اسپرینت (Sprint Goal) را به خطر نمی اندازند.شما ممکن است به این نتیجه برسید که همانطور که دیوید کوربان در پست قبلی من خاطرنشان کرد، با محصول خود مشکل عملکردی دارید. چگونه مطمئن شویم که این مسئله را حل کردیم؟ از دیدگاه من شما ۲ راه پیش روی اسپرینت جاری دارید. شکست را بپذیرید (به دلیل کیفیت پایین، اسپرینت را متوقف کنید) ، و مشکل را برطرف کنید، یا می توانید این دانش جدید را در چرخه محصول خود ادغام کنید.اگر این یک مسئله مهم است که منجر به عدم وجود نرم افزار در حال اجرا می شود، باید متوقف و رفع شود. در اسکرام این کار را غرق شدن (Scrumble) می نامند، به عنوان بازتابی از اینکه تیم توسعه متوقف شده است به دلیل اینکه چیزی را از دست داده است. قبل از ادامه اسپرینت سازی و اضافه کردن ویژگی های جدید، ابتدا باید نرم افزار در حال اجرا خلق کنید. پس از برطرف کردن مسئله، می توانید Definition of Done را بهبود دهید تا مطمئن شوید که تمام فرآورده های آینده نیازمندی های جدید را برآورده می کنند.اگر این از اهمیت کمتری برخوردار باشد ممکن است بخواهید کار خود را ادامه دهید و آنچه را که لازم دارید به بقیه محصول خود اضافه کنید. سپس می توانید چندین اسپرینت بعدی را بهبود بخشیده و مشکل شناسایی شده را برطرف کنید. پس از حل آن می توانید نتیجه را با اضافه کردن بخش جدیدی به DoD خود متصل کنید.همیشه به دنبال راه هایی باشید که بتوانید کیفیت خود را بهبود ببخشید. امروز تعریف شما از “ تکمیل شده ” یا DoD چیست؟لینک مقاله اصلی:https://www.scrum.org/resources/blog/getting-started-definition-done-dodپیج لینکدینپیج اینستاگرامپروفایل در scrum.org