Глава 4

Технические практики

На момент публикации Манифеста Agile (Agile Manifesto) в 2001 году экстремальное программирование (XP) было одним из самых популярных Agile-фреймворков.

В отличие от Scrum XP предписывает ряд технических практик, таких как разработка на основе тестирования и непрерывная интеграция. Непрерывная доставка (Хамбл и Фарлей, 2010) также подчеркивает важность этих технических практик (в сочетании с комплексным управлением конфигурацией) как средства обеспечения более частых, более качественных и менее рискованных выпусков программного обеспечения.

Во многих внедрениях в рамках подхода Agile технические практики рассматриваются как второстепенные по сравнению с управленческими и командными, на которых делают акцент некоторые Agile-концепции. Наше исследование показывает, что техническая практика играет жизненно важную роль в достижении этих результатов.

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

Что такое непрерывная доставка?

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

• Качество сборки. Третий из 14 пунктов Эдвардса Деминга для управления гласит: «Прекратите зависимость от экспертизы для достижения качества. Устраните необходимость проведения экспертизы на массовой основе, поставив на первое место повышение качества продукта» (Деминг, 2000). При непрерывной доставке мы инвестируем в создание культуры, поддерживаемой инструментами и людьми, в которой мы можем быстро обнаружить любые проблемы и устранить их, когда это еще обходится дешево.
• Работа небольшими партиями. Организации, как правило, планируют работу большими частями — будь то создание новых продуктов или услуг или инвестиции в организационные изменения. Разделяя работу на гораздо меньшие части, которые быстро обеспечивают измеримые результаты бизнеса для небольшой части нашего целевого рынка, мы получаем существенную обратную связь о работе, которую мы делаем, чтобы мы могли исправить курс. Даже при том, что работа в небольших партиях добавляет некоторые накладные расходы, она приносит огромные выгоды, позволяя нам избегать работы с нулевой или отрицательной ценностью для наших организаций.

  Ключевой целью непрерывной доставки является изменение экономики процесса доставки ПО, поэтому стоимость выпуска отдельных изменений очень низка.

• Компьютеры выполняют повторяющиеся задачи; люди решают проблемы. Одна из важных стратегий снижения затрат на выпуск изменений заключается в инвестировании в упрощение и автоматизацию повторяющейся работы, которая занимает много времени, такой как регрессионное тестирование и развертывание ПО. Таким образом мы освобождаем людей для более ценной работы по решению таких задач, как улучшение структуры наших систем и процессов в ответ на обратную связь.
• Неустанно проводить постоянные улучшения. Наиболее важной характеристикой высокоэффективных команд является то, что они никогда не бывают удовлетворены: они всегда стремятся стать лучше. В компаниях-лидерах улучшение является частью ежедневной работы каждого сотрудника.
• Каждый несет ответственность. Как мы узнали от Рона Веструма, в бюрократических организациях команды, как правило, сосредоточены на целях своего подразделения, а не на организационных целях. Таким образом, разработка фокусируется на пропускной способности, тестировании качества и операциях по обеспечению стабильности. Однако на самом деле все это результаты системного уровня и они могут быть достигнуты только при тесном сотрудничестве между всеми участниками процесса доставки программного обеспечения.

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

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

• Комплексное управление конфигурацией. Должна быть возможность обеспечить среду разработки и создавать, тестировать и развертывать наше программное обеспечение полностью автоматизированным способом исключительно из информации, хранящейся в системе управления версиями. Любые изменения в среде или программном обеспечении, которое на ней работает, должны применяться с использованием автоматизированного процесса из системы управления версиями. Это все еще оставляет место для ручных утверждений концепций, но, как только они утверждены, все изменения должны применяться автоматически.
• Непрерывная интеграция (НИ). Многие команды разработчиков программного обеспечения используются для разработки функций в ветках в течение нескольких дней или даже недель. Интеграция всех этих ветвей требует значительного времени и доработки. Следуя нашему принципу работы небольшими партиями и построения внутреннего качества продукта, высокоэффективные команды сохраняют короткие ветви (менее одного дня работы) и часто интегрируют их в магистраль. Каждое изменение запускает процесс сборки, который включает выполнение модульных тестов. Если в какой-либо части этого процесса происходит сбой, разработчики немедленно исправляют его.
• Непрерывное тестирование. Тестирование — это не то, что мы должны начинать только после того, как функция или релиз получает статус «разработка завершена» (dev complete). Поскольку тестирование жизненно важно, мы должны проводить его все время как неотъемлемую часть процесса разработки. Автоматические модульные и приемочные тесты должны выполняться на стадии каждой фиксации в системе контроля версий, чтобы дать разработчикам быструю обратную связь по их изменениям. Разработчики должны иметь возможность запускать все автоматические тесты на своих рабочих станциях для сортировки и исправления ошибок. Тестировщики должны проводить исследовательское тестирование непрерывно на стадии каждой новой сборки, чтобы выйти из НИ. Никто не должен утверждать, что работа сделана, пока все необходимые автоматические тесты не будут написаны и пройдены.

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

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

