Читать онлайн Ускоряйся! Наука DevOps бесплатно

Переводчик А. Техненко

Редактор Е. Закомурная

Руководитель проекта М. Пикалова

Дизайн Е. Шестернина

Корректоры Е. Якимова, Е. Тимошкина

Компьютерная верстка Б. Руссо

© 2018 by Nicole Forsgren, Jez Humble, and Gene Kim. Chapter 16 Copyright © 2018 by Karen Whitley Bell and Steve Bell, Lean IT Strategies, LLC.

© Издание на русском языке, перевод, оформление. ООО «Интеллектуальная Литература», 2020.

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

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

* * *

Эта книга – своего рода предвидение, в котором так отчаянно нуждаются генеральные директора, финансовые директора и ИТ-директора компаний, если они собираются выжить в этом новом программно ориентированном мире.

Любой, кто не читает эту книгу, будет заменен тем, кто ее читал.

Томас А. Лимончелли, соавтор книги The Practice of Cloud System Administration

«Вот, сделай это!» Данные, представленные в книге «Ускоряйся! Наука DevOps», являются триумфом исследований, упорства и проницательности, которые доказывают не только зависимость, но и причинно-следственную связь между грамотным техническим и управленческим поведением и эффективностью бизнеса. Они также разоблачают миф о «моделях зрелости» и предлагают реалистичную, действенную альтернативу. Как независимый консультант в сфере, где пересекаются люди, технологии, процессы и организационное проектирование, я могу вам сказать: это манна небесная!

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

Дэн Норт, независимый консультант по технологиям и организации

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

Карен Мартин, автор книг Clarity First и The Outstanding Organization

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

Рин Дэниэлс, инженер по эксплуатации инфраструктуры компании Travis CI, автор книги Effective DevOps

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

«Ускоряйся!» предоставляет научно обоснованные, поддающиеся количественной оценке и реально работающие принципы создания высокопроизводительных ИТ-команд мирового класса, позволяющих достичь удивительных результатов бизнеса.

Поддержанная двумя идейными лидерами сообщества DevOps (Ким и Хамбл) и исследованиями мирового класса от доктора наук (Форсгрен), эта книга настоятельно рекомендуется к прочтению!

Джонатан Флетчер, CTO группы компаний Hiscox

В своей книге «Ускоряйся!» Николь Форсгрен, Джез Хамбл и Джин Ким не разрушают никаких новых концептуальных основ в отношении Agile, Lean и DevOps. Вместо этого они представляют нечто, что может быть еще более ценным, – возможность заглянуть внутрь строгой методологии их подхода к сбору и анализу данных, который привел их к более ранним выводам о ключевых возможностях, увеличивающих вклад ИТ-компаний в бизнес. Я с удовольствием поставлю эту книгу на свою книжную полку рядом с другими великими работами.

Кэмерон Хайт, вице-президент и CTO компании VMware

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

Том и Мэри Поппендайк, авторы серии книг по бережливой разработке ПО (Lean Software Development)

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

Барон Шварц, основатель и CEO компании VividCortex и соавтор книги High Performance MySQL

Книга о том, как быть, а не казаться цифровой организацией

«Ускоряйся!» – говорит вам заголовок этой книги. И если вы рассчитываете устоять в эпоху фундаментальных трансформаций организации и менеджмента, которая наступила на наших глазах, вам придется последовать этому совету. Николь Форсгрен, Джез Хамбл и Джин Ким предлагают для этого несколько практических решений, пусть и не самых простых.

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

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

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

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

Вначале была Big Data, обещавшая решение если не всех, то многих проблем и радикальный рост эффективности. От нас требовалось лишь собрать на порядок больше данных и правильно их обработать. Потом возник интернет вещей. Казалось, если оснастить датчиками всевозможные предметы, это точно сработает. Затем пришла очередь Agile, роботизации, искусственного интеллекта… И наконец, появилась цифровая трансформация.

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

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

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

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

Работа Форсгрен, Хамбл и Ким скрупулезно прослеживает, как связаны технологическая платформа, ее процессы и архитектуры с конкретными параметрами эффективности бизнеса и организации. Мы много слышали о том, что бизнесу пора принимать форму цифровых или ИТ-компаний. Книга «Ускоряйся!» – одна из первых, где показано, как это сделать практически. По сути, это готовый учебник по трансформации. Книга поможет справиться со сложными задачами управления и станет источником аргументов для дискуссий любого уровня – от рядового сотрудника до топ-менеджера и акционера.

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

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

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

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

