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

Шрифт
Интервал

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

Другие практики, описанные в частях II–IV, также могут оказаться полезными. Agile-практики объединены множеством зависимостей друг от друга, поэтому обязательно обратите внимание на блоки «См. также» и подраздел «Предварительные требования» каждой практики.

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

Глава 3. Выберите свою гибкость

Нет смысла использовать Agile ради него самого. Задайте себе два вопроса.

1. Поможет ли нам Agile стать более успешными?

2. Чего нам будет стоить достижение этого успеха?

Ответив на эти вопросы, вы поймете, нужен ли вам Agile.

Что ценно для организаций?

Успех определяется не только доходами. Вот только несколько составляющих успеха:

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

• достижение целей организации – стратегические цели, оригинальные исследования, благотворительные цели;

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

• обретение популярности – стратегическая информация, аналитика, отзывы клиентов;

• снижение риска – безопасность, требования законодательства, аудит;

• увеличение потенциала – наем и удержание персонала, моральный климат и развитие навыков, автоматизация.

Модель Agile Fluency

В 2014 году я сотрудничал с Дианой Ларсен, чтобы проанализировать, почему компании видят разные результаты от их Agile-команд. Мы оба работали с командами с самого начала. С годами мы заметили, что команды начинали склоняться к кардинально разным типам результатов и эти результаты имели тенденцию группироваться в разных «зонах».

Мы обобщили эти наблюдения в модели Agile Fluency™. Ее упрощенный вариант показан на рис. 3.1 [Shore2018b].

Следующая страница