Agile
Agile-коуч
Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
HR
Kanban
KPI
LeSS
OKR
OKR-инструменты
PMI
Project management
SAFe
Scrum
Scrum in Hardware
Scrum-мастер
Spotify
XM
Архитектура
Бюджетирование
Владелец продукта
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Продуктовый менеджмент
Самоорганизация
Тренинг
Фасилитация
Финансы
Холакратия
Применить

Как появился Agile. Часть 2. Поиски

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

В предыдущих сериях

В первой части я описал состояние IT-отрасли перед появлением Agile и рассказал про “каскадную модель”, которая была одним из первых подходов, формализующих управление разработкой ПО.

Смерть патриарха

В 1986 году умерла компания Computer Usage Company.

В связи с этим журнал “Government Computer News” выпустил статью под заголовком “Смерть софтверной компании знаменует конец эпохи”, и для этого имелись все основания.

CUC death

CUC прожила долгую жизнь, начиная с 1955 года, и в большинстве источников ее называют первой независимой компанией, которая начала создавать софт на продажу.

Computer Usage Company

В середине 50-х годов программы были жестко привязаны к “железу” и создавались либо компаниями — производителями компьютеров (мейнфреймов), либо силами компаний, которые использовали эти компьютеры для решения своих задач. А CUC впервые вышла на рынок с предложением независимой разработки софта, не являясь при этом ни производителем мейнфреймов, ни их пользователем.

К 1986-му году это была старейшая софтверная компания в США. И вот она рухнула, пройдя путь от пионера в области разработки программного обеспечения до динозавра, который проиграл конкурентную борьбу, потому что не смог вовремя понять, что правила игры стали иные, и то, что работало в середине 50-х, к 80-м годам перестало работать.

За период с 1955 по 1986 года ситуация на рынке компьютеров и софта радикально менялась несколько раз. В 50-х годах XX века компьютеры (мейнфреймы) имели совершенно разную реализацию и набор команд, и под каждый мейнфрейм надо было писать свою версию программы. Программы считались частью мейнфрейма, без которого он превращался в дорогую груду редкоземельных металлов. Все пользователи мейнфреймов привыкли, что софт приходит к ним вместе с “железом”. Никто не думал, что софт можно продавать отдельно. Это долгое время сдерживало появление софтверного рынка, но к 80-м годам XX века ситуация в корне поменялась, и главным виновником этих изменений была компания IBM.

IBM/360

