چند دقیقه با کتاب Accelerate

• «کد بدون تست نداریم.»
• «هیچ کدی بدون بازبینی (review) داخل نمی‌رود.»
• «همه‌ی مراحل استقرار (deployment) خودکارسازی شده است.»
• «ما مجهز به CI/CD هستیم.»
• «کارهای بزرگ را به کارهای کوچک‌تر شکسته و کارهای موازی را محدود می‌کنیم.»
• «همواره از مشتری بازخورد دریافت می‌کنیم.»
• «در سازمان ما، افراد به داشتن ارتباط مستقیم با تیم‌ها و بخش‌های دیگر سازمان و حتی مدیران تشویق می‌شوند.»

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

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

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

خوراک کتاب، سلسله پژوهش‌هایی است که از سال ۲۰۱۴ با عنوان State of DevOps Report منتشر می‌شود. نویسندگان کتاب در واقع پژوهش‌گرانی هستند که آن را پیش می‌برند: Nicole Forsgren, Jez Humble و Gene Kim. در دنیای مهندسی نرم‌افزار شاید هامبل از سایرین شناخته شده‌تر باشد. او نویسنده‌ی کتاب Continuous Delivery است.

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

با این مقدمه، سراغ خود کتاب می‌رویم. کتاب در سه بخش تألیف شده است. من مطالب کتاب را به طور کامل پوشش نداده و به ذکر نکات برجسته بسنده می‌کنم.

چطور کارایی را اندازه‌گیری کنیم؟

متدولوژی‌ها و چهارچوب‌های کاری متعددی وجود دارند که تلاش می‌کنند روش توسعه‌ی محصولات و خدمات را بهبود دهند. هر یک با ارائه‌ی یک تعریف از «خوب» و اندازه‌گیری کمیت مربوط به آن، مسیر بهبود را به ما نشان می‌دهند. کاستی‌هایی که روش‌های پیشین داشته‌اند، معمولاً مربوط به تعریف اشتباه از «خوب» است. برای مثال، تعداد خط کد، سرعت (velocity) یا بهره‌گیری (utilization) را به عنوان شاخص‌های کارایی در نظر بگیرید؛ آیا تعداد خط بیشتر نشان‌دهنده‌ی کارایی بیشتر یک تیم یا توسعه‌دهنده است؟ تعداد خط کم‌تر چطور؟ عمدتاً ما ترجیح می‌دهیم به جای یک برنامه‌ی هزار خطی با یک برنامه‌ی ده‌خطی دست و پنجه نرم کنیم. حتی دوست داریم با هیچ کدی مواجه نباشیم و کدهای اضافی را پاک می‌کنیم. از سوی دیگر، گاهی یک قطعه کد ده خطی را که واضح است و به راحتی خوانده می‌شود، نسبت به نسخه‌ی فشرده‌شده‌ی سه خطی و جادویی آن که نیاز به رمزگشایی دارد، ترجیح می‌دهیم. بنابراین اندازه‌گیری تعداد خط کد معیار ایده‌آلی نیست.

اندازه‌گیری سرعت چطور؟ در فرهنگ اصطلاحات چابک (Agile)، مسائل به تعدادی داستان (story) شکسته شده و به داستان‌ها عددی به عنوان امتیاز (point) نسبت داده می‌شود که برآوردی از میزان نیرویی است که صرف آن کار می‌شود. تعداد امتیازهایی که در هر دوره (iteration) توسط تیم به مشتری تحویل داده می‌شود، قابل اندازه‌گیری است و به آن سرعت تیم گفته می‌شود. هدف طراحی سرعت، ارائه‌ی ابزاری برای برنامه‌ریزی ظرفیت است. یعنی پیش‌بینی زمان کامل‌ شدن کارهایی که برنامه‌ریزی و برآورد شده‌اند. سرعت، یک کمیت نسبی و وابسته به تیم است. به همین دلیل نمی‌توان از آن به عنوان شاخصی برای اندازه‌گیری کارایی یا مقایسه میان تیم‌های متفاوت استفاده کرد. علاوه بر این، استفاده از این کمیت برای مقایسه بین تیم‌ها سبب ایجاد یک بازی‌ شده که در این بازی، بی‌شک طرف پیروز، اغراق در برآورد و تمرکز بر کارهای درون‌تیمی به جای همکاری میان‌تیمی خواهد بود.

