Kitobni o'qish: «Искусство Agile-разработки. Теория и практика гибкой разработки ПО»

Name: Искусство Agile-разработки. Теория и практика гибкой разработки ПО
ISBN: 978-5-4461-2386-5

Shrift:

Отзывы

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

Гойко Аджич, автор книг Running Serverless, Impact Mapping и Specification by Example

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

Ави Кесснер, инженер, Forter

Эта книга получит свое постоянное место на моей книжной полке.

Кришна Кумар, основатель и CEO, Exathink Research

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

Бенджамин Мускалла, старший инженер-программист, GitHub

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

Луиза Нуньес, менеджер программ, Thoughtworks

Это моя любимая книга об Agile. Она охватывает технические и управленческие темы. Я использую ее на своих занятиях и всегда рекомендую своим клиентам.

Николас Паес, инженер-программист и преподаватель, Университет Буэнос-Айреса

Джеймс подробнейшим образом описывает собственный опыт в Agile-разработке ПО. Простыми словами, связывая теорию с практикой.

Кен Пью, главный консультант, автор книги Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability

Тысячи книг об Agile. Какую из них прочитать? Я советую вам эту. Джеймс работает с Agile с первых дней его появления и знает свое дело. Книга разбирает весь бессмысленный мусор в нашей отрасли, окружающий это понятие, и предлагает тщательно выверенный, целостный подход. Этот подход не будет быстрым и легким, но он того стоит. Мне понравилась книга «Искусство Agile-разработки». Это книга с характером!

Бас Водде, соавтор LeSS

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

Билл Уэйк, XP123, LLC

Моей семье

Предисловие

Когда мы писали Манифест Agile для разработки программного обеспечения, нашими сторонниками было незначительное меньшинство людей, пытавшихся изменить отрасль. Сейчас, 20 лет спустя, «agile» – это мейнстрим. Я пишу «agile» в кавычках намеренно: множество людей говорят, что они занимаются разработкой программного обеспечения по Agile, в самом деле искренне в это веря, однако их действия мало напоминают то ви́дение, которым мы поделились со всеми два десятилетия назад.

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

Джеймс Шор был одним из пионеров, вставших на тропу экстремального программирования (Extreme Programming, XP), центрального элемента движения Agile. Первое издание этой книги было отличным руководством для команд, показывавшим им, что нужно знать для правильного выполнения Agile-процессов. Позже Джеймс вместе с Дианой Ларсен продолжили работу над созданием модели Agile Fluency™, которая объединила в себе их опыт развития навыков в использовании подходов Agile. Модель показывает, что простое применение техник проектного управления, часто именуемых базовым подходом Scrum, дает некую ценность, фокусируя внимание на потребностях клиентов, но не учитывает технических навыков, необходимых для того, чтобы полностью раскрыть преимущества высокой производительности и надежности, которых добиваются многие команды.

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

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

Мартин Фаулер, Chief Scientist, Thoughtworks

Введение

Вопрос: Что нужно делать, чтобы выступить в Карнеги-холле?

Ответ: Практиковаться, практиковаться и еще раз практиковаться.

Я хочу помочь вам овладеть мастерством Agile-разработки.

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

Как можно научиться такому сложному искусству? Практикуясь!

Во-первых, эта книга – руководство. Она содержит подробное описание одного из способов практического применения Agile. Книга основана на экстремальном программировании, но также берет идеи и практики из Scrum, Kanban, DevOps, Lean Software Development, Lean Startup и др. В конечном счете это практическое пособие, которое позволит вам успешно внедрить Agile-разработку в вашу команду и организацию или поможет обнаружить, что Agile не подходит в вашей ситуации.

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

Я не могу спрогнозировать, какую волну поднимет ваш выбор в вашей организации. Я и не пытаюсь. Вы должны сами определить нюансы и достичь понимания. Это единственный способ овладеть искусством. Следуйте практикам. Смотрите, что происходит. Думайте, почему они сработали… или не сработали. Потом повторяйте. Что было таким же? Что получилось по-другому? Почему? Потом делайте это снова. И снова.

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

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

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

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

Для прагматиков

А что, если вы не хотите овладевать так называемым «искусством»? Что, если вы хотите просто разрабатывать хорошее ПО?

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

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

Есть и обратная сторона обсуждения только одного подхода: ни один подход не применим ко всем случаям. Мой совет может быть непригоден для вашей команды или организации. Прочтите главы 4 и 5, чтобы понять, на каких общих условиях возможен успех, и изучите подраздел «Предварительные требования» каждой практики.

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

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

Что нового во втором издании

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

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

Среди наиболее заметных дополнений:

• подробное руководство по внедрению Agile и адаптации этого внедрения к потребностям вашей компании, основанное на модели Agile Fluency™¹, которую я создал вместе с Дианой Ларсен;

• новая глава о масштабировании Agile, основанная на моем опыте помощи большим и маленьким компаниям;

• новая глава о DevOps, содержащая новый материал о работе в сфере эксплуатации и безопасности, а также вдохновленные темой DevOps обновления по остальной части книги;

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

Для кого предназначена книга

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

Книга представляет собой краткий справочник, но ее также можно читать и подряд, от корки до корки. Каждая практика в частях II–IV предназначена для самостоятельного чтения. Блоки «См. также» и ссылки на источники помогут вам сопоставить информацию. Вдобавок печатное издание можно открыть в любом месте и быстро просмотреть интересующую информацию. Можете пролистать книгу и остановиться, чтобы прочитать какую-то врезку более внимательно, если она привлечет ваше внимание.

Если вы менеджер или руководитель высшего звена, который хочет понять, как Agile может или должен работать в вашей компании, то прочитайте часть I. Если вы руководитель командного уровня, то прочтите еще и раздел «Менеджмент» главы 10 и, возможно, другие практики, рассматриваемые в той же главе.

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

Если вы часть Agile-команды и просто хотите получить знания, которые позволят выполнять вашу работу, то можете сосредоточиться на практиках, изложенных в частях II и III. Начните с главы 1, чтобы получить общую картину, затем перейдите к тем практикам, которые использует ваша команда.

Если вы не являетесь частью Agile-команды, но работаете с одной из них, то посоветуйтесь с ними, что почитать. Продакт-менеджеры, владельцы продукта, дизайнеры могут начать с главы 8 и раздела «Цель» главы 7. Сотрудникам отделов безопасности и отделов эксплуатации рекомендую разделы «Сборка для эксплуатации» главы 15, «Обнаружение слепых зон» и «Анализ инцидентов» главы 16. Тестировщики, ознакомьтесь с главой 16.

Если вам просто любопытно узнать об Agile, то начните с главы 1. После этого ознакомьтесь с частями II–IV. Начните с наиболее интересных для вас практик. Можете читать их в любом порядке.

О приглашенных авторах

Эта книга создана в соавторстве с несколькими выдающимися людьми. Гитте Клитгаард написала раздел «Безопасность» главы 7, профессионально осветив тему психологической безопасности. Диана Ларсен написала разделы «Динамики команды» и «Устранение препятствий» главы 11, поделившись своим многолетним опытом организационного и командного развития. Шейн Уорден, мой соавтор первого издания, не смог написать новый материал для второго, но остался надежным и ценным советчиком, и наша работа над первым изданием легла в основу этой книги.

Гитте Клитгаард

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

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

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

Гитте является владельцем Native Wired и руководила преобразованиями в таких компаниях, как LEGO, Spotify и Mentimeter.

Диана Ларсен

Более 20 лет Диана Ларсен вносила свой вклад в формирование основ и расширение идей Agile, а также в практику создания и развития квалифицированных команд. Диана – соавтор книг Agile Retrospectives², Liftoff, 2nd ed., Five Rules for Accelerated Learning и электронной книги The Agile Fluency Model: A Brief Guide to Success with Agile; кроме того, сейчас пишет две новые книги. Будучи главным коучем, консультантом, координатором, спикером и наставником, она продолжает вносить свой вклад и соответствует своему званию в проекте Agile Fluency – «Главное связующее звено» (Chief Connector). Живет в Портленде, на верхнем левом побережье США.

Шейн Уорден

Шейн Уорден – руководитель инженерно-технической службы и писатель, в частности, соавтор первого издания этой книги, а также книги Masterminds of Programming³. В свободное от работы время он помогает находить животным хорошие дома.

Условные обозначения

В книге используются следующие условные обозначения.

Аудитория
В этих блоках указывается целевая аудитория каждой практики Agile.
См. также
В этих блоках приводятся связанные практики.

Курсив

Курсивом выделены новые термины и важные понятия.

Шрифт одной ширины

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

Жирный шрифт одной ширины

Показывает добавленный код в работающих примерах кода.

Перечеркнутый шрифт одной ширины

Показывает удаленный код в работающих примерах кода.

Шрифт без засечек

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

Использование примеров кода

Дополнительные материалы доступны для скачивания по ссылке https://www.jamesshore.com/v2/books/aoad2.

Пожалуйста, напишите по адресу электронной почты bookquestions@oreilly.com, если у вас технический вопрос или проблема с использованием материалов.

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

Мы рекомендуем, но не требуем добавлять ссылку на первоисточник при цитировании. Под ссылкой на первоисточник мы подразумеваем указание авторов, издательства и ISBN.

Получить разрешение на использование значительных объемов программного кода примеров из этой книги можно по адресу permissions@oreilly.com.

Благодарности

Эта книга вдохновлена бессчетным количеством источников. На протяжении всей книги я поблагодарил скольких мог, но наверняка забыл кого-то. (Пожалуйста, примите мои извинения.) Я хочу выразить особую признательность Кенту Беку, Рону Джеффрису и Уорду Каннингему за то, что они создали экстремальное программирование, с которого я начал мое Agile-путешествие. Алистер Коберн и его круглый стол по программному обеспечению, как и бурные споры и обсуждения Вики-страниц C2 Уорда Каннингема, помогли определить направление в начале этого пути. Благодарю также Диану Ларсен, с которой я работаю много лет – ее точка зрения так хорошо уравновешивает мою. И конечно, Мартина Фаулера, чей вдумчивый стиль письма много лет вдохновляет меня.

Поддержка этого издания со стороны O’Reilly была просто исключительной. Я выражаю огромную благодарность Гэри О’Брайену, моему редактору, обеспечивавшему постоянную обратную связь и поддержку. Благодарю также Мелиссу Даффилд, которая помогла сделать так, чтобы книга пользовалась успехом; Райана Шоу, убедившего меня в том, что пришло время для второго издания; Дебору Бейкер, подготовившую издание ранних выпусков книги; Сюзанну Хьюстон, которая позаботилась о том, чтобы люди узнали о книге; Ника Адамса и команду Tools издательства O’Reilly, которые выстроили производственный процесс и успешно разобрались с моими запутанными и придирчивыми требованиями к оформлению; Кристофера Фоучера, который руководил превращением «сырой рукописи» в «законченную книгу»; Тонью Трибулу и Стефани Инглиш, исправивших мои грамматические чудачества; Кейт Дулли, превратившую мои наброски от руки в понятные рисунки.

Что касается обратной связи, особую признательность выражаю моим рецензентам. Рецензирование было открытым, и мы получили более 700 электронных писем от десятков людей. Практически каждое было содержательным и полезным и в результате улучшило книгу. Кроме того, благодарю тех людей, которые ответили на мои прямые запросы на рецензию. Спасибо всем: Адриану Саттону, Энтони Уильямсу, Ави Кесснер, Басу Водде, Бенджамину Мускалла, Биллу Уэйку, Брэду Эпплтону, Си Кейту Рэйю, Си Джею Джеймсону, Кристиану Дювану, Дэйвиду Пулу, Диане Ларсен, Диего Фонтдевиле, Эмили Бач, Эрику Петерсону, «Эвану M.», Францу Амадору, Джорджу Динвидди, Гойко Аджичу, Джейсону Йипу, Джеффу Григгу, Джеффу Паттону, Джеффри Палермо, Йохану Алуддену, Кену Пью, Кришне Кумару, Лиз Кеог, Луизе Нуньес, Марсело Лопесу, Маркусу Гертнеру, Мартину Фаулеру, Михалу Свободе, Николасу Паесу, Полу Стивенсону, Петеру Гравесу, Реувену Ягелю, Рикардо Майерхоферу, Рону Джеффрису, Рону Квартелу, Саре Хоран Ван Треесе, Стиву Бементу, Томасу Джей Оуэнсу, Тодду Литтлу и Уорду Каннингему.

Особая благодарность тем рецензентам, которые пошли еще дальше, прочитав и прокомментировав почти каждую из частей книги: Басу Водде, Биллу Уэйку, Кену Пью, Мартину Фаулеру и Томасу Джей Оуэнсу.

Процесс открытого рецензирования пошел на пользу и первому изданию, и все его преимущества, в свою очередь, отразились и на этой книге. Спасибо Адриану Ховарду, Адриану Саттону, Энн Баркомб, Энди Лестеру, Энтони Уильямсу, Басу Водде, Биллу Капуто, Бобу Коррику, Брэду Эпплтону, Крису Уилеру, Кларку Чингу, Дади Ингольфссону, Диане Ларсен, Эрику Петерсену, Джорджу Динвидди, Илье Прейсу, Джейсону Йипу, Джеффу Олферту, Джеффри Палермо, Джонатану Кларке, Кейт Рэй, Кевину Рутерфорду, Ким Грэсман, Лизе Криспин, Марку Уайтэ, Николасу Эвансу, Филиппе Антрасу, Рэнди Коулмэн, Роберту Шмитту, Рону Джеффрису, Шейну Доуну, Тиму Хоутону и Тони Бирну за их множественные комментарии и Брайану Марику, Кену Пью и Марку Стрейбеку за их замечания по готовому черновику.

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

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

I
Улучшая гибкость

Глава 1. Что есть Agile

Agile везде. И, как ни парадоксально, нигде.

Двадцать лет назад локомотив Agile с ревом ворвался в сознание разработчиков программного обеспечения. За это время количество компаний, называющих себя Agile, возросло на порядки. А сколько команд действительно применяет Agile-подход в своей работе? Не так много. Agile, легко повторяемое название, пользуется огромным успехом. А как насчет идей, стоящих за названием? Вообще-то большинство из них игнорируется.

Исправим это.

Происхождение Agile

В 1990-е считалось, что разработка ПО находится в кризисе. Это явление так и называлось: «Кризис программного обеспечения». Проекты разработки выходили за рамки бюджетов, задерживались, не отвечали требованиям, и (согласно часто цитируемому и зловеще именуемому «Отчету о Хаосе» (CHAOS Report)) почти треть их была полностью отменена [Standish1994].

Agile не был ответом на этот кризис. Отнюдь нет. Agile стал ответным подходом.

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

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

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

Подход, основанный на фазах, получил название водопадной (waterfall development) или каскадной разработки (phase-gate development)⁴. Если вам это кажется похожим на нелепое пугало – считайте, что вам повезло. Не все команды применяли в 1990-х перегруженный документацией каскадный процесс, но он широко признавался как логичный и разумный метод работы. Конечно, нужно было определить требования, разработать проект, затем выполнить реализацию и следом – тестирование. Конечно, нужно было документировать каждую фазу. Это была дисциплина. Это была инженерия. Как еще можно было добиться успеха?

Рожденный из кризиса

Крупные компании расписывали свои процессы в мельчайших деталях. Роли, ответственности, шаблоны документов, языки моделирования, советы по контролю за изменениями… каждый аспект разработки строго регламентировался и контролировался. Если проект заканчивался провалом (а согласно CHAOS Report, менее одной шестой доли проектов были успешны), причиной считалась недостаточная детализация процесса: нужно больше документов, больше согласований. Это порождало огромное количество документации. Мартин Фаулер описывал это в своей статье The Almighty Thud [Fowler1997].

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

И тогда несколько человек создали более простые, изящные и менее директивные методы разработки программного обеспечения. Они назывались легковесными в отличие от тяжеловесных, использовавшихся большими компаниями. Эти методы носили такие названия, как адаптивная разработка программного обеспечения (Adaptive Software Development), Crystal, разработка на основе функциональности (Feature-Driven Development, FDD), метод разработки динамических систем (Dynamic Systems Development Method, DSDM), экстремальное программирование (ХР) и Scrum.

К концу 1990-х эти методы стали привлекать серьезное внимание. Экстремальное программирование, в частности, вызвало вспышку массового интереса среди программистов. В 2001 году 17 сторонников легковесной методологии встретились на горнолыжном курорте в штате Юта, чтобы обсудить объединение усилий.

Манифест Agile

«Лично я не ожидал, что эта конкретная группа [людей] сможет договориться о чем-либо по существу», – позже говорил Алистер Кокберн.

И действительно, за два дня они смогли договориться только о двух вещах: названии Agile и заявлении о четырех ценностях новой методологии (рис. 1.1). В течение следующих нескольких месяцев, переписываясь по электронной почте, эти люди сформулировали 12 сопутствующих принципов (рис. 1.2) [Beck2001].

Рис. 1.1. Ценности Agile

Рис. 1.2. Принципы Agile

Это стало Манифестом Agile, который изменил мир. «Таким образом, – продолжил Алистер, – они в конце концов все же смогли договориться о чем-то по существу»⁵.

Однако единого метода Agile не было. Его никогда не было и никогда не будет. Agile подразумевает три составляющие: название, ценности и принципы. И все. Это не что-то, что можно делать. Это философия. Это способ мышления, посвященный разработке программного обеспечения. Невозможно «использовать» Agile или «делать» Agile… вы только можете быть Agile. Или не быть. Если ваши команды воплощают философию Agile, то вы – Agile. Если не воплощают – то нет.

Суть Agile

Мартин Фаулер сделал карьеру, превращая сложные вопросы о программировании в тщательно продуманные, беспристрастно точные объяснения. Его определение «Суть разработки программного обеспечения по Agile» – одно из лучших:

