Agile-комплаенс

Вольный перевод статьи Compliance — Scaled Agile Framework®.

Доверяй, но проверяй.
— Рональд Рейган, цитируя русскую пословицу

Compliance (комплаенс) — нормативно-правовой контроль, под которым понимается стратегия и комплекс мероприятий и артефактов, которые позволяют командам применять методы разработки Lean-Agile для создания систем с максимально возможным качеством, одновременно гарантируя их соответствие любым нормативным, отраслевым или другим соответствующим стандартам.

Примечание: Эта статья дополняется официальным документом Achieving Regulatory and Industry Standards Compliance with the Scaled Agile Framework® (SAFe®). Кроме того, вебинар с вопросами и ответами на указанную тему можно посмотреть здесь.

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

Чтобы обеспечить общественную безопасность, эти системы часто не только подпадают под строгие требования нормативного-правового контроля, но и под обширный надзор со стороны регулирующих органов или клиентов. Кроме того, многие предприятия подчиняются различным государственным нормативам (например, Sarbanes-Oxley, HIPAA, ACA, правила государственного страхования), которые требуют аналогичного внимания и проверок для обеспечения соответствия.

Исторически сложилось так, что организации, действующие в соответствии с указанными правилами, полагались на комплексные системы менеджмента качества (Quality Management Systems, QMS). Устаревшие системы QMS основаны на традиционных, поэтапных моделях разработки (прим. пер. — систем) и борются за то, чтобы идти в ногу со сокращающимся временем вывода продуктов на рынок (time-to-market) и применением практик Lean-Agile. Еще большую озабоченность вызывает то, что даже при принятии более высокой цены задержки (Cost of Delay) традиционные подходы часто не повышают качество и не устраняют риск.

Инспекция не улучшает качества, да и не гарантирует его.
Проверять всегда слишком поздно.
Качество, хорошее или плохое, уже содержится в продукте.
— Эдвардс Деминг, в книге «Выход из кризиса»

Постоянное решение проблем нормативного-правового контроля является одной из девяти практик компетенции SAFe по поставке корпоративных решений (Enterprise Solution Delivery). Статья расширяет эти знания и предлагает рекомендации о том, как применять методы Lean-Agile для более быстрого и качественного создания высоконадежных систем, а также соблюдения критических требований нормативного-правового контроля.

Роль системы менеджмента качества

Классическое управление проектами часто требует, чтобы полная спецификация системы была определена и принята во внимание в деталях, задолго до того, как могут быть известны все реальные модели поведения системы. Последовательный характер прохождения фаз проектов приводит к большим объемам работы (прим. пер. — в течение каждой фазы), длительным циклам между точками интеграции частей системы и запоздалой обратной связи. Кроме того, мероприятия по обеспечению соответствия регуляторным требованиям, как правило, откладываются до конца проекта, что не дает представления о ходе выполнения указанных требований.

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

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

К сожалению, многие системы QMS находятся под сильным влиянием традиционных многоэтапных классических методов управления проектами. Это серьезно тормозит и даже может препятствовать внедрению новых методов, поскольку старые методы закреплены в форме единственно одобренного способа работы. Как показано на рисунке 1, SAFe описывает инкрементальный подход к разработке и нормативно-правовому контролю.

Рисунок 1. Система управления качеством Lean-Agile повышает качество и делает соответствие нормативным требованиям более предсказуемым

Это означает, что те, кто хочет воспользоваться преимуществами Lean-Agile разработки (более быстрое время выхода на рынок и более высокое качество, и это только некоторые из них), как правило, должны будут разработать Lean-QMS.

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

Стройте решение и комплаенс постепенно

Даже имея набор надежных спецификаций, инженерные команды никогда не имеют всех ответов, когда начинается разработка. Вместо этого у них есть набор гипотез, которые должны быть проверены с помощью серии коротких, повторяющихся экспериментов. Эти эксперименты позволяют обучаться таким образом, чтобы достаточно идеально продвигаться к окончательному решению. На рисунке 2 показан инкрементальный подход к развитию (по SAFe), проведено сравнение циклов обучения Шухарта/Деминга с классической моделью.

Рисунок 2. Быстрые циклы обучения PDCA повышают качество и снижают риск

На рисунке 2 показаны два важных последствия для соблюдения требований.

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

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

Организуйтесь вокруг ценности и контроля

Agile Release Trains (ART, «поезда») — это основные организационные единицы по поставке ценности в SAFe. Каждый «поезд» требует всех навыков, необходимых для создания и выпуска решения, включая тех, кто отвечает за обеспечение качества (QA), безопасность, тестирование, а также проверку и валидацию (V&V).

Примечание: Несмотря на то, что некоторые нормативы требуют независимой и объективной проверки, представители комплаенса все же могут постоянно участвовать в качестве членов ART. Результатом является ART, сформированный, как показано на рисунке 3.

Рисунок 3. Agile Release Trains включают все дисциплины, включая нормативно-правовой контроль

Управление решениями и продуктами гарантирует, что Solution Intent и бэклог должным образом отражают требования комплаенса. Команды также гарантируют, что их работа включает в себя соответствующие мероприятия по соблюдению нормативно-правовых требований.

