Текст книги "Ускоряйся! Наука DevOps. Как создавать и масштабировать высокопроизводительные цифровые организации. Николь Форсгрен, Джез Хамбл, Джин Ким. Саммари"

Ускоряйся! Наука DevOps. Как создавать и масштабировать высокопроизводительные цифровые организации. Николь Форсгрен, Джез Хамбл, Джин Ким. Саммари

Оригинальное название:

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

Авторы:

Nicole Forsgren, Jez Humble, Gene Kim

www.smartreading.ru

Скорость решает все

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

Чтобы преуспевать на рынке сегодня, организации должны ускориться:

▶ в доставке товаров и услуг;

▶ во взаимодействии с рынком для выявления и понимания потребительского спроса;

▶ в соблюдении требований законодательства;

▶ в реакции на потенциальные риски, такие как угрозы безопасности или экономические изменения.

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

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

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

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

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

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

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


[Закрыть], и они способны трансформировать и уже трансформируют различные отрасли. Авторы делают акцент не на разработке программного обеспечения (о ней уже написано достаточно книг), а на доставке ПО, которая представляет собой путь от коммита[2]2
  Коммит (от англ. commit) – сохранение, фиксация изменений в программном коде.


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

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

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

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

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

▶ Автоматизация. Компьютеры выполняют повторяющиеся задачи, а люди решают проблемы. Инвестируя в упрощение и автоматизацию повторяющейся работы, которая занимает много времени (например регрессионное тестирование и развертывание ПО), можно снизить затраты и освободить людей для более ценной работы, например по улучшению структуры систем и процессов в ответ на обратную связь.

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

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

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

Вот несколько способов улучшить доставку в вашей организации:

▶ Внедряйте непрерывную доставку. При НД система может быть развернута в производство или конечным пользователям в любое время.

▶ Используйте контроль версий для всех артефактов проекта. Контроль версий – это использование системы управления версиями, такой как Git или Subversion, для всех артефактов[3]3
  Артефакты проекта – информация, с помощью которой команда и заинтересованные стороны описывают деятельность в рамках проекта и разрабатываемый продукт.


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

▶ Автоматизируйте процесс развертывания ПО. Сложные, долгие развертывания[4]4
  Развертывание ПО – это один из этапов доставки ПО, включающий набор действий по подготовке программы к использованию.


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

▶ Внедряйте непрерывную интеграцию (НИ, CI–Continuous Integration). НИ – первый шаг на пути к непрерывной доставке. Код регулярно обновляется и тестируется на отсутствие сбоев и соответствие ожиданиям заказчика ПО после изменения разработчиком. Если в процессе обнаруживаются ошибки, разработчики их сразу исправляют. Процесс НИ создает канонические сборки и пакеты, которые в итоге развертываются и выпускаются.

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

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

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

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

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

Тьяго Алмейда – старший инженер по разработке программного обеспечения в Microsoft.Он занимается облачными вычислениями, открытым исходным кодом и DevOps-практиками в команде облачной платформы Azure. Вот что он говорит о преимуществах непрерывной доставки для своей команды: «Возможно, вы думаете, что все преимущества от нее получают только ваши клиенты, но на самом деле непрерывная доставка выгодна в первую очередь для вас». Перед внедрением методов непрерывной доставки в команде Bing инженеры говорили, что показатель удовлетворенности балансом работа/жизнь составляет всего 38 %. После внедрения этих методов он подскочил до 75 %. Разница поразительна: технические специалисты стали лучше справляться со своими обязанностями в рабочее время. Им не приходилось выполнять процессы развертывания вручную, поэтому они были в состоянии выдерживать рабочее напряжение.

Архитектура

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

▶ тестируемость – возможность выполнить большую часть тестирования без интегрированной среды;

▶ развертываемость – возможность делать развертывание или выпуск приложения независимо от других приложений/ сервисов.

Для достижения этих характеристик системы разработки должны быть слабо связаны, то есть иметь возможность меняться и тестироваться независимо друг от друга.

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

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

▶ вносить масштабные изменения в разработку своей системы без разрешения кого-либо вне команды;

▶ вносить масштабные изменения в разработку своей системы независимо от того, сделали это другие команды или нет;

▶ завершить свою работу без коммуникации и согласований с людьми за пределами команды;

▶ осуществить развертывание и выпуск продукта или услуги по требованию независимо от других сервисов;

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

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

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

Вот решения, связанные с архитектурой, способные ускорить доставку ПО:

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

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

Бережливое производство

Agile выиграл все методологические войны и, кажется, распространился по всему миру, проник во все отрасли. Однако большинство компаний внедряют Agile формально – следуют некоторым общим практикам, не затрагивая организационную культуру и процессы.[5]5
  Читайте саммари книги Марка Лейтона и Стива Остермиллера «Просто об Agile».


[Закрыть]

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