Agile-разработка является скорее адаптивной, чем предиктивной; ориентированной скорее на людей, чем на процессы⁶.
Мартин Фаулер

Адаптивность вместо предиктивности

Помните, в CHAOS Report утверждалось, что всего одна шестая часть проектов в области программного обеспечения успешна? В отчете успешность определена очень специфическим образом:

• успешный – проект выполнен вовремя и в рамках бюджета, все характеристики и функциональности соответствуют изначально запланированным;

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

неуспешный – проект отменен в какой-либо момент в течение цикла разработки.

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

На первый взгляд, это разумно. Но посмотрим повнимательнее. Тут чего-то не хватает. Райан Нельсон писал в журнале CIO Magazine [Nelson2006]:

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

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

Взгляните еще раз на Манифест (см. рис. 1.1 и 1.2). Найдите пару минут, чтобы вдумчиво изучить ценности и принципы Agile. Сколько из них относятся к поставкам ценного программного обеспечения и адаптации к полученной обратной связи?

Ориентированность на людей, а не на процессы

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

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

У Agile-команд тоже есть процессы (у любой команды они есть, пусть и неявные), но они находятся на службе у человека, а не наоборот. И Agile-команды сами отвечают за свои процессы. Желая улучшить методы работы, люди меняют процессы.

Посмотрите на Манифест еще раз (см. рис. 1.1 и 1.2). Какие ценности и принципы имеют отношение к концепции «люди на первом месте»?

Почему Agile победил

В течение первых десяти лет после появления Манифеста Agile столкнулся с небывалой критикой. Его называли «недисциплинированным». Говорили, что он никогда не будет работать. Следующие десять лет критики молчали. Agile был уже везде, по крайней мере это название. Тяжеловесные водопадные методы практически умерли. Молодые программисты вообще не верили в то, что кто-то когда-то мог работать таким образом.

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

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

В случае тяжеловесных процессов придавалось настолько большое значение контролю над процессами и согласованию документации, что порождались значительные задержки и расходы. На то, чтобы получить работающее ПО, уходили годы, и заказчику не показывали ничего конкретного почти до самого конца проекта. Вместо того чтобы приветствовать изменения, в этих процессах делалось все, чтобы их избежать. Была даже отдельная составная часть процессов «Совет по контролю за изменениями» (Change Control Board), чьей основной задачей было сказать «нет» запросам на изменения. (Точнее, «да, но за это понадобится доплатить».)

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

Типичный провал тяжеловесного процесса
Третьего февраля 2005 года Роберт С. Мюллер III, директор Федерального бюро расследований, предстал перед подкомитетом Сената США, чтобы объяснить, как ФБР умудрилось потратить впустую 104,5 миллиона долларов⁷.
Это явно было не комфортно для компании. В июне 2001-го ФБР запустило проект VCF с целью заменить программное обеспечение для управления делами. Через четыре года он был отменен. Общие затраты составили 170 миллионов долларов; 104,5 миллиона из них были полностью невозвратными.
Сроки и последовательность событий проекта могут рассказать нам хорошо знакомую историю. Проект начался в июне 2001 года. Через 17 месяцев, в ноябре 2002-го, были определены «четкие требования». Программное обеспечение было поставлено год спустя, в декабре 2003-го, но «ФБР сразу обнаружило некоторое количество недостатков в VCF, которые делали его непригодным для использования». Подрядчик, разрабатывавший программу, согласился исправить недостатки, но только за дополнительную плату в размере 56 миллионов долларов и в срок один год. В конце концов ФБР отказалось от идеи исправлять недочеты, фактически перечеркнув годы работы.

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

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

Почему Agile работает

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

«Если коротко, то экстремальное программирование обещает снизить риски проекта, улучшить отклик на потребности бизнеса и повысить продуктивность в течение всего срока жизни системы, сделать приятным создание ПО в команде – и все это одновременно. Это правда. Прекратите смеяться» [Beck2000a].
Extreme Programming Explained, первое издание

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

Экстремальное программирование было живым примером Agile, заложившим основу идей и терминологии, которые используются до сих пор. Однако сила сообщества Agile в том, что оно всегда было широкой коалицией. Agile не ограничивается каким-то одним методом. Он постоянно расширяется, включая в себя новых людей и свежие идеи. «Бережливая разработка программного обеспечения» (Lean software development), Scrum, Kanban, «Бережливый стартап» (Lean Startup), DevOps и многие-многие другие подходы внесли свой вклад в то, что сейчас известно под общим названием Agile.

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

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

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

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

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

• Совершенствуйте ваши процессы. Экспериментируйте с новыми идеями. Настраивайте и адаптируйте то, что работает. Никогда не считайте, что отлаженный, популярный способ будет самым лучшим и для вас.

Agile определяется Манифестом, но сам Манифест – лишь начальная точка. Agile работает потому, что люди заставляют его работать. Они берут идеи Agile, адаптируют их к своим ситуациям и не перестают совершенствоваться.

Почему Agile терпит неудачу

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

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

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

Карго-культы
Корни этой истории уходят в 1940-е⁸, когда американские войска высадились на далеком острове. Местные жители никогда не встречались с современной цивилизацией, и люди и материалы, привезенные союзными войсками, изумили аборигенов. Они наблюдали, как солдаты строили взлетно-посадочную полосу и башню управления воздушным трафиком, надевали наушники и вызывали с небес на землю больших металлических птиц, нагруженных ценным грузом (карго). Когда птицы приземлялись, часть груза распределялась между всеми островитянами, благодаря чему те жили в благополучии и комфорте.
Однажды войска покинули остров, и большие металлические птицы перестали прилетать. Успевшие привыкнуть к комфорту островитяне сплели из бамбука собственную взлетно-посадочную полосу. Они построили высокую платформу, посадили на нее своего вождя и надели ему на голову кокосы, которым придали форму наушников. Но как бы ни старались островитяне, большие металлические птицы так больше никогда и не вернулись.

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

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

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

Так и получается карго-культ. Много действий, ноль результата. Относящаяся к Agile составляющая отсутствует.

«В моей предыдущей компании огромное количество человеко-часов тратилось на совещания».
«Из-за этого [Agile] целая команда (30+ человек) лишилась работы, поскольку они не произвели почти ничего в результате почти года работы».
«Все это [Agile] означает, что разработчиков просто обманули, когда проект изменился… за день до поставки».
Реальные комментарии об Agile из сети

Слово Agile – повсюду. Идеи Agile – нет. Это вечный самообман для многих: единственный Agile, который они знают, – это карго-культ Agile.

Настало время это исправить. В этой книге я расскажу вам, как применять идеи Agile по-настоящему. Будьте начеку, чтобы не поддаться поборникам карго-культа Agile, которых вы встретите в книге. Они покажут вам, как делать не надо.

Готовы? Поехали.

Глава 2. Как быть Agile

Как перейти от нагромождения Agile-идей к реальным, действующим Agile-командам?

Нужна практика. Очень много практики.

Практика Agile

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

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

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

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

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

Как достичь мастерства

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

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

1. Выберите для освоения подгруппу идей Agile. Глава 3 поможет вам определиться.

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

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

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

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

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

Рис. 2.1. Как достичь мастерства

С чего начать?

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

Присоединение к действующей команде Agile

Если вы планируете присоединиться к действующей Agile-команде или просто хотите дополнить свои знания о том, как Agile работает на практике, то можете перейти к частям II–IV. Каждая часть начинается с истории в стиле «один день из жизни», описывающей, как может выглядеть Agile. Команды, работающие по Agile, отличаются друг от друга, поэтому и ваша не будет абсолютно такой же. Но эти истории дадут вам представление, чего можно ожидать.

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

Введение Agile

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

Сначала убедитесь, что Agile подходит вашей компании:

• выберите подход Agile, который ваша организация сможет поддерживать (см. главу 3);

• определите, что ей нужно сделать, чтобы успешно внедрить Agile (см. главу 4);

• получите согласие на эксперимент с Agile (см. главу 5);

• если у вас несколько команд, то решите, как вы будете их масштабировать (см. главу 6).

За несколько недель до начала:

• определитесь, кто будет коучем (или коучами) команды, и выберите по меньшей мере одного человека, который будет продакт-менеджером (см. раздел «Вся команда» главы 7);

• организуйте встречу продакт-менеджера с исполнительным спонсором команды и ключевыми стейкхолдерами, чтобы разработать замысел проекта (см. раздел «Цель» главы 7);

• обеспечьте команде физическое или виртуальное помещение (см. раздел «Командная комната» главы 7);

• запланируйте и проведите сессию подготовки устава команды (см. врезку «Планирование сессии подготовки устава» в главе 7);

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

Когда команда будет готова начать, сделайте глубокий вдох и:

• поручите членам команды спланировать первую рабочую неделю (см. подраздел «Ваша первая неделя» главы 9).

Совершенствование действующих Agile-команд

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

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

В качестве руководства используйте чек-листы из предыдущего подраздела «Внедрение Agile» данной главы.

Если Agile не срабатывает в вашей организации, то ознакомьтесь с врезкой «Руководство по устранению неполадок» в главе 4.

Применение отдельных практик Agile

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

• Ежедневное планирование. Если вы боретесь с частыми прерываниями (interruptions), то попробуйте использовать однодневные итерации (см. раздел «Планирование задач» главы 9). Возьмите за основу игру в планирование (см. раздел «Игра в планирование» главы 8) и измеряемый потенциал (capacity) по работе вашей команды на спринте (см. раздел «Потенциал» главы 9) и проводите совместные сессии планирования в начале каждого дня, откладывая все прерывания на сессию планирования следующего дня. Обеспечьте условия, чтобы люди сами оценивали свои задачи.

Итерации. Если частые прерывания для вас не проблема, но вы все же хотели бы улучшить свое планирование, то попробуйте использовать недельные итерации (см. раздел «Планирование задач» главы 9). В этом случае вы также можете практиковать ежедневные рабочие стендап-митинги (см. раздел «Стендап-митинги» главы 9) и регулярные демо для стейкхолдеров (см. раздел «Демо для стейкхолдеров» главы 10). Со временем рассмотрите возможность использования индексных карточек для планирования и больших диаграмм, показывающих предстоящую работу, как описано в разделе «Визуальное планирование» главы 8.

Ретроспективы. Частое проведение ретроспектив (см. раздел «Ретроспективы» главы 11) – отличный способ адаптировать и улучшить рабочие процессы команды. Могут быть полезны и другие практики, перечисленные в главе 11.

Быстрая обратная связь. Быстрая автоматизированная сборка значительно улучшит вашу жизнь, а также откроет возможности для других усовершенствований (см. раздел «Нулевое трение» главы 13).

Непрерывная интеграция. Непрерывная интеграция (практика, а не инструмент) не только уменьшает проблемы интеграции, но и способствует повышению качества сборок и тестов. Более подробную информацию см. в разделе «Непрерывная интеграция» главы 13.

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

Другие практики, описанные в частях II–IV, также могут оказаться полезными. Agile-практики объединены множеством зависимостей друг от друга, поэтому обязательно обратите внимание на блоки «См. также» и подраздел «Предварительные требования» каждой практики.

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

Глава 3. Выберите свою гибкость

Нет смысла использовать Agile ради него самого. Задайте себе два вопроса.

1. Поможет ли нам Agile стать более успешными?

2. Чего нам будет стоить достижение этого успеха?

Ответив на эти вопросы, вы поймете, нужен ли вам Agile.

Что ценно для организаций?
Успех определяется не только доходами. Вот только несколько составляющих успеха:
• улучшение финансовых результатов – прибыль, рост выручки, биржевая стоимость акций, снижение затрат;
• достижение целей организации – стратегические цели, оригинальные исследования, благотворительные цели;
• укрепление позиций на рынке – продвижение бренда, конкурентные различия, лояльность существующих клиентов, привлечение новых;
• обретение популярности – стратегическая информация, аналитика, отзывы клиентов;
• снижение риска – безопасность, требования законодательства, аудит;
• увеличение потенциала – наем и удержание персонала, моральный климат и развитие навыков, автоматизация.

Модель Agile Fluency

В 2014 году я сотрудничал с Дианой Ларсен, чтобы проанализировать, почему компании видят разные результаты от их Agile-команд. Мы оба работали с командами с самого начала. С годами мы заметили, что команды начинали склоняться к кардинально разным типам результатов и эти результаты имели тенденцию группироваться в разных «зонах».

Мы обобщили эти наблюдения в модели Agile Fluency™. Ее упрощенный вариант показан на рис. 3.1 [Shore2018b].

Рис. 3.1. Упрощенная модель Agile Fluency™

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

ПРИМЕЧАНИЕ
Несмотря на то что на рис. 3.1 представлен прямой путь от одного уровня к другому, в реальности все более беспорядочно. Команды могут достигать уверенного владения навыками на любом уровне, в любом порядке, хотя продвижение, показанное на рис. 3.1, типично.

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

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

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

Вероятнее всего, вам не удастся убедить вашу компанию инвестировать в каждый уровень. Это нормально. В отличие от моделей зрелости (maturity models), таких как интегрированная модель зрелости возможностей компании при разработке ПО (Capability Maturity Model Integration, CMMI), модель Agile Fluency™ не показывает продвижения от слабых навыков к сильным. Вместо этого она демонстрирует множество вариантов соотношения инвестиций/выгоды. Хотя диаграмма показывает наиболее распространенный вариант продвижения, каждый уровень можно выбрать независимо. Каждый имеет ценность сам по себе.

Уровень владения навыками и степени зрелости
Свободное владение навыками – это свойство, присущее команде, а не одному индивидууму. Свободное владение навыками не означает, что каждый член команды обладает каждым навыком, связанным с данным уровнем. Вместо этого им нужна способность, будучи командой, привлекать к работе правильных людей в правильное время.
Каждый уровень имеет несколько степеней зрелости.
1. Обучение – команда изучает нужные навыки.
2. Профессионализм – команда может продемонстрировать нужные навыки, когда она концентрируется на них.
3. Свободное владение – команда демонстрирует нужные навыки автоматически, не прикладывая осознанных усилий, при условии, что в команде есть коуч.
4. Самостоятельное свободное владение – команда демонстрирует нужные навыки автоматически, не нуждаясь в присутствии в команде коуча.

Уровень фокусировки (Focusing)

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

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

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

Чтобы команды вашей организации достигали успеха, понадобится поддерживать перемены конкретными инвестициями в форме изменения командной структуры, системы управления и рабочей среды. (Я подробно расскажу об этом в следующей главе.) Это ситуация в стиле «хорошие новости и плохие новости»: плохие новости в том, что когда доходит до дела, у многих организаций пропадает желание инвестировать. А хорошие новости таковы: если они отказываются, то вы понимаете сразу, на начальном этапе, что на самом деле они не готовы к погружению в философию Agile. Вы просто избавили себя от долгих лет разочарований и душевной боли, которые пришлось бы испытать, следуя за карго-культом Agile.

Если же вам удастся получить поддержку, то владение навыками на уровне фокусировки может быть достигнуто каждой командой примерно за 2–6 месяцев целенаправленных усилий. При должной поддержке они превзойдут свой предыдущий уровень производительности даже в течение 1–4 месяцев¹⁰. В части II приведены практики, которые могут им понадобиться.

Уровень поставки (Delivering)

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

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

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

Если ваша компания сделает эти инвестиции, то на достижение владения навыками на уровне поставки у ваших команд уйдет от 3 до 24 месяцев, и повышение производительности вы сможете увидеть в течение 2–6 месяцев. Точное количество времени, которое понадобится каждой команде, зависит от текущего качества ее кода и от того, сколько у нее будет коучей. Часть III содержит нужные практики.

Уровень оптимизации (Optimizing)

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

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

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

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

Уровень укрепления (Strengthening)

Есть еще один последний уровень в модели Agile Fluency™. Он во многом теоретичен: это возможное будущее Agile. Кроме того, он подходит только для организаций, находящихся на переднем крае теории и практики управления. Это обстоятельство выводит данный уровень за рамки темы этой книги. Вкратце, уровень укрепления предполагает переработку коллективных идей команд и направление их в организационные улучшения. Если вы хотите узнать об этом больше, то прочтите главу 19.

Уровни свободного владения навыками Agile, резюме
Фокусировка
• Основные преимущества: фокус на бизнес-приоритеты, наглядность работы команды, способность менять направление.
• Инвестиции: структура команд, управление, рабочая среда.
• Примерные сроки: падение производительности на 1–4 месяца, достижение владения наыками в течение 2–6 месяцев.

Поставка
• Основные преимущества: мало дефектов и высокая производительность, техническая долговечность.
• Инвестиции: навыки разработки, слияние тестирования и эксплуатации.
• Примерные сроки: падение производительности на 2–6 месяцев, достижение владения навыками в течение 3–24 месяцев.

Оптимизация
• Основные преимущества: повышение уровня ценности релизов и улучшенные продуктовые решения.
• Инвестиции: встроенное управление продуктом, команда несет ответственность за бюджет и планы.
• Примерные сроки: падение производительности на 1–3 месяца, достижение владения навыками в течение 3–9 месяцев.

Выберите свои уровни

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

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

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

Какие же уровни вам все-таки выбрать?

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

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

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

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

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

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

Глава 4. Инвестируйте в гибкость

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

Если это выглядит как очень трудозатратное дело… что ж, так и есть. Неужели эти инвестиции действительно настолько важны?

Да, действительно настолько.

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

Как сказал Мартин Фаулер¹¹, «я вижу поразительную параллель между ДХХ (Давид Хейнемейер Ханссон, создатель Ruby on Rails) и Кентом Беком (создатель экстремального программирования). Любой из них, получив в подарок ограниченный мир, посмотрит на его ограничения, которые мы принимаем как должное, сочтет их несущественными и создаст новый мир без них… они просто подложат под них заряд интеллектуального динамита и двинутся дальше. Именно поэтому они могут создавать такие вещи, как экстремальное программирование и Rails, которые встряхивают всю индустрию».