Влияние непрерывной доставки

В первых нескольких итерациях нашего исследования 2014–2016 годов мы смоделировали и измерили следующие возможности:

• использование системы управления версиями для кода приложения, конфигурации системы, конфигурации приложения, а также сценариев сборки и конфигурации;
• комплексную автоматизацию тестирования, надежную, легкую в исправлении ошибок и работающую постоянно;
• автоматизацию развертывания;
• непрерывную интеграцию;
• «сдвиг влево» по безопасности: включение групп безопасности и самой безопасности в процесс доставки программного обеспечения, а не в качестве нисходящей фазы;
• использование магистральной разработки в отличие от долгоживущих функциональных ветвей;
• эффективное управление тестовыми данными.

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

• Наш код приложения находится в системе контроля версий.
• Наши системные конфигурации находятся в системе контроля версий.
• Наши конфигурации приложений находятся в системе контроля версий.
• Наши скрипты для автоматизации сборки и конфигурации находятся в системе контроля версий.

Затем мы используем статистический анализ, чтобы определить, в какой степени эти возможности влияют на результаты, которые нам важны. Как и ожидалось, в совокупности эти возможности оказывают сильное положительное влияние на эффективность доставки программного обеспечения. (Ниже в этой главе мы обсудим некоторые нюансы реализации этих практик.) Однако они также имеют и другие существенные преимущества: они помогают уменьшить «боль развертывания» и выгорание команды. Хотя мы слышали в организациях, с которыми мы работаем, интересные подтверждения преимуществ качества работы в течение многих лет, увидеть доказательства в данных было фантастическим. И это важно: мы ожидаем этого, потому что, когда команды практикуют непрерывную доставку (НД), развертывание в производство не является грандиозным событием уровня Большого взрыва — это то, что можно сделать в обычные рабочие часы в рамках стандартной повседневной работы. (Мы рассмотрим здоровье команды более подробно в Главе 9.) Интересно, что команды, хорошо справлявшиеся с непрерывной доставкой, сильнее идентифицировали себя с организацией, в которой они работали, — а это ключевой прогностический фактор организационной эффективности, который мы обсуждаем в Главе 10.

Как обсуждалось в Главе 3, мы предположили, что реализация НД повлияет на организационную культуру. Наш анализ показывает, что это действительно так. Если вы хотите улучшить свою культуру, вам поможет применение методов НД. Предоставляя разработчикам инструменты для обнаружения возникающих проблем, время и ресурсы для инвестирования в их развитие, а также полномочия для немедленного устранения проблем, мы создаем среду, в которой разработчики принимают ответственность за глобальные результаты, такие как качество и стабильность. Это оказывает положительное влияние на групповые взаимодействия и деятельность организационной среды и культуры членов команды.

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

• Команды могут делать развертывание в производство (или конечным пользователям) по требованию на протяжении всего жизненного цикла доставки программного обеспечения.
• Быстрая обратная связь по качеству и развертываемости системы доступна всем в команде, и люди считают своим высшим приоритетом действия по этой обратной связи.

Наш анализ показал, что исходные возможности, измеренные в 2014–2016 годах, оказали сильное и статистически значимое влияние на эти результаты. Мы также измерили две новые возможности, которые также оказали сильное и статистически значимое влияние на непрерывную доставку:

• слабосвязанную, хорошо инкапсулированную архитектуру (подробнее это обсуждается в Главе 5);
• команды, которые могут выбрать свои собственные инструменты на основе того, что лучше для пользователей этих инструментов.

Мы покажем эту взаимосвязь на рис. 4.1.

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

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

Эти взаимосвязи показаны на рис. 4.2.

Более того, наше исследование показало, что улучшения в НД принесли плюсы в том, как люди чувствовали себя на работе. Это означает, что инвестиции в технологии также являются инвестициями в людей и эти инвестиции сделают наш технологический процесс более устойчивым (рис. 4.3). Таким образом, НД помогает нам достичь одного из двенадцати принципов Манифеста Agile: «Процессы Agile способствуют устойчивому развитию. Организаторы, разработчики и пользователи должны иметь возможность поддерживать постоянство темпа бесконечно» (Бек и соавторы, 2001).

