-Agile — это не просто «способ быстро разрабатывать»-
Термин «Agile» часто используется в среде разработки программного обеспечения.
Однако если понимать Agile лишь как
«быструю разработку»
«проведение спринтов в двухнедельных циклах»
«проведение ежедневного утреннего собрания»
легко упустить суть Agile.
Agile возник благодаря Манифесту гибкой разработки программного обеспечения, опубликованному в 2001 году.
Манифест Agile выделяет следующие четыре ценности.
-
Люди и взаимодействие важнее процессов и инструментов
-
Работающее программное обеспечение важнее исчерпывающей документации
-
Сотрудничество с заказчиком важнее согласования условий контракта
-
Готовность к изменениям важнее следования плану
Процессы, документация, контракты и планы также необходимы, но Agile придаёт большее значение людям и коммуникации, работающим результатам, сотрудничеству с заказчиками и реагированию на изменения.
12 принципов Agile
Помимо четырёх ценностей, Манифест Agile включает 12 принципов их практического применения.
1. Уделяйте первостепенное внимание удовлетворённости заказчика
Высший приоритет — удовлетворять заказчиков, как можно быстрее и непрерывно поставляя ценное программное обеспечение.
2. Приветствуйте изменения требований
Принимайте изменения требований даже на поздних этапах разработки.
Вместо того чтобы безоговорочно рассматривать изменения как препятствие для проекта, воспринимайте их как возможность обеспечить заказчикам конкурентное преимущество.
3. Регулярно поставляйте работающее программное обеспечение
Предоставляйте фактически работающие результаты короткими циклами, а не разрабатывайте продукт несколько месяцев, представляя всё сразу.
4. Представители бизнеса и разработчики должны работать вместе
Планировщики, представители бизнеса и разработчики должны непрерывно сотрудничать на протяжении всего проекта, а не встречаться только в его начале.
5. Создавайте проекты вокруг мотивированных людей
Обеспечьте участникам команды необходимые среду и поддержку и доверьте им самостоятельное выполнение работы.
6. Наиболее эффективный способ коммуникации — личный разговор
Вместо того чтобы обмениваться только документами или электронными письмами, при необходимости общайтесь напрямую, чтобы быстро решать проблемы.
7. Работающее программное обеспечение — важнейший показатель прогресса
Вместо того чтобы оценивать объём написанной документации, сосредоточьтесь на том, какой объём функциональности действительно удалось реализовать.
8. Поддерживайте устойчивый темп разработки
Придерживайтесь темпа разработки, который можно поддерживать в долгосрочной перспективе, вместо того чтобы многократно работать допоздна и брать сверхурочную работу в отдельные периоды для повышения скорости.
9. Непрерывно стремитесь к техническому совершенству и качественному дизайну
Недостаточно просто быстро реализовывать функциональность.
Необходимо непрерывно улучшать качество кода и дизайна, а также техническое качество продукта.
10. Стремитесь к простоте
Сводите к минимуму работу, которую не требуется выполнять.
Иными словами, задавайтесь вопросом не только «Что нам следует делать?», но и «Чего нам не следует делать?».
11. Лучшие архитектуры, требования и дизайны формируются самоорганизующимися командами
Вместо того чтобы менеджеры единолично принимали каждое решение, команда, выполняющая непосредственную работу, решает проблемы и участвует в принятии решений.
12. Регулярно анализируйте результаты и совершенствуйтесь
Вместо того чтобы анализировать проблемы только после завершения проекта, мы регулярно проверяем и совершенствуем методы работы команды.
Это важный принцип, связанный с ретроспективойв Agile.
Возможно ли тогда применять Agile и в SI-проектах?
Здесь есть одна практическая проблема.
Среда SI-проекта значительно отличается от среды типичного стартапа или проекта по разработке продукта.
Например, в SI-проектах часто встречаются следующие ситуации.
-
Срок действия контракта и дата его окончания фиксированы.
-
Имеется отдельная компания-клиент.
-
Объём разработки определён в предложении и контракте.
-
Предусмотрены такие этапы, как анализ, проектирование, разработка и тестирование.
-
Необходимо предоставить большое количество результатов работ.
-
Изменения требований клиента могут потребовать дополнительных затрат или привести к изменению графика.
-
В одном проекте участвуют несколько компаний-партнёров.
Поэтому просто применить Agile к SI-проекту, полностью отказавшись от существующей системы управления проектом и заявив: «С сегодняшнего дня мы будем использовать Scrum»— нереалистично.
Напротив, в SI-проектах практичнее внедрить философию Agile и некоторые его практики в существующий подход к управлению проектом.
Методы Agile, подходящие для SI-проектов
① Scrum
Наиболее распространённым методом является Scrum.
Scrum основан на эмпиризме. Вместо того чтобы сразу идеально спланировать сложные задачи, он предполагает проверку фактических результатов, их анализ и корректировку следующих действий на основе этих результатов.
Эмпиризм Scrum можно объяснить с помощью трёх основных понятий.
Прозрачность → проверка → адаптация
Иными словами,
сделать выполняемую работу видимой
→ проверить фактические результаты
→ пересмотреть план и методы на основе результатов.
Такова структура.
Как применить её к SI-проекту?
Предположим, что проект рассчитан на шесть месяцев.
При традиционном подходе:
Анализ требований
↓
Общее проектирование
↓
Общая разработка
↓
Интеграционное тестирование
↓
Приёмочное тестирование пользователями
↓
Ввод в эксплуатацию
Этот подход можно использовать для продолжения работы.
В этом случае может пройти довольно много времени, прежде чем вы сможете проверить, подходят ли требования, определённые в начале разработки, реальным пользователям.
Если вы применяете часть методологии Scrum, разделите её на более мелкие единицы.
Например, две недели как один спринт.
Спринт 1
Регистрация + вход
Спринт 2
Просмотр и редактирование информации об участнике
Спринт 3
Просмотр товаров
Спринт 4
Оформление заказа
Спринт 5
Оплата
Разрабатывайте таким образом и показывайте заказчику или представителю бизнеса работающий результат каждый раз по завершении спринта.
Тогда заказчик может сказать:
«Это немного отличается от того, что я представлял себе».
Он может сказать это.
Внесите изменения на этом этапе.
Изменения можно внести с гораздо меньшими затратами, чем если бы проблема была обнаружена во второй половине проекта.
② Применение эмпиризма в SI-проектах
Лично я считаю, что одной из наиболее важных концепций Agile в SI-проектах является эмпиризм.
Проще говоря, эмпиризм означает
не полагаться только на планы или предположения, а принимать решения на основе фактического опыта и наблюдений
.
Scrum также использует подход, при котором вы наблюдаете фактические результаты и на их основе решаете, что делать дальше, поскольку при работе со сложными задачами трудно заранее идеально всё предсказать.
Например, предположим, что заказчик сделал следующий запрос:
«Пожалуйста, создайте экран оформления заказа, которым пользователи смогут легко пользоваться».
Если разработчики работают только с документацией, каждый из них может по-своему интерпретировать слово «легко».
Однако после создания реального экрана и его демонстрации пользователям ситуация меняется.
Пользователи могут самостоятельно опробовать его и сказать, например:
«Эту кнопку трудно заметить».
«Не думаю, что этот шаг действительно необходим».
«На мобильном устройстве удобнее пользоваться им именно так».
Они могут сказать это.
Именно это и есть опыт → наблюдение → обратная связь → улучшение.
Применение эмпиризма в SI-проекте в конечном итоге означает
не утверждать требования, основываясь исключительно на документации, а как можно скорее создать фактический результат и проверить его
.
③ Использование парной работы
Ещё один метод, который можно использовать в Agile-разработке, — это парное программирование.
Это метод, при котором два разработчика совместно работают над одной задачей.
Один человек пишет код, а другой в реальном времени проверяет его, что позволяет им совместно разрабатывать решение.
Разумеется, не каждую задачу разработки в SI-проекте необходимо выполнять в парах.
Фактически с точки зрения численности команды и затрат это может быть неэффективно.
Поэтому избирательное применение этого подхода к важным или высокорисковым задачамявляется практичным подходом.
Например, к таким задачам относятся:
-
Основная бизнес-логика
-
Платёжные модули
-
Функции, связанные с безопасностью
-
Сложные SQL-запросы
-
Крупномасштабные преобразования данных
-
Общие фреймворки
-
Функции с высокой вероятностью сбоя
-
Разработка ключевых функций разработчиками с небольшим опытом
Например, вместо традиционного подхода, при котором разработчик A разрабатывает платёжный модуль, а разработчик B позже проверяет код,
A + B с самого начала проектируют и разрабатывают его вместе— именно такой подход следует применять.
Это может снизить концентрацию знаний у одного разработчика.
④ Делайте ежедневные собрания короткими
При применении Agile в SI-проекте проще всего начать с Daily Scrum.
Однако здесь следует обратить внимание на один момент.
Ежедневное собрание не должно превращаться во время, когда руководитель команды принимает отчёты о выполненной работе.
Хорошее ежедневное собрание — это не
«Что вы делали вчера?»
«Что вы будете делать сегодня?»
собрание, которое лишь повторяет эти вопросы.
Главное — проверять, продвигается ли команда к цели Спринта, и при необходимости корректировать план.
Например, вместо того чтобы разработчик сообщал:
«API готов примерно на 80 %.»
гораздо полезнее сообщить следующее:
«Экраны A и B готовы, но в API C возникла проблема интеграции с внешней системой. Если эту проблему не решить, будет сложно завершить разработку функций оплаты в рамках этого Спринта.»
.
Иными словами, ежедневное собрание должно быть местом для раннего выявления проблем, а не сессией отчётности.
⑤ Проводите Sprint Review с заказчиком
Это особенно важно в SI-проектах.
В конце Спринта вместо того, чтобы проверять результаты только внутри команды разработки, по возможности покажите заказчику или заинтересованным лицам со стороны бизнеса реально работающую систему.
Например, вместо того чтобы сообщать в документе:
«Разработка функции управления участниками завершена»,
покажите
в реальной системе:
Зарегистрироваться → Войти → Просмотреть информацию об участнике → Редактировать
Продемонстрируйте это напрямую.
Затем спросите заказчика:
«Когда вы представляете себе использование этого экрана в своей реальной работе, есть ли в нём что-нибудь неудобное?»
Это позволяет быстро выявить расхождения между требованиями и реальной работой.
⑥ Проведение ретроспективы
Ещё один важный аспект Agile — этоРетроспектива.
В конце спринта команда вместе отвечает на следующие вопросы.
Что прошло хорошо?
Что вызвало проблемы?
Что мы изменим в следующем спринте?
Например, в первом спринте
настройка среды разработки заняла три дня.
Затем в следующем спринте
мы можем заранее подготовить шаблон общей среды разработки.
Это можно оформить как пункт улучшения.
Важно, чтобы ретроспектива не превращалась просто в сеанс самоанализа.
Вместо вопроса «Кто виноват?» следует обсудить: «Как мы можем сделать лучше в следующий раз?».
12-й принцип Agile также подчёркивает, что через регулярные промежутки времени команда должна анализировать свою работу и корректировать её, переходя к более эффективным методам.
Как это можно объединить при применении к SI-проекту
В конечном счёте практический способ применения Agile к SI-проекту можно обобщить следующим образом.
|
Метод Agile |
Применение к SI-проекту |
|---|---|
|
Scrum |
Проведение спринтов циклами продолжительностью от двух до трёх недель |
|
Эмпиризм |
Быстрое создание и проверка фактических результатов |
|
Ежедневный Scrum |
Обмен краткими обновлениями о ходе работы и информацией о препятствиях |
|
Обзор спринта |
Демонстрация фактической функциональности заказчикам и представителям бизнеса |
|
Ретроспектива |
Улучшение способов работы после завершения спринта |
|
Парная работа |
Избирательное применение к ключевым задачам и задачам высокой сложности |
|
Бэклог |
Управление требованиями на основе приоритетов |
|
Инкремент |
Обеспечение рабочего результата в каждом спринте |
|
Самоорганизующаяся команда |
Команда разработки самостоятельно решает, как выполнять детальные задачи |
Ключ к Agile SI-проекту — «мышление в духе Agile»
Применение Agile к SI-проекту не обязательно означает, что каждый проект должен управляться с использованием Scrum.
Что важнее всего —применять к проекту принципы Agile.
Например, существуют следующие различия.
Традиционный подход
«Разрабатывайте только после того, как требования будут окончательно согласованы.»
Гибкий подход
«Создайте что-нибудь как можно быстрее и уточняйте требования на основе фактических результатов.»
Традиционный подход
«Если график меняется, значит, проект провален.»
Гибкий подход
«Если происходит изменение, скорректируйте приоритеты и найдите способ создать более ценный результат.»
Традиционный подход
«Важно то, завершил ли разработчик работу.»
Гибкий подход
«Важно то, создана ли функциональность, которой пользователи действительно могут пользоваться.»
Заключение
Agile — это не просто методика управления проектами, предполагающая внедрение Scrum или создание бэклога в Jira.
Её суть можно свести к следующим четырём пунктам.
Быстро создавайте
↓
Проверяйте на практике
↓
Получайте обратную связь от клиентов
↓
Применяйте её в следующем цикле разработки.
Повторяя этот процесс, вы постепенно направляете проект в более эффективное русло.
Особенно в SI-проектах трудно применять все аспекты Agile в неизменном виде из-за различных ограничений, таких как контракты, графики, результаты поставки и требования клиентов.
Поэтому реалистичный подход заключается в том, чтобы сохранять существующую систему управления в SI, одновременно избирательно применяя при необходимости такие практики Agile, как Scrum, эмпирический подход, короткие циклы разработки, обратная связь от клиентов, ретроспективы и парная работа.
В конечном счёте ключевой вопрос Agile заключается не в том,
«Насколько хорошо мы придерживались плана, составленного в начале?»
а в том,
«Насколько быстро мы учились, адаптировались и предоставляли ценность клиентам по мере продвижения проекта?»
.
Luke