سنجش بهره‌گیری (utilization) به عنوان معیاری برای بهره‌وری (productivity) چطور؟ ایراد این روش این است که بالا بردن بهره‌گیری تا حدی خوب است. به حداکثر رساندن بهره‌وری به این معنی است که هیچ ظرفیت خالی‌ای نداریم. بنابراین، نمی‌توانیم کارهای برنامه‌ریزی نشده، تغییرات یا کارهایی را که منجر به بهبود فرایند می‌شود، بپذیریم. در نتیجه، زمان انجام کار افزایش پیدا خواهد کرد.

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

1. زمان تحویل (delivery lead time)
2. فرکانس استقرار (deployment frequency)
3. زمان بازیابی سرویس (time to restore service)
4. نرخ شکست تغییرات (change failure rate)

بر این اساس سوالاتی طراحی شده تا میزان تأثیر این شاخص‌ها را روی کارایی تحویل نرم‌افزار، مشخص کند. جداول زیر نتیجه‌ی این پژوهش در سال‌های ۲۰۱۶ و ۲۰۱۷ را نشان می‌دهند.

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

• «نوشتن تست خوب است؛ اما باعث می‌شود کار دیرتر به نتیجه برسد.»
• «خودکارسازی خوب است؛ اما وقت نداریم.»
• «مدام خطاهای محیط عملیاتی با تغییرات انسانی برطرف می‌شوند.»
• …

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

فرهنگ؟ اندازه‌گیری؟ مگر داریم؟ مگر می‌شود؟!

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

مدل فرهنگ سازمانی وستروم

پژوهش‌گران از مدل فرهنگ سازمانی وستروم (Westrum) برای مدل‌سازی فرهنگ استفاده می‌کنند. بر اساس این مدل، سازمان‌ها در سه دسته قرار می‌گیرند:

1. بیمار‌گونه (pathological) / مبتنی بر قدرت: میزان وجود ترس و تهدید در بدنه‌ی سازمان، چنین سازمانی را مشخص می‌کند. افراد معمولا اطلاعات را به دلایل سیاسی نشر نداده یا آن را تغییر می‌دهند تا بهتر به نظر برسند.
2. بوروکراتیک / مبتنی بر مقررات: از بخش‌های (department) خود حمایت می‌کنند. افرادِ داخل یک بخش، از «خاک» خود دفاع می‌کنند، به مقررات خودشان اصرار دارند، و معمولاً بر اساس مقررات عمل می‌کنند (البته، مقررات خودشان).
3. مولد / مبتنی بر کارایی: سازمان‌هایی که بر مأموریت تمرکز می‌کنند. همه چیز به کارایی خوب بستگی دارد؛ به کاری که قرار است انجام دهیم.

مدل وستروم به چه درد می‌خورد؟

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

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

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

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

چطور فرهنگ را اندازه بگیریم؟

برای اندازه‌گیری فرهنگ سازمانی بر اساس مدل وستروم، از پرسش‌نامه‌ی زیر استفاده ‌شده است:

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

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

تا این‌جا متوجه شدیم چطور کارایی را اندازه‌گیری کنیم. دیدیم که فرهنگ سازمانی تعیین‌کننده‌ی میزان کارایی است. چگونگی اندازه‌گیری آن را هم بررسی کردیم. حالا نوبت به این سوال می‌رسد که فرهنگ سازمانی تحت تأثیر چیست و چطور آن را بهبود دهیم؟ کتاب عوامل فنی و مدیریتی را در فرهنگ سازمانی مؤثر می‌داند. عوامل فنی مؤثر در قالب مجموعه‌ای از تمرین‌ها با عنوان تحویل مستر (Continuous Delivery) و عوامل مدیریتی تحت عنوان تمرین‌های مدیریتی Lean معرفی می‌شوند.

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

تمرین‌های فنی

تحویل مستمر (Continuous Delivery) یعنی چه؟ تحویل مستمر (Continuous Delivery) مجموعه‌ای از توانایی‌هاست که به ما امکان می‌دهد انواع تغییرات-ویژگی‌های جدید (feature)، تغییرات پیکربندی، رفع خطاها، و آزمایش‌هایمان-را به شکلی ایمن، سریع و پایدار در محیط عملیاتی به دست کاربر برسانیم. پنج اصل کلیدی در تحویل مستمر (Continuous Delivery) وجود دارد:

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

آثار تحویل مستمر

طی پژوهش‌ها کیفیت تحویل مستمر در تیم با اندازه‌گیری توانایی‌های زیر انجام شد.

هر کدام از این توانایی‌ها در قالب سوالات چند گزینه‌ای اندازه‌گیری شدند. برای مثال، در مورد کنترل نسخه (version control) از شرکت‌کنندگان پرسیده شد که در تا چه حد با گزاره‌های زیر موافق یا مخالف‌اند.