Встроенное качество и комплаенс

Встроенное качество (Build-In Quality) — это одна из четырех ключевых ценностей (Core Values) SAFe, измерение компетенции SAFe под названием Командная и техническая гибкость (Team and Technical Agility), а также основной принцип мышления Lean-Agile. SAFe описывает использование методов встроенного качества, включая автоматизацию для обнаружения проблем с соответствием нормативным требованиям и качеством и, при обнаружении, остановку системы целиком, чтобы сконцентрировать всех на решении проблемы. Эта философия применяет системное мышление, «оптимизируя целое», обеспечивая высокую скорость при прохождении по потоку создания ценности и делая качество заботой каждого. Качество — это культура, а не должность.

С этой целью вопросы нормативно-правового контроля также включаются непосредственно в процесс разработки и автоматизируются там, где это возможно, как показано на рисунке 4.

Рисунок 4. Автоматизация комплаенса, как часть процессов автоматизации

Однако, не все мероприятия по соблюдению требований могут быть автоматизированы, поскольку некоторые нормативные требования предписывают ручные мероприятия, включая такие мероприятия, как анализ видов и последствий отказов (Failure Mode and Effects Analysis, FMEA) и аудит. Эта работа просто запланирована как часть бэклога команды. Цель состоит в том, чтобы проводить эти мероприятия и обзоры по мере того, как строится решение, сокращая завершающие мероприятия выпуска конечного решения с крупных и продолжительных до быстрых и скучных «не-событий».

Таким образом, участники программы получают раннюю обратную связь о степени выполнения комплаенс-мероприятий команды и, наоборот, о том, как эти мероприятия могут повлиять на производительность команды. На рисунке 5 показан цикл обратной связи между деятельностью команды и практикой, определяемой Lean-QMS.

Рисунок 5. Инкременты программы обеспечивают петлю обратной связи для комплаенс деятельности и практики

Непрерывная проверка и валидация (V&V)

Большинство высоконадежных систем требуют V&V, чтобы убедится в следующем:

• Система работает так, как задумано (верификация).
• Она отвечает потребностям пользователя (валидация).

V&V всегда должны выполняться в соответствии с известным набором требований. В противном случае, нечего проверять. Как показано на рисунке 6, SAFe использует Solution Intent в качестве хранилища для существующих и возникающих требований и проектов.

Рисунок 6. Solution Intent SAFe обеспечивает поддержку для проверки и валидации (V&V)

Прослеживаемость в Solution Intent гарантирует, что артефакты произведенные в каждом инкременте программы (PI) — актуальное программное обеспечение, аппаратные компоненты и т.д. — соответствуют нормативным требованиям и спецификациям; предоставляет сквозные доказательства того, что требования V&V были выполнены.

Модель требований SAFe поддерживает V&V

В SAFe все элементы требований имеют тестовые примеры (см. рисунок 7), которые создаются одновременно с функциональностью.

Рисунок 7. Мета-модель требований SAFe поддерживает проверку и валидацию

Каждый инкремент дает новую функциональность и, следовательно, добавляет новые тесты. Поскольку число тестов растет, автоматизация жизненно важна, чтобы предотвратить превращение тестовой деятельности в узкое место.

Сделайте проверку, валидацию и комплаенс рутиной

Проверочные и валидационные работы выполняются небольшими партиями. Каждый рабочий элемент гарантирует, что он включает в себя всю необходимую информацию, необходимую для соответствия требованиям. Любые проверки, аудиты и подписи включаются в критерии готовности (Definition of Done, DoD) рабочего элемента, как показано на рисунке 8. В каждом инкременте программы (PI), на каждой системной демонстрации оценивается прогресс решения на пути к его операционным целям и наличие объективных доказательств, необходимых для нормативно-правового контроля.

Рисунок 8. Деятельность по проверке и валидации является частью потока работ

Выпускайте проверенные решения по требованию

Наконец, SAFe признает, что, хотя процесс разработки продукта происходит в предсказуемом ритме, процесс выпуска (Релиз по потребности) может потребовать дополнительных действий. Они могут включать в себя:

• Валидационное тестирование окончательного кандидата на выпуск (примеры: медицинское испытание, летное испытание).
• Рассмотрение объективных доказательств, необходимых для утверждения и выпуска продукции.
• Подписание документов с заказчиком, регулятором, в части ПМИ (Программа и Методика Испытаний) и финализирующих документов.

Даже в этом случае Lean-организации всегда стремятся полностью автоматизировать поставку и, по возможности, встраивать автоматизированные проверки окончательного выпуска в рамках конвейера непрерывного развертывания (CDP) SAFe и выпуска по требованию.

О переводчике

Лебедев Сергей

17 лет в разработке программных продуктов. Специализируюсь на построении систем управления предприятий. Сейчас руковожу внутренней автоматизацией на производственном предприятии. До этого долгое время был тим-лидом в компании 1С. Ранее консалтинг и автоматизация РЖД, ГК Дело, ЭнПро. Образование: ТУСУР, МЭСИ. PMP, SSM.

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