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

Часть 1. Про то как разработка программ вышла из-под контроля и что из этого вышло

Часть 2. (эта статья) Про поиски «серебряной пули» в управлении разработкой программ

Часть 3. Как «легковесные методы» объединились в Agile

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

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

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

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

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

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

Чтобы понять, в чем была прогрессивность этого подхода в середине 50-х, надо принять во внимание, что в то время, программы были жестко привязаны к “железу”. Программное обеспечения создавалось либо компаниями которые это “железо» производили, либо силами компаний, купившими это “железо” для решения своих задач. А CUC впервые вышла на рынок с предложением независимой разработки ПО, не являясь при этом ни производителем «железа», ни его пользователем.

Пройдя долгий путь, к 1986-му году CUC была старейшей софтверная компания в США. Она прошла  путь от пионера в области разработки программного обеспечения до динозавра, который проиграл конкурентную борьбу, так как не смог приспособиться к тем изменениямн на рынке ПО, которые сложили в 80-е годы.

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

Но к 80-м годам XX века ситуация в корне поменялась, и главным виновником этих изменений была компания IBM, которая была бесспорным лидером рынка, и влияла на него очень сильно.

IBM/360

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

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

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

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

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

Software Crisis

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

Одним из самых печально известных и хорошо задокументированных примеров этого кризиса стал проект 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 программных пакетов только для индустрии страхования жизни.

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

Что же случилось с 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).

Это была критически важная система, более чем в 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 миллионов долларов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но об этом — в следующей части: Часть 3. Призыв

Предыдущя часть тут: Часть 1. Предтечи

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

• Computer Usage Company https://en.wikipedia.org/wiki/Computer_Usage_Company
• Martin Campbell-Kelly, “Development and Structure of the International Software Industry, 1950-1990” https://www.cin.ufpe.br/~in953/lectures/papers/DevelopmentandStructureoftheInternationalSoftwareIndustry.pdf
• History of IBM: https://www.ibm.com/ibm/history/history/history_intro.html
• IBM 360 Wiki https://en.wikipedia.org/wiki/IBM_System/360
• “Building the System/360 Mainframe Nearly Destroyed IBM” https://spectrum.ieee.org/tech-history/silicon-revolution/building-the-system360-mainframe-nearly-destroyed-ibm
• Фредерик Брукс “Мифический человеко-месяц” https://en.wikipedia.org/wiki/The_Mythical_Man-Month
• TRW Inc.  https://en.wikipedia.org/wiki/TRW_Inc.
• IBM Federal System Division https://en.wikipedia.org/wiki/History_of_IBM#IBM_Federal_Systems_Division_(FSD)
• Trident Submarines: https://fas.org/nuke/cochran/nuc_84000001d_01.pdf
• Highlands Army Air Defense Site https://en.wikipedia.org/wiki/Highlands_Army_Air_Defense_Site
• Don O’Neill https://us-cert.cisa.gov/bsi/about-us/authors/don-oneill
• Victor Basili, Albert Turner “Iterative Enhancement: A Practical Technique for Software Development“ https://www.cs.umd.edu/users/basili/publications/journals/J04.pdf
• Victor Basili https://en.wikipedia.org/wiki/Victor_Basili
• Spiral Model : https://en.wikipedia.org/wiki/Spiral_model
• Frederick Brooks “No Silver Bullet” http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf
• Craig Larman “Iterative and IncrementalDevelopment: A Brief History” https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf
• Intel 4001 https://en.wikipedia.org/wiki/Intel_4004