PI Planning — планування для великих команд: як його провести і як це відбувається на практиці

На етапі організації процесу розробки проєктів чи програм ми часто звертаємося до гнучких (Agile) методологій, наприклад Scrum. У тому числі й для планування обсягу робіт і умов розробки та постачання. Але Scrum-практики та артефакти ефективно працюють для однієї-двох команд загальною чисельністю до 20 осіб. А що робити, якщо потрібно організувати планування програми, до якої залучено сотні людей?

Півтора роки тому ми стикнулися з такою ситуацією на одному з наших екаунтів - Ahold Delhaize. Команда за цей період зросла від 40 до 130 осіб. Таким чином виникла необхідність впровадження інструментів масштабування в процес планування програми. Я розповім про PI Planning. Не тільки теоретично, але й про власний досвід кількох планувальних сесій з нашим клієнтом. Оскільки цей досвід реальний, в ньому є і плюси, і мінуси. Спробую пояснити, як використовувати цей інструмент із максимальною користю.

Program Increment (PI) Planning Meeting - це практика планування, яка прийшла зі Scaled Agile Framework (SAFe). SAFe - спеціально розробленого гнучкого фреймворку для великих організацій. Набір інструментів, які надає SAFe, допомагає вибудувати Agile-процеси і ефективну комунікацію між бізнесом і командами розробки програмного забезпечення в масштабі 100-1000 осіб.

Варто окремо сказати кілька слів про нашого клієнта. Ahold Delhaize - один з найбільших представників grocery retail у світі. Проєкт з розвитку онлайн-гілки їхнього бізнесу розпочався в нас у 2015 році. Протягом року на проєкті в нашому харківському офісі було задіяно до 20 осіб. Згодом клієнт вирішив інтенсифікувати вихід нового функціоналу. Ми почали масштабуватися: спочатку 2 команди, після - 4, потім - 6. А коли зрозуміли, що команд буде 9, як зараз, знадобилися інструменти для підтримки такого масштабу.

Ми дійшли до того, що будемо впроваджувати окремі практики SAFe, зокрема щоквартальне PI планування. SAFe - звичайно, не єдиний спосіб. Крім нього масштабування для Agile організацій надають: Scrum Of Scrums, Nexus, LeSS. Але наш замовник, який добре знає власну діджитал-організацію, вирішив, що саме SAFe підійде найкраще. Тобто до вибору PI Planning ми прийшли еволюційним шляхом.

Якщо коротко, сам PI Planning Meeting відбувається протягом двох днів, які повністю розписані. На початку озвучуються спільні цілі від бізнесу. Потім люди розходяться по командах, вивчають, що саме потрібно зробити конкретно кожній команді. Через деякий час знову збираються разом, діляться тим, що змогли запланувати, які залежності та ризики виявили. Знову розходяться по командах і обговорюють: можливо, щось потрібно посунути через залежності від інших команд.

На нашому проєкті Program Increment включає в себе шість двотижневих спринтів. Тому, наприклад, одна команда каже: «Вам потрібен даний функціонал? Але ми зможемо зробити його тільки в п'ятому спринті цього Program Increment ». Інша каже: «Нам потрібна ваша фіча, щоб доробити нашу. А нашу теж потрібно віддати в п'ятому спринті. Давайте ви заплануєте закінчити вашу в третьому, і тоді ми зможемо віддати нашу в п'ятому».

Якщо зовсім спросити, то саме для таких нагальних питань-відповідей і організовується загальне планування протягом двох днів.

Загалом для Program Increment Planning необхідно зібрати оффлайн усіх людей, які беруть участь в розробці проєкту. Команда переглядає плани і цілі на квартал від бізнесу, пропонує рішення, і планує, коли ці рішення будуть передані клієнту.

Головна перевага, заради якої усе організовується, це участь усієї команди. Тобто кожного розробника, починаючи від Junior, закінчуючи Technical Leads, Solution Architects, Program Managers. Відповідно, всі проблеми і залежності можна досить якісно виявити і відразу їх запланувати. Або озвучити їх як ризики і почати працювати над управлінням та зменшенням їхнього впливу.

