معمار و معماری چابک

– اسد : ” بچه ها امروز روز اول پروژه مون هست، و متدلوژی ما چابک هست و قراره در اسپرینت های دو هفته ای نرم افزار کار کننده تحویل مشتری بدهیم”

– علی : ” نرم افزار کار کننده چی هست؟ ”

– اسد : ” نرم افزاری که کار کند و انتظارات مشتری در حدی که خواسته بود بر طرف کند”

– ناصر : ” این خوب است ولی اسد این فعلا امکان پذیر نیست، میدونی که پروژه ما اینترپرایز هست و باید معماری پیاده سازی شود شاید بعد اون بتونیم محصول قابل استفاده بدهیم دست مشتری”

– اسد : “چقدر طول میکشه ما معماری رو پیاده سازی کنیم؟

– ناصر : ” حداقل 4 ماه”

– اسد :” یعنی قرار نیست چیزی تا چهار ماه به مشتری داده بشود یا دیده بشود؟

– ناصر :”می تونه کدهامون رو ببینه”

– اسد: “معماری به چه درد مشتری میخورد؟ ما قرار است چابک باشیم تا یاد بگیریم”

– اسد : “از کجا می فهمیم که بعد چهار ماه راه رو درست رفتیم؟ معماری پیاده سازی شده منطبق بر درخواست مشتری است؟ اگر مشتری تغییرات بخواهد هزینه تغییر چقدر خواهد بود؟”

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

سوال اصلی معمولا این است که معماری چابک چگونه انجام می شود؟ کی انجام می شود؟ و چقدرش کافی است؟ یا اصلا ما در دنیای چابک مفهومی به نام معماری یا نقشی با عنوان معمار داریم؟

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

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

  • معمار تیم است و مسئولیت طراحی با تیم است

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

اگر تعداد تیم ها و نفراتتان زیاد است، بهتر است از تکنیک اخیر ما استفاده کنید، یک تیم با عنوان تیم ببر بسازید که کار آنها حمله به پروژه و تکه پاره کردن پروژه خواهد بود، اعضای این تیم معمولا افراد با توانایی فنی بالا در حوزه های معماری، آنالیز، طراحی، الگوهای طراحی، مباحث شی گرایی و … هستند.

  • ساده ترین معماری ممکن که کار کند را بسازید

بعد از اینکه تیم ساخته شد، وظیفه تیم این خواهد بود: ساده ترین معماری ممکن که قابلیت هایی از سیستم بر روی آن کار کند را بسازد. یعنی این تیم قرار نیست فقط فریم ورک برای دیگران بسازد، بلکه در عین پیاده سازی خود معماری، قابلیت ها و درخواست های مشتری را نیز پیاده سازی می کند.

فرض کنید که در همین پروژه اخیر، ما با پیاده سازی قابلیت لاگین به سیستم، لایه ها یا سرویس های مختلف را نسبت به نیاز آن قابلیت پیاده سازی می کردیم، در آخر کار فهمیدیم که فلان سرویس های اضافی تر لازم است یا فلان لایه ها اضافه پیش بینی شده اند یا … .

  • برش عمودی است نه افقی

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

admin-ajax.php (300×200)

  • معماری چابک پدیداری است نه رو به جلو

یکی از بدترین چیزهای ممکن که همه در دام آن می افتند این است که سعی می کنند در مراحل ابتدایی پروژه  یک معماری دقیق و کامل با صرف زمان زیاد به وجود آورند، در حالی که در معماری چابک مفهومی داریم به نام طراحی پدیداری – تدریجی یا Emergent Design که سعی می کنیم با یک معماری ساده شروع کنیم و آن را رفته رفته گسترش بدهیم .

  • اصل YAGNI را فراموش نکنیم

دلیل اینکه ما سعی می کنیم پدیداری طراحی کنیم این است که سعی کنیم از اتلافات جلوگیری کنیم، اصل YAGNI یا You aren’t gonna need it می تواند در این وادی به ما کمک کند به این صورت که سعی کنیم مواردی را تنها و تنها پیاده سازی کنیم که الان به آن نیازمند هستیم نه آنها که شاید یک روزی شاید لازم بشود.

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

  • اسپرینت صفر 

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

معمولا طبق تجربه من برای تیم ها توصیه می کنم از لحن Project Liftoff یا کندن پروژه استفاده کنند، در این بازه زمانی که تایم آن نسبت به حجم پروژه باید انتخاب شود، سعی می شود ابتدا دامنه نسبی پروژه شناخته شود، قابلیت های اساسی سیستم معلوم شود، برآورد نسبی بر روی آنها انجام شود، و طراحی و معماری کاندیدی انتخاب شود.

  • وقتی شک دارید شروع کنید به کدنویسی

در یکی از پروژه های اخیر تیم بر روی مسایل تکنولوژی دو به شک بودند که آیا از ESB استفاده کنیم یا نه، بعد از R&D های مختلف تیم همچنان قادر به انتخاب نبود که استفاده بکند یا نه، اما با رعایت اصل Keep It Simple And Stupid  تصمیم گرفتند که استفاده نکنند ولی معماری را طوری در نظر بگیرند که اگر لازم شد بتوانند بعدا استفاده کنند، اصطلاحا بلک باکس در نظر گرفتند.

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

  • آماده پرداخت هزینه باشید

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

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

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

چابک و موفق باشید

درباره اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

1 دیدگاه در “معمار و معماری چابک

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

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