چرا توسعه دهندگان نرم افزار معیارهای DORA را ترجیح می دهند

تیم های مهندسی نرم افزار انواع روش ها را برای اندازه گیری فرآیند توسعه نرم افزار و بهره وری توسعه دهندگان امتحان کرده اند. در اینجا دلیل تبدیل شدن معیارهای DORA به استاندارد صنعتی است.

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

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

اما هنگامی که هیئت مدیره، رهبران مهندسی و توسعه دهندگان به طور یکسان می خواهند بدانند که آیا یک فرآیند کار می کند، آیا تیم کارآمد است و چگونه بهتر باشیم، ما به راهی برای اندازه گیری کار در حال انجام نیاز داریم.< /p>

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

ما بیشتر به آن خواهیم پرداخت، اما ابتدا، بیایید انواع دیگر معیارهای موجود را درک کنیم.

معیارهای کسب و کار

معیارهای کسب و کار را می توان به عنوان اندازه گیری زمان جریان یک توسعه دهنده در نظر گرفت. اگر جریان شما دو یا سه بار در روز قطع شود، می‌دانید که انجام کارها تقریباً غیرممکن است.

در تلاش برای محافظت از زمان توسعه‌دهندگان، یک دسته کامل از ابزارهای کارآمدی مهندسی توسعه داده شد که به سیستم‌ها و تقویم‌های منابع انسانی متصل می‌شوند. آنها سعی می‌کنند ارزیابی کنند که آیا یک توسعه‌دهنده سوئیچ‌های زمینه، جلسات، و فرآیندهای زمان‌بر زیادی برای دنبال کردن دارد یا خیر.

در نهایت، این معیارها سعی می‌کنند با نگاه کردن به جنبه انسانی کدنویسی، از فرسودگی شغلی جلوگیری کنند، که مطمئناً مهم است، اما این معیارها چندان قابل اجرا نیستند.

اگر می‌دانید که برنامه‌نویسان در جلسات بسیار زیادی شرکت می‌کنند، چگونه محیطی را ساختار می‌دهید که جلسات لازم در آن برگزار می‌شود اما جریان نیز کارآمدتر است؟ معیارهای مشغله همراه با مجموعه ای از بهبودهای بالقوه برای راهنمایی شما نیستند.

چارچوب فضایی

نیکول فورسگرن، یکی از بنیانگذاران DORA (ارزیابی تحقیقات DevOps)، این چارچوب را ایجاد کرد که هدف آن درک بهره وری توسعه دهندگان اما به جای معیارهای سخت، چارچوب SPACE بر وضعیت ذهنی و رفاه فیزیکی توسعه‌دهندگان تمرکز دارد، که بدون شک عوامل مهمی در لذت کلی توسعه‌دهندگان از کارشان و عملکرد مهندسی تیم هستند.

چارچوب SPACE پنج بعد بهره وری توسعه دهندگان را می سنجد:

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

مثل معیارهای Busyness، چارچوب SPACE اطلاعات معتبری را جمع‌آوری می‌کند، اما عمل کردن به آن دشوار است. به آن بیشتر به عنوان بهترین شیوه‌هایی فکر کنید که اندازه‌گیری آن‌ها از روی کار انجام شده دشوار است. موجز بودن و نتایج هدف گرا را از دست داده است.

معیارهای مدرسه قدیمی

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

اما توسعه دهندگان می دانند که در واقع چیز مهمی را اندازه گیری نمی کنند. من می توانم مهم ترین پنج خط کد را در برنامه بنویسم که آنقدر پیچیده هستند که دو هفته طول می کشد تا مطمئن شوم که پنج خط کد مناسب هستند. یا می توانم پنج میلیون خط کد بنویسم که خیلی مفید نیستند. اندازه‌گیری تعداد درخواست‌های کشش ادغام شده نیز مشابه است. این می‌تواند کمی در مورد اندازه کلی دسته‌تان به شما بگوید، اما برای کمک به بهبود یک تیم بسیار روشنگر یا مفید نیست.

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

معیارهای جریان ارزش

هدف معیارهای جریان ارزش آگاهی از توزیع سرمایه‌گذاری‌های مهندسی است، یعنی اینکه این سرمایه‌گذاری‌ها به کجا می‌رود. این به ویژه در مواردی مفید است که سازمان‌ها اعتبار تحقیق و توسعه را از دولت دریافت می‌کنند و نیاز دارند تا میزان کار تحقیق و توسعه، رفع اشکالات، روشن نگه داشتن چراغ‌ها و غیره را طبقه‌بندی کنند. چگونه به بهبود آنها کمک کنیم.

معیارهای DORA

واضح است که معیارهای بالا همه ثابت نشده اند. اما چرا بسیاری از تیم ها و سازمان ها به جای آن از معیارهای DORA استقبال می کنند؟ شش دلیل کلیدی به ذهن می رسد.

