نکات کلیدی
چابک (Agile) و ناب (Lean) یکی نیستند. چابک یک رویکرد تجربی برای تحویل افزودههای ارزشمندِ یک محصول است، در حالی که ناب رویکردی برای بهبود جریان کار از طریق کاهش اتلاف، کاهش کار ناتمام و بهبود زمان چرخه است.
ناب برای محیطی بهینه شده که در آن نیازمندیها عمدتاً مشخص هستند و مسئلهای که باید حل شود بهخوبی تعریف شده است. چالش کار معماری این است که در ابتدای چرخه عمر محصول (و گاهی حتی مدتها بعد از آن) نیازهایی که معماری را شکل میدهند، یعنی آنچه «الزامات ویژگیهای کیفی» یا Quality Attribute Requirements (QARs) مینامیم، هنوز بهخوبی درک نشدهاند.
تیمهای توسعه به شیوههای چابک نیاز دارند تا ارزشی را که MVP آنها ارائه میکند، و همچنین تصمیمهای طراحی خود را اعتبارسنجی کنند تا مطمئن شوند محصول به اهدافش خواهد رسید (حداقل معماری قابلاتکا یا Minimum Viable Architecture).
وقتی تیم توسعه MVP و MVA را اعتبارسنجی کرد و نسبت به تصمیمهایش احساس راحتی کرد، شیوههای ناب میتوانند به آنها کمک کنند تا شیوه کار خود را بهبود دهند.
استفاده زودهنگام یا نامناسب از شیوههای ناب میتواند تکامل معماری را مختل کند، چون تمرکز بیش از حدی روی قابل پیشبینی و روان کردن جریان کار میگذارد. تا زمانی که QARها بهطور نسبتاً خوبی فهم نشدهاند، معماری ممکن است دچار تغییر و بازبینیهای قابل توجهی شود. این اتلاف نیست، بلکه واقعیتی است از پالایش درک تیم توسعه نسبت به QARهای سیستم.
در طول سالها شنیدهایم که افراد از معماری خود، یا تلاشهای معماریشان، شاید با عنوان «ناب و چابک» یاد میکنند. این موضوع ما را به فکر انداخت که شیوههای ناب و چابک چگونه میتوانند به یک تیم کمک کنند تا معماری یک محصول نرمافزاری را توسعه دهد. بعضی افراد این دو را با هم اشتباه میگیرند و فکر میکنند ناب و چابک رویکردهایی عمدتاً مشابهاند. ما فکر میکنیم آنها کاملاً متفاوت هستند، با نقاط قوت و ضعف متفاوت، بهویژه زمانی که به معماری نرمافزار مربوط میشوند.
رویکردهای ناب روی کاهش اتلافی تمرکز دارند که توسط فرایندها و شیوههای ناکارآمد توسعه ایجاد میشود و همچنین روی کاهش زمان چرخه، و عمدتاً در حوزه مسائل تولیدی تکامل یافتهاند. در حالی که بیشتر بر ابزارها و روشهای توسعه محصول تمرکز دارند، سازوکارهایی نیز برای بهبود تدریجی خود محصول ارائه میکنند.
رویکردهای ناب فرض میکنند سازمان تا حد زیادی میداند چه محصولی باید بسازد یا چه مسئلهای را باید حل کند، بنابراین باید اساساً روی کاهش اتلاف در ساخت راهحلِ شناختهشده تمرکز کند.
برخی مدیران ناب را دوست دارند، زیرا روی افزایش کارایی، افزایش بهرهوری، کاهش هزینه و افزایش قابلیت پیشبینی تمرکز دارد.
آنها توسعه نرمافزار را نوعی خط تولید میبینند، و شیوههای ناب، با ریشههای تولیدیشان، بهخوبی با این دیدگاه همسو میشوند.
این تمرکز، تمرکز رویکرد چابک نیست. رویکردهای چابک بر کارایی، بهرهوری، کاهش هزینه یا افزایش پیشبینیپذیری متمرکز نیستند، هرچند ممکن است همه اینها به عنوان پیامد جانبیِ دستیابی به هدف اصلی یک رویکرد چابک حاصل شوند:
اینکه بهسرعت مشخص شود آیا سازمان در حال ساخت «محصول درست» است یا نه.
در جهت دستیابی به این هدف، تیمها مجبورند اتلاف را کاهش دهند تا به چرخههای بازخورد سریع برسند که خود به کاهش هزینه و بهبود کارایی منجر میشود، اما اینها وسیلهاند، نه هدف.
این موضوع برای معماری نرمافزار چه معنایی دارد؟
MVP، MVA و تجربیگرایی
مفهوم حداقل محصول پذیرفتنی (MVP) به عنوان راهی برای اعتبارسنجی تجربی اینکه آیا یک تیم در حال ساخت محصول درست است یا نه، مدتهاست که وجود دارد. در مجموعهای از مقالات، ما این ایده را با مفهومی مرتبط که آن را حداقل معماری قابلاتکا (MVA) مینامیم، گسترش دادهایم.
ما MVA را اینگونه تعریف میکنیم: مجموعهای کوچک از تصمیمهای بنیادی طراحی که تیم توسعه درباره راهحل میگیرد. این تعریف بر پایداری و دوام بلندمدتِ MVP تمرکز دارد، از طریق در نظر گرفتن اینکه محصول چگونه علاوه بر نیازهای عملکردی خود، QARها را نیز برآورده میکند، و در عین حال با حداقل بدهی فنی، پایداری را محقق میسازد.
هم در MVP و هم در MVA، نیازهای واقعی مشتریان و تصمیمهای فنی لازم برای ارائه راهحلهایی که آن نیازها را برآورده کنند، دستکم تا حدی ناشناختهاند. تیمها باید از حلقههای بازخورد تجربی استفاده کنند تا نیازهای مشتری را بفهمند و همچنین بازخورد جمعآوری کنند که آیا راهحل آنها این نیازها را برآورده میکند یا نه. این موضوع هم برای MVP و هم برای MVA صادق است.
MVP و MVA نیز چیزهایی یکباره نیستند؛ هر انتشار در واقع مجموعهای از آزمایشهای MVP و MVA است که تیم برای درک بهتر نیازها و تحویل ارزش اجرا میکند. در نتیجه، هر انتشار را میتوان نسخهای تازه از یک زوج MVP/MVA دانست.
چابک، ناب و پیچیدگی
چارچوب هوشمندانه Cynefin از دیو اسنودن چهار نوع فضای مسئله را توصیف میکند:
-
واضح (Obvious): گزینهها روشن هستند و توافق بر روابط علت و معلول بهراحتی حاصل میشود.
-
پیچیده (Complicated): ممکن است بیش از یک راهحل «درست» وجود داشته باشد و انتخاب بین آنها نیازمند تخصص برای تشخیص و تصمیمگیری است.
-
پیچیدهگونه (Complex): ممکن است هیچ راهحل «درستی» وجود نداشته باشد، زیرا راهحلها بیش از حد غیرقابل پیشبینی هستند که بتوان راهحلهای اثباتشده را اعمال کرد یا روابط علت و معلول را شناسایی نمود. حل این نوع مسائل به رویکردی تجربی از شکل دادن و آزمودن فرضیهها و سازگاری بر اساس نتایج نیاز دارد.
-
آشفته (Chaotic): هیچ رابطه علت و معلولی وجود ندارد. بهترین کاری که میتوان انجام داد کاهش آشفتگی و ایجاد درجهای از نظم و ثبات است. نمونهها شامل شرایط اضطراری و واکنش به بلایای طبیعی است.
رویکردهای ناب، با تمرکز بر پیشبینیپذیری، در کار روی مسائل واضح و پیچیده درخشان عمل میکنند؛ جایی که راهحلها بهخوبی تعریف شدهاند یا دستکم قابل تعریف هستند. وقتی این شرایط وجود دارد و راهحل یا هدف بهخوبی تعریف شده است، تمرکز بر کاهش اتلاف، بهبود کارایی و سرعت، و بهبود پیشبینیپذیری اهداف مهمی هستند.
رویکردهای چابک وقتی میدرخشند که روی مسائل پیچیده کار میشود؛ زمانی که هدفها و راهحلها بهخوبی تعریف نشدهاند، و هیچ راهحل شفاف و کاملی وجود ندارد و فقط راهحلهای جزئی همراه با مصالحهها وجود دارند.
این به این معنا نیست که برای حل مسائل پیچیده جایی برای شیوههای ناب وجود ندارد. در زمینه توسعه نرمافزار، برای مثال، بخش زیادی از کار همچنان نسبتاً ساده یا فقط پیچیده است؛ مانند فرایند ساخت و تست نرمافزار، بهویژه با استفاده از پایپلاین تحویل مستمر، یا کاهش اتلاف در تحویلگیریها بین تیمها. ساخت محصول درست مسئلهای پیچیده است، اما درست ساختن آن فقط مسئلهای پیچیده است.
چابک، ناب و معماری نرمافزار
ایجاد معماری برای یک محصول نرمافزاری مستلزم حل انواع مختلفی از مسائل پیچیده است؛ هر محصول با چالشهای منحصربهفردی روبهروست که معماریاش باید از طریق مجموعهای از مصالحهها بر آنها غلبه کند. ما این فرایند تصمیمگیری را در مقالات دیگر توضیح دادهایم، جایی که مفهوم حداقل معماری قابلاتکا (MVA) را به عنوان بازتابی از این تصمیمهای مبتنی بر مصالحه معرفی کردهایم.
MVA مکمل معماریِ یک Minimum Viable Product یا MVP است. MVA با اطمینان از اینکه MVP از نظر فنی قابلاتکا، پایدار و در طول زمان قابل گسترش است، آن را متعادل میکند؛ و همین است که MVP را از یک نمونه اثبات مفهومِ دورریختنی متمایز میکند.
رویکردهای ناب دوست دارند به مسئله اصلی توسعه نرمافزار به چشم بهبود جریان کار نگاه کنند، اما از منظر معماری، مسئله اصلی ایجاد یک MVP و یک MVA است که هر دو «حداقلی» و «قابلاتکا» باشند.
یکی از جنبههای کلیدی MVA این است که بهصورت تدریجی و در طی مجموعهای از انتشارهای محصول توسعه مییابد. تیم توسعه از دادههای تجربی این انتشارها برای تأیید یا رد فرضیههایی که درباره مناسب بودن MVA شکل میدهد، استفاده میکند. آنها بدون دادههای تجربی نمیتوانند تعیین کنند که آیا MVA برای MVP متناظر خود مناسب است یا در طول عمر محصول قابل اتکا خواهد بود. تیم برای رفع نارساییها و بهبود MVA در انتشارهای بعدی به بازخورد نیاز دارد. این چرخه بازخورد تجربی بهطور ایدهآل با یک رویکرد چابک همخوان است.
این کار ذاتاً غیرقابل پیشبینی است، به دلیل تنوع انواع مختلف تصمیمهایی که تیم توسعه باید بگیرد، و به خاطر تازگی کار؛ اعضای تیم روی مسائلی کار میکنند که هرگز با آنها مواجه نشدهاند، و تمرکز آنها بر «کارایی» نیست، بلکه بر «اثربخشی» است. اثربخشی آنها میتواند با استفاده از برخی اصول ناب، مانند کاهش تعداد کارهای همزمان (WIP)، یا کاهش زمان انتظار، وقفهها یا تحویلگیریها بهبود یابد، و آنها قطعاً به کوتاهتر کردن زمانی که برای دریافت بازخورد نیاز دارند علاقهمندند، اما در غیر این صورت چندان دغدغه بهینهسازی جریان کار خود را ندارند.
ناب برای محیطی بهینه شده که در آن نیازمندیها عمدتاً قطعی هستند و مسئلهای که باید حل شود بهخوبی تعریف شده است. چالش کار معماری این است که در ابتدای چرخه عمر محصول (و گاهی حتی در ادامه چرخه) نیازهایی که معماری را شکل میدهند، یعنی QARها، هنوز بهخوبی درک نشدهاند.
ناب همچنین در پی کاهش اتلاف است، که هدفی شایسته است. مشکل کار معماری این است که تیم توسعه بدون آزمایش نمیداند کدام تصمیمها درست هستند و کدامها نه. برخی از این آزمایشها دادههایی تولید میکنند که به تیم میگوید تصمیمشان درست نبوده است. میتوان این کار انجامشده را اتلاف دانست، اما همین کار اطلاعات ارزشمندی فراهم کرده که اتلافهای آینده را بیش از این کاهش میدهد.
رویکردهای ناب در توسعه نرمافزار بهویژه نسبت به اتلافی حساسند که از خودِ فرایند ناشی میشود، بهخصوص در قالب کاری که شروع شده اما کامل نشده است. این معمولاً نتیجه داشتن WIP بیش از حد است، اما در محصولات نرمافزاری نوع خاصی از اتلاف وجود دارد که از به تعویق انداختن تصمیمها ناشی میشود: بدهی فنی. بازخورد حاصل از چرخههای تحویل چابک میتواند نشان دهد که میانبرهای فنی و تصمیمهای به تعویقافتاده در حال تضعیف توان محصول برای برآوردن QARهایش هستند. وقتی این اتفاق میافتد، تیم توسعه معمولاً باید زمان صرف کند تا بدهی فنی را حل کند و معماری را بازطراحی کند. از دیدگاه ناب، این کار جریان را مختل میکند، اما برای کاهش شدید اتلاف آینده ناشی از محصولی که نمیتواند ارزش خود را حفظ کند، ضروری است.
نتیجهگیری
سازمانها به هر دو رویکرد چابک و ناب نیاز دارند، اما به دلایل متفاوت. آنها به بازخورد چابک نیاز دارند تا بدانند محصولی که میسازند نیازهای مشتری را برآورده میکند، و بهویژه زمانی که این نیازها را برآورده نمیکند. آنها همچنین به شیوههای ناب نیاز دارند تا منابع اتلاف را که توانشان برای تحویل محصولات باکیفیت و مقرونبهصرفه را مختل میکند، شناسایی و حذف کنند. به این شکل، رویکردهای ناب، رویکردهای چابک را تکمیل میکنند.
تیمهای توسعه به شیوههای چابک نیاز دارند تا بازخورد دریافت کنند که آیا MVP و MVA متناظر با آن به اهداف خود میرسند یا نه. آنها باید از این بازخورد برای بهبود MVP/MVA در انتشارهای بعدی استفاده کنند. اگر MVP/MVA به اهداف خود نرسد، تمرکز بر کارایی و بهرهوری کمکی به تحویل راهحل بهتر نخواهد کرد.
وقتی تیم تا حد زیادی مطمئن شد که در حال ساخت محصول درست است و معماری محصول به اهدافش میرسد، تیم میتواند تمرکز خود را به موضوعات کارایی، بهرهوری و هزینه منتقل کند، مادامی که به یاد داشته باشد هر انتشار هنوز یک آزمایش است که ارزش و پایداری محصول را میآزماید.
