Строгая реализация скорых методов разработки

Концепция строгой, упорядоченной скорой разработки (Disciplined Agile Delivery, DAD) задумана как согласованная сквозная стратегия практического применения скорых методов подготовки программных решений. DAD представляет собой agile-подход, на первое место ставящий людей и ориентированный на обучение. Жизненный цикл DAD опирается на снижение рисков и повышение ценности, ориентирован на достижение целей, является масштабируемым и действует в контексте предприятия. Процессный каркас DAD строится на десяти принципах.

1. Люди превыше всего. DAD опирается на стратегию формирования многофункциональных команд, состоящих из специалистов широкого профиля. Участники команды поощряются к приобретению навыков во многих областях и к выполнению работы, относящейся не только к их основной области специализации.

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

3. Agile-принципы. Процессный каркас DAD придерживается ценностей и принципов Agile Manifesto и дополняет их.

4. Гибридность. DAD перенимает и адаптирует проверенные стратегии таких методологий, как Scrum, Extreme Programming, Agile Modeling, Unified Process, Kanban, Agile Data и т. п. Таким образом, DAD представляет собой agile-методологию второго поколения, опирающуюся на все лучшее, что было создано ранее.

5.Ориентация на ИТ-решения. DAD переключает внимание с простой разработки ПО на создание именно решений, представляющих реальную ценность для бизнеса с учетом имеющихся экономических, культурных и технических ограничений. Само по себе ПО, без сомнения, важно, но чтобы выполнить требования заказчиков и предоставить им реально работающее решение, приходится предлагать им новое или модернизированное оборудование, менять бизнес-процессы или операционные процессы и даже помогать в изменении организационной структуры.

6. Ориентация на выпуск. На рис. 1 изображен базовый жизненный цикл DAD-проекта, от стартовой точки до сборки и запуска решения в производство. В отличие от DAD, agile-методы первого поколения обычно фокусировались на этапе сборки, а все остальное оставлялось на откуп разработчикам.

Рис. 1. Базовый жизненный цикл DAD-проекта

7. Ориентация на цели. Одна из сложностей описания процессного каркаса в том, что, с одной стороны, нужно дать достаточный объем информации, чтобы читатели поняли концепцию, а с другой, если переборщить с рекомендациями, может показаться, что концепция диктует слишком много указаний. Избежать этого помогает ориентация на достижение целей, как это проиллюстрировано на рис. 2. Опыт показывает, что ориентированный на цели рекомендательный подход дает командам разработки достаточно указаний, но при этом является вполне гибким, чтобы процесс можно было адаптировать в соответствии с конкретными обстоятельствами.

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

9. Акцент на риски и ценность. Процессный каркас DAD полагается на жизненный цикл, подразумевающий минимизацию рисков и повышение ценности и, по сути, представляющий собой «облегченный» вариант используемого в методологии Unified Process. DAD-команды стараются на ранних стадиях жизненного цикла проекта устранить общие риски, в частности, согласовать с заказчиком общий замысел и архитектуру. DAD также требует целенаправленно проверять жизнеспособность проекта, достаточность разработанного объема функциональности и готовность решения к рабочему применению. Помимо этого, делается акцент на ценность: реализуется стратегия, снижающая риски выпуска, то есть DAD-команды регулярно выпускают потенциально пригодные для применения решения.

10. Масштабируемость. Процессный каркас DAD обеспечивает основу для масштабируемых «скорых» ИТ-проектов и является, в частности, важным элементом стратегии IBM Agility at Scale. Данная стратегия опирается на тезис о том, что масштабируемость означает не просто численность проектной команды, а учитывает еще несколько факторов масштаба: географическое распределение, необходимость обеспечения соответствия нормативным актам, сложность проблемной области, техническую сложность, распределенность, сложность и специализацию организации заказчика. Каждая команда должна адаптировать данную стратегию в соответствии с конкретным положением дел. Например, команда из семи человек, работающих в одном офисе, которая занимается нормативно-регулируемым проектом, будет действовать иначе, по сравнению с командой из 40 человек, распределенных по нескольким офисам и осуществляющих нерегулируемый проект.

Ориентация на цели

Данную характеристику DAD-процесса большинство сторонников agile-подхода, вероятно, сочтут необычной. Ее принцип в том, чтобы определиться с фундаментальными целями, применимыми на конкретном этапе проекта (рис. 2), а затем адаптировать стратегию для достижения этих целей в соответствии с текущим положением дел. Чтобы эффективно следовать этому принципу, нужно понимать суть проблем, характерных для каждой цели, а также подготовиться к компромиссам, на которые придется идти в решении этих проблем. В этом и помогает процессный каркас DAD.

Рис. 2. Цели различных этапов DAD-проекта

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

