Роберт Мартин - Чистый Agile. Основы гибкости

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

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

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

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

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

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

В 1970 году Уинстон Ройс в своей работе [7] Royce W. W. 1970. Managing the development of large software systems. Proceedings, IEEE WESCON, August: 1–9. URL: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf . описал идеи для управления крупномасштабными проектами по разработке программного обеспечения. В этой работе присутствовала схема (рис. 1.1), которая наглядно изображала его план. Ройс не был автором этой схемы и не продвигал ее в качестве плана. В действительности график представлял собой изображение соломенного человечка и помогал Ройсу ориентироваться в последующих страницах своего труда.

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

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

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

Каскадная модель стала логическим продолжением научной организации труда. При использовании этой модели на первый план ставится тщательный анализ, составление подробного плана, а затем уже доведение этого плана до завершения. Хотя Ройс и не рекомендовал такой подход, но именно эту концепцию вынесли из его работы. А потом эта концепция главенствовала в отрасли более трех десятков лет [8] Стоит отметить, что мое толкование этой временной шкалы подвергли сомнениям. См.: Bossavit L. The Leprechauns of Software Engineering: How Folklore Turns into Fact and What to Do About It, Ch. 7. Leanpub, 2012. .

Как раз тогда и начинается моя история. В 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 я писал только на ассемблере.

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

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

Какую методологию мы использовали на протяжении того времени? Это, конечно, была не каскадная модель. У нас не было концепций или подробных планов. Мы просто писали код каждый день, компилировали, тестировали и устраняли ошибки. Это был бесконечный цикл без структуры. Также это был не Agile и даже не прото-Agile. В ходе работ мы не придерживались каких-либо правил организации. Тогда не было каких-либо пакетов программ для тестирования и измеряемых временных интервалов. Просто надо было писать код и фиксить баги. День за днем, месяц за месяцем.

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

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

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