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

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

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

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

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

Характеристика

Метод исследования

Метрика

GIT инструменты

Наблюдение за инструментом GIT.

GIT инструмент есть — 0 баллов.

GIT инструмента нет — 5 баллов.

Частота CI

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

менее раза в сутки — 0 баллов.

1 раз в сутки — 1 балл.

4 раз в сутки — 3 балла.

более 5 раз — 5 баллов.

Время CI

Наблюдение за временем CI, выполняемым одним разработчиком.

более 4 часов — 0 баллов.

от 1 до 4 часов — 1 балл.

от 30 минут до 1 часа — 3 балла.

от 5 до 30 минут — 5 баллов.

Частота CD

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

менее раза в сутки — 0 баллов.

от 2 до 4 раз в сутки — 1 балл.

более 5 раз в сутки — 3 балла.

при каждом CI — 5 баллов.

Время CD

Наблюдение за временем CD, выполняемое на стенде разработки.

более 8 часов — 0 баллов.

от 3 до 8 часов — 1 балл.

от 1 до 3 часов — 3 балла.

менее 1 часа — 5 баллов.

Роль DevOps

Наблюдение за присутствием роли DevOps в контуре разработки.

роль отсутствует — 0 баллов.

роль присутствует — 5 баллов.

Количество сред

Наблюдение за применяемыми средами в процессе разработки.

более 3 сред — 0 баллов.

3 среды — 5 баллов.

Количество веток

Наблюдение за используемыми ветками в процессе разработки.

более 2 веток — 0 баллов.

2 ветки — 5 баллов.

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

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

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


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

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

Характеристика

Метод исследования

Метрика

Unit тесты

Опрос разработчиков о наличии unit тестов.

0-30% покрытие — 0 баллов.

30-50% покрытие — 1 балл.

50-80 % покрытие — 3 балла.

80-100% покрытие — 5 баллов.

Функциональные тесты

Опрос разработчиков о наличии функциональных тестов.

0-30% покрытие — 0 баллов.

30-50% покрытие — 1 балл.

50-80% покрытие — 3 балла.

80-100% покрытие — 5 баллов.

Регрессионные тесты

Опрос разработчиков о наличии регрессионных тестов.

0-30% покрытие — 0 баллов.

30-50% покрытие — 1 балл.

50-80 % покрытие — 3 балла.

80-100% покрытие — 5 баллов.

Нагрузочные тесты

Опрос разработчиков о наличии нагрузочных тестов.

0-30% покрытие — 0 баллов.

30-50 % покрытие — 1 балл.

50-80% покрытие — 3 балла.

80-100% покрытие — 5 баллов.

Автотесты

Опрос разработчиков о наличии автотестов.

0-30% покрытие — 0 баллов.

30-50% покрытие — 1 балл.

50-80% покрытие — 3 балла.

80-100% покрытие — 5 баллов.

Частота unit тестирования

Наблюдение за периодичностью unit тестирования.

не проводится — 0 баллов.

менее 1 раз в день — 1 балл.

1 раз в день — 3 балла.

при каждом MR — 5 баллов.

Частота регрессионного тестирования

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

по запросу — 0 баллов.

при выпуске версии — 1 балл.

при выпуске фичи — 5 баллов.

Частота нагрузочного тестирования

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

по запросу — 0 баллов.

при выпуске версии — 1 балл.

при выпуске фичи — 5 баллов.

Частота функционального тестирования

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

по запросу — 0 баллов.

при выпуске версии — 1 балл.

при выпуске фичи — 5 баллов.

Частота запуска автотестов

Наблюдение за периодичностью запуска автотестов в окружении разработки.

не проводятся — 0 баллов.

1 раз в неделю — 1 балл.

пару раз в неделею — 3 балла.

при каждом CD — 5 баллов.

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

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

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


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

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

Характеристика

Метод исследования

Метрика

Время ожидания ответа на запрос принятия решения

Наблюдение за средним временем ожидания ответа на вопрос в контексте принятия решения или блокирования работы.

более 8 часов — 0 баллов.

от 1 до 8 часов — 1 балл.

от 30 минут до 1 часа — 3 балла.

менее 30 минут — 5 баллов.

Принцип организации групп

Наблюдение за принципом организации групп.

функциональный принцип — 0 баллов.

продуктовый принцип — 8 баллов.

Звенья управления

Наблюдение за количеством сотрудников с функцией управления на пути движения задачи.

более двух звеньев — 0 баллов.

2 звена управления — 5 балла.

1 звено управления — 8 баллов.

Транспарентность коммуникаций

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

хаотичные каналы — 0 баллов.

фиксированные каналы — 5 баллов.

Транспарентность триггеров событий

Наблюдение за триггерами, при которых должно произойти определённое событие (тестирование, авторская приёмка, новый билд).

ручная нотификация — 0 баллов.

автоматизированная — 5 баллов.

Отношение решённых задач к открытым

Наблюдение за графиком роста решённых задач по отношению к открытым.

преобладают пологие участки — 0 баллов.

стабильный рост — 5 баллов.

Визуализация организационного потока

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

отсутствует визуализация — 0 баллов.

присутствует в контексте функциональной задачи — 1 балл.

применяются SCRUM, Kanban доски для визуализации общего потока — 5 баллов.

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

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

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


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

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

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

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

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

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

Характеристика

Метод исследования

Метрика

Финансовый риск

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

более 3 месяцев — 0 баллов.

от 2 до 3 месяцев — 3 балла.

до 2 месяцев — 5 баллов.

Бизнес-риск

Наблюдение за частотой демонстрации инкремента продукта стейкхолдерам.

при выпуске версии — 0 баллов.

при выпуске инкремента — 5 баллов.

Технический риск

Наблюдение за объёмом технического долга.

технический долг растёт с каждой версией — 0 баллов.

технический долг снижается с каждой версией — 5 баллов.

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

пользователь воспроизвёл критичную ошибку — 0 баллов.

пользователь не воспроизвёл критичную ошибку — 5 баллов.

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