Как мы масштабировали agile в тестировании: обзор Scaled Agile Framework

17 марта 2017
Дата публикации
Как мы масштабировали agile в тестировании: обзор Scaled Agile Framework
  • Тестирование ПО
  • Обеспечение качества

Предлагаем поговорить про гибкие методологии. Но речь пойдет не про Scrum, с которым многие знакомы не понаслышке, а про SAFe–методологию, которая позволяет делать гибким процесс разработки ПО в очень больших командах.

Начнем с предыстории. У нас есть заказчик, качество продуктов которого мы обеспечиваем уже более четырех лет. Работа над его решениями строилась по Scrum’у Framework до тех пор, пока однажды он не поставил нас перед фактом: с завтрашнего дня переходим на SAFe Framework. Данный фреймворк можно отнести к редко используемым, и мы решили не упускать возможности детально его изучить.

Внедрение SAFe происходило методом проб и ошибок, но в итоге процесс был настроен, оптимизирован и уже более полутора лет успешно работает.

Мы решили поделиться интересным опытом и надеемся, что наши советы будут полезны и предупредят сложности, которые могут возникнуть у вашей команды.

В этой и еще четырех статьях мы дадим базовое представление о SAFe, расскажем о том, какие уровни он включает. Кроме этого, поделимся своим опытом внедрения фреймворка и перечислим главные отличия от обычного Scrum’а. Итак, начнем.

Что такое SAFE?

На запрос «Что такое SAFe?» в Google мы получили вот такую диаграмму:

Рисунок1.webp

Методология Scaled Agile Framework (SAFe) — это набор правил и предписаний для внедрения agile-принципов в больших организациях. Одной из причин популярности данного фреймворка сегодня – это неудачный опыт использования agile-принципов на крупных предприятиях, которые, с одной стороны, стремятся соответствовать принципам agile, а, с другой стороны, хотят добиться предсказуемости сроков выпуска продукта. Всем им необходим проверенный подход, который можно было бы «развернуть» среди многочисленных команд разработки.

Когда стоит внедрять SAFE?
Наличие следующих предпосылок говорит о том, что на предприятии можно подумать о внедрении SAFe:
  1.     Множество разрабатываемых продуктов (так называемый портфель проектов).
  2.     Множество проектных ролей.
  3.     Сложная процедура внедрения какого-нибудь предложения или изменения (требуются десятки согласований).
  4.     Большое количество команд разработки и желание работать по Scrum.
Допустим, нам нужно увязать между собой разработку и релиз более чем 15 программных решений, каждое из которых имеет более десятка stakeholder’ов. Решения разрабатываются 10 командами из 5 стран. Такого уровня задачу решить с помощью традиционного Scrum’а невозможно.

Какое решение предлагает SAFE?

Scaled Agile Framework (SAFe) разбивает любое предприятие на три уровня:
  •          уровень портфолио;
  •          уровень программ;
  •          уровень команд.
Давайте разберемся на примере простого вымышленного проекта, что собой представляет каждый из уровней.

Допустим, нам нужно доработать веб-приложение для книжного магазина. Основные функции текущей версии просты: на сайте через поиск можно найти книгу и оставить предзаказ. Когда заказ готов, менеджер связывается с покупателем, и тот самостоятельно забирает его со склада. Очевидно, что функциональность описанной версии веб-сайта весьма ограничена. Чтобы добавить конкурентных преимуществ, нужно придумать дополнительную функциональность на сайт.

Работа начинается на уровне портфолио. Здесь центральным является понятие «бизнес-эпика», которое отражает наиболее приоритетные направления развития продукта в ближайшее время. Эпики бывают функциональные и архитектурные.

Для нашего веб-сайта примерами функциональных эпиков будут следующие: «Организовать доставку по стране с возможностью отслеживания обработки заказа в личном кабинете» и «Создать онлайн-площадку для общения любителей книг». Примерами архитектурных эпиков могут быть «Интеграция с геоинформационными системами» и «Перенос системы в облако».

Рисунок2.webp

SAFe: пока все просто, спускаемся ниже

На уровне программ эпики разбиваются на фичи, т.е. куски функциональности, реализующие данный эпик. Фича – это ограниченный, чаще всего крупный кусок функциональности, который приносит определенную пользу бизнесу или позволяет конечному пользователю решать какую-либо задачу.

Давайте возьмем один из эпиков и детализируем его до уровня команд. Например, функциональный эпик про создание площадки для общения онлайн. На уровне программ он будет представлен фичами «Управление профилем пользователя», «Форум» и «Личные сообщения».

Рисунок3.webp

На уровне команд требуется еще большая декомпозиция задач. Каждая фича должна быть разбита на несколько понятных и четко сформулированных пользовательских историй (user stories), которые можно оценить и реализовать в течение спринта.

Например, фичу «Личные сообщения» можно декомпозировать в следующие пользовательские истории: «Возможность отправлять сообщения», «Возможность получать сообщения», «Сохранение истории переписки». Такая же декомпозиция потребуется и для архитектурных эпиков.

Таким образом, по мере спуска с уровня портфолио к уровню команд, задачи уменьшаются, а их границы уточняются. Соответственно, оценки также становятся точнее.

В следующей статье мы расскажем подробнее про то, как организуется работа на каждом из уровней SAFe.

Связаться с нами можно через форму обратной связи.