Все статьи
Встроенное качество в SAFe®
Дата: 08.11.2024
Встроенное качество в SAFe® (Scaled Agile Framework®) — это набор практик, помогающих гарантировать, что результаты работы Agile-команд в бизнес- и технологических областях соответствуют установленным стандартам качества на протяжении всего процесса создания ценности для клиента.
Содержание
Встраивание (обеспечение) качества требует постоянного обучения и приверженности. Но преимущества оправдывают инвестиции и включают:
- Более высокая удовлетворенность клиентов.
- Повышенная скорость и предсказуемость доставки.
- Лучшая производительность системы.
- Больше возможностей инноваций, масштабирования и соблюдения регуляторных требований.
Встроенное качество связано с быстрым потоком ценности, описанным в принципе SAFe 6: «Сделайте поток ценности непрерывным». Ускорение обнаружения проблем и принятия корректирующих мер происходит путем смещения обучения влево по временной шкале. Улучшенное сотрудничество, автоматизация рабочего процесса, более частая доставка и более быстрая обратная связь с клиентами способствуют более быстрому процессу обучения.
В оставшейся части статьи эти компоненты описываются более подробно.
Домены обеспечения качества
Практики встроенного качества различаются в зависимости от областей, в которых они применяются. Несмотря на то же намерение, лежащее в основе подхода встроенного качества к созданию ценности для клиента, фактические практики отражают сложность их среды и контекста. Ниже приведены области встроенного качества в SAFe.
Бизнес-функции включают маркетинг, продажи, HR, финансы, управление цепочками поставок и другие не-ИТ-дисциплины. Наряду с рутинными операциями каждая функция также включает в себя сложные усилия, требующие определенных качественных результатов для успеха. Например, создание новой маркетинговой кампании или установление новой HR-политики подразумевает определенные ожидания в отношении качества.
Программное обеспечение является важным фактором гибкости бизнеса, способности масштабировать бизнес и лучше конкурировать в цифровую эпоху. Но чтобы воспользоваться такими возможностями, необходимо поддерживать предсказуемое качество поставляемых решений.
При использовании в компьютерных технологиях аппаратное обеспечение обычно относится к кабелям, мониторам, интегральным схемам и другим осязаемым элементам компьютерной системы. Но в более общем смысле аппаратное обеспечение относится к устройствам с конкретными физическими свойствами: массой, размером и материей. Примерами являются двигатели, шестерни, инструменты, шасси, корпуса и простые или сложные механизмы. Из-за значительно более высокой стоимости изменений аппаратные системы требуют уникального подхода к качеству.
Киберфизические системы — это сложные системы, в которых множество физических элементов управляются программными алгоритмами. Примерами служат роботы, самолеты и автомобили. Это одни из самых сложных систем в мире, которые часто включают в себя сложные электрические, механические, оптические, жидкостные, сенсорные и другие подсистемы. Их сложность и сильное влияние отказов подчеркивают критическую важность качества в таких системах.
Базовые Agile-практики обеспечения качества
Разработка всегда включает в себя множество неизвестных, которые всплывают по ходу разработки, и команды узнают новые факты. Если обучение происходит на поздних этапах процесса, то основные проблемы существенно повлияют на решение, что приведет к значительным доработкам и задержкам. Однако, если обучение происходит намного раньше — или смещено влево — проблемы проявляются раньше, что позволяет вносить корректирующие действия с минимальным воздействием.
Смещение обучения влево означает не просто то, что некоторые действия происходят раньше на временной шкале, но и то, что структура некоторых базовых процессов меняется. Например, подход «сначала тест» требует отхода от традиционного тестирования. Вместо этого тесты по возможности создаются до того, как будут реализованы желаемые функции решения.
Парная работа описывает практику, в которой два работника умственного труда совместно работают над одним и тем же активом в режиме реального времени. Часто один выступает в качестве водителя, напрямую продвигая работающий продукт, в то время как другой выступает в качестве штурмана, обеспечивая оценку и обратную связь в режиме реального времени. Члены команды часто меняются ролями. Поскольку работающий продукт будет содержать общие знания, точки зрения и передовой опыт каждого члена, парная работа создает и поддерживает более высокое качество. По мере того, как члены команды учатся друг у друга, наборы навыков всей команды растут и расширяются. Кроме того, рецензирование помогает выявлять проблемы с качеством, когда один член команды тестирует работающие продукты другого. Например, многие процессы управления, связанные с программным обеспечением, требуют рецензирования как деятельности по соблюдению регуляторных требований.
Совместное владение — это практика обеспечения качества, при которой отдельные члены команды обладают необходимыми навыками и полномочиями для обновления любого соответствующего актива. Такой подход снижает зависимость между командами и гарантирует, что ни один отдельный член команды или команда не будет блокировать быстрый поток поставки ценности. Любой человек может добавлять функциональность, исправлять ошибки, улучшать проекты или проводить рефакторинг, поскольку рабочий продукт не принадлежит одной команде или отдельному человеку. Совместное владение поддерживается стандартами качества, которые поощряют последовательность, позволяя каждому понимать и поддерживать качество каждого компонента. Совместное владение дополнительно обеспечивается «T-образными навыками». T-образные навыки характеризуют людей, которые обладают глубоким опытом в одной области, но также имеют широкие навыки в других областях. T-образные навыки также представляют собой способность хорошо работать с другими.
Активы, созданные и поддерживаемые организацией, должны соответствовать стандартам, которые помогают гарантировать их ценность для бизнеса. Эти стандарты могут отражать, как создаются артефакты или какие свойства они должны проявлять. Стандарты часто уникальны для конкретной организации и контекста решения, появляются постепенно, часто проверяются и корректируются с помощью нескольких циклов обратной связи. Чтобы продуктивно поддерживать стандарты артефактов, команды должны понимать мотивы их существования. Практики проектирования артефактов и эффективное использование автоматизации помогают облегчить стандарты. Принятие продуктивных стандартов артефактов включает применение критериев готовности (Definition of Done, DoD) — важнейший способ обеспечения того, чтобы рабочий продукт был полным и правильным. Каждая команда, поезд и предприятие должны создать DoD, который соответствует их потребностям.
Рабочие процессы, как правило, имеют много ручных действий. Передача от одного работника другому, поиск интересующего актива и ручная проверка актива на соответствие стандарту — вот лишь несколько примеров. Дело в том, что все эти ручные действия подвержены ошибкам и вызывают задержки в процессе. Многие из этих задач можно автоматизировать, если команды потратят время на то, чтобы вложить средства в более автоматизированный конвейер, поддерживающий действия. Автоматизация обеспечивает существенные выгоды за счет снижения затрат на выполнение и внутреннего соблюдения стандартов. Конечно, это можно делать постепенно, и часто это начинается с внедрения системы Kanban, а затем выбора шагов, которые можно автоматизировать. Иногда первым шагом является простая настройка автоматических уведомлений при изменении состояния элемента. Еще проще, многие такие системы спроектированы как настоящие вытягивающие системы, где работник просто проверяет систему, чтобы узнать, какая работа доступна ему на основе ее состояния. В этом случае передача происходит автоматически и не требует отдельных накладных расходов на связь только для того, чтобы узнать состояние рабочего продукта.
Бизнес-стандарты качества
- Организуйтесь в Agile-команды, пройдите обучение и работайте итеративно.
- Определите стандарты и политики соответствия для вашей функции.
- Согласуйте критерии готовности (Definition of Done, DoD) для артефактов и действий для вашего рабочего процесса.
- Внедрите основные Agile-практики качества.
- Измеряйте и учитесь.
- Специализируйте Agile-практики качества в соответствии с вашей конкретной функцией.
- Неустанно совершенствуйтесь.
Agile-практики разработки качественного программного обеспечения
Создание крупномасштабной ценности требует от работников умственного труда создания системы пошагово, что приводит к частым небольшим изменениям. Каждое должно постоянно проверяться на наличие конфликтов и ошибок и интегрироваться с остальной частью системы для обеспечения совместимости и продвижения вперед. Непрерывная интеграция (Continuous Integration, CI) предоставляет разработчикам быструю обратную связь. Каждое изменение быстро создается, интегрируется и затем тестируется на нескольких уровнях. CI автоматизирует процесс тестирования и переноса изменений через различные среды, уведомляя разработчиков, когда тесты не пройдены.
Непрерывная интеграция имеет решающее значение как внутри команд, так и между ними, позволяя им быстро выявлять и устранять проблемы во всех частях кодовой базы.
Agile-команды работают в быстрой, основанной на потоке системе для быстрой разработки и выпуска высококачественных бизнес-возможностей. Вместо того, чтобы выполнять большую часть тестирования в конце, Agile-команды определяют и выполняют множество тестов на ранних этапах и часто как часть своего процесса интеграции. Тесты определяются для небольших порций программного кода с использованием Test-Driven Development (TDD), для критериев приемки Story, Feature и Capability с использованием Behavior-Driven Development (BDD) и для гипотезы о преимуществах фичи или возможности с использованием Lean UX. Создание качества гарантирует, что частые изменения Agile-разработки не привнесут новых ошибок, обеспечивая при этом быстрое и надежное выполнение.
Постоянно меняющиеся технологии и меняющиеся бизнес-цели затрудняют поддержание и постоянное увеличение бизнес-ценности. Однако, существуют два пути в будущее:
- Продолжайте добавлять новые функции в существующую кодовую базу, пока в конечном итоге не доведете ее до состояния «выбрасывания», которое невозможно поддерживать.
- Постоянно реорганизуйте систему, чтобы создать основу для эффективного предоставления текущей бизнес-ценности, а также будущей бизнес-ценности.
Рефакторинг, который улучшает внутреннюю структуру или работу части программного кода, не меняя ее внешнего поведения, лучше. При непрерывном рефакторинге срок службы инвестиций предприятия в программные активы может быть существенно продлен, что позволит пользователям получать выгоду от потока ценности в течение многих лет. Но рефакторинг требует времени, а возврат инвестиций не происходит немедленно, поэтому резерв времени и усилий должен быть частью соображений по планированию емкости.
Непрерывная поставка обеспечивает возможность выпускать ценность для клиентов, когда бы им это ни понадобилось. Это достигается с помощью конвейера непрерывной поставки (Continuous Delivery Pipeline, CDP), который содержит четыре аспекта: непрерывное исследование, непрерывную интеграцию, непрерывное развертывание и выпуск по требованию. Continuous Delivery Pipeline, CDP позволяет организациям сопоставлять свой текущий конвейер с новой структурой и использовать неустанное улучшение для предоставления ценности клиентам. Циклы обратной связи внутри и между шагами и внешние между клиентами и предприятием подпитывают улучшения. Внутренние циклы обратной связи часто сосредоточены на улучшениях процесса; внешние циклы часто сосредоточены на улучшениях решения. Улучшения в совокупности создают синергию, гарантируя, что предприятие «создает правильную вещь правильным способом» и часто поставляет ценность рынку. Кроме того, SAFe DevOps включает в себя важные практические области для создания быстрых и надежных механизмов доставки ценности.
Непрерывная поставка помогает командам SAFe выпускать релизы по требованию. Однако, выпуск с качеством требует конкретных масштабируемых критериев готовности, которые помогают гарантировать, что требуемое качество встроено.
Для поддержки мер безопасности команды создают спецификацию программного обеспечения (Software Bill of Materials, SBOM) для каждого выпуска, описывающую коммерческие и открытые компоненты и зависимости, чтобы гарантировать отсутствие уязвимостей.
Agile-архитектура — это набор ценностей, практик и сотрудничества, которые поддерживают активный, эволюционный дизайн и архитектуру системы. Она охватывает мышление DevOps, позволяя архитектуре системы непрерывно развиваться, одновременно поддерживая потребности текущих пользователей.
Agile-архитектура поддерживает Agile-методы разработки посредством сотрудничества, эмерджентного проектирования, целеориентированной архитектуры и простоты проектирования. Она также позволяет проектировать для тестируемости, развертываемости и изменяемости. Быстрое прототипирование, проектирование на основе наборов, моделирование доменов и децентрализованные инновации, в свою очередь, поддерживают Agile-архитектуру.
Основная концепция Архитектурной Полосы позволяет Agile-командам и обучающим программам эффективно внедрять будущие бизнес-возможности и фичи, одновременно постепенно проверяя базовые архитектурные предположения.
Практики обеспечения качества ИТ-систем
Одной из важнейших проблем в обеспечении качества ИТ-экосистем является определение и поддержка конфигураций последовательно. Часто представляя сотни или даже тысячи параметров среды, конфигурации выходят из синхронизации и вызывают проблемы в различных частях ландшафта решений предприятия. «Инфраструктура как код» — это подход к программному управлению этими конфигурациями и, таким образом, полное использование автоматизации для определения, закупки и поддержки конфигураций последовательно и целостно. Контейнеризация — отличный инструмент для инфраструктуры как кода, поскольку она позволяет применять программные интерфейсы к различным аспектам среды выполнения. Кроме того, использование «неизменяемой инфраструктуры» — подхода, при котором ИТ-компоненты перестраиваются по мере необходимости, а не изменяются в процессе производства, — вынуждает организацию явно контролировать все изменения в среде путем их формального переопределения и повторного развертывания измененного компонента.
ИТ-инфраструктура должна предоставлять определенные качества среде выполнения для поддержки систем, необходимых для работы бизнеса. Эти атрибуты качества включают такие вещи, как безопасность, надежность, производительность, ремонтопригодность и масштабируемость (нефункциональные требования или Non Functional Requirements, NFR). Кроме того, должны быть обеспечены соответствующие соглашения об уровне обслуживания (Service Level Agreement, SLA), такие как среднее время до отказа (Mean Time Before Failure, MTBF) и среднее время ремонта (Mean Time to Repair, MTTR). В SAFe NFR и SLA достигаются постепенно путем раннего и непрерывного тестирования и своевременных корректирующих действий. Обеспечение соответствия систем своим NFR и SLA требует инструментирования и проактивного построения и использования архитектурной полосы.
Реагирование на непредвиденные нагрузки, атаки безопасности, аппаратные, программные и сетевые сбои требуют ряда вариантов: от понижения или удаления служб до добавления емкости служб. Возможности телеметрии и ведения журналов позволяют организациям понимать и настраивать свою архитектуру и операционные системы для соответствия предполагаемым нагрузкам и шаблонам использования. Эффективный мониторинг требует, чтобы телеметрия полного стека была активна для всех функций, развернутых через CDP. Мониторинг гарантирует, что проблемы с производительностью системы можно предвидеть или быстро решать в процессе производства.
ИТ-среды должны соответствовать все более строгим стандартам качества для защиты от несанкционированного доступа, использования, раскрытия или уничтожения. Спектр мероприятий по достижению всеобъемлющей кибербезопасности включает:
- Поддержка технологий (шифрование данных, оптимизированное управление идентификацией и т.д.).
- Частое тестирование и проверка (аудиты, тестирование на проникновение и т.д.).
- Обучение и надлежащие привычки сотрудников.
- Тестирование всех новых активов на предмет различных уязвимостей.
- Часто просматривайте новые оповещения об уязвимостях по сравнению с существующим SBOM (Software Bill of Materials) решения для затронутых компонентов и предоставляйте исправления или хотфиксы.
Последние достижения в DevOps и связанных с ними методах, практиках и инструментах предоставляют новые возможности для ИТ-команд по автоматизации управления. Автоматизированное управление заменяет утомительные, ручные и подверженные ошибкам действия и в частности решает проблемы безопасности, соответствия и аудита.
Автоматизация управления конфигурацией, аудита, тестирования безопасности (как во время сборки, так и во время развертывания) и неизменяемая инфраструктура помогают сократить количество человеческих ошибок, которые могут привести к уязвимостям системы.
Практика обеспечения качества гибкой разработки аппаратного обеспечения
Анализ и моделирование в цифровых моделях, используемых в электрическом и механическом автоматизированном проектировании (Система автоматизированного проектирования, САПР) и системной инженерии на основе моделей (Model-Based Systems Engineering, MBSE), могут быстро и экономично тестировать изменения. Цифровые двойники объединяют несколько виртуальных моделей с данными, собранными из телеметрии в операционных системах, чтобы улучшить модели и лучше предсказать, как системы будут вести себя в будущем. Циклы обратной связи на рисунке показывают, как данные из других сред проверяют и улучшают цифровую среду. Некоторые аэрокосмические и автомобильные продукты даже используют моделирование моделей для сертификации, что существенно сокращает время и стоимость изменений.Виртуальная среда не может выявить все проблемы. Физические прототипы являются более дешевой заменой реального оборудования «изогнутого металла». Они обеспечивают более точную обратную связь, доступную только в физической среде. Примеры практик прототипирования включают:
- Деревянные и другие макеты с низкой точностью.
- Макетирование электрических компонентов.
- Механические и электрические детали, напечатанные на 3D-принтере (печатные платы, жгуты проводов).
Все чаще аддитивное производство используется для снижения затрат на быстрое экспериментирование и создание прототипов.
«Аддитивное производство использует программное обеспечение для автоматизированного проектирования данных (САПР) или 3D-сканеры объектов, чтобы направлять оборудование на нанесение материала, слой за слоем, в точные геометрические формы. Как следует из названия, аддитивное производство добавляет материал для создания объекта. Напротив, когда вы создаете объект традиционными способами, часто необходимо удалить материал посредством фрезерования, обработки на станке, резьбы, формовки или других способов».
Многие организации, имеющие оборудование и знания для «печати» механических и электрических деталей, могут производить и отгружать их за один день. А детали, изготовленные с помощью аддитивного производства, теперь поступают в производство.
Практики качества киберфизических систем
Системная инженерия на основе моделей (Model-Based Systems Engineering, MBSE) — это практика разработки набора взаимосвязанных цифровых моделей, которые помогают определять, проектировать и документировать разрабатываемую систему. Эти модели предоставляют эффективный способ исследования, обновления и сообщения аспектов системы заинтересованным сторонам, при этом значительно сокращая или устраняя зависимость от традиционных документов. Тестируя и проверяя характеристики системы на ранних этапах с помощью модели, они облегчают своевременное изучение свойств и поведения, обеспечивая быструю обратную связь по требованиям и решениям по проектированию.
В области программного обеспечения непрерывная интеграция является сердцем непрерывной поставки: это функция принудительной проверки изменений и обоснования предположений по всей системе. Agile-команды инвестируют в автоматизацию и инфраструктуру, которая создает, интегрирует и тестирует каждое изменение разработчика, обеспечивая немедленную обратную связь по ошибкам.
Крупные киберфизические системы гораздо сложнее интегрировать непрерывно, поскольку:
- Товары с длительным сроком поставки могут быть недоступны.
- Интеграция выходит за рамки организационных границ.
- Автоматизация редко бывает сквозной.
- Законы физики диктуют определенные ограничения.
Вместо этого частая сквозная интеграция решает экономические компромиссы между транзакционными издержками интеграции и задержкой получения знаний и обратной связи.
Целью является частая частичная интеграция с как минимум одной полной интеграцией решения для каждого PI (Planning Interval).
