Есть еще один последний уровень в модели Agile Fluency™. Он во многом теоретичен: это возможное будущее Agile. Кроме того, он подходит только для организаций, находящихся на переднем крае теории и практики управления. Это обстоятельство выводит данный уровень за рамки темы этой книги. Вкратце, уровень укрепления предполагает переработку коллективных идей команд и направление их в организационные улучшения. Если вы хотите узнать об этом больше, то прочтите главу 19.
Уровни свободного владения навыками Agile, резюме
Фокусировка
• Основные преимущества: фокус на бизнес-приоритеты, наглядность работы команды, способность менять направление.
• Инвестиции: структура команд, управление, рабочая среда.
• Примерные сроки: падение производительности на 1–4 месяца, достижение владения наыками в течение 2–6 месяцев.
Поставка
• Основные преимущества: мало дефектов и высокая производительность, техническая долговечность.
• Инвестиции: навыки разработки, слияние тестирования и эксплуатации.
• Примерные сроки: падение производительности на 2–6 месяцев, достижение владения навыками в течение 3–24 месяцев.
Оптимизация
• Основные преимущества: повышение уровня ценности релизов и улучшенные продуктовые решения.
• Инвестиции: встроенное управление продуктом, команда несет ответственность за бюджет и планы.
• Примерные сроки: падение производительности на 1–3 месяца, достижение владения навыками в течение 3–9 месяцев.
К каким уровням свободного владения навыками должна стремиться ваша команда? Это зависит от того, на каких из них вас может поддержать ваша организация. В идеале все вместе: фокусировка, поставка и оптимизация – наилучший вариант. Комбинация трех уровней обеспечивает наилучшие результаты и чистейшую реализацию идей Agile.
Но выбор всех трех уровней одновременно требует и максимальных инвестиций. Если вы не можете обосновать их, то у вас наверняка будут сложности с получением необходимой поддержки. А при недостаточных инвестициях вашим командам будет тяжело достичь уверенного владения навыками. Вы понесете расходы на обучение и не получите преимуществ. Вы даже можете увидеть худшие результаты по сравнению с тем, что есть сейчас.
Другими словами, выбирайте те уровни, которые нужны вашей компании и за которые она хочет платить.
Какие же уровни вам все-таки выбрать?
• Каждая команда нуждается в свободном владении навыками на уровне фокусировки. Это базовое свойство. Если ваша компания не может инвестировать по меньшей мере в навыки в фокусировке, то, вероятно, Agile вам не подходит, хотя, возможно, у вас получится постепенно продвигаться в этом направлении, если вы начнете со свободного владения навыками на уровне поставки.
• Свободное владение навыками на уровне поставки снижает затраты и повышает скорость разработки. Без нее ваш код в конечном итоге скатится к техническому долгу. Это делает уровень поставки очевидной целью для большинства команд. Тем не менее многие организации не готовы к большим инвестициям в обучение и качество кода, требующимся для уровня поставки. Тогда имеет смысл начать со свободного владения навыками на уровне фокусировки, продемонстрировать успех и использовать его как положительный пример для обоснования дальнейших инвестиций.
• Свободное владение навыками на уровне оптимизации — это то, где Agile проявляет себя наиболее ярко. Но хотеть этого сразу, возможно, чересчур. Для большинства организаций лучше сначала выстроить доверительные отношения, продемонстрировав навыки на уровнях фокусировки и поставки, а затем постепенно брать на себя больше ответственности. Но если в вашей организации уже принято делегировать полномочия по принятию решений кросс-функциональным командам, как это часто бывает в стартапах, то благодаря свободному владению навыками на уровне оптимизации вы получите великолепные результаты.
Больше информации о каждом уровне и его преимуществах вы можете найти в предисловиях к частям II–IV. Подробная информация о необходимых инвестициях представлена во врезке «Список необходимых инвестиций» в главе 4. Если вы не можете определиться, какой из уровней выбрать, то начните с фокусировки и поставки.
Какие бы уровни вы ни выбрали, инвестируйте в изучение всех относящихся к ним практик одновременно. Практики из более поздних уровней улучшают работу более ранних, поэтому вам лучше осваивать их все вместе, а не по отдельности. Но если вы не можете инвестировать в каждый из желаемых уровней, то это нормально. Процесс будет длиться дольше, но со временем вы сможете добраться и до других уровней.
Определившись с желаемыми уровнями, переходите к более подробному рассмотрению инвестиций, требуемых от вашей организации. Мы будем изучать их в следующей главе.
Как мы видим из предыдущей главы, для того чтобы команды получили все преимущества Agile, ваша организация должна приобщиться к его основополагающей философии. Не просто тратить деньги (это сравнительно легко), а выполнять реальные, осмысленные изменения в организационных структурах, системах и рабочих привычках…
Если это выглядит как очень трудозатратное дело… что ж, так и есть. Неужели эти инвестиции действительно настолько важны?
Да, действительно настолько.
Инвестировать в Agile важно, поскольку вы инвестируете в изменение границ, которые вас сдерживают. По большей части команды сдерживают не процессы, которым они следуют, а ограничения, в которых они находятся. Попробуйте делать эти инвестиции и не следовать практикам, и ваши команды, вероятно, все же покажут улучшение результатов. А если, наоборот, следовать практикам и игнорировать инвестиции? Тогда командам придется тяжело.
Как сказал Мартин Фаулер11, «я вижу поразительную параллель между ДХХ (Давид Хейнемейер Ханссон, создатель 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 ресурсом являются команды.
Вашей организации нужно инвестировать в команды, которые будут:
• кросс-функциональными – члены команды в совокупности обладают всеми знаниями, которые нужны ей для достижения цели;
полностью вовлеченными – внешние специалисты могут время от времени приходить в команду, чтобы помочь, но основные члены команды должны посвящать все свое время только своей команде;
сплоченными – отношения между членами команды дружеские, конструктивные, позволяющие сотрудничать;
• долгосрочными – у команд могут уходить месяцы на то, чтобы понять, как наиболее эффективно работать вместе, поэтому сохраняйте состав команд как можно дольше.
Размер и состав каждой команды зависят от того, какие уровни свободного владения навыками вы выбрали. В разделе «Вся команда» главы 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 от его предшественников. Приложите максимальные усилия, чтобы интересы бизнеса, клиентов и конечных пользователей были представлены в вашей команде. Если этого не сделать, то поставленное программное обеспечение, скорее всего, разочарует.