Напомним, что SAFe – это фреймворк, который позволяет реализовывать agile-методологии в крупных командах разработки.
Будучи гибким фреймворком, SAFe следует agile-манифесту, один из принципов которого гласит: «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды».
Несложно следовать этому принципу, если разработку и
тестирование продукта ведет команда из десяти человек. А как быть, когда команд много и необходимо синхронизировать их работу?
Для этого в SAFe используется инструмент PI-планирование — это практика прямого общения команд, представителей бизнеса и других заинтересованных лиц, которые объединяются в одну команду.
Почему PI? Во время планирования команды создают план реализации инкремента продукта, Program Increment.
Что такое PI-планирование?
На уровне программ создается бэклог функциональных и архитектурных фич. Бэклог – основа планирования, которое длится несколько дней.
Результатом планирования должна стать доска программы (Program Board), на которой указано, какая команда, над какой юзер-стори и в каком спринте будет работать.
Там же указываются взаимосвязи между юзер-стори, чтобы все участники понимали и учитывали риски. Команды в SAFe берут на себя ответственность за реализацию не конкретных фич команды, а фич всего инкремента в целом. То есть если PI провален, то он провален для всех команд.
Длится каждый инкремент два с половиной месяца, или пять спринтов.
Сам процесс планирования в SAFe очень интересный и чем-то напоминает тимбилдинг. Конечно же, он значительно отличается от планирования спринта в Scrum. Расскажем о наиболее ярких отличиях, с которыми столкнулась наша QA-команда.
Организационные отличия safe от scrum
Длительность
Раньше Scrum планирование спринта длилось не более четырех часов в каждой из команд, сейчас планирование растянулось на неполных четыре дня.
Участники
В Scrum планирование спринтов осуществлялось независимо от других команд, в SAFe же в планировании принимает участие сразу вся проектная команда, включая разработчиков, тестировщиков, бизнес-аналитиков, UX-специалистов. Если кто-то не может присутствовать лично, он должен быть доступен для вопросов.
Этапы
При планировании Scrum этапов спринта большая часть времени отводится под оценивание трудозатрат, которые уйдут на разработку или тестирование стори.
PI-планирование включает в себя больше этапов, чем просто оценивание.
Вот расписание PI-планирования, которое проходило у нас. На его примере и расскажем об основных этапах мероприятия.
Начинается планирование с того, что руководство компании доносит
бизнес-контекст предстоящего PI всей команде (Business Context).
Затем менеджер по продукту рассказывает, как будет реализовываться бизнес-контекст через функциональность (Product / Solution Vision).
Архитектор рассказывает, как будет развиваться наше приложение технически (Architecture Vision & Development Practices).
После этого владелец продукта (Product Owner) каждой команды в общих чертах презентует свой кусок требований, чтобы все команды имели представление, кто и какие фичи будет разрабатывать (Planning Requirements High Level Feature Overview). Так заканчивается первый день планирования.
В течение второго дня каждая из команд работает над своим планом на предстоящий PI, а на третий день Scrum-мастера представляют планы своих команд, которые все вместе образуют Program Board.
Далее команды должны подтвердить готовность подписаться под этим планом, т. е. считают его выполнимым. Это процедура называется Confidence Vote. Проголосовать должен каждый участник, оценив план по шкале от 1 до 5.
План считается принятым только в том случае, если все члены команды выставили ему 3 и выше. В противном случае, команды расходятся на перепланирование.
Отличия в коммуникации
- В SAFe существует понятие Scrum of Scrums — это митинг Scrum-мастеров команд. Такие митинги проходят каждый час, пока команды оценивают свои стори. Задача SoS-митингов – синхронизироваться по статусу и обсудить зависимости между командами.
- Поскольку команды у нас распределенные, то большая часть обсуждений ведется на английском языке.
- Новый уровень визуализации. Если при работе по Scrum нам вполне хватало Jira, то в SAFe проблема визуализации общего плана стала остро. Ведь члены команды находятся на разных континентах, и возможности зайти в соседний кабинет и что-то обсудить лично нет. Мы пробовали разные подходы, но остановились на online-сервисе RealTimeBoard – виртуальные доски, на которых можно совместно работать с любым визуальным контентом.
Отличия в методах оценивания
- Методы оценки также отличаются от методов, принятых в Scrum. Оцениваем мы не в часах, а в стори-поинтах. Это относительная оценка, которая показывает, насколько одна стори больше и сложнее другой.
- На обдумывание оценки дается всего 2-3 минуты. Нужно это для того, чтобы команды не погружались в длинную дискуссию о деталях разработки, на данном этапе нужна всего лишь высокоуровневая оценка.
- Если стори оценена больше чем на 8 поинтов, то ее следует разбить на несколько более мелких стори, т.к. команда скорее всего не успеет полностью завершить ее за один спринт, а это противоречит основным правилам SAFe. Ведь к концу спринта мы должны прийти с законченным ПО.
- Самое интересное: теперь мы оцениваем не только свою работу, но и работу своих коллег. Каждый член команды должен оценить и разработку и тестирование и дать общую оценку. Это сложно, но дает лучшее понимание. Мы реже стали слышать вопрос: «Ну что там столько тестировать-то?»
Преимущества PI-планирования
Главные преимущества планирования в SAFe – прозрачность процесса и сплочение команды. Лишний повод пообщаться с коллегами, которые находятся в разных зданиях или на разных континентах, всегда сказывается положительно.
Кроме того, мы стали лучше понимать, зачем мы все это делаем, и какую пользу проекту приносит то, что мы разрабатываем. Будущее стало более определенным. Теперь мы знаем планы всех команд на несколько спринтов вперед.
Ну и, конечно, планирование стало хорошей возможностью попрактиковать свой английский. Ну чем не бонус?
