Текст книги "Ускоряйся! Наука DevOps"

Глава 3
Измерение и изменение культуры

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

МОДЕЛИРОВАНИЕ И ИЗМЕРЕНИЕ КУЛЬТУРЫ

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

Второй уровень организационной культуры – ценности, которые являются более видимыми для членов группы, поскольку эти коллективные ценности и нормы могут обсуждаться и даже оспариваться теми, кто их знает. Ценности являются своего рода объективом, через который члены группы просматривают и интерпретируют отношения, события и действия вокруг них. Ценности также влияют на групповые взаимодействия, устанавливая социальные нормы, которые формируют действия членов группы и обеспечивают контекстуальные правила (Бансал, 2003). Эти правила довольно часто формируют понятие «культура», о которой мы думаем, когда говорим о культуре команды и организации.

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

Основываясь на дискуссиях в кругах DevOps и важности организационной культуры на втором уровне, мы решили выбрать модель, определенную социологом Роном Веструмом. Веструм проводил исследования человеческого фактора в области безопасности систем, особенно в контексте аварий в технологических областях, которые являются весьма сложными и рискованными, таких как авиация и здравоохранение. В 1988 году он разработал типологию организационных культур (Веструм, 2014).

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

● Бюрократические (ориентированные на правила) организации защищают отделы. Те, кто в департаменте, хотят сохранить свою «территорию», настаивают на своих собственных правилах и обычно делают все по правилам – своим правилам.

● Производительные (ориентированные на результат) организации сосредоточены на миссии. Как мы достигаем нашей цели? Все подчинено эффективной работе – тому, что мы должны делать.

Следующая идея Веструма состояла в том, что организационная культура влияет на то, как информация распространяется внутри организации. Веструм приводит три характеристики хорошей информации:

1. Она дает ответы на вопросы, которые востребованы тем, кто их задает.

2. Она своевременна.

3. Она представлена таким образом, что может быть эффективно использована тем, кто ее получает.

Хорошая циркуляция информации имеет решающее значение для безопасной и эффективной работы в условиях высоких темпов и критических последствий, которые свойственны в том числе технологическим организациям. Веструм описывает характеристики организаций, которые подпадают под его три типа, в таблице 3.1.

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

ИЗМЕРЯЯ КУЛЬТУРУ

Для того чтобы измерить культуру организаций, мы используем преимущества того факта, что указанные типы организаций формируют «точки на шкале» – «сплошную Веструма» (Веструм, 2014). Поэтому здесь отлично подходят вопросы по типу шкалы Ликерта. В психометрии шкалу Ликерта используют для оценки восприятия людей, предлагая им оценить, насколько они согласны или не согласны с утверждением. Когда люди отвечают на вопрос по шкале Ликерта, мы присваиваем ответу значение от 1 до 7, где 1 означает «категорически не согласен», а 7 означает «полностью согласен».

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

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

Анализ конструкций

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

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

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

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

● Надежность: проверка того, что утверждения прочитаны и одинаково интерпретированы всеми участниками опроса. Это также называется внутренней последовательностью.

Взятый вместе анализ достоверности (валидности) и надежности подтверждает наши методы и предшествует любому дополнительному анализу для проверки таких отношений, как корреляция или прогноз. Дополнительные сведения о достоверности и надежности см. в Главе 13. Дополнительную информацию о статистических испытаниях, используемых для подтверждения достоверности и надежности, можно найти в Приложении С.

Наше исследование последовательно выявило, что наша конструкция по модели Веструма – индикатор уровня организационной культуры, который определяет приоритет доверия и сотрудничества в команде, – является как достоверной, так и надежной[8]8
  В 2016 году 31 % респондентов были классифицированы как патологические, 48 % – как бюрократические и 21 % – как производительные.


[Закрыть].

Это означает, что вы тоже можете использовать эти вопросы в своих опросах. Чтобы вычислить балл для каждого ответа в опросе, возьмите числовое значение (1–7), соответствующее ответу на каждый вопрос, и вычислите среднее значение по всем вопросам. Затем вы можете выполнить статистический анализ всех ответов в целом.

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

