روز های اولی که با اصول چابک(Agile), از طریق XP آشنا شده بودم یادم نمیره. دچاری تعارض بدی بودم از یک طرف میدیدم متدولوژی های RUP که و در اون نقش معمار و اصول معماری با فرایند ها و دیسیپلین های سخت از پیش تعریف شده نهادینه شده بود و شفاف بود. درحال از بین رفتنه, جای خودشو داره به یک اصولی می ده که بنظر می رسد پایبندی مشخصی به معماری و کیفیت نداره بلکه فقط میخواد زودتر یک نرم افزار بسازه و بدست مشتری برسونه حتی لعنتی پایبند به مستندسازی هم نیست.
بنابراین هی با خودم می گفتم این هم یه چند روزی هست و تب فضای نرم افزاره ولی چند سال بعد که مشکلاتش بیرون زد ازبین میره.
زمان گذشت دیدم سروکله اسکرام پیدا شد اونم میگه هر دو هفته یا سه هفته باید یه فیچر به کاربر داد.و سازمانها یکی بعد از دیگری در حال های پیاده سازی اونن با خودم گفت دیگه انکار بسه مثل اینکه این تغییر بیشتر از حذف مستندات ، دو هفته ای کار کردن و کاغذی های رنگی قشنگه.
یادم نمیره رفته بودم برای مصاحبه توی یک شرکت وقتی کانبان برد اونجا رو دیدم توی دلم گفتم
اوه اوه .. اینجا هم از این قرتی بازیا داره.
حالا باید اقرار کنم بعد از کار توی چندین شرکت و کار با دوستانی خوبی که مفاهیم چابکی رو خوب درک کرده بودند به روشنی میگم
بزرگترین تحول در تولید نرم افزار توی این سالهای اخیر همین تفکر چابک است.
شاید شما هم مثل من دچار این تعارض شده باشید من توی این متن سعی دارم راجب تحول فکری خودم بگم و راهی که رفتم.
رویکرد چابک با در مرکز قرار دادن مشتری و تغییر رویکرد, به ایجاد ارزش برای مشتری انگار جایی برای تفکر معماری و اصول اولیه تولید نرم افزار ارزان(high internal quality) و با کیفیت قائل نیست.
“High internal quality leads to faster delivery of new features, because there is less cruft to get in the way”
--Martin Fowler
تازه اوضاع بدتر میشه وقتی که می فهمید برای مشتری اصول نرم افزار و ابزار و استاندارها همگی از جنس کیفیت داخلی بوده نه قابل درکه و نه قابل دیدن پس ارزشمند محسوب نمیشه.
از اون بدتر میشه وقتی که رویکرد سازمان محصول گرا شده و از شما خودمختاری می خواهند.
تعارض بدیه از یک طرف همه شما رو به عنوان معمار یا مدیرفنی، وقتی سیستم باگ داره یا دچار Crash میشه خلاصه بگم بدهی های فنی بیرون میزنه مسئول میدونن از طرف دیگر جایی برای ایجاد یک زیرساخت خوب قائل نیستند.
معماران نرم افزار سالهاست که یاد گرفته اند چگونه اصول یک معماری خوب از همون روز اول و با صرف وقت و ایجاد فریم ورک ها و پیاده سازی استاندارد های سختگیرانه و انتخاب ابزارها مناسب و … نهادینه کنن.
حالا فرض کنید چنین تفکر میخواد کنار تفکر چابک قرار بگیره رسما تعارضه
این تعارض شاید دردناک باشه و سرچشمه تحولات معماری بعد از ایجاد موج چابک در سالهای اخیر است.
برای حل این تعارض بهتر است پناه ببریم به همون به پنج اصل کلیدی از ۱۲ اصل چابک با رویکرد معماری
پس در گام نخست چابک با کیفیت و طراحی خوب مشکلی ندارد بلکه اونو باعث افزایش چابکی می داند.
گام بعدی تیم های "خود سامانده" اساس ایجاد یک معماری خوبه نه ساختارهای سخت از پیش تعریف شده و تمرکز گرا
خودمختاری نه تنها منجر به خودساماندهی میشه بلکه انگیزه راهم بالا می برد.
استقبال از تغییر به جای مقابله با آن
معماری نرم افزار همگرا با چابک باید دارای چندین خصوصیاتی باشد:
“The first and foremost lesson is a meta-lesson: If applied, strict service orientation is an excellent technique to achieve isolation; you come to a level of ownership and control that was not seen before.”
-- Werner Vogels Amazon CTO 2006
این ها اساس شکل گیری موج بعدی چابک یعنی معماری میکروسرویس است.
مساله همچنان باقی است؟ تکلیف معماری و کیفیت توی این فرهنگ جدید چیه؟
شما به عنوان معمار نرم افزار یا مدیر فنی از هر سبکی که استفاده می کنید:
چه به عنوان معمار و مدیر فنی تمام تصمیمات مهم را می گیرد.تا مطمئن شود کلیه سیستم از یک یکپارچگی لازم و مفهومی برخوردار است و معتقدید که اعضای تیم از مهارت های لازم برای انجام این تصمیم برخوردار نیستند.
و یا سعی دارید همواره از آنچه که در پروژه می گذرد با خبر باشید و به دنبال موضوعات مهم بوده تا قبل از اینکه تبدیل به چالش بزرگی شود با تعامل زیاد با تیم ها با آن مقابله کنید.
باید پارادایم ذهنی خود را تغییر داده و بدونید در فضای چابک
حال چگونه ساختارها و فرایندها و تمهیداتی ایجاد کنیم که خودمختاری را به حداکثر برساند؟
اگر توجه کنید معماری میکروسرویس دارای دو وجه بیرونی و درونی است.
وظیفه شما ,ایجاد همسویی (Alignment)است و شما می توانید با تمرکز بر روی وجه بیرونی و با مشارکت تیم ها همسویی لازم را ایجاد نمایید.
زمانی که مشخصات این وجه بیرونی مشخص شد آنگاه خودمختاری قابل اعطا به تیم های تولید سرویس می باشد.البته یادتان نرود همین اصول معماری بیرونی هم باید قابل تغییر توسط تیم ها باشد شما و تیم ها باید مکانیسمی برای تحول در صورت نیاز داشته باشید. نقش شما صرفا از ایجاد رویکردهایی برای Alignment است.
حال با وجهه درونی چکار باید کرد؟ آیا خودمختاری در این حوزه منجر به از دست رفتن کیفیت نمیشه؟
اینجا نقش شما چیه؟
بهتره در اینجا از دو فرهنگ سازمانهای چابک کمک بگیرید. "Fast Failed" و "Data Driven"
ابتدا اجازه بدید بجای اعمال استانداردهای از پیش نوشته شده و اعلان آن به تیم ها, خود تیم ها به صورت خودمختار دست به انتخاب ابزارها و استانداردها و … زده و شما با ایجاد و تعریف معیارهای کیفی مثل throughput , Load و … و پیاده سازی آن از طریق گیت های تست و فراهم کردن بستری CI/CD آنها را زودتر به چالش بکشید وبا جمع آوری اطلاعات از طریق سیستم های مانیتورینگ و Log تیم ها را ترغیب به برگزاری جلسات Postmortem کرده و برای اعضای تیم فضای یادگیری ایجاد نمایید.تا اقدام به بهبود نمایند.
زمانی که استانداردها , ابزارها و حتی Library ها درست بدست آمد و یادگیری انجام شد اجازه بدهید این استاندارد ها خود به خود بین تیم های انتشار یابد و از یکدیگر بیاموزند.
به طور مثال
باید گفت درسته فضای تولید نرم افزار با رویکرد چابک دچار تغییر شده ولی دیگر نمی توان با پارادایم های قبلی با آن همراه شد.وظیفه شما به حداکثر رسانی تغییرپذیری است و این با افزایش خود مختاری و جدا کردن دغدغه ها در قالب سرویس های کوچک قابل بدست آمدن است.
در این مقاله سعی شد، در رابطه با تحول چابک بر روی معماری نرم افزار و ایجاد مایکروسرویس صحبت شود در آینده سعی می کنم در رابطه با موج های بعدی این تحول بیشتر بنویسم.
به نظر شما خودمختاری (Autonomy)که اساس این نوع معماریه چطوری منجر به ایجاد نتایج شگفت انگیز میشه؟؟
