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

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

Остальные части программы оценки готовности к трансформации:
SCRUM: Понимание и применение фреймворка
SCRUM: Гибкое управление продуктовыми направлениями
SCRUM: Развитие сотрудников и продуктовых команд

Инженерная практика CI/CD

Инженерная практика CI (непрерывная интеграция) / CD (непрерывная поставка) позволяет активировать эмпирический процесс инспекции рабочей функциональности продукта с большой частотой для дальнейшей адаптации в части решения найденных проблем. Идея этой практики заключается в том, что любые изменения разработчика в части ПО должны быть слиты в общий репозиторий кодовой базы как можно чаще. Далее должна происходить компиляция сборки из общего репозитория как можно чаще для инспекции изменений.

[0–28] — низкий результат, свидетельствующий об отсутствии инженерной практики CI/CD как класса. Управление средой разработки и поставками происходит хаотичным образом с повышенными временными и экономическими затратами. При данном результате необходимо переосмыслить текущий подход в части его трансформации и зафиксировать в плане мероприятий для улучшения каждой из характеристик. Не рекомендуется проводить мероприятия вне контекста общей программы трансформации.

[28–33] — средний результат, свидетельствующий о наличии инженерной практики CI/CD как класса. Однако существуют определённые ограничения для его эффективного использования. В рамках данного результата необходимо рассмотреть мероприятия, направленные для улучшения характеристик с низкой оценкой. Допускается проводить внедрение мероприятий изолировано от общей программы.

[34–40] — максимальный результат, свидетельствующий об использовании инженерной практики CI/CD, как это задумано по определению. В случае данного результата целесообразно зафиксировать процессы и практики для разработки регламента в целях масштабирования на новые продукты. Рекомендуется также рассмотреть следующее свойство: непрерывное обеспечение качеством (CQ), так как в паре c CI/CD достигается больший синергетический эффект.

Непрерывное обеспечение качества CQ

В отличие от QA (quality assurence), которое фокусируется на решении возникших проблем с использованием инструмента доступных регламентов и процедур, система непрерывного обеспечения качества CQ (continious quality) создаёт условия для решения проблем через непрерывное улучшение процессов и компетенций сотрудников. Одним из основополагающих принципов CQ является создание оптимальных контуров обратной связи (тестирования) в части нахождения дефектов программного обеспечения, а также частоты запуска обозначенных контуров.

[0–35] — низкий результат, свидетельствующий об отсутствии системы непрерывного обеспечения качеством (CQ) как отдельного организационного класса. Производственный процесс разработки программного обеспечения является дефектно ориентированным, при котором запускаются циклы «тестирование — исправление» при каждом выполнении регрессионного тестирования. Отдельно стоит упомянуть про технический долг, который растёт по экспоненте. При данном результате рекомендуется переосмыслить текущие подходы и разработать программу мероприятий для улучшения каждой из характеристик. Не рекомендуется проводить мероприятия вне контекста общей программы трансформации.

[35-50] — средний результат, свидетельствующий о наличии системы непрерывного обеспечения качеством (CQ) как класса, но присутствуют ограничения для его эффективного проявления. При этой оценке уже наблюдаются проявления подхода «сначала тестирование — потом программирование» , однако он не выделен в отдельную сущность как часть культуры CQ. Рост технического долга имеет линейную зависимость от выпущенных версий. В рамках данного результата необходимо рассмотреть мероприятия для улучшения характеристик с низкой оценкой. Допускается проводить внедрение мероприятий изолировано от общей программы.

[42–50] — максимальный результат, свидетельствующий о ярко выраженном свойстве, которое развивается и характеризует производственный процесс разработки ПО, как функционально-ориентированным (feature driven). Любые активности, связанные с тестированием, рассматриваются как очевидные и рутинные операции, которые не требуют времени для планирования и выполняются в едином производственном потоке.

Оптимальный организационный поток

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

[0–29] — низкий результат, свидетельствующий о неоптимальном организационном потоке, которому свойственно до 50% времени ожидания на решение задач, а также фокусирование на задачах, быстро теряющих актуальность. В первую очередь рекомендуется сделать акцент на снижение звеньев управления на пути движения задачи и изменить принцип организации групп на предметный — продукт, сервис, компонент. Данные мероприятия необходимо зафиксировать в программе трансформации.

[29-34] — средний результат, свидетельствующий о формировании оптимального организационного потока. Однако существуют ограничения для его эффективного использования. Рекомендуется разработать мероприятия с акцентом на снижение времени ожидания и формирование культуры визуализации рабочего потока с помощью инструментов доступных инструментов: SCRUM и Kanban-доски.

[35-41] — высокий результат, свидетельствующий о наличии оптимального организационного потока, при котором соблюдается принцип транспарентности и предметно-ориентированная группа сфокусирована на задачах, имеющих актуальность в текущий момент времени. Время предоставления ответов на вопросы внутри предметно-ориентированной группы сводится к минимуму, что сказывается на уменьшении времени релизного цикла. Рекомендуются зафиксировать данное свойство как эталонное и включить в программу обучения и коучинга.

Управление рисками

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

• Финансовый риск — можем ли мы заплатить за продукт?

• Бизнес-риск — будет ли продукт использоваться? Продукт решает проблему?

• Технический риск — можем ли разрабатывать и поддерживать продукт?

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

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