دِوآپس؛ حالمان هنوز خوب نیست (2)

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