Текст книги "Agile-трансформация. Раскрывая гибкость бизнеса"

КАКИЕ ПРОБЛЕМЫ ЭТО РЕШАЕТ?

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

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

КАК ИЗВЛЕЧЬ ИЗ ЭТОГО ПОЛЬЗУ

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

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

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

ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ

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

ПРАВИЛЬНОЕ СОЗДАНИЕ ПРОДУКТА

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

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

• Scrum;

• Kanban.

SCRUM: ИТЕРАТИВНОЕ И ИНКРЕМЕНТАЛЬНОЕ СОЗДАНИЕ ЦЕННОСТИ

Scrum, о котором мы уже говорили в главе 1, – определенно самый популярный Agile-фреймворк, используемый сегодня. Согласно опросу компании Version One, около 60 % команд, практикующих гибкие методологии, сообщают, что используют Scrum[73]73
  «VersionOne: State of Agile Report». https://explore.versionone.com/state-ofagile/versionone-11th-annual-state-of-agile-report-2


[Закрыть].

Отчасти Scrum так популярен из-за того, что он изящно прост. Но не позволяйте простоте обмануть вас, простой не значит легкий. Как говорили Кен Швабер и Джефф Сазерленд, создатели Scrum, «Scrum легко понять, но сложно освоить»[74]74
  Ken Schwaber and Jeff Sutherland. «The Scrum Guide». https://www.scrumguides.org/scrum-guide.html


[Закрыть].

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

По сути, Scrum помогает конкретизировать ценности Agile-манифеста с помощью фреймворка, состоящего из четырех событий, трех ролей и нескольких простых артефактов (см. рис. 3.7).

Рис. 3.7. Обзор фреймворка Scrum[75]75
  Кеннет Рубин. Основы Scrum. Практическое руководство по гибкой разработке ПО. М.: Вильямс, 2016.


[Закрыть]. (PBR)* –[76]76
  В оригинальном тексте используется устаревший термин grooming, которому соответствует современный PBR (Product Backlog Refinement) – «уточнение бэклога продукта»; «деятельность, направленная на уточнение, оценку и упорядочивание элементов в бэклоге продукта». Речь идет о непрерывном процессе, в рамках которого владелец продукта и команда разработки обсуждают детали элементов бэклога продукта, тем самым проверяя и пересматривая эти элементы. Прим. пер.


[Закрыть]

КАК ЭТО РАБОТАЕТ

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

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

Представитель потребителя в Scrum называется владельцем продукта (Product Owner, PO). Владелец продукта отвечает за видение продукта и выражает его с помощью ряда приоритизированных элементов бэклога продукта (Product Backlog Items, PBI), которые обычно называют пользовательскими историями (User Stories). Эти истории последовательно улучшаются со временем, так что бэклог продукта динамичен и может изменяться по мере того, как становится доступно больше информации.

Итерация, или спринт, фиксирована. Владелец продукта вместе с командой делает выборку историй из бэклога продукта. Эта выборка выполняется за время спринта, которое, как правило, не превышает двух недель (хотя Scrum официально устанавливает временные рамки в 30 дней).

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

Команда сама по себе – многопрофильная, кросс-функциональная группа, члены которой обладают всеми навыками, необходимыми для работы по бэклогу. Команда включает разработчиков, тестировщиков, дизайнеров взаимодействия с пользователем (User Experience, UX), архитекторов, бизнес-аналитиков – всех, чьи навыки, знания и умения необходимы для создания ценности. Загвоздка в том, что оптимальный для сохранения эффективного сотрудничества и коммуникации размер команды – не более 7 +/– 2 человек. Рекомендации по размеру команды основываются на том факте, что ухудшение линий коммуникации (и сопутствующее им снижение эффективности) значительно возрастает по мере роста команды. Например, в команде из шести человек 15 линий коммуникации, а в команде из десяти человек 45 линий коммуникации – следовательно, сложность увеличивается втрое.

Третья роль Scrum, помимо владельца продукта и команды, – scrum-мастер. Scrum-мастер – коуч команды, который помогает устранять препятствия для выполнения работы. Scrum-мастер сопровождает процесс и помогает членам команды постоянно совершенствовать способы работы.

