Перевод статьи, написанной Scrum.org и DevOps Institute. Ссылка на оригинальный файл

От переводчика

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

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

Ссылки, которые были в основном документе, я поместил сразу в текст, они отделяются скобками и курсивом. Если были сомнения в корректности перевода термина, то я дублировал его в скобках на английском.

Совместное использование Scrum и DevOps

"Программное обеспечение поглощает мир"

(Andreessen, Marc. "Why Software Is Eating The World." The Wall Street Journal. August 20, 2011.
https://www.wsj.com/articles/SB10001424053111903480904576512250915629460).

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

ПО — это также источник изменений. Те организации, что полностью используют преимущества автоматизации, обходят своих "нецифровых" конкурентов ("2017 State of DevOps Report." Puppet. https://puppet.com/resources/whitepaper/state-of-devops-report) за счёт того, что быстрее проверяют гипотезы, получают и анализируют результаты экспериментов и используют эту информацию, чтобы улучшаться.

Ускоряемый новыми технологиями, рынками и изменением климата мир меняется всё быстрее (FRIEDMAN, THOMAS L. THANK YOU FOR BEING LATE: an optimists guide to thriving in the age of accelerations. S.l.: PICADOR, 2017). Единственный способ выжить — это вступить на путь изменений.

Две методологии — одна цель

Agile и DevOps — это основные способы, которыми организации добиваются одних и тех же целей: более быстрые циклы разработки, меньшие блоки функционала для релиза, использование обратной связи для улучшения процессов, устранение препятствий и нецелевых трудозатрат. Аспекты, на которые делается упор в этих двух методологиях, различаются, потому иногда люди считают, что это разные подходы. Agile делает упор на командное взаимодействие, культуру и ценности, в то время как DevOps во главу ставит конвейер разработки (delivery pipeline) и его непрерывность (flow). Но Agile так же касается темы автоматизации, а DevOps — коммуникации и культуры.

DevOps и Agile должны использоваться одновременно. Одним из самых популярных Agile-методов разработки является Scrum, которым ежедневно пользуется до 18 миллионов IT-профессионалов (https://www.infoq.com/news/2014/01/IDC-software-developers), что делает его (и Agile в целом) ключевым компонентом разработки, то есть как минимум обеспечивает часть "Dev" в термине "DevOps" (примечание переводчика: Dev — от английского developement — разработка, Ops — operations — эксплуатация).

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

• Некоторые приверженцы Agile думают, что любой процесс — это плохо, а "Ops" имеет богатую историю обеспечения стабильности через выстраивание процесса.
• В DevOps инструкции (tools) и автоматизация используются, чтобы увеличить скорость, в то время как те, кто пользуется Agile, в лучшем случае, видят в инструкциях неизбежное зло, а в худшем — помеху.
• Концепция DevOps обращается к системному мышлению для решения проблем, в то время как Agile подталкивает людей быть драйверами изменений.
• Политические игры и недостаток коммуникаций между подразделениями компании усиливают разрыв.

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

• Враждебно настроенные друг к другу стейкхолдеры. Деловые партнеры и менеджеры видят конфликт и теряют уверенность в том, что хотя бы кто-то понимает, что делает.
• Столкновение культур между разработкой и эксплуатацией. Открытое, ориентированное на людей сообщество Agile сильно отличается от процессно-ориентированной группы эксплуатации.
• Нарастающий страх и защитное поведение. Никто не хочет увеличения уровня риска, но при этом работает с ним по-разному. В Agile риски снижаются, путём многочисленных, но мало рисковых изменений. С точки зрения Ops, большое количество изменений по своей сути рискованно, потому ответной реакцией является усиление упорядоченности, контроля и управления.
• Разработчики рассматривают DevOps как временную меру; они видят цель как “NoOps”. NoOps означает полную автоматизацию работы эксплуатации, позволяющую разработчикам управлять продукционной средой. Является ли это реально возможным или же только желаемым, в целом, не важно; большинство организации до сих пор настолько далеки от эффективного применения концепции DevOps, что NoOps — это туманная и бесполезная цель.

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

• Низкому качеству. Системный подход к качеству имеет решающее значение для качества любого продукта, но для многих команд, качество по-прежнему обеспечивается местечково, в лучшем случае ручным тестированием, окружающим их процесс непрерывной интеграции.
• Никогда ничего не доводится до конца. При наличии слишком большого количества сложных процессов, которые требуют внешнего согласования или проверки, для команды становится практически невозможным довести задачу из бэклога до состояния "Выполнено".
• Отсутствию прозрачности и наглядности. Многие процессы настолько сложны, что никто не может охватить их целиком, и становится невозможным принимать взвешенные решения.
• При изменениях в составе команды меняется всё. Без четкого и понятного процесса трудно управлять изменениями, связанными с людьми, или что либо масштабировать.
• Появлению скрытой работы, которую процесс не включает в явном виде. В то время, как процессы становятся более детализированными и всеобъемлющими, возникает всё больше работы, которая в них не включена (примечание переводчика: я это понял так: более детальные процессы требуют всё больше времени, но  ни один процесс не может покрыть всё, потому возникают работы, в них не включённые, которые тоже нужно делать). Это приводит либо к большому количеству «скрытой» работы и работы «в обход» или же к работе впустую.

Объединение Scrum'a и DevOps.

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

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

Создание кросс-функциональных команд не является чем-то новым. Хиротака Такеучи и Икуджиро Нонака описали важность гибких, кросс-функциональных команд в книге «The New New Product Delivery Game» в 1986 году (Nonaka, Hirotaka TakeuchiIkujiro. "The New New Product Development Game." Harvard Business Review. August 01, 2014. https://hbr.org/1986/01/the-new-new-product-development-game). Но принять правильное решение о том, кто должен быть включен или не включен в команду — сложно. Современные продукты представляют собой сногсшибательное множество различных технологий, которые исторически требовали особых навыков и инфраструктуры. А команда разработки должна обладать всеми навыками, необходимыми для создания рабочего продукта. Это описано в Scrum Guide (The Scrumuide. http://www.scrumguides.org) как:

«Кросс-функциональные команды обладают всеми компетенциями, необходимыми для выполнения работы и не зависят от тех, которых в составе команды нет».

Кросс-функциональные команды должны иметь необходимый набор навыков, чтобы выполнить работу. Когда команда выполняет переход от традиционного подхода, основанного на ролях, её члены должны увеличивать количество имеющихся навыков. Они также должны научиться чувствовать симпатию (build empathy) к клиенту, чтобы делать лучшие продукты. Это не означает, что каждый отдельно взятый человек может быть только в одной команде. Есть большое количество примеров, когда кто-то с экспертизой в эксплуатации является членом сразу нескольких команд (действуя почти как "подразделение обслуживания" для команды), принося свои опыт и знаний в команду (одну или несколько), что позволяет улучшить процесс разработки продукта, одновременно с обучением других членов команды, чтобы они могли расширить свои навыки. Но это должно находится в балансе с тем, как их доступность влияет на способность команды разрабатывать задачи из бэклога. Они также, как правило, должны:

• Уменьшить количество перекидываемых задач (hand-offs). Перекидывание задач увеличивает время ожидания и уменьшает владение кодом и ответственность. Перекидывание задач может быть неизбежным, когда у команды не хватает полного набора нужных навыков или же авторитета, чтобы разработать полноценное решение. Но если это касается большей части работы, которая выполняется командой, тогда людей с необходимыми навыками нужно включать в команду.
• Развить все навыки, которые необходимы, чтобы создавать ценность. Когда у команд нет полного набора необходимых навыков, им нужна будет помощь специалистов. Со временем они должны стремиться учиться у этих специалистов, чтобы увеличить собственную независимость. Например, на этапе начала разработки любого приложения должен приниматься во внимание вопрос безопасности. Те, кто отвечает за безопасность, могут оказать помощь команде, у них команда может учиться, снижая свою зависимость и улучшая качество работы.
• Увеличить автоматизацию процесса. Автоматизация большого числа задач, которые выполняются командой механически в процессе разработки программного обеспечения, высвобождает время на ценную работу, ориентированную на удовлетворение потребностей клиента. К таким механическим задачам можно отнести как минимум: непрерывную интеграцию, тестирование, развертывание и подготовку среды.

DevOps и Scrum используются успешно, когда устранены препятствия

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

При построении системы разработки будущего, следует шаг за шагом устранять очереди и заменять их на системы "самообслуживания" (self-service capabilities). Такие традиционные функции, которые относятся к IT, как: поддержание среды, базы данных, безопасность, сетевая инфраструктура, а также разворачивание программного обеспечения, должны поддерживаться, как набор систем самообслуживания. Эти системы будут очень похожи на сервисы, которые сейчас предоставляют такие компании, как Amazon Web Services (AWS), Microsoft Azure и Google и часто будут использовать эти внешние облачные сервисы, добавляя к ним специфичные для организации интеллектуальные права, чтобы сделать их соответствующими clomplience-политике компании (company complient).

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

Помощь командам в увеличении их возможностей подразумевает:

• Команды должны иметь полномочия на выполнение всего, что требуется для выпуска (release) продукта. Вместо введения большого количества ограничений, чтобы защитить команду от её самой, нужно дать ей полномочия принимать решения и целиком разрабатывать продукт. Но следует следить за тем, чтобы, во-первых, масштаб расширения полномочий был не больше того, который позволяет легко откатить изменения, во-вторых, среды разработки и применяемые архитектурные принципы были достаточно устойчивы, чтобы выдержать изменения.
• Уменьшение внешних зависимостей, через автоматизацию, построенную на сервисах самообслуживания (self-service automation). Вместо того, чтобы включать Agile-команды в сложные процессы, обеспечьте их сервисами самообслуживания, которые позволят Scrum-командам выдавать результат автономно. Например, выделение виртуальных машин или предоставление доступа к тестовым данным.
• Обеспечение доступа команд к техническим ресурсам, доступным без ожидания в очереди. Чем проще программное обеспечение, тем более гибкой может быть команда в его разработке и поддержке. С ростом его сложности и важности отдельно взятой команде становится всё тяжелее иметь все необходимые навыки для его поддержки. Но любая зависимость от внешних ресурсов может стать узким местом. Концентрируясь на поддержке Scrum-команд силами экспертов, которые могут обучать и поддерживать команду в использовании определённой технологии, вы одновременно устраняете бутылочное горлышко и улучшаете навыки команды, делая её более гибкой (flexible and Agile).
• Упрощение и разбиение на модули старых (legacy) приложений. Стремитесь к переработке старых систем и поддержке инфраструктуры такой, как среды разработки и тесты, чтобы лучше поддерживать гибкость (Agility). Это означает, что нужно сфокусироваться на уменьшении ограничений в тестировании, обеспечении лучшему разделению на модули и распространении знаний о старых системах по по всем командам, нежели концентрации его в одном месте.

Автоматизация, автоматизация и ещё раз автоматизация

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

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

• Простые процессы — лучше всего. Избавляйтесь от переусложненных процессов  (complexity and over-engineered processes).
• Начинайте с начала и с конца процесса и двигайтесь к его середине. Юнит-тесты и разворачивание на продукционную среду, пожалуй, являются наиболее подходящими областями, чтобы начать писать скрипты.
• Автоматизация должна быть естественной частью работы Scrum-команд.Можно подумать, что должны быть отдельные команды, которые занимаются автоматизацией и выстраивают стандартизованную среду. Опыт показывает, что эти команды, которые поддерживают централизованные инструменты, стремятся работать для всех, но в результате никому не оказывают услуги в полной мере. Сфокусируйте Scrum-команды на том, чтобы они делали нужные вещи для удовлетворения их собственных потребностей. Эти команды должны работать вместе с эксплуатацией, чтобы быть уверенным, что всё, что делается, может быть использовано, как в разворачивании ПО, так и в продукционной среде.

Профессионалы в разработке программного обеспечения

В сердце современной организации, которая занимается разработкой программного обеспечения находятся квалифицированные профессионалы, которые могут применять свой опыт (apply an empirical process) и у которых есть нужные инженерные/эксплуатационные навыки для того, чтобы гарантировать, что выполняемая ими работа находится на нужном уровне качества.

Scrum считает, что профессионализм настолько важен, что Scrum-Guide включает в себя пять
ценностей: концентрация, открытость, уважение, приверженность и мужество.

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

• Введите ученичество, наставничество, обучение на примерах в практики личностного развития. Основываясь на средневековых методах передачи знаний, этот подход к построению карьеры создаёт сообщество учеников и учителей в соответствии с принципами бережливого мышления (lean thinking), лидеры которого, выходят из переговорной комнаты и офиса, чтобы работать с командой в Gembla или в другом месте, где создаётся ценность.
• Вознаграждайте команды, а не отдельных людей. В большинстве организаций существует мало направлений, где человек может чего-то достичь в одиночку. Большое количество разных людей должны работать вместе, чтобы принести больше пользы потребителю. Большинство инициатив, которые завязаны на одного человека — неуместны, а персональные поощрения противоречат тому факту, что результат очень редко достигается в одиночку.
• Вознаграждайте людей за реальные достижения, а не просто за то, что они чем-то заняты. Фокусируйтесь на том, чтобы увеличивать полезность для покупателя и устранении ненужной работы, а не на том, чтобы держать людей занятыми, насколько это возможно. Покуда человеческий ресурс дорог, никто не выигрывает от того, что занятые люди выдают неверное решение. А поддержание постоянно занятыми людей, навыки которых являются дефицитными, попросту  означает, что много кому другому придётся ждать.
• Делайте эти ценности такими же важными, как и результат работы. Как часто вы слышали кого-то, кто говорил: "Да, ему удалось завершить разработку, но это была кровавая баня"? Такой героический подход к разработке иногда работает, но его результат непредсказуем и уничтожает организацию, приводя к выгоранию людей и создавая огромные объемы технического долга. Способствуя тому, что профессионалы живут по ценностям, на которые ориентирован Scrum (Отличный обзор Scrum-ценностей можно найти здесь: "There’s value in the Scrum Values." Ullizee. May 03, 2013.  https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/), открытость, уважение, приверженность и мужество вы не просто создаёте среду, которая способствует гибкости, но в которой также будет хотеться работать. Если команды разработки, эксплуатации и представители бизнеса также будут разделять эти ценности, взаимное доверие появится само собой. В конечно счёте, концентрируясь на общих для организации ценностях, вы выстраиваете качественные продукты, не только с точки зрения отсутствия дефектов, но и с точки зрения ценности для пользователя.

Интегрируйтесь, концентрируйтесь и побеждайте

Для многих барьеры, которые мешают стать целостной, имеющей хорошо развитое внутреннее сотрудничество, кросс-функциональной организацией, занимающейся разработкой и поддержкой, являются непреодолимыми: статус кво кажется нерушимым, старые (legacy) приложения и культура — неизменяемыми. Попытки некоторых организаций измениться выливаются лишь в присваивании старым процессам, ролям, организационным структурам новых имён.

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

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

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

Шаг 1: Унификация подхода к поставке программного обеспечения

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

Таким образом, первый шаг призывает организацию остановить это безумие, принимая целостный продуктоцентрический подход к созданию бизнес-ценности. Проекты могут продолжать существовать, но они являются вторичными по отношению к стабильным командам, включая эксплуатацию, которая добавляет новую ценность посредством удовлетворения потребностей в поддержании сред в работоспособном состоянии. Крупные продукты, которые разрабатываются группами команд могут использовать фреймворк Nexus ("Scaling Scrum with Nexus." Scrum.org. https://www.scrum.org/resources/scaling-scrum) с целью масштабирования Scrum'a с целью создания Scrum-команд, в то время как маленькие продукты могут разрабатываться с использованием Scrum.

Вот какие выводы следуют для Scrum-команды:

• Создание команд, которые ориентируются на продукт и заказчиков. Ориентация на продукт или заказчика означает, что бэклог продукта будет содержать как новые задачи, так и задачи поддержки. Если продукт является крупным, то эти команды будут организованы вокруг Nexus, который упрощает работу большого количества команд над одним бэклогом продукта.
• Включение подходящих людей для того, чтобы поставить полностью готовый продукт. А когда мы говорим готовый продукт — это означает, что он выведен в продукционную среду и передан в поддержку. Для того, чтобы полностью соответствовать "Критериям готовности" ("Difinition of done") для программного обеспечения ("Definition of "Done"." The Scrum Guide. http://scrumguides.org/scrum-guide.html#artifact-transparencydone), требуется привлечение всех необходимых людей. Эксплуатация, безопасность, работа с данными будут либо включены в команды, либо уполномочат Scrum-команды взять задачи, которые традиционно будут относиться к их зоне ответственности. Это требует перемен от организаций, означающих отход от одиночной работы и выполнение задачи, являясь частью команды, помогая другим выполнять работу и обеспечивая её правильность.
• Несение ответственности за полный цикл выпуска, а не только за часть, связанную с разработкой. Фундаментальным изменением для Scrum-команд, которые всё ещё живут в парадигме "Скрамоводопада" ("Water-Scrum-Fall"), которое нужно для того, чтобы они были эффективными и приносили реальную пользу бизнесу, является то, что они должны стать полностью ответственными за полный процесс создания ценности как команда, ломая преграды собственничества и индивидуализма.

А такие — для службы эксплуатации:

• Реструктуризация поддерживаемых сервисов с целью группировки вокруг клиентов/продуктов. Первый шаг — это стремление работать с заявками в привязке к бизнесу, и реструктуризация исходя из бизнес-результатов и продуктов, а не основываясь на процессах и навыках специалистов.
• Удаление очередей из системы. Когда Scrum-команда не может делать работу самостоятельно,  не заставляйте её ждать кого-то ещё для получения помощи; сделайте так, чтобы помощь была доступна в любой момент, когда она нужна Srcum-команде. Предоставляйте сервисы самообслуживания везде, где это возможно, или набирайте людей на вакансии "экспертов" таким образом, чтобы их было достаточное количество для того, чтобы обеспечить командам помощь, как только она потребуется. В любом случае критичным является устранение преград на пути рабочего процесса.
• Предоставляйте услуги службы эксплуатации Scrum-командам. Наличие раздельных команд разработки и эксплуатации может быть неизбежным, но всегда должны быть доступны специалисты, готовые выполнять запросы Scrum-команд. Принимайте участие в ежедневных Scrum'ах, будьте приписаны к каким-либо Scrum-командам, понимайте, что такое Бэклог Продукта и Бэклог Спринта. Будьте частью команд, в которые вы входите, чтобы вы могли помочь им  с приоритизацией, в той же степени, в какой вы приоритизируете свои задачи.
• Автоматизируйте, автоматизируйте и ещё раз автоматизируйте. Для многих команд эксплуатации единственным способом начать доверять Scrum-командам — это либо стать частью команды, либо автоматизировать её работу, чтобы исключить ошибки. С этой стороны автоматизация — это жизненно важная часть обеспечения того, что целостный (holistic) подход к циклу поставки продукта является применимым.

Шаг 2. Добавляйте циклы обратной связи.

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

Для Scrum-команды это означает:

• Более частый релиз ПО в течение спринта. Ревью спринта (Sprint Review) — это НЕ единственная точка, когда можно выполнять релиз; программное обеспечение может выводиться на продукционную среду настолько быстро, насколько это нужно, и много раз за время спринта. Улучшенная обратная связь не ограничивается только используемым инструментарием и сбором большего количества данных, она также касается более частого сбора данных. Если команда или Nexus часто выводят ПО в продукционную среду, то Ревью спринта является гораздо более интересным, чем, когда во время ревью обсуждается то, что может быть "потенциально поставлено", так как в этом случае обсуждаться будет то, что уже в продукции.
• Встраивание критериев успешности выполнения в задачи бэклога продукта. Анализ задач бэклога продукта с точки зрения критериев успешности выполнения обеспечивает не только то, что когда команда завершает разработку задачи, она имеет на руках инструмент измерения её успешности, но также позволяет проверить саму задачу ещё до начала разработки. Эмпирический (Emperical) процесс получения опыта призывает к проверке и доработке на основании прозрачности. Это означает, что каждый результат должен быть измерим, чтобы можно было провести такую проверку и доработку.
• Приведение ревью спринта к виду более наглядному и прозрачному для бизнеса. Данные ценны лишь в том случае, если они используются, чтобы улучшить понимание и позволить принять решения. Для Scrum-команды важным является передача информации заинтересованным лицам (stakeholders), которые помогут принять правильные решения. Спринт ревью — это регулярная, формальная встреча, которая позволяет Scrum-команде и другим заинтересованным сторонам (например Стейкхолдерам (Stakeholders)), проверить ту часть работы, которая была выполнена за спринт (это может быть один или несколько выводов в продукционную среду (release), или что-то разработанное, но развернутое не в продукционной среде). Добавляя критерии оценки в ревью, можно сконцентрировать внимание на вещах, которые являются важными.
• Добавление критериев оценки (метрик) в программное обеспечение, чтобы улучшить понимание. Чтобы улучшить весь процесс требуется добавлять метрики как в процесс разработки, так и в само ПО.

Для Команды эксплуатации это означает:

• Внедрение поддержки среды для измерений и аналитики. Анализ среды разработки и самого ПО, требует внедрения технологий, которая могла бы поддерживать как учёт показателей, так и их хранение и анализ данных. Предоставляя эти среды и навыки, необходимые для понимания полученной информации, команда эксплуатации предоставляет для Scrum-команд полезный сервис.
• Создание общих информационных панелей (dashboards), которые содержат важные для конечного пользователя показатели успешности разработки. Очень часто команды эксплуатации и разработки используют разные информационные панели, чтобы показывать информацию о прогрессе, успехе или неудаче. Создавая информационную панель, которая содержит информацию, важную для обеих команд, вы создаёте коммуникационную среду, которая способствует эффективному сотрудничеству.
• Быть частью Скрам-команд, Ежедневных Scrum'ов, Ревью спринта и Ретроспектив спринта. Это может звучать очень просто, но тем не менее без концентрации на совместной работе со Scrum-командами профессионалы из службы эксплуатации выпадают из процесса анализа предыдущего опыта (review). Scrum — это эмпирический подход; это требует постоянного тестирования идей, для чего они должны быть прозрачны для всех, но тесты по умолчанию являются некорректными, если в них не принимают участия нужные заинтересованные лица. Делая профессионалов из службы эксплуатации частью команды и вовлекая их в различные Scrum-мероприятия, можно собирать идеи, что позволяет перестроить будущую работу с бэклогом и изменить планы.
• Обеспечение того, что вопросы, возникшие на ретроспективе спринта, будут учтены при проведении мероприятий, связанных с DevOps. В процессе работы по Scrum'у возникает большое количество моментов, когда проводятся проверка и доработка. Ретроспектива спринта — это лучшее событие, чтобы проверить, как работает команда. Из этой ретроспективы проистекают возможности для улучшения. Многие из направлений улучшений связаны с процессом управления релизами (release management), безопасностью и эксплуатацией. Тем более важным становится участие команд эксплуатации в проходящих ретроспективах спринта и использование их (ретроспектив) как части работ по улучшению.

Шаг 3. Взращивайте культуру постоянных экспериментов и обучения.

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

Это может прозвучать как игра словами (This might sound like semantics), но эта модель подразумевает, что работа проводится только в Scrum-командах, а сообщество, как это проистекает из самого слова — это ряд квалифицированных профессионалов, которые могут поддерживать, обучать и работать вместе с Scrum-командой чтобы производить лучшее программное обеспечение. Каждая Scrum-команда может напрямую контактировать с потребителем и, как того требует владелец продукта, на постоянной основе поставляет ценное программное обеспечение. Работа команды основана на измеримых результатах и в каждом её "эксперименте" или спринте идёт работа в сторону получения знаний и опыта. Эти  Scrum-команды поддерживаются инфраструктурой и сообществом, которое связано с этой работой через сервисы самообслуживания, членов команды и наставников, которые помогают команде выполнять работу и совершенствоваться. Чтобы это делать командам нужно:

• Внедрять показатели, основанные на реально видимом результате (evidence-based measures), чтобы дать командам возможность улучшаться. Доказательное управление (примечание переводчика: по аналогии с доказательной (evidence-baced) медициной) — описывает подход, который основывается на трёх группах показателей ценности: текущей ценности, возможности осуществлять инновации и времени вывода на рынок ("Evidence Based Management (EBMgt)." Scrum.org. https://www.scrum.org/resources/evidence-basedmanagement). Отслеживание улучшения по этим трём показателям позволяет командам сфокусироваться на том, что им реально нужно улучшать.
• Уполномочивать владельцев продукта проводить изменения и принимать решения по продукту. Сложные системы отчётности и комитеты по согласованию не нужны. Владелец продукта несёт ответственность не только за его развитие, но и использование в продукционной среде. Эта ответственность означает, что работы по эксплуатации — это также их зона ответственности и это следует принимать во внимание, когда рассматривается их роль. Общая цена владения/эксплуатации — это более не абстрактная цифра, затерявшаяся где-то на информационных панелях, а показатель, который должен приниматься во внимание, когда владелец продукта принимает решения.
• Включать в бэклог "экспериментальные" задачи. Не вся работа будет носить экспериментальный характер; бэклог также будет содержать задачи, которые были созданы, чтобы проверить понятную, ориентированную на будущее гипотезу, а также задачи с чётко определённой ценностью, устранение ошибок и работу с техническим долгом. Каждая задача бэклога будет определять работу в Scrum-команде и в тех службах/сообществах, которые оказывают ей поддержку. Эта работа должна быть сбалансирована, позволяя командам строить как настоящее, так и будущее, в то же время разбираться с прошлым.
• Создавать общую систему мотивации, которая объединяет членов команд и заинтересованных лиц (stakeholders). Сотрите различия между разработкой, эксплуатацией и бизнесом, внедрив единую систему мотивации для всех, кто создаёт ценность для конечного потребителя.

Заключение

DevOps появился из тех проблем, которые испытывали Agile-команды и изначально назывался "Agile-инфраструктура". Суть подхода заключалась в лучшей поддержке Agile-команд с более гибкими подходами к инфраструктуре. Эта инициатива стала частью более широкого движения, чем изначально задумывалось, и стала затрагивать не только инфраструктуру, но привела к революции во всём IT. Но важно, чтобы сообщество DevOps не забывало об истоках. Поддержка ориентированных на пользователя Scrum/Agile-команд всё ещё является основой успеха. И это означает радикальные перемены в том, как проводятся изменения, обеспечивается поддержка и организуются команды. По прежнему сохраняется потребность в совместной работе сообщества DevOps и Scrum-команд, чтобы создавать качественно сделанное программное обеспечение, а также в том, чтобы они поддерживали друг друга в своей постоянной потребности в самосовершенствовании путём взаимной проверки выполнении доработок, которые обеспечиваются прозрачностью процесса (by inspection and adaptation through transparency).

Способы организации

Не существует универсальной модели того, как сотрудники эксплуатации взаимодействуют со Scrum-командами. В некоторых случаях сотрудники службы эксплуатации будут сделаны частью команд. В других — они будут выступать в роли общего ресурса, который обучает и работает вместе с большим количеством команд. В более сложных продуктах которые используют подход, называющийся Nexus, для того, чтобы организовывать группы команд, группа эксплуатации может быть как частью Интеграционной команды Nexus (Nexus Integration Team (NIT)), так и частью отдельных Scrum-команд. Точно не подлежит сомнению тот факт, что каждая организация будет использовать различные модели, так как их продукты/потребители, могут требовать различных типов поддержки. А организации, в которых придерживаются мнения, что оптимизация эффективности службы эксплуатации — это более важная задача, чем создание ценности, никогда не смогут полноценно работать по Agile. Когда вы анализируете, как работает служба эксплуатации, обратите внимание на следующее:

• Делает ли объем неопределённости и сложности процессов невозможным применение какой-либо модели совместного использования ресурсов эксплуатации? В случаях, когда при эксплуатации решения имеется большое количество неизвестных, вынос функции эксплуатации за пределы Scrum-команды является сомнительным способом сэкономить, так как стоимость времени ожидания ответа от службы поддержки или появление излишнего объема коммуникации уменьшит гибкость (agility) команды.
• Если ли смысл в том, чтобы навыки этих специалистов получало большее количество людей. Гибкость требует универсалов, и в ситуации, когда есть поддержка передачи навыков членам Scrum-команд, функция эксплуатации в меньшей степени является узким местом и в большей — частью Scrum-команды. Это также обеспечивает большую гибкость в долгосрочной перспективе, так как у большего количества людей есть большее количество навыков.

Отчётность и ответственность

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

• Один общий бэклог продукта. В наше время у большинства организаций есть несколько бэклогов, при этом у каждой команды есть свой список задач и приоритетов. Для того, чтобы создать общую систему отчётности и ответственности, необходимо, чтобы был ОДИН общий, наглядный, бэклог продукта. Этот бэклог должен управляться одним Владельцем продукта, который несёт ответственность за то, что результат текущей работы создаёт ценность. Скорее всего, они не будут выполнять всю работу, но они несут ответственность за то, что работа доводится до конца и приоритезируется исходя из того, чтобы в конечном итоге она создавала наибольшую ценность.
• Единственную, ориентированную на результат информационную панель, к улучшению показателей которой все стремятся. Если вы хотите, чтобы все двигались в одном ритме, нужно, чтобы все знали, какой это ритм. Настроив общую информационную панель, Скрам-команды и служба эксплуатации будут работать, чтобы достичь одних и тех же понятных показателей.
• Владельца продукта, который отвечает за результат, предоставляемый покупателю. Будучи Владельцем продукта очень просто фокусироваться на предоставлении новых продуктов потребителю и при этом не нести ответственности за операционные системы, цену и качество. DevOps должен подразумевать более широкое участие Владельца продукта и делать его участником всей разработки решения (make them part of the solution).

Самоорганизация и распределение полномочий

Здоровые, высокопроизводительные команды сами решают, как они выстраивают свою организацию, как работают, какие инструменты и процессы они используют. Чтобы это делать, они должны нести ответственность за ценность и качество тех результатов, которые они приносят, при этом не нужно заниматься микроменеджментом, чтобы они этого результата достигли. Нет единого подхода, который работает в любой ситуации. Тем не менее, люди, которые выполняют работу, лучше всего в состоянии принять решение о том, как её делать. Нельзя использовать универсально решение для всех, а ключевая идея, которой можно научиться у Agile-сообщества — это то, что если пытаться применить стандартный "Agile" процесс для любой ситуации, в итоге получишь результат противоположный гибкому (the opposite of agility). Вместо этого фокусируйтесь на подходе, основанном на получении опыта (empirical), который начинается с идеи и заканчивается на покупателе. Это означает чёткую ориентацию на потребителя на всей цепочке создания ценности.