• کد برنامه‌ی ما در سیستم کنترل نسخه ذخیره شده است.
• پیکربندی سیستم ما در سیستم کنترل نسخه ذخیره شده است.
• پیکربندی برنامه‌ی ما در سیستم کنترل نسخه ذخیره شده است.
• اسکریپت‌های خودکارسازی build و پیکربندی ما در سیستم کنترل نسخه ذخیره شده است.

تحویل مستمر به این معنی تعریف و اندازه‌گیری شد:

• تیم می‌تواند استقرار در محیط عملیاتی (یا محیط کاربر) را در هر لحظه از چرخه‌ی حیات تحویل نرم‌افزار انجام دهد.
• بازخورد سریع در مورد کیفیت و قابل استقرار بودن سیستم برای همه‌ی تیم در دسترس است و افراد واکنش به این بازخورد را در اولویت قرار می‌دهند.

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

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

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

اثر تحویل مستمر بر کیفیت

برای اندازه‌گیری کیفیت، این موارد اندازه‌گیری شد: زمانی که صرف انجام کارهای جدید، دوباره‌کاری و کارهای برنامه‌ریزی نشده، و سایر کارها شده است. نتیجه‌ی بررسی‌ها نشان داد میزان زمان صرف شده در هر مورد بین تیم‌های کارآمد و سایرین متفاوت است.

تفاوت میزان وقت صرف شده در هر مورد شاید موضوع چندان عجیبی نباشد. آن‌چه جالب است صرف بیش از نیمی از وقت برای کارهای پیش‌بینی نشده و دیگر کارها حتی در تیم‌های کارآمد است. تصور بسیاری از ما این است که در جلسات برنامه‌ریزی دوره‌ای می‌توانیم و باید برآوردهای (estimate) دقیقی ارائه دهیم. این در حالی است که می‌بینیم حتی در تیم‌های موفق، نزدیک به 20 درصد از کارها غیرقابل پیش‌بینی بوده و نیمی از کارها مواردی هستند که احتمالاً ما در زمان برنامه‌ریزی در نظر نگرفته یا نمی‌توانیم در نظر بگیریم. این به آن معنی نیست که برنامه‌ریزی و برآورد را باید دور ریخت و یا نباید برای بهبود آن تلاش کرد. در عوض باید نظر داشت که ذات توسعه‌ی نرم‌افزار قرار گرفتن در یک فضای ناشناخته و دست و پنجه نرم‌کردن با مسأله است. معمولاً کاری را انجام می‌دهیم که قبلاً انجام نداده‌ایم. بنابراین انتظار ارائه‌ی برآوردهای دقیق و رسیدن ضرب‌العجل‌های (deadline) سخت‌گیرانه، غیر واقع‌بینانه است.

نکته‌ی جالب دیگر این است که تفاوت میان گروه کارآمد و سایرین از میزان مورد انتظار کم‌تر بود. پاسخ به این سوال به نقل از کتاب:

ما از سازمان‌ها و متخصصانی که با چیزهایی مثل مدیریت پیکربندی، زیرساخت با کد (infrastructure-as-code)، و استقرار مستمر (continuous deployment) آشنایی نداشتند، اطلاعاتی جمع‌آوری نکردیم. با جمع‌آوری نکردن داده‌های این گروه، عده‌ای که به احتمال زیاد حتی از ناکارآمدترین گروه ما بدتر عمل می‌کنند را از دست می‌دهیم.

کنترل کیفیت و هیأت مشاور تغییرات

یکی از یافته‌های جالب مربوط به اثرگذاری موجودیت‌های کنترل کیفیتی خارج از تیم است. این موجودیت‌ها را ممکن است با عناوینی مثل تیم کنترل یا تضمین کیفیت (QA/QC) و یا هیأت مشاور تغییرات (CAB: Change Advisory Board) بشناسید. مطالعات نشان می‌دهد:

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

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

پس آیا دیگر احتیاجی به نقش آزمون‌گر (tester) نداریم؟ جواب کوتاه این سوال خیر است. از پرداختن بیشتر به این موضوع در این‌جا صرف نظر می‌کنم. برای اطلاعات بیشتر می‌توانید به متن کتاب مراجعه کرده و یا کتاب How Google Tests Software را بخوانید.

موضوع هیأت مشاور تغییرات (CAB) نیز به طور خاص مورد بررسی قرار گرفته است. در پرسش‌نامه گزینه‌های زیر در اختیار شرکت‌کنندگان قرار گرفت:

