Таким образом, несмотря на соблазн сразу настроить метод Agile под себя, лучше все же начать со стандартного, «книжного» подхода. Идея удалить наименее знакомые практики выглядит заманчиво, но именно они и будут вам нужны больше всего, если вы действительно собираетесь перейти на Agile. Именно с этими практиками связаны главные изменения в философии.
Как достичь мастерства
Овладение искусством разработки по Agile требует реального опыта использования конкретного, четко определенного метода Agile. Начните со стандартного, «книжного» подхода. Примените его на практике – полностью – и потратьте несколько месяцев, совершенствуя практику и досконально разбираясь, почему она работает. Потом настройте под себя. Выберите один из нюансов, разберитесь с последовавшими переменами и повторите.
Данная книга посвящена этой цели. В ней представлен тщательно подготовленный набор практик Agile, проверенных в реальном мире. Чтобы совершенствоваться в искусстве Agile или просто достичь бо?льшего успеха с помощью практик Agile, выполняйте следующие шаги.
1. Выберите для освоения подгруппу идей Agile. Глава 3 поможет вам определиться.
2. Применяйте как можно больше соответствующих практик. Они описаны в частях II–IV. Практики Agile усиливают друг друга, поэтому работают наилучшим образом, если использовать их все вместе.
3. Применяйте практики строго и последовательно. Если практика не работает, то попробуйте следовать методу еще точнее. Команды-новички в Agile часто недостаточно тщательно следуют практикам. Будьте готовы к тому, что вам потребуются два-три месяца на то, чтобы почувствовать себя комфортно, работая с новыми практиками, и еще от двух до шести месяцев на то, чтобы довести их использование до автоматизма.
4. По мере того как вы почувствуете уверенность в том, что применяете практики правильно (повторимся, отведите на это несколько месяцев), начните экспериментировать, внося изменения. Описание каждой из практик в этой книге дополнено рассуждениями о том, почему она работает и что в ней можно изменить. Каждый раз, меняя что-либо, наблюдайте за результатами и затем вносите дальнейшие улучшения.
5. Последнего шага нет. Разработка программного обеспечения по Agile – это непрерывный процесс обучения и совершенствования. Не прекращайте практиковаться, экспериментировать и развиваться.
На рис. 2.1 показан этот процесс. Сначала следуйте правилам, потом нарушайте их и в конце концов будьте выше правил[9 - Эта последовательность действий следует из рассуждений Алистера Кокберна о сюхари (Shu-Ha-Ri).].
Рис. 2.1. Как достичь мастерства
С чего начать?
Ваши первые шаги зависят от того, чего вы хотите. Вы присоединяетесь к действующей команде Agile, внедряете Agile в работу одной или нескольких команд или стремитесь улучшить свою команду Agile?
Присоединение к действующей команде Agile
Если вы планируете присоединиться к действующей Agile-команде или просто хотите дополнить свои знания о том, как Agile работает на практике, то можете перейти к частям II–IV. Каждая часть начинается с истории в стиле «один день из жизни», описывающей, как может выглядеть Agile. Команды, работающие по Agile, отличаются друг от друга, поэтому и ваша не будет абсолютно такой же. Но эти истории дадут вам представление, чего можно ожидать.
Прочитав истории, переходите к интересующим вас практикам. Каждая написана как отдельный справочный материал.
Введение Agile
Если вы помогаете своей организации сформировать Agile-команды или только хотите убедить ее сделать это, то оставшиеся главы части I помогут вам начать. Чтобы структурировать процесс, используйте чек-лист, представленный ниже.
Сначала убедитесь, что Agile подходит вашей компании:
• выберите подход Agile, который ваша организация сможет поддерживать (см. главу 3);
• определите, что ей нужно сделать, чтобы успешно внедрить Agile (см. главу 4);
• получите согласие на эксперимент с Agile (см. главу 5);
• если у вас несколько команд, то решите, как вы будете их масштабировать (см. главу 6).
За несколько недель до начала:
• определитесь, кто будет коучем (или коучами) команды, и выберите по меньшей мере одного человека, который будет продакт-менеджером (см. раздел «Вся команда» главы 7);
• организуйте встречу продакт-менеджера с исполнительным спонсором команды и ключевыми стейкхолдерами, чтобы разработать замысел проекта (см. раздел «Цель» главы 7);
• обеспечьте команде физическое или виртуальное помещение (см. раздел «Командная комната» главы 7);
• запланируйте и проведите сессию подготовки устава команды (см. врезку «Планирование сессии подготовки устава» в главе 7);
• попросите команду ознакомиться с новым методом. Раздайте людям копии этой книги, чтобы они могли ее изучить самостоятельно, предложите применить некоторые практики в их текущей работе и рассмотрите возможность проведения тренинга по тем практикам, которые вызывают трудности (практики представлены в частях II–IV).
Когда команда будет готова начать, сделайте глубокий вдох и:
• поручите членам команды спланировать первую рабочую неделю (см. подраздел «Ваша первая неделя» главы 9).
Совершенствование действующих Agile-команд
Если у вас уже есть действующие Agile-команды и вы хотите улучшить их работу, то ваш подход будет зависеть от того, какие именно улучшения вам нужны.
Если вы заинтересованы в небольшой регулировке уже работающих процессов вашей команды, то перейдите к частям II–IV и прочитайте об интересующих вас практиках. Если вы хотите более масштабных улучшений, то процесс будет таким же, как и при внедрении Agile в команду, за исключением того, что вам понадобится сосредочиться на конкретных элементах, требующих изменений.
В качестве руководства используйте чек-листы из предыдущего подраздела «Внедрение Agile» данной главы.
Если Agile не срабатывает в вашей организации, то ознакомьтесь с врезкой «Руководство по устранению неполадок» в главе 4.
Применение отдельных практик Agile
Agile работает наилучшим образом, когда вы идете ва-банк, но если это не ваш вариант, то вы можете добавить немного Agile в действующие процессы. Вот подходящие практики, c которых можно начать.
• Ежедневное планирование. Если вы боретесь с частыми прерываниями (interruptions), то попробуйте использовать однодневные итерации (см. раздел «Планирование задач» главы 9). Возьмите за основу игру в планирование (см. раздел «Игра в планирование» главы 8) и измеряемый потенциал (capacity) по работе вашей команды на спринте (см. раздел «Потенциал» главы 9) и проводите совместные сессии планирования в начале каждого дня, откладывая все прерывания на сессию планирования следующего дня. Обеспечьте условия, чтобы люди сами оценивали свои задачи.
Итерации. Если частые прерывания для вас не проблема, но вы все же хотели бы улучшить свое планирование, то попробуйте использовать недельные итерации (см. раздел «Планирование задач» главы 9). В этом случае вы также можете практиковать ежедневные рабочие стендап-митинги (см. раздел «Стендап-митинги» главы 9) и регулярные демо для стейкхолдеров (см. раздел «Демо для стейкхолдеров» главы 10). Со временем рассмотрите возможность использования индексных карточек для планирования и больших диаграмм, показывающих предстоящую работу, как описано в разделе «Визуальное планирование» главы 8.
Ретроспективы. Частое проведение ретроспектив (см. раздел «Ретроспективы» главы 11) – отличный способ адаптировать и улучшить рабочие процессы команды. Могут быть полезны и другие практики, перечисленные в главе 11.
Быстрая обратная связь. Быстрая автоматизированная сборка значительно улучшит вашу жизнь, а также откроет возможности для других усовершенствований (см. раздел «Нулевое трение» главы 13).
Непрерывная интеграция. Непрерывная интеграция (практика, а не инструмент) не только уменьшает проблемы интеграции, но и способствует повышению качества сборок и тестов. Более подробную информацию см. в разделе «Непрерывная интеграция» главы 13.
• Разработка через тестирование. Хотя эту практику не так легко принять, как другие, она весьма эффективна. Разработка через тестирование (см. соответствующий раздел главы 13) позволяет снизить частоту появления программных ошибок (багов), повысить скорость разработки, улучшить вашу способность к переработке кода (рефакторингу) и сократить технический долг. На ее освоение может уйти некоторое время, так что запаситесь терпением.
Другие практики, описанные в частях II–IV, также могут оказаться полезными. Agile-практики объединены множеством зависимостей друг от друга, поэтому обязательно обратите внимание на блоки «См. также» и подраздел «Предварительные требования» каждой практики.
Не расстраивайтесь, если возникнут проблемы с применением отдельных практик. Быстрее и проще выбрать соответствующую группу практик и применить ее полностью, от начала и до конца. Это мы и рассмотрим далее.
Глава 3. Выберите свою гибкость
Нет смысла использовать Agile ради него самого. Задайте себе два вопроса.
1. Поможет ли нам Agile стать более успешными?
2. Чего нам будет стоить достижение этого успеха?
Ответив на эти вопросы, вы поймете, нужен ли вам Agile.
Что ценно для организаций?
Успех определяется не только доходами. Вот только несколько составляющих успеха:
• улучшение финансовых результатов – прибыль, рост выручки, биржевая стоимость акций, снижение затрат;
• достижение целей организации – стратегические цели, оригинальные исследования, благотворительные цели;
• укрепление позиций на рынке – продвижение бренда, конкурентные различия, лояльность существующих клиентов, привлечение новых;
• обретение популярности – стратегическая информация, аналитика, отзывы клиентов;
• снижение риска – безопасность, требования законодательства, аудит;
• увеличение потенциала – наем и удержание персонала, моральный климат и развитие навыков, автоматизация.
Модель Agile Fluency
В 2014 году я сотрудничал с Дианой Ларсен, чтобы проанализировать, почему компании видят разные результаты от их Agile-команд. Мы оба работали с командами с самого начала. С годами мы заметили, что команды начинали склоняться к кардинально разным типам результатов и эти результаты имели тенденцию группироваться в разных «зонах».
Мы обобщили эти наблюдения в модели Agile Fluency™. Ее упрощенный вариант показан на рис. 3.1 [Shore2018b].
Рис. 3.1. Упрощенная модель Agile Fluency™
Каждый уровень связан с набором преимуществ. Чтобы обрести их, команде необходимо свободно (уверенно) владеть навыками, относящимися к этому уровню. Считается, что команда свободно владеет навыками, если способна применять все навыки этого уровня, не прикладывая сознательных усилий.
ПРИМЕЧАНИЕ
Несмотря на то что на рис. 3.1 представлен прямой путь от одного уровня к другому, в реальности все более беспорядочно. Команды могут достигать уверенного владения навыками на любом уровне, в любом порядке, хотя продвижение, показанное на рис. 3.1, типично.
Навыки, необходимые для свободного применения, перечислены в предисловиях к частям II–IV. Но уверенное владение навыками не достигается само по себе. Ваша организация тоже должна инвестировать в эти навыки своих команд. Это гораздо больше, чем поддерживать идеи Agile на словах. Организация должна произвести реальные, значительные изменения, которые занимают время, стоят денег и требуют вложения политического капитала.
Результат, который вы получаете от команд, зависит от того, насколько ваша организация вкладывается в идеи Agile. Компании не удается добиться результатов, которых она хочет от Agile, обычно потому, что она не сделала необходимые инвестиции. Часто организации даже не осознают, что это было нужно.
Инвестирование в Agile должно стать осознанным выбором. Тщательно изучите каждый из уровней. Каждый требует затрат, и каждый имеет свои преимущества. Выберите те уровни, которые имеют наилучшее соотношение затрат и выгоды для вашей ситуации.
Вероятнее всего, вам не удастся убедить вашу компанию инвестировать в каждый уровень. Это нормально. В отличие от моделей зрелости (maturity models), таких как интегрированная модель зрелости возможностей компании при разработке ПО (Capability Maturity Model Integration, CMMI), модель Agile Fluency™ не показывает продвижения от слабых навыков к сильным. Вместо этого она демонстрирует множество вариантов соотношения инвестиций/выгоды. Хотя диаграмма показывает наиболее распространенный вариант продвижения, каждый уровень можно выбрать независимо. Каждый имеет ценность сам по себе.
Уровень владения навыками и степени зрелости
