Радар DevOps-здоровья

	A	B	C	D	E	F
1
2			© 2017 Scaled Agile, Inc. All rights reserved.
3			Радар DevOps-здоровья
4			Название Agile Release Train : xxxxxxxxxxxxxxxxx Дата: xx/x/20xx
5
6			Оценка: Сидим (1-2), Ползем (3-4), Идем (5-6), Бежим (7-8), Летим (9-10)
7
8	Раздел	Подраздел	Вопрос	Оценка	Рейтинг	Комментарий
9	Непрерывное исследование	Генерации гипотез	Генерация гипотез влечет за собой создания бизнес-идеи (эпика) с описанием ценности, которую планируется получить. Эта гипотеза реализуется в виде минимально-жизнеспособного продукта (Minimal Viable Product, MVP) и потом оценивается после релиза. Пожалуйста, оцените способность своей команды транслировать бизнес-идеи в четкие, измеримые описания гипотез (эпики). Сидим (1-2): Идеи туманны и не определены. Ползем (3-4): Идеи определены (как эпики), но описание не включает гипотезу ценности. Идем (5-6): Небольшая часть идей включает описание гипотезы с измеримым результатом. Бежим (7-8): БОльшая часть идей включает описание гипотезы с измеримым результатом и MVP. Летим (9-10): Все идеи описаны с точки зрения гипотезы с измеримым результатом и MVP.	5.0	3
10	Непрерывное исследование	Сотрудничество и исследование	Продуктовые менеджеры работают напрямую с конечными пользователями, заинтересованными лицами и экспертами предметной области для понимания реальных потребностей пользователей и измеримой бизнес ценности. Пожалуйста, оцените способность продуктового менеджмента сотрудничать с клиентом и экспертами для определения минимальных фич, ценных для потребителей (Minimum Marketable Feature, MMF). Сидим (1-2): Роли и отвественность продуктового менеджмента не определена или не соблюдается Ползем (3-4): Продуктовый менеджмент создает длинные требования и практически не общается с клиентом и разработкой Идем (5-6): Продуктовый менеджмент общается только с одной из сторон во время проработки требований: либо с клиентом, либо с разработкой Бежим (7-8): Продуктовый менеджмент регулярно работает со всеми сторонами (бизнесом, клиентом, разработкой, операциями, экспертами), но не определяет минимальные фичи, ценные для потребителей (Minimum Marketable Feature, MMF) Летим (9-10): Продуктовый менеджмент регулярно работает со всеми сторонами и определяет минимальные фичи, ценные для потребителей (Minimum Marketable Feature, MMF)	5.0	3
11	Непрерывное исследование	Архитектура	Для непрерывной поставки архитектура должна прорабатываться до минимально достаточного уровня, чтобы соответствовать внешним требованиям регулятора (Compliance) без вреда потоку разработки продукта. Для этого необходимо обеспечивать минимальную связность решений и постоянно уделять внимание техническому долгу. Пожалуйста, оцените способность вашей команды создавать подобную архитектуру. Сидим (1-2): Архитектура монолитна и хрупка, сложно вносить изменений и управлять сложными зависимостями между несколькими компонентами и системами Ползем (3-4): Архитектура преимущественно монолитна, но часть приложений/систем слабо связаны Идем (5-6): Архитектура в большей мере слабо связанна, но не позволяет выполнять релиз по потребности Бежим (7-8): Архитектура выстроена вокруг поставки ценности, есть лишь немного зависимостей между системами и компонентами Летим (9-10): Архитектура отказоустойчива и позволяет делать релиз по потребности	5.0	3
12	Непрерывное исследование	Синтез	Под синтезом понимается возможность объединить результаты предыдущих блоков для производства приоритезированных по ROI бизнес-фич. Эти фичи являются базовым блоком конвейера непрерывной доставки. Пожалуйста, оцените способность своей команды прорабатывать, приоритезировать бэклог фич. Сидим (1-2): Бэклог программы не существует или не доступен для всех Ползем (3-4): Бэклог программы существует, но фичи полноценно не описываеются и не приоритезируются Идем (5-6): Бэклог программы содержит хорошо проработанные фичи, но не приоритезированные для максимизации ROI с помощью метода WSJF Бежим (7-8): Бэклог программы содержит хорошо проработанные и приоритезированые на максимизацию ROI фичи и их размер оптимален для пропускной способности поезда Летим (9-10): Бэклог программы является коллекцией минимальных фич, ценных для потребителей (Minimum Marketable Feature, MMF), приоритезированных для максимизации ROI с помощью метода WSJF	5.0	3
13	Непрерывная интеграция	Разработка	Для непрерывной поставки разработка декомпозирует фичи на пользовательские истории, разрабатывает все компоненты необходимые для реализации пользовательской ценности. Оцените способность вашей команды быстро определять и реализовывать пользовательские истории. Сидим (1-2): Бэклог команды не существует или не используется регулярно Ползем (3-4): Пользовательские истории не полны или наоборот слишком подробны; unit-тесты обычно не пишутся, рецензирования кода не проводится Идем (5-6): Пользовательские истории описаны достаточно, большая часть изменений покрывается unit-тестами, рецензирования кода проводится часто Бежим (7-8): Код загружается в репозиторий каждый день, покрытие unit-тестов более 80%, рецензирование кода проводится постоянно Летим (9-10): Код загружается в репозиторий несколько раз в день, тесты пишуться до кода (TDD), парное программирование и другие практики обеспечения качества являются нормой	5.0	3
14	Непрерывная интеграция	Сборка	Сборка запускается в момент загрузки кода в репозиторий, включает прогон unit-тестов (и других способов проверки стабильности на уровне компонент), в итоге сборки получается сборка, готовая к развертыванию. Пожалуйста, оцените способность команды непрерывно интегрироваться и собирать стабильные сборки. Сидим (1-2): Сборки запускаются реже чем 1 раз в итерацию, сборка полностью ручная Ползем (3-4): Сборки запускаются 1 раз в итерацию, сборки частично автоматизированы, ветки разработчиков могут жить больше месяца, сборки часто ломаются Идем (5-6): Автосборка производится 1 раз в день, проблемы в сборках исправляются в течение 2-4 часов; ручные unit-тесты запускаются для каждой сборки, ветки разработчиков могут жить 2-4 недели Бежим (7-8): Сборки запускаются автоматически после коммита, проблемы в сборках исправляются в течение 1 часа; unit-тесты автоматически запускаются для каждой сборки; разработческие ветки сливаются в trunk каждую итерацию Летим (9-10): Сборки запускаются на каждое изменение в репозитории (commit), используется статический анализатор кода и есть тесты на безопасность; тесты запускаются до изменения в репозитории (commit); ветки разработки сливаются в trunk каждый коммит	5.0	3
15	Непрерывная интеграция	Сквозное тестирование	Тестирование включает в себя валидацию фич на окружениями, приближенных к промышленному. Тестирование состоит из функционального тестирования, интеграционного тестирования, регрессионого тестирования, нагрузочного тестирования, исследовательского (exploratory) тестирования. Пожалуйста, оцените способность своей команды непрерывно верифицировать конечный результат на окружениях приближенных к боевым. Сидим (1-2): Тестирование проводится вручную на отличных от боевых окружениях, тестирование начинается только после готовности большого объема кода Ползем (3-4): Большая часть тестирования ручная на окружениях отличных от боевых; пользовательские истории разрабатываются и тестируются в одном PI Идем (5-6): Половина тестирования автоматизирована и проводиться на окружении приближенным к боевым каждый PI Бежим (7-8): Большая часть тестирования автоматизирована и проводиться на окружении приближенным к боевым; пользовательские истории тестируются в той же итерации, в которой разработаны Летим (9-10): Успешные сборки автоматически развертываются на окружения приближенных к боевым, все тесты автоматизированы; тесты запускаются в параллель на каждое изменение репозитория (commit)	5.0	3
16	Непрерывная интеграция	Приемка	Приемка заинтересованными лицами проходит на окружении, являющем полной копией промышленного, приемка и обучение производится конечными пользователями до запуска новой функциональности. Пожалуйста, оцените способность своей команды проводить качественную приемку. Сидим (1-2): Нет окружения для приемки или используется тестовое окружение для приемки Ползем (3-4): Фичи разворачиваются вручную на приемочном окружении 1 раз в PI Идем (5-6): Фичи разворачиваются 1 раз в месяц и демонстрируются продуктовому менеджменту Бежим (7-8): Фичи автоматически разворачиваются на окружении для приемки продуктовым менеджементом каждую итерацию Летим (9-10): Пользовательские истории, любые изменения в инфраструктуре автоматически разворачиваются на окружении для приемки	5.0	3
17	Непрерывная поставка	Развертывание	Развертывание - это перенос готовых фич на промышленное окружение. Для непрерывной поставки характерна ситуация, когда фичи развернутые на промышленное окружении не сразу становятся доступны пользователю. Пожалуйста, оцените способность свой команды непрерывно развертывать готовые фичи на промышленное окружение, а также способность управлять их доступностью. Сидим (1-2): Фичи развертываются в промышленном окружении реже чем 1 раз в 3 месяца, процесс развертывания ручной и мучительный, "развертнуто" означает "доступно пользователям" Ползем (3-4): Фичи развертываются в течение PI, процесс развертывания в основном ручной, "развернуто" означает "доступно пользователям" Идем (5-6): Фичи развертываются каждую итерацию; большая часть процесса развертывания автоматизирована, часть фичей может быть развернута без открытия для пользователя Бежим (7-8): Фичи развертываются в промышленное окружение каждую итерацию с помощью полностью автоматизированной процедуры, большая часть фичей развертывается в закрытом для пользователя состоянии (dark releases) Летим (9-10): Фичи развертываются в промышленное окружение каждую итерацию с помощью полностью автоматизированной процедуры, все фичи развертываются сначала без доступности пользователю	5.0	3
18	Непрерывная поставка	Верификация	Фичи необходимо верифицировать на полноту и целостность перед открытием для пользователей. Пожалуйста, оцените способность своей командый быстро и точно определять успешность развертывания, а также способность было откатиться или исправить проблемы развертывания. Сидим (1-2): Развернутые фичи в промышленном окружении не проверяют перед релизом пользователям Ползем (3-4): Развернутые фичи в промышленном окружении проверяются ручным способом и/или приемочными тестами (UAT); проблемы после развертывания решаются в течение оговоренного срока, мы часто делаем исправления сразу на промышленной среде Идем (5-6): Развернутые фичи проверяются ручным способом перед открытием для пользователя; откат с предыдущему состоянию сложен или невозможен; мы не вносим изменения прямо на промышленной среде Бежим (7-8): Развернутые фичи проверяются автоматическими smoke-тестами, синтетическими транзакциями и тестам на проникновение до открытия пользователям; мы можем с легкостью откатиться или исправить неудачное развертывание Летим (9-10): Постоянно на промышленной среде запускаются автотесты и информация отправляется в системы мониторинга; мы можем с легкостью откатиться или исправить неудачное развертывание	5.0	3
19	Непрерывная поставка	Мониторинг	Мониторинг покрывает все фичи продукта как в части технических метрик, так и бизнес-метрик. Сидим (1-2): Нет мониторинга на уровне фичи, есть только мониторинг инфраструктуры Ползем (3-4): Логируются только ошибки и исключительные ситуации (exceptions); анализ логов из разных точек системы агрегируется и проводится в ручном режиме Идем (5-6): Продукт логирует ошибки, активность пользователей и другие данные; данные анализируются вручную для исследования инцидентов и измерения ценности фичей Бежим (7-8): Развернута полноценная система мониторинга, позволяющая связать события из разных частей системы, данные отображаются на панелях управления Летим (9-10): Распределенная система мониторинга предоставляет единую точку доступа к бизнес-метрикам и метрикам производительности	5.0	3
20	Непрерывная поставка	Восстановление	Возможность быстро определить инцидент и восстановить работоспособность критически важна для потока непрерывной поставки. Пожалуйста, оцените, насколько ваша команда проактивно определяет проблемы на промышленном окружении, находит причинно-следственные связи и исправляет проблему используя конвейер (вместо применения патчей на промышленной среде). Сидим (1-2): Клиенты находят проблемы до нас; решение проблем затянуто; клиенты не уверены в нашей способности быстро восстанавливать сервис Ползем (3-4): Системные администраторы отвечают за проблемы на промышленном окружении; вовлечение разработки требует эскалации; команды разработки и администрирования обвиняют друг друга Идем (5-6): Системные администраторы и разработчики вместе владеют процессом решения инцидентов ; восстановление начинается только после обращения пользователей Бежим (7-8): Наши системы мониторинга определяют бОльшую часть проблем до обращения клиентов; системные администраторы и разработчики проактивно вместе восстанавливают сервис Летим (9-10): Наши системы мониторинга уведомляют нас о превышениях порогов; пороги качественно настроены; разработчики отвечают за поддержку своего кода и проактивно исправляют проблемы до того, как они начнут влиять на работу пользователей	5.0	3
21	Релиз по потребности	Релиз	Релиз - это включение развернутых фич для пользователей. Пожалуйста, оцените способность своей команды включать/выключать фичи, быстро переключать трафик между разными промышленными окружениями (blue/green environments), распространять релиз сначала на небольшой процент пользователей (canary releases) перед общей доступностью фичи всем. Сидим (1-2): Релиз для пользователя сильно связан с развертыванием, клиенты сильно расстроены редкостью релизов Ползем (3-4): Релизы плотно связаны с развертыванием, но клиенты отчасти расстроены частотой релизов Идем (5-6): Релизы и развертывание связаны, но могут проходить непрерывно или по требованию Бежим (7-8): Релиз отделен от развертывания; развертнутые фичи включаются для пользователей по мере готовности операционных отделов и бизнеса Летим (9-10): Фичи могут быть включены для небольших сегментов пользователей, переключатели фич удаляются из кода, когда необходимость в них отпадает	5.0	3
22	Релиз по потребности	Стабильность	Непрерывная доставка требует стабильного, надежного промышленного окружения. Пожалуйста, оцените способность своей команды поддерживать промышленное окружение и избегать внеплановых отключений. Сидим (1-2): Мы испытываем частые внеплановые отключения и долго восстанавливаем работу Ползем (3-4): Мы периодически испытываем внеплановые отключения, но восстанавливаем работу в течение оговоренных сроков (SLA) Идем (5-6): Редко происходит внеплановое отключение, меры по восстановлению работоспособности или безопастности эффективны Бежим (7-8): У нас нет внеплановых отключений; мы планируем и репетируем отключение и восстановление Летим (9-10): Мы принудительно отключаем часть инфраструктуры для тестирования процедур восстановления и усиления отказоустройчивости (Chaos Monkey в Netflix)	5.0	3
23	Релиз по потребности	Метрики	Сравнение фактической ценности развернутой фичи с первичной гипозетой - неотъемлемая часть непрерывной обратной связи. Оцените способность своей команды собирать объективную информацию о ценности развернутого программного продукта для уточнения будущей стратегии. Сидим (1-2): Мы не определяем метрики ценности фичей Ползем (3-4): Мы пониманием и определяем ценность, но не знаем, как ее изменить Идем (5-6): Мы собираем качественную (не количественную) обратную связь от бизнес-подразделений о ценности наших фичей Бежим (7-8): Мы собираем качественную и количественную обратную связь от бизнес-подразделений и из систем мониторинга о ценности наших фичей Летим (9-10): Мы аггрегируем качественную и количественную обратную связь для объективной проверки гипотезы и принятия дальнейшего решение по развитию/остановке бизнес-кейса (эпика), в рамках которого была сделана данная фича	5.0	3
24	Релиз по потребности	Обучение	Обучение - это решение об успехе или неудаче первичной гипотезы ценности, основанное на объективных метриках, оценке бизнесом и клиентом созданного решений. Оцените способность команды принимать стратегические решения на основе эмпирических данных и стремление активно использовать эти инсайты для улучшения результатов. Сидим (1-2): Никогда не проводится пост-релизная оценка фичей Ползем (3-4): Фичи иногда оцениваются на основе субъективной информации Идем (5-6): Гипотезы фичи оцениваются с помощью объективных метрик, но на окончательные решения сильно влияет политика внутри компании Бежим (7-8): Гипотезы фичи оцениваются с помощью объективных метрик; решения о продолжении/остановке разработки эпика принимаются без сожаления Летим (9-10): Непрерывное обучение и эксперименты укоренились в ДНК компании	5.0	3
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100