Приложение А

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

Наше исследование выявило 24 ключевые возможности, которые статистически значимым образом влияют на повышение эффективности доставки программного обеспечения. В нашей книге подробно описаны эти открытия. Данное приложение содержит удобный список этих возможностей — каждая с указанием на главу, которая подробно ее рассматривает (также см. рис. A.1).

Мы разделили эти возможности на пять категорий:

• непрерывная доставка;
• архитектура;
• продукт и процесс;
• бережливое управление и мониторинг;
• культура.

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

Возможности непрерывной доставки

1. Используйте контроль версий для всех производственных артефактов. Контроль версий — это использование системы управления версиями, такой как GitHub или Subversion, для всех производственных артефактов, включая код приложения, конфигурации приложений, системные конфигурации и скрипты для автоматизации сборки и настройки среды. См. .
2. Автоматизируйте ваш процесс развертывания. Автоматизация развертывания — это степень, с которой развертывания полностью автоматизированы и не требуют ручного вмешательства. См. .
3. Внедряйте непрерывную интеграцию (НИ). НИ является первым шагом на пути к непрерывной доставке. Это практика разработки, в которой код регулярно проверяется и каждая проверка запускает набор быстрых тестов для обнаружения серьезных сбоев, которые разработчики немедленно исправляют. Процесс НИ создает канонические сборки и пакеты, которые в конечном итоге развертываются и выпускаются. См. .
4. Используйте магистральные методы разработки. Было показано, что магистральная разработка является прогностическим фактором высокой эффективности в разработке и доставке программного обеспечения. Для нее характерны менее трех активных ветвей в репозитории кода, ветви и вилки с очень коротким сроком жизни (например, менее одного дня) до слияния в магистраль и крайне редкие или отсутствующие периоды «кодовой блокировки» у команд приложений, когда никто не может проверить код или выполнить запрос на вытягивание из-за конфликтов слияния, заморозки кода или фаз стабилизации. См. .
5. Внедряйте автоматизацию тестирования. Это практика, при которой тесты программного обеспечения выполняются автоматически (а не вручную) непрерывно на протяжении всего процесса разработки. Эффективные наборы тестов надежны, то есть тесты находят реальные сбои и пропускают только код, готовый к выпуску. Обратите внимание, что разработчики должны нести основную ответственность за создание и обслуживание наборов автоматических тестов. См. .
6. Поддерживайте управление тестовыми данными. Они требуют тщательного обслуживания. Управление тестовыми данными становится все более важной частью автоматизированного тестирования. Эффективные практики включают наличие достаточных данных для запуска набора тестов, возможность получения необходимых данных по требованию, возможность создания условий для тестовых данных в конвейере и данные, не ограничивающие количество тестов, которые вы можете запустить. Однако мы предупреждаем, что команды должны по возможности минимизировать объем тестовых данных, необходимых для выполнения автоматических тестов. См. .
7. «Сдвигайтесь влево» по безопасности. Интеграция безопасности в этапы проектирования и тестирования процесса разработки программного обеспечения является ключом к повышению эффективности ИТ. Это включает в себя проверку безопасности приложений, подключение команды по безопасности (infosec) в процесс разработки и демонстрации приложений, использование предварительно утвержденных библиотек и пакетов безопасности, а также тестирование функций безопасности в составе набора автоматических тестов. См. .
8. Внедряйте непрерывную доставку (НД). НД — это практика разработки, когда программное обеспечение находится в развертываемом состоянии на протяжении всего жизненного цикла и поддержание ПО в развертываемом состоянии для команды приоритетнее, чем работа над новыми функциями. Быстрая обратная связь по качеству и развертываемости системы доступна всем членам команды, и когда они получают отчеты о том, что система не может быть развернута, оперативно исправляют ошибки. Наконец, система может быть развернута в производство или конечным пользователям в любое время по требованию. См. .

Возможности архитектуры

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