Авторы книги «Ускоряйся!» используют подход, подобный тому, который описан Эриком Рисом в книге о методе Lean Startup. Подход Lean предполагает создание прототипов и их проверку, работу небольшими партиями, сбор обратной связи и частое изменение создаваемых ПО и бизнес-моделей на ранней стадии.[6]6
  Читайте саммари книги Эрика Риса «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели».


[Закрыть]

Возможности эффективного продакт-менеджмента

Приведенные ниже советы по продакт-менеджменту способствуют ускорению доставки ПО:

▶ Собирайте и изучайте обратную связь от клиентов. Используйте ее в процессе разработки и доставки своих продуктов.

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

▶ «Нарезайте» работу на небольшие куски, которые должны быть завершены в течение недели или меньше. Вместо того чтобы разрабатывать сложные функции на ветвях и выпускать их редко, лучше сфокусироваться на небольших функциях, которые можно быстро разработать. Эта идея применима не только на уровне функции, но и на уровне продукта – нужно как можно быстрее выпустить MVP – минимальный рабочий продукт или прототип продукта с достаточным количеством функций для достоверного изучения самого продукта и его бизнес-модели. Так вы сможете сократить время выполнения заказа и ускорить цикл обратной связи.

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

Бережливое управление

Теория и практика управления в контексте доставки программного обеспечения значительно изменилась за последние десятилетия. После выпуска Манифеста Agile в 2001[7]7
  Манифест Agile – документ, содержащий основные принципы и ценности гибкой разработки ПО. Манифест был подписан на встрече 17 представителей различных концепций разработки ПО 13 февраля 2001 года в штате Юта.


[Закрыть] году методы Agile стали применяться практически повсеместно.

В то же время идеи бережливого производства, зародившиеся в автомобильном концерне Toyota, стали применяться и к ПО.

Стремление Toyota к непрерывному совершенствованию позволило производить автомобили быстрее, дешевле и превосходить конкурентов в качестве. Философия бережливого производства была впервые адаптирована к разработке ПО Мэри и Томом Поппендайками, авторами серии книг Lean Software Development («Бережливая разработка ПО»).

В своем исследовании Николь Форсгрен, Джес Хамбл и Джин Ким смоделировали бережливое управление в доставке ПО с помощью трех практик – ограничения незавершенного производства (НЗП)[8]8
  Незавершенное производство – элементы производства, которые находятся на этапе добавления ценности.


[Закрыть]; создания и поддержки визуальных дисплеев, демонстрирующих ключевые показатели качества и производительности и текущий статус работы и позволяющих понять, нормально ли текущее состояние системы; ежедневного использования данных мониторинга инфраструктуры и эффективности приложений для принятия бизнес-решений. Исследователи обнаружили, что в сочетании эти методы повышают эффективность доставки и оказывают положительное влияние на культуру и производительность команды, а также снижают выгорание.[9]9
  Читайте саммари книг Джеймса Вумека, Дэниела Джонса «Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании» и Майка Ротера «Тойота Ката. Лидерство, менеджмент и развитие сотрудников для достижения выдающихся результатов».


[Закрыть]

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

Эти советы по бережливому менеджменту помогут вам ускорить доставку ПО.

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

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

▶ Проверяйте работоспособность системы заранее, чтобы вовремя обнаруживать и оперативно устранять проблемы.

▶ Улучшайте процессы и управляйте ограничением НЗП. При эффективном использовании это приведет к увеличению производительности и сделает ограничения видимыми в системе.

▶ Визуализируйте работу, чтобы контролировать качество и общаться всей командой. Для этого используйте такие визуальные дисплеи, как приборные панели или внутренние сайты.

Организационная культура

Организационная культура имеет огромное значение, когда речь идет об эффективности и конкурентоспособности. Это прописная истина в кругах DevOps. Авторы «Ускоряйся!» в своих исследованиях опирались на типологию организационных культур, разработанную социологом Роном Веструмом, изучавшим влияние человеческого фактора на безопасность систем, и включающую три вида организаций:

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

▶ Бюрократические (ориентированные на правила). Здесь все действуют строго по регламенту. Причем на каждом уровне управления создаются свои правила.

▶ Производительные (ориентированные на результат). Эти организации сосредоточены на миссии. Здесь все подчинено эффективной работе.

В ходе исследования авторов был проведен опрос, и 31 % организаций-респондентов были классифицированы как патологические, 48 % – как бюрократические и 21 % – как производительные (из приблизительно двух тысяч организаций). Исследование также выявило, что тип организационной культуры напрямую не зависит от размера, возраста или отрасли организации. Некоторые команды из федерального правительства США, которые участвовали в исследовании, без натяжки можно было назвать производительными. При этом некоторые стартапы были патологическими.

Возможности, связанные с культурой

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

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

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

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

Обучение часто происходит вне рамок формального образования. Некоторые компании, такие как 3M и Google, выделяют часть рабочего времени (15 и 20 % соответственно) для изучения сторонних проектов.

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

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

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

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

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