Искусство Agile-разработки. Теория и практика гибкой разработки ПО
Шрифт:
• определите, что ей нужно сделать, чтобы успешно внедрить 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].
<