Как появился Agile. Часть 1. Предтечи

Часть 1 (эта статья)

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

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

Истоки

Сейчас применение Agile-подходов выходит далеко за рамки IT, но история появление и развития Agile тесно связана с историей компьютерной техники и разработки программного обеспечения. Поэтому чтобы понять Agile, придется отталкиваться от истории software engineering  —  менеджмента разработки программ, и развития компьютеров ка.

Первое электронное устройство, в названии которого было слово «computer», это ENIAC (Electronic Numerical Integrator and Computer), который разрабатывался в 1942–1945 годах и работал 10 лет, до 1955 года. Это было детище ученых, которые сами его проектировали, создавали, отлаживали и вообще лучше всех в нем разбирались.

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

Устоявшихся стандартов разработки программ еще не существовало. Ученые постоянно экспериментировали и при разработке программ каждый из них делал так, как считал нужным.

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

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

Это было время, про которое говорят, что “компьютеры были большими, а программы маленькими”. Для примера  —  ENIAC весил 30 тонн, содержал 18 000 радиоламп, имел размеры 2,5×30 метров и обеспечивал выполнение 5000 сложений и 360 умножений в секунду. По нынешним временам ENIAC представлял собой очень большой калькулятор. Ничего больше он не умел. Убожество, по сравнению с сегодняшними смартфонами, не правда ли?

При этом программы, которые готовили для ENIAC, имели размер всего несколько десятков бит информации. Сравните это с размером программы калькулятора сейчас  —  счет идет на Мегабайты ( 2.8 Мегабайта ), то есть больше миллиона бит информации.

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

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

Между тем потребность в массовой разработке встала во весь рост, и все начало меняться.

Взрывной рост

Начало массовой разработке ПО было положено в 1957 году, когда компания IBM презентовала первый язык программирования высокого уровня Fortran (Formula Translator). Он предоставлял возможность создавать программы на понятном для обычного человека языке (английском), а не переключая тумблеры или пробивая дырки в перфокарте.

Вслед за этим стали появляться другие языки высокого уровня, что привело к взрывному росту объемов разработки ПО. Всякий, кто освоил синтаксис такого языка программирования, изучил правила работы и справился с компилятором, считал себя программистом. Чем-то это напоминало мем “я купил зеркалку, теперь я фотограф”.

В то время еще не существовало каких-либо правил или стандартов разработки программ. Каждый писал программы так, как “Бог на душу положит”. Были отдельные уникумы, у которых это получалось хорошо, но в основной массе эти “писатели программ” делали совершенно ужасные программы, которые были нестабильны, плохо оптимизированы. Пользоваться ими тоже было не особо удобно.

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

В процессе разработки Заказчик обязательно вспоминал что-то, что он забыл попросить Программиста сделать, прибегал к нему с “ценными замечаниями и дополнениями”, что меняло направление разработки и сдвигало срок окончания.

Так как Программист обладал всей полнотой экспертизы в разработке программ, то он сам проектировал программу, разрабатывал, тестировал и упаковывал для отправки Заказчику. Никакого разделения труда не существовало. Надо ли говорить, что это не способствовало качеству конечного продукта, т.к. “глаз замыливался” и Программист не видел совершенно очевидных дефектов или даже не считал их дефектами.

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

Такой подход к разработке программ назвали “Code & Fix”, и к сожалению, он встречается и сейчас.

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

В конечном итоге, в режиме “Code & Fix” разработка программы заканчивалась либо тогда, когда у Заказчика кончалось терпение, либо тогда, когда исчерпывался бюджет.

Причина этих проблем была в отсутствии общих стандартов и подходов к разработке ПО.

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

А теперь представьте, что у вас десяток писателей, и им надо сообща написать роман на 500 страниц. Причем роман, который будет иметь коммерческий успех, нравиться читателям, и содержать все пожелания Заказчика. Представили? Кажется, что задача весьма непростая. Для успеха, как минимум, этой группе писателей нужно договориться об общих правилах, стандартах, этапах написания, приемки и так далее. Иначе коллективная работа превращается в хаос.

Последствия