Во-вторых, «производительная культура подчеркивает миссию – акцент, который позволяет вовлеченным людям оставить в стороне свои личные проблемы, а также отраслевые проблемы, которые так очевидны в бюрократических организациях. Миссия первична. И в-третьих, созидательность поощряет равные условия, в которых иерархия играет не такую важную роль» (Веструм, 2014, с. 61).

Мы должны подчеркнуть, что бюрократия – это не обязательно плохо. Как отмечает Марк Шварц в книге The Art of Business Value, цель бюрократии – «обеспечить справедливость путем применения правил к управленческому поведению. Правила будут одинаковыми для всех случаев – так никто не получит преференциального или дискриминационного отношения. Кроме того, правила будут представлять собой лучшие продукты накопленных знаний организации: сформулированные бюрократами, которые являются экспертами в своих областях, правила будут насаждать эффективные структуры и процессы, гарантируя справедливость и устраняя произвол» (Шварц, 2016, с. 56).

Описание Веструмом культуры, ориентированной на правила, пожалуй, лучше всего рассматривать как культуру, в которой следование правилам считается более важным, чем достижение миссии. Мы работали с командами в федеральном правительстве США, которые без натяжки можно назвать производительными. И мы также работали со стартапами, которые были явно патологическими.

ЧТО ПРОГНОЗИРУЕТ ОРГАНИЗАЦИОННАЯ КУЛЬТУРА ВЕСТРУМА

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

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

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

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

Мы предположили, что культура будет предсказывать как эффективность доставки программного обеспечения, так и эффективность организации. Мы также предвидели, что это приведет к более высокому уровню удовлетворенности работой[9]9
  Эти гипотезы основаны на предыдущих исследованиях и существующих теориях и подкреплены нашим собственным опытом и опытом других специалистов в отрасли. Таким образом построены все наши исследовательские гипотезы. Это пример дедуктивно-прогностического исследования, о котором вы можете подробнее прочитать в Главе 12.


[Закрыть]. Обе эти гипотезы оказались верными. Эти взаимосвязи показаны на рис. 3.2.

ПОСЛЕДСТВИЯ ТЕОРИИ ВЕСТРУМА ДЛЯ ТЕХНОЛОГИЧЕСКИХ ОРГАНИЗАЦИЙ

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

Конструкция эффективности доставки

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

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

Google хотела выяснить, есть ли какие-либо факторы, общие для ее наиболее эффективных команд. Они начали двухлетний исследовательский проект, чтобы изучить, что сделало команды Google эффективными, проведя «более 200 интервью… с сотрудниками и [имея перед глазами] более чем 250 характеристик более чем 180 активных команд Google» (Google, 2015). Они ожидали найти сочетание индивидуальных черт и навыков, которые были бы ключевыми компонентами высокоэффективных команд. Вместо этого они обнаружили, что «то, кто находится в команде, имеет меньшее значение, чем то, как члены команды взаимодействуют, структурируют свою работу и оценивают свой вклад» (Google, 2015). Другими словами, все сводится к динамике команды.

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

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

КАК МЫ МЕНЯЕМ КУЛЬТУРУ?

Джон Шук, описывая свой опыт преобразования культуры команд на автомобильном заводе во Фремонте (Калифорния), заводе-основоположнике движения бережливого производства в США, написал: «…мой опыт научил меня, и это было действительно мощно, что изменить культуру – это не сначала изменить то, как люди думают, а вместо этого начать с изменения того, как люди себя ведут и что они делают» (Шук, 2010)[10]10
  История этого преобразования рассказана в эпизоде 561 радиошоу This American Life на радиостанции WBEZ (2015).


[Закрыть].

Таким образом, мы предполагаем, что, следуя теории, разработанной движениями Lean и Agile, внедрение практик этих движений может оказать влияние на культуру. Мы решили рассмотреть как технические, так и управленческие практики, а также оценить их влияние на культуру. Наше исследование демонстрирует, что бережливое управление, как и ряд других технических практик, известных как непрерывная доставка (Хамбл и Фарлей, 2010), действительно влияет на культуру, как показано на рис. 3.3.

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

Глава 4
Технические практики

