ادغام تفکر چابک و دواپس چه مزایایی به همراه می‌آورد؟

قبل از شروع بحث نوشته‌های زیر را بخوانید و کمی به آن فکر کنید:
*محبوب‌ترین روش تفکر چابک، اسکرام است که پیش از رشد دِواپس (DevOps) وجود داشته، بنابراین تمرکز اسکرام بیشتر روی تحویل نرم‌افزار است، نه جنبه‌های عملیاتی.
* ترکیب روش‌ها با دواپس به تفکر جدیدی در مورد تیم‌ها، نحوه نوشتن داستان کاربری و ... نیاز دارد.
*برنامه‌ریزی برای سرعت دادن به کار باید شامل برخی از جنبه‌های عملیاتی دواپس باشد.
* باید از دواپس از همان لحظه استخدام اعضای تیم استفاده کنیم.
هیچ نقطه مشخصی وجود ندارد که بگوییم یک محصول، کاربردی، اساسی و خواسته دقیق مشتری است؛ مگر این‌که بتوانید آن را توسعه دهید، از آن نگهداری کنید و پشتیبان آن باشید. متدولوژی چابک، به‌عنوان یک چهارچوب مناسب، ایده‌هایی عالی را در بخش‌های مختلف جذب کرده و اکنون زمان آن است که از صحنه دواپس کمک بگیریم تا اطمینان حاصل شود که تفکر چابک هنوز می‌تواند موفق شود.
بیشتر تمرکز روی محصولات پس از راه‌اندازی است؛ یعنی زمان رفع اشکال، پشتیبانی و نگهداری. طبق گزارش‌های اخیر ZDNet بالغ بر 57 درصد از بودجه، صرف نگهداری و فعالیت‌های بعد از ارائه محصول می‌شود و این مقدار در سال 2011 بیش از 63 درصد بوده است.

 نیاز به DevOps

در شماره‌های قبلی ماهنامه شبکه دو مفهوم چابک و دواپس را بررسی کرده‌ایم و در اینجا خلاصه‌ای از تعریف آن‌ها را بیان می‌کنیم. تفکر چابک (Agile) روش یا روش‌هایی است که با به‌کارگیری آن‌ها می‌توان محصولی نزدیک‌تر به نیاز مشتری ساخت. اسکرام یه متد از روش‌های چابک است و چهارچوبی برای توسعه نرم‌افزار و مدیریت پروژه تعریف می‌کند. 
DevOps (دِواپس) ترکیبی از دو کلمه توسعه (Development) و عملیات (Operation) است. کار تیم توسعه مشخص است؛ مجموعه مهندسان سعی دارند قابلیت‌های محصول را افزایش دهند. در مقابل تیم عملیات سعی در ثابت نگه‌داشتن وضعیت سرویس‌ها دارد. برای درک بهتر این دو تیم از یکدیگر مفهوم دواپس به وجود آمد که طی فرایند تولید نرم‌افزار تاکید زیادی بر همکاری این دو تیم می‌شود. دواپس به ما می‌آموزد که ویژگی‌های عملیاتی، اهمیت بالایی دارد و باید مانند دیگر خصوصیات موردتوجه قرار گیرد. بهترین راه برای اطمینان از این اتفاق، تقویت یک فرهنگ قوی همکاری بین تیم‌های توسعه و عملیات است. البته چگونگی دستیابی به این همکاری یک سوال دیگر است و مدل‌های دواپس کاملا متفاوت هستند. مثلا آمازون رویکرد «شما آن را ساختید، آن را اجرا می‌کنید» را در پیش گرفته و در برخی تیم‌های گوگل رویکرد «دواپس به‌عنوان یک پلتفرم» مطرح می‌شود.
در چند سال گذشته تفکر چابک و دواپس در کنار هم زندگی کرده‌اند و بحث‌های زیادی در مورد رابطه بین این دو وجود دارد. بعضی افراد دواپس را به‌عنوان یک زیرمجموعه از چابک می‌بینند و بعضی دیگر آن را به‌عنوان مجموعه‌ای از شیوه‌های خودکارسازی در نظر می‌گیرند. این‌ها همه به تعریف شما از دواپس بستگی دارد. اما صرف‌نظر از دیدگاه‌ها، هدف نرم‌افزار کاری این است که بتواند مدیریت، نگهداری، مقیاس‌پذیری، پشتیبانی و به‌روزرسانی را با سهولت انجام دهد و این چیزی است که جهان نرم‌افزار به‌شدت به آن نیاز دارد.
راه‌هایی که نرم‌افزار از طریق آن اجرا می‌شود نسبت به‌روزهایی که تفکر چابک تازه اختراع‌شده بود، تغییرات زیادی داشته است. اسکرام در سال 1993 شروع به کار کرد، کتاب XP در سال 1999 و DSDM (روش توسعه سامانه‌های پویا) در سال 1994 منتشر شد. اجرا، نگهداری و عملیات مواردی نبودند که توسعه‌دهندگان نرم‌افزار در هر شرایطی درگیر آن باشند. اما تغییرات بزرگی اتفاق افتاد و در حال حاضر توسعه‌دهندگان به‌طور فعال در عملیات و پشتیبانی از سیستم‌های خود مشارکت دارند. اکنون ما به دنبال چهارچوبی هستیم که این تغییرات را در نحوه کار ما ایجاد کند. ترکیب دواپس و تفکر چابک می‌تواند باعث این کار شود.

