ویژگی‌های کار تیم Agile در SAFe نسبت به Scrum در عمل

پس از انتشار مقاله اول درباره Burn Down Chartدر میان دوستان، در نظرات اولین سؤالی که پرسیده شد این بود: «جالب است که بیشتر درباره تجربه‌تان با SAFe بدانیم». بنابراین، در این مقاله سعی می‌کنم ویژگی‌های کار در SAFe نسبت به Scrum را در عمل ما روشن کنم. من قطعاً ادعای حقیقت مطلق را ندارم و از هر اصلاح و توضیحی از سوی همکاران خوشحال خواهم شد.

ابتدا به صورت نکته‌ای مهم‌ترین چیزهایی را که به نظر من کار در SAFe را از SCRUM متمایز می‌کند، فهرست می‌کنم.

• Increment در Scrum و Program Increment در SAFe
• ART - Agile Release Train
• تعداد تیم‌های در تعامل
• PIPE
• SOS
• PO - مالک کسب‌وکار نیست
• RTE
• اسپرینت پنجم برای آموزش
• System Demo

Increment در Scrum و Program Increment در SAFe. در واقع اصطلاحات متفاوتی هستند، اما به راحتی می‌توان در آن‌ها گیج شد چون هیچ‌کس در ما اصطلاح Program Increment را استفاده نمی‌کند، همه فقط Increment می‌گویند - که این اصطلاح دیگری است که در SCRUM استفاده می‌شود. اما به طور کلی از نظر معنا، به نظر من کاملاً شبیه هم هستند. Increment در SCRUM در واقع محصول فعلی + داستان‌های برنامه‌ریزی‌شده برای اسپرینت در حالت انجام‌شده است (که DOD تیم را گذرانده‌اند). Program Increment بازه زمانی است که طی آن قطار (Agile Release Train) ارزش افزایشی را به تولید می‌رساند. از نظر مدت، در ما این ۴ اسپرینت دو هفته‌ای برای توسعه و یک اسپرینت برای آموزش است.

Agile Release Train - تیمی از تیم‌هاست که روی یک جریان ایجاد ارزش کار می‌کنند. ما این را فقط قطار می‌نامیم، اما طبق چارچوب درست این است که «Solution» نامیده شود. در مورد ما، این قاعده کاملاً رعایت نمی‌شود و تیم‌ها اغلب از نظر فنی روی محصولات مختلف کار می‌کنند، چون بیشتر ویژگی‌های کسب‌وکار به صورت комплексی پیاده‌سازی می‌شوند و چند محصول را درگیر می‌کنند. این از جنبه فنی است. اما مطمئنم که کسی همه سیستم‌های IT را یک محصول شرکت می‌داند و شاید حتی این درست‌تر باشد.

تعداد تیم‌های در تعامل در SAFe ما به طور قابل توجهی بیشتر است، در مجموع تا ۱۲۵ نفر در یک قطار توصیه می‌شود. ما ۳ قطار داریم و این قاعده در هر کدام رعایت نمی‌شود، قطارهایی با بیش از ۱۲۵ نفر وجود دارند. SCRUM توصیف نمی‌کند که چگونه با تیم‌های دیگر تعامل کنیم، تا آنجا که می‌دانم، برخلاف SAFe که توصیه‌های بسیار واضحی در این باره دارد. به نظر من بارزترین آرتیفکت برای این کار Program Board است.

روی آن روابط بین تیم‌های قطار نمایش داده می‌شود و با بحث درباره آن، رویداد هفتگی Scrum Of Scrums (SOS) در ما برگزار می‌شود.

تقریباً هر ۲.۵ ماه (هر ۵ اسپرینت) رویداد PIPE - Programm Increment Planning Eventرخ می‌دهد. این زمانی است که همه تیم‌های توزیع‌شده به مدت ۲ روز در یک سالن جمع می‌شوند و کارهای خود را برای ۲.۵ ماه آینده برنامه‌ریزی می‌کنند. در جریان این رویداد آرتیفکت‌هایی مانند Program board پدید می‌آیند، مثلاً روی آن همه وابستگی‌های تیم‌ها به یکدیگر برای هر یک از قطارها نمایش داده می‌شود، قبلاً نشان دادم که چگونه به نظر می‌رسد. وظیفه Scrum Master هر تیم در این رویداد تسهیل شناسایی حداکثر تعداد وابستگی‌ها و سپس در صورت امکان حذف آن‌هاست (مثلاً با انتقال شفاهی مهارت‌ها از تیمی به تیم دیگر یا با برداشتن وابستگی از یک تیم به تیم دیگر تا تیم بتواند به صورت مستقل ویژگی خود را بدون وابستگی به کسی پیاده‌سازی کند). در عمل در ما این‌گونه اتفاق می‌افتد. ابتدا ویژگی‌ها به User Story تجزیه می‌شوند، User Storyها بین ۴ اسپرینت تقسیم می‌شوند. ویژگی‌ها روی Program Board قرار می‌گیرند و وابستگی‌های موجود به تیم‌های دیگر مشخص می‌شوند. در طول رویداد این موضوع بحث و اصلاح می‌شود.