Ориентация DAD на цели исходит из идеи, что для эффективного применения agile-подхода в организации необходимо учитывать обстоятельства, в которых вы работаете. Особенности адаптации процесса, например, будут зависеть от того, работает ваша команда в одном офисе или в нескольких. Имеет значение и численность команды: команда из пяти человек работает по-иному, чем команда из пятисот. Влияние на адаптацию процесса окажут и соображения нормативного регулирования, а также уровень сложности технологий, с которыми вы работаете. Команде, создающей совершенно новое одноплатформное решение, работать гораздо проще, чем команде, которой приходится иметь дело с несколькими платформами, а также с унаследованным кодом и источниками данных. У разных команд разные обстоятельства, поэтому придется взять на вооружение стратегию, отражающую конкретное положение дел. Методология DAD напомнит вам о вопросах, которые необходимо рассмотреть для принятия решений по адаптации процесса.

Целенаправленное совершенствование процесса

При всех разговорах об эмпирическом подходе, важности обучения и потребности в усовершенствовании процесса разработки ПО, в методологии Scrum за последние 15 лет мало что изменилось. Методология DAD, в свою очередь, не подразумевает, что процесс разработки будет постоянным, — она предполагает обратное. Работа с заказчиками в различных странах мира показала, что они обычно начинают с чего-то простого вроде Scrum, как на рис. 1, но со временем приходят к более действенной стратегии наподобие Kanban.

Рис. 3. Усовершенствованный жизненный цикл DAD

На рис. 3 показан жизненный цикл, к которому со временем приходят опытные agile-команды, осознающие, что темпы проектов, выполняемых с применением различных agile-подходов, не обязательно должны быть одинаковыми. При использовании итерационного подхода, показанного на рис. 1, agile-практики, такие как планирование и моделирование «точно в срок» (Just-In-Time, JIT), демонстрации и ретроспективные обзоры привязаны к одному и тому же итерационному ритму. Но вместо того чтобы планировать в начале итерации, почему бы не делать это тогда, когда вам необходимо? Вместо проведения демонстрации в конце итерации, почему не делать это в нужный вам момент? Вместо тестового развертывания решения в конце итерации, почему бы не делать это, когда вы будете готовы? Начав задаваться подобными вопросами, вы будете отходить от итерационного подхода и склоняться в пользу непрерывного потока разработки. Этот принцип в целом требует более отточенных навыков и более жесткой дисциплины, чем подход, основанный на итерациях/спринтах.

Другое важное отличие между двумя жизненными циклами состоит в принципе приоритизации работ. На рис. 1 элементы работ, в том числе требования, рассматриваются в виде упорядоченного по приоритетам набора, подобного используемому в Scrum (однако DAD предлагает несколько стратегий приоритизации работ, в том числе простую, основанную на ценности стратегию, позаимствованную у Scrum). На рис. 3 элементы работ помещаются в общий пул, в котором они классифицируются по темпам выполнения с помощью различных схем приоритизации, и работа «выдвигается» из этого пула, когда есть возможность ее выполнить. Такая стратегия обеспечивает команде большую гибкость, но и требует более жесткой дисциплины.

Почему DAD?

DAD — золотая середина. Действительно, RUP чересчур требователен, Scrum недостаточно функционален, а DAD — именно то, что надо. Слабое место RUP в том, что у многих команд нет знаний о процессе, чтобы успешно его упростить, в результате чего зачастую выполняется много лишней работы. У многих Srum-команд недостаток знаний о процессе, наоборот, приводит к тому, что они не могут необходимым образом расширить его, из-за чего значительные усилия вкладывются в то, чтобы изобретать заново или осваивать методы решения многочисленных задач, которые Scrum не охватывает. В любом случае можно было бы избежать массы лишней работы, если бы был какой-то вариант между двумя этими крайностями. Таким вариантом и является DAD.

Методология DAD также закладывает основы для масштабируемых agile-проектов и показывает, что требуется для успешного выпуска ИТ-решения на всех этапах, от начала до сборки и запуска в эксплуатацию (или выпуска на рынок). После того как вы разобрались, как выполнять эти этапы на простых примерах, вы можете двигаться дальше и расширять налаженный процесс, чтобы учитывать различные сложности, которые возникнут при увеличении масштаба. Короче говоря, придется научиться ходить, прежде чем начинать бегать.

Скотт Амблер (Scott_Ambler@ca.ibm.com) — главный специалист по ИТ-методологиям IBM Rational, Марк Лайнс (Mark@UPMentors.com) — сооснователь компании UPMentors. 

Первоначальная редакция этой статьи была опубликована в австралийском издании Agile Today, а материалы для нее частично позаимствованы из книги Скотта Эмблера и Марка Лайнса “Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise” (IBM Press, 2012). Мне неоднократно приходилось работать в России, и меня всегда поражала дисциплинированность команд разработчиков ПО в вашей стране. Думаю, они найдут полезной эту статью о методе строгой скорой разработки.

— Скотт