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

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

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

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

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

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

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.

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

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

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

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 года. Мне она казалась даром свыше. Неужели мы могли бы проанализировать задачу, потом предложить ее решение, а затем реализовать замысел? Реально ли было на самом деле разработать график, основанный на трех перечисленных этапах?

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

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

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

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

Чтобы увидеть, насколько каскадная модель захватила наши умы, посмотрите на программные языки того времени. Когда Дейкстра в 1968 году представил структурное программирование, структурный анализ [9] и структурный дизайн [10] не сильно отставали. В 1988 году, когда объектно-ориентированное программирование (ООП) набрало популярность, объектно-ориентированный анализ [11] и объектно-ориентированное проектирование [12] также не сильно отставали. Эта тройка идей, эти три этапа словно держали нас в плену. Мы просто не могли представить, что можно работать как-то по-другому.

9

DeMarco T. Structured Analysis and System Specification. Upper Saddle River, New Jersey: Yourdon Press, 1979.

10

Page-Jones M. The Practical Guide to Structured Systems Design. Englewood Cliffs, New Jersey: Yourdon Press, 1980.

11

Coad P., Yourdon E. Object-Oriented Analysis. Englewood Cliffs, New Jersey: Yourdon Press, 1990.

12

Booch G. Object Oriented Design with Applications. Redwood City, California: Benjamin-Cummings Publishing Co., 1991.

А потом оказалось, что можно.

Зародыши преобразований, связанных с Agile, появились в конце 1980-х или в начале 90-х. В сообществе Smalltalk их признаки начали проявляться в 1980-х. В книге Буча по объектно-ориентированному проектированию, вышедшей в 1991-м, были намеки на них. Прочие решения возникли в 1991 г. в книге Кокберна Crystal Methods. Сообщество Design Patterns начало обсуждать это в 1994-м под влиянием статьи, написанной Джеймсом Коплиеном [13] .

13

Coplien J. O. A generative development-process pattern language. Pattern Languages of Program Design. Reading, Massachusetts: Addison-Wesley, 1995. P. 183.

К 1995 году Бидл [14] , Девос, Шэрон, Швобер и Сазерленд написали свои знаменитые труды о Scrum (Скрам) [15] . И затворы открылись. На бастионе каскадной модели образовалась брешь, и пути назад не было.

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

14

Майк Бидл был убит 23 марта 2018 года в Чикаго психически нездоровым человеком, до этого арестованным и отпущенным 99 раз, который должен был находиться в психбольнице. Майк Бидл был моим другом.

15

Beedle M., Devos M., Sharon Y., Schwaber K., Sutherland J. SCRUM: An extension pattern language for hyperproductive software development. Ссылка: http://jeffsutherland.org/scrum/scrum_plop.pdf.