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. Часть 1. Предтечи

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

Истоки

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

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

ENIAC

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

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

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

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

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

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

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

perfocard

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

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

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

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

fortran

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

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

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

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

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

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

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

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

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

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

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

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

ballistic

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

 

Время первых

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

NATO Conference

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

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

 

Waterfall

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

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

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

waterfall_ford

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

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

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

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

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

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

waterfall real

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

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

Что дальше?

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

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

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

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

plan vs reality

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

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

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

Sashimi

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

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:

 

 

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

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

Agile поиски
1 сен 2020, Василий Савунов
Как появился Agile. Часть 2. Поиски

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

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

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