اندازه گیری سرعت مهندسی تمام مقدار را از دست می دهد

دل مشغولی ما به سرعت توسعه نرم افزار، سرعت را به معیار اصلی موفقیت برای تیم های مهندسی تبدیل کرده است – به ضرر افراد، فرآیند و ارزش محصول.

در دنیای تحویل مداوم، انتشار مکرر برنامه‌نویس به وضعیت موجود تبدیل شده است و اکثر شرکت‌ها برای به‌روزرسانی روزانه محصولات خود رقابت می‌کنند. با پشتیبانی از ابر و فناوری‌های اتوماسیون پیشرفته، خط‌های لوله CI/CD ما غوغا می‌کنند (همانطور که نگرانی‌های امنیتی و کیفیتی نیز وجود دارد). اما با توجه به تمرکز سرعت، سرعت به معیار اصلی موفقیت برای تیم های مهندسی تبدیل شده است – به ضرر افراد، فرآیند و ارزش محصول.

وقتی سرعت مهندسی تنها معیار باشد، چه چیزی را از دست می دهیم؟ خارج از این میدان دید باریک چه می گذرد؟ و این معیارهای نزدیک بینی چه چیزی را از دست می دهند؟

توسعه نرم افزار در تاریکی

سرعت نقطه داستان با افزایش scrum به محرک غالب چرخه های عمر توسعه نرم افزار چابک (SDLC) تبدیل شده است.

تیم چند نقطه داستانی را در این هفته تکمیل کرد؟ چگونه می‌توانیم آن‌ها را وادار کنیم تا امتیازات بیشتری ارائه دهند، در حالی که هنوز معیارهای پذیرش را دارند؟

سرعت مترادف با موفقیت تلقی می شود و شتاب به عنوان تمرکز اصلی هر شرکت مهندسی موفق مورد ستایش قرار می گیرد. نکات داستانی بیشتری ارائه دهید و شما به وضوح “کار را انجام می دهید.”

این انگیزه بدون منطق نیست. از دیدگاه C-suite، یک محصول عالی که لحظه‌ی حضور خود را در بازار از دست بدهد، ارزش زیادی ندارد. مطمئناً، ممکن است پر از نبوغ مهندسی باشد، اما اگر ارزش تجاری کمی ایجاد کند، به سرعت بیشتر به «یادگار موزه» تبدیل می‌شود تا «تغییرگر بازی صنعت». اول بودن ارزش دارد. در واقع، یک مطالعه نشان داد که تسریع زمان عرضه به بازار تنها ۵ درصد می‌تواند بازگشت سرمایه را تقریباً ۱۳ افزایش دهد. %.

با این حال، من معتقدم که یک وسواس ساده در مورد سرعت، چندین عامل حیاتی برای بهینه سازی تأثیر واقعی هر راه حل نرم افزاری را از دست می دهد.

همه سوالاتی را که نمی‌پرسیم وقتی به شدت روی سرعت تمرکز می‌کنیم در نظر بگیرید:

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

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

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

معیارهای ما چه چیزی را از دست می دهند؟

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

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

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

مهندسان آن بلیط ها را کار می کنند و کد ایجاد و مستقر می کنند. و این سرعتی است که آنها با آن این استقرارها را ارائه می دهند که برای ارزیابی بهره وری اندازه گیری می شود.

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

برای مثال، فرض کنید بلیتی دریافت می‌کنید که الزامات آن همه ناشی از سوء تفاهم در سمت محصول است، چیزی که احتمالاً فقط یک مهندس می‌تواند آن را ببیند – و شما ۲۰ دقیقه را صرف این واقعیت می‌کنید. این زمان گرانبهایی است که می‌توانستید برای نوشتن یک تست در یک تابع یا توسعه چیز دیگری که سوزن را به جلو حرکت می‌دهد، صرف کنید. و گاهی اوقات، ممکن است متوجه نادرست بودن بلیط نشوید تا زمانی که زمان قابل توجهی را صرف کدنویسی نکرده باشید.

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

تاریخ ها باعث تصمیم گیری های بد می شوند

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

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

اما هی، به موقع بود.

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

طبق U.S. اداره آمار کار، تقاضا برای توسعه‌دهندگان نرم‌افزار از سال ۲۰۲۱ تا ۲۰۳۱ به میزان ۲۵ درصد افزایش خواهد یافت. اکنون زمانی نیست که عزم برخی از با ارزش‌ترین کارمندان خود را آزمایش کنید، یا سعی کنید بفهمید که چقدر فاصله دارید. می تواند آنها را فشار دهد – به خصوص زمانی که محصول نهایی نیز در نتیجه آسیب می بیند.

مرغ یا خوک؟

در هر چرخه عمر توسعه نرم افزار چابک (SDLC)، حل مسئله یک بخش کلیدی و جاسازی شده از فرآیند است، و ما می دانیم که خروجی توسعه هرگز کامل نخواهد بود (از این رو مرحله آزمایش بعدی). اما بدون هیچ KPI مربوط به کیفیت بلیط، تیم محصول انگیزه کمی برای تجدید نظر در روند خود ندارد، بنابراین سیستم همچنان به تولید ضایعات غیرضروری ادامه می‌دهد – زباله‌هایی که می‌توانند تیم مهندسی را در تقلای ساعتی قرار دهند.

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

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

آن را بی‌عیب نگه دارید، به حرکت ادامه دهید

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

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

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

و بیایید اصول اصلی پس از مرگ “بی تقصیر” را فراموش نکنیم. بدون مسئولیت پذیری مشترک، سازمان ها نمی توانند درک دقیقی از آنچه در طول هر دوی سرعت معین رخ داده است، ایجاد کنند. در یک فرهنگ بی‌عیب، صرف‌نظر از اینکه «تقصیر» چه کسی بوده است، هر دو تیم با هم کار می‌کنند تا بفهمند چرا چیزها اشتباه پیش رفتند تا پیچیدگی کامل آن اتفاق را درک کنند و بفهمند که چگونه آن را اصلاح کنیم. آینده. اگر تیم‌های مهندسی نیاز به یافتن راه‌هایی برای کار مؤثرتر داشته باشند، خوب است، اما تیم‌های محصول احتمالاً باید برای بهبود مستمر بلیط‌های خود نیز تلاش کنند.

همه دور هم جمع شوند

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

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