کتاب Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions (تسهیل معماری نرمافزار: توانمندسازی تیمها برای اتخاذ تصمیمات معماری) یک راهنمای ارزشمند برای مدیران پروژه، معماران نرمافزار و توسعهدهندگانی است که به دنبال بهبود فرآیند تصمیمگیری در مورد ساختار سیستمهای نرمافزاری هستند.
کتاب Facilitating Software Architecture با ارائه روشها و تکنیکهای عملی، به تیمها کمک میکند تا تصمیمات معماری بهتری اتخاذ کنند و در نتیجه، سیستمهای نرمافزاری با کیفیتتر، پایدارتر و انعطافپذیرتری تولید کنند.
در ادامه مقدمهای از کتاب Facilitating Software Architecture را از زبان نویسنده شرح خواهیم داد.
مقدمهای بر کتاب Facilitating Software Architecture:
اگر تحویل نرمافزار صرفاً نوشتن خطوط کد بود، افراد جدا از هم میتوانستند به همان نتایجی دست یابند که تیمهایی از افراد همشمار و با مهارتهای مشابه. اما اینطور نیست. تیمها میتوانند و نرمافزار بهتری میسازند.
در ورزش، انتظار میرود که تواناییها و تجربیات متنوع باشند و همه نقش خود را ایفا کنند. هنگامی که یک تیم مهارتهای خود را ترکیب میکند و بر یک هدف مشترک تمرکز میکند، بیشترین شانس پیروزی را دارد. (این حتی در سطح بنیادی نیز صدق میکند. مربی راگبی پسرم علاقه داشت بگوید: “توپ همیشه سریعتر از یک بازیکن میدود”، به این معنی که آنها باید توپ را بین یکدیگر پاس دهند تا نسبت به حریفان خود برتری پیدا کنند.)
پویایی مشابه در تیمهای توسعه نرمافزار نیز اعمال میشود، جایی که هدف ما تحویل پایدار و تکامل یک محصول نهایی با کیفیت است.
به عنوان یک مشاور، توسعهدهنده و معمار نرمافزار/سیستم، بسیار خوش شانس بودم که با برخی از تیمهای تحویل نرمافزار درخشان همکاری نزدیکی داشتهام. من آنها را در عمل دیدهام که در بسیاری از سبکهای مختلف معماری کار میکنند، از طیف گستردهای از زبانهای برنامهنویسی، ابزارها و پشتههای فناوری استفاده میکنند، رویکردها و روشهای مختلفی را به کار میگیرند، روی طیف وسیعی از زمان اجرا اجرا میشوند و توسط فراوانی از فرهنگها و سازمانها پشتیبانی میشوند. من از دیدن کار آنها چیزهای باورنکردنی یاد گرفتهام. آنها نمونههایی از مفهوم “تیمهای با عملکرد بالا” بودهاند.
همچنین خوش شانس بودم که برخی از معماران نرمافزار درخشان را شناختهام، از آنها آموختهام و – زمانی که بسیار خوش شانس بودم – با آنها همکاری کردهام. من دیدهام که آنها چگونه فکر میکنند، خلق میکنند، خرد را به کار میگیرند و مشکلات را حل میکنند. اما این چیزی نبود که آنها را درخشان میکرد.
چیزی که آنها را درخشان میکرد این بود که چگونه گوش میدادند، ارتباط برقرار میکردند، همکاری میکردند، مشترکاً خلق میکردند و تسهیل میکردند. این بدان معنا بود که معماریهایی که آنها ایجاد کردند با موفقیت وارد جهان شدند و طبق انتظار اجرا شدند.
تیمهای تحویلی که بیشترین درس را به من دادند همیشه موفق شدهاند مهارتها و قابلیتهای بیشترین تعداد از اعضای تیم خود را برای دورههای زمانی طولانی به حداکثر برسانند – کاری که آنها انجام دادند پایدار و به نفع همه آنها بود. معمارانی که بیشترین درس را به من دادند دقیقاً به همان هدف دست یافتند، اما آنها این ارزش را در تمام تیمها ارائه کردند. در همه موارد، آنها توانستند از تمام قدرت بالقوه نرمافزار استفاده کنند.
آن تیمها چه کارهایی انجام میدادند که به معنای موفقیت آنها بود؟ به طور مشابه، چه کارهایی را انجام نمیدادند؟ به تدریج متوجه شدم که تیمهای با عملکرد بالا، با حمایت معماران با بیشترین همکاری، به نظر نمیرسید که تحت تأثیر پیچیدگی باورنکردنی معماریهایی که در حال ساخت و اجرا بودند، قرار بگیرند.
در واقع، بسیاری از مواقع زمانی که این همکاری را در عمل مشاهده میکردم، تشخیص اینکه چه کسی معمار بود و چه کسی اعضای تیم تحویل بود، آسان نبود. ترکیب ذهنیتها و نقشها به حدی گسترده بود که تقریباً احساس میشد همه در حال معماری هستند.
در همین حال، در تیمهای کمعملکرد، به ندرت کمبود مهارت فنی وجود داشت. همچنین نبود تمایل به کار به عنوان یک تیم خودمدیریتی وجود نداشت. چرا شکست خوردند؟ چه کارهایی انجام میدادند که مضر بود؟ چه کارهایی را انجام نمیدادند که به آنها کمک میکرد؟ یک مشکل کلیدی بارها و بارها ظاهر میشد: تیمهای شکستخورده فاقد رابطه دو طرفه با معماری بودند. در عوض، آنها توسط معماران در فاصله دور و طرحهای بسیار محافظتشده آنها و سایر مصنوعات، مانع شدند.
با مشاهده تیمها و معماران موفق و ناموفق، الگوهایی را در روشهای کار شناسایی کردم و مشخص کردم که چه چیزی کار میکند و چه چیزی مانع آنها میشود. با پشتیبانی، آزمایشهایی را انجام دادهام تا ببینم آیا میتوانیم قسمتهای کلیدی ذهنیتها، رویکردها و روشهای مشترک آنها را که به نظر میرسید همه را بسیار قدرتمند میکرد، بهینه کنیم.
در نتیجه، توانستم مجموعهای از عناصر مرتبط و سایر درسهایی را استخراج کنم که باعث شد روشهای تیمهای با عملکرد بالا برای همه قابل دسترسی باشد، که به نوبه خود قدرت بالقوه کامل نرمافزار را به همه بازگرداند.
مارک آندریسن معروف گفت: “نرمافزار در حال بلعیدن جهان است”
Marc Andreesen, “Why Software Is Eating the World”, The Wall Street Journal, August 20, 2011.
زیرا نرمافزار، تمام نرمافزارها، پتانسیل عظیمی دارند. نرمافزار به ما امکان میدهد کارها را سریعتر، ارزانتر و کارآمدتر انجام دهیم. نرمافزار به ما امکان میدهد کارهایی را انجام دهیم که در غیر این صورت غیرممکن است – حتی غیرقابل درک. اما اگرچه آن مقاله (در زمان نگارش) 10 سال پیش منتشر شد و از آینده نزدیک صحبت کرد، نرمافزار همه چیز را در مسیر خود مصرف نکرده است.
این به این دلیل است که اگرچه نرمافزار قدرت دارد، اما آن قدرت هدر میرود و به صورت پیچیدگی، خشکی، هزینه و اتلاف ظاهر میشود. با این حال، اگر بتوانیم با چالشها مقابله کنیم، قدرت همچنان در دسترس ما است، درست همانطور که در زمان نگارش مقاله بود.
با وجود این پتانسیل قدرت، تیمهای بسیار زیادی با اکراه روی رندرهای ناقص دیدگاه دیگری از کسی که در حال تلاش برای حل مشکلی است که در حال تلاش برای حل آن هستند، کار میکنند.
نرمافزار با کیفیت توسط تیمهای هماهنگ و بینرشتهای ایجاد میشود که مشکل خود و طراحیهای استفاده شده برای مقابله با آن را درک میکنند و اختیار آن را دارند. نرمافزار با کیفیت منعکس کننده ذهنیت و مدلهای ذهنی جمعی تیم است که عمیقاً تحت تأثیر واقعیت سیستمهای آنها در دنیای واقعی قرار دارد. این باید آینده همه باشد. این باید تجربه همه باشد.
متأسفانه، این آینده – به نقل از ویلیام گیبسون – به طور نامتوازن توزیع شده است. بارها و بارها، من روشهای معماری، ساختارهای سازمانی و فرهنگهای شرکتی را دیدهام که آگاهانه، حتی عمداً، در مسیر این قدرت جمعی تیمهای بینرشتهای قرار میگیرند. از سوی دیگر، این تلاشها برای کنترل دقیقاً به این دلیل وجود دارد که از قدرت نرمافزار در حالتهای شکست (به درستی) ترسیده میشود. اما هر چه بیشتر تلاش میکردند تا معایب را مدیریت کنند، بیشتر در مسیر مزایای بالقوه قرار میگرفتند.
هدف کتاب Facilitating Software Architecture تغییر روش تمرین معماری نرمافزار به صورت جمعی، ارائه فرصتی به همه برای حضور در یک تیم با عملکرد بالا است. من روشها و ذهنیتهایی را که دیدهام به طور گسترده برای معماران و توسعهدهندگان کار میکنند، به اشتراک خواهم گذاشت. معماران به ویژه یک رویکرد مبتنی بر تسهیل را یاد خواهند گرفت که پتانسیل آزادسازی قدرت تیمهای معمار و نرمافزار آنها را دارد.
توسعهدهندگان یاد خواهند گرفت که چگونه به عنوان شرکای برابر در بحثهای معماری نرمافزار مشارکت کنند و در عین حال بیاموزند و آموزش دهند. کتاب Facilitating Software Architecture به همه – هم معماران و هم توسعهدهندگان – کمک خواهد کرد تا به این رویکرد جدید، مبتنی بر مجموعهای از اصول اساسی که تضمین میکند، صرف نظر از شرایط فردی شما، در مسیر موفقیت باقی خواهید ماند، انتقال یابند.
همانطور که مهارتهای خود را در طول کتاب Facilitating Software Architecture تقویت میکنید، درباره توهم کنترلی که بر معماریها و سیستمهای اجرایی خود دارید و در مورد قدرت یادگیری و تیمها هنگامی که رها میکنید، خواهید آموخت.
اگر شما یک معمار هستید، همچنین یاد خواهید گرفت که چگونه تسهیل جمعی را تسهیل کنید، پتانسیل آن را برای مزایای معماری مشترک خود آزاد و رشد دهید. اگر شما یک عضو تیم هستید، یاد خواهید گرفت که چگونه به معماری نرمافزار کمک کنید، همزمان که یاد میگیرید و آموزش میدهید، تأثیر مثبت همه را به حداکثر برسانید. شاید مهمتر از همه، همه در مورد اهمیت ایمنی و شمول و همچنین نیاز اساسی به صداقت و اعتماد یاد خواهند گرفت.
چرا کتاب Facilitating Software Architecture را نوشتم؟
کتاب تسریع (انتشارات O’Reilly) نوشته نیکول فورسگرن، جز humilde و جین کیم، همه ما را در دنیای مهندسی نرمافزار به چالش کشید تا بهتر عمل کنیم و نتایج بهتری ارائه دهیم. به طور خاص، برای اینکه سریعتر و بدون تاثیر بر کیفیت کار کنیم. برای افزایش استقلال تیم بدون خدشهدار کردن انسجام و کیفیت سیستم نهایی.
در پاسخ به این چالش، من با مجموعهای از روشها آزمایش کردم. برخی از دنیای نرمافزار آمده بودند، برخی دیگر از جاهای دیگر. من از تجربیات افرادی که در رویداد فضای باز Java Posse Roundup ملاقات کرده بودم الهام گرفتم. وقتی اینها را با مشتریان مختلف (که نه از افراد فوقالعاده بلکه از توسعهدهندگان و معمارانی شبیه شما و من تشکیل شده بودند) کنار هم قرار دادم، از اینکه چقدر خوب کار میکردند و چقدر برای همه شرکتکنندگان رضایتبخش بودند، شگفتزده شدم.
بخش زیادی از این آزمایشها پس از آشفتگی ناشی از همهگیری کووید-19 انجام شد. شاید مشتریان احساس میکردند که برای سازگاری با دوران نامشخص نیاز به امتحان رویکردهای جدید و متفاوت دارند. هر دلیلی که داشت، نتایج جالبی به دست آمد که احساس کردم باید با دنیا به اشتراک بگذارم. من افکار اولیهام را در یک رشته توییتری ارسال کردم که به طرز شگفتانگیزی مورد استقبال قرار گرفت.
برخی از همکاران من در Thoughtworks درباره موفقیتهایی که به دست آورده بودم شنیدند و از من پرسیدند که چه کار میکنم. در پاسخ، چیزی نوشتم که به یک پست وبلاگ برای مارتین فولر تبدیل شد: «مقیاسگذاری عملی معماری، به صورت مکالمهای». پس از انتشار آن، باز هم از سطح علاقهای که ایجاد کرد شگفتزده شدم. شروع کردم در مورد آن در کنفرانسها و پادکستها صحبت کنم. مردم هم برای درخواست مشاوره بیشتر و هم برای اینکه به من در مورد رویکردهای بسیار مشابهی که خودشان به آن رسیده بودند، کاملاً مستقل از کاری که من انجام میدادم، نزدیک شدند. دیگران نیز در این زمینه آزمایش میکردند و میخواستند در مورد آن صحبت کنند.
در حالی که همه این اتفاقات در حال رخ دادن بود، من همچنان با مشتریان کار میکردم و طعمهای مختلفی از این رویکرد را با آنها اجرا میکردم، در حالی که از دیگران که همین کار را در سازمانهایشان انجام میدادند، یاد میگرفتم.
من تحقیق کردم که چرا کارها به درستی پیش میرفتند و به مشکلاتی که با آنها مواجه میشدیم توجه کردم. مشخص شد که در مورد این ترکیب اساساً ساده از عناصر، حرفهای زیادی برای گفتن وجود دارد. یادداشتهای من جمع شد و رویکردهایم دقیقتر شد. مجموع آنچه یاد گرفتم در نهایت مرا به نوشتن کتابی که اکنون در دست دارید سوق داد.
بزرگترین امید من این است که کتاب Facilitating Software Architecture، آزمایش، یادگیری و به اشتراک گذاری را ادامه دهد. عمیقترین چیزی که در مورد تجربیاتم به من ضربه میزند، چگونگی تجلی متفاوت عناصر و فرهنگ پیرامون آنها در هنگام راهاندازی است.
اگرچه هستهای وجود دارد که برای به دست آوردن حداکثر بهره از رویکردی که در کتاب Facilitating Software Architecture توضیح میدهم، باید به آن پایبند باشید، اما یک «راه واحد» برای انجام آن وجود ندارد.
آنچه را که در اینجا یاد میگیرید بردارید و آن را با نیازهای خود تطبیق دهید. حتی اگر فقط بخش کوچکی از آن برای شما کارساز باشد، تجربه خود را با دیگران به اشتراک بگذارید. لطفاً آنچه را آموختهاید منتقل کنید تا همه ما بتوانیم بهرهمند شویم.
پیمایش کتاب Facilitating Software Architecture
کتاب Facilitating Software Architecture به شرح زیر سازماندهی شده است:
- فصل 1 کتاب Facilitating Software Architecture مشکل شیوههای معماری متمرکز در دنیای غیرمتمرکز را توصیف میکند.
- بخش اول کتاب Facilitating Software Architecture، “اصول اولیه” (فصلهای 2 تا 6 کتاب Facilitating Software Architecture) جنبههای اصلی رویکرد غیرمتمرکز و با تمرکز بر بازخورد به معماری را پوشش میدهد.
- بخش دوم کتاب Facilitating Software Architecture، “پرورش و تکامل فرهنگ اعتماد غیرمتمرکز شما” (فصلهای 7 تا 11 کتاب Facilitating Software Architecture) پویاییهای ناشی از رویکرد اصلی را روشن میکند و مجموعهای از عناصر حمایتی را برای اطمینان از اثربخشی آنها معرفی میکند.
- بخش سوم کتاب Facilitating Software Architecture، “یافتن راه خود در چشمانداز تصمیمگیری” (فصلهای 12 تا 14 کتاب Facilitating Software Architecture) به شیوههای اصلی بازمیگردد و بررسی میکند که چگونه آنها را در سازمان خود به بهترین نحو اجرا کنید.
- بخش چهارم کتاب Facilitating Software Architecture، “تمرکز بر “اجتماعی” در عمل معماری شما” (فصلهای 15 تا 17 کتاب Facilitating Software Architecture) در نهایت یک قدم عقب میرود و به جنبههای اجتماعی عمل معماری که در صورت اتخاذ این رویکرد در مرکز صحنه قرار میگیرند، نگاه میکند و هم چالشها و هم روشها را به اشتراک میگذارد.
سرفصلهای کتاب Facilitating Software Architecture:
- Cover
- Copyright
- Table of Contents
- Foreword
- Preface
- Chapter 1. Centralized Architecture Practices in a Decentralized World
- Part I. First Principles
- Chapter 2. To Practice Architecture Is to Decide
- Chapter 3. Decisions at Scale
- Chapter 4. The Architecture Advice Process
- Chapter 5. Rolling Out the Architecture Advice Process
- Chapter 6. Architectural Decision Records
- Part II. Nurturing and Evolving Your Culture of Decentralized Trust
- Chapter 7. Replacing Hierarchy with Decentralized Trust
- Chapter 8. An Architecture Advice Forum
- Chapter 9. Testable CFRs and Technology Strategy
- Chapter 10. Collectively Sourced Architectural Principles
- Chapter 11. Using a Technology Radar
- Part III. Finding Your Way Through the Decision Landscape
- Chapter 12. The Art of Deciding
- Chapter 13. Tackling Architectural Variability
- Chapter 14. Variability and the Interconnectedness of Decisions
- Part IV. Centering the “Social” in Your Practice of Architecture
- Chapter 15. The Transition of Power and Accountability
- Chapter 16. On Leadership
- Chapter 17. Fitting the Advice Process Within Your Organization
- Index
- About the Author
- Colophon
جهت دانلود کتاب Facilitating Software Architecture میتوانید پس از پرداخت، دریافت کنید.
دیدگاهها
هیچ دیدگاهی برای این محصول نوشته نشده است.