• تمامی تغییرات باید توسط یک موجودیت خارجی (مثل یک مدیر یا هیأت مشاور) مورد تأیید قرار بگیرد.
• فقط تغییرات پرخطر مثل تغییرات پایگاه داده نیاز به تأیید دارند.
• برای مدیریت تغییرات از بازبینی همتایان (peer review) استفاده می‌کنیم.
• هیچ فرایندی برای تأیید تغییرات نداریم.

یافته‌ها شگفت‌انگیزند. در مورد تأثیر هیأت مشاور بر کارایی:

… نیاز به تأیید، فقط برای تغییرات پرخطر با کارایی تحویل نرم‌افزار ارتباطی نداشت. تیم‌هایی که فرایند تأیید نداشتند یا از بازبینی همتایان (peer review) استفاده می‌کردند به کارایی تحویل نرم‌افزار بیشتری دست می‌یافتند. در نهایت، تیم‌هایی که نیاز به تأیید توسط موجودیت خارجی داشتند کارایی کمتری داشتند.

در مورد تأثیر هیأت مشاور بر پایداری:

… تأییدهای خارجی با زمان تحویل (lead time)، فرکانس استقرار، و زمان بازیابی ارتباط منفی داشته و با نرخ شکست تغییرات ارتباطی نداشتند.

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

توسعه‌ی مبتنی بر trunk

توسعه‌ی مبتنی بر trunk یکی از روش‌های مدیریت branchها در سیستم کنترل نسخه (version control) است. روش‌های مختلفی برای مدیریت branchها در سیستم کنترل نسخه وجود دارد. برای مثال ممکن است عبارات git workflow، github workfow، یا gitflow را شنیده باشید. هر کدام از این روال‌های کاری، روشی برای مدیریت branchها در سیستم کنترل نسخه ارائه می‌دهند. برخلاف این روال‌ها، توسعه‌ی مبتنی بر trunk تلاش می‌کند به جای مدیریت branchهای متفاوت، استفاده از branchها را به حداقل کاهش دهد. در توسعه‌ی مبتنی بر trunk یک branch اصلی وجود دارد که همه‌ی تغییرات به صورت روزانه در آن ادغام (merge) می‌شوند. branchها عموماً عمر کوتاهی دارند و پس از ادغام در شاخه‌ی اصلی حذف می‌شوند.

بررسی‌ها نشان می‌دهد توسعه‌ی مبتنی بر trunk با کارایی بیشترِ تحویل در ارتباط است. تیم‌هایی که عملکرد خوبی داشتند حداکثر سه branch فعال داشتند و طول عمر branchهایشان خیلی کوتاه (کم‌تر از یک روز) بود. همچنین چیزی تحت عنوان دوره‌ی پایدارسازی و متوقف کردن فرایند توسعه نداشتند. این نتایج مستقل از اندازه‌ی تیم، اندازه‌ی سازمان، و صنعتی است که سازمان در آن فعالیت می‌کند.

در این‌جا باز هم شاهد نکات ارزش‌مندی هستیم: طول عمرهای به شدت کوتاه، تعداد branchهای فعال خیلی کم، و فراگیر بودن مطالعات. با این‌حال ممکن است افرادی که Github یا سیستم‌های مشابه کار کرده‌اند نسبت به این مشاهدات بدبین باشند. نکته‌ی کلیدی در این‌جا این است که توسعه‌ی مبتنی بر trunk بر طول عمر کوتاه branchها تأکید دارد. مادامی که این شرط برقرار باشد، هر روال کاری که مورد استفاده قرار گیرد از مزیت‌های این روش بهره‌مند خواهد شد.

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

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

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

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

ویژگی‌های معماری

تا این‌جا از آثار به‌کارگیری تمرین‌های تحویل مستمر (continuous delivery) بر فرهنگ، کارایی و … صحبت کردیم. با این‌حال ممکن است با خود بگوییم:

«همه‌ی این‌ها درست است، اما در سازمان ما یا پروژه‌ی ما یا در نوع پروژه‌هایی که ما انجام می‌دهیم جواب نمی‌دهد. DevOps و تحویل مستمر برای سیستم‌های مبتنی بر وب طراحی شده‌اند در حالی که ما روی یک نرم‌افزار یک‌تکه (monolithic) که روی mainframe اجرا می‌شود کار می‌کنیم.»

