Текст книги "Искусство Agile-разработки. Теория и практика гибкой разработки ПО"

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

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

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

Книгу 7 Rules for Positive, Productive Change[21]21
  Дерби Э. Психология управления изменениями. Семь главных правил.


[Закрыть] [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 помогут вам оценить прогресс.) К этому моменту некоторые члены команды, возможно, уже сами будут обладать квалификацией, достаточной для того, чтобы выступать в качестве коучей командного уровня, и смогут развивать свои новые навыки в более опытных командах. Убедитесь, что такие горизонтальные перемещения улучшают карьеру ваших коучей, а не вредят ей, иначе их поток может иссякнуть[22]22
  Спасибо Эндрю Стельману за то, что в Twitter-посте указал на опасность горизонтального перемещения (https://oreil.ly/E0EaB).


[Закрыть].

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

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

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

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

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

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

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

Синдром второго ребенка

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

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

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

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

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

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

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

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

LeSS

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


[Закрыть].

Базовый 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. Это детище Рона Куартела и один из наиболее многообещающих подходов к масштабированию, который я когда-либо видел. К сожалению, на момент написания этой книги и наименее проверенный. Я включил его в книгу, поскольку думаю, что он заслуживает вашего внимания[24]24
  Большое спасибо Рону Куартелу за отзывы по теме FAST.


[Закрыть].

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

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

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

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

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

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

Вместо того чтобы разбивать истории на детализированные списки задач, команды FAST создают дерево открытий (discovery tree) для каждого ценного инкремента[25]25
  Буквально «приращение», «добавка». Часть (или версия) создаваемого продукта, потенциально готовая к использованию и увеличивающая ценность для конечных пользователей/потребителей. Инкремент необходимо показывать конечным потребителям для получения от них обратной связи (отзывов, замечаний и предложений).


[Закрыть]. (Ценный инкремент представляет собой то, что может быть выпущено само по себе (см. подраздел «Ценные инкременты» главы 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.