Ответ
Program Increment (PI) — это фиксированный временной интервал (обычно 8-12 недель), в течение которого Agile Release Train (ART) в SAFe разрабатывает, тестирует и поставляет значимый инкремент ценности. Это основа для планирования и выполнения работы на уровне нескольких команд.
Ключевые элементы PI:
- PI Planning: Центральное событие (обычно 2 дня), где все команды ART совместно планируют работу на следующий инкремент, синхронизируют зависимости и формулируют PI Objectives.
- PI Objectives: Измеримые бизнес- и технические цели, согласованные между командами и заинтересованными сторонами.
- Артефакты: Программный бэклог, дорожная карта, доска зависимостей.
Пример PI Objectives:
• (Команда Frontend) Увеличить производительность рендеринга главной страницы на 25%.
• (Команда Backend) Интегрировать новый платежный шлюз X.
• (Общая) Реализовать сквозной сценарий «Оформление заказа».Цикл PI:
Планирование PI → Выполнение (несколько итераций/спринтов) → Системная демонстрация → Инспекция и адаптация (Retrospective).
Зачем это нужно? PI обеспечивает выравнивание, синхронизацию и предсказуемость для больших групп команд, работающих над общей целью, сохраняя при этом гибкость Agile в рамках инкремента.
Ответ 18+ 🔞
А, слушай, вот эта ваша PI, Program Increment, блядь! Ну, это ж просто, как три копейки, ёпта!
Представь себе: куча команд, все такие Agile, гибкие, все в своих спринтах скачут, как мартышлюшки. А бизнес-то орет: «Ну и хули вы там делаете, когда уже что-то целое будет, а?». Вот для этого и придумали PI — такой здоровенный, блядь, временной промежуток, обычно недель на 8-12, за который вся эта артель под названием ART (Agile Release Train, по-нашему — «поезд», который, сука, с рельс не сходит) должен выдать что-то осязаемое. Не просто коммит в мастер, а именно инкремент ценности, чтоб его потрогать можно было.
Из чего же, из чего же этот PI сделан?
- PI Planning — это пиздец, а не событие. Два дня, все команды, куча стикеров, пицца, кофе. Все орут, синхронизируют свои зависимости, чтобы потом не вышло, что фронтенд сделал кнопку, а бэкенд на неё, блядь, API не завез. Главный итог — PI Objectives, то есть цели на этот самый инкремент. Без них — нихуя не понятно, что делали.
- Сами эти PI Objectives. Это не просто «поработать хорошо». Это конкретика, которую потом можно проверить. Типа: «Сделать так, чтобы страница грузилась не за 4 секунды, а за 3, блядь».
- Артефакты всякие. Бэклог программы, доска зависимостей (чтобы видеть, кто от кого ебётся), дорожная карта. Всё это, сука, нужно, чтобы не скатиться в хаос.
Вот, смотри, как это выглядит на практике, чтоб не быть голословным:
• (Команда Frontend) Увеличить производительность рендеринга главной страницы на 25%.
• (Команда Backend) Интегрировать новый платежный шлюз X.
• (Общая) Реализовать сквозной сценарий «Оформление заказа».Видишь? Всё понятно. Не «пофиксить баги», а именно вот это. И общая цель есть, которая всех объединяет.
А живёт PI по такому циклу, блядь:
Сначала все сходятся на Планировании и орут два дня. Потом наступает Выполнение — несколько итераций, где все пашут. В конце — Системная демонстрация, где показывают, что получилось. И завершает всё Инспекция и адаптация — большая ретроспектива, где все дружно рефлексируют: «Ну что, опиздохуели, или как?».
И зачем весь этот цирк? Да затем, ёпта! Чтобы 10 команд, как слепые котята, не бегали в разные стороны, а были выровнены под одну цель, синхронизированы между собой и давали хоть какую-то предсказуемость бизнесу. Гибкость Agile остаётся внутри, но снаружи — уже не полный пиздец и анархия, а некое подобие порядка. Ну, или его иллюзия, что тоже неплохо.