Так зростає прозорість процесу. Це вже не менеджери, які сказали, що потрібно зробити щось до певної дати, і тиснуть на команди розробки згори. Команда сама, зсередини, каже: «Цю частину роботи ми можемо зробити до цієї дати». Сама аналізує проблеми, можливі ризики і механізми роботи з ними. Думає, як зробити, щоб залежностей від інших команд було менше. Після усіх цих процесів команда відчуває себе більш відповідальною за кінцевий результат і доставку цього результату вчасно.

Також під час залучення великих команд (в нашому кейсі разом з бізнесом та іншими відділами на стороні клієнта це ± 200 осіб) завжди є кілька ключових архітекторів, які дуже перенавантажені. На зустріч з ними заради обговорення одного-двох питань деколи доводиться чекати тижнями. E-mail комунікація теж не завжди ефективна, тому що кількість повідомлень у цих людей надмірна. Поки вони зможуть відповісти, проходить ще пара тижнів. Сесії PI Planning вирішують і цю задачу.

Перша і найголовніша проблема - для PI Planning потрібна дуже якісна підготовка з боку бізнесу. Бізнес-представники заздалегідь повинні визначитися, чого саме хочуть і в якому пріоритеті. Формулювання «Я хочу нову сторінку з супер-UX для покупців» - не підходить. Потрібна конкретика - як і навіщо буде використовуватися ця новинка? Бажано заздалегідь мати аналіз і дизайн.

В іншому випадку планування перетворюється на дуже складну вправу для всієї команди. Без вхідних даних вона відчуває незадоволення через те, що не може правильно спланувати процеси. В такому випадку PI краще не організовувати.

Інший недолік - зворотна сторона переваги. У цій вправі бере участь велика кількість людей. Понад 6-7 команд, а зазвичай це більше 100 чоловік - вже важко. Потрібні оптимізації. Доведено, що PI Planning добре працює до 100 осіб. Більше 100 - вже мистецтво. Ми стикалися з ситуаціями, коли нам потрібно було організувати PI для 160 осіб.

Все починається з підготовки. Як я зазначила вище, спочатку все починається на боці бізнесу: опрацьовуються вимоги та пріоритети. Потім складається графік власне заходу. Є лідер цілого Program Increment - зазвичай це Agile-коуч. Залежно від масштабу заходу, їх може бути один чи двоє. У нашому випадку спочатку був один, а минулого разу - двоє.

Приклад стандартного розкладу рекомендований самим SAFe. Ми у зустрічах з Ahold Delhaize йдемо за схожим, адаптуючи його під завдання заходу.

На початку є інтро, де бізнес ставить цілі на наступний інкремент (квартал). Бажано в форматі «Хочемо запровадити ось цю фічу, щоб завоювати новий сегмент ринку або збільшити доходи на $ 2-3 млн».

Рівнем нижче у кожній команді є Product Owners, які ретельно опрацьовують побажання бізнесу. Вони придумують, як переформатувати їх на реальні рішення того функціоналу, який ми надаємо клієнту. Разом з командами вони формують детальніші вимоги і рішення. Перш, ніж це буде заплановано та обговорено докладно, вони презентують докладну розбивку. Зазвичай це триває протягом 2-3 годин першого дня.

Після цього команди розходяться. У кожній з них є власний Scrum Master як фасилітатор обговорень всередині команди разом з Product Owner, який транслює побажання бізнесу. Scrum Master фасилітує і разом з усією командою (5-6 розробників, тестувальники, а також, в залежності від завдань, дизайнери та архітектори) обговорює обсяг робіт та побажання самої команди. Обговорення триває близько 2 годин. Вони виділяють основні ризики, залежності від інших команд і / або вендорів.

