در این پست، قصد دارم خلاصه‌ای از مفاهیم کلیدی کتاب Team topologies را ارائه دهم و نکاتی را مرور کنم که به نظر من برای هر کسی که درگیر ساخت یا مدیریت تیم‌های نرم‌افزاری است، می‌تواند مفید و کاربردی باشد.
نکتهی محوری کتاب این است که بسیاری از مشکلات تحویل نرم‌افزار، ریشه در ساختار تیم‌ها و نحوهی تعامل آنها با یکدیگر دارد، نه صرفاً در فناوری یا فرآیندها. نویسندگان با تکیه بر قانون کانوی و مفهوم بار شناختی، مدلی عملی برای طراحی سازمان ارائه می‌دهند که در آن تیم‌ها به جای سازماندهی بر اساس تخصص‌های فنی، بر اساس جریان ارزش ساماندهی می‌شوند.
در ادامه، مهم‌ترین ایده‌های این کتاب را به زبانی ساده و خلاصه مرور می‌کنم.
سازمان‌های فناوری امروز با چالشی دوگانه روبرو هستند: از یک سو باید سامانه‌های نرم‌افزاری پیچیده را با سرعت بالا تحویل دهند و از سوی دیگر باید ایمنی و پایداری را حفظ کنند. تیم‌ها بهترین ابزار برای تحویل پیوسته و پایدار ارزش هستند، به شرطی که با نیازهای کسب‌وکار هم‌راستا باشند. تیم‌های ایده‌آل باید بلندعمر، خودمختار و دارای اعضای درگیر و متعهد باشند، اما لازم است بدانند چه زمانی و چگونه با تیم‌های دیگر تعامل کنند. این تعامل‌ها باید با گذر زمان و متناسب با مرحله‌های کشف و اجرا در چرخه عمر محصول و فناوری تغییر کنند.
رویکرد Team Topologies یک مدل عملی، گام‌به‌گام و تطبیقی برای طراحی سازمان ارائه می‌دهد، نه یک فرمول جهان‌شمول. این رویکرد برای بسیاری از تیم‌ها و سازمان‌ها الگوهای روشن و قابل‌فهم فراهم میکند و به آنها کمک میکند تا بدون نیاز به نسخه‌های دستوری برای افراد بسیار ممتاز یا سازمان‌های بسیار بالغ، مسیر موفقیت را پیدا کنند. این مدل چارچوبی مشخص ارائه می‌دهد که در عین حال فضای کافی برای تفسیر و انطباق با شرایط خاص هر سازمان را باقی می‌گذارد.
در سازمان‌های بزرگتر از حدود چهل تا پنجاه نفر، یک پلتفرم داخلی به بیش از یک تیم هشت‌نفره برای ارائه خدمات لازم نیاز دارد. به همین دلیل، مفهوم «تیم پلتفرم» به «گروه‌بندی پلتفرم» تعمیم داده شده است که می‌تواند شامل چندین تیم باشد. این رویکرد فراکتالی به این معناست که اگر به درون یک پلتفرم بزرگ‌نمایی کنیم، همان چهار نوع تیم بنیادی را در آنجا نیز مشاهده خواهیم کرد.
تغییرات سازمانی موفق معمولاً توسط نیازهای کسب‌وکار و فشار برای رقابتی ماندن هدایت می‌شوند. سازمان‌هایی که صرفاً به خاطر مد روز یا پیاده‌سازی «بهترین شیوه‌های صنعت» دست به بازسازی می‌زنند، معمولاً در بلندمدت موفق نمی‌شوند. رویکرد Team Topologies یک سفر مستمر است، نه یک برنامه تغییر کوتاه‌مدت با زمان پایان مشخص.
بخش اول: تیم‌ها به‌عنوان ابزار تحویل
فصل اول: مسئله با چارت سازمانی
سازمان‌های فناوری باید به‌جای نگاه مکانیکی و خطی، به‌صورت موجودیت‌های پیچیده و سازگارپذیر دیده شوند. ساخت و اداره سامانه‌های امروزی نیازمند ترکیب مهارت‌های مختلف در قالب کار تیمی است، زیرا این سامانه‌ها مستقیماً بر زندگی روزمره مردم اثر می‌گذارند. اگر طراحی یا تعامل میان نرم‌افزار، ارائه‌دهنده و مشتری نامناسب باشد، پیامدهای جدی ایجاد می‌شود. سازمان‌های فناوری باید هم‌زمان سریع و ایمن عمل کنند، اما بسیاری هنوز افراد و تیم‌ها را بر پایه چارت سازمانی و ماتریس‌ها سازماندهی می‌کنند، در حالی که برای کار دانش‌محور، تیم‌های پایدار، توانمند و بلندعمر لازم است.
چارت سازمانی فقط یک نمای رسمی از تیم‌ها، واحدها و سلسله‌مراتب گزارش‌دهی است و در عمل، مسیرهای واقعی ارتباطی را نشان نمی‌دهد. چارت در زمینه‌هایی مانند انطباق قانونی و مقرراتی کاربرد دارد، اما وقتی کار پیچیده و همراه با عدم قطعیت است، تکیه بر آن برای تقسیم کار به انتظارات غیرواقعی می‌انجامد. مردم در عمل برای پیش بردن کار، به‌صورت افقی و خارج از خطوط رسمی با یکدیگر ارتباط می‌گیرند؛ بنابراین باید تصویر دقیق‌تری از ارتباطات واقعی و مورد انتظار بین افراد و تیم‌ها داشت.
تصمیم‌های مبتنی بر چارت سازمانی معمولاً فقط یک بخش از سیستم را بهینه می‌کنند و اثرات بالادستی و پایین‌دستی را نادیده می‌گیرند. به جای دنبال کردن چارت، باید به جریان کلی کار، گلوگاه واقعی، و هماهنگی میان بخش‌های مختلف توجه کرد.
سه ساختار متفاوت در هر سازمان وجود دارد: ساختار رسمی (چارت سازمانی)، ساختار غیررسمی (حوزه نفوذ بین افراد)، و ساختار خلق ارزش (نحوه انجام واقعی کار بر اساس اعتبار بین‌فردی و بین‌تیمی). موفقیت در کار دانشی به تعامل میان ساختار غیررسمی و ساختار خلق ارزش وابسته است. Team Topologies با توانمندسازی تیم‌ها و تعریف روشن الگوهای تعامل، تلاش میکند این روابط را شفاف‌تر و قابل‌اعتمادتر کند. رویکردهای سازمانی نیز اغلب در عمل به‌سرعت از واقعیت عقب می‌مانند، چون سازمان و فناوری دائماً تغییر می‌کنند. بنابراین به‌جای یک ساختار ایستا، به مدلی تطبیقی و پویا نیاز است که با رشد تیم‌ها و تغییر زمینه هماهنگ شود.
کتاب چهار نوع اصلی تیم و سه حالت اصلی تعامل را معرفی میکند. این کتاب تیم را واحد بنیادی تحویل نرم‌افزار می‌داند، به ظرفیت شناختی محدود تیم‌ها احترام می‌گذارد، و همراه با قانون کانوی و طراحی پویا، به سازمان کمک میکند تشخیص دهد چه زمانی باید همکاری کند و چه زمانی باید روی اجرا و کاهش سربار ارتباطی تمرکز کند.
فصل دوم: قانون کانوی و اهمیت آن
قانون کانوی که در سال ۱۹۶۸ توسط ملوین کانوی مطرح شد، بیان میکند که سازمان‌هایی که سیستم طراحی می‌کنند، ناگزیر طراحی‌هایی می‌سازند که بازتاب ساختارهای ارتباطی خودشان است. اگرچه ممکن است تصور شود این قانون با ظهور فناوری‌هایی مانند میکروسرویس‌ها، ابر، کانتینرها و سرورلس دیگر کاربردی ندارد، اما تجربه نشان می‌دهد که هرچه سازمان بزرگتر باشد، ساختار تیم‌ها و نحوه ارتباط آنها همچنان عامل اصلی موفقیت یا شکست است. بسیاری از سازمان‌ها هنوز بر اساس پروژه‌های قدیمی یا فناوری‌های قدیمی سازماندهی شده‌اند.
در بسیاری از سازمان‌های بزرگ، یک پایگاه داده مشترک بزرگ، کل کسب‌وکار را پشتیبانی میکند. این وضعیت به دلایل تاریخی مانند تخصص‌گرایی تیم‌ها بر اساس لایه‌های فنی، پروژه‌محور بودن سازمان، برون‌سپاری و وجود تیم‌های کم‌تجربه به وجود آمده است. چنین پایگاه داده‌ای باعث می‌شود برنامه‌ها به هم وابسته شوند، تغییرات کوچک کسب‌وکار همه قسمت‌ها را تحت تأثیر قرار دهد، و جداسازی سیستم دشوار شود. برای جلوگیری از این وضعیت، تنها داشتن معماری خوب کافی نیست؛ ساختار تیم‌ها نیز باید با آن معماری هماهنگ باشد.
تحقیقات مختلف نشان می‌دهند که معماری محصول و ساختار سازمان به شدت به هم وابسته‌اند. هرچه هماهنگی این دو بیشتر باشد، کیفیت طراحی بهتر خواهد بود، و ناهماهنگی میان آنها باعث کاهش کیفیت و افزایش پیچیدگی می‌شود. برداشت رایج از قانون کانوی ناقص است. قانون صرفاً نمی‌گوید ساختار ارتباطات روی معماری اثر می‌گذارد، بلکه می‌گوید ساختار سازمان، محدوده راه‌حل‌هایی را که سازمان قادر به طراحی آن‌هاست محدود میکند و سازمان تنها می‌تواند معماری‌هایی را تولید کند که با ساختار ارتباطی خودش سازگار باشند. که به آن «فضای جستجوی راه‌حل» نیز گفته می‌شود.
اگر همه افراد مجبور باشند دائماً با همه افراد دیگر ارتباط برقرار کنند، ارتباطات انفجاری می‌شود، پیچیدگی افزایش می‌یابد، هماهنگی دشوار می‌شود و سرعت توسعه کاهش پیدا میکند. در مقابل، باید مسیرهای ارتباطی محدود، مشخص و هدفمند طراحی شوند. معماری باید امکان جریان سریع تغییرات در داخل هر تیم را فراهم کند و ویژگی‌هایی مانند وابستگی کم میان اجزا، انسجام زیاد مسئولیت‌ها، سازگاری نسخه‌ها و روش‌های مناسب تست میان تیم‌ها را داشته باشد. معماری باید بیش از آنکه مجموعه‌ای از اجزا باشد، بازتاب جریان تغییراتی باشد که تیم‌ها ایجاد می‌کنند.
«مانور معکوس کانوی» رویکردی است که در آن به جای اینکه ابتدا معماری طراحی شود و سپس تیم‌ها مجبور شوند از آن پیروی کنند، ابتدا تیم‌ها مطابق معماری مطلوب سازماندهی می‌شوند و سپس معماری نیز در همان جهت شکل میگیرد. نگاه به معماری به‌عنوان چیزی مستقل از ساختار تیم‌ها اشتباه است و اگر معماری و تیم‌ها با هم هماهنگ نباشند، یکی از آنها ناچار به تغییر خواهد شد. رواج میکروسرویس‌ها باعث شد توجه دوباره‌ای به قانون کانوی جلب شود، زیرا اگر معماری به سمت سرویس‌های مستقل حرکت کند اما ساختار تیم‌ها همچنان قدیمی باقی بماند، سازمان نمی‌تواند به مزایای واقعی میکروسرویس‌ها دست پیدا کند. هر بخش نرم‌افزار که آن‌قدر بزرگ باشد که از ظرفیت شناختی یک تیم فراتر برود، باید شکسته شود.
فصل سوم: اول تیم، بعد باقی چیزها!
واحد اصلی تحویل نرم‌افزار فرد نیست؛ تیم است. سیستم‌های نرم‌افزاری مدرن آن‌قدر پیچیده‌اند که دیگر یک فرد نمی‌تواند به‌تنهایی مسئول توسعه و نگهداری آنها باشد. تیم، کوچک‌ترین واحدی است که می‌تواند مسئولیت کامل طراحی، توسعه، استقرار و نگهداری یک بخش از سیستم را بر عهده بگیرد. بنابراین طراحی سازمان باید از نیازهای تیم شروع شود. تیم‌ها باید کوچک باشند، عمر طولانی داشته باشند، اعضای نسبتاً ثابتی داشته باشند و فرصت ایجاد اعتماد و شناخت متقابل پیدا کنند. جابجایی مداوم اعضا باعث از بین رفتن اعتماد، کم شدن بهره‌وری و نیاز به شکل‌گیری مجدد تیم می‌شود.
نظریه دانبار اعلام میکند انسان تنها می‌تواند با تعداد محدودی از افراد روابط مؤثر و پایدار برقرار کند و این محدودیت برای طراحی سازمان نیز اهمیت دارد. تیم‌های حدود هفت تا نه نفره برای توسعه نرم‌افزار مناسب هستند. اعتماد عامل اصلی عملکرد تیم است. هرچه اندازه تیم بزرگتر شود، ایجاد و حفظ اعتماد دشوارتر خواهد شد.
هر تیم باید مالک بخش مشخصی از نرم‌افزار باشد. مالکیت یعنی تیم مسئول توسعه، نگهداری، کیفیت، تغییرات و پاسخگویی همان بخش از سیستم باشد. وقتی مسئولیت بین چند تیم تقسیم شود، تصمیم‌گیری کند شده و کیفیت کاهش پیدا میکند. تیم‌های موفق فقط برای پروژه‌های کوتاه‌مدت تشکیل نمی‌شوند، آینده محصول را میبینند، مسئول نگهداری نرم افزار را بر عهده میگیرد تا بتواند تصمیم‌های بلندمدت بگیرد و از نتایج تصمیم‌های قبلی خود یاد بگیرد.
بار شناختی میزان تلاش ذهنی لازم برای انجام کار است و سه نوع دارد: بار ذاتی که ناشی از خود مسئله و ماهیت کار است، بار اضافی که ناشی از محیط، ابزارها، فرآیندها و پیچیدگی‌های غیرضروری است، و بار مفید که مربوط به یادگیری، درک بهتر مسئله و ایجاد مهارت است. بار ذاتی باید با آموزش، انتخاب فناوری مناسب، برنامه‌نویسی دونفره و افزایش مهارت کاهش یابد، بار اضافی باید تا حد امکان حذف شود، و ظرفیت ذهنی تیم برای بار مفید آزاد بماند. همان‌طور که هر فرد ظرفیت ذهنی محدودی دارد، هر تیم نیز ظرفیت شناختی محدودی دارد. اگر مسئولیت‌های زیادی به یک تیم داده شود، تمرکز کاهش می‌یابد، جابجایی مداوم بین موضوعات افزایش می‌یابد، تسلط اعضا بر حوزه کاری کمتر می‌شود و تیم به مجموعه‌ای از افراد مستقل تبدیل می‌شود.
برای جلوگیری از افزایش بار شناختی، هر تیم باید مسئول تعداد محدودی دامنه یا زیرسیستم باشد. یک تیم نباید هم‌زمان مسئول چند حوزه پیچیده یا کاملاً متفاوت باشد. اندازه زیرسیستم باید با ظرفیت شناختی همان تیم متناسب باشد. مرزهای تیم باید به گونه‌ای تعیین شوند که مسئولیت‌ها شفاف باشند، وابستگی بین تیم‌ها کاهش یابد، تیم بتواند مستقل تصمیم بگیرد و جریان تغییر سریع باقی بماند.
همان‌طور که نرم‌افزار API دارد، هر تیم نیز باید روش مشخصی برای تعامل با سایر تیم‌ها داشته باشد. این API تیم شامل مسئولیت‌های تیم، خدمات قابل ارائه، روش ارتباط، زمان پاسخگویی، نحوه دریافت درخواست، مستندات و ابزارهای ارتباطی است تا سایر تیم‌ها بدانند چگونه با آن تیم تعامل کنند. محیط کار نیز باید بر اساس نیاز تیم طراحی شود و صرف کنار هم نشستن افراد همکاری ایجاد نمی‌کند. طراحی فیزیکی یا مجازی محیط باید ارتباطات مؤثر داخل تیم را تسهیل کند. در تیم‌های توزیع‌شده نیز باید همان اصول رعایت شود و ابزارهای ارتباطی مناسب، کانال‌های مشخص، مستندسازی، قراردادهای ارتباطی و شفاف بودن تعاملات مورد تأکید است.
بخش دوم: توپولوژی‌های تیم که برای جریان کار می‌کنند
فصل چهارم: توپولوژی‌های ایستای تیم‌ها
صرف داشتن تیم‌ها کافی نیست؛ نحوه سازماندهی آنها مستقیماً بر سرعت جریان تغییر اثر می‌گذارد. طراحیای که دائماً در حال تغییر تیم‌هاست، سرعت تحویل نرم‌افزار را کاهش می‌دهد.
هیچ ساختار واحدی برای همه سازمان‌ها وجود ندارد، اما برای هر سازمان، ساختارهای نامناسب زیادی وجود دارد. انتخاب ساختار تیم باید متناسب با اندازه سازمان، بلوغ مهندسی، مقیاس نرم‌افزار و وابستگی‌های بین تیم‌ها باشد.
سازمانی که برای تخصص‌های جداگانه و واحدهای وظیفه‌ای طراحی شده است با سازمانی که برای جریان سریع تغییرات طراحی شده، تفاوت اساسی دارد. در ساختار اول، توسعه‌دهنده، عملیات، تست، امنیت، پایگاه داده و سایر تخصص‌ها در سیلوهای جدا قرار دارند و هر تغییر باید از چندین تیم عبور کند. در ساختار دوم، تیم‌ها مسئول جریان کامل تغییر هستند، تعداد تحویل‌ها افزایش می‌یابد، زمان انتظار کمتر می‌شود و تصمیم‌گیری سریع‌تر انجام می‌شود.
برخی از الگوهای DevOps تنها برای دوره انتقال مناسب‌اند و نباید دائمی شوند. اگر تیم DevOps بدون مأموریت و زمان پایان مشخص باقی بماند، به یک سیلوی جدید تبدیل می‌شود و دانش مربوط به استقرار، مانیتورینگ و مدیریت زیرساخت را در خود متمرکز میکند. در سازمان‌های بزرگ، وجود یک تیم مبلغ و راهبر DevOps برای ترویج فرهنگ و هم‌راستاسازی حرکت سازمان می‌تواند مفید باشد، اما نباید جایگزین مسئولیت تیم‌های محصول شود.
در الگوی SRE، مسئولیت قابلیت اطمینان سیستم به‌صورت مشترک میان تیم محصول و SRE مدیریت می‌شود. SRE به ایجاد قابلیت‌های عملیاتی، اتوماسیون و استانداردهای قابلیت اطمینان کمک میکند، اما تیم محصول همچنان مالک سرویس باقی می‌ماند. سه عامل اصلی در انتخاب توپولوژی عبارت‌اند از اندازه سازمان، مقیاس و پیچیدگی نرم‌افزار، و میزان بلوغ مهندسی. سازمان‌های کم‌بلوغ ممکن است در ابتدا ناچار به استفاده از تیم‌های تخصصی باشند، به شرط آنکه همکاری نزدیک داشته باشند. در سازمان‌های متوسط، همکاری نزدیک میان تیم‌ها برای رسیدن به جریان سریع تغییر مؤثر است. در سازمان‌های بزرگ، ارائه زیرساخت و قابلیت‌ها به‌صورت سرویس از طریق پلتفرم مزیت بیشتری ایجاد میکند.
گاهی وابستگی‌ها با افزودن افراد کمتر نمی‌شوند، بلکه باید مسئولیت‌ها بازتعریف شوند. برای مثال، جداسازی دو نقش Database Development و Database Administration در بسیاری از سازمان‌ها انجام شده است. توسعه پایگاه داده به تیم‌های مسئول محصول نزدیک‌تر می‌شود و وظایف DBA به‌تدریج به بخشی از پلتفرم داخلی یا خدمات ابری Database-as-a-Service تبدیل می‌شود. هدف، کاهش وابستگی‌های غیرضروری میان تیم‌هاست، نه صرفاً افزایش تعداد افراد.
برای داشتن تیم‌های مستقل و دارای مسئولیت روشن، باید وابستگی‌ها شناسایی، اندازه‌گیری و به‌صورت مداوم پایش شوند. وابستگی‌ها به سه دسته دانشی، وظیفه‌ای و منابعی تقسیم می‌شوند. تعداد وابستگی‌ها در هر بخش باید اندازه‌گیری شود و اگر از حد قابل‌قبول عبور کرد، طراحی تیم‌ها بازنگری شود. حذف کامل همه وابستگی‌ها امکان‌پذیر نیست، اما باید مشخص شود کدام وابستگی‌ها باید حذف شوند و کدام وابستگی‌ها ارزشمند هستند و آگاهانه پذیرفته شوند. هدف این است که تیم‌ها بیشترین استقلال ممکن را داشته باشند، بدون اینکه ارتباط‌های ضروری از بین برود.
فصل پنجم: چهار توپولوژی بنیادی تیم‌ها
چهار نوع بنیادی تیم وجود دارد که سازمان باید تیم‌های خود را بر اساس آنها شکل دهد تا جریان توسعه نرم‌افزار سریع، ایمن و پایدار باشد: تیم‌های هم‌راستا با جریان ارزش، تیم‌های توانمندساز، تیم‌های زیرسیستم پیچیده، و تیم‌های پلتفرم.
تیم هم‌راستا با جریان ارزش، تیمی است که با یک جریان ارزشمند از کار هم‌راستا است و توانایی ساخت و تحویل ارزش به مشتری یا کاربر را با سرعت، ایمنی و استقلال کامل دارد. این تیم، نوع اصلی تیم در سازمان است و هدف سایر توپولوژی‌های بنیادی، کاهش بار بر روی این تیم‌هاست. در یک سازمان مدرن نرم‌افزاری، اکثر تیم‌ها از این نوع هستند.
تیم توانمندساز، از متخصصان در یک حوزه فنی یا محصولی خاص تشکیل شده است و به پر کردن شکاف قابلیتی کمک میکند. چنین تیم‌هایی به‌صورت عرضی با تیم‌های هم‌راستا با جریان ارزش کار می‌کنند و پهنای باند لازم برای تحقیق، آزمایش گزینه‌ها و ارائه پیشنهادهای آگاهانه را دارند. این تیم‌ها ماهیتی به شدت مشارکتی دارند و برای درک مشکلات و کاستی‌های تیم‌های هم‌راستا، به‌منظور ارائه راهنمایی مؤثر، تلاش می‌کنند. هدف نهایی یک تیم توانمندساز، افزایش استقلال تیم‌های هم‌راستا با جریان ارزش از طریق افزایش قابلیت‌های آن‌هاست. اگر یک تیم توانمندساز کار خود را به خوبی انجام دهد، تیمی که به آن کمک میکند پس از چند هفته یا چند ماه دیگر نیازی به کمک نخواهد داشت.
تیم زیرسیستم پیچیده، مسئول ساخت و نگهداری بخشی از سیستم است که به شدت به دانش تخصصی وابسته است، به طوری که بیشتر اعضای تیم باید در آن حوزه دانش تخصصی داشته باشند. هدف این تیم، کاهش بار شناختی تیم‌های هم‌راستا با جریان ارزش است که روی سیستم‌های شامل یا استفاده‌کننده از زیرسیستم کار می‌کنند.
تیم پلتفرم، هدفش این است که تیم‌های هم‌راستا با جریان ارزش را قادر سازد تا با استقلال بالا کار کنند. تیم هم‌راستا با جریان ارزش، مالکیت کامل ساخت، اجرا و رفع مشکلات برنامه خود را در تولید حفظ میکند و تیم پلتفرم، خدمات داخلی را برای کاهش بار شناختی فراهم میکند. پلتفرم به عنوان مجموعه‌ای از APIهای خودخدمت، ابزارها، سرویس‌ها، دانش و پشتیبانی تعریف می‌شود که به عنوان یک محصول داخلی جذاب ارائه می‌شود.
در سازمان‌های بزرگ، یک پلتفرم به بیش از یک تیم برای ساخت و اجرا نیاز دارد. در این شرایط، یک پلتفرم از گروه‌هایی از انواع تیم‌های بنیادی دیگر تشکیل می‌شود: تیم‌های هم‌راستا با جریان ارزش، تیم‌های توانمندساز، تیم‌های زیرسیستم پیچیده، و پلتفرم‌های سطح پایین‌تر. این رویکرد، تیم‌های تو در تو یا فراکتالی را درون پلتفرم ایجاد میکند. از دیدگاه تیم‌های توسعه، پلتفرم یک موجودیت واحد است که به آنها سرویس می‌دهد، اما درون تیم پلتفرم، چندین تیم مجزا وجود دارند که خود با یکدیگر همکاری می‌کنند یا به تیم‌های پلتفرم دیگر سرویس می‌دهند. نسبت مطلوب تیم‌های هم‌راستا به سایر انواع تیم تقریباً بین شش به یک تا نه به یک است.
فصل ششم: انتخاب مرزهای تیم‌محور
جریان سریع تغییر زمانی سخت می‌شود که هر تیم به شبکه‌ای پیچیده از تعاملات با تیم‌های دیگر وابسته باشد. برای ایجاد جریان سریع تغییر در سیستم‌های نرم‌افزاری باید وابستگی‌ها و تحویل‌دادن کار بین تیم‌ها کاهش یابد و بیشتر تیم‌ها با جریان‌های اصلی تغییر در سازمان همسو شوند. بسیاری از سازمان‌ها مرز مسئولیت تیم‌ها را بدون توجه کافی تعیین می‌کنند و این موضوع باعث کاهش حس مالکیت، کاهش مشارکت و کند شدن شدید تحویل نرم‌افزار می‌شود. هدف این فصل، معرفی روش‌هایی برای یافتن مرزهای مناسب در سیستم‌های نرم‌افزاری است تا هر تیم بتواند بخش خود را به‌طور مؤثر و پایدار مالکیت و تکامل دهد. این مرزها باید در اندازه‌ای باشند که یک تیم بتواند مسئولیت کامل آنها را بر عهده بگیرد.
بسیاری از مشکلات توسعه نرم‌افزار ناشی از نامشخص بودن مرز مسئولیت تیم‌هاست. این مشکل معمولاً با معماری‌ای همراه است که وابستگی زیادی بین اجزای آن وجود دارد و در عمل به یک مونولیت تبدیل شده است. معماری‌های به‌شدت وابسته مانع تشکیل تیم‌های مستقل با مسئولیت‌های روشن می‌شوند. استفاده از Bounded Context و API به شکستن دامنه‌های بزرگ به واحدهای کوچک‌تر و کم‌وابستگی کمک میکند. هنگام تبدیل یک مونولیت به سرویس‌های مستقل، تنها تقسیم فنی سیستم کافی نیست؛ بلکه باید ظرفیت شناختی تیم‌ها، محل استقرار آنها و علاقه و توانایی آنها برای مالکیت سرویس‌های جدید نیز در نظر گرفته شود.
مونولیت برنامه که یک برنامه بزرگ با مسئولیت‌ها و وابستگی‌های فراوان است، مونولیت مبتنی بر پایگاه داده مشترک که چند برنامه یا سرویس از یک شِمای پایگاه داده مشترک استفاده می‌کنند، ساخت مونولیتی که کل کد منبع در هر بار Build به‌صورت یکجا ساخته می‌شود، انتشار مونولیتی که اجزای مختلف اگرچه مستقل ساخته می‌شوند اما برای آزمایش و استقرار به‌صورت یک بسته واحد منتشر می‌شوند، مدل مونولیتی که یک مدل دامنه و یک زبان مشترک به تمام بخش‌های سیستم تحمیل می‌شود، تفکر مونولیتی که همه تیم‌ها مجبور به استفاده از یک فناوری یا ابزار مشترک می‌شوند، و محیط کاری مونولیتی که از یک الگوی ثابت برای فضای کاری استفاده میکند.
بهترین حالت برای شکستن نرم‌افزار، هم‌راستا کردن مرزهای نرم‌افزار با حوزه‌های مختلف کسب‌وکار است، اما انواع دیگری از Fracture Plane نیز وجود دارد که در بسیاری از موارد باید ترکیبی از آنها استفاده شود: حوزه کسب‌وکار که بیشتر مرزهای سیستم باید بر اساس Bounded Context تعیین شوند، الزامات قانونی که در صنایع دارای قوانین سخت‌گیرانه، مقررات خود به‌عنوان مرز طبیعی عمل می‌کنند، سرعت تغییر که اگر بخش‌های مختلف سیستم با سرعت‌های متفاوت تغییر می‌کنند باید از یکدیگر جدا شوند، محل استقرار تیم‌ها که تیم‌های در مکان‌های جغرافیایی یا مناطق زمانی مختلف ارتباط کندتری دارند، ریسک که بخش‌های مختلف سیستم ممکن است سطح ریسک متفاوتی داشته باشند، جداسازی عملکرد که بخش‌هایی با بار پردازشی بسیار بالا می‌توانند به‌صورت مستقل جدا شوند، فناوری که در فناوری‌های قدیمی یا بسیار متفاوت ممکن است این نوع تقسیم‌بندی مفید باشد، و شخصیت کاربران که اگر گروه‌های مختلف کاربران از قابلیت‌های متفاوتی استفاده می‌کنند، تقسیم سیستم بر اساس این گروه‌ها می‌تواند مفید باشد.
بخش سوم: تکامل تعاملات تیم برای نوآوری و تحویل سریع
فصل هفتم: حالت‌های تعامل تیم‌ها
تنها تعیین نوع تیم‌ها برای دستیابی به تحویل سریع نرم‌افزار کافی نیست؛ بلکه باید مشخص شود تیم‌ها چگونه با یکدیگر تعامل داشته باشند و چه زمانی این تعاملات تغییر کنند. سازمان‌ها باید با تغییر نیازهای کسب‌وکار، فناوری، بازار و نیروی انسانی، الگوهای تعامل تیم‌ها را نیز تکامل دهند. در بسیاری از سازمان‌ها، تعاملات و مسئولیت‌ها به‌خوبی تعریف نشده‌اند. ممکن است تیمی مستقل معرفی شود اما برای انجام کار خود مجبور باشد دائماً با تیم‌های دیگر ارتباط برقرار کند که این موضوع باعث اصطکاک و کاهش اثربخشی می‌شود. در هر رابطه بین دو تیم باید مشخص شود که آیا باید با هم همکاری نزدیک داشته باشند یا یکی باید از خدمات تیم دیگر استفاده کند.
هدف این است که همه تیم‌ها مجبور نباشند دائماً با همه تیم‌های دیگر ارتباط برقرار کنند، بلکه ارتباطات سازمان به‌صورت هدفمند و کنترل‌شده باشد.
سه حالت اصلی تعامل بین تیم‌ها وجود دارد: همکاری، ارائه خدمات به‌عنوان سرویس، و تسهیل‌گری.
یک تیم ممکن است هم‌زمان با تیم‌های مختلف از حالت‌های متفاوت استفاده کند.
حالت همکاری زمانی مناسب است که نیاز به کشف فناوری جدید، نیاز به نوآوری، مسئله‌ای که نیازمند تخصص چند تیم باشد، یا لازم باشد دانش تیم‌های مختلف ترکیب شود. همکاری باعث کاهش تحویل‌های بین‌تیمی شده و سرعت کشف راه‌حل‌های جدید را افزایش می‌دهد. همکاری می‌تواند به دو شکل باشد: همپوشانی محدود که دو تیم همچنان مسئولیت اصلی خود را حفظ می‌کنند اما روی بخش مشخصی با هم همکاری می‌کنند، و همپوشانی کامل که دو تیم تقریباً مانند یک تیم واحد عمل می‌کنند و مسئولیت‌ها و تخصص‌ها را با هم ترکیب می‌کنند. در هر دو حالت مسئولیت نتایج باید مشترک باشد. هر تیم در یک زمان فقط باید با یک تیم دیگر در حالت همکاری باشد.
حالت X-as-a-Service زمانی استفاده می‌شود که یک تیم بتواند API، کتابخانه، کامپوننت، پلتفرم یا هر قابلیت دیگری را به شکل «سرویس» در اختیار سایر تیم‌ها قرار دهد. این حالت بیشتر در مراحل بلوغ سیستم و زمانی که تحویل قابل پیش‌بینی اهمیت دارد استفاده می‌شود. در این حالت، مالکیت‌ها کاملاً مشخص هستند، تعامل روزانه کمی لازم است، بار شناختی تیم‌ها کاهش پیدا میکند و تیم مصرف‌کننده می‌تواند روی کار اصلی خود تمرکز کند. اما نوآوری روی مرز سرویس نسبت به حالت همکاری کندتر خواهد بود. برای موفق بودن این مدل، مرز سرویس باید درست انتخاب شود، تیم ارائه‌دهنده باید مدیریت محصول مناسبی داشته باشد، نسخه‌بندی انجام شود، سازگاری نسخه‌ها حفظ شود، مستندات واضح و به‌روز باشند، و استفاده، تست، استقرار و اشکال‌زدایی سرویس ساده باشد.
حالت تسهیل‌گری زمانی است که یک تیم به تیم دیگر کمک میکند تا فناوری جدید یاد بگیرد، موانع را برطرف کند، سریع‌تر پیشرفت کند و مشکلات مشترک را شناسایی کند. این حالت، شیوه اصلی کار تیم‌های توانمندساز است. تیم تسهیل‌گر نرم‌افزار اصلی را توسعه نمی‌دهد، بلکه کیفیت تعامل تیم‌ها را بهبود می‌بخشد، مشکلات مشترک را کشف میکند و ضعف سرویس‌ها و پلتفرم‌ها را شناسایی میکند. هر تیم فقط با تعداد کمی از تیم‌ها به‌صورت هم‌زمان در حالت تسهیل‌گری تعامل دارد.
الگوهای تعامل می‌توانند مشکلات طراحی سیستم را آشکار کنند. اگر تیمی که باید فقط از یک سرویس استفاده کند مجبور باشد دائماً با تیم ارائه‌دهنده ارتباط برقرار کند، احتمالاً مرز سرویس، API یا قابلیت‌های تیم مناسب نیست. اگر همکاری مورد انتظار بین دو تیم شکل نگیرد، ممکن است ارزش همکاری درک نشده باشد، مهارت کافی وجود نداشته باشد، یا مرز بین تیم‌ها نامناسب انتخاب شده باشد.
فصل هشتم: تکامل ساختار تیم‌ها با استفاده از حسگری سازمانی
در سازمان‌های مدرن، مهم‌ترین موضوع صرفاً طراحی ساختار سازمان نیست، بلکه طراحی قواعد و معیارهایی است که سازمان بتواند با تغییر شرایط بازار، فناوری، مشتریان و مقررات، ساختار خود را به‌طور مستمر تغییر دهد. سازمان باید «قواعد طراحی» را طراحی کند، نه فقط خود ساختار سازمان را. هیچ‌یک از دو حالت همکاری و X-as-a-Service به خودی خود بهتر از دیگری نیست و هر کدام برای نوع خاصی از کار مناسب هستند. همکاری برای کشف سریع راه‌حل‌ها و نوآوری سریع مناسب است، اما هزینه آن افزایش بار شناختی است. X-as-a-Service مالکیت‌های کاملاً مشخص، بار شناختی کمتر و تحویل قابل پیش‌بینی‌تر دارد، اما سرعت نوآوری در آن کمتر است. سازمان‌های با عملکرد بالا معماری و تیم‌های خود را به گونه‌ای طراحی می‌کنند که تیم‌ها برای انجام کار روزانه نیاز به ارتباط زیاد با یکدیگر نداشته باشند.
همکاری هزینه‌بر است و نباید دائمی باشد. همکاری فقط زمانی توجیه دارد که برای یکی از اهداف کشف، ایجاد قابلیت جدید، یا رفع کمبودهای موجود انجام شود. سازمان باید برای هر رابطه بین دو تیم تصمیم بگیرد که آیا فقط استفاده از سرویس کافی است یا لازم است برای مدتی همکاری کنند تا API مناسب طراحی شود. تغییر آگاهانه تعامل دو تیم به حالت همکاری می‌تواند یادگیری فناوری‌ها و روش‌های جدید را سرعت دهد. اگر یک تیم تجربه زیادی در زمینه‌ای داشته باشد، همکاری چندماهه با تیمی که این تجربه را ندارد باعث می‌شود API بین دو تیم بهتر تعریف شود، توانایی تیم دوم افزایش یابد و روش‌های کاری جدید منتقل شود.
تعامل بین تیم‌ها باید با تغییر نیازها تغییر کند. اگر تیمی نیاز به کشف فناوری یا بخشی از دامنه داشته باشد که در اختیار تیم دیگری است، باید برای مدت مشخصی وارد حالت همکاری شود. پس از پایان مرحله کشف و افزایش نیاز به تحویل قابل پیش‌بینی، تعامل باید به حالت X-as-a-Service تغییر کند. در مرحله همکاری مرزهای مسئولیت و معماری تا حدی با هم ترکیب می‌شوند، اما هنگام انتقال به X-as-a-Service باید APIها شفاف و مرزها مشخص شوند.
الگوی تکامل به این صورت است: همکاری نزدیک، همکاری محدودتر، و سپس X-as-a-Service. در سازمان‌های بزرگ این چرخه به‌طور هم‌زمان در بخش‌های مختلف رخ می‌دهد؛ برخی تیم‌ها در مرحله کشف هستند و برخی دیگر از سرویس‌های تثبیت‌شده استفاده می‌کنند.
پنج محرک اصلی برای تغییر توپولوژی تیم‌ها وجود دارد. اول، نرم‌افزار برای یک تیم بیش از حد بزرگ شده است. با بزرگ شدن سیستم، تخصص افراد روی بخش‌های مختلف افزایش می‌یابد و برنامه‌ریزی کار بر اساس "چه کسی این بخش را می‌شناسد؟" انجام می‌شود، نه بر اساس اولویت کار. این موضوع گلوگاه ایجاد کرده و جریان کار را کاهش می‌دهد. دوم، سرعت تحویل کاهش یافته است. علت می‌تواند ایجاد وابستگی‌های سخت بین تیم‌ها، ایجاد سیلوهای عملکردی مانند تیم QA مستقل، یا افزایش بدهی فنی باشد که انجام حتی تغییرات کوچک را دشوار میکند. سوم، چندین سرویس کسب‌وکار به مجموعه بزرگی از سرویس‌های زیرساختی وابسته هستند.
تیم‌ها و ارتباطات میان آنها نقش اندام‌های حسی سازمان را دارند. وقتی مسیرهای ارتباطی پایدار و مشخص باشند، سازمان می‌تواند تغییرات محیط داخلی و خارجی را تشخیص دهد. در مقابل، سازمان‌هایی که تیم‌های ناپایدار، مسئولیت‌های مبهم و وابستگی زیاد به افراد کلیدی دارند، توانایی حس کردن محیط را از دست می‌دهند.
بهتر است یک تیم مسئول هم توسعه قابلیت‌های جدید و هم نگهداری سیستم‌های قدیمی باشد. این کار باعث می‌شود تله‌متری سیستم‌های جدید به سیستم‌های قدیمی منتقل شود، کیفیت حسگری سازمان افزایش یابد، تیم از رفتار کاربران و سیستم‌های مختلف یاد بگیرد و اشتباهات گذشته تکرار نشود.
نتیجه‌گیری: مدل عملیاتی دیجیتال نسل بعد
بسیاری از مشکلات رایج تحویل نرم‌افزار، با وجود ظهور فناوری‌های جدید، همچنان باقی مانده‌اند: مشارکت پایین تیم‌ها، غافلگیر شدن های مداوم در برابر تغییرات فناوری و بازار، نادیده گرفتن یا مقابله با قانون کانوی، بزرگ شدن بیش از حد نرم‌افزار برای یک تیم، وجود مدل‌ها و چارچوب‌های متعدد و گیج‌کننده برای سازماندهی، کشیده شدن تیم‌ها به جهت‌های مختلف، بازسازمان‌دهی‌های سخت و مکرر، و جریان ضعیف تغییر. علت اصلی این مشکلات، برداشت نادرست بسیاری از سازمان‌ها از ماهیت توسعه نرم‌افزار است. تمرکز بیش از حد بر "تحویل قابلیت‌ها" باعث نادیده گرفتن عوامل انسانی، پویایی تیم‌ها و محدودیت بار شناختی می‌شود و در نتیجه مشارکت افراد کاهش می‌یابد. همچنین بسیاری از سازمان‌ها پیامدهای واقعی قانون کانوی را نادیده می‌گیرند؛ در نتیجه یا معماری به‌صورت اتفاقی شکل میگیرد یا اصطکاک دائمی بین ساختار سازمان و معماری ایجاد می‌شود.
رویکرد کتابTeam Topologies با ارائه یک رویکرد «تیم‌محور» این مشکلات را برطرف میکند. این رویکرد بر سه اصل استوار است: چهار نوع اصلی تیم، سه الگوی اصلی تعامل بین تیم‌ها، و استفاده از مشکلات تحویل نرم‌افزار به‌عنوان سیگنال‌هایی برای درک وضعیت سازمان. این مدل باعث می‌شود نحوه تعامل تیم‌ها شفاف شود، معماری نرم‌افزار پایدارتر و روشن‌تر باشد، و مشکلات بین تیم‌ها به نشانه‌هایی برای هدایت و اصلاح سازمان تبدیل شوند.
ساخت و نگهداری یک سیستم نرم‌افزاری تنها با چهار نوع تیم قابل انجام است و وجود انواع دیگر تیم‌ها ممکن است حتی برای سازمان مضر باشد. تیم هم‌راستا با جریان ارزش، تیمی است که با جریان اصلی تغییرات کسب‌وکار همسو است، مهارت‌های میان‌وظیفه‌ای دارد و بدون وابستگی به تیم دیگر می‌تواند تغییرات مهم را تحویل دهد. تیم پلتفرم، پلتفرم موردنیاز تیم‌های هم‌راستا را توسعه می‌دهد، فناوری‌های پیچیده را ساده میکند و بار شناختی سایر تیم‌ها را کاهش می‌دهد. تیم توانمندساز به سایر تیم‌ها در یادگیری، پذیرش فناوری جدید و انجام تغییرات کمک میکند. تیم زیرسیستم پیچیده، مسئول زیرسیستم‌هایی است که پیچیدگی آنها بیش از توان یک تیم هم‌راستا یا پلتفرم است و این نوع تیم اختیاری است و فقط زمانی ایجاد می‌شود که واقعاً ضرورت داشته باشد.
سه حالت اصلی تعامل نیز عبارت‌اند از: همکاری که دو تیم برای رسیدن به هدفی مشترک با یکدیگر همکاری نزدیک می‌کنند، X-as-a-Service که یک تیم از محصول، API، ابزار یا سرویس تیم دیگر استفاده میکند، و تسهیل‌گری که یک تیم به تیم دیگر کمک میکند تا روش یا فناوری جدیدی را یاد بگیرد یا به کار گیرد. تعاملاتی خارج از این سه حالت معمولاً نشانه انتخاب نادرست مرز مسئولیت تیم‌ها یا درک نادرست از هدف آن‌هاست.
برای روشن شدن هدف و مرز مسئولیت هر تیم، باید نوع تیم و نوع تعامل آن مشخص شود. اما Team Topologies یک گام فراتر می‌رود و خود تیم را واحد اصلی تحویل نرم‌افزار می‌داند. در این دیدگاه، تیم فقط مجموعه‌ای از افراد با یک مدیر مشترک نیست، بلکه موجودیتی مستقل با یادگیری، مأموریت، اهداف و استقلال معقول است که به‌صورت جمعی یاد میگیرد و نرم‌افزار را تحویل می‌دهد. API تیم فقط کد نیست، بلکه شامل مستندات، فرآیند ورود اعضای جدید، شیوه تعامل با سایر تیم‌ها، ارتباطات حضوری، ابزارهای گفت‌وگو و هر چیزی است که تیم‌های دیگر برای همکاری با آن تیم نیاز دارند.
برای جلوگیری از بزرگ شدن بیش از حد سیستم، اندازه هر زیرسیستم باید در حدی باشد که یک تیم بتواند آن را مدیریت کند. هدف این است که بار شناختی از ظرفیت تیم بیشتر نشود و همه اعضای تیم بتوانند پیچیدگی سیستم را درک کنند. این رویکرد نسبت به معماری‌های مونولیت یا میکروسرویس‌ها انسانی‌تر و پایدارتر است، زیرا به‌جای فناوری، بر انسان تمرکز دارد. ساختار تیم‌ها نباید ثابت بماند. در دوره‌های کشف فناوری یا محصول، همکاری زیاد لازم است، اما پس از تثبیت فناوری، باید همکاری کاهش پیدا کند و قابلیت‌ها وارد پلتفرم شوند.
موفقیت علاوه بر ساختار تیم‌ها به عوامل زیر وابسته است: فرهنگ سالم سازمان، مهندسی مناسب، شیوه مناسب تأمین مالی، و شفافیت چشم‌انداز کسب‌وکار. فرهنگ سالم سازمان یعنی محیطی که در آن افراد احساس امنیت کنند، درباره مشکلات صحبت کنند و یادگیری مستمر وجود داشته باشد.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