Делайте инвестиции – в них секрет успеха Agile.

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

Список необходимых инвестиций
Все команды Agile
• Получите поддержку руководства, команд и ключевых стейкхолдеров, как описано в главе 5.
• Создайте долговечные кросс-функциональные команды и все время назначайте людей только в эти команды (см. раздел «Выберите или создайте Agile-команды» текущей главы).
• Предоставьте каждой команде коуча, который поможет ей научиться быть эффективной слаженной командой (см. раздел «Выберите Agile-коучей» текущей главы).
• Поручайте работу командам, а не отдельным людям. Ожидайте от команд самостоятельного выбора подхода к ежедневному планированию и распределению задач (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).
• Направьте усилия руководителей командного уровня на управление общей системой работы вместо управления отдельными людьми и задачами (см. раздел «Измените стиль управления командой» текущей главы).
• Организуйте физические или виртуальные рабочие помещения для каждой команды (см. раздел «Организуйте рабочие помещения» текущей главы).
• Для получения первого опыта работы в Agile выберите командам значимую, но несрочную задачу (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы).
• Замените водопадные политики управления на политики управления Agile (см. раздел «Смените водопадные подходы в управлении» текущей главы).
• Удалите, пересмотрите или научитесь обходить политики отдела кадров, препятствующие эффективной командной работе (см. раздел «Измените вредные кадровые политики» текущей главы).
Команды фокусировки
• Рассчитывайте на 1–4 месяца пониженной производительности каждой команды (см. раздел «Найдите время на обучение» текущей главы).
• Включите в команду людей, имеющих навыки в сфере деятельности пользователей и заказчиков (см. раздел «Выберите или создайте Agile-команды» текущей главы).
• Убедитесь, что в каждой команде есть тот, кто принимает решение, над чем команда будет работать, или команда имеет к нему свободный доступ (см. раздел «Выберите или создайте Agile-команды» текущей главы).
• Предоставьте каждой команде коуча, который сможет научить ее практикам фокусировки (см. раздел «Выберите Agile-коучей» текущей главы).
• Обеспечьте каждой команде доступ к стейкхолдерам или их представителям (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).
Команды поставки
• Рассчитывайте на 2–6 месяцев пониженной производительности каждой команды (см. раздел «Найдите время на обучение» текущей главы).
• Объедините в каждой команде все нужные навыки разработки, такие как тестирование и эксплуатация (см. раздел «Выберите или создайте Agile-команды» текущей главы).
• Предоставьте каждой команде коуча, который сможет научить ее практикам поставки (см. раздел «Выберите Agile-коучей» текущей главы).
• Доверьте каждой команде контроль над ее процессами разработки, сборки, тестирования и релиза (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).
• Для получения первого опыта работы в Agile выберите задачу, предполагающую написание кода с нуля (green-field codebase), если коуч не сочтет, что в этом нет необходимости (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы).
• Разберитесь с вопросами безопасности, которые мешают коллективной разработке (см. раздел «Решите проблемы, связанные с безопасностью» текущей главы).
Команды оптимизации
• Рассчитывайте на 1–3 месяца пониженной производительности каждой команды (см. раздел «Найдите время на обучение» текущей главы).
• Включите в команду экспертов в области бизнеса, рынка и продукта (см. раздел «Выберите или создайте Agile-команды» текущей главы).
• Предоставьте каждой команде коуча, который сможет научить ее практикам оптимизации (см. раздел «Выберите Agile-коучей» текущей главы).
• Передайте каждой команде ответственность за ее бюджет, планы и результаты (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).

Найдите время на обучение

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

Насколько они замедлятся? Объективных критериев продуктивности в разработке программного обеспечения нет [Fowler2003], но, исходя из моего опыта, я бы предположил снижение на 10–20 % на первых порах. По мере освоения знаний и навыков Agile производительность команд будет расти. Она будет увеличиваться, пока команды не достигнут уверенного владения навыками, и тогда рост постепенно начнет выравниваться (рис. 4.1). Это называется J-кривой, и она характерна для всех значительных изменений. В главе 5 мы более подробно рассмотрим эти изменения.

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

• фокусировка – 1–4 месяца;

поставка – 2–6 месяцев;

• оптимизация – 1–3 месяца.

Рис. 4.1. Изменение производительности в Agile с течением времени

Эти периоды пересекаются, поэтому команда, обучающаяся навыкам фокусировки и поставки одновременно, будет менее продуктивна в течение 2–6 месяцев. Для сравнения: команда, которая сначала изучает фокусировку и позже переходит к обучению поставке, продемонстрирует два спада: 1–4 месяца – при обучении фокусировке и затем 2–6 месяцев – при обучении поставке.

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

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

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

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

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

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

Если нет времени на обучение…

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

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

Если нет средств на финансовую помощь…

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

Отберите или создайте Agile-команды

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

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

• кросс-функциональными – члены команды в совокупности обладают всеми знаниями, которые нужны ей для достижения цели;

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

сплоченными – отношения между членами команды дружеские, конструктивные, позволяющие сотрудничать;

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

Размер и состав каждой команды зависят от того, какие уровни свободного владения навыками вы выбрали. В разделе «Вся команда» главы 7 представлены все подробности. Краткое описание команд выглядит следующим образом.

• Команды фокусировки концентрируются на достижении бизнес-результатов. Им нужны люди, способные поставить себя на место пользователей и заказчиков, чтобы точно понять, что должно делать программное обеспечение. Если команда работает над задачей, ориентированной на пользователя, необходимы специалисты, имеющие навыки UI/UX (UI – User Interface – «пользовательский интерфейс», UX – User Experience – «опыт пользователя»). Команды также должны иметь способ определять, чем заниматься дальше. Лучше всего, если в команде есть люди с навыками и полномочиями, позволяющими делать это самостоятельно, однако члены команды могут работать и с кем-то извне.

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

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

Возможно, у вас уже есть команды, которые отвечают всем требованиям. Если вы собираете новые Agile-команды, то можете выполнить шаги, описанные ниже. В любом случае вам понадобится вовлечь команду в процесс, как описано в разделе «Заинтересуйте команду» главы 5.

1. Определите цель каждой команды (см. раздел «Цель» главы 7).

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

3. Определите, какие навыки нужны в каждой команде.

4. Выберите людей с соответствующими навыками, которые наверняка смогут сотрудничать и хотят попробовать работу в Agile.

Если вы создаете или реорганизуете множество команд, то позвольте командам провести самостоятельный отбор. Этот способ удивительно эффективен в создании высокопродуктивных команд, которые будут в восторге от совместной работы. В книге Creating Great Teams: How Self-Selection Lets People Excel [Mamoli2015] рассказывается, как это работает.

Если вы не можете закрепить людей за определенной командой…

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

Если члены команды не ладят друг с другом…

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

Если вы не можете создать долгосрочную команду…

Разбивать отлично работающую команду – расточительно, но это не помешает вашим командам быть Agile.

Если вы не можете получить необходимых экспертов со знанием бизнеса, клиентов или пользователей…

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

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

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

Если вы не можете получить необходимые вам навыки разработчиков…

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

Выберите Agile-коучей

Каждой команде нужен коуч, который поможет ей научиться быть эффективной Agile-командой. В подразделе «Навыки коучинга» главы 7 содержатся подробности. Краткое описание коуча представлено ниже.

• Каждой команде необходим тот, кто может помочь ей научиться быть эффективной и сплоченной.

• Командам фокусировки нужен тот, кто может научить практикам планирования, описанным в части II.

• Командам поставки нужен тот, кто может научить техническим практикам, изложенным в части III.

• Командам оптимизации нужен тот, кто сможет научить практикам развития бизнеса, описанным в части IV.

Некоторые коучи могут охватить сразу несколько категорий. Каждый коуч может работать с одной или двумя командами.

Если вы не можете нанять на работу нужных вам коучей…

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

Делегируйте полномочия и ответственность команде

Уважение к человеческим способностям лежит в центре философии Agile, и нигде это не очевидно настолько, как в подходе Agile к полномочиям и ответственности.

Секрет первоклассного выполнения работы заключается в правильном понимании деталей, а никто не понимает их лучше, чем непосредственные исполнители этой работы… Имея необходимую квалификацию и направляемые лидером, они будут принимать наилучшие технические решения и воплощать их лучше, чем кто-либо другой смог бы сделать за них [Poppendieck2003].
Мэри и Toм Поппендик

С точки зрения организационных инвестиций это означает следующее.

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

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

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

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

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

Если работу нужно поручить отдельным людям…

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

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

Если корпоративные инструменты не поддерживают командную работу…

Если в вашей компании используется система распределения задач, которую невозможно заменить, то одним из вариантов краткосрочного решения проблемы может стать создание для каждой команды «фантомного» человека, чтобы он принимал командные задачи. Другой вариант – члены команды могут рассматривать получаемые индивидуальные задания как командные.

В долгосрочной перспективе лучше все же исправить корпоративную программу.

Если команды должны использовать корпоративный инструмент отслеживания…

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

Принуждение Agile-команд к использованию корпоративных инструментов отслеживания в их повседневной деятельности снижает их производительность. Если у вас нет выбора в этом вопросе, то можно применять две отдельные системы отслеживания: одну для легковесного подхода Agile и основную корпоративную систему. Более подробная информация доступна в подразделе «Корпоративные системы отслеживания» главы 10.

Если у команды нет доступа к стейкхолдерам…

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

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

Если команда поставки не управляет своим процессом релиза…

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

Если команда оптимизации не управляет своими планами создания продукта и расходами…

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

Измените стиль управления командой

Когда команды сами определяют свои процессы, назначают себе задачи и координируют работу со стейкхолдерами, менеджеры командного уровня могут подумать, что им нет места в Agile. Но это далеко не так. Работа руководителя группы в Agile различается, но она не менее важна, чем в команде периода «до Agile». Больше информации об этом можно найти в разделе «Менеджмент» главы 10.

Поговорите с менеджерами об их новой роли и предложите им тренинг, если необходимо. Убедитесь, что их ожидания тоже соответственно изменились.

Если менеджеры не могут отпустить ситуацию…

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

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

Организуйте рабочие помещения

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

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

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

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

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

Если команда удаленная…

Вы можете создать виртуальную командную комнату. В подразделе «Виртуальные командные помещения» главы 7 рассказывается, как это сделать.

Если вы не можете организовать физическое помещение для офисной команды…

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

Выберите команде подходящую для обучения задачу

У любой команды есть цель: ее место в общей стратегии организации. (См. раздел «Цель» главы 7.) Когда команда только начинает учиться Agile, важно выбрать цель, которая поможет в учебе. В практическом смысле это означает три вещи.

• Цель, имеющая ценность, но не срочная. Если команда будет сильно ограничена во времени, то ей будет трудно учиться. Члены команды по умолчанию вернутся к тому, что у них хорошо получалось в прошлом, чем будут тратить время на воплощение новых идей.

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

• Совершенно новая кодовая база (green-field codebase). Команды, изучающие практики поставки, должны многому научиться, и это проще делать с нуля. В конце концов им придется научиться работать с существующим кодом. Команды, у которых есть опытный коуч в области поставки, могут игнорировать это требование, если тот согласится. Таким же образом могут поступить и те команды, которые изучают уровни, отличные от поставки.

Если есть важный дедлайн…

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

Если нет значимой работы с нуля…

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

Смените водопадные подходы в управлении

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

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

Если требуется водопадная модель управления…

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

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

Как добиться успеха, используя водопадную модель
Agile подходит далеко не для каждой компании. И это нормально! Можно добиться успеха, используя водопадную модель. Если вы в компании, которой нужны предварительные планы или культура которой – «командуй и контролируй», то водопадная модель может быть более уместной.
Наиболее безопасно использовать итеративный водопад. Вместо того чтобы реализовывать один большой водопадный проект, что довольно рискованно, начните серию небольших водопадных проектов. Каждый должен длиться не больше 3–6 месяцев и завершаться работающим программным обеспечением, действительно пригодным для выхода на рынок. Каждый проект должен содержать стандартные фазы водопада: анализ требований, архитектура и дизайн, реализация, тестирование – или тот вариант фаз, который предпочитает ваша компания.
Водопадная модель работает наилучшим образом в хорошо изученных предметных областях при наличии небольшой неопределенности. Постарайтесь взять на работу людей, весьма опытных в создании именно того типа программного обеспечения, который вы собираетесь реализовывать.

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

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

Измените вредные HR-политики

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

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

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

Такие особенности корпоративной культуры часто отражены в HR-политиках (Human Resources, HR) в части продвижения и поощрения. Если карьера людей зависит от внешней причины, независимо от их реального влияния на производительность команды, то у ваших команд, вероятно, будут трудности в совместной работе по Agile.

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

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

Если HR-политики не подлежат изменению…

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

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

Решите проблемы, связанные с безопасностью

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

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

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

С этим связана проблема возможности отслеживания. Некоторые компании требуют, чтобы каждое внесенное изменение (commit) можно было отследить до его автора. Это требование можно выполнить, добавив инициалы или адрес электронной почты в коммит-комментарий команды. У Git есть соглашение о том, чтобы добавлять строку Co-authored-by в конце каждого коммит-сообщения¹³.

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

Если требования безопасности не допускают гибкости…

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

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

Если вам требуется дополнительный этап ревью кода…

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

