PI Planning — планування для великих команд: як його провести і що виходить на практиці - SEO Blog - все про пошукову оптимізацію та веб розробку українською.

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

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

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

Аж до 1000 осіб

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 включає в себе 6 двотижневих спринтів. Тому, наприклад, одна команда каже: «Вам потрібен ось цей функціонал? Але ми зможемо зробити його тільки в п'ятому спринті цього Program Increment». Інша каже: «Щоб нам завершити нашу фічу, потрібна ваша. А нашу теж потрібно віддати в п'ятому спринті. Давайте ви запланували закінчити вашу в третьому, і тоді ми зможемо віддати нашу в п'ятому».

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

Головна мета PI Planning

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

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

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

Також у разі великих команд (в нашому кейсі разом з бізнесом та іншими відділами на стороні клієнта ± 200 чоловік) завжди є кілька ключових архітекторів, які дуже перевантажені. Щоб з ними поспілкуватися, зустрічі заради одного-двох питань деколи доводиться чекати тижнями. E-mail комунікація теж не завжди ефективна, тому що кількість 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-коучі на чолі проведення сесій.
Правильні інструменти фасилітації мітингів — щоб люди вчасно зупинялися. Не повинно бути такого, що одна задача обговорювалася годину, а решта 20 — по 1 хвилині. Для цього бажано впроваджувати певні обмеження по часу на кожне питання/завдання, щоб люди були максимально сконцентровані. Звичайні інструменти фасилітації мітингу дуже важливі, тому роль Scrum-майстра — вчасно їх пропонувати і застосовувати. На рівні загальних сесій це завдання Agile-коучів.

Квартальний тімбілдінг

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

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

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

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

Опубліковано: 16/01/19 @ 08:00
Розділ Різне

SEO Блог