ضد الگوها در دوآپس

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

به‌روز‌رسانی شیوه‌های چابک

چگونه می‌توانیم اطمینان حاصل کنیم درحال‌توسعه نرم‌افزار به شیوه چابک هستیم، درحالی‌که ارائه و نگهداری از محصولات و خدمات مطابق با آخرین و بزرگ‌ترین بخش‌های دواپس باشد؟ پاسخ آسان است. با اضافه کردن
وظایف/داستان‌های عملیاتی به داستان‌های کاربری برای رسیدن به موفقیت. البته برای رسیدن به این هدف به نظر ساده باید به چند نکته مهم توجه داشت: کسانی که روی این وظایف یا داستان‌ها کار می‌کنند، بهترین تمرینات دواپس، مدیریت مالک و نوشتن داستان عملی.
تیم‌ها: بیشتر تیم‌های چابک که با آن‌ها کار می‌کنیم شامل عملیات، پشتیبانی یا متخصصان زیرساخت نیستند. ممکن است بگویید کهدر هر تیم چابک  تقاضای کافی برای وجود چنین تخصص‌هایی وجود ندارد و شاید هم درست باشد اما فراموش نکنید که این صحبت دقیقا در مورد تست‌کننده‌ها، معماران و مهندسان پایگاه داده، UX و ... نیز گفته می‌شد. اگر ارائه، پشتیبانی، به‌روزرسانی، مقیاس‌پذیری و نگهداری محصول برای شما مهم است، پس به این مهارت‌ها در تیم خود نیاز دارید.
پشتیبانی: اگر تیم‌هایی داریم که در حال کار روی محصولات هستند، پس باید تیمی هم برای پشتیبانی داشته باشیم و دیدگاه سنتی را فراموش کنیم و به رویکردهای تازه رو آوریم که با آغوش باز جنبه‌های عملیاتی را می‌پذیرد. شاید بهترین واژه برای روشن شدن مفهوم، واژه «خدمات» باشد. خدمات محصولاتی هستند که باید به کار گرفته شوند و بعد از ارائه محصول برای پشتیبانی ارائه می‌شوند. وقتی از پشتیبانی صحبت می‌کنیم باید بتوانیم پاسخ‌گوی موارد زیر باشیم:
• مقیاس‌پذیری محصول یا سرویس (در داخل یا خارج؟ و چه زمانی؟)
• قابلیت گسترش (آیا این مورد بدون این‌که وقفه‌ای در کار سیستم ایجاد کند، انجام‌شده است؟)
• نظارت بر سرویس (چه جنبه‌هایی به نظارت نیاز دارند؟ چگونه با هر تغییری نحوه نظارت کردن را به‌روزرسانی کنیم؟)
• ورود به سیستم (چه اطلاعاتی باید وارد شود؟ چرا؟ و این کار به چه روشی انجام شود؟)
• هشدار (چه کسی؟ چه وقتی؟ چطور؟)
• تست‌پذیر بودن خدمات
• جنبه‌های امنیتی مانند مدل‌های رمزنگاری، حفاظت از داده‌ها، قوانین داده‌ها و ... .
• عملکرد عملیاتی. 

مطلب پیشنهادی

چالاکی رمز موفقیت متدولوژی‌های سبک وزن چابک

متدولوژی‌های چابک چه هستند و چطور فرآیند توسعه را سریع و ساده می‌کنند؟

داستان‌های کاربری (User Stories)

داستان‌های کاربری، راهی عالی برای به دست آوردن نیازمندی‌های محصولات هستند. در این راه، توسعه‌دهنده خود را به‌جای کاربر نهایی قرار می‌دهد و از دید او به مشکلات نگاه می‌کند. به این ترتیب، به‌جای پیروی ساده از دستورالعمل‌ها تمرکز خود را بر راه‌حل مشکلات واقعی قرار می‌دهد. داستان‌های کاربری به‌جای توجه به «چگونه» به روی «چه چیز» تمرکز می‌کند. فرمت داستان‌های کاربری طوری است که معمولا با عبارت‌های «من می‌خواهم...»، «به این دلیل که...»، «برای این‌که...» و مانند آن آغاز می‌شوند.
برنامه‌ریزی برای سرعت بیشتر در اجرای کار
اگر بخواهید به کار سرعت بیشتری بدهید باید برای آن برنامه‌ریزی کنید. برای رسیدن به یک دیدگاه دواپس باید کارهای زیر انجام شود:
• دعوت از افراد پشتیبان، زیرساخت و عملیاتی برای جلسه‌های برنامه‌ریزی
• صحبت در مورد ویژگی‌های عملیاتی، علاوه بر ویژگی‌های فنی محصول
• تعیین یک روند منطقی و قابل دسترس
• توجه به زمان و تلاشی که صرف وقفه‌ها می‌شود (برای مثال، رفع اشکالات برنامه‌نویسی).

تعریف اتمام کار

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

مالکیت محصول

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

مطلب پیشنهادی

چرا دِواپس آینده کسب‌وکار شما را رقم خواهد زد؟

۱۰ مزیتی که دِواپس برای کسب‌وکارها به وجود می‌آورد

نتیجه‌گیری

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