نشریه دانشکده کامپیوتر دانشگاه صنعتی اصفهان
دوآپس؛ حلقه گمشده توسعه نرم‌افزار
به قلم دانیال خراسانی‌زاده، ورودی ۹۹ مهندسی کامپیوتر صنعتی اصفهان
بازنگری‌شده توسط مهشید شیرانی و مهدی قاسمی، ورودی ۱۴۰۱ و ۹۹ کارشناسی مهندسی کامپیوتر صنعتی اصفهان
رویداد سی‌تی‌افی که چند‌وقت پیش در دانشگاه برگزار شد، برای من تجربه متفاوتی بود. قبل از این، به عنوان عضوی از تیم اجرایی با رویداد‌ها همراه بودم. اما در سی‌تی‌اف به عنوان یک ناظر خارجی سعی کردم به بچه‌ها کمک کنم. این موقعیت جدید باعث شد چیزهایی رو ببینم که قبلا با این شفافیت نمی‌تونستم ببینم و حتی اگر می‌دیدم، علاوه بر دیدن این مشکلات، حالا با دانشی که از کار و یادگیری‌های یک سال اخیرم کسب کرده بودم، راه‌حل احتمالی اون‌ها رو هم می‌دونستم.
اما این مشکلات چه چیزهایی بودن؟ توی این رویداد بچه‌هایی که توی تیم فنی بودن، وقت زیادی رو صرف پیاده‌سازی بخش‌های مختلف کرده بودن و با تمام وجود به بهتر شدن کیفیت اهمیت می‌دادن. اما با وجود این، در فرآیند رسیدن کارهاشون به دست شرکت‌کننده‌ها مشکلات خیلی زیادی مثل ناهماهنگی، دیده‌نشدن و برنامه‌ریزی نشدن کارها از قبل و کندی در استقرار دیده می‌شد.
تمام این مشکلات، الگوهایی هستن که خیلی وقته در توسعه نرم‌افزار دیده میشه و متخصص‌های این حوزه راه‌حل‌های مختلفی براشون ارائه دادن. یکی از این راه‌حل‌ها فرهنگ دوآپسه. فرهنگی که به ما کمک می‌کنه تیم‌های توسعه، استقرار و کاربرها رو در کنار هم قرار بدیم.
دوآپس
اما دوآپس چیه؟
معمولا هرکس تعریف متفاوتی از دوآپس داره، اما اگر تمام این تعاریف رو جمع‌آوری کنیم و نقطه مشترکشون با هم رو پیدا کنیم، این نقطه مشترک، همکاری تیم‌های توسعه و تیم‌های زیرساخت در تمامی چرخه تولید نرم‌افزاره.
دوآپس به ما میگه روش‌های قدیمی مدیریت زیرساخت رو کنار بذاریم و در کنار توسعه‌دهنده‌ها و با استفاده از تکنیک‌هایی که خیلی وقته در دنیای نرم‌افزار به عادت تبدیل شده، زیرساخت‌هامون رو توسعه بدیم.
اما چرا باید به این روش جدید اعتماد کنیم؟ از کجا معلوم این تغییرات باعث نشن وضعمون از اینی که الان هست هم بدتر بشه؟
آمار نشون می‌ده که شرکت‌هایی که فرهنگ دوآپس رو در پیش گرفتن، دویست برابر سریع‌تر به نیازهای جدید پاسخ میدن، سی برابر سریع‌تر تغییرات رو به دست کاربرها می‌رسونن و بر خلاف تصور این کار رو با مشکلات شصت برابر کمتر انجام میدن و در زمان وقوع مشکل، شصت برابر سریع‌تر اون رو حل می‌کنن.
همه ما بیش از هر‌چیز به دنبال بهینه‌کردن ساختارهای تولید نرم‌افزار برای رسیدن به محصولاتی هستیم که در عین پایداری، به سرعت خودشون رو با تغییر نیازهای کاربر وفق میدن. برای رسیدن به این هدف، ما نیاز به یک راه و سنجه‌هایی برای سنجش عملکردمون داریم و دوآپس دقیقا همین‌هارو در اختیار ما قرار می‌ده.
بیاید با مسیری که دوآپس در پیش پای ما قرار می‌ده شروع کنیم.
فرهنگ
اولین توصیه دوآپس به ما ایجاد یک فرهنگ مولده.
در یک سازمان مولد، همه افراد روی یک هدف خاص تمرکز دارن و به همین خاطر برای رسیدن به این هدف به هم کمک می‌کنن. در چنین جایی، مسئولیت‌ها به اشتراک گذاشته میشه و کسی به خاطر مشکلات سرزنش نمیشه و به همین‌خاطر افراد بدون ترس از بازخواست‌شدن، ایده‌های جدید رو امتحان می‌کنن و سازمان رو به سمت هدفش پیش می‌برن.
در کنار یک فرهنگ مولد، دوآپس با الگوگیری از روش‌های مدیریتی Lean و Agile به ما توصیه می‌کنه که سه چیز رو همیشه به خاطر داشته باشیم:
1. Systems thinking
برای رسیدن به یک نرم‌افزار خوب، تلاش افراد و تیم‌های مختلفی نیازه. خیلی وقت‌ها، ما بدون توجه به این کل، سعی می‌کنیم قسمتی از چرخه تولید نرم‌افزار رو بهینه کنیم. این کار معمولا باعث میشه که نابهینگی‌های چرخه تولیدمون از یک قسمت، به قسمت دیگه منتقل بشه و در نهایت، در سرعت تولید ارزش برای کاربر تفاوتی ایجاد نشه. دوآپس به ما توصیه می‌کنه که به جای تمرکز روی نقاط مختلف سازمان، دید کل‌نگری داشته باشیم و سعی کنیم که مشکلاتی که در تمام قسمت‌هایی که از ورود ایده کاربر به چرخه تا رسیدن محصول به دست کاربر وجود داره رو در کنار هم ببینیم و بهینه کنیم.
2. Amplify feedback loops
یکی از مهم‌ترین چیزهایی که برای رسیدن به یک سیستم خوب نیاز داریم، بازخوردهای مداوم و مفیده. چون به خاطر طبیعت پویا و همیشه در حال تغییر نرم‌افزار، فقط بازخورده که می‌تونه به پاسخگویی بهتر به نیازهای کاربر کمک کنه. بیشتر اوقات ما سعی می‌کنیم که یک چرخه بازخورد با کاربر ایجاد کنیم اما در دوآپس این کافی نیست، ما باید بین تیم‌ها و افراد مختلفی که در چرخه تولید ارزش برای کاربر قرار دارن هم چرخه‌های بازخوردی ایجاد کنیم که در صورت بروز مشکل، این مشکل رو برای حل شدن سریع‌تر به بخش‌های دیگه اطلاع میدن.
3. Continuous experimentation
در نهایت، دوآپس به ما میگه که در زمان مشاهده مشکل، نباید از آزمون و خطا بترسیم بلکه باید برای حل مشکل راه‌های مختلفی که در نظر داریم رو امتحان کرده و اگر به پاسخ دلخواهمون نرسیدیم یاد بگیریم که کجای مسیر رو اشتباه رفتیم و با این دانش جدید، دوباره برای حل مشکل تلاش کنیم.
اندازه‌گیری
یکی از مهم‌ترین کارها در رسیدن به هر‌هدفی، داشتن سنجه‌های دقیق و اندازه‌گیری فاصلمون با هدفه. دوآپس در کنار نشون دادن مسیر، پیشنهاد می‌ده که برای رسیدن به هدف تولید نرم‌افزار خوب از چهار سنجه استفاده کنیم. با توجه به دیدگاه دوآپس، این سنجه‌ها باید دو خصوصیت مهم داشته باشن، اول اینکه باید روی هدف کلی تمرکز کنن و سعی در بهینه کردن یک قسمت خاص نداشته باشن و دوم اینکه به جای اندازه‌گیری حجم کار خروجی، نتایج مفید رو اندازه‌گیری کنن.
- Lead Time
سنجه اولی که به اون می‌پردازیم، فاصله بین تعریف نیاز کاربر تا رسیدن راه‌حل اون نیاز به دستش رو می‌سنجه. کاهش این سنجه در دو مورد به ما کمک می‌کنه.
1. در زمان ارائه یک قابلیت جدید به کاربرها، کوتاه‌بودن زمان رسیدن قابلیت به دست اون‌ها، طول چرخه بازخورد رو کاهش می‌ده و به ما کمک می‌کنه که سریع‌تر مسیرمون رو برای رسیدن به خواسته‌هاشون اصلاح کنیم.
2. در زمان مشاهده یک مشکل در محصول در دست کاربر، با کاهش زمان رسیدن نرم‌افزار به دست اون، می‌تونیم سریع‌تر از گذشته مشکل رو حل کرده و پچ مورد نیاز رو به دستش برسونیم.
- Deployment Frequency
کاهش اندازه هر یک از خروجی‌های تیم نرم‌افزاری، هزینه‌های برنامه‌ریزی و ریسک ایجاد مشکل در هنگام تغییرات بزرگ رو کاهش می‌ده و میزان بازخوردهای دریافت‌شده رو افزایش می‌ده. اما اندازه‌گیری میزان خروجی یک تیم نرم‌افزاری پیچیده‌ست و به همین خاطر، ما می‌تونیم با اندازه‌گیری تعداد استقرارهای محصول در یک بازه زمانی، و تلاش برای افزایش اون، اندازه هر‌آپدیت نرم‌افزار رو کاهش بدیم.
- Mean time to restore
دو سنجه قبلی که درباره اون‌ها صحبت کردیم، به افزایش سرعت توسعه می‌پردازن. اما افزایش سرعت توسعه نباید به کاهش پایداری محصول منجر بشه و به همین خاطر دو سنجه دیگه رو برای جلوگیری از این اتفاق در نظر می‌گیریم. هیچ نرم‌افزاری بدون باگ نیست و به خاطر پیچیدگی و سرعت توسعه نرم‌افزارهای امروزی، بدون شک زمانی پیش می‌یاد که با قطعی سیستم مواجه بشیم. در چنین مواقعی مهمه که سعی کنیم در حداقل زمان ممکن نرم‌افزارمون رو دوباره به پایداری برسونیم و همواره برای کاهش این زمان تلاش کنیم.
- Change Fail Percentage
دومین سنجه‌ای که دوآپس برای افزایش پایداری نرم‌افزار به ما پیشنهاد می‌ده، درصد تغییراتیه که با مشکل مواجه می‌شن. با تلاش برای کاهش مقدار این سنجه، ما می‌تونیم از پایداری بیشتر قابلیت‌های جدیدی که به دست کاربرمون می‌رسه مطمئن بشیم.
Continuous delivery
تا اینجای کار درباره اینکه دوآپس چیه، روی چه چیزهایی تاکید می‌کنه، و چطور سنجیده میشه صحبت کردیم. اما چطور باید به دوآپس برسیم؟
یکی از چیزهایی که خوبه برای رسیدن دوآپس بهش توجه کنیم، Continuous Delivery هستش. این مفهوم، مجموعه‌ای از روش‌هاست که به ما کمک می‌کنه تغییرات رو به سرعت و با پایداری به دست کاربر برسونیم و با این کار به اهداف دوآپس نزدیک‌تر بشیم. در قلب Continuous Delivery پنج اصل وجود داره:
1. Build quality in
این اصل به ما میگه که در تمامی مراحل تولید نرم‌افزار به کیفیت توجه کنیم. این کار باعث ایجاد چرخه‌های بازخورد کوتاهی میشه که به ما کمک می‌کنن مشکلات رو خیلی زودتر از زمانی که به دست کاربر می‌رسن تشخیص بدیم و با هزینه کمتری حل کنیم.
2. Work in small batches
قبل از این هم به اهمیت کاهش حجم خروجی تیم توسعه در هر مرحله اشاره کردیم، یکی از دلایلی که ما کمتر به سمت این روش می‌ریم و همیشه بعد از انجام تغییرات خیلی بزرگ، محصول رو منتشر می‌کنیم، هزینه ارائه این تغییرات به مراحل بعدی چرخه تولید نرم‌افزار مثل تست و استقراره، که Continuous Delivery سعی می‌کنه با تغییر ساختار تولید نرم‌افزار، این هزینه رو کاهش بده تا در هر تغییر، اون تغییر رو ساده‌تر به مراحل بعدی تولید نرم‌افزار برسونیم و با گرفتن بازخورد سریع‌تر، مشکلات رو کشف و با هزینه کمتر اون‌ها رو رفع کنیم.
3. Computers perform repetitive tasks; people solve problems
معمولا افراد مختلفی که در چرخه تولید نرم‌افزار نقش دارند، افراد متخصصی هستن که به خاطر دانش و تواناییشون در حل مشکلات شناخته می‌شن. پس بهتره که بار کارهای تکراری مثل تست‌های در هنگام انتشار نرم‌افزار که به‌راحتی به‌وسیله کامپیوترها انجام میشه رو از روی شونه اون‌ها برداریم و حل مسائل مهم‌تر رو به اون‌ها بسپاریم.
4. Relentlessly pursue continuous improvement
برای بهتر شدن چرخه تولید نرم‌افزار هیچ سقفی وجود نداره، چهارمین اصل Continuous Delivery، ما رو به راضی نشدن به وضعیت موجود و تلاش همیشگی برای بهتر کردن روندها دعوت می‌کنه.
5. Everyone is responsible
اصل پنجم Continuous Delivery، با تفکر سیستمی و فرهنگ سازمانی مولد ارتباط تنگاتنگی داره. این اصل به ما میگه که همه افراد سازمان، باید بدون توجه به نقششون، نسبت به تولید ارزش برای کاربر مسئول باشن و برای رسیدن محصول نهایی به دست کاربر تلاش کنن.
شاید پیاده‌سازی دوآپس در یک رویداد دانشجویی کار پیچیده‌ای باشه، اما دوآپس مسیر بی انتهاییه که در هر جایی از اون باشیم، از ده قدم عقب‌تر وضع بهتری داریم و به همین خاطر، به نظرم شناخت و تلاش برای رسیدن به دوآپس در هر جایی می‌تونه به نرم‌افزارهای با کیفیت‌تر در کنار آرامش بیشتر، کمک کنه. از طرف دیگه، رویدادهای دانشجویی زمین بازی خوبی برای امتحان کردن و یادگیری هستن. به همین خاطر به همه توصیه می‌کنم در هر جایی که با تولید نرم‌افزار درگیر هستن، پا در مسیر دوآپس بذارن و برای بهتر شدن نرم‌افزارها تلاش کنن.
منابع
در راه رسیدن به دوآپس منابع مختلفی برای استفاده وجود داره و متنی که مطالعه کردید، برداشت و چکیده من از این کتاب‌ها بود. اگر به دوآپس علاقه‌مند شدید، می‌تونید برای آشنایی بهتر با خودش و روش‌های پیاده‌سازیش از این کتاب‌ها استفاده کنید:
مطلبی دیگر از این انتشارات
چرا داوطلبانه فعالیت می‌کنم؟!
مطلبی دیگر از این انتشارات
چگونه برنده شویم؟(نگاهی بر نظریه بازیها و طراحی مکانیزم)
مطلبی دیگر از این انتشارات
چیزهایی که دانشگاه به من یاد داد!