Ускоряйся! Наука DevOps

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

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

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

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

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

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

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

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

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

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

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

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

Но эти придирки не должны отвлекать нас от основного направления этой книги. Эти исследования и их тщательный анализ дают одно из лучших объяснений методов, которые могут значительно продвинуть вперед большинство ИТ-компаний. Каждый руководитель ИТ-группы должен внимательно изучить эти методы и работать над их использованием для улучшения своей деятельности. Любой, кто работает с ИТ-группой – либо внутри компании, либо из компании, которая занимается доставками ИТ (такой как наша), – должен искать возможности применить эти практики на месте и выработать устойчивую программу непрерывного совершенствования, чтобы развиваться вместе с ними. Форсгрен, Хамбл и Ким нарисовали картину того, как эффективно ИТ выглядит в 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 - Shift Left – устойчивый термин, обычно означающий привлечение команды тестировщиков на ранней стадии разработки ПО. Здесь и далее – встраивание информационной безопасности в процессы разработки и доставки ПО вместо выделения ее в отдельную фазу. – Прим. ред.] по безопасности: Глава 6.

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

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

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

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

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

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

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

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

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

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

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