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

شخصیت توسعه‌دهنده

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

انواع مختلفی از توسعه‌دهندگان وجود دارد، اما اگر منظور ما کسی است که کارش اضافه کردن ویژگی‌های جدید، رفع اشکالات و شرکت در تصمیم‌گیری‌های معماری است، شخصیت بالا کاملاً مناسب اوست. در هر صورت، توسعه‌دهندگان در حالت جریان کار می‌کنند و وقفه‌ها بر بهره‌وری تأثیر می‌گذارند.

راه قدیمی

بلیط‌های جیرا

بعضی از سازمان‌ها به JIRA به عنوان مدیر وظایف خود متکی هستند که در آن ویژگی‌ها و اشکالات درخواستی به صورت تیکت ثبت می‌شوند. کسی که بیشترین تیکت را در یک بازه زمانی می‌بندد، مطمئناً پربازده‌ترین است، درست است؟

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

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

چیزی مثل اضافه کردن یک «منوی کشویی ساده» می‌تواند به یک مشکل اساسی تبدیل شود اگر با تنظیمات فعلی تداخل داشته باشد یا برای ادامه کار نیاز به حل و فصل بدهی‌های فنی قبلی داشته باشد. شاید بتوانید از یک مهندس بخواهید که تیکت‌های دقیقی بنویسد، اما این کار اتلاف وقت گرانبهای توسعه‌دهنده خواهد بود. در نهایت، حل و فصل JIRA یا هر نوع تیکتی، شاخص خوبی نیست.

امتیازهای داستان

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

امروزه بسیاری از شرکت‌ها از این معیارها به عنوان معیاری برای بهره‌وری استفاده می‌کنند و تیم‌ها بر اساس تعداد امتیازاتی که در اسپرینت فعلی کسب کرده‌اند و خدای نکرده اگر کمتر از اسپرینت قبلی بوده باشد، قضاوت می‌شوند. این امر به طور مؤثر باعث بازی دادن سیستم و ارائه تخمین‌های طولانی‌تر می‌شود که هدف را نقض می‌کند.

جلسات پیشرفت

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

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

راه جدید

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

ارائه نرم‌افزار اساساً با چهار معیار کلیدی اندازه‌گیری می‌شود:

زمان تحویل تغییر: ما با چه سرعتی حرکت می‌کنیم؟

فراوانی استقرار: چند وقت یکبار به سمت تولید پیش می‌رویم؟

درصد شکست تغییر: استقرارهای ما چقدر قابل اعتماد هستند؟

زمان بازیابی پس از شکست در استقرار: چقدر سریع می‌توانیم بازیابی کنیم؟

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

اندازه‌گیری معیارهای DORA و موارد دیگر

در سازمان‌های کوچک با تعداد کمی توسعه‌دهنده، استفاده از ابزارها برای اندازه‌گیری بهره‌وری تیم ضروری نیست، اما با رشد تیم، مواردی که باید پیگیری شوند نیز باید انجام شوند. اینجاست که می‌توانید از ابزارهای مشاهده‌پذیری که معیارهای DORA را اندازه‌گیری می‌کنند، مانند Swarmia، LinearB و Codemetrics، استفاده کنید.

من به طور خاص Codemetrics را در اینجا ذکر خواهم کرد، زیرا ارزان‌ترین قیمت را برای هر صندلی دارد، به علاوه این واقعیت که من در ابتدا مدتی با آن همکاری داشتم. (افشای کامل)

سخت‌ترین مرحله و تصمیم، دادن مجوزهای مشاهده برای انتخاب بخشی از مخزن کد شماست، اما این ابزارها از متادیتای درخواست‌های pull برای محاسبه تمام آمار استفاده می‌کنند تا کد شما دیده نشود و ایمن بماند.

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

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

تست مسدودسازی تبلیغات