На мой взгляд, единственный способ преодолеть технологические ограничения сегодняшнего дня – создавать принципиально новые ИТ-платформы. Их основой должны стать достижения цифровой эпохи: передовые архитектуры, революционные технологии, прогрессивные подходы к управлению. Я уверен, что книга «Ускоряйся!» будет полезна каждому, кто твердо решил встать на путь к свободе цифрового развития.

Сергей Мацоцкий,основатель и член совета директоров IBS

Предисловие Мартина Фаулера

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

Вместо этого я отправил Джезу письмо по электронной почте, чтобы узнать, что стоит за этим заявлением. Несколько недель спустя я созвонился с ним и Николь Форсгрен, которая терпеливо ввела меня в курс дела. Хотя я не эксперт по методам, которые они использовали, она сказала достаточно, чтобы убедить меня, что здесь речь идет о реальном анализе, гораздо большем, чем я обычно вижу даже в научных работах. Я следил за последующими отчетами о состоянии DevOps с интересом, но и с растущим разочарованием. Отчеты представляли результаты их работы, но никогда не содержали тех подробных объяснений, которые Николь дала мне во время телефонного разговора. Это сильно подорвало к ним доверие, поскольку было мало доказательств того, что эти отчеты основаны на чем-то большем, чем просто гипотезы. Наконец, те из нас, кто уже «побывал за кулисами», убедили Николь, Джеза и Джина раскрыть свои методы, написав эту книгу. Для меня это было долгое ожидание, но теперь я рад, что у меня есть то, что я могу искренне рекомендовать как способ взглянуть на эффективность доставки ИТ-решений, основанный на чем-то большем, чем разрозненный опыт нескольких аналитиков.

Картина, которую они нарисовали в своей книге, просто неотразима. Они описывают, как компаниям с эффективными ИТ-доставками требуется около часа, чтобы довести код от «сохранения в магистраль» (committed to mainline) до «запуска в производство», – путь, который в некоторых организациях занимает месяцы. Таким образом они обновляют свое программное обеспечение много раз в день, а не один раз в несколько месяцев, увеличивая свою способность использовать программное обеспечение для изучения рынка, реагирования на события и выпуска новых функций быстрее, чем конкуренты. Такое огромное увеличение быстродействия не связано с затратами на стабильность, так как эти организации обнаруживают, что их обновления вызывают сбои, быстрее их менее эффективных коллег и эти сбои обычно фиксируются в течение часа. Их доказательства опровергают бимодальное представление о том, что вам нужно выбирать между скоростью и стабильностью, – напротив, скорость зависит от стабильности, поэтому хорошие ИТ-практики дают вам и то и другое.

Итак, как вы можете представить, я в восторге, что они запустили эту книгу в производство, и волей-неволей я буду рекомендовать ее в течение следующих нескольких лет. (Я уже использовал много битов из черновиков этой книги в своих выступлениях.) Тем не менее я хочу внести несколько предостережений. Авторы книги хорошо объясняют, почему их подход к опросам делает их прочной основой для их данных. Однако это все еще опросы, которые отражают субъективное восприятие. И мне интересно, как представленная ими выборка отражает ИТ-мир в целом. У меня будет больше уверенности в их результатах, когда другие команды, используя разные подходы, смогут подтвердить рассуждения авторов. В книге уже есть некоторые из таких подтверждений. Так, работа, проделанная Google по формированию командной культуры, дает дополнительные доказательства в поддержку суждения авторов о том, насколько важна организационная культура, основанная на модели Веструма, для эффективных команд, занятых разработкой ПО. Подобная дальнейшая работа также заставила бы меня меньше беспокоиться о том, чтобы их выводы подтверждали большую часть моих доводов при их отстаивании – подтверждение предвзятости является мощной силой (хотя я в основном замечаю это в других;-)). Мы также должны помнить, что их книга фокусируется на доставке программных продуктов, то есть на пути от коммита[1] к запуску в производство, а не на всем процессе разработки программного обеспечения.

