شما چطور تعیین می کنید “عاری از نقص” چیست؟ از آنجا که این برای هر محصول متفاوت است و ممکن است با گذشت زمان تغییر کند شما نیاز به تمرکز بر کیفیت و انعکاس کیفیت در “تعریف انجام شده” (Definition of Done) دارید.
در نهایت این تیم توسعه شماست که مسئولیت تولید فرآورده های تکمیل شده از نرم افزار را به عهده دارد. فرآورده های تکمیل شده. به معنای واقعی تکمیل شده.
تیم توسعه شما باید تصمیم بگیرد که تکمیل شده چیست. آنها باید لیستی از مواردی را تهیه کنند که برای هر فرآورده یا خروجی قابل ارائه نرم افزاری که تولید می کنند صادق باشد. نرم افزار در حال اجرا مختص یک PBI نیست؛ بدون توجه به هر آیتم از بک لاگ محصول در تحویل نهایی اعمال می شود. نه فقط برای هر آیتم از بک لاگ محصول.
“فرآورده مورد نظر بدون در نظر گرفتن اینکه آیا مالک محصول (Product Owner) تصمیم به انتشار آن را در بازار داشته باشد یا خیر، باید در شرایط قابل استفاده باشد.“
اگر شما حداقل هر ۳۰ روز یک بار نتوانید نرم افزارهای در حال اجرا به بازار ارائه دهید، پس با هرگونه تعریفی شما هنوز در حال اجرای Scrum نیستید. از آنجا که تیم های اسکرام حرفه ای نرم افزاری را تولید می کنند که کار می کند ، توقف کنید، یک نرم افزار را تولید کنید که مطابق با تعریف شما از در حال اجرا (DoD) باشد و سپس بخش بندی دوره های تکرار (Sprinting) را شروع کنید و مقصود خود را با “کار” مداوم و بر روی حداقل یک قاعده منظم، بررسی و مرور کنید.
شما باید از جایی شروع کنید و بیشتر اوقات ما یک محصول کامل شده و نهایی نداریم. یا به ما یک محصول موجود تحویل داده می شود، یا ما تیمی هستیم که آن را ساخته و به اسکرام سوئیچ می کنیم. از هر کجا که محصول شما سرچشمه گرفته باشد، کد و در نتیجه محصول، در حال حاضر نرم افزار اجرایی نیست. وقتی تعریفی از معنی “در حال اجرا” ندارید چگونه می توانید تعریفی از “تکمیل شده” داشته باشید؟ در نتیجه چه کاری انجام می دهید؟
قبل از اینکه یک خط کد را قطع کنید باید تصمیم بگیرید که چه چیزی برای محصول و شرکت شما به معنی “انجام شده” است. قطعا این مفهوم در مورد ساختن سیستم عامل برای دستگاه های تنظیم کننده ضربان قلب با ایجاد یک پورتال تجارت الکترونیک بسیار متفاوت خواهد بود. در اینجا به بیان برخی از ویژگی های DoD می پردازیم:
چک لیست کوتاه و قابل اندازه گیری شما که بازتاب های قابل ارائه را در خود جای می دهد و نتیجه کار دیگری برای تحویل کالای شما نیست، لازم است تعریف شود. از دید من بهترین راه برای این کار، داشتن یک جلسه ساده سازی DoD برای تیم Scrum (مالک محصول به اضافه تیم توسعه) است. بدون تعریف Done ما درک نمی کنیم که نرم افزار در حال اجرا چیست و بدون نرم افزار در حال اجرا نمی توانیم تحویل قابل پیش بینی داشته باشیم. مالک محصول شما نمی تواند یک آیتم از بک لاگ محصول را رد کند، فقط به این دلیل که فرآورده کار می کند یا خیر.
تعریف شما از “تکمیل شده” بطور جادویی ظاهر نمی شود و نرم افزار شما بطور اتفاقی با این تعریف مطابقت پیدا نمی کند. سازگاری نرم افزار با تعریف خود از کار انجام شده کار سختی است و اگرچه تعریف شما از انجام شده باید به صورت ارگانیک رشد کند، اما ابتدا باید دانه ای را ایجاد کنید که بتوانید آن را خلق کنید.
من توصیه می کنم که یک کارگاه آموزشی را با کل تیم Scrum و احتمالاً برخی دیگر از متخصصین حوزه انجام دهید. اگر مراحل دیگری نیز وجود دارد که نرم افزار شما پس از اتمام کار تیم توسعه باید آن ها را طی کند، برای شرکت در کارگاه به نمایندگان آن مراحل احتیاج دارید. صرف نظر از نوع محصولتان، شما به تخصص های زیر در مورد نمایندگان احتیاج دارید. کد ، تست ، امنیت ، UX ، UI ، معماری و غیره. ممکن است این مهارت را در تیم خود داشته باشید یا شاید لازم باشد یک متخصص از سازمان خود یا حتی خارج از آن برای سازمان خود بیاورید.
برخی از نمونه مواردی که می توانید تعریف خود را از تکمیل شده بیان کنید:
همان حالت باقی می ماند یا بالاتر می رود – نگاه کردن به یک اندازه گیری خاص ، مانند ۹۰٪ ، پوشش کدها شنوایی خوانده شده است و هیچ چیزی از کیفیت کد به شما نمی گوید. با این حال ، ممکن است نظارت و اندازه گیری برای تغییرات منفی در پوشش کد سودمند باشد ، و ما همیشه از شیوه های TDD طرفداری می کنیم.
هرچقدر هم که تعریف Done را خوب و جامع ارائه دهید بعید است که محصول شما در حال حاضر معیارها را برآورده کند. شما هنوز در حال اجرای اسکرام نیستید. قبل از شروع به اسپرینت سازی، باید اطمینان حاصل کنید که پیشرفت فعلی شما با تعریف جدید Done شما مطابقت دارد. روی کیفیت تمرکز کنید ، این همان چیزی است که تیم توسعه مسئولیت آن را بر عهده دارد و مطمئن شوید که پیشرفت شما قبل از شروع کار با آن نوار کیفیت جدید مطابقت دارد. فرآورده بعدی فقط می تواند به کیفیت تمام کارهایی که قبلاً انجام شده اند افزوده شود.
یک خروجی قابل اجرا از نرم افزار تولید کنید که مطابق با تعریف شما از “انجام شده” باشد و سپس اسپرینت سازی را شروع کنید. نگه داشتن نرم افزار در وضعیت در حال اجرا، به یک سیستم کنترل منبع مدرن نیاز دارد که امکانات شما را برای اجرای شیوه های خوب DevOps فراهم می کند.
این بسیار مهم است که کیفیت همیشه در حال بهبود است و این بدان معناست که شما نیاز دارید که حداقل در یک تعریف منظم روی 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
