Искусство Agile-разработки. Теория и практика гибкой разработки ПО
Шрифт:
В качестве руководства используйте чек-листы из предыдущего подраздела «Внедрение Agile» данной главы.
Если Agile не срабатывает в вашей организации, то ознакомьтесь с врезкой «Руководство по устранению неполадок» в главе 4.
Применение отдельных практик Agile
Agile работает наилучшим образом, когда вы идете ва-банк, но если это не ваш вариант, то вы можете добавить немного Agile в действующие процессы. Вот подходящие практики, c которых можно начать.
• Ежедневное планирование. Если вы боретесь с частыми
Итерации. Если частые прерывания для вас не проблема, но вы все же хотели бы улучшить свое планирование, то попробуйте использовать недельные итерации (см. раздел «Планирование задач» главы 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].
< image l:href="#"/>Рис. 3.1. Упрощенная модель Agile Fluency™
Каждый уровень связан с набором преимуществ. Чтобы обрести их, команде необходимо свободно (уверенно) владеть навыками, относящимися к этому уровню. Считается, что команда свободно владеет навыками, если способна применять все навыки этого уровня, не прикладывая сознательных усилий.
ПРИМЕЧАНИЕ
Несмотря на то что на рис. 3.1 представлен прямой путь от одного уровня к другому, в реальности все более беспорядочно. Команды могут достигать уверенного владения навыками на любом уровне, в любом порядке, хотя продвижение, показанное на рис. 3.1, типично.
Навыки, необходимые для свободного применения, перечислены в предисловиях к частям II–IV. Но уверенное владение навыками не достигается само по себе. Ваша организация тоже должна инвестировать в эти навыки своих команд. Это гораздо больше, чем поддерживать идеи Agile на словах. Организация должна произвести реальные, значительные изменения, которые занимают время, стоят денег и требуют вложения политического капитала.
Результат, который вы получаете от команд, зависит от того, насколько ваша организация вкладывается в идеи Agile. Компании не удается добиться результатов, которых она хочет от Agile, обычно потому, что она не сделала необходимые инвестиции. Часто организации даже не осознают, что это было нужно.