Но эти придирки не должны отвлекать нас от основного направления этой книги. Эти исследования и их тщательный анализ дают одно из лучших объяснений методов, которые могут значительно продвинуть вперед большинство ИТ-компаний. Каждый руководитель ИТ-группы должен внимательно изучить эти методы и работать над их использованием для улучшения своей деятельности. Любой, кто работает с ИТ-группой – либо внутри компании, либо из компании, которая занимается доставками ИТ (такой как наша), – должен искать возможности применить эти практики на месте и выработать устойчивую программу непрерывного совершенствования, чтобы развиваться вместе с ними. Форсгрен, Хамбл и Ким нарисовали картину того, как эффективно ИТ выглядит в 2017 году, и практикующие специалисты в сфере ИТ должны использовать ее как карту, чтобы присоединиться к высокоэффективным лидерам.

Мартин Фаулер, главный научный сотрудник компании ThoughtWorks

Предисловие Кортни Кисслер

Мой путь начался летом 2011 года. Я работала в Nordstrom, и мы приняли стратегическое решение сосредоточиться на цифровом секторе как двигателе роста. К этому моменту наша ИТ-компания прошла через оптимизацию расходов. В своей презентации на DevOps Enterprise Summit 2014 я поделилась информацией о том, что для меня одним из моментов прозрения был переход к оптимизации скорости. Я сделала много ошибок на этом пути, и хотела бы я тогда иметь доступ к этой книге и изложенной в ней информации. Я наступила на все классические грабли. Например, в попытке взять и внедрить Agile сверху вниз, думая, что он подходит всем, не фокусируясь на измерениях (или правильных параметрах измерений). При этом лидерское поведение не меняется и рассматривает трансформацию как программу вместо создания обучающейся организации (чего никогда не делалось).

На протяжении всего пути мы фокусировались на командных структурах, основанных на результатах: мы знали наше время цикла (понимали нашу карту ценностей), ограничивали «радиус взрыва» (начинали с 1–2 команд вместо того, чтобы пытаться «вскипятить океан»), использовали данные для управления действиями и решениями и признавали, что работа – это работа (цель – отсутствие недоработок и отставаний по функционалу, техническому обеспечению и операционной работе; вместо этого иметь только одно отставание, потому что NFRs (Nonfunctional Requirements – нефункциональные требования. – Прим. ред.) тоже являются функциями, а сокращение технических недоработок повышает стабильность продукта). Ничто из этого не было достигнуто в одночасье, а процесс потребовал множества экспериментов и корректировок.

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

Несмотря на то, что путь будет нелегким, я могу сказать, что он определенно того стоит, и вы не только увидите результаты, но и ваша команда станет счастливее. Например, когда мы начали измерять eNPS (employee Net Promoter Score – индекс чистой лояльности сотрудников. – Прим. ред.), команды, практикующие эти методы, получили самые высокие баллы во всей нашей технологической организации.

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

Вы столкнетесь со скептиками на этом пути. Я слышала такие вещи, как «DevOps – это новый Agile», «Lean не применяется к доставке программного обеспечения», «Конечно, это сработало для команды мобильных приложений. Они – единорог». Когда я столкнулась со скептиками, я попыталась использовать внешние примеры, чтобы повлиять на обсуждение. Я опиралась на поддержку наставников – без них мне было бы сложно сосредоточиться. Наличие информации из этой книги было бы мне тогда чрезвычайно полезно, и я настоятельно рекомендую вам использовать ее в своей организации. Я провела большую часть своей карьеры в розничной торговле, и в этой отрасли все более и более важной становилась способность меняться, а программное обеспечение для доставки теперь является частью ДНК каждой организации. Не игнорируйте науку, изложенную в этой книге. Она поможет вам ускорить ваше превращение в высокоэффективную технологическую организацию.

Кортни Кисслер, вице-президент по разработке цифровых платформ компании Nike

Краткая справка: Возможности управления оптимизацией

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

Они подразделяются на пять категорий:

● непрерывная доставка;

● архитектура;

● продукт и процесс;

● бережливое управление и мониторинг;

● культурные возможности.

ВОЗМОЖНОСТИ НЕПРЕРЫВНОЙ ДОСТАВКИ

1. Контроль версий: Глава 4.

2. Автоматизация развертывания: Глава 4.

3. Непрерывная интеграция: Глава 4.

4. Магистральная разработка: Глава 4.

5. Автоматизация тестирования: Глава 4.