Каждый день команда встречается для 15-минутной координационной встречи, которая называется «Ежедневный Scrum», или «Ежедневный stand-up» (от англ. stand – «стоять»). Обычно участники этого короткого собрания действительно стоят, чтобы обсуждение прошло быстро и затрагивало только насущные вопросы. В ходе встречи члены команды помогают друг другу понять, что они делают, чтобы выполнить цели для текущего спринта, и есть ли препятствия, мешающие им выполнить свои обязательства в этом спринте.

Они задают следующие вопросы.

1. Что я сделал вчера, что помогло команде разработки приблизиться к цели спринта?

2. Что я сделаю сегодня, чтобы помочь команде разработки достичь цели спринта?

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

Если препятствия обнаружены, в дело вступает scrum-мастер. После встречи он убеждается в том, что работа может продолжаться с минимальными разрушениями.

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

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

КАКИЕ ПРОБЛЕМЫ ЭТО РЕШАЕТ?

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

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

КАК ИЗВЛЕЧЬ ИЗ ЭТОГО ПОЛЬЗУ

Чтобы Scrum был эффективен, тем не менее должны соблюдаться некоторые условия. Вот как их формулирует Майк Коттмайер, СЕО компании Leading Agile и топ-консультант по организационным изменениям.

1. Полная команда, способная доставлять ценность в соответствии с бэклогом продукта.

2. Полностью протестированное и интегрированное программное обеспечение, доступное в конце каждой итерации.

3. Четко определенный, улучшенный бэклог, управляемый вовлеченным владельцем продукта.

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

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

Scrum – это не просто другой фреймворк с другими ярлыками; он представляет собой способ работы, критически отличающийся от предсказуемых методологий, построенных на следовании плану.

Чтобы Scrum был эффективным, вы вынуждены поменять то, как вы работаете. Это часть могущества Scrum: он подчеркивает и делает видимыми многие недостатки, существующие в текущих процессах, так что вы можете обсудить их на ретроспективе и внести в них подходящие изменения. Помните, Toyota рассматривала дефекты как сокровища, представленную информацию – как способ улучшить систему? За Scrum стоит точно такое же мышление.

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

ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ

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

Scrum можно использовать в различных контекстах за пределами программного обеспечения. Мы с семьей делаем это, чтобы составить планы на неделю. Каждое воскресенье я, моя жена и наши дети определяем бэклог на неделю и планируем его совместное выполнение. Обсуждая бэклог и оценивая относительные усилия, необходимые для его выполнения, мы помещаем список работ на видное место – на scrum-доску, расположенную в гостиной; поэтому мы всегда знаем, как обстоят дела, и можем быстро помогать друг другу, если кто-то не справляется. Несмотря на то что у нас нет формального scrum-мастера или владельца продукта (думаю, что моя жена ближе всего к этой роли), мы организуем свою деятельность вокруг согласованного бэклога и помогаем друг другу следовать ему. Так и справляемся с домашними делами!

KANBAN: УКРОЩЕНИЕ ХАОТИЧНЫХ СРЕД С ПОМОЩЬЮ ВИЗУАЛИЗАЦИИ

В переводе с японского Kanban означает «визуальный сигнал» или «карта». Изначально это техника визуализации, в которой карточка с инструкциями отправлялась по конвейеру для визуализации потока работ и реализации принципа производственного управления ресурсами точно в срок. Затем, в середине 2000-х, техника была адаптирована для интеллектуального труда группой лидеров мнений, включавшей Дэвида Андерсона и Джима Бенсона – писателей и консультантов по управлению[77]77
  Дэвид Андерсон. Kanban: Альтернативный путь в Agile. М.: МИФ, 2017.


[Закрыть].

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

Scrum использует ограничения по времени для сдерживания системы и создания неявного ритма работы, в то время как Kanban устраняет временные ограничения и вместо этого фокусируется на управлении потоком работ, ограничивая объем незавершенных задач (Work in Progress, WIP). Таким образом, убеждаясь, что команды не заняты большим количеством работы, чем то, с которым они в состоянии справиться, мы можем сократить количество «бутылочных горлышек», повысить скорость и улучшить общее качество работы.