Для начала, в 1965 году компания IBM выпустила серию компьютеров IBM/360 (https://en.wikipedia.org/wiki/IBM_System/360), на которых можно было запускать программы общего назначения, а не только научные и инженерные.

IBM 360

Революционность этой линейки компьютеров заключалась еще и в стандартизации модельного ряда таким образом, что во всей линейке использовался один набор команд и одинаковые периферийные устройства (клавиатура, монитор и тд). Во всей линейке IBM/360, в которой было более 10 моделей, можно было запускать одни и те же программы. Таким образом, заказчик мог купить дешевую модель, а потом обновить свое “железо”, без необходимости переписывать программы. Кроме того, была обеспечена обратная совместимость с программами для компьютеров предыдущего поколения.

Не удивительно, что  после анонса компьютеров IBM/360 первичный объем заказов составил 100 000 заявок.

Под семейство IBM/360 можно было один раз написать программу и переиспользовать ее много раз на разных компьютерах одной линейки, это дало необходимую стабильность среды для развития софта.

Модель IBM/360 стала по настоящему массовым компьютером, и в результате сформировался софтверный рынок программ исключительно под IBM/360. Появилось множество компаний заказной разработки, которые специализировались на программах для этой линейки. В числе таких компаний была и упомянутая выше Computer Usage Company (CUC), которая к 1967 году разрослась до 12 офисов и 700 сотрудников, и ее годовой оборот составлял 13 миллионов долларов. CUC выделила команду из 20 программистов, которые работали над программами только под линейку IBM/360.

number of IBM 360

Оценочное количество коммерческих компьютеров, поставленных с 1959 по 1968 года. 
Источник: http://ethw.org/Early_Popular_Computers,_1950_-_1970

Software Crisis

Следующим фактором, который изменил правила игры на рынке, был разрастающийся программный кризис (software crisis).

software crisis

Одним из самых печально известных и хорошо задокументированных примеров этого кризиса стал проект IBM по разработке операционной системы (ОС) IBM OS/360 для линейки компьютеров System/360.

На разработку этой ОС у IBM ушло 5 тысяч человеко-лет (не часов!), и пиковое значение количества людей, занятых в разработке этой системы, составляло 1000 разработчиков! Именно по итогам работы в IBM Фредерик Брукс написал свою знаменитую книгу “Мифический человеко-месяц” (https://en.wikipedia.org/wiki/The_Mythical_Man-Month), когда после добавления 1000 разработчиков в проект, сроки разработки не только не уменьшились, а наоборот, увеличились!

Общие затраты на разработку OS/360 превысили 5 миллиардов долларов(!), что составляло половину стоимости американской атомной бомбы и вдвое больше того, что IBM зарабатывало в год. Разработка OS/360 заняла 5 лет, и этот проект стал “черной дырой”, которая высасывала время и деньги компании.

И хотя с началом продаж в 1971 году все затраты окупились, потому что годовой доход от OS/360 составил цифру 8.3 миллиарда долларов, стало ясно, что время “больших монолитных программ” сочтено.

Чем больше программа, тем больше в ней потенциальных ошибок, тем больше людей вовлечено в разработку, тем сложнее сохранить единство архитектуры и прочее, и прочее, и прочее. Подходы к разработке надо было менять, и рынок немедленно отреагировал. На первый план вышла разработка “коробочных” программ* (packaged software), не привязанных к конкретной модели компьютера, поставляемых покупателю “как есть” и окупающих свое производство за счет массовых продаж разным клиентам. Стоимость таких программ была на несколько порядков меньше, чем гигантские заказные программы для мейнфреймов, что диктовало необходимость удешевлять производство программ за счет более коротких сроков разработки и меньшей численности команды разработчиков. Появилась конкуренция, и во главу угла теперь встала скорость разработки при сохранении качества, а не стабильность и известность на рынке.

Разделение продаж

Еще одно событие, изменившее рынок, произошло три года спустя, в 1968 году. Компания IBM, боясь преследований со стороны антимонопольных регуляторов США, официально перешла к политике разделения продаж “железа” и софта. Сама IBM позднее утверждала, что поступила так из-за растущей стоимости разработки софта, но в свете того, что через год, в 1969-м, началось антимонопольное расследование в отношении IBM, более вероятной кажется версия о превентивных мерах со стороны руководства компании, чтобы снизить будущие убытки. Вслед за лидером рынка, к разделению продаж “железа” и софта перешли и остальные игроки. К 71-му году такое разделение было обычным делом.

Все эти события привели к появлению полноценного софтверного рынка, который стремительно рос. Для примера, если в середине 60-х годов XX века американская страховая индустрия в основном пользовалась “бесплатным” софтом от IBM, который входил в поставку мейнфреймов, то после разделение продаж “железа” и софта произошел бурный рост фирм-разработчиков программного обеспечения, и к 1972 году 81 компания предлагала 275 программных пакетов только для индустрии страхования жизни.

software market share

В 1971 году резко изменился и рынок “железа”, в связи с появлением первого микропроцессора Intel 4001. Это открыло эру “микрокомпьютеров”, а затем и персональных компьютеров. Множество производителей мейнфреймов не смогли проявить гибкость и приспособиться к новым реалиям, однако были и те, кто оседлал волну.

intel 4001

Что же случилось с Computer Usage Company? Она продолжала цепляться за заказную разработку для мейнфреймов, предлагая разработку отраслевого софта “под ключ” вместе с поставкой соответствующего “железа”. Это требовало определенных организационных изменений, с которыми компания не справилась.

Первые финансовые проблемы у CUC начались уже в 1969 году. За этим последовала череда переговоров о слиянии с другими фирмами, несколько раз сменялся главы компании, но в конечном итоге 1985-й год компания закончила с убытком в 2.5 миллиона долларов и в 1986 году объявила о банкротстве.

Пример Computer Usage Company показал, что софтверный рынок требует быстрой реакции на изменения, иначе компания рискует вылететь с рынка. Долгая история, хорошая репутация и качество старых продуктов не гарантировало компании длинной жизни. В отличие от 50х, в 70-80-е годы XX века конкурентный рынок требовал скорости и гибкости. Старые методы не работали, пришло время для новых.

Поиски серебряной пули

Уинстон Ройс в своей статье, с которой мы ознакомились в первой части, писал: «Если рассматриваемая компьютерная программа разрабатывается впервые, сделайте так, чтобы версия, которая в конечном итоге предоставляется заказчику для оперативного развертывания, фактически была второй версией в том, что касается критических участков проектирования/функционирования».

Таким образом, в статье Ройса мы видим зачатки концепции итеративно- инкрементальной разработки (ИИР), обратной связи и адаптации. Может, основная масса тогдашних читателей статьи Ройса этого и не заметили, но специалисты из компании TRW (в которой работал Уинстон Ройс) и их конкуренты из IBM, вероятно, читали внимательно и сделали соответствующие выводы. Далее мы увидим, как они эти выводы использовали.

70-е годы XX века стали временем экспериментов с ИИР в проектах разного масштаба. Первый из известных нам крупных программных проектов, разработанных с применением ИИР, был осуществлен в 1972 году подразделением IBM Federal Systems Division (IBM FSD), которое специализировалось на крупных государственных проектах для NASA, Министерства обороны США или Агентства Национальной Безопасности.

Нужно было разработать ни много ни мало — систему управления и контроля для первой американской подводной лодки класса USS Ohio (SSBM-726), вооруженной новейшими баллистическими ракетами “Трайдент” (US Trident Submarine).

trident submarine

Это была критически важная система, более чем в 1 миллион строк кода. Разработку системы нужно было завершить к конкретному сроку, иначе IBM FSD пришлось бы платить неустойку в размере 100 тыс. долл. за каждый день просрочки. Команда разбила разработку проекта на четыре итерации по 6 месяцев и в конце каждой итерации проводила верификацию требований на основе обратной связи по готовой части проекта. На основании этой обратной связи готовились спецификации для следующей итерации.

Проект был завершен успешно и вовремя. Руководитель проекта Дон О’Нейл особо отмечал впоследствии, что использование ИИР было ключевым фактором успеха и отличным способом управления сложностью и рисками в таком большом проекте. Компания IBM отметила О’Нейла премией за выдающийся вклад в работу, а использованный им подход с 1977 года официально применялся в IBM под названием «интеграционной инженерии».

Тогда же, в 1972 году, компания TRW, конкурент IBM FSD, применила ИИР в крупном проекте разработки программного обеспечения Army Site Defense (https://en.wikipedia.org/wiki/Highlands_Army_Air_Defense_Site) для баллистической противоракетной обороны. Стоимость проекта составила 100 миллионов долларов.

missles contolr system

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

Первая версия системы отслеживала всего один летящий объект, а с выпуском по итогам пятой итерации несколькими годами позднее система была полностью готова и военные остались довольны результатом (количество объектов которые отслеживала финальная версия системы мне найти не удалось, наверное это военная тайна 🙂 ).

Были и другие крупные проекты с использованием ИИР, так что все 70-е годы специалисты набирали опыт применения этого подхода, экспериментируя с разной длиной итерации, разной наполненностью итераций, разным подходом к документам и тд. В конечном итоге, все, кто применял ИИР, стремились достичь следующих результатов:

  • Использовать ограниченные по времени итерации, чтобы управлять рисками и сложностью проектов
  • Обеспечить раннюю обратную связь по ходу проекта
  • Соответствовать ожиданиям конечных пользователей
  • Не пытаться предсказать заранее нужный результат, а действовать на основе данных от заказчика (пользователя)

В 1975 году вышла первая статья, официально описывающая итеративно-инкрементальный подход “Iterative Enhancement: A Practical Technique for Software Development“ (https://www.cs.umd.edu/users/basili/publications/journals/J04.pdf), и это вывело дискуссию о применении ИИР в публичную плоскость.

iterative incremental

Все 80-е годы среди специалистов было много дискуссий о том, каким должен быть ИИР. В этих дискуссиях участвовали такие известные в компьютерном мире люди, как Гради Буч, Джеральд Вайнберг, Эдсгер Дейкстра, Барри Боэм, Фредерик Брукс и другие. Все они хотели найти идеальную конфигурацию ИИР для быстрой и качественной разработки программ.

Важной вехой в этом процессе было появление в 1985 году “Спиральной модели” Барри Боэма. Она была универсальная, но довольно сложная для понимания, поэтому автору пришлось трижды разъяснять ее в соответствующих публикациях — в 86-м, 88-м и 2000 годах.

spiral model

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

В каждом витке тестируется гипотеза о возможности создания данного программного продукта, или что в действующий продукт можно внести изменение. Если гипотеза верна — мы получаем успешно завершенный проект, если мы ошиблись — спираль завершается без результата.

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

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

  1. Планирование
  2. Анализ рисков (Боэм выделил 10 типов рисков)
  3. Конструирование
  4. Оценка результата заказчиком

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

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

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

Глядя на спиральную модель, невольно приходит на ум цикл Шухарта — Plan-Do-Study-Act (PDSA), который лежит в основе системы управления качеством японской компании Тойота, из которой выросло “бережливое управление производством” (Lean Manufacturing).

PDSA

Японцев мы еще с вами вспомним чуть попозже, а пока приходится только удивляться, как одна и та же идея (цикл PDSA или PDCA) “проступает” в разных подходах к менеджменту, которые обсуждались специалистами, в поисках идеального процесса.

Подытожил все эти поиски идеала в 1986-м году Фредерик Брукс (тот самый, который написал про “Мифический человеко-месяц”) в своей широко обсуждаемой статье “No Silver Bullet”. В этой статье он фактически развенчал классическую каскадную модель как нерабочую и провозгласил, что сложные системы надо разрабатывать итеративно, через прототипы.

Итого: к началу 80-х годов XX века идея итеративно-инкрементальной разработки была уже хорошо известна и воспринималась как передовая. Оставалось добавить человеческое, командное измерение, чтобы появился Agile. Кто-то должен был сделать этот шаг, и он не заставил себя ждать.

Но об этом — в следующей части.

Часть 1. Предтечи

Источники для части 2:

1 сен 2020, Василий Савунов
Другие статьи
Agile манифест
20 сен 2020, Василий Савунов
Как появился Agile. Часть 3. Призыв

Это завершающая часть статьи про причины появления Agile.

agile history
24 авг 2020, Василий Савунов
Как появился Agile. Часть 1. Предтечи

Чтобы исчерпывающе ответить на вопрос «Что такое Agile?», надо сперва понять, в каких исторических условиях он зарождался, какие условия рынка привели к его появлению, и что двигало его создателями. Ничто не появляется “на пустом месте”, всегда есть влияние как прошлого, так и настоящего. Из исторического контекста можно понять логику подхода и применять предложенные им решения с умом, не сваливаясь в карго-культ.

6 июл 2020, Дмитрий Круглов
Темная сторона Agile

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