موضوع پروژه: مطالعه کتاب
عنوان کتاب: «Team Topologies: Organizing Business and Technology for Fast Flow of Value»
نویسندگان: Matthew Skelton و Manuel Pais
ویرایش دوم، ۲۰۲۵
جمع آوری و نگارش: آرمان مقیمی ابیانه
استاد درس: دکتر صادق علی‌اکبری
دانشکده مهندسی و علوم کامپیوتر - دانشگاه شهید بهشتی
کتاب «Team Topologies» نوشته‌ی متیو اسکلتون و مانوئل پایس، به بررسی یکی از مسائل اساسی در مهندسی نرم‌افزار مدرن می‌پردازد: چگونه باید تیم‌های یک سازمان نرم‌افزاری را طراحی و سازمان‌دهی کرد تا بتوانند با سرعت، استقلال، کیفیت و پایداری بیشتری نرم‌افزار تولید و تکامل دهند. نویسندگان استدلال می‌کنند که مشکلات مربوط به سرعت پایین توسعه، وابستگی بیش از حد میان تیم‌ها، معماری‌های پیچیده، افزایش بار شناختی مهندسان و سازمان‌دهی‌های ناکارآمد، صرفاً مشکلات فنی نیستند؛ بلکه ارتباط مستقیمی با نحوه‌ی سازمان‌دهی افراد و تیم‌هایی دارند که نرم‌افزار را می‌سازند.
ایده‌ی محوری کتاب این است که «تیم» باید واحد اصلی طراحی در یک سازمان نرم‌افزاری در نظر گرفته شود. بنابراین، همان‌گونه که برای طراحی یک سیستم نرم‌افزاری درباره‌ی معماری، مرزهای اجزا، رابط‌ها و وابستگی‌ها تصمیم‌گیری می‌کنیم، باید برای تیم‌هایی که آن سیستم را ایجاد و نگهداری می‌کنند نیز به‌صورت آگاهانه درباره‌ی مسئولیت‌ها، مرزها، اندازه، وابستگی‌ها و شیوه‌ی تعامل تصمیم بگیریم.
کتاب در سه بخش اصلی سازمان‌دهی شده است. بخش نخست به نقش تیم‌ها در تحویل نرم‌افزار، قانون کانوی و تفکر تیم‌محور می‌پردازد. بخش دوم چهار توپولوژی بنیادی تیم‌ها و نحوه‌ی انتخاب مرزهای مناسب را معرفی می‌کند. بخش سوم نیز بر نحوه‌ی تعامل تیم‌ها و تکامل تدریجی ساختار سازمانی بر اساس تغییر شرایط تمرکز دارد.
کتاب بحث خود را با نقد «نمودار سازمانی» یا Org Chart آغاز می‌کند. در سازمان‌های سنتی، نمودار سازمانی معمولاً ساختار سلسله‌مراتبی، مدیران، واحدها و روابط گزارش‌دهی را نمایش می‌دهد. با این حال، این نمودار الزاماً نشان‌دهنده‌ی مسیر واقعی ارتباطات در سازمان نیست.
در توسعه‌ی نرم‌افزار، افراد معمولاً برای انجام کار خود فقط با مدیر مستقیم یا اعضای تیم خود ارتباط برقرار نمی‌کنند. یک مهندس ممکن است برای حل یک مشکل فنی با متخصص تیم دیگری، تیم زیرساخت، تیم امنیت یا حتی یک توسعه‌دهنده در بخشی کاملاً متفاوت از سازمان ارتباط برقرار کند. بنابراین، ساختار واقعی ارتباطات می‌تواند با خطوط موجود در نمودار سازمانی تفاوت قابل‌توجهی داشته باشد. کتاب تأکید می‌کند که تکیه‌ی بیش از حد بر Org Chart باعث می‌شود سازمان تلاش کند انسان‌ها را مانند اجزای یک سیستم نرم‌افزاری در خطوط ارتباطی از پیش تعیین‌شده قرار دهد، در حالی که افراد برای حل مسائل واقعی به‌صورت افقی و انعطاف‌پذیر با یکدیگر ارتباط برقرار می‌کنند.
مشکل دیگر، بهینه‌سازی محلی است. ممکن است یک تیم با تغییر ساختار داخلی خود عملکرد بهتری پیدا کند، اما این تغییر هیچ بهبودی در جریان کلی تحویل ارزش ایجاد نکند. برای مثال، اگر یک تیم بسیار سریع عمل کند ولی برای تکمیل هر تغییر مجبور باشد منتظر چند تیم دیگر بماند، سرعت واقعی تحویل نرم‌افزار همچنان پایین خواهد بود. بنابراین، هدف اصلی نباید صرفاً افزایش بهره‌وری یک تیم باشد، بلکه باید بهبود «جریان ارزش» در کل سازمان باشد.
از دیدگاه کتاب، سازمان نرم‌افزاری باید به‌جای تمرکز صرف بر ساختار مدیریتی، بر تیم‌های کوچک، پایدار، مستقل و دارای مسئولیت مشخص تمرکز کند.
یکی از مهم‌ترین مفاهیم کتاب، «قانون کانوی» (Conway’s Law) است. این قانون بیان می‌کند که ساختار سیستم‌هایی که یک سازمان طراحی می‌کند، معمولاً بازتابی از ساختار ارتباطات موجود در همان سازمان است.
به بیان ساده، اگر چهار تیم نرم‌افزاری به شکلی سازمان‌دهی شوند که هر تیم به مجموعه‌ای خاص از اجزای سیستم دسترسی داشته باشد و ارتباط میان آن‌ها از مسیرهای مشخصی انجام شود، معماری نرم‌افزار نیز به‌احتمال زیاد همان الگوی ارتباطی را منعکس خواهد کرد.
کتاب برای توضیح این مفهوم مثالی ارائه می‌کند. فرض می‌شود چهار تیم توسعه وجود دارند که هرکدام شامل توسعه‌دهندگان Front-end و Back-end هستند، اما همه‌ی آن‌ها برای تغییرات پایگاه داده باید به یک تیم یا متخصص DBA مراجعه کنند. چنین ساختاری احتمالاً به معماری‌ای منجر می‌شود که در آن چند بخش نرم‌افزاری مستقل وجود دارد، اما همگی به یک پایگاه داده‌ی مشترک وابسته‌اند. بنابراین، ساختار تیم‌ها مستقیماً بر معماری حاصل تأثیر گذاشته است.
این موضوع در معماری Microservices اهمیت بیشتری پیدا می‌کند. اگر هدف، ایجاد سرویس‌های مستقل با پایگاه‌های داده‌ی مستقل باشد، وجود یک تیم پایگاه داده‌ی مرکزی که تمام تیم‌های دیگر برای تغییرات به آن وابسته باشند، با این معماری سازگار نیست. نویسندگان پیشنهاد می‌کنند که برای ایجاد چنین معماری‌ای، ساختار تیم‌ها نیز متناسب با معماری موردنظر طراحی شود؛ برای مثال، قابلیت‌های مرتبط با داده در خود تیم‌های توسعه قرار گیرد تا هر تیم بتواند مسئولیت سرویس و داده‌ی مربوط به حوزه‌ی خود را بر عهده بگیرد.
از همین ایده، مفهوم «Reverse Conway Maneuver» شکل می‌گیرد. در این روش، سازمان ابتدا معماری مطلوب آینده را مشخص می‌کند و سپس ساختار تیم‌ها و مسیرهای ارتباطی را به‌گونه‌ای طراحی می‌کند که احتمال شکل‌گیری آن معماری افزایش یابد. هدف این است که معماری نرم‌افزار و معماری سازمانی در یک راستا قرار گیرند.
پس از قانون کانوی، کتاب مفهوم «Team-First Thinking» را معرفی می‌کند. در این دیدگاه، تیم یک مجموعه‌ی تصادفی از افراد با مدیر مشترک نیست؛ بلکه یک واحد مستقل با هدف، مأموریت، دانش مشترک، چرخه‌ی یادگیری و سطح معقولی از استقلال است.
نویسندگان بر اهمیت تیم‌های کوچک و پایدار تأکید می‌کنند. دلیل این موضوع تنها سهولت مدیریت نیست، بلکه محدودیت‌های شناختی انسان است. با افزایش اندازه‌ی تیم، تعداد روابط ارتباطی و مقدار اطلاعاتی که اعضای تیم باید در ذهن داشته باشند افزایش پیدا می‌کند. در نتیجه، هماهنگی دشوارتر شده و بخشی از ظرفیت شناختی افراد صرف مدیریت ارتباطات به‌جای حل مسائل اصلی می‌شود. کتاب در این زمینه از مفاهیمی مانند Dunbar’s Number، اعتماد، اندازه‌ی تیم و چرخه‌ی عمر تیم استفاده می‌کند.
مفهوم مهم دیگر در این بخش، «Cognitive Load» یا بار شناختی تیم است. یک تیم زمانی عملکرد مناسبی دارد که بتواند دانش و اطلاعات موردنیاز برای انجام مسئولیت‌های خود را مدیریت کند. اگر مسئولیت تیم بیش از حد گسترده باشد، اعضای آن مجبور می‌شوند هم‌زمان درباره‌ی تعداد زیادی فناوری، سیستم، دامنه‌ی کسب‌وکار و وابستگی فکر کنند. در چنین شرایطی، حتی افزایش تعداد افراد نیز الزاماً مشکل را حل نمی‌کند.
بنابراین، یکی از اصول اصلی Team Topologies این است که دامنه‌ی مسئولیت هر تیم باید با ظرفیت شناختی آن تیم سازگار باشد. معماری نرم‌افزار نیز باید تا حد امکان به اندازه‌ای تقسیم شود که یک تیم بتواند مالکیت و تکامل آن را به‌صورت پایدار بر عهده بگیرد.
هدف اصلی مدل Team Topologies، ایجاد «Fast Flow of Value» یا جریان سریع ارزش است. منظور از جریان ارزش، مسیر حرکت یک تغییر از ایده یا نیاز کسب‌وکار تا تبدیل شدن آن به قابلیت واقعی و قابل استفاده برای مشتری است.
هرچه برای تکمیل یک تغییر، تعداد بیشتری تحویل، هماهنگی، تأیید و وابستگی بین تیم‌ها لازم باشد، جریان کندتر خواهد شد. به همین دلیل، نویسندگان توصیه می‌کنند تیم‌ها تا حد امکان بتوانند بخش قابل‌توجهی از کار خود را از ابتدا تا انتها انجام دهند و برای هر مرحله‌ی کوچک منتظر تیم دیگری نباشند.
در این مدل، استقلال به معنای «عدم ارتباط» نیست. ارتباط میان تیم‌ها ضروری است، اما باید مشخص، هدفمند و متناسب با نوع نیاز باشد. یکی از اهداف Team Topologies این است که وابستگی‌های غیرضروری کاهش پیدا کنند و ارتباطات میان تیم‌ها به شکل قابل‌پیش‌بینی‌تری انجام شود.
مهم‌ترین بخش کتاب معرفی چهار نوع اصلی Team Topology است. نویسندگان معتقدند که با استفاده‌ی صحیح از این چهار نوع، می‌توان تقریباً تمام نیازهای سازمان‌دهی تیم‌های مدرن نرم‌افزاری را پوشش داد:
۱. Stream-Aligned Team
۲. Enabling Team
۳. Complicated-Subsystem Team
۴. Platform Team
این چهار نوع باید به‌عنوان الگوهای اصلی برای طراحی تیم‌ها در نظر گرفته شوند و سایر انواع تیم‌ها تا حد امکان به یکی از این الگوها نزدیک شوند. هدف از این ساده‌سازی، کاهش ابهام درباره‌ی مسئولیت و مأموریت تیم‌هاست.
۶.۱. تیم Stream-Aligned
Stream-Aligned Team مهم‌ترین نوع تیم در مدل Team Topologies است. یک «Stream» جریان پیوسته‌ای از کار است که معمولاً با یک حوزه‌ی کسب‌وکار، محصول، قابلیت یا گروه مشخصی از کاربران مرتبط است.
تیم Stream-Aligned باید تا حد امکان دارای مهارت‌های موردنیاز برای تحویل End-to-End باشد و بتواند بدون انتظار طولانی برای تیم‌های دیگر، تغییرات معناداری در محصول ایجاد کند. این تیم فقط مسئول نوشتن کد نیست؛ بلکه در صورت امکان باید مسئول ساخت، استقرار، اجرا و نگهداری سیستم نیز باشد.
در این مدل، تیم‌های Ops و Support به‌عنوان تیم‌های جداگانه و دائمی که در پایان کار نرم‌افزار را تحویل می‌گیرند، مورد تأکید نیستند. تیم‌های Stream-Aligned باید به اجرای واقعی نرم‌افزار نزدیک باشند و مسئولیت سیستم خود را در محیط Production نیز درک کنند.
۶.۲. تیم Enabling
Enabling Team برای کمک به تیم‌های دیگر در یادگیری، رفع شکاف مهارتی یا پذیرش فناوری و روش‌های جدید ایجاد می‌شود.
این تیم معمولاً نباید مسئولیت دائمی یک بخش از محصول را بر عهده بگیرد. هدف آن این است که یک تیم Stream-Aligned را برای مدت مشخصی توانمند کند و سپس وابستگی به تیم Enabling کاهش یابد.
برای مثال، اگر یک تیم توسعه نیاز داشته باشد روش جدیدی برای Continuous Delivery، Cloud، امنیت یا فناوری خاصی را یاد بگیرد، یک Enabling Team می‌تواند آموزش، راهنمایی و تسهیل لازم را ارائه دهد. کتاب تأکید می‌کند که Enabling Team با Community of Practice یکسان نیست؛ Enabling Team یک تیم کوچک و مشخص با مأموریت معین است، در حالی که Community of Practice معمولاً گروه گسترده‌تری از افراد علاقه‌مند از چند تیم مختلف است.
۶.۳. تیم Complicated-Subsystem
برخی قسمت‌های یک سیستم به دانش تخصصی بسیار عمیق نیاز دارند. برای مثال، یک الگوریتم پردازش ویدئو، مدل ریاضی پیچیده، سیستم تسویه‌ی معاملات مالی یا موتور تشخیص چهره ممکن است نیازمند متخصصانی باشد که قرار دادن آن‌ها در تمام تیم‌های Stream-Aligned عملی یا اقتصادی نیست.
در چنین شرایطی، Complicated-Subsystem Team مسئول آن بخش تخصصی می‌شود. هدف این تیم، انتقال یا کاهش پیچیدگی از دوش تیم‌های Stream-Aligned است.
نکته‌ی مهم این است که نویسندگان با Component Teamهای سنتی تفاوت قائل می‌شوند. یک تیم نباید صرفاً به این دلیل ایجاد شود که یک Component در چند سیستم استفاده می‌شود. معیار اصلی باید میزان پیچیدگی و دانش تخصصی موردنیاز باشد. بنابراین، تعداد Complicated-Subsystem Teamها باید محدود و فقط در موارد واقعاً ضروری باشد.
۶.۴. تیم Platform
Platform Team با هدف فراهم کردن قابلیت‌هایی ایجاد می‌شود که به تیم‌های Stream-Aligned اجازه دهند با استقلال بیشتری کار کنند.
برای مثال، یک Platform می‌تواند امکانات مربوط به زیرساخت Cloud، CI/CD، محیط‌های تست، Logging، Monitoring یا سایر قابلیت‌های فنی مشترک را به‌صورت Self-Service در اختیار تیم‌های دیگر قرار دهد.
نکته‌ی مهم این است که Platform نباید تبدیل به یک گلوگاه جدید شود. اگر هر تیم برای انجام یک کار ساده مجبور باشد یک درخواست به Platform Team ارسال کند و منتظر انجام دستی آن بماند، Platform به‌جای افزایش سرعت، وابستگی ایجاد کرده است.
در ویرایش دوم کتاب، نویسندگان تأکید بیشتری بر مفهوم «Platform Grouping» دارند. در سازمان‌های بزرگ‌تر، یک Platform ممکن است از چند تیم تشکیل شود و خود Platform را می‌توان مانند یک ساختار Fractal در نظر گرفت؛ یعنی با نزدیک شدن به داخل آن، دوباره همان الگوهای تیمی مشاهده می‌شوند.
پس از تعریف انواع تیم‌ها، کتاب به مسئله‌ی تعیین مرزهای مناسب برای مسئولیت‌های تیم‌ها می‌پردازد. مرز یک تیم باید به اندازه‌ای باشد که آن تیم بتواند مسئولیت خود را به‌طور مؤثر مالکیت و تکامل دهد.
یکی از مشکلات مهم، وجود «Hidden Monolith»ها است. یک سیستم ممکن است از نظر کدنویسی به Microservices تقسیم شده باشد، اما همچنان به دلیل Shared Database، Coupled Builds، Coupled Releases یا وابستگی‌های مشابه، در عمل مانند یک Monolith رفتار کند. در این شرایط، تقسیم ظاهری نرم‌افزار به سرویس‌های کوچک لزوماً استقلال واقعی ایجاد نکرده است.
کتاب پیشنهاد می‌کند مرزهای نرم‌افزاری در بسیاری از موارد با Business Domain و Bounded Contextها هماهنگ شوند. این کار باعث می‌شود مرزهای معماری با جریان‌های واقعی تغییر در کسب‌وکار هماهنگ شوند و تیم‌های Stream-Aligned بتوانند مسئولیت مشخص‌تری داشته باشند.
البته Bounded Context تنها معیار ممکن نیست. نویسندگان از مفهوم «Fracture Plane» نیز استفاده می‌کنند؛ یعنی نقطه‌ای که می‌توان سیستم را به‌گونه‌ای تقسیم کرد که وابستگی و هماهنگی بین تیم‌ها کاهش یابد. فناوری، الزامات قانونی، Performance، موقعیت جغرافیایی تیم‌ها و نوع کاربران می‌توانند در انتخاب چنین مرزهایی نقش داشته باشند.
داشتن تیم‌های مناسب به‌تنهایی کافی نیست. باید مشخص باشد که این تیم‌ها چگونه با یکدیگر تعامل می‌کنند. کتاب سه Interaction Mode اصلی معرفی می‌کند:
الف) Collaboration
ب) X-as-a-Service
ج) Facilitating
در حالت Collaboration، دو تیم به‌صورت نزدیک با یکدیگر روی یک هدف مشترک کار می‌کنند. این حالت به‌خصوص در زمان کشف فناوری جدید، حل مسئله‌ی ناشناخته یا Innovation مفید است. مزیت آن یادگیری سریع است، اما هزینه‌ی ارتباطی بالایی دارد؛ بنابراین نباید برای همیشه ادامه پیدا کند.
در حالت X-as-a-Service، یک تیم چیزی را به‌عنوان یک سرویس در اختیار تیم دیگر قرار می‌دهد. این سرویس می‌تواند API، ابزار، Platform، محیط تست یا حتی یک محصول نرم‌افزاری باشد. در این حالت، هدف کاهش نیاز به ارتباط مستقیم و ایجاد یک رابط مشخص است. تجربه‌ی استفاده از سرویس نیز اهمیت زیادی دارد؛ یعنی API یا Platform باید از دید تیم مصرف‌کننده قابل‌استفاده و قابل‌فهم باشد.
در حالت Facilitating، یک تیم به تیم دیگری برای یادگیری یا رفع یک مشکل کمک می‌کند. این حالت معمولاً برای Enabling Teamها اهمیت زیادی دارد. هدف این نیست که تیم کمک‌کننده برای همیشه مسئولیت کار را بر عهده بگیرد، بلکه باید توانایی تیم اصلی را افزایش دهد.
بنابراین، یکی از پیام‌های مهم کتاب این است که ارتباط بین تیم‌ها باید دارای یک «نوع» و هدف مشخص باشد. ارتباطات مبهم و دائمی معمولاً نشانه‌ای از مرزبندی نامناسب تیم‌ها است.
یکی از تفاوت‌های مهم Team Topologies با مدل‌های ثابت سازمانی این است که نویسندگان انتظار ندارند ساختار تیم‌ها برای همیشه ثابت باقی بماند.
فناوری، بازار، نیاز مشتری، اندازه‌ی سازمان و میزان تخصص تیم‌ها تغییر می‌کند. بنابراین، توپولوژی مناسب امروز ممکن است چند ماه یا چند سال بعد دیگر مناسب نباشد.
برای مثال، ممکن است دو تیم در ابتدای توسعه‌ی یک فناوری جدید مجبور باشند به‌شدت با یکدیگر همکاری کنند، اما پس از تثبیت فناوری، بهتر باشد تعامل آن‌ها به X-as-a-Service تبدیل شود. در نتیجه، همکاری نزدیک یک مرحله‌ی موقت است و استقلال بیشتر می‌تواند مرحله‌ی بعدی باشد.
کتاب از مفهوم «Organizational Sensing» برای توصیف این قابلیت استفاده می‌کند. سازمان باید بتواند از مشکلات و نشانه‌های موجود در فرآیند توسعه و عملیات نرم‌افزار برای تشخیص نیاز به تغییر استفاده کند.
به عبارت دیگر، مشکلاتی مانند افزایش زمان تحویل، وابستگی زیاد میان تیم‌ها، افزایش بار شناختی، کاهش سرعت Release یا ایجاد گلوگاه در یک Platform نباید فقط به‌عنوان شکست تیم‌ها تلقی شوند؛ بلکه می‌توانند «سیگنال»هایی باشند که نشان می‌دهند ساختار سازمان یا مرزهای تیمی نیاز به تغییر دارند.
کتاب همچنین تأکید می‌کند که اطلاعات حاصل از عملیات واقعی سیستم‌ها می‌تواند ورودی بسیار ارزشمندی برای چنین فرایند تصمیم‌گیری باشد. تیم‌های عملیاتی و مهندسانی که به رفتار واقعی سیستم در Production دسترسی دارند، می‌توانند اطلاعات دقیقی درباره‌ی مشکلات و نقاط اصطکاک ارائه کنند.
یکی دیگر از مفاهیم مطرح‌شده در ویرایش دوم، «Fractal Organization» است. ایده‌ی اصلی این است که برخی الگوهای سازمانی می‌توانند در چند مقیاس مختلف تکرار شوند.
برای مثال، یک Platform بزرگ ممکن است از چند تیم تشکیل شده باشد. هر یک از این تیم‌ها نیز می‌تواند خود یکی از چهار توپولوژی بنیادی را داشته باشد. بنابراین، با حرکت از سطح سازمان به سطح Platform و سپس به سطح تیم، می‌توان الگوهای مشابهی را مشاهده کرد.
این مفهوم برای سازمان‌های بزرگ اهمیت دارد، زیرا نشان می‌دهد Team Topologies فقط برای سازمان‌های کوچک طراحی نشده است. اصول آن می‌توانند در سطوح مختلف سازمانی تکرار شوند، مشروط بر اینکه مسئولیت‌ها، مرزها و وابستگی‌ها در هر سطح به‌درستی مدیریت شوند.
کتاب علاوه بر معرفی الگوهای مطلوب، چندین Anti-Pattern رایج را نیز بررسی می‌کند. یکی از آن‌ها ایجاد تیم‌ها به‌صورت واکنشی و بدون طراحی آگاهانه است. برای مثال، سازمان ممکن است بعد از یک مشکل Production یک DBA Team، Infrastructure Team یا DevOps Team ایجاد کند، بدون اینکه اثر آن تیم جدید بر جریان کلی تحویل بررسی شود. چنین تیمی ممکن است به‌سرعت به یک Dependency برای تمام تیم‌های دیگر تبدیل شود.
Anti-Pattern مهم دیگر، Component Teamهای متعدد است. اگر سازمان برای هر بخش فنی کوچک یک تیم جدا ایجاد کند، تیم‌های Feature یا Stream-Aligned مجبور می‌شوند برای انجام یک قابلیت ساده بین چندین تیم جابه‌جا شوند. در نتیجه، تعداد Handoffها و وابستگی‌ها افزایش یافته و Flow کاهش می‌یابد.
همچنین کتاب نسبت به Reorganizationهای مکرر که صرفاً با هدف مدیریتی یا کاهش تعداد کارکنان انجام می‌شوند هشدار می‌دهد. تغییر ساختار سازمانی باید با معماری مطلوب، Cognitive Load، جریان ارزش و نیازهای واقعی سیستم هماهنگ باشد؛ در غیر این صورت، Reorganization می‌تواند توانایی سازمان برای توسعه‌ی پایدار نرم‌افزار را کاهش دهد.
اگر تمام مفاهیم کتاب را در کنار یکدیگر قرار دهیم، مدل Team Topologies را می‌توان به شکل یک زنجیره‌ی منطقی در نظر گرفت.
ابتدا باید تیم را واحد اصلی تحویل نرم‌افزار بدانیم. سپس باید مسئولیت هر تیم را با توجه به ظرفیت شناختی آن تعیین کنیم. بعد، باید ساختار تیم‌ها را با معماری مطلوب نرم‌افزار هماهنگ کنیم؛ این همان استفاده از Conway’s Law و Reverse Conway Maneuver است.
در مرحله‌ی بعد، تیم‌ها باید در یکی از چهار توپولوژی بنیادی قرار گیرند: Stream-Aligned، Enabling، Complicated-Subsystem یا Platform. سپس باید برای ارتباط میان آن‌ها یکی از سه Interaction Mode یعنی Collaboration، X-as-a-Service یا Facilitating را انتخاب کنیم.
در نهایت، این ساختار نباید ثابت تلقی شود. سازمان باید از نشانه‌های حاصل از توسعه و عملیات استفاده کند تا متوجه شود آیا مرزها، وابستگی‌ها و تعاملات موجود همچنان مناسب هستند یا خیر. در صورت تغییر شرایط، Topology و Interaction Mode نیز باید تغییر کنند.
به این ترتیب، Team Topologies یک مدل صرفاً برای «تقسیم کردن افراد به تیم‌ها» نیست؛ بلکه مدلی برای هماهنگ کردن سه عنصر مهم است: ساختار تیم‌ها، معماری نرم‌افزار و جریان ارزش.
اهمیت Team Topologies برای مهندسان نرم‌افزار در این است که بسیاری از مشکلاتی را که معمولاً به‌عنوان مشکلات معماری، DevOps یا مدیریت پروژه شناخته می‌شوند، از زاویه‌ی دیگری بررسی می‌کند.
برای مثال، اگر یک Microservice دائماً به چند تیم دیگر وابسته باشد، مشکل الزاماً فقط در کد آن سرویس نیست؛ ممکن است مرز تیم‌ها اشتباه انتخاب شده باشد. اگر یک تیم دائماً منتظر Infrastructure Team باشد، ممکن است مشکل کمبود ابزار نباشد، بلکه Platform به شکل نادرستی طراحی شده باشد. اگر اعضای یک تیم مجبور باشند درباره‌ی تعداد زیادی فناوری و سیستم غیرمرتبط دانش کسب کنند، مشکل ممکن است از Cognitive Load و دامنه‌ی مسئولیت تیم ناشی شود.
بنابراین، کتاب دیدگاه Software Engineering را از «طراحی سیستم» به «طراحی سیستم اجتماعی-فنی» گسترش می‌دهد. نرم‌افزار توسط افراد و تیم‌ها ساخته می‌شود و در نتیجه، معماری سازمانی و معماری نرم‌افزار نمی‌توانند کاملاً مستقل از یکدیگر طراحی شوند.
کتاب Team Topologies تلاش می‌کند یک چارچوب منسجم برای سازمان‌دهی تیم‌های نرم‌افزاری و ایجاد جریان سریع و پایدار ارزش ارائه کند. نقطه‌ی شروع این چارچوب، پذیرش این واقعیت است که ساختار سازمان و مسیرهای ارتباطی آن تأثیر مستقیمی بر معماری نرم‌افزار دارند؛ موضوعی که در قانون کانوی بیان می‌شود.
راهکار کتاب، طراحی آگاهانه‌ی تیم‌های کوچک، پایدار، مستقل و دارای مسئولیت مشخص است. این تیم‌ها باید از نظر Cognitive Load توانایی مدیریت مسئولیت‌های خود را داشته باشند و معماری نرم‌افزار نیز باید به اندازه‌ای تقسیم شود که با ظرفیت یک تیم سازگار باشد.
چهار توپولوژی بنیادی Stream-Aligned، Enabling، Complicated-Subsystem و Platform ساختار اصلی این مدل را تشکیل می‌دهند. در کنار آن‌ها، سه روش Collaboration، X-as-a-Service و Facilitating مشخص می‌کنند که تیم‌ها در چه شرایطی و با چه هدفی باید با یکدیگر تعامل داشته باشند.
مهم‌تر از همه، Team Topologies یک مدل ایستا نیست. سازمان باید دائماً شرایط محیطی، فناوری، نیاز مشتری، عملکرد سیستم و مشکلات موجود در جریان تحویل را مشاهده کند و در صورت مشاهده‌ی نشانه‌های نامناسب، ساختار تیم‌ها و نحوه‌ی تعامل آن‌ها را تکامل دهد.
در نهایت، پیام اصلی کتاب را می‌توان چنین بیان کرد: برای دستیابی به نرم‌افزار قابل‌تکامل و جریان سریع ارزش، تنها انتخاب فناوری و معماری مناسب کافی نیست؛ باید تیم‌هایی با مسئولیت‌های مناسب، بار شناختی قابل‌مدیریت، مرزهای روشن و تعاملات مشخص طراحی کرد و سپس اجازه داد این ساختار همگام با تغییرات سازمان و سیستم تکامل پیدا کند. به همین دلیل، Team Topologies را می‌توان چارچوبی برای هم‌راستا کردن «افراد، تیم‌ها، معماری نرم‌افزار و جریان ارزش» در سازمان‌های مدرن نرم‌افزاری دانست.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
