Гибкая разработка¶

До наступления XXI века разработка программного обеспечения, как правило, основывалась на "водопадной модели" — линейном процессе, состоящем из последовательных этапов, похожем на строительство моста: месяцы или даже годы уходили на детальный анализ требований и проектирование, затем следовали длительные этапы разработки и тестирования, и в конце клиенту передавался "идеальный" готовый продукт. Однако в эпоху интернета, когда требования быстро меняются, а рынок полон неопределённости, недостатки этой модели становились всё более очевидными: она была медленной, сопряжённой с большими рисками, и часто приводила к тому, что финальный продукт уже не соответствовал реальным потребностям пользователей. Именно для решения этой проблемы и возникло новое течение — гибкая разработка.

Гибкая методология — это не конкретный метод или процесс, а набор ценностей и принципов, направленных на принятие изменений, повышение ценности для заказчика и эффективное сотрудничество. Она берёт своё начало в "Манифесте гибкой разработки программного обеспечения", опубликованном в 2001 году. Её основная идея заключается в том, чтобы отказаться от стремления к "идеальным планам" и вместо этого постоянно и быстро предоставлять работающее программное обеспечение посредством краткосрочных, итеративных и инкрементальных процессов разработки, постоянно собирая обратную связь и внося корректировки. Она разбивает большой и непредсказуемый "проект" на ряд коротких и управляемых "спринтов", сохраняя гибкость и адаптивность разработки в условиях изменяющегося рынка.

Манифест гибкой разработки программного обеспечения¶

Суть Agile воплощена в четырёх кратких ценностях и двенадцати поддерживающих принципах.

Четыре основные ценности:

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

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

То есть, хотя элементы справа имеют свою ценность, мы придаём большее значение элементам слева.

Эти четыре ценности глубоко отражают суть гибкого подхода: ориентация на человека, ценность результата, сотрудничество и адаптивность.

Итерационный цикл гибкой разработки¶

graph TD
    subgraph Agile Development Iterative and Incremental Cycle
        A(<b>Product Backlog</b><br/>A prioritized list of<br/>all requirements) --> B(<b>Sprint Planning Meeting</b><br/>Team selects tasks to complete<br/>from top of Backlog for this iteration);
        B --> C(<b>Sprint / Iteration</b><br/>A fixed-time, 1-4 week<br/>development cycle);
        subgraph Sprint / Iteration (1-4 weeks)
            direction LR
            C1(Daily Stand-up<br/>Daily Scrum) --> C2(Development, Testing, Integration);
        end
        C --> C1 & C2;
        C2 --> D(<b>Potentially Shippable Product Increment</b>);
        D --> E(<b>Sprint Review Meeting</b><<br/>Demonstrate results to stakeholders<br/>and gather feedback);
        E --> F(<b>Sprint Retrospective Meeting</b><br/>Team reflects and improves<br/>its own workflow);
        F --> A;
    end

Двенадцать принципов Agile¶

Эти двенадцать принципов представляют собой конкретные рекомендации по реализации ценностей Agile:

Наивысшим приоритетом для нас является удовлетворение потребностей заказчика посредством ранней и постоянной поставки ценного программного обеспечения.
Принимайте изменения в требованиях, даже если они появляются на поздних этапах разработки. Гибкие процессы используют изменения в интересах конкурентоспособности заказчика.
Регулярно предоставляйте работающее программное обеспечение, с интервалами от нескольких недель до нескольких месяцев, предпочтительно более короткие сроки.
Представители бизнеса и разработчики должны работать вместе ежедневно на протяжении всего проекта.
Строить проекты нужно вокруг мотивированных людей. Предоставьте им необходимую среду и поддержку, и доверяйте, что они выполнят работу.
Самый эффективный и результативный способ передачи информации разработчикам и внутри команды — это прямой личный контакт.
Работающее программное обеспечение — главный критерий прогресса.
Гибкие процессы способствуют устойчивой разработке. Спонсоры, разработчики и пользователи должны иметь возможность неограниченно поддерживать постоянный темп.
Постоянное внимание техническому совершенству и качеству проектирования повышает гибкость.
Простота — искусство максимизации объёма невыполненной работы — крайне важна.
Лучшие архитектура, требования и дизайн рождаются в самоорганизующихся командах.
Команда регулярно размышляет над тем, как стать более эффективной, и соответственно корректирует своё поведение.

Распространённые методологии Agile¶

Agile — это набор философий, а не конкретный процесс. На основе гибких принципов было разработано множество конкретных и применимых методологий разработки, среди которых наиболее известны:

