Модель требований в SAFe®

Те, кто так или иначе сталкивался с SAFe, знают, что задачи в нем выстроены в иерархической структуре бэклогов. Какие-то задачи являются декомпозицией более верхнего уровня и так далее до Стратегических Тем (Strategic Themes).

Чтобы не запутаться в этом многообразии, в этой статье мы привели перевод официальной модели требований в SAFe: SAFe Requirements Model — актуализировав ее с учетом актуальной версии фреймворка SAFe 5.1. Надеемся, что визуальное отображение элементов бэклогов, их свойств и взаимосвязей даст вам возможность с легкостью разобраться в различных типах требований в SAFe.

Итак, внимание на модель!

Нажмите на изображение, чтобы открыть его крупнее.

Рассмотрим ее подробнее. Каждый элемент бэклога относится к одному из четырех типов: Эпик, Возможность, Фича или История — все они ограничены Нефункциональными Требованиями (NFRs) и описываются набором свойств.

Эти артефакты во многом способны заменить традиционную модель работы с требованиями. Простые, но достаточные описания оставляют пространство для гибкости, вместе с тем конкретно определяя суть каждого элемента. Требования разработаны в полном согласии с принципами Lean-Agile. Мы помним, что важно не зацикливаться на специфических деталях реализации задачи раньше получения полезной обратной связи, чтобы не выполнять лишнюю работу (Принцип #3: Предполагайте изменчивость, сохраняйте опции).

Рассмотрим, как поддерживается Lean в требованиях на разных уровнях.

• Уровень Портфеля. Реализация и финансирование Эпика в SAFe происходит не целиком, а только в рамках MVP (Minimum Viable Product, минимально жизнеспособный продукт). Результаты реализации проверяют, используя опережающие метрики, чтобы заранее понимать эффект и принимать соответствующие управленческие решения. Оформление производится минимальным набором документов: Lean Business Case и Epic Hypothesis Statement существенно снижают нагрузку на бюрократическую часть процесса, не теряя в контроле и сохранении знаний.
• На уровне Решения и Программы требования ограничены по длительности: их размер ограничен 1 (одним) PI (Инкрементом Программы) на 1 (один) элемент бэклога — а также обязательно должна быть определена Гипотеза о выгоде, позволяющая понимать успешность результатов от выполнения требования.
• Отдельным подтипом являются Enabler-требования: они помогают найти баланс между инвестициями в технологическое совершенство и бизнес-потребностями — на всех уровнях организации.

Переходя к уровню команд, требования начинают сильнее поддерживать Agile.

• Работа по производству продукта происходит в условиях повышенной неопределенности, что требует гибкой и быстрой реакции на основе получаемой информации. Истории, как основной элемент требований на уровне Agile-команд, должны соответствовать критериям INVEST, простым языком доносить суть работ как до исполнителей, так и до заинтересованных лиц и явно указывать на то, зачем планируется реализация того или иного требования.
• Модель включает в себя и артефакты тестирования. Приемочные тесты являются ограничением для выполнения каждого элемента, отдельно учитываются тесты качества системы для Нефункциональных Требований. Несмотря на то, что разработка ведется гибко, качество — это одна из четырех ценностей, на которых работает эта модель.

Многим компаниям потребуется только часть из этой модели. Например, Agile-команды в первую очередь работают с Историями, их приемочными тестами и NFRs. Основная задача, которую преследовали при переводе — помочь консультантам и экспертам в SAFe понять, как все элементы бэклогов разного уровня взаимодейтсвуют друг с другом в единой системе. Модель можно применить для проектирования уровней иерархии требований в системах управления задачами, например, в JIRA.

Не стоит удивляться тому, что модель выглядит запутанной, требования на масштабе всей организации — это сложная система даже при работе по Lean-Agile. Помните, если какой-то из элементов не отвечает контексту вашей организации, не используйте его. Применение всех элементов модели является необходимым только при производстве очень большого и сложного продукта, требующего работы нескольких сотен, а то и тысяч специалистов.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.