ایجاد هماهنگی بین چند تیم
با افزایش تعداد اعضای تیم‌های توسعه ابعاد استفاده از اسکرام افزایش نمی‌یابد بلکه باید تعداد تیم‌هایی که اندازه مناسبی دارند افزایش یابد. داشتن بیش از یک تیم چالش هماهنگی ایجاد میکند که دو رویکرد برا آن داریم «اسکرام اسکرام‌ها» و «قطار انتشار»

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

-تیم‌ من از آخرین جلسه قبلی چه کاری انجام داده است که ممکن است تیم‌های دیگر را تحت تاثیر قرار دهد؟
-تیم‌ من تا جلسه بعدی چه کاری انجام می‌دهد که احتمالا تیم‌های دیگر را تحت تاثیر قرار می‌دهد؟
-تیم‌ من چه مشکلاتی دارد و برای حل آنها ممکن است به کمک تیم‌های دیگر نیاز داشته باشد؟

جلسات آن ۱۵ دقیقه است و بحث در خصوص مسایل را بعد از ان انجام می‌دهند تا افراد علاقمند و مورد نیاز حضور داشته باشند. اگر گروه‌های مختلف در اسکرام اسکرام را خوشه بندی کنیم.

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

-تاریخ‌های برنامه ریزی و تاریخ انتشارهای متناوب و دوره‌ای راهکار تعیین شده باشند
-مدت تکرار در تیم‌ها یکسان است
-مایلستونهای میانی و کلی با هدفی تعیین شده باشند
-یکپارچه سازی علاوه در سطح ویژگی و مولفه، در سطح کلان یا سیستم نیز انجام شود
-بخش‌های قابل انتشار که به آن PSI گفته میشود در فواصل زمانی ۳ یا ۴ ماه جهت نمایش برای مشتری، تضمین کیفیت در سطح سیستم و بازنگری داخلی آماده باشند
-از تکرار تثبیت جهت کاهش بدهی فنی و اختصاص زمان برای ازمون و اعتبارسنجی خاصی در انتشار استفاده شود
-جهت کار تیم‌ها در بستری یکسان مولفه‌های زیرساختی مشخصی همچو رابط‌ها، بسته‌های توسعه سیستم، ابزارهای نصب و محوزدهی، تحربه کاربر و خدمات پایه اینترنتی در دستور کار قرار گیرند

قطار انتشار شامل سبد محصول و سطوح انتشار می‌شود که دارای سه سطح است: بک لاگ سبد محصول(اپیک‌هایی که مالکیت آن با مدیریت آن است)، بک لاگ برنامه(ویژگی‌هایی که مالکیت آن با مدیرت آن است)، بک لاک تیم(داستان‌های کاربر قابل انجام در یک اسپرینت که با ماک محصول است)می‌باشد تصویر اول در کامنت
۹ تیم در قالب ۳ خوشه که با اسکرام اسکرام‌ها پیش می‌روند.در هر زمان ممکن باید ازمون و یکپارچه سازی سیستم به نحوی انجام شود که همه ویژگی‌های ویژگی را در بر بگیرد. مدت اسپرینت برای تمام تیم‌ها یکسان است که موجب ایجاد هماهنگی در تمامی تیم‌ها میشود. هر PSI (هر انتشار بعد از تعداد معینی اسپرینت که معمولا ۴ اسپرینت است) آماده می‌شود. این زمان بندی به سازمان کمک می‌کند هماهنگی اتی خود را انجام دهد که در زمان تعیین شده انتشار میتواند:

-تصمیم گیری بر اساس منافع کسب و کار جهت استقرار PSI
-فرصت برای تایید صحت یکپارچگی و آزمون کارهای گروه‌های مختلف
-درخواست بازنگری داخلی

را داشته باشد

هر قطار انتشار با برگزاری جلسه برنامه ریزی انتشار آغاز می‌شود که همه تیم‌هایی که روی PSI کار می‌کنند در ان حاضرند.

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

#scrum

@code_crafters