10. Создавайте архитектуру для уполномоченных команд. Наше исследование показывает, что команды, которые могут сами выбирать, какие инструменты использовать, лучше справляются с непрерывной доставкой и, в свою очередь, улучшают эффективность разработки и доставки программного обеспечения. Никто лучше специалистов-практиков не знает, что им нужно, чтобы быть эффективными. См. . (Аналог этого подхода в сфере управления продуктом можно найти в .)

Возможности продукта и процесса

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

12. Сделайте рабочий процесс видимым через поток создания ценности. Команды должны обладать хорошим пониманием и видимостью рабочего процесса от бизнеса до клиентов, включая статусы продуктов и функций. Наше исследование показало, что это положительно влияет на эффективность ИТ. См. .

13. Работайте в небольших партиях. Команды должны «нарезать» работу на небольшие куски, которые могут быть завершены в течение недели или меньше. Суть состоит в том, чтобы работа была разделена на небольшие функции, которые можно быстро разработать, вместо того чтобы разрабатывать сложные функции на ветвях и выпускать их нечасто. Эта идея применима как на уровне функции, так и на уровне продукта. (MVP — это прототип продукта с достаточным количеством функций для достоверного изучения продукта и его бизнес-модели.) Работа в небольших партиях позволяет сократить время выполнения заказа и ускорить цикл обратной связи. См. .

14. Поощряйте и создавайте условия для командных экспериментов. Командное экспериментирование — это возможность для разработчиков опробовать новые идеи и создавать и обновлять спецификации в процессе разработки, не требуя одобрения извне команды, что позволяет им быстро внедрять инновации и создавать ценность. Это особенно эффективно в сочетании с работой в небольших партиях, включая обратную связь с клиентами и создание видимого процесса работы. См. Главу 8. (Технический аналог этого можно найти в .)

Возможности бережливого управления и мониторинга

15. Обеспечьте облегченный процесс утверждения изменений. Наше исследование показывает, что облегченный процесс утверждения изменений, основанный на внутренней экспертизе (парном программировании или внутрикомандной проверке кода), обеспечивает более высокую эффективность ИТ, чем использование внешних органов по утверждению изменений (CABs). См. .

16. Проводите мониторинг всех приложений и инфраструктуры для принятия бизнес-решений. Используйте данные из инструментов мониторинга приложений и инфраструктуры для принятия мер и бизнес-решений. Это лучше, чем искать виноватых, когда что-то идет не так. См. .

17. Заранее проверяйте работоспособность системы. Мониторинг работоспособности системы с помощью предупреждений о пороговых значениях и скорости изменения помогает командам заблаговременно обнаруживать и устранять проблемы. См. .

18. Улучшайте процессы и управляйте ограничением незавершенного производства (НЗП). Использование ограничений НЗП для управления процессом работы хорошо известно в «бережливом» сообществе. При эффективном использовании это приводит к улучшению процесса, увеличивает производительность и делает ограничения видимыми в системе. См. .

19. Визуализируйте работу, чтобы контролировать качество и общаться всей командой. Визуальные дисплеи, такие как приборные панели или внутренние веб-сайты, используемые для мониторинга качества и НЗП, способствуют повышению эффективности доставки программного обеспечения. См. .

Культурные возможности

20. Поддерживайте производительную культуру (по Веструму). Эта оценка организационной культуры основана на типологии, разработанной Роном Веструмом, социологом, который изучал критические с точки зрения безопасности сложные системы в области авиации и здравоохранения. Наше исследование показало, что этот показатель культуры предсказывает эффективность ИТ, организационную эффективность и снижение выгорания. Его отличительными чертами являются хороший поток информации, высокий уровень сотрудничества и доверия, наведение мостов между командами и сознательное изучение ошибок. См. .

21. Поощряйте и поддерживайте обучение. Считается ли обучение в вашей культуре необходимым условием для постоянного прогресса? Рассматривается ли обучение как затраты или как инвестиции? Это показатель обучающей культуры организации. См. .

22. Поддерживайте и оказывайте содействие сотрудничеству между командами. Это отражает, насколько хорошо команды, которые традиционно были изолированы, взаимодействуют в области разработки, эксплуатации и информационной безопасности. См. и .

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

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