ADD – добавим гибкости

Что такое ADD

Коротко, ADD (английская аббревиатура Artifact Driven Development) – это новая методология организации процесса разработки программного обеспечения. Она основана на парадигме создания артефактов, имеющих ценность для абсолютно всех заинтересованных сторон проекта. Новизна ADD в том, что артефакты так же могут быть абсолютно любыми. Не ограничиваясь версиями программного обеспечения, как, например, в Scrum и Kanban. Не даром неформальная расшифровка аббревиатуры звучит, как Absolutely Ductile Design (абсолютно гибкая конструкция). Методология ADD входит в семейство гибких (Agile) методологий итеративной инкрементальной разработки программного обеспечения. К этому дополнительно отсылает аббревиатура ADD, созвучная английскому глаголу «добавить».

Как возникла ADD

В начале 2020-х окончательно оформились непреодолимые недостатки гибких методологий разработки программного обеспечения, такие как:

• концептуальный разрыв между бизнес-задачами заказчика и требованиями к разрабатываемому программному продукту;

• не системность бэклога продукта, как средства достижения цели;

• невозможность планирования проекта при заранее неизвестном количестве спринтов;

• скрытая потребность в специфицировании требований к продукту при явном ее отрицании;

• тяготение исполнителей к разделению труда в команде разработки;

• отсутствие де-факто самоорганизации команды разработки;

• и другие.

Попытки их преодоления в рамках известных методологий гибкой разработки приводили к отходу от парадигмы Agile. Ситуация усугубилась рядом факторов, таких как:

• неготовность крупных заказчиков отказаться от традиционной каскадной модели разработки в надежде сохранить контроль над проектом;

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

• большое количество провальных ИТ-проектов (более 80% — неудачные, остальные 20% приходится переделывать на 80%);

• бесплодность попыток системных и бизнес-аналитиков найти свое место в новых процессах разработки;

• отсутствие де-факто кросс-функциональности членов большинства команд разработки.

Назрела потребность в новой методологии. В ее основу легли:

• расширенное толкование положений манифеста Agile (вместо программного продукта – полезный артефакт);

• конструктивный подход к разрешению конфликтов (акцентирование внимания заинтересованных сторон на выработке и достижении общих целей);

• признание исполнителя заинтересованной стороной (внутренние интересы разработчиков обычно не принимались во внимание).

Суть методологии ADD

Самоорганизация в процессе создания продукта поднимается на уровень выше и присутствует не только на уровне членов команды разработки, но и на уровне сотрудников заказчика и исполнителя.

Методология ADD предполагает:

1. Определение артефактов, имеющих ценность обязательно для всех заинтересованных сторон (заказчика, исполнителя, аудитора и др.).

2. Планирование работ (как последовательности итераций, спринтов) по созданию таких артефактов.

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

• концепция будущего программного продукта;

• спецификация бизнес-требований заказчика;

• спецификация системных требований к программному продукту;

• фрагмент бэклога программного продукта;

• законченная версия продукта с заранее заданными характеристиками;

• и другие.

Часто первым артефактом проекта становится налаженное взаимодействие заказчика с исполнителем, которое, как известно, важнее спецификаций, документации, стандартов и даже самой методологии разработки.

Методология не накладывает никаких ограничений на виды, количество, состав, порядок создания артефактов. Заинтересованные стороны процесса разработки программного продукта должны договориться о критериях качества артефакта (например, комплекс критериев INVEST для элемента бэклога в методологии Scrum).

Процесс разработки программного продукта по методологии ADD представляет собой последовательность итераций (спринтов) с целью разработки артефактов. Одного или нескольких в результате каждой итерации. Состав, количество итераций в рамках методологии ADD определяется заинтересованными сторонами. Количество итераций может быть заранее заданным (аналог каскадной методологии разработки) или неопределенным с критериями завершения проекта (аналог итеративных методологий). Длительность итераций также устанавливается заинтересованными сторонами. Итерации могут иметь как одинаковую, так и разную длительность в рамках проекта.

При разработке по методологии ADD рекомендуется активно использовать паттерны (как известные, так и вновь созданные):

• артефактов (моделей, документов и др.);

• итераций в отдельности (как видов работ – формирование бэклога продукта, тестирование и др.);

• совокупности итераций процесса разработки продукта в целом (например, анализ-проектирование-реализация-тестирование-документирование по каскадной методологии или последовательность циклов постановка-проектирование-реализация-стабилизация по итеративной методологии);

• и другие.

Достоинства и недостатки методологии ADD

Основные достоинства методологии ADD:

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

2. Методология позволяет существенно снизить противостояние заказчик-исполнитель за счет смещения фокуса на общие цели сторон, избежать длительных дискуссий (в том числе, на концептуальные темы).

3. Методология предоставляет истинную гибкость процесса разработки продукта (теоретически, даже последовательность итераций со смещением по времени).

4. Методология не накладывает ограничений на состав команды исполнителя (позволяет использовать как команды с «классическим» распределением ролей, так и команды с условно полной кросс-функциональностью).

5. В случае явного отсутствия (или ограниченной доступности) заказчика его роль может успешно играть владелец продукта от исполнителя.

6. Методология может быть применена для создания любых продуктов, не только программных.

Основные недостатки методологии ADD:

1. Поскольку заинтересованные стороны имеют равные полномочия (в отличие от большего веса заказчика в «традиционных» методологиях), может потребоваться некий третейский судья для разрешения тупиковых ситуаций.

2. Этот недостаток может привести к появлению новой дополнительной роли – независимого куратора проекта разработки продукта (вероятно, из числа влиятельных ИТ-специалистов современности).

3. Успешное применение паттернов требует определенной модерации, вероятно, независимым экспертом.

4. Методологии присущи все недостатки самоорганизации в проектах разработки продуктов.

5. Этот недостаток может усиливаться нетипичностью процесса гибкой разработки для заказчика.

6. Методология не предлагает готовых механизмов преодоления разногласий внутри сторон (может быть для заказчиков – больших или сильно регламентированных организаций).

7. И последний. Данной методологии не существует. Она появилась как шутка внутри команды разработки Innovative People. С первым апреля, коллеги!

В сухом остатке

“Новый выстрел «Серебряной пули нет»” (Ф.Брукс).

“…всегда хочется, чтобы проектанты работали вместе с конструкторами.” (К.Феоктистов)

“- А какой самый главный прибор в кораблевождении?

— Голова, — отвечали педагоги…” (В.Пикуль)