Читаем статью «Итеративная и инкрементальная разработка: краткая история»

Оригинал статьи: Iterative and Incremental Development: Brief History (локальная копия на всякий случай).

Авторы: Craig Larman, Victor R. Basili

Опубликована IEEE Computer Society в 2003 году

Бытует мнение, что итеративная разработка — это изобретение 21-го века, присущее агильным методам. А ранее, дескать, был водопад. Авторы статьи показывают, что идеи итеративной инкрементальной разработки (Iterative Incremental Development, IID) уходят корнями в 50-е годы 20-го века, и что в каждой декаде с тех пор наиболее прогрессивные умы успешно применяли IID в своих проектах.

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

До 1970

IID выросла из работы Walter Shewhart, опубликованной в 30-е годы в области улучшения качества. Shewhart предлагал короткие циклы plan-do-study-act (PSDA), планирование-действие-проверка-корректировка, методика известная в русском языке как принцип Деминга-Шухарта. W. Edwards Deming последовательно продвигал эту методику в 40-е годы.

Проект сверхзвукового самолёта X-15 был одним из ключевых проектов 50-х годов, применивших IID, причем IID стала одной из главных составляюзих успеха проекта.Это не был проект по разработке ПО (программного обеспечения), но интересно, что часть команды этого проекта стала ядром команды проекта NASA «Меркурий» (начало 60-х), в котором IID использовалась для разработки ПО. А далее часть команды «Меркурия» стала ядром отделения IBM Federal Systems Division (FSD), также большим пропонентом IID. В проекте «Меркурий» использовались микро-итерации по полдня длиной. Интересно, что использовалась практика test-first, входящая в XP (Экстремальное Программирование).

Первая публикация фокусирующаяся на рекомендации подхода IID — это отчёт 1968-го года Brian Randell и F.W. Zurcher из IBM T.J. Watson Research Center.

70-е годы

В 1970-м году вышла знаменитая статья Winston Royce «Управление разработкой больших компьютерных систем». (Поскольку я уже подробно комментаровал и даже переводил эту статью в «Где истоки водопада?«, здесь без подробностей. — Григорий Грин.) Хотя Ройса несправедливо называют отцом водопада, на самом деле в этой статье он проповедовал раннюю версию итеративного процесса. Достаточно указать на принципы праллельной эволюции дизайна (архитектуры) и анализа, раннего прототипа и прохождения всего цикла разработки дважды.

Следующее свидетельство IID можно найти в работе Harlan Mills из IBM FSD. В своей работе «Программирование сверху вниз в больших системах» он продвигал итеративную разработку. К примеру, он писал:

… возможно создать последовательность промежуточных систем, включающих код и под-спецификации, так что на каждом шагу соответствующая промежуточная система может быть верифицирована на корректность…

Очевидно, Миллс предложил итеративное уточнение в фазе разработки, но он не упомянул об избежании большого детального планирования заранее, не указал длину итерации и не подчеркнул важности обратной связи и адаптации в зависимости от результата итерации. Он говорил об этих вещах позже, в конце 70-х.

Очень успешно практика IID применялась и развивалась в IBM FSD, в их критических проектах для министерства обороны и авионики, к примеру, система управления подводной лодкой Trident.

Также применяла IID и фирма TRW — конкурент IBM FSD. Известен их оборонный проект по ПВО — защиты от баллистических ракет с бюджетом в 100 миллионов долларов. В TRW работал упоминавшийся выше Royce. Также в TRW на должности главного научного сотрудника работал Barry Boehm, ставший в середине 80-х известен своей спиральной моделью.

В 1975 Vic Basili и Joe Turner опубликовали статью, описывающую классический подход IID.

В 1976 Tom Gilb опубликовал книгу Software Metrics (откуда пошел термин «метрика»). В книге он обсуждал свою практику работы с IID — эволюционное управление проектом и ввёл термины «эволюция» и «эволюционный». Это самая ранняя книга, чётка обсуждающая преимущества IID, особенно эволюционной поставки. Гильб пропагандировал агильные, легковесные, адаптивные итерации, схоже с современными методологиями.

В 1977 FSD включила итеративный подход проекта Trident в свой инструментарий. Методология распространилась на 2.500 инженеров фирмы, а идея IID как альтернатива водопаду, пробудила большой интерес как среди коммерческих подразделений IBM, так и среди их клиентов.