На момент публикации Манифеста Agile (Agile Manifesto) в 2001 году экстремальное программирование (XP) было одним из самых популярных Agile-фреймворков[11]11
  Согласно Google Trends, Scrum обогнал экстремальное программирование примерно в январе 2006 года, и его популярность продолжала расти, в то время как ХР практически сошло на нет.


[Закрыть].

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

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

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

ЧТО ТАКОЕ НЕПРЕРЫВНАЯ ДОСТАВКА?

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

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

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

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

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

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

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

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

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

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

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

● Непрерывное тестирование. Тестирование – это не то, что мы должны начинать только после того, как функция или релиз получает статус «разработка завершена» (dev complete). Поскольку тестирование жизненно важно, мы должны проводить его все время как неотъемлемую часть процесса разработки. Автоматические модульные и приемочные тесты должны выполняться на стадии каждой фиксации в системе контроля версий, чтобы дать разработчикам быструю обратную связь по их изменениям. Разработчики должны иметь возможность запускать все автоматические тесты на своих рабочих станциях для сортировки и исправления ошибок. Тестировщики должны проводить исследовательское тестирование непрерывно на стадии каждой новой сборки, чтобы выйти из НИ. Никто не должен утверждать, что работа сделана, пока все необходимые автоматические тесты не будут написаны и пройдены.

Реализация непрерывной доставки означает создание многочисленных циклов обратной связи для обеспечения того, чтобы высококачественное программное обеспечение доставлялось пользователям чаще и надежнее[12]12
  Ключевой шаблон, который соединяет эти циклы обратной связи, известен как конвейер развертывания. См. https://continuousdelivery.com/implementing/patterns/


[Закрыть].

При правильной реализации процесс выпуска новых версий для пользователей должен быть рутинной деятельностью, которая может быть выполнена по требованию в любое время. Непрерывная доставка требует, чтобы разработчики и тестировщики, а также специалисты UX[13]13
  User experience (пользовательский опыт) – сфера на стыке дизайна и аналитики, сфокусированная на создании прототипов на основе анализа ощущений пользователей. – Прим. ред.


[Закрыть], менеджеры продуктов и сотрудники техподдержки эффективно сотрудничали на протяжении всего процесса доставки.

ВЛИЯНИЕ НЕПРЕРЫВНОЙ ДОСТАВКИ

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

● использование системы управления версиями для кода приложения, конфигурации системы, конфигурации приложения, а также сценариев сборки и конфигурации;

● комплексную автоматизацию тестирования, надежную, легкую в исправлении ошибок и работающую постоянно;

● автоматизацию развертывания;

● непрерывную интеграцию;

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

● использование магистральной разработки в отличие от долгоживущих функциональных ветвей;

● эффективное управление тестовыми данными.

Большинство из этих возможностей измеряется в виде конструкций с использованием вопросов по шкале Ликерта[14]14
  Значимым исключением является развертывание автоматизации.


[Закрыть]. Например, чтобы измерить возможности контроля версий, мы просим респондентов сообщить, в какой степени они согласны или не согласны со следующими утверждениями.

● Наш код приложения находится в системе контроля версий.

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

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

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

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

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

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

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

● Быстрая обратная связь по качеству и развертываемости системы доступна всем в команде, и люди считают своим высшим приоритетом действия по этой обратной связи.

Наш анализ показал, что исходные возможности, измеренные в 2014–2016 годах, оказали сильное и статистически значимое влияние на эти результаты[15]15
  Из-за ограничений по длине было протестировано только подмножество технических возможностей. См. диаграмму в конце Приложения А.


[Закрыть]. Мы также измерили две новые возможности, которые также оказали сильное и статистически значимое влияние на непрерывную доставку:

● слабосвязанную, хорошо инкапсулированную архитектуру (подробнее это обсуждается в Главе 5);

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

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

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

● сильная идентификация с организацией, в которой они работают (см. Главу 10);

● более высокие уровни эффективности доставки ПО (время выполнения, частота развертывания, время восстановления службы);

● более низкий процент отказов при изменениях;

● производительная, ориентированная на результат культура (см. Главу 3).

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

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

● Меньше «боли развертывания».

● Снижение командного выгорания (см. Главу 9).

ВЛИЯНИЕ НЕПРЕРЫВНОЙ ДОСТАВКИ НА КАЧЕСТВО

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

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