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

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

Agile-разработка является скорее адаптивной, чем предиктивной; ориентированной скорее на людей, чем на процессы[6].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ваши первые шаги зависят от того, чего вы хотите. Вы присоединяетесь к действующей команде 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-практики объединены множеством зависимостей друг от друга, поэтому обязательно обратите внимание на блоки «См. также» и подраздел «Предварительные требования» каждой практики.

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

В 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 месяцев[10]. В части 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 поначалу замедлит работу ваших команд.

Насколько они замедлятся? Объективных критериев продуктивности в разработке программного обеспечения нет [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 от его предшественников. Приложите максимальные усилия, чтобы интересы бизнеса, клиентов и конечных пользователей были представлены в вашей команде. Если этого не сделать, то поставленное программное обеспечение, скорее всего, разочарует.

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

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

Каждой команде нужен коуч, который поможет ей научиться быть эффективной 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.

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

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

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

Руководители часто занимаются микроменеджментом, когда не знают, чем еще им заниматься, или когда боятся, что им не найдется места в среде 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), как и любые другие запросы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код, написанный в результате парного или группового программирования, уже может считаться прошедшим дополнительное ревью, поэтому команды могут начать не глядя штамповать отзывы об этом коде. Однако это тоже вызывает сложности, так что лучше убрать данное требование до того, как начинать широкое распространение 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); или

Команда не может полностью контролировать свой процесс разработки (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы); или

Команда работает с существующим кодом (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы); или

Команда ограничена требованиями руководства, отданными на высоком уровне (см. раздел «Смените водопадные подходы в управлении» текущей главы); или

Команда ограничена требованиями безопасности (см. раздел «Решите проблемы, связанные с безопасностью» текущей главы).

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, чтобы мотивировать организационные изменения[18]. 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 в течение трех месяцев. После этого мы оценим, что работает, что нет, и попробуем что-то улучшить[19]. Спустя шесть месяцев у вас будет возможность принять решение – продолжаем мы работать с Agile или остаемся с тем, что есть сейчас».

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

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

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

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

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

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

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

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

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

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

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

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

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