Потім ключові особи з кожної команди збираються разом і розміщують ці ризики та проблеми на єдиному великому борді. Він може бути двох типів. Ми використовуємо паперовий - кілька склеєних аркушів А1 з таблицею, що саме кожна команда має принести і до якої дати. Кожна команда на стікерах пише свої основні фічі, ризики, проблеми, питання і клеїть їх на цю паперову дошку. Потім стрічками позначає залежності один від одного. Зараз ми розглядаємо Діджитал опції - існують програми, які дозволяють робити те саме з виводом на стіну через проектор.

Приклад робочого паперового борду (ілюстрація)

Так відбуваються 2-3 ітерації: команди разом, команди окремо, ключові особи працюють з бордом. Наприкінці команди знову розходяться та завершують планування. Після цього ключові особи фіналізують залежності та питання.

Зазвичай основні ітерації закінчуються в перший день. На другий день залишається фіналізація. У разі, якщо виявлено якісь великі ризики і виникли питання, першу половину другого дня команди ще раз опрацьовують їх окремо, а приблизно до полудня приносять остаточні плани.

Після цього починається фіналізація загального плану і вирівнювання з бізнесом. Представники бізнесу обов'язково повинні бути присутніми на цих зустрічах, під час яких тривають дискусії та консультації. Наприклад, ми говоримо представникам замовника: «Ми бачили ваш план з п'яти пунктів. Він був ось такий, і згідно з ним потрібно встигнути ось це. Але ми розуміємо, що це нереально. Будь ласка, підтвердіть, що три з цих п'яти пунктів - найбільш пріоритетні. Ми їх зробимо, якщо ви з цим згодні. Якщо не ок, давайте приберемо ось це, але поставимо ось це». Приблизно в такому форматі проходять обговорення другого дня.

Завершується усе, зазвичай, голосуванням від команд - confidence vote. Наскільки вони впевнені, що зможуть, як команда, надати обіцяний скоуп до кінця наступного кварталу. І бажано, щоб confidence vote був досить високий. У нас він від одного до п'яти – ми просто голосуємо пальцями однієї руки.

Приклад підрахунку «пальців» під час голосування

Бажано, щоб від усієї команди confidence vote був близько чотирьох. Тоді ми впевнені, що гаразд. Якщо ж він менше, значить, цій команді потрібна ще одна ітерація - на роздуми, обговорення ризиків і проблем. Ймовірно, десь є неповне розуміння. Тому на цьому плануванні важлива особиста присутність архітекторів. Вони допоможуть прояснити усі питання на місці. Це важлива точка PI Planning як заходу: всі ключові люди, які можуть відповісти на питання, як з боку бізнесу, так і з боку архітекторів, знаходяться в одній кімнаті і можуть миттєво відповідати на різні питання, непорозуміння, проблеми і т. д.

Після confidence vote проводиться ретроспектива. Вона може бути двох типів.

Перший варіант - попередній квартал. Чи виконали ми усе, що обіцяли? Якщо ні, то в форматі ретроспективи розбираємося чому.

Другий варіант - ретроспектива самого Program Increment. Як пройшли ці 2 дні? Наскільки вони ефективні? Що варто поліпшити наступного разу? Чого не треба робити наступного разу? До речі, останнє запитання ми включили до недавнього чергового PI Planning з Delhaize. І фідбек був дуже цінним.

Приблизно так проходять ці 2 дні.

Вище я згадувала, що в PI Planning беруть участь усі задіяні на проекті особи. В реальності можна спробувати оптимізувати склад учасників. В цілому це мають бути:

• Представники бізнесу, які уповноважені приймати рішення на місці;
• архітектори;
• технічні ліди;
• Scrum-мастери;
• аналітики;
• ключові розробники;
• Subject Matter Experts;
• Program або Project Managers (якщо тривають розробки різних рівнів програм).

В цілому Agile-коуч або Release Train Engineer фокусується на тому, щоб ціла програма була доставлена. А якщо якісь частини програми важливо зробити до певної дати, це відстежують Program Managers. Це суттєво, коли є інтеграція з іншими системами або існує залежність від зовнішньої системи за межами основної. Тоді необхідно погоджувати терміни з кількома сторонами. І чим більше сторін, тим складніше це все відбувається.

