در توسعه محصولات نرم‌افزاری، سه تصور یا پیش فرض غلط وجود داشته و بعضا هنوز هم وجود دارد:

۱- مشتریان از نیازمندی‌های خود آگاهند.
۲- توسعه دهندگان روش ساخت محصول را می‌دانند.
۳- در مدت توسعه چیزی تغییر نمی‌کند.

تجربه نشان داده که اینطور نیست و چنین فرضیاتی در اغلب موارد و به خصوص در تولید محصولات پیچیده و یا نوآورانه غلط هستند و در واقع:

۱- مشتری/ذینفع به مرور به جزییات نیازمندیهای خود پی می‌برد.

۲- توسعه دهنده ها بر اساس یافته های جدیدشان میفهمند که محصول را چگونه بهتر از قبل بسازند.

۳- در حین توسعه، به چیزهای جدیدی یاد می‌گیریم و این یادگیری‌ها میتواند برنامه‌های قبلی را به طور کامل عوض کند.


متدهای چابک هم بر مبنای همین تجربیات پایه گذاشته شدند. رویکردی که از پیش بینی (Prediction) فاصله گرفت و پذیرای تغییر و تطبیق با شرایط جدید (Adaption) شد.

بر اساس همین رویکرد جدید (چابکی) می‌پذیریم، طراحی های ما به مرورد «بهتر» و «پدیدار»‌ می‌شوند و به تدریج به شکل مطلوب در می‌آیند. به تجربه ثابت شده که ایده‌ی طراحی «کامل» (GOD Design) ایده‌ای است که در عمل شکست می‌خورد. لذا می‌پذیریم که پیش بینی‌های بلند مدت نکنیم و به جای آن پذیرای تغییرات باشیم. البته این تغییرات مبتنی بر یادگیری معتبر (Validated Learning) هستند. شاید این حرف بدیهی به نظر برسد اما ایده یک طراحی جامع و زودهنگام (Big Up Front Design) که بشود بر اساس آن برنامه دقیقی ارایه داد، مدتها مطرح و در متدلوژی‌های سنگین وزن (Plan-Driven) معتبر بوده است.

طراحی پدیدآ و ارتباط آن با بیانیه چابک

در بیانیه چابک، اصل یازدهم گفته شده که:

The best architectures, requirements, and designs emerge from self-organizing teams.

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

Welcome changing requirements, even late in development.

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

برای مطالعه بیشتر میتوانید این مطلب را بخوانید:

http://www.scaledagileframework.com/agile-architecture/

همینطور خواندن کتاب  Lean Architecture for Agile Software Development نوشته جیمز کاپلین، مخصوصا فصل ۵ را پیشنهاد می‌کنم.