Summarize this content to 400 words in Persian Lang
3 روز برنامه ریزی، 5 روز اجرا و سپس کل کار هفته ها در QA گیر می کند. از طرف دیگر، اگر برداشته شود، منجر به آزمایش ضعیفی می شود که بعداً به آتش نشانی واکنشی منجر می شود.
آشنا به نظر می رسد؟
خوب این حداقل وضعیت تیم من در Shuttl برای هر ویژگی جدیدی بود که توسعه دهندگان ما انتخاب کردند. مهم نیست چقدر بزرگ یا کوچک، QA گلوگاه هر تغییری بود.
اجتناب ناپذیر بود زیرا در غیاب QA، ریسک کیفیت حتی بالاتر بود.
هیچ کس آتش نشانی را به طور مداوم دوست ندارد. بنابراین، راه حل چیست؟
در این وبلاگ، ما در مورد 5 مرحله (به ترتیب) صحبت خواهیم کرد که به شما کمک می کند تا از تاییدیه QA خارج شوید:
وقتی QA درگیر شد، به چپ تغییر مکان دهید
شما آن را کد می کنید، شما مالک آن هستید
در صورت نیاز همیشه پشتشان باشد
برای یافتن الگوهای بهبود به عقب نگاه کنید
از معیارهای صنعت الهام بگیرید
وقتی QA درگیر شد به چپ تغییر مکان دهید
یک فرآیند توسعه معمولی از برنامه ریزی شروع می شود، سپس آن را برنامه ریزی می کنید، آن را آزمایش می کنید، آن را رها می کنید و در صورت وجود هرگونه شکست نظارت می کنید. (همانطور که در زیر نشان داده شده است)
در یک تیم نرم افزاری معمولی، مهندسان متعددی ویژگی های ساختمانی دارند، با این حال 1 یا 2 QA دستی به هر تیم (یا pod) متصل است. هنگامی که ویژگی‌ها/رفع اشکالات توسط توسعه‌دهندگان آماده شد، QAها مسئول انجام آزمایش‌های سیستمی برای اطمینان از صحت هستند و سپس منتشر می‌شوند.
مشکلات زمانی رخ می دهند که چندین ویژگی باید با هم منتشر شوند.این زمانی است که پهنای باند QA در جابجایی بین ویژگی های مختلف خرد می شود.این زمانی است که تیم توسعه با وجود داشتن یک ویژگی آماده، تولید را به تاخیر می اندازد.
گیلاس در بالا این است: پس از یک انتظار طولانی، یک بازخورد وجود دارد و سپس دوباره یک انتظار طولانی – بنابراین چرخه ادامه می یابد!
برای رفع این مشکل، اولین قدم این است که QA را در فرآیند به سمت چپ تغییر دهید.
به جای اینکه آنها تغییرات را به صورت دستی آزمایش کنند، از آنها بخواهید در طول برنامه ریزی ویژگی، یک طرح آزمایشی ایجاد کنند
طرح تستسندی که شامل تمام سناریوهایی است که محصول باید در آن کار کند، تمام موارد گوشه ای و خطرات آبشاری تحت پوشش.
از آنجایی که QA ها متخصص تفکر در مورد کیس های گوشه هستند، رهایی آنها از سنگ زنی کیفیت و پوشش بیشتری را در کیس های آزمایشی امکان پذیر می کند.
پس از آماده شدن طرح تست، به مرحله بعد می رویم⬇️
شما آن را کد می کنید، شما مالک آن هستید
ما توسعه دهندگان بیش از حد قادر و باهوش هستیم که همه چیز را به پایان برسانیم. طرح آزمون بار فکر کردن به موارد غم انگیز را برمی دارد و اکنون تنها کاری که باید انجام دهیم این است که بررسی کنیم، بررسی کنیم، بررسی کنیم
یکی از مزایای داشتن یک طرح تست قبل از برنامه نویسی این است که می توانید طرح خود را مطابق با خود طرح تست درست کنید و بسیاری از روزها (و شب ها) را از زندگی خود نجات دهید.
بنابراین، در حال حاضر هیچ چیز شما را متوقف نمی کند!
در صورت نیاز همیشه پشتشان باشد
با این حال، زندگی چندان ایده آل نیست. و گاهی اوقات ممکن است لازم باشد داده‌های جعلی ایجاد کنید، محیط‌های جدیدی راه‌اندازی کنید یا زمینه‌های اضافی را بدانید که ممکن است جریان شما را کاملاً از مسیر خارج کند.
پس از آن لحظه ای است که باید به یاد داشته باشید که QAها هم تیمی های ما هستند 😄 و از قبل به آنها اطلاع دهید که چه مواردی از طرح آزمون ممکن است به کمک آنها نیاز داشته باشد تا وقتی برای آزمایش آماده شدید، بتوانند از شما در فعال کردن این فعالیت ها حمایت کنند.
راه های متداول برای مشارکت دادن آنها در:
موارد را در خود مرحله برنامه ریزی علامت گذاری کنید
وقتی در آستانه اتمام توسعه هستید، از قبل زمان آنها را رزرو کنید تا محیط خود را آماده کنید
از آنها در استندآپ های خود کمک بخواهید
برای یافتن الگوهای بهبود به عقب نگاه کنید
در طول این تغییر، مطمئناً مراحل مختلفی از مشکل وجود خواهد داشت:
[Pre Change] زمان زیادی صرف انتظار برای تایید QA شده است[During Change] مشکلات دندان درآوردن و تنظیم فرآیند به راحتی تیم شما
[Post Change] تکرارها برای یافتن مواردی که می توان برای دستیابی به اوج بهره وری خود به عنوان یک تیم بهبود بخشید.
یکی از تمرین‌هایی که همیشه به شما کمک می‌کند این است که پس از هر دوی سرعت بر اساس داده‌های واقعی (مانند زیر) مروری به گذشته انجام دهید.
جمع‌آوری داده‌ها می‌تواند زمان‌بر باشد و از این رو خطر از بین بردن همه موارد گذشته را دارد.
(سلب مسئولیت: من هم بنیانگذار آن هستم) ابزاری مانند MiddlewareHQ به شما کمک می‌کند تا با جمع‌آوری تمام بینش‌های فرآیند در یک مکان از ابزارهای خود مانند Jira، Git و غیره، روی کار خود متمرکز شوید.
این را به عنوان یک باند تناسب اندام برای کل تیم در نظر بگیرید در حالی که ورزشکار (تیم) در حال تمرین است 🏃🏼♀️
از معیارهای صنعت الهام بگیرید
ما به عنوان مهندسان نرم افزار با نگاهی به معیارهای فناوری و معیارهای زبان بزرگ شده ایم. با این حال، وقتی نوبت به بهره‌وری ما می‌رسد، هیچ روش استانداردی وجود ندارد.
یک گلوگاه بودن QA یکی از چالش های متعدد در مسیر تحویل نرم افزار شما است.
یک راه عالی برای ادامه پیشرفت (IMO) این است که از معیارهای صنعت برای تیم هایی مانند شما استفاده کنید. معیارهای DORA یک چارچوب عالی توسط Google است و هر سال گزارشی سالانه با معیارهایی در مورد فرآیند تحویل و کیفیت منتشر می‌کند. (در مورد معیارهای DORA بیشتر بخوانید)
این هدفی بود که با آن تصمیم گرفتیم یک پیشنهاد منبع باز برای اندازه گیری معیارهای DORA برای هر تیمی در محیط مورد نظر شما راه اندازی کنیم.
ماموریت ما حذف اصطکاک از فرآیند توسعه و توانمندسازی سازندگان برای ساخت بهتر است! اگر آنچه را که می سازیم دوست دارید، به ما یک ⭐️ بدهید!
✨ پلت فرم بهره وری توسعه دهنده منبع باز برای تیم های مهندسی ✨
مدیریت مهندسی منبع باز که پتانسیل توسعه دهندگان را باز می کند
معرفی
میان افزار یک ابزار منبع باز است که برای کمک به رهبران مهندسی برای اندازه‌گیری و تجزیه و تحلیل اثربخشی تیم‌هایشان با استفاده از معیارهای DORA طراحی شده است. معیارهای DORA مجموعه ای از چهار مقدار کلیدی هستند که بینش هایی را در مورد عملکرد تحویل نرم افزار و کارایی عملیاتی ارائه می دهند.
آن ها هستند:
فرکانس استقرار: فراوانی استقرار کد در تولید یا یک محیط عملیاتی.
زمان سرب برای تغییرات: زمانی که طول می کشد تا یک تعهد به تولید برسد.
میانگین زمان بازیابی: مدت زمانی که طول می کشد تا سرویس پس از یک حادثه یا خرابی بازیابی شود.
تغییر نرخ شکست: درصد استقرارهایی که منجر به خرابی یا نیاز به اصلاح می شود.
فهرست مطالب
…
با آرزوی بهترین ها و امیدواریم که هیچ چیز مانع از رسیدن به هدف شما نشود!
3 روز برنامه ریزی، 5 روز اجرا و سپس کل کار هفته ها در QA گیر می کند. از طرف دیگر، اگر برداشته شود، منجر به آزمایش ضعیفی می شود که بعداً به آتش نشانی واکنشی منجر می شود.
آشنا به نظر می رسد؟
خوب این حداقل وضعیت تیم من در Shuttl برای هر ویژگی جدیدی بود که توسعه دهندگان ما انتخاب کردند. مهم نیست چقدر بزرگ یا کوچک، QA گلوگاه هر تغییری بود.
اجتناب ناپذیر بود زیرا در غیاب QA، ریسک کیفیت حتی بالاتر بود.
هیچ کس آتش نشانی را به طور مداوم دوست ندارد. بنابراین، راه حل چیست؟
در این وبلاگ، ما در مورد 5 مرحله (به ترتیب) صحبت خواهیم کرد که به شما کمک می کند تا از تاییدیه QA خارج شوید:
- وقتی QA درگیر شد، به چپ تغییر مکان دهید
- شما آن را کد می کنید، شما مالک آن هستید
- در صورت نیاز همیشه پشتشان باشد
- برای یافتن الگوهای بهبود به عقب نگاه کنید
- از معیارهای صنعت الهام بگیرید
وقتی QA درگیر شد به چپ تغییر مکان دهید
یک فرآیند توسعه معمولی از برنامه ریزی شروع می شود، سپس آن را برنامه ریزی می کنید، آن را آزمایش می کنید، آن را رها می کنید و در صورت وجود هرگونه شکست نظارت می کنید. (همانطور که در زیر نشان داده شده است)
در یک تیم نرم افزاری معمولی، مهندسان متعددی ویژگی های ساختمانی دارند، با این حال 1 یا 2 QA دستی به هر تیم (یا pod) متصل است. هنگامی که ویژگی‌ها/رفع اشکالات توسط توسعه‌دهندگان آماده شد، QAها مسئول انجام آزمایش‌های سیستمی برای اطمینان از صحت هستند و سپس منتشر می‌شوند.
مشکلات زمانی رخ می دهند که چندین ویژگی باید با هم منتشر شوند.
این زمانی است که پهنای باند QA در جابجایی بین ویژگی های مختلف خرد می شود.
این زمانی است که تیم توسعه با وجود داشتن یک ویژگی آماده، تولید را به تاخیر می اندازد.
گیلاس در بالا این است: پس از یک انتظار طولانی، یک بازخورد وجود دارد و سپس دوباره یک انتظار طولانی – بنابراین چرخه ادامه می یابد!
برای رفع این مشکل، اولین قدم این است که QA را در فرآیند به سمت چپ تغییر دهید.
به جای اینکه آنها تغییرات را به صورت دستی آزمایش کنند، از آنها بخواهید در طول برنامه ریزی ویژگی، یک طرح آزمایشی ایجاد کنند
طرح تست
سندی که شامل تمام سناریوهایی است که محصول باید در آن کار کند، تمام موارد گوشه ای و خطرات آبشاری تحت پوشش.
از آنجایی که QA ها متخصص تفکر در مورد کیس های گوشه هستند، رهایی آنها از سنگ زنی کیفیت و پوشش بیشتری را در کیس های آزمایشی امکان پذیر می کند.
پس از آماده شدن طرح تست، به مرحله بعد می رویم⬇️
شما آن را کد می کنید، شما مالک آن هستید
ما توسعه دهندگان بیش از حد قادر و باهوش هستیم که همه چیز را به پایان برسانیم. طرح آزمون بار فکر کردن به موارد غم انگیز را برمی دارد و اکنون تنها کاری که باید انجام دهیم این است که بررسی کنیم، بررسی کنیم، بررسی کنیم
یکی از مزایای داشتن یک طرح تست قبل از برنامه نویسی این است که می توانید طرح خود را مطابق با خود طرح تست درست کنید و بسیاری از روزها (و شب ها) را از زندگی خود نجات دهید.
بنابراین، در حال حاضر هیچ چیز شما را متوقف نمی کند!
در صورت نیاز همیشه پشتشان باشد
با این حال، زندگی چندان ایده آل نیست. و گاهی اوقات ممکن است لازم باشد داده‌های جعلی ایجاد کنید، محیط‌های جدیدی راه‌اندازی کنید یا زمینه‌های اضافی را بدانید که ممکن است جریان شما را کاملاً از مسیر خارج کند.
پس از آن لحظه ای است که باید به یاد داشته باشید که QAها هم تیمی های ما هستند 😄 و از قبل به آنها اطلاع دهید که چه مواردی از طرح آزمون ممکن است به کمک آنها نیاز داشته باشد تا وقتی برای آزمایش آماده شدید، بتوانند از شما در فعال کردن این فعالیت ها حمایت کنند.
راه های متداول برای مشارکت دادن آنها در:
- موارد را در خود مرحله برنامه ریزی علامت گذاری کنید
- وقتی در آستانه اتمام توسعه هستید، از قبل زمان آنها را رزرو کنید تا محیط خود را آماده کنید
- از آنها در استندآپ های خود کمک بخواهید
برای یافتن الگوهای بهبود به عقب نگاه کنید
در طول این تغییر، مطمئناً مراحل مختلفی از مشکل وجود خواهد داشت:
- [Pre Change] زمان زیادی صرف انتظار برای تایید QA شده است
- [During Change] مشکلات دندان درآوردن و تنظیم فرآیند به راحتی تیم شما
- [Post Change] تکرارها برای یافتن مواردی که می توان برای دستیابی به اوج بهره وری خود به عنوان یک تیم بهبود بخشید.
یکی از تمرین‌هایی که همیشه به شما کمک می‌کند این است که پس از هر دوی سرعت بر اساس داده‌های واقعی (مانند زیر) مروری به گذشته انجام دهید.
جمع‌آوری داده‌ها می‌تواند زمان‌بر باشد و از این رو خطر از بین بردن همه موارد گذشته را دارد.
(سلب مسئولیت: من هم بنیانگذار آن هستم) ابزاری مانند MiddlewareHQ به شما کمک می‌کند تا با جمع‌آوری تمام بینش‌های فرآیند در یک مکان از ابزارهای خود مانند Jira، Git و غیره، روی کار خود متمرکز شوید.
این را به عنوان یک باند تناسب اندام برای کل تیم در نظر بگیرید در حالی که ورزشکار (تیم) در حال تمرین است 🏃🏼♀️
از معیارهای صنعت الهام بگیرید
ما به عنوان مهندسان نرم افزار با نگاهی به معیارهای فناوری و معیارهای زبان بزرگ شده ایم. با این حال، وقتی نوبت به بهره‌وری ما می‌رسد، هیچ روش استانداردی وجود ندارد.
یک گلوگاه بودن QA یکی از چالش های متعدد در مسیر تحویل نرم افزار شما است.
یک راه عالی برای ادامه پیشرفت (IMO) این است که از معیارهای صنعت برای تیم هایی مانند شما استفاده کنید. معیارهای DORA یک چارچوب عالی توسط Google است و هر سال گزارشی سالانه با معیارهایی در مورد فرآیند تحویل و کیفیت منتشر می‌کند. (در مورد معیارهای DORA بیشتر بخوانید)
این هدفی بود که با آن تصمیم گرفتیم یک پیشنهاد منبع باز برای اندازه گیری معیارهای DORA برای هر تیمی در محیط مورد نظر شما راه اندازی کنیم.
ماموریت ما حذف اصطکاک از فرآیند توسعه و توانمندسازی سازندگان برای ساخت بهتر است! اگر آنچه را که می سازیم دوست دارید، به ما یک ⭐️ بدهید!
✨ پلت فرم بهره وری توسعه دهنده منبع باز برای تیم های مهندسی ✨
مدیریت مهندسی منبع باز که پتانسیل توسعه دهندگان را باز می کند
معرفی
میان افزار یک ابزار منبع باز است که برای کمک به رهبران مهندسی برای اندازه‌گیری و تجزیه و تحلیل اثربخشی تیم‌هایشان با استفاده از معیارهای DORA طراحی شده است. معیارهای DORA مجموعه ای از چهار مقدار کلیدی هستند که بینش هایی را در مورد عملکرد تحویل نرم افزار و کارایی عملیاتی ارائه می دهند.
آن ها هستند:
- فرکانس استقرار: فراوانی استقرار کد در تولید یا یک محیط عملیاتی.
- زمان سرب برای تغییرات: زمانی که طول می کشد تا یک تعهد به تولید برسد.
- میانگین زمان بازیابی: مدت زمانی که طول می کشد تا سرویس پس از یک حادثه یا خرابی بازیابی شود.
- تغییر نرخ شکست: درصد استقرارهایی که منجر به خرابی یا نیاز به اصلاح می شود.
فهرست مطالب
…
با آرزوی بهترین ها و امیدواریم که هیچ چیز مانع از رسیدن به هدف شما نشود!