В 60-80х годах XX века, отсутствие такого рода стандартов и правил привело к полноценному мировому кризису разработки программного обеспечения (software crisis).

Во всем мире в проектах по разработке ПО наблюдались одни и те же нерешаемые проблемы:

• Проекты всегда превышали бюджеты;
• Реализация проекта всегда превышала оговоренные сроки;
• Итоговое ПО неэффективно решало возложенную на него задачу (тормозило, нестабильно работало и т.д.);
• Итоговый результат был низкого качества;
• Проекты были неуправляемыми, а код было сложно поддерживать;
• Разработке не было видно конца, и в конечном итоге, заказанное ПО никуда не поставлялось и нигде не разворачивалось и не использовалось (https://en.wikipedia.org/wiki/Vaporware).

Источник: https://en.wikipedia.org/wiki/Software_crisis

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

Например, печально известный случай с аппаратом лучевой терапии Therac-25. Он был предназначен для лечения онкологии, и с этой целью дозировано облучал опухоль узконаправленным пучком электронов энергией до 25 МэВ. Излучение такой мощности очень опасно для человека, поэтому режим облучения был строго ограничен по времени и мощности.

Аппаратом управляла мини — ЭВМ с ПО написанным на ассемблере. Казалось бы, что могло пойти не так?

Однако из-за необрабатываемых ошибок в управляющей программе этот аппарат минимум 6 раз превышал допустимую мощность облучения в сотни раз. Как минимум двое пациентов умерли непосредственно от передозировок.

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

С другой стороны, в самом разгаре шла Холодная война, и противоборствующие стороны  —  США и СССР  —  вовсю наращивали свой ядерный потенциал. Расчеты траекторий баллистических ракет делались на компьютерах с применением соответствующих программ, которые разрабатывались по “Code & Fix” процессу. А если в программе будет ошибка, то куда упадет ракета? К противнику? Или на нашу территорию? Цена ошибки  —  несколько сотен тысяч жизней.

 

Время первых

Военные это все понимали, поэтому в 1968 году, под эгидой блока NATO (не путать с NASA!) была организована первая в мире конференция по разработке общих правил разработки ПО ( https://www.scrummanager.net/files/nato1968e.pdf )

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

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

 

Waterfall

В 1970 году Уинстон Уокер Ройс (Winston Walker Royce), американский ученый, директор центра Lockheed Software Technology Center опубликовал статью, под заголовком “Managing the Development of Large Software Systems”, в которой описал концепцию “каскадной модели”  разработки программного обеспечения. Описал он его, как иллюстрацию наиболее распространенного подхода к разработке ПО, а вовсе не предлагая как единственно верное решение.

Сам Уинстон Ройс не называл этот подход “каскадным”, но сама логика повествования и иллюстрации очень напоминали “каскад” водопадов, поэтому модель больше известна как “waterfall model” или “каскадная модель”.

Описанный подход был очень похож на конвейер, используемый в материальном производстве сложных устройств (автомобилей и др). Работа двигалась по стадиям, как по ленте конвеера, и в результата появлялся готовый продукт.

В исходной “каскадной модели” стадии шли в таком порядке:

1. Определение требований
2. Проектирование
3. Конструирование (также «реализация» либо «кодирование»)
4. Тестирование и отладка (также «верификация»)
5. Инсталляция
6. Поддержка

В процессе разработки все стадии проходятся строго последовательно, один за другим. Тем самым “каскадная модель” подразумевает, что переход от одной стадии разработки к другой происходит только после полного и успешного завершения предыдущей стадии, и что переходов назад либо вперед или перекрытия стадий не происходит.

Для своего времени это был гигантский прорыв, по сравнению с “Code & Fix”. Впервые появилась модель, которая описывала конкретные этапы реализации программного обеспечения и переходы между ними. Это давало понятный алгоритм работы, который расставлял зоны ответственности, позволял планировать и бюджетировать отдельные этапы, снижал многие риски и делал проект более прозрачным.

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

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

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

Но так получилось, что Уинстон Ройс останется в истории как создатель “каскадной модели” без какой-либо итеративности. Возможно, дело было в том, что сама формализация процесса разработки ПО была настолько ценной идеей, что именно этим аспектом она и запомнилась. Большинство задач, которые решали компьютеры в то время, были технологическими, инженерными или научными, как например, расчет траектории полета ракеты, а для таких задач есть понятный эмпирический алгоритм расчета, что позволяет исчерпывающе провести стадии определения требований и проектирования, без необходимости вносить коррективы в процессе реализации, поэтому классиеская «каскадная модель» для таких проектов работает хорошо. Таким образом, даже в PMBOK 3-й редакции модель вошла без всякого упоминания об итеративности.

Что дальше?

Мир разработки ПО ринулся воплощать в жизнь “каскадную модель” и почти сразу наткнулся на неприятные последствия. Хотя алгоритм разработки ПО стал более понятным, это не дало желаемой предсказуемости в плане сроков и оценки бюджетов. Кроме того, Заказчик получал совсем не то, что хотел.

В чем же были причины этих неприятных последствий?

Как мы помним, в “каскадной модели” все этапы надо проходить строго последовательно. При этом, качество и польза итогового продукта критически зависят от первых двух стадий  —  “определение требований” и “проектирование”. Если на этих стадиях допускалась ошибка, то она выявлялась только в самом конце, при выпуске продукта.

Получается, что пока все стадии не будут пройдены до конца, Заказчик не поймет, что же на самом деле он получит. Если требовалось внести в ПО какие-то коррективы, то каждая из них должна была опять пройти все стадии “каскадной модели”, что приводило к увеличению затрат. Бюджеты пухли, сроки «ехали».

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

Поэтому почти сразу стали появляться модификации “каскадной модели”, призванные решить недостатки исходной модели.

Например, была модель “Sashimi” Питера Де Грэйса, которая представляла собой “каскадную модель” с перекрывающимися стадиями для более раннего получения обратной связи и внесения корректировок.

Другая модификация предполагала “каскад с подпроектами” (Waterfall with Subprojects), в которой от этапа детального проектирования проект распадался на несколько подпроектов по каждому модулю, со своими этапами проектирования, разработки и тестирования.

Были и другие, более сложные модификации. Целью всех этих модификаций было одно  —  как можно более раннее обнаружение ошибок и их корректировка.

Тем не менее, в отдельных отраслях и видах проектов “каскадная модель” и сейчас показывает себя хорошо. Как правило, это происходит в случаях, когда стоимость ошибки столь высока, что лучше делать “долго и дорого”, чем допустить вероятность переделки. Например, NASA делает космические аппараты по процессу, который очень похож на “каскадный”. Подробнее можно посмотреть здесь: https://www.nasa.gov/sites/default/files/atoms/files/nasa_systems_engineering_handbook_0.pdf

Хотя другая компания подобного профиля, SpaceX, использует, другой итеративный подход для разработки космических аппаратов ( https://www.mindk.com/blog/iterative-development/ ).

Но об этих подходах мы поговорим уже в следующей части моего повествования.

Конец первой части

P.S.

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

Часть 2. Поиски

До встречи!

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

• ENIAC History :  https://en.wikipedia.org/wiki/ENIAC
• Перфокарты:  https://en.wikipedia.org/wiki/Punched_card
• Fortran :   https://www.ibm.com/ibm/history/ibm100/us/en/icons/fortran/
• Software Crysis : https://en.wikipedia.org/wiki/Software_crisis
• Therac 25: https://en.wikipedia.org/wiki/Therac-25
• NATO Software Engeneering Conference: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/NATOReports/index.html
• W. Royce Waterfall: http://web.archive.org/web/20160318002949/http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
• Сравнение Software Development Models  https://www.researchgate.net/publication/267711880_A_Comparative_Overview_of_the_Evolution_of_Software_Development_Models
• NASA Development Process : https://www.nasa.gov/sites/default/files/atoms/files/nasa_systems_engineering_handbook_0.pdf
• SpaceX Design process: https://arstechnica.com/science/2020/02/elon-musk-says-spacex-driving-toward-orbital-starship-flight-in-2020/
• SpaceX Development process: https://www.nextbigfuture.com/2018/12/reverse-engineering-spacex-to-learn-how-to-speed-up-technological-development.html