1. آنها توسط تحقیقات پشتیبانی می شوند، که ارتباط آماری معنی داری را بین معیارهای DORA مثبت و عملکرد سازمانی مثبت نشان می دهد. معیارهای DORA یک احساس واقعی نیستند.
2. متریک‌های DORA تبلور روش‌های DevOps است که سال‌هاست اما به روشی مختصر از آنها استفاده می‌کنیم. معیارهای DORA نشان می دهد که تیم شما در بهبود مستمر و یادگیری چقدر خوب عمل می کند. به عنوان مثال، ما از طریق تمرین متوجه شده‌ایم که کاهش اندازه دسته مؤثر بود زیرا به ما امکان می‌داد کار را سریع انجام دهیم. DORA آن چیزها را در دسته‌هایی از معیارها قرار داد – فرکانس استقرار، زمان تغییر، نرخ شکست تغییر، و میانگین زمان بازیابی – و نشان داد که چگونه با یکدیگر ارتباط دارند. از دیدگاه یک پزشک، معیارهای DORA کارهایی را که ما همیشه انجام داده‌ایم نام‌گذاری کرده است.
3. سنجه‌های DORA آن را ساده نگه می‌دارند. سازمان‌ها معمولاً هنگام تصمیم‌گیری درباره اینکه چه چیزی را از نظر مهندسی اندازه‌گیری کنند، گرفتار می‌شوند. DORA به تیم‌ها اجازه می‌دهد با معیارهایی شروع کنند که به خوبی با معیارهای صنعت تعریف شده‌اند و خرد جمعی را پشت سر خود دارند.
4. معیارهای DORA معیارهای تیمی هستند و بنابراین همان ترس و نگرانی هایی را که معیارهای فردی برای توسعه دهندگان ایجاد می کند ایجاد نمی کنند. معیارهای DORA هنوز هم می توانند سلاح شوند، اما آنها تشخیص می دهند که توسعه نرم افزار یک ورزش تیمی است. اگر درباره DORA و گزارش‌های وضعیت DevOps مطالعه کنید، همه چیز درباره تیم ها.
5. متریک‌های DORA فعالیت‌های پیچیده را به معیارهای ساده و سخت تقطیر می‌کنند. آن‌ها می‌توانند داده‌ها را از کنترل منبع، سیستم‌های بررسی منبع، ردیاب‌های موضوع، ارائه‌دهندگان مدیریت حادثه و ابزارهای سنجش گرفته و آنها را به چهار معیار کلیدی تبدیل کنند. این امکان مقایسه معیارهای DORA از یک تیم به تیم دیگر را فراهم می کند، حتی اگر همه تیم ها برابر نیستند. تحقیقات DORA به تیم‌ها این امکان را می‌دهد تا بر اساس نحوه عملکردشان در چهار معیار کلیدی ذکر شده در بالا، خود را در دسته‌های عملکرد پایین، متوسط ​​و بالا قرار دهند. این به تیم ها اجازه می دهد تا در مورد نحوه عملکرد خود در مقایسه با سایر تیم ها نتیجه گیری های گسترده ای بگیرند.
6. معیارهای DORA محدوده وسیعی را شامل می‌شود، از جمله فرآیند توسعه‌دهنده و نحوه ارائه آن فرآیند به مشتریان. معیارهای DORA از زمانی که توسعه‌دهنده شروع به کدنویسی می‌کند تا زمانی که تیم چیزی را به تولید تحویل می‌دهد، به این فرآیند نگاه می‌کند. آنها تشخیص می‌دهند که هیچ‌کس نمی‌خواهد رویکرد «سریع حرکت کنید و چیزها را بشکنید». معیارهای DORA رویکرد سالم تر «حرکت سریع و مسئولانه» را تشویق می کند.

متریک‌های DORA بهترین گزینه برای تبدیل شدن به بهترین تیم مهندسی نیستند—هیچ مجموعه‌ای از معیارها چنین نیست. اما معیارهای DORA به صنعت نرم‌افزار کمک کرده است تا حول یک سیستم علمی اندازه‌گیری تحویل نرم‌افزار و عملکرد عملیاتی به گونه‌ای جمع شود که توسعه‌دهندگان واقعاً برایشان مهم نیست. شاید حتی آن را دوست داشته باشند.

دیلان اتکین مدیر عامل و یکی از بنیانگذاران Sleuth است، پیشرو ردیاب معیارهای مبتنی بر استقرار . دیلن به عنوان یکی از ۲۰ کارمند اول Atlassian، مهندس موسس و اولین معمار جیرا بود. او مهندسی محصولات را در مقیاس Bitbucket و Statuspage رهبری کرده است. او دارای مدرک کارشناسی ارشد در رشته علوم کامپیوتر از ASU است.

—

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.