6. Управление тестовыми данными: Глава 4.

7. «Сдвиг влево»[2] по безопасности: Глава 6.

8. Непрерывная доставка (НД): Глава 4.

ВОЗМОЖНОСТИ АРХИТЕКТУРЫ

9. Слабосвязанная архитектура: Глава 5.

10. Уполномоченные команды: Глава 5.

ВОЗМОЖНОСТИ ПРОДУКТА И ПРОЦЕССА

11. Обратная связь от клиентов: Глава 8.

12. Поток создания ценности: Глава 8.

13. Работа небольшими партиями: Глава 8.

14. Командные эксперименты: Глава 8.

ВОЗМОЖНОСТИ БЕРЕЖЛИВОГО УПРАВЛЕНИЯ И МОНИТОРИНГА

15. Процесс утверждения изменений: Глава 7.

16. Мониторинг: Глава 7.

17. Упреждающее уведомление: Глава 13.

18. Пределы НЗП (незавершенного производства): Глава 7.

19. Визуализация: Глава 7.

КУЛЬТУРНЫЕ ВОЗМОЖНОСТИ

20. Организационная культура Веструма: Глава 3.

21. Поддерживающее обучение: Глава 10.

22. Взаимодействие между командами: Главы 3 и 5.

23. Удовлетворенность работой: Глава 10.

24. Трансформационное лидерство: Глава 11.

Вступление

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

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

Для проведения исследований, представленных в этой книге (в дополнение к тем, над которыми мы работаем до сих пор), мы используем перекрестные межгрупповые исследования. Те же методы используются в медицинских исследованиях (например, для изучения взаимосвязи между потреблением пива и ожирением, Бобак и соавторы, 2003), исследованиях рабочей среды (например, для изучения взаимосвязи между рабочей средой и сердечно-сосудистыми заболеваниями, Джонсон и Холл, 1988) и исследованиях памяти (например, для изучения различий в процессах развития и снижения памяти, Алловэй и Алловэй, 2013). Поскольку мы хотим по-настоящему изучить отрасль и понять, что приводит к значительному улучшению программного обеспечения и организационной эффективности, мы используем строгие методы построения научных исследований и публикуем большую часть нашей работы в академических журналах. Дополнительную информацию о методах нашего исследования вы найдете в Части II «Исследование».

ИССЛЕДОВАНИЕ

В рамках исследования мы собрали по нашим опросникам более 23 000 ответов со всего мира. Мы получили обратную связь от более чем 2000 уникальных организаций, от небольших стартапов с количеством сотрудников до пяти человек до крупных предприятий со штатом более 10 000 человек. Мы собрали данные от маленьких стартапов и передовых интернет-компаний, а также организаций, работающих в строго регулируемых отраслях, таких как финансы, здравоохранение и государственные структуры. Наши данные и анализ включают программное обеспечение, разработанное на совершенно новых платформах, так называемых greenfield («зеленое поле» – проекты, созданные с нуля. – Прим. ред.), а также обслуживание и разработку существующего кода ПО.

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

Улучшение возможно для всех

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

Цель этой книги – поделиться тем, что мы узнали, чтобы помочь организациям преуспевать, вырастить более счастливые команды, которые быстрее доставляют лучшее программное обеспечение, и помочь процветанию организаций и отдельных людей. Остальная часть этого вступления кратко описывает, как началось и как проводилось это исследование. Более подробно о его научной основе вы прочтете в Части II этой книги.

ПРОДЕЛАННАЯ РАБОТА И ДАННЫЕ

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

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

● Джез Хамбл – соавтор книг «Непрерывная доставка» (Continuous Delivery), «Бережливое предприятие» (Lean Enterprise) и «Руководство по DevOps» (The DevOps Handbook). Его первой работой после колледжа был стартап в Лондоне в 2000 году, а затем в 2005–2015 годах он провел десять лет в компании ThoughtWorks, занимаясь доставкой программных продуктов и консультируя клиентов в качестве специалиста по инфраструктуре, разработчика и продукт-менеджера.

● Джин Ким изучает высокоэффективные технологические организации с 1999 года. Он был основателем и техническим директором компании Tripwire в течение 13 лет и является соавтором многих книг, включая «Проект Феникс» (The Phoenix Project) и «Руководство по Visible Ops» (The Visible Ops Handbook).