Scrum – техника, наиболее популярная в средах с более традиционной разработкой продуктов ПО; Kanban более популярен в менее предсказуемых средах с большим количеством помех – например, таких как сопровождение ПО или техническая поддержка.

КАК ЭТО РАБОТАЕТ

Kanban позволяет командам быстро увидеть поток работ в пределах их рабочих процессов, сообщать о статусе работы и более глубоко понять контекст выполняемой работы. Как говорит один из лидирующих консультантов Kanban, «Kanban берет информацию, которая обычно сообщается словами, и превращает ее в конфетку для мозга»[78]78
  https://leankit.com/learn/kanban/what-is-kanban/


[Закрыть].

Доска Kanban проста и наглядна, ее содержание можно понять за доли секунды (см. рис. 3.8).

Рис. 3.8. Пример Kanban-доски[79]79
  Leankit: «What Is Kanban?» https://leankit.com/learn/kanban/what-is-kanban/


[Закрыть]

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

КАК ИЗВЛЕЧЬ ИЗ ЭТОГО ПОЛЬЗУ

В основе Kanban лежат четыре принципа.

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

2. Ограничение объема незавершенной работы (Work in Progress, WIP). В главе 2 мы уже обсуждали некоторые преимущества, которые дает выполнение не слишком большого количества работы. Kanban явным образом признаёт это, побуждая команды сокращать количество незаконченной текущей работы. Это позволяет увеличить скорость ее выполнения, сократить несоответствия и повысить качество за счет снижения многозадачности.

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

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

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

ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ

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

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

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

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

СОЗДАНИЕ ПРОДУКТА С ПРАВИЛЬНОЙ СКОРОСТЬЮ: ОПТИМИЗАЦИЯ ПОТОКА РАБОТ

Определение желаний потребителей и работа согласно уникальному ценностному предложению очень важны. Но для того, чтобы оставаться конкурентоспособным и постоянно улучшать методы работы, важно разрабатывать продукты так, чтобы сократить потери в процессе и время, которое занимает путь «от идеи до прибыли»[80]80
  Отсылка к книге «Бережливое производство программного обеспечения. От идеи до прибыли» Мэри Поппендик и Тома Поппендика. Прим. науч. ред.


[Закрыть], как говорит Мэри Поппендик, заслуженный лидер мнений Lean[81]81
  Том и Мэри Поппендик. Бережливое производство программного обеспечения. От идеи до прибыли. М.: Вильямс, 2009.


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

• Экстремальное программирование (Extreme Programming, XP).

• Систематизирование потока ценности (Value Stream Mapping, VSM).

ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ

Экстремальное программирование, XP, – это набор инженерных практик и дисциплин, которые помогают команде обеспечивать более быстрые петли обратной связи. XP также контролирует технический долг на уровне исходного кода, продвигая спонтанное проектирование, управляя технической сложностью. Обычно XP соотносится с такими практиками, как разработка через тестирование (Test Driven Development, TDD), непрерывная интеграция (Continuous Integration), парное программирование (Pair Programming), коллективное владение (Collective Ownership) и рефакторинг (Refactoring).

КАК ЭТО РАБОТАЕТ

Суть экстремального программирования – встраивание исходного кода и быстрая доставка ПО с помощью частых циклов проверки и адаптации. В последующем списке я приведу обзор ключевых практик, ассоциирующихся с XP. Детали этих практик выходят за пределы книги, поэтому я рекомендую вам обратиться к разделу «Что почитать по теме» в конце этой главы, чтобы узнать о них больше.

1. Разработка через тестирование (Test Driven Development, TDD). TDD – это процесс разработки ПО, повторяющий короткий цикл разработки. Сначала пишется тест, чтобы определить желаемые системные изменения или новые функции. Затем тест запускается (и проваливается), разработчик пишет минимально необходимый код для того, чтобы пройти тест, затем проводит рефакторинг кода, чтобы убедиться в его «гигиене». Этот процесс позволяет установить качество тестирования кода и снижает риски. Обычно он выглядит следующим образом:

– добавление теста;

– проведение всех тестов и проверка, пройден ли последний тест;

– написание кода;

– проведение тестов;

– рефакторинг кода;

– повторение.

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