Руководство по устранению неполадок
Если Agile не работает для ваших команд и особенно если вы замечаете одни и те же проблемы в нескольких командах, то причина, вероятно, в недостаточных инвестициях. Ваши команды в большинстве случаев могут сами вам сказать, что им мешает, но если нет, то сверьтесь со списком часто встречающихся проблем, который приводится ниже.
Члены команды не пытаются применять новые практики
Команда не заинтересовалась Agile (см. «Заинтересуйте команду» главы 5); или
В команде нет коуча, который может научить ее практикам (см. раздел «Выберите Agile-коучей» текущей главы); или
На команду слишком давят, чтобы она давала результат (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы).
Внутри команды слишком много конфликтов
Команды слишком часто переформируются (см. раздел «Выберите или создайте Agile-команды» текущей главы); или
Команда испытывает слишком большое давление (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или
Менеджеру команды приходится постоянно помогать улаживать конфликты (см. раздел «Измените стиль управления командой» текущей главы); или
Политики отдела кадров поощряют конкуренцию (см. раздел «Измените вредные кадровые политики» текущей главы).
Члены команды не сотрудничают друг с другом
Команда не заинтересовалась Agile (см. раздел «Заинтересуйте команду» главы 5); или
Члены команды не имеют возможности посвятить все свое время команде или не ладят друг с другом (см. раздел «Выберите или создайте Agile-команды» текущей главы); или
В команде нет коуча, который может научить ее сотрудничеству (см. раздел «Выберите Agile-коучей» текущей главы); или
Распределение или отслеживание задач требует индивидуальной работы (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или
Рабочее пространство не подходит команде (см. раздел «Организуйте рабочие помещения» текущей главы); или
Команда испытывает слишком большое давление (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или
Менеджер команды раздает индивидуальные задания (см. раздел «Измените стиль управления командой» текущей главы); или
HR-политики поощряют индивидуальную работу (см. раздел «Измените вредные кадровые политики» текущей главы).
Команда тратит слишком много времени на предварительную оценку, планирование и отслеживание работ
Команда вынуждена использовать корпоративную систему отслеживания задач (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или
От команды требуют составления предварительных планов и детальных прогнозов (см. раздел «Смените водопадные подходы в управлении» текущей главы); или
Команде нужно развивать свободное владение навыками на уровне фокусировки (см. часть II).
Программное обеспечение, созданное командой, не делает то, что нужно стейкхолдерам
У команды нет доступа к нужному представителю бизнеса, или ей нужны люди с большим опытом в сфере деятельности заказчика и пользователей (см. раздел «Выберите или создайте Agile-команды» текущей главы); или
В команде нет коуча, который может научить ее работе со стейкхолдерами (см. раздел «Выберите Agile-коучей» текущей главы); или
У команды нет доступа к стейкхолдерам (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).
Команде тяжело привлекать внимание стейкхолдеров
Стейкхолдеры не поддержали инициативу с Agile (см. раздел «Заручитесь поддержкой стейкхолдеров» главы 5); или
У команды отсутствуют необходимые навыки в сфере деятельности заказчика (см. раздел «Выберите или создайте Agile-команды» текущей главы); или
Стейкхолдеры не считают работу команды актуальной или значимой (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы).
Программное обеспечение, созданное командой, делает то, что хотят заказчики и пользователи, но не имеет коммерческого успеха
У команды нет доступа к нужному представителю бизнеса или опыта в бизнесе (см. раздел «Выберите или создайте Agile-команды» текущей главы); или
Команде нужна более подходящая цель (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или
Команде нужно развивать свободное владение навыками на уровне оптимизации (см. часть IV); или
Команда свободно владеет навыками в оптимизации, но не может контролировать свои планы и расходы (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).
Программное обеспечение, разрабатываемое командой, имеет очень долгие циклы выпуска версий, много багов или эксплуатационные проблемы
В команде нет людей, уверенно владеющих навыками на уровне поставки (см. раздел «Выберите или создайте Agile-команды» текущей главы); или
В команде нет коуча, который может научить ее практикам поставки (см. раздел «Выберите Agile-коучей» текущей главы); или
Команде нужно развивать свободное владение навыками на уровне поставки (см. часть III); или
Команда свободно владеет навыками на уровне поставки, но не может полностью контролировать свою разработку, выпуск версий и эксплуатацию (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или
Команда учится работать с существующим кодом (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы).
Разработка идет медленнее, чем ожидалось
Команда завершает предыдущие задачи, которые были до Agile, или все еще учится (см. раздел «Найдите время на обучение» текущей главы); или
Команде нужно больше коучинга (см. раздел «Выберите Agile-коучей» текущей главы); или
Рабочее пространство не подходит командам (см. раздел «Организуйте рабочие помещения» текущей главы); или
Команде нужно развивать свободное владение навыками на уровне поставки (см. часть III); или
Команда не может полностью контролировать свой процесс разработки (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или
Команда работает с существующим кодом (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или
Команда ограничена требованиями руководства, отданными на высоком уровне (см. раздел «Смените водопадные подходы в управлении» текущей главы); или
Команда ограничена требованиями безопасности (см. раздел «Решите проблемы, связанные с безопасностью» текущей главы).

Глава 5. Инвестируйте в изменения

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

Осознание изменений

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

Понять, как люди реагируют на изменения, можно с помощью модели изменений Вирджинии Сатир (рис. 5.1)¹⁴. Согласно рисунку, существует пять ступеней перемен. Они применимы к Agile следующим образом.

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

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

3. Хаос. Проект изменений одобрен, и команды начинают использовать практики Agile. Старые методы работы и привычные ожидания больше не действуют. Люди растеряны, находятся в замешательстве, и настроения в коллективе переменчивы. В какие-то дни все хорошо, в другие – все плохо. Люди периодически демонстрируют ребяческое поведение. Производительность и моральный климат ухудшаются.

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

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

Рис. 5.1. Модель изменений Вирджинии Сатир (The Satir Change Model)

Такие реакции на изменения неизбежны. Попытки ускорить процесс только ухудшают ситуацию. Вот почему организациям следует отвести время на обучение (см. раздел «Найдите время на обучение» главы 4). Обратите внимание на параллели между моделью Сатир, представленной на рис. 5.1, и J-кривой, показанной на рис. 4.1 (см. выше).

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

Вы можете снизить (но не полностью устранить!) хаос, применив технику, которой я научился у Дианы Ларсен: поддержка, информация и структура (Support, Information, Structure – SIS)¹⁵.

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

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

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

Масштабные изменения

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

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

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

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

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

Процессы изменений

Кайдзен – общий термин в сообществе Agile. Это японское слово, означающее «совершенствование». В Agile-сообществе этот термин означает непрерывное постепенное совершенствование¹⁷.

Непрерывное совершенствование – неотъемлемая часть Agile, так не нужен ли кайдзен в первую очередь для того, чтобы направить ваши усилия к Agile? Парадоксально… но, наверное, нет. Кайдзен предназначен для улучшения существующих методов работы. Если в вашей компании особое значение имеют документы, то кайдзен поможет вам рационализировать документооборот. Если культура вашей организации основана на обвинениях, то кайдзен поможет вам точнее устанавливать вину. Но он не поможет вам перейти с любой культуры на Agile.

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

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

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

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

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

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

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

Заручитесь поддержкой руководства

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

1. Начните с разговора

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

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

2. Получите одобрение экономичного покупателя

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

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

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

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

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

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

Заполучив в команду союзников экономичного покупателя, начните говорить об инвестициях. Не перегружайте собеседников излишними подробностями; кратко перечислите несколько ключевых инвестиций, необходимых каждому уровню (врезка «Список необходимых инвестиций» в главе 4 поможет вам подготовиться), а также то, как эти уровни соотносятся с пожеланиями покупателя. Спросите его, какой компромисс между размером инвестиций и выгодой он считает приемлемым. Если вы предложите несколько вариантов, а не потребуете ответа «да или нет», это понизит шансы категорического отказа.

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

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

3. Сделайте официальное предложение

Если вы добрались до этого этапа, то поздравляю! Вы преодолели самое важное препятствие. Сейчас вам нужно пройти через официальное предложение.

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

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

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

Выход на экономичного покупателя
Приведу пример того, как вовлеченность руководства работает в сложной ситуации; он взят из моего собственного опыта в роли консультанта. Это не было обычным проектом по переходу организации к Agile, поэтому у вас все будет иначе, но этапы обсуждения в организации наверняка будут похожими.
Изначально ко мне обратился менеджер по проектированию компании, насчитывающей несколько сотен инженеров и порядка 45 команд разработчиков программного обеспечения. Этот руководитель искал кого-нибудь, кто возглавил бы маленькую команду. Мы поговорили, и я узнал, что у них были сложности с взаимодействием команд. Я предложил свою помощь в решении этой проблемы.
Этот руководитель нашел мои идеи касательно масштабирования довольно содержательными и представил меня своему вице-президенту по проектированию. Мы поговорили спустя две недели. Ему понравилось то, что я сказал, и еще через полторы недели мы обедали с его боссом – директором по продукту. Он и был экономичным покупателем.
Во время того обеда директор по продукту высказал ряд опасений, касающихся его организации. Мы обсудили несколько способов, как я могу помочь, и в качестве продолжения запланировали встречу между мной и их директором по управлению продуктами, который также присутствовал на том обеде.
Я встретился с директором через неделю. Он не являлся покупателем, поэтому моей целью было не убедить его, а узнать больше информации о компании. Я также хотел убедиться, что мы правильно понимаем друг друга, поскольку нам предстояло тесно сотрудничать. К счастью, мы были на одной волне, и мой собеседник запланировал еще одну встречу с участием нас двоих и директора по продукту.
Эта встреча состоялась на следующей неделе. Наша предыдущая встреча за обедом была нашим шансом познакомиться друг с другом, тогда как эта встреча была моим шансом заручиться поддержкой директора по продукту.
Я не пытался развернуть рекламную кампанию. Я никогда не считал полезным говорить людям, что они должны хотеть. Вместо этого я задавал вопросы. У меня была реальная цель: я хотел понять потребности директора по продукту и проинформировать его о тех моментах, которые чреваты трудностями или даже проблемами. Я спросил его, как он представляет себе успех, как он поймет, что успех достигнут, и как, по его ожиданиям, в итоге это повлияет на бизнес.
К концу встречи, которая заняла час, я узнал достаточно, чтобы обрисовать примерный подход и ценовой диапазон. Я спросил, правильно ли я все понял, и мой собеседник ответил утвердительно. Мы ударили по рукам, и я обещал к концу следующего рабочего дня представить детальное предложение, что и сделал. Его рассмотрели в течение недели (директор держал меня в курсе того, что происходило в компании) и одобрили на следующей неделе, внеся небольшие поправки.
Окончательное одобрение заняло еще некоторое время, которое ушло на то, чтобы пробиться сквозь корпоративную бюрократию, однако на тот момент это был уже решенный вопрос. От первой встречи до первого одобрения прошло пять встреч и семь недель. Это довольно быстрый результат для организации такого размера, но они были очень мотивированы. У них была серьезная проблема, которая блокировала прогресс, и они верили, что я могу помочь им решить ее.
Вот те ингредиенты, которые понадобятся и вам: мотивирующая проблема и вера в то, что вы можете ее решить.

Если это выглядит слишком трудозатратным…

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

Но иногда все это не так сложно. Иногда вы просто помогаете одной маленькой команде стать более Agile. Если вы и ваш руководитель уже имеете все полномочия, чтобы выделить необходимые вам инвестиции, то просто сделайте это!

Если руководство считает, что они уже Agile…

Некоторые организации (а в наши дни таких много) думают, что они уже Agile. Одна организация говорила мне: «Мы пост-Agile!» Или вы можете услышать: «Мы agile с маленькой буквы “а”, а не Agile с большой буквы “A”!» Но сравнив философию, описанную в главе 1, с тем, как действует организация, вы поймете, что это далеко не так.

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

Если руководство не поддерживает…

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

Если у вас есть руководитель, которому вы доверяете, то обратитесь к нему за помощью и советом. Если его нет, то попробуйте провести информационное интервью: поговорите с руководителем из другой компании, проходившей через это недавно. (Они могут попытаться нанять вас на работу. Взаимовыгодный вариант, win/win!) Во врезке «Смените организацию» далее в этой главе рассматривается ряд идей на этот случай.

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

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

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

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

Изменить организацию
Вы можете изменить свою организацию или сменить ее.

Мартин Фаулер

Изменить организацию изнутри непросто, но возможно. Это отнимает много сил и времени, и не всегда оказывается, что оно того стоило. Поэтому более простой способ изменить организацию – сменив работу – может оказаться более разумным выбором. Для тех, кто все же хотел бы попытаться, ниже приведены 13 советов, почерпнутых из моего собственного опыта изменения организации изнутри.
1. Задумывайтесь о своих мотивах. Отвечает ли Agile в наивысшей степени интересам организации или он нужен вам по личным причинам? Есть ли у вас время, энергия и энтузиазм, чтобы проповедовать эти изменения? Есть ли у вас стратегия поиска выхода из проблем, которые могут возникнуть вследствие ваших усилий? Если ответ на любой из этих вопросов – «нет», то смена работы может оказаться лучшим выходом.
2. Организуйте надежную сеть поддержки. Изменения в направлении снизу вверх – неблагодарная работа, часто ведущая к разочарованию. Полагайтесь на семью и друзей, уходите домой вовремя и не живите рабочими проблемами в нерабочее время.
3. Находите для себя маленькие удовольствия. Без поддержки сверху организационные изменения в значительной мере находятся вне вашего контроля. Находите небольшие ежедневные рабочие задачи, благодаря выполнению которых вы будете чувствовать удовлетворение.
4. Не сдавайтесь. Небольшие изменения накапливаются. Поначалу эффект от ваших усилий будет незаметным, но они будут постепенно менять стиль мышления людей в сфере решения проблем. В конце концов, по достижении некоего порога все внезапно начнет меняться.
5. Уважение – ваша валюта. Чем больше люди уважают вас, тем больше ваш авторитет. Завоевывайте авторитет своими действиями и уважительно относитесь к другим, даже в мыслях.
6. Оставайтесь внутри сферы своего влияния. Изменения снизу требуют постоянного повторения. Пытайтесь вносить изменения только в тех отделах организации, с которыми вы находитесь в постоянном контакте.
7. Пополняйте ряды сторонников. Найдите хотя бы одного человека, который уважает вас и ваши идеи и имеет большее влияние, чем вы. Привлеките его к распространению ваших идей.
8. Находите пробелы. Люди должны хотеть изменений, но они будут их хотеть, только если это дает им что-то, что они не могут получить другим способом, или если это убережет их от потери чего-то ценного для них. Фокусируйтесь на этих моментах.
9. Вникайте в причины. Всегда есть причины, почему что-то делается именно так, а не иначе, и вы можете сделать свое вмешательство более эффективным, если разберетесь, что это за причины.
10. Повторяйте. Продвигайте свою идею изменений снова и снова, разными способами и разным людям. Но старайтесь не быть назойливым.
11. Не критикуйте все подряд. Выберите что-то одно и работайте с этим. Если вы будете находить проблемы во всем, то люди просто перестанут вас слушать.
12. Не ищите признания. Если вы успешны, то люди начнут повторять ваши идеи, как если бы они были их собственными. Это не плагиат. Ваши усилия на самом деле могут изменить мышление людей, при этом они даже не будут это осознавать. Пусть они так думают. Они будут более усердно трудиться ради собственных идей.
13. Будьте осторожны в своих желаниях. Если ваш проект изменений будет успешен, то готовы ли вы взять на себя ответственность за то, что будет дальше?
Если вы захотите прочесть историю изменений, вдохновившую автора на эти советы, то можете найти ее онлайн на веб-странице [Shore2006]. Подробное руководство по изменениям изнутри содержится в книге More Fearless Change: Strategies for Making Your Ideas Happen [Manns2015].

Заинтересуйте команду

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

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

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

Я говорю: «Если вы согласитесь, то я предложу вам попробовать стандартный вариант Agile в течение трех месяцев. После этого мы оценим, что работает, что нет, и попробуем что-то улучшить¹⁹. Спустя шесть месяцев у вас будет возможность принять решение – продолжаем мы работать с Agile или остаемся с тем, что есть сейчас».

Затем я даю всем возможность задать вопросы. У команд обычно множество вопросов касательно процесса, но один вопрос возникает всегда: «Что будет, если мы скажем “нет”?» Мой ответ всегда один и тот же: «Ничего не произойдет». Это важно! Должна быть реальная возможность наложить вето. Если вы не дадите людям возможность сказать «нет», то их «да» ничего не будет значить. Давая людям шанс отказаться сейчас и конкретную возможность передумать позже, вы позволяете им в безопасном режиме попробовать что-то новое.

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

Если команда настроена скептически…

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

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

Если несколько членов команды против…

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

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

Если большинство членов команды против…

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

Если люди обманывают насчет своего согласия…

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

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

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

Заручитесь поддержкой стейкхолдеров

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

Мы уже разбирались с вопросом поддержки со стороны членов команды и руководителя. Вам не нужно, чтобы все остальные стейкхолдеры поддерживали ваш замысел, но вам точно нужно заручиться поддержкой тех, кто имеет значительное политическое влияние. В противном случае они могут тихо саботировать ваши усилия или каким-нибудь неожиданным образом выбить почву у вас из-под ног через полгода-год, если (особенно если) внедрение Agile будет успешным²⁰.

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

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

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

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

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

Если нужны конкретные обязательства…

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

Если этого недостаточно, то можно применить подход, описанный в подразделе «Если требуется водопадная модель управления…» главы 4, то есть подготовить планы с фиксированными сроками и объемом работ. Нет гарантии, что эти планы будут правильными, но это лучшее, что вы можете предложить на данный момент. Если и этого недостаточно, то, видимо, Agile вам не подходит.

Если стейкхолдеры не спешат поддержать…

Иногда у команд разработчиков складываются непростые отношения с некоторыми стейкхолдерами, особенно с продакт-менеджерами или отделом продаж. Эти отношения могут быть довольно напряженными. В некоторых случаях неприязнь и отсутствие доверия даже могут привести к тому, что эти люди будут категорически против Agile. Они могут также возражать против замедления работы, вызванного необходимостью обучения Agile в начале процесса внедрения (см. раздел «Найдите время на обучение» главы 4).

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

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

Литература для дополнительного чтения

Книгу 7 Rules for Positive, Productive Change²¹ [Derby2019] должен прочитать каждый, кто занимается организационными изменениями.

Если хотите понять, как повлиять на изменения в вашей организации, то начните с прекрасной книги More Fearless Change: Strategies for Making Your Ideas Happen [Manns2015].

Глава 6. Масштабирование гибкости

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

Но это совершенно нереалистично. Типичная Agile-команда состоит из 4–10 человек. Как правило, этого недостаточно.

Как же вам тогда расширяться? Эта книга посвящена в основном индивидуальным Agile-командам, однако этот вопрос достаточно важен, чтобы заслуживать отдельной главы.

Масштабирование свободного владения навыками

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

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

Организационный потенциал

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

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

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

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

Коучинговый потенциал

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

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

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

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

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

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

Потенциал команды

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

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

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

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

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

Синдром второго ребенка
Я заметил удивительный тренд среди компаний, внедряющих Agile: пилотные команды часто очень успешны и вдохновляют организацию на дальнейшее распространение Agile, но вторая волна команд начинает испытывать трудности.
Я называю это синдромом второго ребенка. Моя теория заключается в том, что пилотные команды получают всю необходимую поддержку: целеустремленных участников, терпеливую организацию, помощь извне и задачи, хорошо подходящие для обучения.
А затем, думая, что все ее сотрудники уже хорошо знакомы с Agile, организация оказывает второй волне команд гораздо меньшую поддержку. Agile навязывается людям, которые его совсем не хотят; кроме того, руководители не предоставляют помощь извне и оказывают большее давление по срокам выполнения задач.
Чтобы избежать синдрома второго ребенка, помните, что успех одной команды не гарантирует автоматически успех другой. Каждой команде требуются понимание и поддержка, когда она впервые пытается быть Agile-командой.

Масштабирование продуктов и портфелей

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

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

Вертикальное масштабирование

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

Я рассмотрю два подхода к тому, как это сделать: LeSS и FAST. Для ясности буду использовать терминологию из этой книги вместо терминов, которые применяются в каждом из подходов, но приведу их в скобках.

LeSS

LeSS, который расшифровывается как Large-Scale Scrum, – один из оригинальных подходов в Agile-масштабировании. Он был создан Крейгом Ларманом и Басом Водде в 2005 году²³.

Базовый LeSS применим для 2–8 команд, численностью до восьми человек каждая. Все команды работают по одному визуальному плану (который в LeSS называется бэклогом продукта) и совместно являются владельцами всего общего кода. Кроме того, существует LeSS Huge, который применяется при значительно большем количестве команд. Это мы обсудим позже.

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

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

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

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

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

Внедрение LeSS

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

См. также
Коллективное владение кодом (глава 12)
Разработка через тестирование (глава 13)
Непрерывная интеграция (глава 13)

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

Если вы ищете устоявшийся, хорошо проверенный подход к масштабированию Agile, то начните с LeSS. Вам понадобится развить свободное владение навыками на уровнях фокусировки и поставки. Уровень фокусировки – это фундамент, а уровень поставки необходим, чтобы команды могли совместно владеть общим кодом. Как минимум вам понадобятся практики коллективного владения кодом, разработки через тестирование и непрерывной интеграции.

Больше информации о LeSS доступно на сайте less.work или в книге о LeSS Large-Scale Scrum: More with LeSS [Larman2015].

FAST

FAST расшифровывается как Fluid Scaling Technology. Это детище Рона Куартела и один из наиболее многообещающих подходов к масштабированию, который я когда-либо видел. К сожалению, на момент написания этой книги и наименее проверенный. Я включил его в книгу, поскольку думаю, что он заслуживает вашего внимания²⁴.

Рон Куартел создал FAST в одной из страховых компаний в Вашингтоне. На пике подхода у него было 65 человек, которые работали как одна команда. Он начал с экстремального программирования в качестве основы, затем наложил его на технологию открытого пространства (Open Space Technology, OST), помогающую большим группам людей самоорганизовываться вокруг какой-либо цели или задачи.

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

FAST-группа называется трайбом (tribe – «племя»). Каждый трайб состоит из разработчиков и одного или нескольких продакт-менеджеров (которых FAST называет директорами по продукту), ответственных за определение направления. В теории трайб может насчитывать до 150 человек, но такое количество не тестировалось на момент написания этой книги.

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

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

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

Вместо того чтобы разбивать истории на детализированные списки задач, команды FAST создают дерево открытий (discovery tree) для каждого ценного инкремента²⁵. (Ценный инкремент представляет собой то, что может быть выпущено само по себе (см. подраздел «Ценные инкременты» главы 8).)

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

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

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

Внедрение FAST

См. также
Командная комната (глава 7)
Согласование (глава 7)
Ретроспективы (глава 11)
Визуальное планирование (глава 8)
Игра в планирование (глава 8)
Планирование задач (глава 9)
Потенциал (глава 9)
Резерв времени (глава 9)
Стендап-митинги (глава 9)
Прогнозирование (глава 10)
Динамики команды (глава 11)

FAST не настолько точно совпадает с техниками, представленными в этой книге, как LeSS. Например, многие практики из уровня фокусировки не будут применимы.

В частности:

• все места в книге, где упоминается термин «команда», относятся к FAST-трайбу в целом;

• у вас будут дополнительные требования к командной комнате, хотя настоящее руководство остается в силе, особенно для удаленных команд;

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

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

игра в планирование, планирование задач и потенциал больше не нужны;

резерв времени должен внедряться по-другому;

стендап-митинги заменяются FAST-митингами;

прогнозирование – совершенно другое (и значительно проще, хотя его точность не оценивалась);

• динамики команд осложнены, поскольку отсутствуют постоянные составы команд.

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

Хотя FAST и не проверялся до такой степени подробно, как LeSS, я считаю его очень перспективным. Если у вас есть опыт в Agile и вам ничего не мешает протестировать его с пилотной командой, состоящей из 10–30 человек, то рекомендую вам сделать это.

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

Вы можете найти больше информации о FAST на сайте fastagile.io. Поищите там раздел FAST Guide. Руководство короткое и легко читается. У меня на сайте также есть интервью с Роном Куартелом о FAST [Shore2021].

Проблемы и преимущества вертикального масштабирования

См. также
Коллективное владение кодом (глава 12)

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

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

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

А для вертикально масштабированных групп это не проблема. Если у вас 30 человек и достаточно работы только для двух UX-специалистов, это не проблема: вы можете взять всего двух UX-специалистов. В FAST они сами включат себя в те команды, в которых нужны их навыки. В LeSS они присоединятся к определенной команде или двум, и эти команды вызовутся добровольцами на задачу, требующую квалификации в UX.

Горизонтальное масштабирование

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

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

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

В результате, хотя в идеале каждая команда владела бы долей продукта, вам почти всегда придется вводить в работу и менее идеальные типы команд. В книге Team Topologies [Skelton2019] они разделены на четыре категории.

• Поточно-ориентированные команды. Это идеальный вариант. Они сфокусированы на определенном продукте, его доле, обращенной к заказчику или группе заказчиков.

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

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

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

Секрет успеха горизонтального планирования – в правильном распределении ответственности среди команд. Чем меньше перекрестных зависимостей между командами, тем лучше. Это фундаментальный вопрос архитектуры, поскольку зоны ответственности ваших команд должны имитировать желаемую системную архитектуру. (Это также называется обратным маневром Конвея (Inverse Conway Maneuver).)

Горизонтальное масштабирование работает наилучшим образом, когда у вас всего несколько команд. Когда их количество невелико, легко понять, как все они сочетаются друг с другом, и координировать их работу. Если есть проблема, то представители команд могут собраться вместе и все урегулировать.

Такой принцип координации по необходимости (ad-hoc coordination) перестает работать при наличии примерно 5–10 команд. Начинают формироваться узкие места, одни команды почти останавливают работу, а другие оказываются перегружены ею. Чтобы сохранять команды как можно более независимыми друг от друга, вам нужно уделять особое внимание их структуре. Каждая команда, особенно те, которые не относятся к типу поточно-ориентированных команд, должна рассматривать автономию тех, кто от нее зависит, как свой высочайший приоритет. А продакт-менеджеры должны тщательно координировать действия всех участников, обеспечивая общую согласованность работы.

Когда вы достигаете уровня 30–100 команд, даже этот подход начинает сбоить. Чаще происходят различные изменения, и зоны ответственности команд нужно корректировать, чтобы не отставать от изменений в бизнес-приоритетах. Вам уже требуется многоуровневая система координации и управления. Люди перестают понимать, как работает система в целом.

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

Вертикальное и горизонтальное масштабирование

Я работал со стартапом, в котором участниками команд стали 300 человек и который застопорился на этом. (Вся организация насчитывала более 1000 человек, а в командах разработки продукта состояло около 300 человек.) Все команды работали над разными аспектами одного и того же продукта, и кросс-командные зависимости просто блокировали их деятельность.

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

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

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

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

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

Моя рекомендация

Резюмируем: как вам масштабировать вашу Agile-организацию?

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

Делайте вертикальное масштабирование прежде, чем горизонтальное. В большинстве случаев лучшим выбором является LeSS. Если у вас есть опыт и вы хотите экспериментировать, то попробуйте FAST.

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

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

Но помните: успех масштабирования зависит от свободного владения навыками команд. Этому посвящена вся оставшаяся часть книги. Мы начнем со свободного владения навыками на уровне фокусировки.

Несколько слов о SAFe
SAFe (Scaled Agile Framework), масштабированный гибкий фреймворк, представляет собой популярный подход к Agile-масштабированию. К сожалению, я пока еще не видел его хорошо работающим. Как правило, компании принимают его с большой помпой, но через несколько лет тихо избавляются от него.
Я не знаю точно, почему это так. Критики SAFe заявляют, что это не совсем Agile и что ему свойствен характерный оттенок преобладания «процессов над людьми» и «предиктивности над адаптивностью».
Я подозреваю, что настоящих причин неудач SAFe две. Во-первых, SAFe подчеркивает, что «он дружествен для предприятий», что в организациях, которые я видел, приводит к недостаточным инвестициям в идеи Agile. Организации склонны придерживаться привычного предиктивного мышления в стиле управления сверху вниз и «командуй-и-контролируй».
Во-вторых, SAFe мало что предлагает для координации команд – самой сложной и критически важной проблемы масштабирования. До SAFe 5 он предлагал делить команды по функциональностям (то же, что и LeSS), но это было крайне невыгодно и не включало элементы, с помощью которых LeSS обеспечивает работу команд²⁶. SAFe 5, появившийся в феврале 2021 года, заменил функциональные команды дискуссией о топологиях команд, которая хотя бы содержит больше деталей. Но это подход горизонтального масштабирования, что является шагом назад. Он требует обращать пристальное внимание на структуру обязанностей команд, которую SAFe опять-таки даже не упоминает, не говоря о том, чтобы помочь с этим разобраться.
Небольшим вкладом SAFe в координацию команд может считаться сессия планирования инкремента программы (Program Increment (PI) Planning) каждые несколько месяцев, также известная как «планирование в большой комнате». Эта сессия предиктивная, не адаптивная; чрезвычайно трудоемкая и изнурительная; плохо работающая с удаленными командами. Хотя некоторые команды и ценят ее за возможность привести команды к общему пониманию, по моему опыту, это первое, от чего избавляются компании. К сожалению, в SAFe больше нет ничего особенного, и как только из него исчезает PI Planning, вы остаетесь с группой команд и ограниченными возможностями их координации.
В общем и целом SAFe на словах поддерживает идеи Agile, однако не понимает их по-настоящему. Я его не рекомендую.

II
Фокус на ценность

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

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

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

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

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

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

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

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

У вашей команды перерыв после ретроспективы, затем Ханна начинает еженедельную сессию планирования. Она достает доску для визуального планирования. Это большая белая доска с пачкой индексных карточек, прилепленных к ней магнитами. Карточки образуют кластеры, и у каждого из них есть название, например, «реселлеры», «актуарии», «бухгалтеры». Кластеры представляют собой группы ваших заказчиков. Есть и другая большая группа карточек, помеченная словом whitelabel.

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

Ханна делает знак Колтону, UX-дизайнеру команды, и он вступает в разговор. «Мы с Ханной собираемся заняться пробным прогоном и администрированием whitelabel чуть позже сегодня. Приглашаем всех поучаствовать. После этого я хотел бы составить карту историй и провести игру в планирование, чтобы конкретизировать истории. Это не должно быть слишком сложным. Я сообщу вам, когда мы это запланируем».

Ханна берет несколько голубых карточек с историями из раздела доски, подписанного whitelabel. «У нас еще достаточно историй на эту неделю. Наш потенциал все еще составляет 12 пойнтов (point), верно?» Все кивают. «Отлично. Вот 3… 6… 8, 11, 12. Это должно приблизить нас к пробному прогону с реальными заказчиками». Она поднимает первую карточку, на которой написано «цветовая схема whitelabel». «Окей, для этого нам нужна возможность изменить цветовую схему сайта, чтобы она соответствовала фирменным цветам каждого реселлера». Вдобавок Ханна кратко поясняет содержимое остальных карточек. Ей задают несколько уточняющих вопросов, но вообще-то вы все уже видели это раньше, поэтому процесс идет быстро.

«Вот такой план! – заканчивает Ханна. – Колтон сможет ответить на любые вопросы, касающиеся деталей. Сейчас мне нужно заняться электронными письмами, но я буду здесь, – она показывает на угол, – до тех пор, пока вы не закончите планирование. Дайте знать, если от меня понадобятся какие-либо пояснения».

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

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

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

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

«Думаю, на этом все», – говорит Шайна. Стендап занял всего несколько минут, а вся сессия планирования продолжалась менее часа. Учитывая ретроспективу и демо, время приближается к полудню. «Кто на обед?»

Добро пожаловать на уровень фокусировки

Свободное владение навыками на уровне фокусировки – для тех команд, которые хотят сконцентрироваться на том, что их компания ценит больше всего. Они тесно сотрудничают со своими бизнес-партнерами, чтобы понимать приоритеты, обеспечивать наглядность и реагировать на обратную связь. В частности, команды, которые свободно владеют навыками на уровне фокусировки²⁷:

• планируют свою работу с точки зрения бизнес-ценности, а не технических задач и согласовывают работу с бизнес-приоритетами компании;

• демонстрируют прогресс по меньшей мере ежемесячно и делают это с точки зрения бизнес-ценности, а не технических задач;

• меняют свое направление, чтобы следовать за изменениями в приоритетах бизнеса;

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

• регулярно улучшают свои рабочие привычки, снижая затраты и повышая эффективность;

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

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

Команда отвечает на потребности бизнеса:

• работает с представителем бизнеса, который обеспечивает ее организационными перспективами и ожиданиями;

• стейкхолдеры от бизнеса могут быть уверены, что команда будет работать над тем, что ее бизнес-представитель называет своим самым важным приоритетом;

• команда планирует свою работу и демонстрирует прогресс поэтапно, чтобы ее бизнес-представитель мог его понять и оценить;

• бизнес-представитель команды видит и может изменить направление работы команды по меньшей мере раз в месяц;

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

Команда эффективно работает как команда:

• составляет свои ежедневные задачи и план, основываясь на приоритетах ее бизнес-представителя;

• участники считают план командной работой, а не индивидуальной;

• члены команды разделяют ответственность за выполнение плана;

• руководство считает план командной работой, а не назначает ответственными отдельных исполнителей.

Команда стремится к командным достижениям:

• принимает и постоянно улучшает общий подход к своей работе;

• понимает, как внутрикомандные отношения влияют на ее способность достигать успеха, и своевременно пытается их улучшить;

• понимает, как рабочая атмосфера влияет на способность команды выполнять работу, и своевременно пытается ее улучшить.

Достижение свободного владения навыками на уровне фокусировки

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

• В главе 7 рассматривается эффективная работа в команде.

• В главе 8 описывается, как планировать и приоритизировать работу в соответствии с бизнес-ценностью.

• В главе 9 рассказывается о том, как взять на себя ответственность за повседневный процесс и планы.

• В главе 10 описывается, как обеспечить наглядность рабочего процесса и завоевать доверие стейкхолдеров.

• В главе 11 представлена информация о том, как улучшать рабочие привычки, отношения и атмосферу в команде.

Глава 7. Командная работа

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

Кросс-функциональные самоорганизующиеся команды – основной ресурс любой Agile-организации. Но кто должен быть частью Agile-команды? Как они узнают, над чем работать? Что помогает им продуктивно работать вместе?

В этой главе содержатся практики, позволяющие создать отличную команду Agile.

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

• Практика «Командная комната» позволит создать пространство, физическое или виртуальное, в котором команда может эффективно сотрудничать.

• С помощью практики «Безопасность» вы можете создать рабочую среду, в которой члены команды могут делиться опытом и знаниями.

• Практика «Цель» помогает командам понять, как их работа поддерживает глобальные планы компании.

• В практике «Контекст» рассматриваются вопросы о стейкхолдерах команды и выделенных ресурсах.

• Практика «Согласование» дает возможность устанавливать нормы и правила, позволяющие членам команды эффективно сотрудничать.

• В практике «Энергичная работа» рассказывается о том, как работать таким способом, который ваша команда может поддерживать неограниченно долго.

Источники командной работы
Идея кросс-функциональных самоорганизующихся команд была частью Agile с самого начала. В экстремальном программировании эта идея называется «вся команда», данный термин я использую в этой книге. В Scrum это явление называется Scrum-командой. Командная комната – тоже устоявшийся термин, в экстремальном программировании это называется «сидеть вместе», а в оригинальной книге о Scrum [Schwaber2002] говорилось о важности рабочей среды для команды.
Безопасность также была частью обсуждения в Agile в течение многих лет. [Beck2004] рассуждает об этом в своей дискуссии о команде. Джошуа Кериевски называет принцип «безопасность – предварительное условие» руководящим принципом современного Agile. Обсуждение этой темы было включено в данную книгу благодаря приглашенному автору Гитте Клитгаард, которая имеет огромный опыт помощи командам и организациям в создании психологической безопасности.
Практики «Цель», «Контекст» и «Согласование» основаны на великолепной книге Дианы Ларсен и Эйнсли Нис Liftoff: Start and Sustain Successful Agile Teams [Larsen2016]. Вместе они являют собой пример подготовки устава (chartering), который я впервые увидел, в контексте Agile, в методе Джошуа Кериевски Industrial XP (IXP) [Kerievsky2005]. Подготовку устава внес в IXP неподражаемый III²⁸, который также оказал большое влияние на работу Нис и Ларсен.
Практика «Энергичная работа» – еще одна давняя идея Agile. Термин пришел из XP: в первом издании книги по XP эта концепция носила название «40-часовая неделя», но оно было пересмотрено, превратившись во втором издании в название «Энергичная работа», менее ориентированное на США.

Вся команда

Аудитория
Коучи

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

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

См. также
Цель (глава 7)

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

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

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

Карго-культ
Провальная команда
«Окей, теперь вы Agile», – говорит ваш руководитель и немедленно исчезает за дверью офиса.
Вы вчетвером нервно смотрите друг на друга. Вы – команда фронтенд-программистов и не совсем понимаете, что вам делать. До вас доходили слухи о новой инициативе и о том, что ваша команда будет участвовать в ней… как?
На следующий день вбегает Клодин. «Привет! Я ваш Scrum-мастер, – говорит она. – Извините, вчера меня не было. У меня еще четыре команды, и я только что узнала, что буду работать еще и с вами. Рамонита будет вашим владельцем продукта, но она сегодня не сможет присутствовать. Я назначила встречу через неделю».
Клодин вводит вас в курс дела касательно продукта, над которым вы будете работать. Ваша команда создает пользовательский интерфейс, а несколько других команд делают микросервисы бэкенда. Тестирование будет проводиться отделом контроля качества, как обычно, и когда вы будете готовы к развертыванию, то отправите заявку в отдел эксплуатации, который будет отвечать за мониторинг и бесперебойную работу. «Вот макет интерфейса, подготовленный отделом дизайна, – говорит Клодин, – и Рамонита добавит в трекер задач истории со всеми требованиями. Я буду встречаться с вами каждый день на стендап-митинге. Просто сообщайте мне, что вы сделали, и я буду обновлять трекер задач».
Клодин выбегает, и ее голос, затихая, доносится из глубины коридора. «Дайте мне знать, если вам что-то понадобится!» Вы смотрите друг на друга, пожимаете плечами и открываете трекер задач. Истории не совсем понятные, поэтому вы отправляете несколько электронных писем с вопросами. И начинаете разработку.
Проходит месяц. Все идет не очень хорошо. Вы встречаетесь с Рамонитой каждые две недели и в итоге вынуждены переделывать многое из того, что она просит. Требования в трекере задач не всегда понятны, поэтому вам приходится отправлять письма с вопросами, параллельно строя догадки.
Даже когда вы думаете, что что-то наконец сделано, отдел контроля качества находит проблемы с теми задачами, в правильности которых вы уверены, хотя истории можно было интерпретировать по-разному. Вы просите Рамониту указывать больше деталей, но их всегда недостаточно. Системы бэкенда тоже никогда полностью не работают так, как вы ожидали, и отдел эксплуатации тратит огромное количество времени на обновление среды разработки с помощью новых сборок.
И наконец, вы поставляете готовый продукт. Вы не знаете, насколько хорошо он будет принят, но на данном этапе это неважно. Вы уже готовы заняться чем-то другим. Во всяком случае, это теперь проблема отдела эксплуатации.

Навыки в сфере деятельности заказчика

См. также
Вовлечение реального заказчика (глава 8)

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

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

Управление продуктом (оно же владение продуктом – ownership)

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

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

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

Во многих компаниях довольно мало продакт-менеджеров. Для команд, работающих медленно и имеющих предсказуемые задачи, это, возможно, не проблема. Но чаще всего это приводит к тому, что команды тратят время впустую, создавая не то, что требуется. [Rooney2006] столкнулся с этой проблемой, приведшей к печальным результатам:

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

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

Экспертные знания в предметной области (Domain expertise, Subject Matter Expertise)

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

См. также
Поэтапные требования (глава 8)
Примеры заказчика (глава 9)
Единый язык (глава 12)

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

Даже если в вашем ПО нет сложных правил предметной области, вам все равно понадобятся люди, которые смогут детально разобраться в том, что именно оно должно делать. В некоторых командах таким человеком может быть продакт-менеджер, дизайнер пользовательского интерфейса (User Experience; UX-дизайнер) или бизнес-аналитик.

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

Дизайн пользовательского интерфейса (UX-дизайн) (он же дизайн взаимодействий)

Пользовательский интерфейс вашего ПО – лицо вашего продукта. Для многих пользователей интерфейс и есть продукт. Они судят о продукте, основываясь только на том, какое впечатление у них вызвал его пользовательский интерфейс.

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

Быстрая, итеративная и ориентированная на обратную связь природа Agile-разработки приводит к формированию среды, отличной от той, к которой, возможно, привыкли UX-дизайнеры. Вместо того чтобы включать UX-дизайн в предварительные исследования пользователей, его выполняют итеративно, одновременно с такой же итеративной доработкой самого ПО. Agile-команды выпускают ПО каждую неделю или две, что дает дизайнерам возможность дать его реальным пользователям, понаблюдать за паттернами его использования и руководить дальнейшими планами команды, основываясь на полученной обратной связи.

Навыки разработки

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

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

Программирование, дизайн и архитектура

См. также
Разработка через тестирование (глава 13)
Простой дизайн (глава 14)
Инкрементный дизайн (глава 14)
Рефлексивный дизайн (глава 14)
Эволюционная системная архитектура (глава 15)
Игра в планирование (глава 8)
Без багов (глава 16)
Сборка для эксплуатации (глава 15)

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

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

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

Тестирование

См. также
Поэтапные требования (глава 8)
Примеры заказчика (глава 9)
Обнаружение слепых зон (глава 16)
Без багов (глава 16)

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

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

Эксплуатация (Operations)

См. также
Непрерывное развертывание (глава 15)
Сборка для эксплуатации (глава 15)
Анализ инцидентов (глава 16)

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

В навыки эксплуатации также входит помощь команде в поддержании рабочих реалий: планирование потребностей отдела эксплуатации, таких как безопасность, производительность, масштабирование, контроль и управление; справедливое распределение смен дежурств на линии поддержки (при необходимости); помощь в анализе и предотвращении инцидентов.

Навыки коучинга

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

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

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

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

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

Командам нужен коучинг в четырех категориях в зависимости от того, какие уровни свободного владения навыками их интересуют.

• Развитие команды, самоорганизация и посредничество (все команды).

• Практики планирования и командной работы на уровне фокусировки.

• Практики разработки на уровне поставки.

• Практики развития бизнеса на уровне оптимизации.

Для этого может потребоваться несколько коучей.

См. также
Ретроспективы (глава 11)
Динамики команды (глава 11)
Устранение препятствий (глава 11)

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

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

Коучи-практики

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

Коучи-игроки

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

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

Коучи-фасилитаторы

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

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

Специалисты широкого профиля

Команды Agile работают наилучшим образом, когда состоят из специалистов широкого профиля, также называемых людьми с профилем компетенций T, или T-людьми (T-shaped people). Специалист широкого профиля обладает глубокими знаниями и опытом сразу в нескольких областях, что символизирует вертикальная линия буквы Т, но полезен и в некоторых других областях, необходимых команде. Это символизирует горизонтальная черта. (Иногда используют термин «М-люди» (M-shaped people), чтобы подчеркнуть, что такие специалисты могут развить у себя экспертные навыки во многих областях.)

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

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

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

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

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

Комплектование команды

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

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

У вас может не получиться найти в команду человека, имеющего навыки продакт-менеджера или экспертные знания в предметной области. Во многих компаниях такого человека назначают на неполный рабочий день координировать команду в качестве владельца продукта. Рассматривайте это как знак того, что члены команды должны сами развить у себя навыки менеджмента продукта и экспертные знания в предметной области. Такой внештатный владелец продукта может помочь им начать, однако не сможет поддерживать их в долгосрочной перспективе. Лучшие Agile-команды прекрасно разбираются в сфере деятельности заказчиков. Это хорошо сформулировал Бас Водде³⁰:

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

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

Постоянные члены команды

Каждый постоянный член команды должен быть полностью приписан только к одной команде. Дробные назначения (когда человек назначается одновременно в несколько команд) дают ужасные результаты. Частично занятые работники не связаны со своей командой, часто не присутствуют при обсуждениях и не слышат ответы на вопросы, к тому же должны постоянно переключаться между задачами, что влечет за собой множество скрытых потерь. «Минимальные потери – 15 процентов. Работники с частичной занятостью могут выглядеть загруженными, но их загруженность – по большей части бестолковая суета» [DeMarco2002] (гл. 3).

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

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

Стабильные команды

См. также
Динамики команды (глава 11)

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

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

Размер команды

Рекомендации в этой книге предназначены для команд численностью 3–20 человек. Для новых команд хорошей отправной точкой будет численность 4–8 человек. Превысив количество в 12 человек, вы начнете замечать проблемы в общении, так что будьте осторожны при создании больших команд. И наоборот, если у вас очень маленькие команды, то подумайте о том, чтобы объединить их. Это уменьшит расходы, и вы будете менее чувствительны к текучести персонала.

См. также
Парное программирование (глава 12)
Групповое программирование (глава 12)

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

• Команды, которые не используют парное или групповое программирование, должны состоять из 3–5 программистов. По мере увеличения команды у них начинаются проблемы с координацией.

• Команды с парным программированием должны состоять из 4–10 программистов. Оптимальное количество – шесть. Команды – новички в практиках поставки не должны насчитывать больше 6–7 программистов, пока не приобретут достаточного опыта.

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

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

• навыки в сфере деятельности заказчика – один-два локальных заказчика на каждые три программиста. От четверти до половины их времени будет уходить на менеджмент продукта. Оставшееся будет тратиться на сочетание экспертных знаний в предметной области и UX- и UI-дизайна в зависимости от вида вашего ПО;

навыки тестирования – один тестировщик на каждые 2–4 программиста, если команда не имеет свободного владения навыками на уровне поставки, или один тестировщик на каждые 4–8 программистов, если имеет;

навыки эксплуатации – от нуля до двух специалистов эксплуатации в зависимости от типа продукта;

• навыки коучинга – один или два коуча, которые могут делить свое время с другими командами.

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

Почему так много заказчиков
Два заказчика на каждых трех программистов – это очень много, не правда ли? Я начинал с гораздо меньшего соотношения, но часто видел, что заказчики держатся наравне с программистами. В итоге я пришел к соотношению «два к трем» после экспериментов с разными соотношениями в различных успешных командах.
Все эти команды свободно владели навыками на уровне поставки, что подразумевало наличие в команде менеджмента продукта. Большинство работали в сложных предметных областях. Если у вас простое ПО и вы не стремитесь к свободному владению навыками на уровне поставки или у вас в команде отсутствует менеджмент продукта, то, вероятно, сможете обойтись меньшим количеством заказчиков.
Но имейте в виду, что у заказчиков очень много работы. Им необходимо понять, что представляет наибольшую ценность, установить правильные приоритеты в работе, определить все детали, о которых будут спрашивать разработчики, и вовремя реагировать на отзывы и примеры от клиента. Заказчики должны все это делать, на один шаг опережая программистов, которые (особенно в командах поставки) неумолимо следуют за ними, словно товарный поезд, который невозможно остановить. Это очень большая работа. Не стоит ее недооценивать.

Команда единомышленников

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

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

При этом трудно передать, насколько весело и с удовольствием проводят время высокопродуктивные Agile-команды. Брайан Марик, один из авторов Манифеста Agile, говорил, что радостный настрой (Joy) – еще одна ценность Agile³¹. И он прав. Отличные Agile-команды ее ощущают. Они оптимисты, энтузиасты своего дела и получают истинное удовольствие от совместной работы. Есть чувство превосходства, но они не воспринимают его слишком серьезно. Например, когда есть задача, за которую никто не хочет браться, разговор о том, кто ее будет делать, может вестись в игривой и веселой манере. И он протекает быстро. Эффективные Agile-команды легко принимают решения.

См. также
Динамики команды (глава 11)

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

Ключевая идея
Самоорганизующиеся команды
Agile-команды самостоятельно решают, над чем работать, кто будет это делать и как. Это основная идея Agile: люди, которые выполняют работу, достаточно квалифицированны, чтобы решать, как ее делать. Поэтому в данной книге так много практик в областях планирования, взаимодействия и работы со стейкхолдерами. За все это отвечают команды, а не менеджеры. От команд ожидается, что они коллективно возьмут на себя ответственность и будут совместно работать для достижения своей цели.
Это не значит, что руководителям нечем заняться. Фактически, делегируя детали своим командам, руководители освобождают свое время, чтобы иметь возможность сконцентрироваться на более значимой деятельности. Их работа – настраивать команды на успех, управляя более широкой системой, в которую встроены их команды. Более подробная информация представлена в разделе «Менеджмент» главы 10.

Еще раз о провальной команде

Давайте еще раз взглянем на историю провальной команды (см. врезку «Провальная команда» ранее в текущей главе). Что пошло не так?

• Руководитель удивил команду и сразу ее покинул, вместо того чтобы настроить ее на успех.

• Коуч Клодин не помогала команде учиться.

• У Рамониты, продакт-менеджера, совсем не было времени на команду.

• В команде не было никого, кто разбирался бы в сфере деятельности заказчика.

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

А вот как все это должно было произойти.

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

Все присутствующие поочередно представляются. У вас три фронтенд-программиста (один имеет опыт работы с полным стеком (full stack experience)), один бэкенд-программист, тестировщик и один UX-дизайнер. Вы уже познакомились со своим коучем Клодин. Она представляет вам Рамониту, вашего продакт-менеджера.

Входит Клодин. «Я знаю, что вам всем не терпится узнать, как работает Agile, поэтому сразу перейду к делу. Мы начнем с активности, называемой подготовкой устава. Рамонита работает со стейкхолдерами нашего проекта, чтобы понять, что мы будем создавать, почему и как это на всех повлияет. Мы тоже с ними встретимся через пару минут. Кроме того, мы уделим некоторое время тому, чтобы понять, как нам взаимодействовать наилучшим образом».

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

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

Вопросы

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

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

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

Если эти варианты не сработают, то ваша компания может сформировать вспомогательную команду, ответственную за инструкции, стандарты и тренинг для других команд, как описано в подразделе «Горизонтальное масштабирование» главы 6. Например, какая-либо UX-команда может создать руководство по стилям и научить людей, как его использовать применительно к программному обеспечению, разрабатываемому их командами. Это позволяет командам решать собственные проблемы, не нуждаясь в полноценном опыте.

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

Младшие члены команды наравне с остальными?

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

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

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

Предварительные требования

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

Показатели

Когда ваша команда кросс-функциональна:

• она способна решать проблемы и выполнять свою задачу, не дожидаясь внешних специалистов;

• люди в команде работают, выходя за рамки своей специализации, чтобы предотвратить появление узких мест и замедление работы;

• команда способна принимать решения легко и эффективно;

• люди в команде плавно перенимают роли лидерства от задачи к задаче.

Альтернативы и эксперименты

Теория, лежащая в основе этой практики, очень простая. Чтобы избежать задержек и проблем в общении, следует:

1) найти всех, кто нужен для достижения ваших целей;

2) собрать их всех в одну команду;

3) организовать согласованную работу команды так, чтобы она достигла этих целей.

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

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

Простых ответов на эти вопросы не существует. Сделайте предположение. Проверьте его, посмотрите, как все работает, и сделайте другое предположение. Проверьте и его. Никогда не переставайте экспериментировать. Только так можно достичь мастерства.

Литература для дополнительного чтения

The Wisdom of Teams: Creating the High Performance Organization³² [Katzenback2015] – классическое издание о высокоэффективных командах.

Agile Conversations [Squirrel2020] – отличный ресурс для коучей, которые помогают командам и организациям развить культуру Agile.

Командная комната

Аудитория
Вся команда, коучи

Мы взаимодействуем быстро и эффективно.

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

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

Чтобы справиться с этой проблемой, многие команды пытаются снизить необходимость прямого общения. Это спорный способ. Если вопросы порождают задержки и ошибки, снизьте необходимость задавать вопросы! Люди тратят больше времени на предварительное выяснение требований и документирование каждой потребности. Согласно этой теории, впоследствии программистам не нужно будет общаться с экспертами; они могут просто посмотреть ответы в документе.

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

См. также
Вся команда (глава 7)

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

См. также
Поэтапные требования (глава 8)

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

Это сто́ит того, чтобы повторить еще раз: команды поставляли ПО за треть обычного времени. После пилотного исследования еще 11 команд достигли того же результата.

Ключевая идея
Личное общение
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри нее.
Манифест Agile для разработки программного обеспечения
Несмотря на успехи технологий, непосредственное, личное общение остается самым эффективным способом общения. Перефразируя [Cockburn2006] (гл. 3), существует несколько осей эффективности общения. Удаление каждой из них делает его менее эффективным.

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

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

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

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

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

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

Секреты сотрудничества

См. также
Вся команда (глава 7)

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

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

Всегда просите помощи, всегда помогайте

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

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

А как насчет программирования и другой работы, требующей глубокой сосредоточенности? Согласно [DeMarco2013], у программиста уходит 15 минут и больше на то, чтобы погрузиться в работу после прерывания. Не может ли культура, в которой все время просят о помощи, повредить общей продуктивности программирования?

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

См. также
Парное программирование (глава 12)
Групповое программирование (глава 12)

Лучший способ избежать длительного отвлечения в случае прерываний – использовать парное или групповое программирование. В случае парного программирования, пока один человек отвечает на вопросы, второй может продолжать размышлять над текущей задачей. По завершении прерывания вопрос «На чем мы остановились?» вернет процесс в прежнее русло. В случае группового программирования прерывание становится еще меньшей проблемой; как правило, оно имеет тенденцию вовсе не происходить, поскольку все работают вместе. А когда происходит, тот, кого отвлекли, просто отходит в сторону, а остальные продолжают работать.

См. также
Согласование (глава 7)

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

Легко входите в дискуссии и выходите из них

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

Когда кто-то начинает разговор, вам не обязательно сразу в нем участвовать. Подслушайте, о чем речь, и решите, нужно ли что-либо от вас. Так, если оказывается, что дискуссия не имеет к вам отношения, то не нужно в ней участвовать. Вы можете вернуться к работе. Это называется «закон мобильности», или «закон двух ног» (Law of Mobility, или Law of Two Feet): «В любой момент времени, если вы не учитесь чему-то важному и не вносите какой-либо вклад в общее дело, переместитесь в то место, где вы будете это делать»³³. И наоборот! Если оказывается, что обсуждение имеет к вам отношение, то присоединитесь к нему.

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

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

Создавайте визуализации

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

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

См. также
Визуальное планирование (глава 8)
Планирование задач (глава 9)

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

Работайте одновременно

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

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

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

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

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

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

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

Стремитесь к согласию

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

Вместо всего этого используйте голосование согласием (consent vote). При таком способе голосования кто-то высказывает предложение, и затем все голосуют одним из следующих способов: «Я согласен» (большой палец вверх при личном общении, «+1» – в групповом чате), «Я вместе с группой» (большой палец в сторону или «+0») или «Я не согласен и хочу объяснить почему» (большой палец вниз или «–1»). Чтобы избежать случайного давления друг на друга, вы можете договориться, что каждый раскрывает свой вариант голосования на счет три.

Если никто не выбирает вариант «Я согласен», предложение не принимается из-за отсутствия интереса. И наоборот, если отсутствуют несогласные, оно проходит. Если все же кто-то не согласен, то объясняет свои возражения, и группа корректирует предложение, чтобы устранить их. Предложение не проходит, пока не устранены все возражения.

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

Соглашайтесь на эксперимент

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

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

Физические командные комнаты

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

Бьорн Фриман-Бенсон, технологический лидер, имеющий многолетний опыт управления распределенными группами, сказал: «Наши виртуальные команды были гораздо менее креативными. Нам приходилось комплектовать команды с большей численностью персонала, чтобы получать тот же уровень креативности… Ключевой момент любого бизнеса, в котором я был, – это творческий потенциал, в удаленных командах его меньше из-за разногласий. Вы можете даже получить больше единиц работы, но тикеты Jira не оплачивают счета» [Shore2019].

Эффект коктейльной вечеринки

Отчасти причина того, что физические командные комнаты более эффективны, заключается в эффекте коктейльной вечеринки, который [Cockburn2006] называет осмотической коммуникацией. Случалось ли вам разговаривать с кем-либо, стоя посреди переполненной людьми комнаты, и внезапно услышать свое имя? Даже если вы были сконцентрированы на вашей беседе, ваш мозг прислушивался ко всем остальным разговорам. Услышав ваше имя, он воспроизвел эти звуки в вашем сознании. Вы слышите не только ваше имя, но и отрывок обсуждения, в котором оно прозвучало.

Представьте себе команду поставки, которая сидит вместе. Члены команды работают в парах и ведут тихие разговоры. Потом один из программистов упоминает что-то насчет управления соединением с базой данных, и другой оживляется: «О, мы с Кейли на прошлой неделе сделали рефакторинг соединений с базой данных. Больше не нужно управлять соединениями вручную». Когда членам команды удобно разговаривать таким образом, то это происходит часто (по меньшей мере раз в день) и всякий раз экономит время и деньги.

Дизайн вашей командной комнаты

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

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

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

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

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

Множество команд

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

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

Личное оборудование и принадлежности

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

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

• много дополнительных белых досок, предпочтительно магнитных, для обсуждений и диаграмм;

• большой пластиковый вечный календарь (на три месяца и больше), чтобы помечать важные даты;

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

• стулья или что-то иное, на чем кто-либо может временно посидеть;

• блокноты или портативные белые доски, позволяющие сидя зарисовать набросок идеи;

• разнообразные игрушки или другие предметы, вдохновляющие на дискуссии и взаимодействие в команде;

• бумага для флипчарта, один-два мольберта для флипчарта и что-нибудь, что позволит прикреплять листы из флипчарта на стену (клейкая лента, кнопки, булавки);

• разноцветные индексные карточки (не менее 2000 штук каждого цвета). Убедитесь, что каждый в команде различает цвета³⁴;

• стикеры разного цвета, размера и формы;

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

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

• магнитные кнопки для прикрепления карточек и документов к доске;

• экземпляр этой книги и другие полезные справочные материалы.

Командам, работающим в парном программировании в режиме личного общения, также понадобятся специальные рабочие станции (см. раздел «Парное программирование» главы 12):

• широкие столы, подходящие для работы бок о бок. Некоторые команды предпочитают иметь или оба варианта столов (столы для работы сидя и стоя), или столы с изменяемой высотой;

• один компьютер уровня разработки для каждой рабочей станции;

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

• не менее двух мониторов на каждой станции.

Командам, работающим в групповом программировании в режиме личного общения, тоже понадобятся специальные рабочие станции (см. раздел «Групповое программирование» главы 12):

• столы, за которыми поместятся каждый член команды и несколько гостей, и пространство, достаточное для того, чтобы люди могли меняться местами;

• кресло «водителя» – с удобным доступом, мышью, клавиатурой и компьютером уровня разработки;

• кресло «штурмана» – за тем же столом, что и кресло «водителя», или достаточно близко, чтобы «водитель» и «штурман» могли беспрепятственно общаться;

• не менее одного монитора, обычно с диагональю от 60 дюймов, достаточно большого, чтобы его было видно со всех мест. Телевизоры с разрешением 4K тоже вполне пригодны для этой цели. Убедитесь, что всех все устраивает с учетом разницы в зрении.

Не покупайте программное обеспечение для управления жизненным циклом Agile или другие системы отслеживания, если команда не просит именно его, и даже если просит, подождите, пока члены команды сначала наберутся опыта, несколько месяцев работая с практиками планирования, представленными в этой книге. Больше информации можно найти в подразделе «Корпоративные системы отслеживания» главы 10.

Примеры командных помещений

Схема рабочего пространства, представленная на рис. 7.1, основана на командных помещениях, которые я видел в штаб-квартире Spotify в 2015 году. Каждое помещение имело рабочую зону со множеством белых досок, зону для общения и комнату для частных разговоров, вмещающую от трех до пяти человек. За пределами помещения был широкий коридор с уютными диванами и креслами и вешалка для верхней одежды.

Рис. 7.1. План командного помещения, вдохновленный Spotify

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

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

Рис. 7.2. План бюджетного командного помещения

Это было отличное пространство с одним серьезным недостатком: перегородкой между программистами и продакт-менеджером. (На рисунке я ее удалил.) В результате продакт-менеджер сидел снаружи комнаты и не мог слышать членов команды и участвовать в общих дискуссиях. Команда не получала своевременных ответов на вопросы и часто имела проблемы с требованиями по продукту.

Адаптация к физической командной комнате

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

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

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

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

Виртуальные командные комнаты

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

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

Оборудование и инструменты для удаленной работы

Удаленным командам нужна электронная версия командного рабочего пространства:

• ПО для видеоконференций, такое как Zoom, для общения в реальном времени;

• ПО для обмена сообщениями (мессенджер), например Slack;

• виртуальная белая доска, например Miro или Mural, для простого взаимодействия в свободной форме;

• инструменты для конкретных задач, где это возможно, в версиях для совместного использования, такие как Figma для UX- и UI-дизайна;

• хранилище для документации, например DropBox, Google Drive или Вики;

• недорогие планшеты для использования в качестве доски, на которой можно совместно рисовать наброски;

• дополнительный монитор или планшет для видеоконференций, чтобы люди могли видеть друг друга и одновременно работать;

• для команд поставки инструменты для совместного программирования, например Tuple или Visual Studio Live Share, с поддержкой парного или группового программирования (более подробную информацию см. в разделах «Парное программирование» и «Групповое программирование» главы 12).

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

Организация удаленного взаимодействия

См. также
Согласование (глава 7)

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

Я просил людей, имеющих опыт работы с офисными и удаленными командами, поделиться приемами удаленного взаимодействия³⁷. Вот несколько отличных советов.

• Находите время для личных контактов. Команды, общающиеся лично, формируют дружеские связи и взаимное уважение, и это позволяет им принимать решения быстро и эффективно. Виртуальным командам будет полезно выделять время на общение и интересоваться жизнью друг друга. Примеры – виртуальные перерывы на кофе, которые помогают снизить напряженность в общении; отдельные чаты и каналы для приветствий по приходе и выходе из офиса и личных сообщений; а также 30-минутные ежедневные звонки для неформального общения или игр. Одна из команд выработала привычку выделять первые 5–10 минут каждой встречи на неформальное общение; люди могли либо приходить пораньше и общаться, либо приходить позже, непосредственно к деловой части встречи, по настроению. Другая команда специально выделяла время для празднования успехов.

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

Сделайте неявное явным. При личном общении многие социальные сигналы подаются с помощью малозаметных изменений выражения лица и языка тела. При виртуальном общении эти сигналы обычно не видны. Поэтому сделайте их явными. Например, один человек сделал индексные карточки, которые он держал во время видеозвонков. На них было написано «+1», «Обеспокоен», «+1 000 000» и «Да-а-а-а! Сделаем это!» (Пусть это будет весело!) Кроме того, демонстрируйте, что вы доступны для общения. Ставьте в групповом чате статус, оповещающий о том, где вы, что делаете и открыты ли для разговора.

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

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

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

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

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

Младшие члены команды

Бьерн Фриман-Бенсон описывает проблему младших членов команды (джуниоров) как один из трех вызовов распределенных команд:

У начинающих разработчиков очень много вопросов. Они не знают, как делать свою работу. И в то же время они находятся на низшей ступени иерархии. Они не решаются перебивать и не хотят выглядеть обузой.
В InVision [где Бьерн был техническим директором], все команды которой были полностью удаленными, джуниор-разработчики не могли видеть, что делают все остальные. Они боялись прервать других. «Они замирали и тянули время, – говорил Бьерн, – до самого последнего момента, пока их напрямую не спрашивали, чем они заняты» [Shore2019].

Бьерн Фриман-Бенсон. Три проблемы распределенных команд

См. также
Парное программирование (глава 12)
Групповое программирование (глава 12)

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

Вопросы

В физической комнате моей команды слишком шумно, я не могу сосредоточиться. Что мне делать?

См. также
Согласование (глава 7)
Ретроспективы (глава 11)

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

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

Когда начинается разговор, вся команда перестает делать то, что делала, и начинает слушать. Что мы можем сделать, чтобы люди перестали так легко отвлекаться?

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

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

Предварительные требования

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

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

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

См. также
Парное программирование (глава 12)
Групповое программирование (глава 12)
Согласование (глава 7)

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

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

Показатели

Когда у вас хорошая командная комната:

• члены команды взаимодействуют быстро и эффективно;

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

• вам не нужно угадывать ответ. Если кто-либо в команде его знает, вы можете спросить у него и получить быстрый ответ;

• члены команды самостоятельно формируют кросс-функциональные группы для решения проблем;

• в команде царит атмосфера товарищества и взаимного уважения.

Альтернативы и эксперименты

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

См. также
Групповое программирование (глава 12)

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

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

Литература для дополнительного чтения

В книге Agile Software Development [Cockburn2006] есть отличная глава, посвященная общению. В главе 3 Communicating, Cooperating Teams обсуждаются источники информации, качество коммуникации и множество других концепций, связанных с использованием общих командных комнат.

The Remote Facilitator’s Pocket Guide [Clacey2020] содержит краткий и полезный материал о фасилитации. Книга в большей степени ориентирована на удаленные сессии, но советы, представленные в ней, будут ценны и для людей, работающих в формате личного общения.

Безопасность

Аудитория
Вся команда

Гитте Клитгаард

Мы без страха делимся противоречивыми точками зрения.

В 2012 году Google запустил проект «Аристотель» – внутреннее исследование, призванное определить, почему одни команды достигали успеха, а другие нет. Google учитывал несколько факторов: состав команды, общение вне работы, образование, являются ли члены команды экстравертами или интровертами, работают в офисе или удаленно, трудовой стаж, численность команды, индивидуальная продуктивность и др. Ничто из перечисленного не оказывало значительного влияния на эффективность, даже стаж и индивидуальная продуктивность.

А что имело значение? Психологическая безопасность.

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

Понятие командной эффективности

Выводы Google сделали психологическую безопасность центром внимания, однако это не новая идея. Она была введена в 1965 году Эдгаром Шейном и Уорреном Беннисом в контексте проведения личных и организационных изменений. «Для того чтобы дискомфорт приводил к усилению желания учиться вместо усиления беспокойства… должна быть создана среда с максимальной психологической безопасностью» [Schein 1965, р. 44].

Понятие психологической безопасности

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

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

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

Как создать атмосферу безопасности

Чувство безопасности очень индивидуально. Оно нематериально и зависит от контекста. Обмен информацией, безопасный для одних участников, может казаться небезопасным для других. Например, вы начинаете разговор с легкой светской беседы наподобие: «Чем вы занимались в выходные?» Один человек уверенно отвечает: «Я ходил в горы с женой». Другому не очень хочется отвечать. Он провел выходные со своим бойфрендом и беспокоится, что если поднимет эту тему, то пойдут неприятные разговоры о его сексуальной ориентации.

Прежний опыт – тоже важный фактор. Я (Гитте) работала с 60-летним человеком, который всегда избегал упоминания пола своего мужа. Он говорил «мой партнер» вместо «мой муж» и никогда не использовал местоимения. Разумом этот человек понимал, что тема его отношений не вызывает у меня дискомфорта, и я никогда не обращалась с ним плохо, но он вырос в то время, когда быть геем было наказуемо, и инстинктивно старался себя защитить.

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

Техники, представленные в этой главе, помогут вам создать атмосферу безопасности.

Дать возможность высказаться всем

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

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

Один из способов – начинать каждое собрание с краткого вступления. Оно может быть совсем небольшим, например: «Выразите одним словом ваше настроение сегодня» или «Расскажите, какая погода сегодня за вашим окном». Когда человек один раз уже сказал что-либо на собрании, ему легче заговорить еще раз позже. Кроме того, дайте возможность пропустить участие. Это покажет всем, что не высказываться тоже безопасно.

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

Открыто говорите об ошибках

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

У Мэтта Смита есть техника, называющаяся «Поклон неудачи» (the failure bow) [Smith2012]. Лучше всего она работает, когда становится общей нормой в команде. Когда вы сделаете ошибку, встаньте, вытяните руки высоко вверх. «Я ошибся!» – скажите это, широко улыбаясь. Остальные тоже начнут улыбаться и, может быть, даже аплодировать. Превратите ошибку во что-то смешное. Это ее обезвредит.

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

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

Будьте любознательны

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

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

Научитесь давать и получать обратную связь

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

Например, если кто-то предлагает поправки в коде, но не учел вопрос обработки ошибок, не говорите: «Ты забыл добавить обработку ошибок». Это перемещает фокус на человека и на то, что он забыл сделать. Вместо этого сфокусируйтесь на идее и развивайте ее: «Куда мы добавим обработку ошибок?» Или: «Давайте добавим сюда обработку ошибок».

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

1. Создайте открытость. Попросите разрешения дать обратную связь: «Жоржетта, могу я поговорить с тобой о том, что ты сказала сегодня во время стендап-митинга?»

2. Опишите поведение. Будьте конкретны насчет того, что случилось: «Сегодня во время стендап-митинга ты пошутила, что люди низкого роста не ходят на свидания. Это была твоя третья шутка на эту тему на текущей неделе».

3. Заявите о последствиях. Опишите, как это повлияло на вас: «Тема моего роста для меня чувствительна, и, хотя я и посмеялся, у меня все утро было плохое настроение».

4. Сформулируйте запрос. Объясните, что бы вы хотели изменить, поощрить или предотвратить: «Я бы хотел, чтобы ты перестала шутить на эту тему».

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

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

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

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

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

Подумайте над заключением рабочего соглашения о том, как давать и получать личную обратную связь. Некоторые советы можно найти в пункте «Разумные конфликты с обратной связью» главы 11.

Используйте эмпатию

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

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

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

Agile Conversations [Squirrel2020] – отличный ресурс, который позволит начать понимать последствия разговоров и научиться быть более эффективными.

Позвольте себе быть уязвимым

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

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

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

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

Роль лидера

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

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

Техники, представленные ниже, помогут вам создать атмосферу безопасности в ваших командах.

Моделирование поведения, которое вы хотели бы видеть

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

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

Будьте конкретны касательно своих ожиданий

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

Не уклоняйтесь от конфликта

Безопасность не означает, что люди всегда получают то, чего хотят. Она подразумевает, что все мнения принимаются во внимание.

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

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

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

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

См. также
Динамики команды (глава 11)

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

Упражнение на построение взаимоотношений в команде
Это забавное упражнение вы можете использовать для налаживания взаимопонимания в вашей команде. Оно хорошо работает как самостоятельное упражнение, а также может быть частью вашей начальной сессии согласования при разработке устава проекта (см. раздел «Согласование» далее в этой главе).
Цель этого упражнения – показать членам команды, что у них гораздо больше общего, чем им кажется. Если вы работаете в общем помещении, то найдите в офисе большое открытое пространство, в котором можно свободно передвигаться. Если команда работает удаленно, то попросите каждого загрузить свое фото на общую виртуальную белую доску. (Готовьтесь, это будет весело!) Затем, когда будете готовы, повторяйте шаги, указанные ниже.
1. Один человек делает заявление о себе: «Я люблю собак».
2. Каждый, кто согласен с этим заявлением, подходит и становится рядом с этим человеком. Удаленные команды передвигают свое фото.
3. Следующий человек делает свое заявление: «Мой любимый язык программирования – Perl». И т. д.
Продолжайте, пока время не истечет. Люди могут поделиться всем, чем захотят, многим или немногим.

Вопросы

Что бы я ни делал, один из членов команды не хочет высказываться. Как я могу ему помочь?

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

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

Еще один вариант для такого человека – проговорить свои идеи с приятелем в команде. Это позволит заранее отрепетировать то, что он хочет сказать, или он может попросить приятеля представить его точку зрения.

Я видел кое-что и знаю, что это повлияло на одного человека. Но меня беспокоит, что он не чувствует себя в достаточной безопасности, чтобы рассказать об этом. Что мне делать?

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

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

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

Разве мы не проведем время с большей пользой, занимаясь своей работой, а не обсуждая свои чувства?

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

Вспомните выводы проекта «Аристотель». Безопасность была показателем номер один производительности команд Google. И даже если это не так, работа – огромная часть нашей жизни. Разве вы не хотите, чтобы она проходила в обстановке, в которой вы и ваши коллеги могут выражать себя без страха?

Предварительные требования

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

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

Показатели

Когда в вашей команде царит атмосфера психологической безопасности:

• члены команды говорят о своих ошибках и чему они их научили;

• они конструктивно выражают несогласие;

• они выносят на общее обсуждение идеи и проблемы;

• команда создает лучшие продукты, содержащие больше идей;

• легче нанимать и удерживать людей с разнообразным опытом.

Альтернативы и эксперименты

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

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

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

См. также
Ретроспективы (глава 11)

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

Литература для дополнительного чтения

The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation and Growth³⁹ [Edmonson2018] – новая книга Эми Эдмонсон, профессора Гарвардской школы бизнеса. Это хорошая книга о многих аспектах психологической безопасности, которую исследовала автор.

Building a Psychologically Safe Workplace [Edmonson2014] – выступление Эми Эдмонсон на TEDx; легкое, быстрое погружение в тему.

Time to Think: Listening to Ignite the Human Mind [Kline2015] посвящена тому, как создать пространство и время для размышлений на работе. Книга содержит практические советы, которые я использую на большинстве встреч.

Цель

Аудитория
Продакт-менеджеры, коучи

Мы понимаем, ради чего работаем.

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

В практике «Цель» объясняется, как сделать так, чтобы каждый понимал общую картину, а не только детали.

Начните с ви́дения

Прежде чем у продукта появляется команда, у кого-то в компании рождается идея. Предположим, это некто в компании Wizzle-Frobitz (выдуманное название). «Эй! – восклицает он (или она), в порыве воодушевления смахивая свой кофе со стола. – Мы могли бы frobitz наши wizzle намного лучше, если бы у нас было ПО, которое сначала сортировало бы wizzle!»

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

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

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

Идентифицируйте цель

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

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

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

См. также
Вовлечение реального заказчика (глава 8)

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

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

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

Задокументируйте цель

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

Проект документа о цели – первый примерный набросок в документировании этого обсуждения. Он используется для того, чтобы развивать дискуссию. Формат документа зависит от стандартов вашей компании. Некоторые компании любят использовать ключевые показатели эффективности (Key Performance Indicators, KPIs) или подход OKR (Objectives and Key Results – цели и основные результаты). Каким бы ни был формат, вам в конечном итоге нужно ответить на три вопроса.

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

2. Миссия. Как команда может реализовать концепцию в следующие 3–6 месяцев? Опишите, что, по ожиданиям, команда должна выполнить и что лежит за пределами объема работ, но на высоком уровне. Оставьте больше пространства команде для проработки деталей. Сосредоточьтесь на итогах и ценности до результатов. Может быть полезным сначала подумать о конкретных результатах, но двигаться в обратном направлении, то есть начать с «почему», а не «что».

3. Показатели. Как члены команды узнают, что они на верном пути? Опишите до пяти кратких показателей успеха. Будьте конкретны и недвусмысленны. Избегайте разговоров о конкретных функциональностях (например, «поставить функциональность Х к дате Y»). Вместо этого пишите о коммерческих результатах, которых ожидают стейкхолдеры. Объясните, как понять по показателю, что ценность миссии была достигнута. Если это трудно сделать, то, вполне возможно, ваша миссия не сфокусирована на ценности.

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

Вспомните Манифест Agile: «Сотрудничество с заказчиком важнее согласования условий контракта». Документ о цели описывает механизм сотрудничества, а не является контрактом. В процессе работы и по мере накопления командой знаний о рынке цели будут меняться.

Пример цели
Ви́дение: команда «Снежный человек» помогает другим командам взаимодействовать на дальних расстояниях. Наши заказчики добиваются того же высокого уровня взаимодействия в случаях, когда команды сидят в одном рабочем помещении. Используя обычные инструменты для демонстрации экрана, человек становится узким местом для всего обсуждения. Наши инструменты позволяют участвовать каждому. Это превращает взаимодействие на расстоянии в эффективное и приятное занятие, в то же время давая нам возможность зарабатывать на оплате подписки лояльными клиентами.
(Обратите внимание, ви́дение фокусируется на ценности в долгосрочной перспективе.)
Миссия: наша первая миссия – создание инфоповода. Наша цель на данный момент – не в создании постоянного дохода, а в том, чтобы доказать жизнеспособность идеи и привлечь внимание к нашему уникальному взгляду на удаленное сотрудничество.
Мы будем это делать, создавая инструмент для одновременной работы, повторяющей принцип работы с индексными карточками на столе. Это не инструмент продакт-менеджмента, не инструмент для отслеживания или проведения ретроспектив. Это «песочница» свободной формы, способная выполнять любую из этих задач. Она сфокусирована на взаимодействии и простоте. Она выделяется своим качеством. Она не предоставляет возможности для чата или видеоконференции, но по-прежнему сфокусирована на базовой функции «песочницы» для одновременного сотрудничества.
(Обратите внимание, что миссия начинается с ценности, затем переходит к деталям конечного продукта.)
Показатели
1. Мы представим первый макет и план для как минимум 20 потенциальных заказчиков. Мы будем считать, что достигли успеха, если 70 % из них скажут, что это решает их проблемы с взаимодействием. Так мы узнаем, является ли наш подход жизнеспособным.
2. Мы проведем демонстрацию ранней версии на стенде во время отраслевого мероприятия. Мы будем считать, что достигли успеха, если минимум 100 человек остановятся и проявят интерес и по меньшей мере 50 подпишутся на бета-версию. Это будет означать, что люди заинтересованы в продукте.
3. Выпустив открытую бета-версию, мы будем считать, что достигли успеха, если минимум 500 команд подпишутся на нее за первый месяц. Это будет означать, что люди заинтересованы в продукте.
4. Через четыре месяца после запуска бета-версии продукта мы будем считать, что достигли успеха, если минимум 100 команд будут оплачивать продукт и пользоваться им регулярно, что будет определяться как минимум одной авторизацией и изменением в течение каждых двух недель. Это будет означать, что продукт полезен в реальной жизни.
(Обратите внимание, что каждый показатель описывает, как он соотносится с целью. Существует множество способов, позволяющих команде оценивать свой прогресс уже на раннем этапе.)

Внесите цель в свой устав

Создав проект документа c предварительным описанием цели и утвердив его с вашими ключевыми стейкхолдерами, вы готовы обсудить его с остальными членами команды. Обычно это происходит во время сессии подготовки устава⁴⁰, также называемой взлет, после одноименной книги [Larsen2016]. Подробная информация о том, как спланировать эту сессию, представлена во врезке «Планирование сессии подготовки устава» далее в текущей главе.

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

Проверьте черновик цели

Сессия подготовки устава начинается с обсуждения цели команды⁴¹. Начните с презентации черновика ви́дения. Будет лучше, если его презентует тот, кто руководил подготовкой черновика. Обычно это делает продакт-менеджер, входящий в команду.

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

Получите общее согласие с ви́дением

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

Совершенствуйте миссию

За ви́дение отвечает спонсор, а за миссию – команда. Именно она отвечает за претворение миссии в жизнь, поэтому должна взять на себя и ответственность за нее.

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

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

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

Пересмотрите показатели

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

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

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

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

Стремитесь к цели

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

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

Примечание
Если во время вашей сессии подготовки устава вы обсуждаете и цель, и контекст (см. раздел «Контекст» далее в этой главе), то можете обсудить контекст и только потом пригласить спонсора.
Планирование сессии подготовки устава
Сессии подготовки устава (chartering session) начинаются с обсуждения цели, но, помимо этого, обычно обсуждаются контекст и согласование (см. разделы «Контекст» и «Согласование» далее в этой главе). Если вы планируете обсудить все три элемента, то выделите на сессию два полных дня. Вы же не хотите спешить, а если закончите раньше, то никто не будет в обиде. Чего нельзя будет сказать, если процесс затянется.
Удаленным командам нужно столько же времени, сколько и командам, работающим в режиме личного общения, – около 15 часов или, возможно, больше; но их сессия должна быть разбита на меньшие периоды, как правило, не превышающие четырех часов в день. Длительные собрания очень утомительны, если проводятся в виртуальном формате, поэтому разделите их. Убедитесь, что все могут полностью погрузиться в дискуссию, и проводите сессию с включенным видео, если это возможно (см. врезку «Личное общение» выше в текущей главе).
Как вариант (особенно для новых команд), с помощью сессии подготовки устава бюджет, заложенный на поездки, можно использовать для построения взаимоотношений. Проведите сессию в приятном месте за пределами офиса и отведите дополнительный день на развлечения, которые позволят лучше узнать друг друга, и, возможно, даже на совместный осмотр каких-либо достопримечательностей.
В сессии должны принимать участие ваш исполнительный спонсор, ключевые стейкхолдеры, члены команды и продакт-менеджер (если он/она уже не является частью команды). Спонсор открывает встречу, поприветствовав и поблагодарив участников, кратко описав бизнес-преимущества командной работы и заявив поддержку инициативы. Затем спонсор может уйти, если не желает участвовать в дискуссии.
Будет лучше, если кто-то, имеющий навыки фасилитации, будет вести сессию, особенно при наличии шансов, что она перерастет в спор. Этим кем-то может быть коуч команды, но часто лучше привлечь представителя нейтральной третьей стороны. Вы можете попросить помочь коуча другой команды или нанять внешнего фасилитатора. В крупных организациях отдел кадров может иметь в своем штате профессионального фасилитатора.
Когда обсуждение цели и контекста закончено, исполнительный спонсор возвращается, чтобы подтвердить свою поддержку. На этом участие стейкхолдеров завершается. Члены команды выражают им свою благодарность за участие и дальше продолжают обсуждение одни. (Люди, близко работающие с командой, например продакт-менеджер, тоже могут участвовать.)
Закончите вашу сессию подготовки устава празднованием, особенно если она продолжалась несколько дней. Как минимум поблагодарите друг друга за проделанную трудную работу. Если есть возможность, то пойдите куда-нибудь вместе развлечься. Помните, что сначала нужно сделать перерыв, чтобы интроверты в вашей команде смогли перезарядиться.
После всего этого разместите результаты сессии где-нибудь в заметном месте вашей командной комнаты. Возможно, вам понадобится переписать их, чтобы сделать более понятными.
• Концепция, миссия и показатели (из раздела «Цель»).
• Контекстная диаграмма (из раздела «Контекст»).
• Рабочие соглашения и стандарты (из раздела «Согласование»).
Остальные составляющие сессии подготовки устава обнародовать не обязательно, но нужно сохранить копию инвентарного списка навыков и подтвержденных ресурсов (из части «Контекст»), чтобы использовать в дальнейшем. Другие составляющие также могут пригодиться.

Продвигайте цель

См. также
Информативное рабочее пространство (глава 9)
Визуальное планирование (глава 8)
Демо для стейкхолдеров (глава 10)

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

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

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

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

Обновляйте цель

Цель команды будет меняться со временем. Показатели будут устаревать, и команда будет узнавать что-то новое о своих стейкхолдерах, заказчиках и рынке. В результате вам понадобится обновлять цель. Это изменяемый документ.

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

Вопросы

Может ли вся команда участвовать в обсуждении проекта цели?

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

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

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

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

Наш спонсор постоянно меняет свое мнение. Как можно заставить его выбрать одно направление и придерживаться его?

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

См. также
Адаптивное планирование (глава 8)

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

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

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

Предварительные требования

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

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

Показатели

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

• легко приоритизировать функциональности;

• продакт-менеджеры без труда обосновывают перед стейкхолдерами свои решения по приоритизации;

• разработчики вносят свой вклад в принятие решений при планировании, предлагая способы того, как повысить ценность, одновременно снизив затраты;

• ключевые стейкхолдеры уверены, что команда разрабатывает именно то, что им нужно;

• организация поддерживает усилия команды.

Альтернативы и эксперименты

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

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

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

Литература для дополнительного чтения

Liftoff, Second Edition: Start and Sustain Successful Agile Teams [Larsen2016] – комплексное руководство по планированию устава в Agile. Оно легло в основу практик в разделах «Цель», «Контекст» и «Согласование» этой книги. Особенно полезны рекомендации по подготовке и фасилитации сессий подготовки устава.

Impact Mapping⁴² [Adzic2012] содержит милую дискуссию о том, как определить цели и создать хорошие показатели (автор называет их «измерители»), в главе Creating an Impact Map.

Контекст

Аудитория
Продакт-менеджеры, коучи

Мы знаем, с кем и с чем мы должны работать.

Какие навыки доступны для вашей команды? Какие ресурсы у вас есть? Кто ваши стейкхолдеры?

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

Запишите контекст в устав

См. также
Цель (глава 7)

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

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

Доступные навыки

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

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

Некто, имеющий опыт в эксплуатации, может сказать: «Я – Ха Лам, и я работаю в эксплуатации пять лет, два из которых – в этой компании. Моя специализация – инфраструктура как код (IaC), и у меня есть опыт в кибернетике. У меня хорошие связи с командой платформ и есть допуск к развертыванию в эксплуатационной среде».

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

См. также
Цель (глава 7)

Обсудив навыки всех участников, обратите общее внимание на цель команды. (Вы можете записать ее на флипчарте или в общедоступном документе; кроме того, можно раздать всем копии.) Прочтите несколько пунктов, а затем попросите участников свериться с перечнем навыков. Не пропущены ли какие-либо навыки или разрешения, которые могут понадобиться команде? Предложите команде одновременный мозговой штурм (см. пункт «Работайте одновременно» выше в данной главе), чтобы подготовить стикеры или их виртуальный эквивалент, по одному на каждый навык.

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

Границы и взаимодействия

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

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

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

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

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

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

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

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

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

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

Выделенные ресурсы

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

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

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

1. Кто может предоставить каждый элемент.

2. Насколько они готовы его предоставить.

3. Как его получить, если это неочевидно.

Группа может работать над несколькими стикерами одновременно.

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

Обязательства спонсора

См. также
Цель (глава 7)

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

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

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

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

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

1.Agile Fluency – зарегистрированный товарный знак Agile Fluency Project LLC.

2.Дерби Э., Ларсен Д. Agile ретроспектива. Как превратить хорошую команду в великую.

3.Бьянкуцци Ф., Уорден Ш. Пионеры программирования: диалоги с создателями наиболее популярных языков программирования.

4.Источником появления подхода Waterfall часто ошибочно считают статью Уинстона Ройса, написанную в 1970 году. Однако применение фазового подхода восходит еще к 1950-м, а статья Ройса не пользовалась широкой известностью до конца 1980-х, когда к ней стали прибегать для описания того, что люди уже давно делали [Bossavit2013, chapt. 7].

5.Алистер Кокберн, цитата Джима Хайсмита в [Highsmith2001]. Полная цитата: «Лично я не ожидал… что эта конкретная группа приверженцев различных гибких методик сможет договориться о чем-либо по существу… Что касается меня, я в восторге от окончательной формулировки [Манифеста]. Я был удивлен, что и другие оказались так же довольны окончательной формулировкой. Таким образом, мы все же смогли договориться о чем-то по существу».

6.Фаулер выражал эту идею множество раз в течение нескольких лет. Оригинальную версию можно найти в статье [Fowler2000].

7.Источники: Mueller’s February 3, 2005, testimony to Congress (https://oreil.ly/GlQSa) и Inspector General Glenn Fine’s May 2, 2005, testimony to Congress (https://oig.justice.gov/node/672).

8.Впервые я прочел эту историю в трудах Ричарда Фейнмана, где в числе прочего была представлена его речь на церемонии вручения дипломов в Калтехе в 1974 году [Feynman1974]. История основана на реальных ритуалах, практиковавшихся в Меланезии после Второй мировой войны.

9.Эта последовательность действий следует из рассуждений Алистера Кокберна о сюхари (Shu-Ha-Ri).

10.Временные рамки, приведенные в этой главе, приблизительны и основаны на моем опыте. Ваш опыт может быть другим.

11.Отрывок из статьи Мартина Фаулера Enterprise Rails (http://martinfowler.com/bliki/EnterpriseRails.html).

12.Спасибо Джорджу Динвидди за это замечание.

13.Спасибо Джею Базузи за то, что обратил мое внимание на эти соглашения о commit-сообщениях (https://oreil.ly/7vSmz).

14.У Стивена Смита есть хорошая статья об этой модели (https://oreil.ly/1KQ38), включающая советы о том, как помочь команде на каждом этапе.

15.Спасибо Диане Ларсен за помощь в составлении этого списка.

16.Диана говорит: «Коммуницируйте, пока вас не затошнит. И даже потом продолжайте».

17.Термин «кайдзен» был импортирован в Agile из концепции бережливого производства (lean manufacturing), которая, в свою очередь, основывается на революционной производственной системе компании Toyota, – отсюда и японский термин. Рифмуется с английским I win – «я выигрываю».

18.Обратите внимание, что метод Kanban – это значительно более широкое понятие, чем доска Kanban, применяемая некоторыми командами для визуализации планирования.

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

20.Алистер Кокберн называет этот феномен организационными антителами. Чем более успешна инициатива по изменениям, тем больше люди беспокоятся о ее влиянии на них и тем сильнее сопротивляются изменениям.

21.Дерби Э. Психология управления изменениями. Семь главных правил.

22.Спасибо Эндрю Стельману за то, что в Twitter-посте указал на опасность горизонтального перемещения (https://oreil.ly/E0EaB).

23.Большое спасибо Басу Водде за отзывы по теме LeSS.

24.Большое спасибо Рону Куартелу за отзывы по теме FAST.

25.Буквально «приращение», «добавка». Часть (или версия) создаваемого продукта, потенциально готовая к использованию и увеличивающая ценность для конечных пользователей/потребителей. Инкремент необходимо показывать конечным потребителям для получения от них обратной связи (отзывов, замечаний и предложений).

26.См. https://www.scaledagileframework.com/features-and-components по состоянию на 30 июня 2021 года.

27.Эти списки взяты из [Shore2018b].

28.III – его полное имя. Произносится как «три».

29.Название Scrum-мастер пришло из популярного метода Scrum. Оно вводит в заблуждение: предполагает кого-то, кто достиг мастерства в понимании Scrum, а не того, кто имеет власть или контроль над командой.

30.В личном общении.

31.Марик определял четыре ценности, которые он видел в ранних Agile-командах: навык, [само]дисциплина, легкость, радостный настрой [Marick2007a].

32.Катценбах Дж., Смит Д. Командный подход: Создание высокоэффективной организации.

33.Закон мобильности, или закон двух ног, пришел из «Технологий открытого пространства» Харрисона Оуэна – прекрасного подхода к организации продуктивных дискуссий в больших группах.

34.Один из восьми человек имеет ту или иную форму дальтонизма.

35.Профессиональный совет: следы от перманентного маркера на белой доске можно удалять, рисуя поверх него маркером для белой доски и немедленно стирая.

36.Гибридно-удаленная команда в одни дни работает в режиме личного общения, а в другие – в удаленном режиме. В частично удаленной команде часть людей работает в офисе, а часть – удаленно.

37.Спасибо Дэйву Пулу, Габриель Хокнесс, Александру Берду, Крису Фентону, Брайану Шефу и Дэйву Руни за то, что поделились своими приемами в Twitter (https://oreil.ly/vwWli). Кроме того, спасибо Бренту Миллеру, Дэннису Макмиллану, Сету Маккарти, Джеффу Олферту, Матту Плавкану за их советы.

38.Первая половина этого определения психологической безопасности («возможность быть собой») основывается на [Kahn1990]. Вторая половина («возможность выдвигать идеи») – на [Edmonson2014].

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

40.На сессии не всегда готовится устав как документ, скорее это сессия, устанавливающая или стартующая проект. Далее оставим вариант «сессия подготовки устава». – Примеч. науч. ред.

41.Данная программа основана на [Larsen2016] (гл. 6), с небольшими изменениями.

42.Аджич Г. Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке.

43.Этот план основан на [Larsen2016] (гл. 7), с некоторыми изменениями. Я добавил перечень навыков, частично вдохновленный активностью «Основная группа», и удалил их активность «Перспективный анализ», чтобы сохранить ее в разделе «Визуальное планирование» главы 8.

44.Это называется приоритизация MoSCoW (must have, should have, could have and won’t have). Последняя категория обычно называется «не будет» (won’t have), но я называл ее «не нужно» (don’t need), чтобы отличать от того, что вы хотели бы, но не можете получить.

Bepul matn qismi tugad.