В конце 2013 года Николь, Джез и Джин начали работать вместе с командой компании Puppet Inc. в рамках подготовки «Отчета о состоянии DevOps 2014 года»[3]. Объединив практический опыт и академическую строгость, команда смогла создать нечто уникальное в отрасли: отчет, содержащий информацию о том, как сделать так, чтобы технологии создавали ценность для сотрудников, организаций и клиентов прогнозируемыми способами. В течение следующих четырех отчетов Николь, Джез и Джин продолжали сотрудничать с командой Puppet Inc., чтобы повторно применять методологию данного исследования и постоянно улучшать отраслевое понимание того, что способствует отличной доставке программного обеспечения, позволяет создать выдающиеся технические команды и как компании могут стать высокоэффективными организациями и выигрывать на рынке, используя технологии. Эта книга охватывает четыре года исследований, начиная с отчета (с 2014 по 2017 год).

Чтобы собрать данные, каждый год мы отправляли приглашения по нашим спискам рассылки и использовали социальные сети, включая Twitter, LinkedIn и Facebook. Наши приглашения были адресованы техническим специалистам, особенно тем, кто знаком с парадигмами разработки и доставки ПО, а также с DevOps. Мы призывали наших читателей приглашать друзей и коллег, которые тоже могли быть заняты в области разработки и доставки программного обеспечения, чтобы помочь нам расширить охват аудитории. Это называется «выборка по методу снежного кома», и мы поговорим о том, почему это был подходящий метод сбора данных для этого исследовательского проекта, в Главе 15 «Данные для проекта».

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

А вот краткий обзор исследования и того, как оно развивалось на протяжении нескольких лет.

2014 ГОД: ЗАКЛАДЫВАЯ ОСНОВЫ. ЭФФЕКТИВНОСТЬ ДОСТАВКИ ПО И ОРГАНИЗАЦИОННАЯ ЭФФЕКТИВНОСТЬ

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

● Что значит доставка программного обеспечения и можно ли ее измерить?

● Влияет ли доставка ПО на организации?

● Имеет ли значение культура и как мы ее измеряем?

● Какие технические практики представляются важными?

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

Группа также пересмотрела способ измерения большинства данных, перейдя от простых вопросов «да/нет» к вопросам по шкале Ликерта (в которых респонденты выбирают из спектра вариантов от «категорически не согласен» до «полностью согласен»). Это простое изменение в вопросах позволило команде собрать больше нюансов – оттенки серого вместо черно-белого. Это позволило провести более детальный анализ. Почему авторы решили использовать опросы для этого исследовательского проекта и почему вы можете доверять их данным, мы обсудим в Главе 14 «Зачем использовать опрос».

2015 ГОД: РАСШИРЕНИЕ РАБОТЫ И УГЛУБЛЕНИЕ АНАЛИЗА

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

Ниже представлены некоторые из вопросов исследования.

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

● Влияют ли технические методы и автоматизация на доставку программного обеспечения?

● Влияют ли методы бережливого управления на доставку программного обеспечения?

● Влияют ли технические методы и методы бережливого управления на те аспекты работы, которые оказывают воздействие на человеческие ресурсы, например, беспокойство, связанное с развертыванием кода и профессиональным выгоранием сотрудников?

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

2016 ГОД: РАСШИРЕНИЕ НАШЕГО ВЗГЛЯДА НА ТЕХНИЧЕСКИЕ МЕТОДЫ И ИЗУЧЕНИЕ НЕЧЕТКОГО ВНЕШНЕГО ИНТЕРФЕЙСА

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

Ниже представлены вопросы нашего исследования.

● Помогает ли интеграция безопасности в разработку и доставку программного обеспечения этому процессу или замедляет его?

● Способствует ли магистральная разработка улучшению доставки программного обеспечения?

● Является ли бережливый подход к управлению продуктами важным аспектом разработки и доставки программного обеспечения?

● Способствуют ли хорошие технические практики повышению лояльности сотрудников?

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

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

Ключевые вопросы четвертого года нашего исследования.

● Какие архитектурные практики способствуют повышению эффективности доставки программного обеспечения?

● Как трансформационное лидерство влияет на доставку программного обеспечения?

● Влияет ли доставка программного обеспечения на некоммерческие результаты?

ВЫВОД

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

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