Другой интересный и малоизвестный пример IID — система авионики программы NASA космический челнок. Команда применила IID в 17 итерациях на протяжении 31 месяца.

Первая публикация по теме в популярной литературе случилась в 1978, когда Том Гильб начал пуликовать столбец в британском Computer Weekly.

Carolyn Wong из System Development Corp. писала в 1984 о проекте ПВО продолжавшимся с 1977 по 80:

Каскадная модель была принята потому, что разработка следовала требованиям министерства обороны. На самом же деле, разработка ПО — это сложный, непрерывный, итеративный и повторяющийся процесс. Каскадная модель не отражает этой сложности.

80-е годы

В 1980 Weinberg опубликовал статью «Адаптивное программирование: новая религия», а годом позже Tom Gilb описал эволюционную разработку.

В том же году Daniel McCracken и Michael Jackson продвигали IID и спорили с «отупляющим водопадом».

В 1982 William Swartout и Robert Balzer писали о том, что между специфицированием и дизайном существуют тесные двухсторонние взаимосвязи и продвигали итеративный и инкрементальный подход к разработки требований и программированию.  В том же году они продемонстрировали самый ранний пример очень большого проекта (100 миллионов долларов, военный проект, IBM), разработанного итеративно.

В 1983 Grady Booch написал книгу «Разработка ПО на языке Ада«, где он описал итеративный процесс для объектно-ориентированных систем. Эта книга стала известной в узких кругах разработчиков для оборонки, и то более за объектно-ориентированный аспект, чем за итеративный. Последующая работа Grady Booch из 90-х стала известна более широкой аудитории, и многие пришли к итеративной разработке как раз через эту книгу.

Практика эволюционного прототипирования стала популярной в 80-е среди разработчиков систем искуссвенного интеллекта, особенно использовавших Лисп.

Статья Tom Gilb середины 80-х «Эволюционная поставка или каскадная модель» продвигала более агрессивную стратегию чем другие IID источники того времени, рекомендуя более короткие итерации (несколько недель).

Важнейшей вехой была публикация 1985 Barry Boehm «Спиральная модель разработки и усовершенствования ПО» (A Spiral Model of Software Development and Enhancement). Спиральная модель не ввели итеративные идеи впервые, но она их формализовала и обосновала планирование итераций с учётом рисков и активное управление рисками.

В 1986 вышла знаменитая статья Frederick Brooks «Серябряной пули нет» (No Silver Bullet), восхваляющая преимущества IID: «… ничего за последнюю декаду не меняло мою практику и её эффективность так радикально [как IID]». А относительно водопада Брукс пишет:

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

В 1986 вышла работа David Parnas и Paul Clements «Рациональный процесс дизайна: как и зачем его фальсифицировать», в которой они сказали, что хотя и поддерживают идеалый образ (чёткая и полная спецификация до начала разработки), на практике он недостижим и поэтому не стоит ему следовать. Они назвали несколько причин:

  • Пользователи не знают точно что и как они хотят от системы
  • Даже если бы можно было сформулировать все требования, всё равно останется много деталей, которые вылезут только во время реализации
  • Даже если бы мы знали все эти детали, будучи людьми, мы можем справляться лишь с ограниченной сложностью
  • Даже если бы мы справлялись с этой сложностью, внешние силы приведут к изменениям требований, что повлияет и на наши ранее принятные решения.

В итоге образ дизайнера, который создаёт свой дизайн полностью корректным безошибочным способом на базе фиксированных требований, не является реалистичным.

В 1987 TRW запустила большой четырехгодичный проект (CCSPDS-R) на базе IID. Было проведено 6 шестимесячных итераций. Подход, описанный в работе Walker Royce, соответствовал тому, что позже стало RUP — Rational Unified Process: особое внимание наибольшим рискам и стабилизация архитектуры в ранних итерациях.

Bill Curtis с коллегами изучили процессы в 19 проектах и опубликовали результаты. Они пришли к выводу о важности итераций и фокуса на любях, процессах обучения и коммуникации, в отличии от классического процесса производства.

В 1987 Mills, Dyer и Linger из IBM FSD развили идеи IID в методику Cleanroom, сочетающую эволюционную разработку с более формальными методами спецификации и доказательства, что отражало сильное влияние математических методов на Mills’а.

