Разработка и поставка продукта является смысловой конструкцией, которая характеризует наличие, понимание, использование инженерных подходов и инструментов для разработки программного обеспечения. Активное использование инженерных практик позволяет выпускать продукт высокого качества инкрементно и итеративно, соответствующего потребностям стейкхолдеров.
В данной статье предложена система метрик для измерения и дальнейшего анализа атрибутов организации разработки и поставки программного продукта.
Остальные части программы оценки готовности к трансформации:
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.