تجربه‌ی دولوپری (DevEx): روش‌های اجرای درست!

در مقاله‌ی قبلی به اهمیت تجربه‌ی توسعه‌دهندگی یا تجربه‌ی دولوپری (DevEx یا DX) پرداختیم. نوبتی هم باشد، نوبت به اندازه‌گیری و پیاده‌سازی و بهبود این موضوع می‌رسد. هیچکدام از ما نمیخواهیم درآمد کمتر، رضایت شغلی کمتر و دردسر بیشتر در کار خود داشته باشیم و امنیت شغلی خوبی را نیز تجربه نکنیم! بیایید این وضعیت را درست کنیم:

همانطور که گفتیم هیچ استانداردی در حال حاضر (و شاید هم همیشه) برای تجربه‌ی دولوپری وجود ندارد. هیچ استاندارد صنعتی‌ای هم برای اندازه‌گیری آن وجود ندارد. البته استاندارد 4کلید DORA یک مقیاس خوب برای سازمان‌ها و کسب و کارها از نظر DevOps performance ارائه می‌دهد که می‌تواند به خوبی برای DX هم استفاده شود:

• نرخ دیپلویمنت یا Deployment frequency (DF) :
  چقدر به صورت مرتب نسخه‌های جدید یا نرم افزار جدید در سازمان عرضه می‌شود و هرچه بالاتر باشد بهتر است.
• زمان پایه تغییرات یا Lead time for changes (LT) :
  زمانی که برای تغییرات درخواست شده یا تعیین شده طول می‌کشد تا انجام و دیپلوی شوند و هرچه پایین تر باشد بهتر است.
• متوسط زمان ریکاوری یا Mean time to recovery (MTTR) :
  زمان متوسطی که طول می‌کشد تا از شرایط بد ( failure ) نجات پیدا کنیم و هرچه پایین تر باشد بهتر است.
• نرخ تغییرات منجر به خطا یا Change failure rate (CFR) :
  درصد تغییراتی که منجر به failure می‌شوند و هرچه پایین تر باشد بهتر است.

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

زمان کمتر تا اولین contribution به این معناست که دولوپر جدید تمام context و مفاهیم لازم برای شروع کار را در اختیار دارد و همچنین احساس می‌کند که می‌تواند ارزش خلق کند.

این کار البته با حرف و روحیه دادن محقق نمی‌شود. درست است که در شرایط خوب DevEx ، اکثر برنامه‌نویسان خوشحال هستند و حس می‌کنند که مفید هستند؛ اما این احساس خوشحالی هدف و نتیجه‌ی تجربه‌ی دولوپری خوب است و نه برعکس. به صورت کلی کار برنامه‌نویسی سنگین و فرسایشی است و هیچکس دوست ندارد بعد از اینکه کار خود را انجام داد مدتها منتظر تایید pull request بماند و یا حتی چندین pull request را در طول روز بررسی کند! تجربه‌ی دولوپری خوب در زمینه‌های مختلف فرسایش را کاهش می‌دهد.

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

درست است که رضایت شغلی و خوشحالی توسعه‌دهنده‌ها یکی از اهداف DX است اما این کار با حقوق بالا، حجم کار پایین (یا حتی بدون کار) نیز محقق می‌شود و این نوع برخورد با DX اصلا با اهداف سازمان هم راستا نیست! برای درک بهتر هدف DX باید دقت کنیم که ابتدا سازمان باید روش درست اندازه‌گیری کارایی و performance سیستم خودش را در اختیار داشته باشد. در واقع تجربه‌ی دولوپری باید بر اساس نیاز سازمان ایجاد شود نه برعکس.

چطور باید تجربه‌ی دولوپری را از دید توسعه دهنده و سازمان ارزیابی کرد؟

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

علیرغم اینکه اکثر سازمان‌ها از این مسئله غافل می‌شوند به نظر من این مسئله اصلا اختیاری نیست و نباید از آن صرف نظر شود. اهمیت دادن به DevEx آینده‌ی سازمان و کسب و کار را بیشتر تضمین می‌کند و توسعه‌دهندگان نیز امنیت و رضایت شغلی بیشتری خواهند داشت! این یک بازی بُرد-بُرد است!

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

برای تجربه‌ی توسعه‌دهندگی بهتر باید فرآیندها، دیپلویمنت و تست‌ها را بهینه‌تر کنیم.

هدف از خلق pull request ها در واقع بهبود collaboration به منظور بهبود تجربه‌ی توسعه‌دهندگی بود. هر سازمان باید تجربه‌ی توسعه‌دهندگی را درک کند و وضعیت فعلی DX خود را بفهمد و فرسایش‌ها را پیدا کند.

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

کار و آزمون و خطای زیادی برای بهینه کردن تجربه‌ی توسعه‌دهندگی لازم است ولی نتیجه‌ی آن این زحمت و آزمون و خطا را توجیح می‌کند.

پس بفهمید و بهبود ببخشید و نظارت کنید.

شکی نیست که هوش‌مصنوعی مولد ( generative AI ) نقش پر رنگی در آینده‌ی تجربه‌ی دولوپری بازی می‌کند. همین حالا هم به لطف ابزاری مثل cursor توسعه‌دهندگان می‌توانند سریع تر کدهای با کیفیت‌تری را بنویسند.

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

