Чистый Agile. Основы гибкости

В первые дни существования программного обеспечения можно найти много примеров решения задач, которые сейчас бы отнесли к Agile. Например, программисты, писавшие код для управления пилотируемым космическим кораблем «Меркурий», работали по этапам с интервалом в полдня с перерывами на модульное тестирование.

Об этом периоде есть много материалов. Крэг Ларман и Вик Базили написали историю, которая кратко изложена в «вики» Уорда Каннингема[5], а также в книге Лармана Agile & Iterative Development: A Manager's Guide[6].

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

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

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

Научная организация труда получила свое название из работ Фредерика Уинслоу Тейлора, написанных в 1880-х. Тейлор сформировал этот подход, придав ему коммерческую ценность и сделав состояние на консультировании по управлению. Метод получил широкий успех и привел к значительному повышению эффективности и производительности в последующие десятилетия.

И так случилось в 1970-е, что мир разработчиков программного обеспечения разделился на два лагеря – сторонников того или иного метода. Прото-Agile (Agile, еще не получивший название «Agile») предлагал предпринимать в зависимости от обстоятельств небольшие случайные шаги, которые можно измерить и выделить, для того чтобы идти в правильном направлении к наилучшему исходу. Научная организация труда призывала откладывать действие до тщательного анализа и проработки заранее подготовленного плана. Прото-Agile прекрасно подходил для проектов с низкой стоимостью внесения изменений, которые решали частично определенные задачи с произвольно поставленными целями.

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

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

В 1970 году Уинстон Ройс в своей работе[7] описал идеи для управления крупномасштабными проектами по разработке программного обеспечения. В этой работе присутствовала схема (рис. 1.1), которая наглядно изображала его план. Ройс не был автором этой схемы и не продвигал ее в качестве плана. В действительности график представлял собой изображение соломенного человечка и помогал Ройсу ориентироваться в последующих страницах своего труда.

Рис. 1.1. Схема Уинстона Ройса, которая стала источником вдохновения для разработки каскадной модели

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

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

Каскадная модель стала логическим продолжением научной организации труда. При использовании этой модели на первый план ставится тщательный анализ, составление подробного плана, а затем уже доведение этого плана до завершения. Хотя Ройс и не рекомендовал такой подход, но именно эту концепцию вынесли из его работы. А потом эта концепция главенствовала в отрасли более трех десятков лет[8].

Как раз тогда и начинается моя история. В 1970-м мне было 18 лет, я работал программистом в компании A.S. C. Tabulating, расположенной в Лейк Блафф, Иллинойс.

У компании был компьютер IBM 360/30 с памятью на магнитных сердечниках 16 килобайт, IBM 360/40 с памятью 64 килобайта и микрокомпьютер Varian 620/f с памятью 6 килобайт. Я писал программы для семейства 360 на COBOL, PL/1, Fortran и ассемблере. Для 620/f я писал только на ассемблере.