این بخش از پژوهش تلاش می‌کند تأثیر تصمیمات و محدودیت‌های معماری را بر تحویل نرم‌افزار در محیط‌های متفاوت بررسی کرده و ویژگی‌های معماری مؤثر را شناسایی کند. یافته‌ها نشان می‌دهد

… دستیابی به کارایی بالا در همه‌ی انواع سیستم‌ها امکان‌پذیر است، به شرطی که سیستم و تیم توسعه‌دهنده و نگه‌دارنده‌ی آن، دارای وابستگی‌های سست (loose coupling) باشند.

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

• زمین سبز (greenfield): سیستم‌های جدیدی که هنوز منتشر نشده‌اند
• سیستم‌های سرگرمی (مورد استفاده‌ی مستقیم کاربران)
• سیستم‌های ثبت و ضبط (برای ذخیره‌سازی اطلاعات حیاتی کسب و کار که در آن صحت و سازگاری اطلاعات اهمیت دارد)
• نرم‌افزار سفارشی که توسط شرکت دیگری توسعه داده می‌شود
• نرم‌افزاری سفارشی داخلی
• نرم‌افزار تجاری از پیش‌آماده و بسته‌بندی شده (commercial off-the-shelf)
• نرم‌افزار تعبیه‌شده (embedded) که روی دستگاه سخت‌افزاری تولید شده اجرا می‌شود
• نرم‌افزارِ دارای مولفه‌ای که توسط کاربر نصب می‌شود (شامل برنامه‌های موبایل)
• نرم‌افزار غیر mainframe که روی سرورهای شرکت دیگری اجرا می‌شود
• نرم‌افزار mainframe

یافته‌ها نشان می‌دهد

… گروه‌های ناکارآمدتر بیشتر می‌گفتند نرم‌افزاری که می‌سازند یا سرویس‌هایی که با آن تعامل دارند نرم‌افزاری سفارشی است که توسط شرکت دیگری توسعه داده می‌شود… همچنین تعداد بیشتری از آن‌ها روی سیستم‌های mainframe کار می‌کردند. به طرز جالبی یکپارچه (integrate) کردن تغییرات در سیستم‌های mainframe ارتباطی با کارایی نداشت.

در سایر موارد ارتباط چشم‌گیری بین نوع سیستم و کارایی تحویل وجود نداشت.

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

تمرکز بر قابل استقرار و قابل تست بودن

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

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

این دو ویژگی را قابل تست و قابل استقرار بودن می‌نامیم. این ویژگی‌ها حاصل تصمیم‌هایی در سطح معماری هستند. برای دست‌یابی به این ویژگی‌ها طراحی باید به شکلی باشد که وابستگی‌ها سست باشند. یعنی تغییر و اعتبارسنجی (validation) بخش‌های مختلف سیستم، باید بتواند به صورت مستقل از هم انجام شود. بررسی‌ها نشان می‌دهد موارد زیر، مهم‌ترین عوامل در تحویل مستمر هستند؛ حتی مهم‌تر از خودکارسازی تست و استقرار.

• تیم می‌تواند تغییرات طراحی در مقیاس بزرگ را بدون نیاز به اجازه‌ی فردی خارج از تیم انجام دهد.
• تیم می‌تواند تغییرات در مقیاس بزرگ را در طراحی سیستم خود انجام دهد؛ بدون این‌که نیاز به تغییر در سیستم دیگری باشد یا کار زیادی برای سایر تیم‌ها ایجاد کند.
• تیم می‌تواند کار خود را بدون نیاز به ارتباط و هماهنگی با افراد خارج از تیم انجام دهد.
• تیم می‌تواند بدون در نظر گرفتن سایر سرویس‌های وابسته، سرویس یا محصول خود را در لحظه (on demand)، استقرار یا انتشار دهد.
• تیم می‌تواند بیشتر تست‌های خود را در لحظه و بدون نیاز به محیط یک‌پارچه انجام دهد.
• تیم می‌تواند استقرار را در ساعات اداری با زمان قطعی (downtime) ناچیز انجام دهد.

این موارد ویژگی‌های سیستمی است که وابستگی‌های سست دارد. اما چطور به این نقطه برسیم؟ برای دست‌یافتن به این قابلیت، به تیم خودکفا (cross functional) نیاز داریم؛ تیمی که تمامی مهارت‌های مورد نیاز طراحی، توسعه، تست، استقرار، و عملیات در آن وجود دارد. هدف این است که تیم بتواند کار خود را از مرحله‌ی طراحی تا استقرار، بدون نیاز به تعاملات بین تیمی زیاد انجام دهد.

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

سخن پایانی

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

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

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