Scrum: В настоящее время самая популярная и широко применяемая гибкая методология. Она предоставляет ясную итеративную структуру сотрудничества для команд, определяя ряд ролей (например, Владелец Продукта, Скрам-мастер), событий (например, Планирование Спринта, Ежедневный Скрам) и артефактов (например, Продуктовый бэклог).
Kanban: Гибкий метод, сосредоточенный на визуализации рабочих процессов и оптимизации непрерывной поставки. Он делает упор на ограничении объёма работ в процессе (WIP) и обработке задач по принципу "pull", стремясь к максимальной эффективности потока ценности.
Extreme Programming (XP): Гибкая методология, сосредоточенная на высококачественных инженерных практиках. Она поддерживает ряд конкретных практик, таких как Разработка через тестирование (TDD), Парное программирование, Непрерывная интеграция и другие, чтобы гарантировать высокое качество и устойчивость программного обеспечения.

Примеры применения¶

Пример 1: Разработка функций для интернет-магазина

Традиционная водопадная модель: Тратится 3 месяца на детальный анализ требований, создаётся идеальный проект со всеми функциями, включая "персонализированные рекомендации", "онлайн-продажи" и "виртуальную примерку". Затем следует 6 месяцев разработки, и только после этого выясняется, что на самом деле пользователям больше всего нужна была упрощённая процедура оплаты.
Гибкая модель:
- Спринт 1 (2 недели): Команда сосредотачивается на одном — оптимизации процесса оплаты. Через две недели выпускается новая версия с оплатой, которая работает на 50% быстрее.
- Спринт 2 (2 недели): На основе обратной связи пользователей следующим приоритетом становится "поиск товаров". Команда тратит две недели на разработку и запуск более умной функции поиска.
- ...И так далее: На каждой итерации команда предоставляет пользователям работающий инкремент программного обеспечения с реальной ценностью и корректирует дальнейшее направление разработки на основе обратной связи рынка.

Пример 2: Модель "Squad" в Spotify

Ситуация: Spotify, крупнейший в мире сервис потокового вещания музыки, является отличным примером гибкой организационной культуры.
Применение: Они разделяют всю команду разработки на множество небольших, высококвалифицированных, межфункциональных и самоорганизующихся групп "Squads". Каждая группа действует как мини-стартап, имея полную автономию в определённой области (например, "поиск" или "пользовательские плейлисты"). Эта модель значительно повысила эффективность разработки, способность к инновациям и чувство ответственности сотрудников.

Пример 3: Команда стартапа в сфере аппаратных решений

Ситуация: Команда хочет разработать новые умные часы.
Применение: Они не начали с проектирования и производства финального продукта. Вместо этого они применили гибкий подход, сначала использовав готовые комплектующие для быстрого создания минимального аппаратного MVP (минимально жизнеспособного продукта), который мог проверить основные потребности, и сразу же передали его тестовым пользователям. Наблюдая за реальной обратной связью, они постоянно совершенствовали дизайн аппаратной части и функции программного обеспечения, избегая значительных потерь на дорогостоящих формах и производстве из-за ошибочных решений на ранних этапах.

Преимущества и вызовы Agile¶

Ключевые преимущества

Более высокая адаптивность и гибкость: Возможность спокойно принимать изменения в требованиях и оперативно реагировать на рынок.
Ранняя и непрерывная поставка ценности: Заказчики могут использовать основные функции раньше и получать постоянные обновления.
Более высокая удовлетворённость заказчика: Благодаря тесному сотрудничеству с заказчиком обеспечивается создание именно того продукта, который ему нужен.
Меньшие риски: Короткие итерации позволяют избежать вложения слишком многих ресурсов в неправильном направлении, существенно снижая риск провала проекта.
Более высокий моральный дух команды: Самоорганизующиеся команды получают больше автономии и чувства достижения.

Возможные вызовы

Требует глубоких изменений культуры и мышления: Успех Agile — это не просто изменение процесса, это переход от "командования и контроля" к "доверию и самостоятельности" со стороны менеджеров и членов команды.
Высокие требования к личностным качествам: Участники гибких команд должны обладать сильными коммуникативными навыками, склонностью к сотрудничеству и межфункциональными знаниями.
Недостаток документации: Неправильное понимание Agile может привести к отсутствию необходимой документации, что вызовет трудности при последующем сопровождении и передаче проекта.
Сложности долгосрочного планирования: Из-за своей природы, ориентированной на изменения, Agile затрудняет предоставление точных долгосрочных обязательств по срокам и стоимости на начальном этапе проекта.

Расширения и связи¶

Lean Startup: Тесно связан с гибким подходом, цикл "построй-измерь-обучись" Lean Startup можно рассматривать как применение Agile на уровне валидации бизнес-модели.
DevOps: Это расширение гибкого подхода в областях разработки программного обеспечения (Dev) и операционного обслуживания (Ops). Оно направлено на преодоление барьеров между разработкой и эксплуатацией посредством изменений в культуре, практиках и инструментах, обеспечивая более быструю и надёжную доставку и развертывание программного обеспечения.

Справка: "Манифест гибкой разработки программного обеспечения" является общей основой и руководящим документом для всех гибких практик. Подписавшие его лица, такие как Кент Бек, Мартин Фаулер и Джефф Сазерленд, являются одними из самых авторитетных специалистов и мыслителей в области Agile.