جستجو برای:
سبد خرید 0
  • خانه
  • دوره های آموزشی
  • مدرسان
  • مقالات
  • تماس با ما
  • باشگاه پیشرفت

ورود

رمز عبور را فراموش کرده اید؟

هنوز عضو نشده اید؟ عضویت در سایت
  • پشتیبانی سریع (واتساپ): ۰۹۱۲۰۳۷۵۱۵۶
  • info@scrumschool.ir
  • تدریس در مدرسه اسکرام
0
مدرسه اسکرام
  • خانه
  • دوره های آموزشی
  • مدرسان
  • مقالات
  • تماس با ما
  • باشگاه پیشرفت
آخرین اطلاعیه ها
جهت نمایش اطلاعیه باید وارد سایت شوید
ورود / عضویت

وبلاگ

مدرسه اسکراموبلاگبدون دسته بندیعامل کیفیت برای دستیابی به تحویل قابل پیش بینی

عامل کیفیت برای دستیابی به تحویل قابل پیش بینی

4 آبان 1399
ارسال شده توسط کسری طوفانی
بدون دسته بندی
117 بازدید
عامل کیفیت برای دستیابی به تحویل قابل پیش بینی

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

 

من ارزیابی های 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

 

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

بعدی KISS در ازای بدهی فنی؟!
قبلی فعلاً از آبنباتت لذت ببر!

دیدگاهتان را بنویسید لغو پاسخ

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

جستجو برای:
  • محبوب
  • جدید
  • دیدگاه ها
پشتیبانی

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

Awareness
We are not affiliated with Scrum.org and do not claim that our contents and classes are endorsed and confirmed by Scrum.org. Furthermore, we are not a representative of Scrum.org.
NOTE: All following words, acronyms, and phrases are trademarks belonging to Scrum.org:
PSM I, PSM II, PSM III, PSPO I, PSPO II, PSPO III, PSD I, SPS, PAL I, PSK I, PSU I, Professional Scrum Master, Professional Scrum Product Owner, Professional Scrum Developer, Scaled Professional Scrum, Professional Agile Leadership, Professional Scrum with Kanban, Professional Scrum with User Experience.

خبرنامه

چیزی را از دست ندهید! ثبت نام کنید و از رویدادها، تخفیف ها و دوره های جدید ما مطلع باشید.

    Scrum School 2021 © | کلیۀ حقوق برای مدرسه اسکرام محفوظ است و استفاده از مطالب در جاهای دیگر صرفا با ذکر منبع و لینک به سایت مدرسه اسکرام بلامانع است.
    رزرو وقت مشاوره
    مسیر شغلی اسکرام
    اشتراک گذاری در شبکه های اجتماعی
    ارسال به ایمیل
    https://scrumschool.ir/?p=6678
    لیست علاقه مندی ها 0
    صفحه لیست علاقه مندی را باز کنید به خرید ادامه دهید
    مرورگر شما از HTML5 پشتیبانی نمی کند.