Гибкая методология разработки

Текст Манифеста гибкой разработки утверждает^[2]:

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

• Люди и взаимодействие важнее процессов и инструментов.
• Работоспособное программное обеспечение важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Реагирование на изменения важнее следования первоначальному плану.

Это означает, что, несмотря на ценность элементов справа, мы больше ценим элементы слева.

Скотт Амблер пояснил^[18]:

• Инструменты и процессы важны, но главное — компетентные люди, работающие вместе.
• Хорошая документация помогает понять, как устроено ПО, но главное — создавать и поддерживать работающее ПО.
• Контракт важен, но не подменяет постоянное взаимодействие с заказчиком в поиске его настоящих потребностей.
• Планирование важно, но не должно мешать адаптации к изменяющимся условиям и пониманию задачи.

Представляя Манифест от имени Agile Alliance, Джим Хайсмит отметил:

Ценности Манифеста раскрываются в 12 принципах^[20]:

1. Удовлетворение заказчика через ранние и регулярные поставки ценного ПО.
2. Приветствие изменений требований даже на поздних этапах.
3. Частые поставки работоспособного ПО (недели, а не месяцы).
4. Тесное ежедневное взаимодействие заказчика и разработчиков.
5. Команды строятся вокруг мотивированных людей, которым доверяют.
6. Личные коммуникации — лучший способ обмена информацией.
7. Работоспособное ПО — первичная мера прогресса.
8. Устойчивое развитие: постоянный ритм.
9. Постоянное внимание к высокой технической культуре и дизайну.
10. Простота — искусство делать только наиболее необходимое.
11. Лучшая архитектура, требования и дизайн рождаются в самоорганизующихся командах.
12. Регулярная рефлексия с целью саморазвития команды.

Большинство agile-методов разбивают работу на малые инкременты с минимальным предварительным планированием. Итерации («спринты») длятся обычно от одной до четырёх недель. Каждая итерация охватывает все этапы — от планирования и анализа до программирования, тестирования и демонстрации заказчикам, что минимизирует риски и облегчает адаптацию к изменениям^[21].

Главное преимущество agile — быстрая обратная связь и вывод продукта на рынок малыми партиями, что снижает время и риски непопадания в запросы пользователя.

6-й принцип Манифеста: «Самый эффективный способ обмена информацией в команде — личное общение». Хотя Манифест был написан, когда видеоконференций почти не было, акцент — именно на качестве коммуникаций.

Размещение сотрудников в одном помещении (co-location) облегчает формирование команды и рабочие коммуникации^[22]. Однако современные исследования отмечают, что удалёнка делает этот принцип менее критичным.

В любой команде должен быть представитель заказчика (product owner), который доступен для вопросов и переоценивает приоритеты по итогам каждой итерации, чтобы повысить отдачу от инвестиций^[23].

Информационный радиатор — большой стенд или доска рядом с командой, на котором отображён текущий статус разработки, чтобы любой мог видеть общий ход проекта^[24]. Также используется световая индикация сборок.

Стандартная agile-практика — ежедневные стендапы (stand-up meetings или scrum meetings), где команда 15 минут обсуждает прогресс и выявляет препятствия^[25].

Такие инструменты, как непрерывная интеграция, автоматические модульные тесты, парное программирование, разработка через тестирование, рефакторинг кода, помогают встроить качество «с самого начала», чтобы ПО всегда было доступно к показу клиенту в конце каждого спринта^[26].

Методы разработки делят на адаптивные (гибкие) и предсказуемые (плановые)^[28]. Agile относится к адаптивным; ключевой принцип — «волнообразное планирование»: фиксируются вехи, а путь до них и даже сами вехи могут пересматриваться^[29].

• Адаптивные команды готовы менять направление даже в процессе спринта, не дают точных обещаний на много месяцев вперёд.
• Плановые (waterfall) методы подробно анализируют и фиксируют будущее, изменения усложняются и требуют согласования.

Схожее разграничение по параметрам:

Главное отличие: в waterfall тестирование выведено в отдельную фазу после завершения кода; в agile тестирование идёт в том же спринте, что ускоряет обратную связь и быстрее даёт пользователю ценность (аналог цикла PDCA).

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

Скептики (например, Стивен Ракин) критиковали agile за якобы «отрицание документации» и подрыв инженерной дисциплины^[30]. Сторонники возражают: документация пишется в ровно той мере, в какой это повышает ценность, чрезмерная же документация либо устаревает, либо мешает развитию^[31].

Несколько ярких agile-практик^[32]:

Понятие адаптации методов (method tailoring) означает гибкую настройку процесса для конкретного проекта через изменение методик и практик в зависимости от ситуации^[33]. Гибкие методы поощряют адаптацию процессных практик под нужды продукта^[34].

Для этого используются как универсальные языки моделирования (например, UML), так и специализированные фреймворки вроде Essence (SEMAT).

Гибкие методы начинали в небольших экспертных командах и зелёных проектах, а попытки внедрять их в крупные организации с устаревшими системами часто сталкивались с трудностями^[35].

Для распределённых (distributed agile) и офшорных команд были развиты особые подходы, но эффективность и соответствие agile до сих пор обсуждаются^[36].

В регулируемых отраслях (медицина, финансы, авиация) agile внедряется со специальными доработками, учитывающими стандарты ISO и дополнительную отчётность для соответствия требованиям безопасности и проверки^[37].

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

Существуют различные метрики: индекс гибкости (Agility measurement index), который оценивает продукт по пяти осям (длительность, риск, новизна, усилия, взаимодействие). Метрики включают измерение скорости (velocity), внутренние agile-тесты команд (Nokia, Karlskrona, тест 42 пункта)^[39].

По ежегодному исследованию State of Agile (с 2006 года) большинство респондентов отмечают рост производительности, скорости вывода продуктов и управляемости изменений^[40].

• Отсутствие дизайна всей архитектуры ведёт к переусложнению и трудной масштабируемости при быстрых успехах в начале^[41].
• Добавление новых требований в середине спринта нарушает ритм, их следует выносить в будущие спринты^[42].
• Недостаточная поддержка инициаторов проекта (спонсоров) снижает шанс на успех внедрения^[43].
• Отсутствие должной подготовки персонала приводит к неправильному внедрению^[44].
• Роль product owner формально заполняется кем-то из разработчиков, что приводит к конфликту интересов и потере ориентации на бизнес-задачи^[45].
• Работа на несколько продуктов параллельно — снижает производительность.
• Чрезмерное планирование, попытки в начале выяснить и описать всё досконально — против идеи итеративного узнавания истинных требований.
• Злоупотребление стендапами для решения подробных проблем — минус для эффективности.
• Назначение задач извне, а не самими участниками команды, ограничивает самостоятельность роста.
• Scrum-мастер берёт на себя задачи разработчика, что снижает способность устранять препятствия^[46].
• Отсутствие автоматизации тестирования не позволяет поддерживать высокое качество на длительном горизонте.
• Рост технического долга (technical debt) из-за стремления быстро выводить новые фичи.
• Чрезмерная загрузка (слишком много задач на итерацию), что увеличивает потери на переключение контекста.
• Неудачные попытки зафиксировать одновременно время, ресурсы, объём и качество — приводит к ущербу для качества^[47].
• Риск выгорания команды из-за интенсивного ритма^[48].