CC BY
59Agile-подход к разработке программных продуктов: истоки и перспективы
CS CS
о
CS
о ш m
X
<
m О X X
Лобасев Дмитрий Владимирович
эксперт в разработке программных продуктов, профессиональный Agile-коуч, управляющий партнер компании OnAgile Consulting
На сегодняшний день Agile-подход де-факто является стандартом по организации процессов в индустрии разработки программных продуктов. Появившись еще в 2001 году, Agile-под-ход решает задачу быстрой поставки решений в условиях непрерывно меняющихся требований бизнес-заказчиков (или клиентов). В данной работе подробно рассмотрена проблематика создания комплексных программных решений, а также эволюция моделей процессов разработки ПО, вызванная необходимостью поиска наиболее эффективного процесса и способа организации проектной работы в сфере разработки программных продуктов.
Ключевые слова: программные продукты, Agile-подход, IT-технологии, разработка ПО, проектный подход
Что такое Agile?
Agile переводится с английского как «гибкий» или «подвижный». Термин применяют в двух значениях:
1 - Система ценностей, которую используют многие IT-компании. Вот ее главные принципы, закрепленные в «Манифесте Agile»:
• Люди и их взаимодействия важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий договора.
• Реагирование на изменения важнее следования первоначальному плану.
2 - Совокупность методов управления командой и проектами, которые базируются на принципах гибкости и прозрачности.
На сегодняшний день гибкость является одним из основных свойств подхода к разработке программных продуктов, который зародился в самом начале XXI века как ответ на главную проблему разработки программного обеспечения — постоянные изменения требований по ходу проекта и, как следствие, срыв сроков, плохое качество финального продукта и выход за согласованный бюджет проекта.
Проектным командам были необходимы методики, которые бы позволили разработчикам оперативно реагировать на возрастающие потребности заказчиков от бизнеса, осуществлять разработку программных продуктов без срыва заявленных сроков и непрерывного увеличения штата аналитиков, разработчиков и тести-ровщиков.
Также важно было найти наиболее эффективный способ выстроить взаимодействие с заказчиками в период разработки, не просто показывая и отдавая получившийся программный продукт в самом финале, а путем непосредственного вовлечения представителей заказчика на каждом этапе создания продукта, чтобы своевременно получать от них обратную связь и сразу вносить необходимые изменения в будущих продукт.
Если посмотреть в самую суть подхода, то Agile как метод гибкой разработки нацелен на быстрое достижение наилучшего результата при создании нового продукта и оптимального распоряжения ресурсами (временными, трудовыми и, в конечном счете, финансовыми) в условиях окружающей неопределенности.
Датой рождения Agile-подхода можно считать февраль 2001 года, когда был сформулирован и подписан Манифест гибкой разработки, который объединяет основные ценности и принципы, позволяющие создавать работающий программный продукт в ситуации постоянно изменяющихся требований и приоритетов. Наибольший вклад в развитие и пропаганду Agile-под-хода в мире внесли его авторы и первые евангелисты: Кент Бек, Мартин Фаулер, Джеф Сазерленд, Кен Швай-
бер, Алистер Коберн, Майк Кон, Хенрик Книберг и другие, чуть менее известные в нашей стране эксперты в области процессов разработки программных продуктов.
Так, в частности, Кент Бек известен своим подходом Extreme Programming (XP) [1], в котором основное внимание уделено инженерным практикам совместной работы с кодом и автоматизации тестирования и поставок. XP появился в 1999 году, однако большинство его практик используется сейчас ведущими технологическими компаниями мира.
Джеф Сазерленд и Кен Швайбер являются авторами метода Scrum [2] (1995 год) - ключевого и самого популярного в настоящее время фреймворка, реализующего принципы гибкой разработки.
Стоит также отметить Хенрика Книберга - одного из самых популярных в мире Agile-евангелистов, который привнес огромный вклад в индустрию разработки ПО и процессы его создания. В частности, Хенрик является автором так называемого Spotify-подхода [3] к выстраиванию организационной структуры компании и процессов внутри нее. На основе этого подхода крупнейшая в мире консалтинговая компания McKinsey проводит Agile-трансформацию в компаниях своих клиентов [4], а базовые принципы, сформулированные Хенриком, используются Agile-коучами во всем мире.
В целом, согласно исследованию 15th Annual State Of Agile Report [5], те или иные элементы Agile-подхода применяются в деятельности 86% компаний, занимающихся программной разработкой. То есть, можно сказать, что в настоящее время Agile-подход стал базовой технологией организации эффективного процесса разработки ПО.
Нужно отметить, что за прошедшие двадцать лет принципы Agile-подхода вышли далеко за пределы сферы разработки программного обеспечения и применяются в проектной работе во всех сферах бизнеса. Среди наиболее крупных и известных компаний России, внедряющих технологии Agile-подхода в свою деятельность, можно назвать MTC, Альфа-банк, Тинькофф, Сбер, Яндекс, Mail.ru (VK), Авито, ABBYY, HeadHunter, ГазпромНефть, Сибур, Северсталь. И это далеко не полный список компаний, которые уже много лет адаптируют и применяют у себя принципы, практики и инструменты Agile-подхода. При этом, Agile-подход применяется не только в департаментах разработки, но и в таких подразделениях, как маркетинг, логистика, продажи, HR, юридический и финансовый департамент.
Для того, чтобы в полной мере описать идею принципов и техник Agile-подхода, необходимо вернуться к процессам разработки программных продуктов и рассмотреть, как происходила смена моделей проектной работы. Это позволит увидеть сильные стороны и границы применимости каждой модели, а также сделать прогноз относительно того, какой будет следующий виток развития, post-Agile.
Эволюция моделей разработки ПО
Можно выделить четыре основные модели разработки ПО, которые представляют собой эволюцию повышения эффективности процессов разработки в проектных командах за последние несколько десятилетий.
Модель Управление задачами (task-management)
Наибольшее распространение эта модель получила в период, когда программные продукты были доста-
точно простые и могли разрабатываться одним или несколькими разработчиками. Заказчик говорил, что необходимо сделать, а выделенные на его задачи из ИТ подразделения разработчики реализовывали пожелания в программном коде. Как правило, такие разработчики достаточно долго работали в компании и контексте продукта, хорошо понимали все его особенности и бизнес-задачи. Взаимодействие между заказчиком и исполнителями происходило оперативно: от постановки задачи до ее реализации проходили считанные часы или дни.
Схема 1. Модель Управление задачами (составлено автором)
Недостатки этой модели ярко проявляются при работе над средними и большими программными продуктами, которые наряду с разработчиками требуют привлечение тестировщиков, занимающихся проверкой соответствия продукта ожиданиям заказчика и пользователей, а также аналитиков, которые изучают предметную область, проектируют и описывают функциональность будущего продукта. Привлечение тестировщиков и аналитиков приводит к увеличению задействованных в команде специалистов в среднем в 2 раза. Ни один бизнес-заказчик уже не сможет адекватно управлять такой командой, так как основное рабочее время и силы посвящает своим должностным обязанностям в рамках компании. Поэтому, при реализации большинства программных продуктов в такой среде неизбежно возникает менеджер проекта - отдельный человек, который координирует деятельность всей команды, отвечает за результат поставки и является экспертом по организации эффективного процесса разработки на основе определенного системного подхода или методологии.
К концу 1990-х годов размер и сложность программных продуктов, создаваемых для нужд бизнеса, увеличилась настолько, что модель управления задачами не позволяла с необходимой скоростью и качеством производить разработку. Поэтому стали появляться другие модели, которые позволяли системно подходить к разработке программного обеспечения и организовывать работу больших команд разработчиков.
Каскадная модель разработки (waterfall)
Широкое распространение получила в 1990-х годах, несмотря на то, что сам подход был сформулирована У. У. Ройсом еще в 1970 году [6]. За основу каскадной модели были взяты принципы, на протяжении многих веков
X X
о
го А с.
X
го m
о
м о м м
es es о es
о ш m
X
<
m О X X
применяемые в строительстве, а именно четкая последовательность этапов работы над проектом. Так, для ИТ проектов основными этапами процесса разработки являются: сбор требований к будущему продукту, проектирование архитектуры системы, разработка кода, тестирование продукта, приемка заказчиком и ввод в эксплуатацию. Особенностью модели является ставка на подготовку качественной документации на каждом из этапов работы по проекту (бизнес и функциональные требования, архитектурные модели, тестовые планы и сценарии), которая бы была неизменной по ходу проекта и обеспечивала нужный уровень качества будущего продукта и успех проекта целом.
Итеративно-инкрементальная модель разработки (Agile-подход, Scrum)
В основе этой модели лежит принятие того факта, что требования заказчиков будут непрерывно меняться прямо в процессе разработки нового продукта. Как следствие, основной задачей проектной команды является создание такого процесса работы, который будет приспособлен к частым изменениям требований, но при этом позволяет в прогнозируемые сроки и бюджет создавать и выпускать желаемый программный продукт.
Суть модели заключается в том, что разработка системы происходит не целиком, а небольшими фрагментами (инкрементами продукта), каждый из которых создается в течение одной короткой итерации или «спринта» (обычно, длительностью одна или две недели). При этом в конце каждой из таких итераций новая функциональность продукта демонстрируется заказчику и другим заинтересованным лицам, чтобы сразу получить от них обратную связь, которая позволит команде понять, какие изменения требований нужно вносить в планы уже сейчас.
KcXOjHoji
Итероц»* 1
_^ /\ ИтерлЧид 2
V .........^^ . Итерлцу-í 1
V
Схема 2. Каскадная модель разработки (составлено автором)
На основе постулатов каскадной модели свои методологии программной разработки создавали разные компании. Наибольшее значение для развития отрасли имели такие методологии как Rational Unified Process (RUP) [7] от компании Rational Software и Microsoft Solutions Framework (MSF) [8] от компании Microsoft. Обе методологии претендовали на создание универсальных, хорошо документированных подходов к процессу разработки программного обеспечения, которые могли бы быть использованы большинством команд разработки. Однако основной проблемой их использования была сложность и объемность базовых методик, например, предполагалось выделение в команде разработки несколько десятков функциональных ролей и подготовку такого большого объема проектной документации, который был явно избыточным для большинства реализуемых в тот период проектов.
Несмотря на то, что обе методологии RUP и MSF активно внедрялись в компаниях по всему миру и дорабатывались на протяжении 1990-2000-х годов, можно говорить, что уже к 2011 году они уступили лидирующие позиции принципам и техникам Agile-подходу.
Основной причиной, по которой каскадная модель в разработке ПО не давала желаемой результативности, стали постоянно изменяющиеся по ходу проекта требования заказчиков. Как показала практика, никакой самый тщательный сбор требований на протяжении нескольких месяцев самыми лучшими аналитиками не гарантировали, что со стороны заказчика не будут выдвигаться новые требования, как дополнительные, так и во многих случаях противоречащие первоначальным. Это привело к тому, что и RUP, и MSF начали обрастать дополнительными процедурами управления изменениями (change management), которые в целом только усложняли как саму работу над проектом, так и взаимодействие проектной команды с заказчиком.
Инкремент
Итерлад tí
НуЛННЛ
к/иенток »р «ffj
Схема 3. Итеративно-инкрементальная модель разработки (составлено автором)
Внесение изменений, которые были признаны важными и были согласованы, происходит в течение следующих итераций. Таким образом, основная идея Agile-подхода — это поэтапный сбор требований и поэтапное создание продукта с регулярным получением ценной обратной связи от заказчиков. Небольшая длительность итераций и регулярность обратной связи позволяет разработчикам быть очень гибкими и избегать ситуаций, когда новые требования заказчика предполагают значительные изменения в уже созданном программном продукте.
Распространение Agile-подхода привело также к появлению такого понятия, как «минимально жизнеспособный продукт» (англ. minimum viable product, MVP) [9]. Концепция MVP предполагает проектирование такой первой версии будущего продукта, которая бы имела минимальный набор функционала, который можно разработать очень быстро и отдать первым, самым заинтересованным клиентам и получить от них наиболее ценную для дальнейшего развития продукта обратную связь. Опыт индустрии за последние несколько десятков лет показал, что получение и использование обратной связи от представителей заказчика никогда не бывает настолько эффективным, как опыт использования продукта первыми реальными пользователями и его дальнейшую доработку с учетом их пожеланий.
Впервые инкрементальный подход был описан Хиро-така Такэути и Икудзиро Нонака в статье The New Product Development Game еще в 1986 году [10]. Позднее, основываясь в том числе на этих идеях, был создан фреймворк Scrum - первая версия была сформулиро-
вана и обнародована Кеном Швабером и Джефом Са-зерлендом в 1995 году. Повсеместное применение SCRUM в компаниях, разрабатывающих ПО, началось с середины 2000-х годов, а к 2020-му году этот подход распространился на все сферы бизнеса в качестве метода организации командной работы. Эффективность и широкое внедрение SCRUM связаны с его простотой, он не претендует на исчерпывающее описание этапов и процессов взаимодействия, как это делали RUP и MSF, а задает лишь основные, самые эффективные правила того, как должна организовать свою работу проектная команда.
К наиболее значимым понятиям SCRUM можно отнести: спринт (короткий временной отрезок, за который должен быть реализован определенный объем задач), цель спринта (описание бизнес-цели текущего спринта, которое помогает команде сфокусироваться на важности поставки для бизнеса и клиентов), команда (небольшая, самоуправляемая группа людей, работающих над созданием продукта). Использование SCRUM позволяет создавать небольшие, кросс-функциональные самоорганизующиеся проектные команды, которые могут с высокой скоростью создавать и развивать новые продукты, ориентированы на постоянное улучшение как создаваемого продукта, так и самого процесса разработки команды.
Ежлог f
ТТЛлНироВл н»е Слри-НТл encejHe&HWA стенали РевЬю Спри-НТл Ретроспектива СприНТа
Cupv^rr 1-2 недел»
>
дат
4TSFV
ванности команды, когда команда способна самостоятельно и эффективно планировать свою работу и обеспечивать устойчивый ритм поставки.
Модель потока (Канбан-метод)
Эта модель пришла в программную разработку из производства и в основе своей имеет представление о конвейере, который должен работать оптимальным способом, то есть с минимальным временем простоя, отсутствием брака и такой загрузкой, чтобы выпускать новую функциональность продукта за наименьшее время со стабильно высоким качеством. А поскольку на фазе активной разработки продукта и его использование клиентами потребность в новых функциях постоянна, команда разработки может фокусироваться на реализации каждой отдельной такой функции, отдавать ее пользователям как можно быстрее и переходить к разработке следующей. Отсюда и метафора потока - непрерывной последовательности задач, которые заходят в команду разработки и по одной отдаются клиентам.
Канбан-метод берет свои истоки в концепции бережливого производства (Lean Manufacturing) и бережливой разработке программного обеспечения (Lean Software Development), а наибольший вклад в развитие последней привнесли Мэри и Том Поппендик [11]. Автором непосредственно Канбан-метода является Дэвид Андерсон, который сформулировал и описал метод [12], а так же провел первые успешные его внедрения в 20062008 годах.
ОчередЬ
ГоТоВо
к. рл,зр<х£отке
© В рлботе
Схема 4. SCRUM фреймворк (составлено автором)
Наибольшую известность приобрел такой артефакт SCRUM как доска задач, в своем базовом виде состоящая их трех столбцов «сделать», «в процессе», «сделано». Задачи записываются на стикерах и размещаются в столбцах в соответствии с актуальным статусом.
Ежедневные встречи у доски задач являются обязательной составляющей работы agile-команды, именно они позволяют отслеживать эффективность во время каждого спринта, своевременно выявлять возникающие проблемы и, как следствие, быстро решать их, что, в свою очередь, обеспечивает более быстрое и качественное выполнение поставленных задач.
Вместе с тем, стоит оговориться, что полноценное внедрение SCRUM имеет ряд ограничений. Например, вызывающим затруднение фактором может выступать размер проектной команды. В случаях, когда он превышает 10 человек, будет разумно разделить команду на две и более команды и каждую из них сфокусировать на своих целях и задачах (даже внутри одного продукта). Меньшее количество человек в команде позволяет более быстро добиться хорошего уровня самоорганизо-
А
ЗлдаЧл
3
| ЗлдлЧл
ЗлдлЧл
3
Рисунок 5. Канбан-метод
Одной из основных практик Канбан-метода является визуализация процесса создание ценности, то есть в случае разработки ПО, визуализация этапов производственного цикла, которые проходит каждая задача, например, Очередь, Аналитика, Разработка, Тестирование, Приемка, Готово. При этом цель команды — обеспечить наиболее быстрое перемещение каждой задачи, которая из-за своей важности попала в начало очереди, из левого столбца («Готово к разработке» или «Очередь») в правый («Готово» или «Поставлено»).
Для обеспечения максимальной эффективности работы проектной команды в Канбан-методе используется практика ограничения количества незавершенной работы (work in process limits, WIP лимиты). Каждая команда опытным путем определяет то количество задач, которое может одновременно находиться в работе для обеспечения максимальной производительности. При этом учитываются все задачи, находящиеся на разных стадиях производственного цикла.
X X
о
го А с.
X
го m
о
м о м м
Еще одной важной практикой Канбан-метода является деление входящих задач на классы обслуживания. Канбан-метод по-умолчанию выделяет 4 стандартных класса обслуживания (classes of service):
• стандартный класс,
• класс с фиксированной датой готовности;
• ускоренный класс, то есть неотложная задача;
• нематериальный класс, то есть задача, не несущая прямой бизнес-ценности, но направленная на повышение эффективности работы команды.
Классы сервисов позволяют команде лучше анализировать поток входящих задач и выстраивать правила своей работы относительно ожиданий заказчиков и потребителей, тем самым обеспечивая наиболее эффективный процесс разработки.
Важным достоинством Канбан-метода является отсутствие ограничений на численный состав рабочей группы и его применимость на любом уровне компании (на уровне отдельной команды, отдельного продукта, конкретного подразделения или компании в целом).
Следует также отметить важную концепцию Канбан-метода под названием Upstream Kanban (восходящий канбан), которую можно рассматривать как метафору воронки задач с набором фильтров, предназначенную для запуска в разработку только наиболее ценных для бизнеса и потребителя задач в минимально необходимом объеме (помогая минимизировать расходование дорогих и ценных ресурсов разработчиков на менее важные и менее срочные задачи).
На сегодняшний день Канбан-метод используется во многих компаниях, занимающихся разработкой По и является действенным методом организации и повышения эффективности разработки и вывода на рынок новых продуктов.
Литература
1. Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley, 2000.
2. Sutherland, Jeff; Schwaber, Ken. The official Scrum Guide. https://scrumguides.org/scrum-guide.html, 2020
3. Kniberg, Henrik; Ivarsson, Anders. Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. https://blog.crisp.se/wp-
content/uploads/2012/11/SpotifyScaling.pdf, 2012
4. Schlatmann, Bart. ING's agile transformation. https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation, 2017
5. 15th Annual State Of Agile Report. https://digital.ai/resource-center/analyst-reports/state-of-agile-report, 2021
6. Royce, Winston. Managing the Development of Large Software Systems. http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf, 1970
7. Kruchten, Philippe. Rational Unified Process - An Introduction. Addison-Wesley, 1999.
8. Michael, Turner. Microsoft Solutions Framework Essentials: Building Successful Technology Solutions. Microsoft Press, 2006.
9. Ries, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown, 2011.
10. Takeuchi, Hirotaka; Nonaka, Ikujiro. The New New Product Development Game. Harvard Business Review, 1986.
11. Poppendieck, Mary; Poppendieck, Tom. Lean Software Development: An Agile Toolkit. Addison-Wesley, 2003
12. Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue hole press, 2010.
СЧ СЧ
о
СЧ
О Ш
m
X
<
m о x
X
Перспективы развития подходов к разработке ПО
На текущий момент времени именно техники SCRUM и Канбан-метод обеспечивают максимальную скорость процессов разработки и поставки программных продуктов.
Несмотря на кажущуюся простоту и небольшой набор принципов, по-настоящему заметные результаты внедрения получаются только при системном внедрении каждой из методик целиком, а не просто некоторых из ее фрагментов. Так, например, наиболее частой ошибкой применения Scrum является отсутствие в процессе команды ретроспектив - регулярных встреч команды, направленных на самостоятельный анализ и улучшение процесса разработки.
Если говорить про актуальные тренды развития процессов в разработке ПО в настоящее время, то они направлены на развитие самоорганизации крупных команд, работающих над одним продуктом (до 150 человек, на основе фреймворков масштабирования SAFe и LeSS), максимальную автоматизацию обеспечивающих процессов (DevOps) и применение Agile-принципов на уровне всей организации (управление портфелем проектов, гибкое бюджетирование и целеполагание).
В целом, все текущие наработки в рамках улучшения процессов разработки продолжают появляться в контексте Agile-подхода, поэтому в ближайшем будущем Agile-подход не только останется основой построения эффективных процессов и культуры организаций, занимающихся разработкой программных продуктов, но и, безусловно, будет пополняться новыми методиками и инструментами.
The Agile Approach to Software Development: Origins and Perspectives Lobasev D.V.
OnAgile Consulting
JEL classification: C10, C50, C60, C61, C80, C87, C90_
Nowadays Agile approach is the de-facto standard for process organization in the software development industry. Introduced back in 2001, Agile approach solves the problem of fast and frequent delivery in the face of continuously changing requirements by business customers (or clients). This paper describes in detail the challenges of creating complex software solutions, as well as the evolution of software development process models, driven by the necessity to discover the most effective method and process to organize software development project work. Keywords: software products, Agile approach, IT technologies, software
development, project approach References
1. Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-
Wesley, 2000.
2. Sutherland, Jeff; Schwaber, Ken. The official Scrum Guide. https://scrumguides.org/scrum-guide.html, 2020
3. Kniberg, Henrik; Ivarsson, Anders. Scaling Agile @ Spotify with Tribes,
Squads, Chapters & Guilds. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf, 2012 4 Schlatmann, Bart. ING's agile transformation. https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation, 2017
5. 15th Annual State Of Agile Report. https://digital.ai/resource-center/analyst-reports/state-of-agile-report, 2021
6. Royce, Winston. Managing the Development of Large Software Systems.
http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf, 1970
7. Kruchten, Philippe. Rational Unified Process - An Introduction. Addison-
Wesley, 1999.
8. Michael, Turner. Microsoft Solutions Framework Essentials: Building
Successful Technology Solutions. Microsoft Press, 2006.
9. Ries, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous
Innovation to Create Radially Successful Businesses. Crown, 2011.
10. Takeuchi, Hirotaka; Nonaka, Ikujiro. The New New Product Development Game. Harvard Business Review, 1986.
11. Poppendieck, Mary; Poppendieck, Tom. Lean Software Development: An Agile Toolkit. Addison-Wesley, 2003
12 Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue hole press, 2010.