• Меньше «боли развертывания».
• Снижение командного выгорания ().

Влияние непрерывной доставки на качество

Важнейший вопрос, который мы хотели бы решить: повышает ли непрерывная доставка качество? Для того чтобы ответить на этот вопрос, мы сначала должны найти способ измерения качества. Это сложно, потому что качество очень контекстуально и субъективно. Как говорит эксперт по качеству ПО Джерри Вайнберг, «качество — это ценность для какого-то человека» (Вайнберг, 1992, с. 7).

Мы уже знаем, что непрерывная доставка предсказывает более низкий процент сбоев при изменениях, что является важным показателем качества. Тем не менее мы также протестировали несколько дополнительных косвенных переменных для оценки качества:

• качество и производительность приложений — как они воспринимаются теми, кто работает над ними;
• процент времени, затраченного на доработку или незапланированную работу;
• процент времени, затраченного на работу с ошибками, выявленными конечными пользователями.

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

Участники с высокими показателями сообщили, что тратят 49% времени на новую работу и 21% на незапланированную работу или доработку. Напротив, участники с низкими показателями тратят 38% своего времени на новую работу и 27% на незапланированную работу или доработку.

Незапланированная работа и доработка являются полезными индикаторами качества, потому что они представляют собой неспособность встроить качество в наши продукты. В книге The Visible Ops Handbook незапланированная работа описана как разница между тем, как если «обратить внимание на сигнал низкого уровня топлива в автомобиле или остаться без топлива на шоссе» (Бер и соавторы, 2004). В первом случае организация может устранить проблему плановым образом, без особой срочности или нарушения других запланированных работ. Во втором случае они вынуждены решать проблему в очень срочном порядке, часто задействуя все ресурсы, — представьте, что шесть инженеров должны бросить все и бежать по шоссе с полными газовыми баллонами, чтобы заправить застрявший грузовик.

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

Практика непрерывной доставки: что работает, а что нет

В нашем исследовании мы обнаружили девять ключевых возможностей, которые управляют непрерывной доставкой. Они перечислены ранее в этой главе. Некоторые из этих возможностей имеют интересные нюансы, которые мы обсудим в этом разделе — за исключением архитектуры и выбора инструментов, которые заслуживают отдельной главы (Глава 5). Непрерывная интеграция и автоматизация развертывания не рассматриваются далее в этой главе.

Контроль версий

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

Автоматизация тестирования

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

• Наличие надежных автоматических тестов: при их выполнении команды уверены, что их программное обеспечение готово к релизу. Кроме того, они уверены, что провалы тестов указывают на реальную ошибку. Слишком много тестовых наборов являются слоеными и ненадежными, производя ложные положительные и отрицательные результаты, поэтому имеет смысл инвестировать постоянные усилия в один надежный набор. Один из способов добиться этого — поместить ненадежные автоматические тесты в отдельный набор «на карантине», который выполняется независимо. Или, конечно, вы можете просто удалить их. Если они управляются версиями (как и должно быть), вы всегда можете их вернуть.
• Разработчики в основном создают и поддерживают приемочные тесты, и они могут легко воспроизводить и фиксировать их на своих рабочих станциях разработки. Интересно отметить, что наличие автоматических тестов, созданных и поддерживаемых главным образом командой обеспечения качества (QA — quality assurance) или аутсорсинговой стороной, не коррелирует с ИТ-эффективностью. Теория, лежащая в основе этого, заключается в том, что когда разработчики участвуют в создании и поддержании приемочных тестов, возникает два важных следствия. Во-первых, код становится проще тестировать, когда разработчики пишут тесты. Это одна из основных причин, почему разработка на основе тестирования (TDD — test-driven development) является важной практикой: она заставляет разработчиков создавать проекты, которые легче поддаются тестированию. Во-вторых, когда разработчики отвечают за автоматические тесты, они больше заботятся о них и будут вкладывать больше усилий в их поддержание и исправление.

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

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

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

Управление тестовыми данными

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

Магистральная разработка

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

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

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

Информационная безопасность

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

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

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

Таким образом, критическим препятствием для реализации непрерывной доставки является архитектура предприятия и самого приложения. Результаты нашего исследования этой важной темы мы обсудим в Главе 5.