در حال حاضر Generative AI پتانسیل این را دارد که به برنامه‌نویسان خوب، باسواد و مسلط کمک کند تا حجم کار بسیار بیشتری انجام دهند و به کمک آن می‌توانیم workflowهای پیچیده‌تر و بهتری خلق کنیم.

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

سازمان‌ها کنترل زیادی روی تجربه‌ی تیم‌های development خود دارند، این بدین معنیست که می‌توانند و باید developer experience خود را بهبود ببخشند. هر تیم و سازمان نیازها و چالش‌های متفاوتی از دیگری دارد و نیاز است که استراتژی‌های مخصوص به خود را برای کشف و بهبود developer experience بچینند. اگر به DX اهمیت بدهید نتیجه‌ی آن افزایش رضایت شغلی، جلو افتادن از نظر زمانی و توسعه‌ی محصول و در نهایت افزایش درآمد است. برای چیدن استراتژی می‌توانید به موارد زیر توجه کنید:

ابزار و تکنولوژی‌ها

در یک کلمه DevOps! ابزار و تکنولوژی‌ها، workflowها و pipeline و ... همگی بخشی از فرآیند تجربه‌ی دولوپری سازمان شما هستند. به DevOps به عنوان وظیفه‌ی بخشی از اعضای ارشد تیم توسعه و نه یک تیم مجزا فکر کنید. برنامه‌نویسان ارشد شما باید به ابزار لازم و ضروری کار خود و اجرای آنها به صورت درست، طراحی workflowها و pipelineها مسلط باشند. بیشتر تجربه‌ی دولوپری خوب را پیاده‌سازی درست DevOps تشکیل می‌دهد. اجرای اتوماتیک تست‌ها بعد از push شدن کد، بررسی کیفیت کد(pre-commit و SonarQube و ...)،مدیریت خطاها و لاگ‌ها (Sentry و DataDog و ...) و دیپلویمنت سریع و با کیفیت (CI/CD)، همگی به بهبود تجربه‌ی دولوپری کمک می‌کنند.

داکیومنت کردن

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

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

پروسه‌ی آنبوردینگ

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

پشتیبانی و کامیونیتی

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

فرهنگ و محیط شغلی

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

سایلنت کردن تلفن‌همراه و خاموش کردن ناتیفیکیشن‌ها نیز کار بدی نیست. به شخصه در زمانی که تمرکز عمیق دارم تمام ارتباط خود را موقتا با دنیا قطع می‌کنم. تمرکز بخش مهمی از کار تمامی اعضای سازمان است و بهتر است به کیفیت آن اهمیت داده شود.

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

آنبوردینگ:

• زمان اجرای E2E اولیه: برای لپتاپی که کد روی آن قرار ندارد، چقدر طول می‌کشد تا بتواند تمام سیستم را به شکل end-to-end اجرا کند؟
• زمان تا اولین کامیت: چقدر طول می‌کشد تا بعد از اجرا اولیه بتوان اولین تغییر را به صورت local انجام داد و تست کرد و به صورت بالقوه آماده‌ی کامیت کردن شد؟

اثرگذاری:

• افزایش سرعت: با چه سرعتی تغییرات را به دست کاربر نهایی می‌رسانیم؟
• افزایش کیفیت: چقدر فرآیند debug و test ما ساده است و چقدر درگیر debug و test می‌شویم؟
• افزایش اتوماسیون: چقدر از کارها را اتومیت کرده ایم و چقدر دیگر می‌توانیم از اتوماسیون استفاده کنیم؟

اهداف:

• زمان بهینه: چقدر از زمان تیم به صورت بهینه صرف می‌شود تا تسک از زمان تعریف شدن به وضعیت done برسد؟
• زمان راه‌اندازی: چقدر زمان اضافه از تیم برای کارهای دستی و manual تلف می‌شود؟
• کاهش خطا: چقدر خطا و defect به برنامه وارد می‌شود؟

قرار نیست که در یک لحظه و با یک کلیک به بهترین حد تجربه‌ی دولوپری برسیم؛ رسیدن به DX بهتر یک فرآیند مرحله به مرحله، کمی زمان بر و نیازمند به آزمون و خطاست!

حالا که می‌دانید به چه چیزهایی باید توجه کنید، شروع کنید! مهم نیست یک دولوپر هستید یا مدیر میانی و ارشد یا ... . وظیفه‌ی شما بهبود است. رضایت و امنیت شغلی خود و همکارانتان را افزایش دهید و باعث رشد و حفظ آینده و امنیت سازمان خود شوید.

یادتان باشد که تغییرات در تجربه دولوپری یک لحظه‌ای یا یک شبه بدست نمی‌آید و این فرآیند یکی از فرآیندهایی است که باید در کنار توسعه‌ی محصول جدی گرفته شود. به صورت کلی هم پیاده سازی DevEx مناسب زمان مفید و هزینه‌ی زیادی از تیم و سازمان شما نخواهد گرفت و این زمان و هزینه‌ی اندک به آورده‌های تجربه‌ی دولوپری برای تیم می‌ارزد!