SCRUM: Разработка и поставка продукта

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

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

Остальные части программы оценки готовности к трансформации:
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.