PI-планування в SAFe

Scaled Agile Framework, SAFe — фреймворк Agile-розробки, розроблений Scaled Agile Inc., по суті база знань по реалізації бережливої Agile-розробки в корпоративних масштабах. Нижче вільний переказ оригінальної статті «PI Planning — Scaled Agile Framework»: http://www.scaledagileframework.com/pi-planning.


Сесія PI-планування на 190 учасників

Зміст
Завдання по розробці продукту неможливо заздалегідь передбачити. Передайте планування і відстеження тим, хто може оцінити кінцевий результат і впливати на те, яким він буде.
— Michael Kennedy, «Product Development for the Lean Enterprise»
SAFe немає ніякого чарівництва… хіба що тільки PI-планування.
— Автори SAFe
Один з принципів Agile-маніфесту (http://agilemanifesto.org/iso/ru/principles.html) каже, що «безпосереднє спілкування є найбільш практичним та ефективним способом обміну інформацією як з самою командою, так і всередині команди». Це нескладно здійснити, якщо у вас одна невелика команда. А як бути в масштабах величезної компанії, коли багато команд і необхідна їх синхронна робота? Для цього в Scaled Agile Framework (SAFe) використовується інструмент PI-планування (PI Planning) — це практика прямого спілкування всіх команд, представників бізнесу та інших зацікавлених осіб, які об'єднуються в одну велику команду — Agile Release Train (ART).

Спілкування проходить на регулярних зустрічах зі стандартною порядком денним: на початку презентація представників бізнесу з розповіддю про поточної ситуації, стратегії та завдання, потім сесія планування, коли команди створюють план реалізації инкремента продукту, створюваного в рамках програми — Program Increment (PI). Відразу обмовимося: в термінології SAFe для позначення великої кількості взаємопов'язаних між собою команд використовується термін «програма», надалі ми будемо його дотримуватися. У цій сесії беруть участь всі члени ART, наскільки це можливо. Для фасилітації таких зустрічей виділена спеціальна роль — Release Train Engineer (RTE). Він же відповідає за ескалацію блокерів, допомагає в управлінні ризиками, постачання цінності і безперервному вдосконаленні.

Для подібних заходів з планування, досліджень і навчання передбачена спеціальна IP-ітерація (Innovation and Planning iteration), щоб не займати час команд на інших ітераціях всередині PI. Сесія триває від 1,5 до 2 днів. Результатом є узгоджений набір цілей програми на наступний PI.

Географічно розподілені ART проводять цю зустріч одночасно в різних місцях, але підтримують між собою постійний зв'язок.

Огляд
PI-планування важливо проводити регулярно, адже воно задає ритм роботи всього ART. Це невід'ємна частина SAFe: якщо ви не проводите PI-планування, ви не застосовуєте SAFe.


Сесія PI-планування на 250 учасників

PI-планування надає бізнесу безліч переваг:

  • ART налагоджується ділове спілкування, адже багато хто з тих, кому потрібно робити спільні проекти, вперше знайомляться наживо.
  • Забезпечується висока ефективність комунікації між усіма членами команд і зацікавленими особами. Простіше кажучи, якщо зібрати багато людей і дати їм мету, то це призводить до надзвичайної енергетики спілкування. Перевірено на нашому досвіді! (прим. перекладача)
  • Бізнес-замовники і розробники нарешті чують один одного і починають діяти злагоджено у відповідності з цілями бізнесу.
  • Команди починають бачити картинку в цілому", виявляються залежності, що підштовхує команди до координації між собою та іншими ART.
  • Команди вибирають лише необхідний мінімум вимог до архітектури і інтерфейсу. Це дозволить вкластися в заплановані строки і «не навертати» надлишковий функціонал.
  • Обсяг робіт планується з урахуванням ємності команд, за рахунок чого усувається надлишок незавершеної роботи.
  • Форсується прийняття рішень.
До сесії готуються наступні матеріали: дорожня карта, концепція, топ-10 пріоритетних фіч з бэклога програми та інші артефакти для передачі бізнес-контексту.

Основними результатами PI-планування є:

  1. Набір SMART-цілей команд на PI, які кожна команда визначає самостійно. Кожна мета оцінена з точки зору значущості для бізнесу. Цілі всіх команд об'єднано в набір цілей всієї програми на PI.
  2. Дошка програми, на якій показані нові фічі, очікувані терміни їх реалізації та будь-які інші віхи, з якими пов'язані цілі команд.
  3. Загальна згода з реалістичністю і готовність взяти на себе відповідальність за досягнення цих цілей.
Підготовка
PI-планування — важлива подія, що вимагає підготовки, координації та комунікації. Учасники заходу: продуктові менеджери, Agile-команди, архітектори та інженери, системні команди, зацікавлені особи — усі вони повинні бути заздалегідь повідомлені і прийти на захід добре підготовленими.

Успішний захід готується за наступними напрямками:

  • Організація: узгодженість бізнесу та розробки стратегії, готовність команд і всього ART.
  • Зміст: підготовленість менеджменту і розробників.
  • Інфраструктура: місце проведення та логістика заходи.
Нижче наводиться опис підготовки по кожному напрямку.

Організація
Важливо переконатися, що у програми є стратегія, яка буде зрозуміла учасникам заходу, включаючи зацікавлених осіб і представників від бізнесу, що робота команд відповідає цій стратегії, що в ART є люди на всіх ключових ролях.

Нижче приклади питань, які допомагають визначити цю готовність.

  • Обсяг роботи і контекст планування: “чи Зрозумілі рамки планування: продукту, системи, технологічної області? Чи знаємо ми, які команди потрібні для спільного планування?"
  • Узгодженість бізнесу: «Узгоджені пріоритети між представниками від бізнесу?»
  • Agile-команди: “чи Є у нас Agile-команди? Всі команди укомплектовані розробниками і тестерами? Скрізь визначені Скрам-майстер і власник продукту?"
Зміст
Не менш важливо правильно донести концепцію і бізнес-контекст, тому на сесії повинні бути всі необхідні зацікавлені особи. Для цього PI-планування включає наступні активності:

  • Огляд поточного бізнес-контексту від топ-менеджменту.
  • Огляд продуктової концепції, який готують продуктові менеджери на основі топ-10 пріоритетних фіч з бэклога програми.
  • Огляд архітектурної концепції зазвичай представляє технічний директор або архітектор, щоб розповісти про технологічні новинки для підтримки реалізації фіч, а також про нефункціональних вимог.
Інфраструктура
Підготувати місце проведення та технічну інфраструктуру заходи з великою кількістю учасників не так просто, особливо якщо є віддалені учасники.

Нижче наведені моменти, які слід врахувати.

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


Стандартна порядок 2-денної сесії PI-планування

1 День

Бізнес-контекст

Топ-менеджер або власник бізнесу описує поточний стан бізнесу і те, наскільки добре поточні рішення в перспективі будуть задовольняти потреби клієнтів.

Концепція продукту

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

Архітектура і практики розробки

Системний архітектор представляє архітектурну концепцію. Крім того, старший менеджер розробки може розповісти про зміни в практиках Agile-розробки, наприклад, автоматизації тестування і безперервної інтеграції, які потрібно враховувати в протягом наступного PI.

Контекст планування

Ведучий — RTE — пояснює процес планування та очікувані результати від заходу.


Ведучий пояснює цілі та план сесії PI-планування на 100 осіб

Робота команд — 1

Команди для кожної ітерації оцінюють обсяг робіт, які вони зможуть виконати (ємність) і визначають елементи бэклога, які, швидше за все, необхідні для реалізації функцій. Кожна команда створює чернетки планів, які видно всім іншим учасникам, ітерацію за ітерацією. В цей час вони виявляють ризики і залежності, що визначають чернетка цілей команди на PI. Також команда додає фічі на дошку програми.


Команди виявляють взаємозалежності на сесії PI-планування на 100 осіб

Рецензування чернеток планів

Рецензування планів відбувається з суворими обмеженнями щодо часу виступу кожної команди. У цей час команди представляють основні результати планування: чернетка цілей, потенційні ризики і залежності. Представники від бізнесу, продуктові менеджери, інші команди і зацікавлені особи задають питання і дають зворотний зв'язок.


Власник продукту презентує зібраний її командою плану на сесії PI-планування на 100 осіб

Рецензування керівництвом і вирішення проблем

Ймовірно, плани необхідно буде доопрацювати з урахуванням очікуваного обсягу робіт, обмеженості ресурсів і виявлених залежностей. Під час цієї зустрічі керівництво погоджує обсяг робіт та усуває недоліки в планах. RTE веде зустріч за участю всіх ключових зацікавлених осіб до тих пір, поки ними не будуть визначені досяжні цілі.

День 2

Зміна планів

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

Робота команд — 2

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


Результати планування однієї з команд на сесії PI-планування на 100 осіб

Презентація підсумкових планів

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

Ризики програми

Під час планування команди виявляють критичні ризики та блокери на рівні всієї програми, які можуть вплинути на можливість вирішення командами своїх завдань. Ці питання розглядаються усіма учасниками. Всі ризики, один за одним, чітко, чесно і відкрито класифікуються за такими групами:

  • Resolved — команда погодилася, що проблема більше не актуальна;
  • Owned — питання не може бути вирішене на заході, але хтось погодився просувати вирішення цього питання далі;
  • Accepted — деякі ризики є фактами або потенційними подіями, які повинні бути зрозумілі всіма і враховані в подальшій роботі;
  • Mitigated — команда може визначити план щодо усунення наслідків цього ризику або блокера.



Ризики програми на сесії PI-планування на 100 осіб

Голосування

Після того, як були розглянуті ризики програми, команди голосують за реалістичність і готовність взяти на себе відповідальність за досягнення цих цілей програми на PI. Всі члени команд піднімають руку, показуючи від одного до п'яти пальців.


Правила голосування на сесії PI-планування на 100 осіб

Якщо по всім командам в середньому підняті три або чотири пальці, то керівництво може прийняти такі зобов'язання. Якщо ж в середньому менше трьох пальців, то в план вносяться необхідні зміни і всі плани переробляються. Кожен, хто піднімає два або менше пальців, повинен висловити свої побоювання. Це дозволяє або ідентифікувати новий ризик, потребує перепланування, або просто донести до всіх важливу інформацію.


Голосування на репетиції з участю Скрам-майстрів та власників продуктів команд перед сесією PI-планування на 100 осіб

Переробка планів, якщо потрібно

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

Ретроспектива

На завершення RTE проводить коротку ретроспективну сесію, щоб визначити, що вийшло добре, що не дуже і що можна зробити краще на наступній сесії PI-планування.

Після цього можна обговорити подальші кроки, занести цілі і користувальницькі в історії IT-інструменти управління Agile-проектами, запланувати майбутні ключові активності та заходи… і навіть прибрати в приміщенні!

Результати
Успішне PI-планування дозволяє отримати три основних артефакту.

  1. Набір SMART-цілей команд на PI, які кожна команда визначає самостійно. По кожній цілі представниками від бізнесу визначена оцінка її бізнес-цінності.
  2. Дошка програми, на якій видно терміни поставки нових фіч, залежності між командами і залежності від інших ART, а також важливі віхи.


    Дошка програми одного ART

  3. Згоду всіх команд ART з реалістичністю цілей PI і їх готовність взяти на себе відповідальність за досягнення цих цілей.


Практика
У цьому відео наша практика PI-планування:


Якщо вам цікаві матеріали по трансформації процесів у великих компаніях, рекомендуємо групу Enterprise Agile Russia в Facebook. Будемо обговорювати кращі практики масштабування, такі як NEXUS, SAFe, LeSS.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.