2. Непрерывная интеграция (Continuous Integration) и непрерывное развертывание (Continuous Deployment). Это практика разработки, которая требует интеграции кода в общий репозиторий разработки несколько раз в день. Каждая интеграция затем верифицируется автоматизированной сборкой, позволяющей командам оперативно обнаруживать проблемы. Регулярная интеграция дает возможность быстро находить ошибки и легче устранять их.

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

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

Непрерывная интеграция и непрерывное развертывание, проводимые вместе, позволяют значительно снизить «цену выпуска». В процессе команды адаптируются к изменениям рынка намного быстрее. В дальнейшем эта концепция стала включать в себя всех, кто участвует в жизненном цикле ПО, – от проектирования и процесса разработки до поддержки продукта, создавая полный сквозной процесс поставки ПО. Это то, что мы сейчас называем DevOps[82]82
  «The Agile Admin.» https://theagileadmin.com/what-is-devops/


[Закрыть],[83]83
  DevOps – акроним от англ. DEVelopment («разработка») и OPerationS («операции»), означает набор практик, нацеленных на интеграцию рабочих процессов специалистов по разработке и информационно-технологическому обслуживанию. Прим. науч. ред.


[Закрыть].

3. Парное программирование (Pair Programming). Это практика создания программного обеспечения с помощью двух программистов, работающих за одним компьютером. Парное программирование требует наличия двух ролей: ведущего, который пишет код, и навигатора, который просматривает только что написанный код. Роли часто меняются, чтобы сохранить свежий взгляд. Групповое программирование, популяризованное Вуди Зуиллом, развивает эту концепцию еще дальше. Оно включает целую команду, работающую «над одной вещью, в одно время, в одном пространстве, за одним компьютером»[84]84
  The Agile Alliance. «What Is Mob Programming?» https://www.agilealliance.org/glossary/mob-programming/


[Закрыть],[85]85
  Woody Zuill and Kevin Meadows. «Mob Programming: A Whole Team Approach». LeanPub. (https://leanpub.com/mobprogramming)


[Закрыть].

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

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

Фактически некоторые компании, например Menlo Innovations – успешная компания-разработчик ПО, делают парное программирование неотъемлемой частью своей работы. В Menlo такой подход к сотрудничеству распространяется за пределы программирования: проектные менеджеры и другие сотрудники постоянно кооперируются во время работы, чтобы обеспечить лучшее качество продукта, лучшее обучение, а также согласованность во всей организации. Рич Шеридан, CEO Menlo, так говорит о парном программировании: «Это просто лучше работает. Два мозга думают лучше, чем один!»

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

Эта практика может показаться чужеродной более традиционным разработчикам, которые привыкли к четкому разделению владения кодом. В конце концов, разработка программного кода может быть очень личным делом, и многие разработчики думают: «Как другие могут оценить и понять мой код?»

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

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

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

Джошуа Кериевски, эксперт XP и автор книги «Рефакторинг с использованием шаблонов», поясняет, что все неудобства, связанные с внедрением рефакторинга в ежедневный поток работ, – это инвестиция в будущий код:

«Постоянно улучшая проект кода, мы делаем работу с ним все проще и проще. Это резко контрастирует с тем, что обычно происходит: небольшая реорганизация кода и добавление новых функциональных возможностей с особой тщательностью. Если непрерывная реорганизация кода станет для вас такой же привычкой, как чистка зубов, вы обнаружите, что расширять и поддерживать код легче именно таким образом»[86]86
  Джошуа Кериевски. Рефакторинг с использованием шаблонов. М.: Вильямс, 2016.


[Закрыть].

КАК ИЗВЛЕЧЬ ИЗ ЭТОГО ПОЛЬЗУ

Технически XP не является частью Scrum или Kanban (или любых их вариантов); однако вся отрасль программного обеспечения все яснее видит, что без внимания к устойчивым инженерным принципам при разработке кода все преимущества, которые можно получить из разработки меньших инкрементальных его частей, постепенно исчезнут под влиянием калечащих последствий технического долга, замедляющего и в конечном счете останавливающего прогресс. На самом деле я никогда не видел команды, которая наслаждалась бы плодами последовательного выполнения работы и не принимала бы при этом во внимание инженерные принципы, используемые при разработке продукта.