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