В конце 80-х министерство обороны проанализировало успехи своих важных проектов (которые были скорее скромными) и пришло к тому, чтобы отойти от строго предписанного каскадного процесса (как зафиксировано в DoD-Std-2167) и разрешить использование IID. Работу исследовательской комиссии возглавлял Brooks.

Дополненный стандарт 2167A хотя формально и позволял использование других методологий, но тем не менее сохранил сильное предпочтение водопада. Даже разработчик стандарта 2167 позднее говорил, что если бы он во время разработки стандарта знал об IID, он бы скорее рекомендовал это, чем водопад.

В 1988 Gilb опубликовал книгу «Принципы управления разработкой ПО» — первую книгу с развёрнутыми главами объясняющими и рекомендующими IID. В них он повторил и углубил материал из своей более ранней книги «Software Metrics». Gilb описал метод «Evo«, характеризующийся частыми эволюционными поставками и использованием количественных метрик.

90-е годы (до 2003)

К 90-м годам, особенно их второй половине, распространение методов IID значительно ускорилось. Были опубликованы сотни книг и статей, родились дюжины методик, построенных вокруг IID, продвигающие короткие фиксированные по времени итерации длительностью от 1 до 6 недель. В отличие от итеративных опытов 70-х и 80-х, в 90-е стали избегать подробные спецификаци в начале проекта, включая деятельность по дизайну и по требования в итерацию.

Даже министерство обороны серьёзно пересмотрело свой подход и заменило стандарт 2167 на новый, Mil-Std-468, который теперь предписывал итеративную разработку. Стандарт даже признаёт тот факт, что при итеративной разработке финальные требования к системе могут быть неизвестны до финального релиза, так же как и финальный дизайн.

Тем временем, в области коммерческого ПО, Jeff Sutherland и Ken Schwaber в Easel Corp. начали применять метод, названный впоследствии Scrum с использованием 30-дневных итераций. Метод черпал вдохновение от японских методов (не-ПО), использованных в Honda, Canon, Fujitsu в 80-е. Статья 1999 года описала их дальнейшие усовершенствования с Scrum.

В 1994 группа последователей RAD (Rapid Application Development) встретилась для обсуждения стандартного итеративного подхода для RAD. Из этой инициативы родился метод DSDM — Dynamic Systems Development Method.

В середине 1990-х внутри Rational Corp. услиями многих людей (прежде всего Philippe Kruchten и Walker Royce) был разработан RUP — Rational Unified Process.

Полное определение процесса XP — eXtreme Programming — сформировалось в 1996 когда Kent Beck присоединился к проекту Chrysler C3. XP приобрела популярность благодаря своей сфокусированности на коммуникации, простоте, тестировании, жизнеспособному набору практик, расчитанных на программистов и своему интересному имени.

В 1997 году Peter Coad и Jeff de Luca спасли большой проект в Сингапуре, начавшийся как водопад и находившийся в критическом состоянии. Проект стал успешным IID проектом. На этой основе родилась итеративная методика FDD — Feature Driven Development.

Отчёт CHAOS, опубликованный в 1998, определил основные причины краха проектов в следовании каскадной модели, и напротив — следование IID улучшает ситуцацию в проектах.

Министерство обороны в 2000 ещё раз обновила свой стандарт. Новая версия, DoD 5000.2, также была сфокусирована на итеративном процессе.

В 2001 группа из 17 экспертов, представляющих разные течения в IID (DSDM, XP, Scrum, FDD, и т.д.), встречалась в штате Юта, чтоб обсудить общие принципы. Из этой встречи родился термин «агильные методы» (agile methods), агильный манифест и агильный альянс. Все агильные методы используют и развивают IID. Alistair Cockburn опубликовал в 2002 первую книгу под названием «Agile Software Development».

 

Как пошутил H.L.Mencken —

… для любой сложной задачи существует решение, являющееся простым, ясным и … неверным.

Таким решением в области разработки ПО стала каскадная модель. Хотя, как показано в этой статье, лучшие умы знали и применяли итеративный подход начиная с 50-х годов. Тем не менее, каскадная модель (водопад) оказалась живучей и продолжала портить проекты на протяжении десятилетий (и продолжает и по сей день).

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s