SOS - Scrum Of Scrum. این رویداد هفته‌ای یک بار برای هر قطار به طور جداگانه برگزار می‌شود. Scrum Masterهای همه تیم‌های قطار به صورت آنلاین جمع می‌شوند، Program Board قطار پخش می‌شود و وضعیت همه وابستگی‌ها و ویژگی‌های تیم‌های آن قطار بحث می‌شود. در واقع این رویداد برای همگام‌سازی متمرکز تیم‌ها درون قطار لازم است. چیزی شبیه استندآپ، اما هفته‌ای یک بار و نه برای تیم، بلکه برای Scrum Masterها.

PO (مالک محصول) - مالک کسب‌وکار نیست. یک Product Manager وجود دارد - او با Business Ownerهای حوزه‌های مربوطه کسب‌وکار کار می‌کند و در واقع ویژگی‌ها را به مالکان محصول می‌دهد. مالک محصول مستقیماً در تیم کار می‌کند - ویژگی‌ها را به User Storyها می‌شکند (در مورد ما همراه با تیم) و همیشه نمی‌شکند، اما ما دائماً در این جهت پیشرفت می‌کنیم.

RTE (Release Train Engineer - машинист поезда. Скрам Мастер Скрам Мастеров. Проводит мероприятия SOS своего поезда. Взаимодействует с Product Manager'ом на уровне фич. Фасилитирует PIPE.

Пятый спринт для обучения - да, в отличие от Scrum, здесь выделен команде целый спринт в конце инремента на обучение. Мы, как правило, на практике используем его в первую очередь для посещения тренингов внутренних в том числе и по SAFe, но не только. Частные курсы и митапы стараемся планировать на это время по возможности. Также у нас есть разработчики, которые расширяют свой стек в течение 5 спринта, чтобы была возможность закрыть чью-либо компетенцию в команде (подстраховать при необходимости).

System Demo. В результате PIPE у каждой команды есть список целей на инкремент и каждая из этих целей оценена Buisseness Owner'ом поезда по 10-бальной шкале. Это называется Business Value. Цели эти делятся на основные и расширенные. Основные цели - это цели, в которых команда не видит никаких рисков в достижении. Расширенные - это цели с рисками достижения. Все цели обязательные и объем работ планируется под все цели. На System Demo Business Owner принимает результаты работы за инкремент. Допустим, у команды было 3 основных цели с оценками 10, 6, 8 и 2 расширенные с оценками 10, 3. Представим, что Business Owner поставил соответственно оценки следующие: 8, 6, 4, 2, 0. Теперь можно посчитать процент достижения целей: за 100% берется изначальная сумма балов за основные цели, в нашем случае это 10+6+8=24. Достигнутые баллы считаются с учетом расширенных целей(т.е. 20 из 24 команда достигла), т.е. в результате процент достижения целей у команды будет (20*100)/24 = 83,3%. Нормальным результатом считается достижение от 80% до 100%.

Во всем остальном мы работаем по SCRUM. Ну или почти во всем :) Что касается нашего опыта: могу сказать, что, с моей точки зрения, эволюция очевидна. За год работы команды сильно выросли, стали самоорганизующимися, какие-то команды, правда, развалились, но и в этом просматривается определенная эволюция. Расти тоже еще есть куда.

Комментарии коллег из facebook

«Женя, привет! Круто, что пишешь, молодец! Чуть поправлю про поезда - собираются они не вокруг продукта, а вокруг потока создания ценности. А в рознице у нас с точки зрения SAFe не поезд, а Solution. Просто для удобства коммуникации и упрощения понимания, мы продолжаем называть это поездом)»

– Константин Воронин (представитель проектного офиса Ингосстраха)

«Ну и может кто-нибудь заметит, что с точки зрения SAFe оценка целей проходит на I&A; (куда SD входит как часть, но напрямую с оценкой не связан) а сами SD должны проходить каждый спринт (после демо команд). Но мы пока от этого далеки, поэтому осознанно называем все как написано у тебя в статье)»

– Константин Воронин (представитель проектного офиса Ингосстраха)

«Женя, продолжай, пожалуйста, очень полезно!»

– Алексей Ионов (Сертифицированный тренер по SAFe)