برای دستیابی به تحویل قابل پیش بینی در سازمان خود به عاملی به نام “کیفیت” نیاز دارید.

من ارزیابی های ALM زیادی را برای شرکت ها انجام می دهم و تقریباً هر مشتری ای که با آن صحبت می کنم در تحویل نرم افزاری که از تیم های خود دریافت می کند کیفیت دور از انتظار به همراه دارد. این همیشه خطای تیم های توسعه نیست و غالباً در سازمانی تنظیم می شود که توانایی داشتن سطح تعریف شده و قابل پیش بینی از کیفیت را به حداقل برساند. در بیشتر موارد، این به دلیل عدم وجود لیستی از کمترین مواردی است که باید تکمیل شود تا یک سازمان درک کند در هر فرآیند تحویل و عرضه چه چیزهایی دخیل است.

اگر هیچ لیستی از موارد قابل تحویل ندارید و در نتیجه نمی دانید که برای تحویل هر مورد چه کارهایی باید تکمیل شود، چگونه می توانید پیش بینی دقیق (یا حداقل به همان اندازه که می توانیم دریافت کنیم) در مورد زمان تحویل کالا داشته باشید؟ در واقع شما هیچ مدرک تجربی ندارید که بتوانید برای پیش بینی تحویل به آن اعتماد کنید. علاوه بر این، سطح متنوع کیفیت منجر به اشکالات بیشتری در تولید می شود که این مسئولیت افزودن ویژگی ها را تحت فشار بیشتری بر عهده این افراد می گذارد. اگر توسعه دهندگان را تحت فشار قرار دهید، آنها به طور مداوم و فزاینده کیفیت را کاهش می دهند تا با همان محصول قابل تحویل و مورد انتظار مطابقت داشته باشند.

علاوه بر این، بسیاری از آیتم های بک لاگ محصول فاقد معیارهای پذیرش (Acceptance Criteria) هستند و تیم توسعه فرض را بر این می گذارد که مشتری اساس کار را کامل می پذیرد. در حقیقت، به دلیل عدم وجود معیارهای پذیرش، آیتم های بک لاگ محصول به طرز عجیبی بزرگ می شوند، این مسئله تیم را برای تحویل و در نتیجه کاهش کیفیت، بیشتر تحت تأثیر قرار می دهد.

برای بهبود پیش بینی پذیری، کیفیت را تنظیم کنید

تنها راه ایجاد موفقیت آمیز تحویل قابل پیش بینی نرم افزاری، تنظیم 3 نقطه مثلث آهنین از 4 نقطه است. در تولید نرم افزار سنتی، کیفیت یک ارزش پنهان است و اگر تلاش کنید هر پارامتر دیگری را تنظیم کنید، این کیفیت است که قربانی می شود. کیفیت باید با یک تعریف صریح ارائه شود.

تعریف انجام شده (Definition of Done) : “تعریف انجام شده” شما معیار ثابت یا تعریف صریح کیفیت برای فرآیند توسعه نرم افزار است. این یک چک لیست کوتاه قابل اندازه گیری است که همانند آینه می تواند برای هر واحد از کار ارائه شده نمایانگر وضعیت آن باشد. تعریف آن دشوار است اما بدون آن نمی دانیم که برای به ثمر رساندن هر آیتم بک لاگ چقدر کار باید انجام شود. در حالت حداقلی و پایه، آن را در خروجی هر تکرار(Iteration)، و در حالت ایده آل برای هر آیتم بک لاگ که کامل می کنید اعمال کنید.

معیارهای پذیرش (Acceptance Criteria) : در حالی که DoD به طور مساوی برای هر آیتم بک لاگ اعمال می شود، معیار پذیرش (Acceptance Criteria)  فقط برای یک آیتم منحصراً اعمال می شود. تمام مکالمات بین تیم توسعه، مالک محصول و بازار هدف باید در معیارهای پذیرش منعکس شود تا مواردی که در مورد آنها بحث می شود از قلم نیفتند. همچنین این مورد به درک مقیاس و ابعاد پروژه کمک می کند و ما را به تجزیه آیتم های بک لاگ به واحدهای کوچکتر تشویق می کند. هنگامی که متوجه شدید برای تکمیل یک مورد چه باید کرد، موارد بیش از حد بزرگ به طور شفاف آشکار می شوند.

ساخت خودکار (Automated Builds) : داشتن ساخت خودکار که می تواند کیفیت نرم افزار شما را اندازه گیری کند مهمترین عامل برای به حداقل رساندن میزان کاری است که تیم برای تأیید نرم افزار باید انجام دهد و همچنین ایجاد تست های پذیرش خودکار و تست واحد، اعتبار این ساخت ها را افزایش می دهد. در حالت ایده آل، برای هر معیار پذیرش که به آیتم بک لاگ اضافه شده است، باید یک تست خودکار (UIیا Unit) داشته باشید.

استقرار خودکار (Automated Deployment) : استقرار خودکار تیم را مجبور به تولید یک نرم افزار قابل اجرا می کند و به شما امکان می دهد چیزی را بسازید که هزینه تحویل را به حداقل می رساند. اگر تیم توسعه بداند که بازار هدف در هر زمان می تواند درخواست یک ارائه کند، در نتیجه تحت فشار خواهد بود تا عرضه پذیری و کیفیت آن را حفظ کند.

انجام همه این کارها کیفیت را هدف قرار می دهد.

برای ورود به دنیای اسکرام می توانید از دوره غیرحضوری “آشنایی مقدماتی با اسکرام” شروع کنید

نتیجه

روشی که ما به طور سنتی تیم های توسعه خود را اندازه گیری می کنیم، آنها را به سوی نوسان کیفیت سوق می دهیم که تنها پیامد آن دستیابی به برنامه های تحویل هیجانی و اضطراری خواهد بود. اگرچه این کیفیت نوسانی صرفاً منجر به کاهش توانایی ما در عرضه و آزار دادن مشتریان هنگام یافتن اشکالات در محصول می شود.

هدف این است كه کیفیت را افزایش دهیم نه اینکه آن را كاهش دهیم اما ابتدا باید بتوانیم این کیفیت را بسنجیم و آن را اجرا كنیم.

لینک مقاله اصلی:

https://www.scrum.org/resources/blog/what-devops-taught-me-about-agile

مدرسه اسکرام ، مرجع حرفه ای آموزش اسکرام