Повною мірою цінність заходу можна виміряти тільки на наступному PI Planning. Скажу просто: якщо ми роз'їжджаємося, і обсяг робіт, і пріоритети не змінюються, і ми доставляємо основну частину робіт згідно з домовленостями під час PI - це успіх. Якщо роз'їжджаємося, і пріоритети раптом змінюються або з якихось інших причин ми не можемо доставити обумовлений обсяг робіт - треба думати над поліпшенням планування і його форматом. Тоді збираємося ретроспективою і думаємо, як це змінити в майбутньому.

У нас був досвід невдалих сесій. Всі збиралися, проводили дорогий та складний захід, планували. Потім все роз'їжджалися, ми сідали на робочі місця, стартували - і за тиждень з тих чи інших причин пріоритети змінювалися. Тобто зусилля були практично марними або використовувалося максимум 30-50% з того, що ми обговорювали. По суті, треба було заново робити планування. Звичайно, через два тижні повторних зборів не робили. Тому ми проводили перепланування більш «кустарним» способом і стикалися з тими самими питаннями, чекали письмових відповідей від менеджерів і тільки тоді рухалися далі. Але з кожною наступною сесією ця складність зникала.

Тому ключовий фактор успішного проведення PI Planning - це якісна підготовка з боку замовника щодо пріоритетів і побажань. Важливо, щоб і після зустрічі вони залишилися незмінними. Бізнес повинен розуміти, чого саме він хоче як мінімум у наступному кварталі.

Результати сесії модеруються та контролюються як з боку менеджменту клієнта, так і з нашого боку.

Ще кілька пунктів для того, щоб все пройшло ефективно:

• Найголовніше – це підготовка. План розкладу повинен опрацьовуватися досвідченими людьми. Бажано драйверами з сертифікацією SAFe, з розумінням бізнес-цілей, з усвідомленням, що саме і навіщо ми робимо.
• Agile-коучі – головують проведенням сесій.
• Правильні інструменти фасилітації мітингів - щоб люди вчасно зупинялися. Не має бути так, що одну задачу обговорюють протягом години, а на решту двадцять залишається по 1 хвилині. Для цього бажано впроваджувати певні часові обмеження на кожне питання / завдання, щоб люди були максимально сконцентровані. Звичайні інструменти фасилітації мітингу дуже важливі, тому роль Scrum-майстра - вчасно їх пропонувати і застосовувати. На рівні загальних сесій це задача Agile-коучів.

Місце проведення PI Planning для розподілених команд обирається з урахуванням кількох факторів: зручність робочого майданчика, розміщення гостей і, зрозуміло, вартість. Наприклад, в нашому випадку з Ahold Delhaize кілька PI сесій ми проводили у Харкові. Тут у нас велика частина команди, але ще є люди з Києва та Гродно. Представники клієнта - в Брюсселі і Афінах. З’ясувалося, що наше місто чудово підходить для таких заходів з точку зору логістики та проживання у готелях. До того ж, нам вдалося провести PI Planning просто в офісі.

Велика частина закулісної роботи з організації заходу лягає на guest relations та event-менеджера. Проектом підготовки до дводенної сесії займається Project Administrator, який відповідає за весь процес. Перший раз був викликом, підготовка до нього тривала майже 2 місяці. Кожен наступний раз потребує менших зусиль - можна сказати, що ми «відкатали» процес. Сьогодні ніхто навіть не дивується, коли ми говоримо про організацію візиту клієнтів на 40 осіб і заходів на 180 учасників.

Певною мірою PI Planning одночасно перетворюється і на квартальний тімбілдинг. Для багатьох, навіть з боку клієнта, це була перша особиста зустріч - адже вони теж працюють в різних локаціях. У нас планування закінчувалося великим заходом для всієї команди, на якому люди могли більше неформально поспілкуватися один з одним, познайомитися ближче.

Так, ми переконані, що будь-яка серйозна робота повинна закінчуватися фаном. Це корисно як для внутрішньої комунікації, так і для емоційного входження команди в новий період. Як то кажуть, «work hard play hard».