ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 344
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Введение
16
выполняют небольшую работу . Agile не рассчитан на решение крупных задач больших команд программистов, которые зани- маются крупными проектами . Есть даже что-то ироничное в том, что такое решение для таких мелких задач вообще имеет название .
В конце концов, мелкие задачи, о которых тут говорится, решили еще в 1950-е и 60-е, почти сразу, как изобрели программное обес- печение в принципе . Даже в те далекие времена небольшие коман- ды научились неплохо справляться с небольшим объемом работ .
Однако все испортилось в 1970-х . Тогда маленькие команды раз- работчиков, выполняющие небольшие объемы работ, запутались в идеях, пропагандирующих выполнение крупных работ в крупных командах .
А разве не так? Боже, да не так! Крупная работа не выполняется большими командами . На самом деле крупная работа выполняется большим количеством маленьких команд, которые в свою очередь выполняют много небольших задач . В 1950-х и 60-х годах програм- мисты понимали это на уровне инстинкта . Но в 1970-е годы про это просто-напросто забыли .
А почему забыли? Полагаю, что так произошло из-за неравно- мерности . Количество программистов в мире стало резко расти в 1970-х годах . До этого в мире было всего несколько тысяч про- граммистов . Но потом их количество резко выросло до сотен ты- сяч . Сейчас их число достигает сотни миллионов .
Те самые программисты 1950-х и 60-х годов были взрослыми . Они стали программистами лет в 30, 40 или даже в 50 . К 1970-м годам, когда программистов вдруг стало тьма-тьмущая, эти «старички» ушли на пенсию . Поэтому некому было обучать новое поколение программистов . Молодые программисты от 20 лет и старше начали работать как раз тогда, когда более опытные ребята уже начали уходить, поэтому их опыт не передавался эффективно .
17
Введение
Некоторые скажут, что с этого события в программировании на- чалось смутное время . На протяжении 30 лет мы боролись за идею, которая гласила, что следует выполнять большую работу в боль- ших командах, совершенно не осознавая, что секрет успеха — это выполнение большого количества мелких задач множеством не- больших команд .
Затем, в середине 1990-х, наконец было переосмыслено то, что было упущено . Идея работы в небольших командах получила но- вую жизнь . Эта идея распространилась в сообществе разработчи- ков программного обеспечения и набирала обороты . В 2000-х мы поняли наконец, что нужно перезагрузить всю отрасль целиком .
Теперь нам нужно вспомнить то, что знали те, кто были до нас, на уровне инстинкта . Нам еще раз потребовалось понять, что крупные задачи выполняются небольшими командами, которые сотруд- ничают между собой в решении небольших задач . Мы подумали, что идея, у которой есть имя, больше привлечет внимания . И мы назвали ее Agile .
Я написал это введение в самом начале 2019-го . Прошло уже около двух десятилетий с перезагрузки 2000-х годов, и, кажется, пришло время для еще одной .
Почему? Да потому, что простое и маленькое послание Agile за эти годы потеряло свою суть . Его перемешали с концепциями
Lean, Kanban, LeSS, SAFe, Modern, Skilled и многими другими .
Перечисленные идеи тоже по-своему хороши, но это все равно не Agile .
Вот и пришло время, чтобы напомнить нам то, о чем знали наши предки в 1950-х и 60-х годах, и о том, что мы вновь усвоили в на- чале 2000-х . Пора вспомнить, что такое Agile на самом деле .
Введение
В этой книге вы не найдете ничего особенно нового, поражающего или изумляющего . Никаких революций, ломающих привычные шаблоны . То, что вы узнаете отсюда об Agile, — это то, о чем уже го- ворилось в 2000-х . Хотя нет . Тут говорится с другой точки зрения .
Ведь за 20 лет, которые прошли за это время, мы усвоили что-то новое, и это включено в книгу . Но в целом посыл этой книги тот же, что и в 2001-м, и в 1950-м .
Посыл стар как мир . Но тем не менее это истина . Этот посыл предлагает нам небольшую идею для решения небольших задач, поставленных небольшими командами программистов, которые выполняют небольшую работу .
БЛАГОДАРНОСТИ
Первая моя благодарность — двум отважным программистам, кото- рые не без удовольствия открыли (а может, и заново открыли) ме- тоды, изложенные в этой книге, — Уорду Каннингему и Кенту Беку .
Следующую благодарность выражаю Мартину Фаулеру . Без его твердой руки революция, произведенная Agile, могла так и не увидеть свет .
Кен Швабер заслуживает особого упоминания за его неукротимую энергию в продвижении и внедрении Agile .
Мэри Поппендик также заслуживает отдельного упоминания за самоотверженность и неиссякаемую энергию, которую она вкла- дывала в движение Agile, и ее заботу об Agile Alliance .
На мой взгляд, Рон Джеффрис благодаря своим выступлениям, статьям, блогам и теплоте своего характера может считать себя совестью в начале движения Agile .
Майк Бидл отлично отстаивал честь Agile, однако погиб ни за что от рук бездомного на улицах Чикаго .
Прочим авторам оригинального Манифеста Agile здесь также отво- дится отдельное место . Перечислю их: Ари ван Беннекум, Алистер
Благодарности
20
Кокберн, Джеймс Греннинг, Джим Хайсмит, Эндрю Хант, Джон
Керн, Брайан Марик, Стив Меллор, Джефф Сазерленд и Дейв Томас .
Джим Ньюкирк, мой друг и деловой партнер, в то время без устали работал в поддержку Agile вопреки личным трудностям, которые большинство из нас (и я в том числе, безусловно) не могут даже представить .
Также я хочу упомянуть людей, работавших в корпорации Object
Mentor Inc . Они приняли на себя основные риски по внедрению и продвижению Agile . Многие из них присутствуют ниже на фото, которое было сделано в начале первых уроков курса XP Immersion .
Задний ряд: Рон Джеффрис, я (автор), Брайан Баттон, Лоуэлл
Линдстрем, Кент Бек, Мика Мартин, Анжелика Мартин, Сьюзен Россо,
Джеймс Греннинг. Передний ряд: Дэвид Фарбер, Эрик Мид, Майк
Хилл, Крис Бигей, Алан Фрэнсис, Дженнифер Конке, Талиша
Джефферсон, Паскаль Рой. Не присутствуют: Тим Оттингер, Джефф
Лэнгр, Боб Косс, Джим Ньюкирк, Майкл Фезерс, Дин Уэмплер и Дэвид
Хелимски
Благодарности
Также я хочу упомянуть ребят, которые смогли собраться и сфор- мировать альянс Agile Alliance . Некоторых из них можно увидеть ниже на фото — оно было сделано в начале заседания альянса в нынешнем августе .
Слева направо: Мэри Поппендик, Кен Швабер, автор, Майк Бидл,
Джим Хайсмит (не присутствует: Рон Крокер)
Наконец, спасибо всем ребятам из Pearson, в особенности моему издателю Джули Файфер .
ОБ АВТОРЕ
Роберт С . Мартин (Дядя Боб) является практикующим програм- мистом с 1970 года . Он является также соучредителем cleancoders.
com
, где представлены различные видеоуроки для разработчиков программного обеспечения, учредителем компании Uncle Bob
Consulting LLC, оказывающей услуги по консультированию, под- готовке и развитию навыков крупным корпорациям по всему миру .
Был высококлассным специалистом в консалтинговой компании, занимающейся отраслью программного обеспечения, 8th Light Inc ., расположенной в Чикаго .
Боб Мартин написал десятки статей для различных профессио- нальных журналов и систематически выступает на международ- ных конференциях и выставках . Он также является создателем известных образовательных видео на cleancoders .com . Боб Мартин является автором и редактором многих книг, в том числе:
23
Об авторе
«Разработка объектно-ориентированных приложений на C++ по
методу Буча» (Designing Object-Oriented C++ Applications Using
the Booch Method)
«Языки паттернов в процессе создания программ 3» (Patterns
Languages of Program Design 3)
«Еще больше сокровищ C++» (More C++ Gems)
«Экстремальное программирование на практике» (Extreme Pro-
gram ming in Practice)
«Быстрая разработка программ. Принципы, примеры, практи-
ка» (Agile Software Development: Principles, Patterns, and Practices)
«UML для программистов на Java» (UML for Java Pro gram mers)
«Чистый код»
1
«Идеальный программист»
2
«Чистая архитектура»
3
Лидер в отрасли разработки программного обеспечения, г-н Мар- тин три года был главным редактором журнала C++ Report, а так- же первым председателем Agile Alliance .
1
Мартин Р . Чистый код: создание, анализ и рефакторинг . — СПб .: Питер,
2018 . — 464 с .: ил .
2
Мартин Р . Идеальный программист . Как стать профессионалом разработки
ПО . — СПб .: Питер, 2019 . — 224 с .: ил .
3
Мартин Р . Чистая архитектура . Искусство разработки программного обес- печения . — СПб .: Питер, 2020 . — 352 с .: ил . .
Об авторе
ОТ ИЗДАТЕЛЬСТВА
Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com
(издательство «Питер», компьютерная редакция) .
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информа цию о наших книгах .
1
ВВЕДЕНИЕ В AGILE
Глава 1. Введение в Agile
26
В феврале 2001-го группа из семнадцати экспертов в области раз- работки программного обеспечения собралась в городке Сноуберд, штат Юта . На собрании обсуждалось плачевное состояние отрас- ли . Тогда большинство программ создавалось посредством неэф- фективных тяжеловесных фреймворков с большим количеством ритуалов, наподобие каскадной модели и раздутых реализаций
Rational Unified Process (RUP) . Целью этих экспертов было со- здание манифеста, который провозглашал бы более эффективный и легковесный подход .
Нельзя сказать, что царило единодушие . У всех семнадцати был разный опыт и, соответственно, сильные расхождения во мнениях .
Рассчитывать, что такое собрание быстро придет к общему мне- нию, было бы слишком наивно . И все же, несмотря на все трудно- сти, согласие было достигнуто, и Манифест Agile увидел свет — так родилось одно из самых мощных и живучих движений в отрасли программного обеспечения .
В этой отрасли практически все движения происходят по одному и тому же пути . Поначалу есть меньшинство, восторженно высту- пающее в поддержку чего-либо, другое меньшинство заряженных критиков и подавляющее большинство — те, кому, мягко говоря, нет дела .
Многие из этих движений хиреют или никогда не проходят этот этап . Можно вспомнить аспектно-ориентированное программи- рование, логическое программирование или CRC-карты . Неко- торые, однако, способны преодолеть такую пропасть, становясь чрезвычайно популярными и разносторонними . Некоторым уда- ется оставить позади противоречия и занять господствующее положение в современной мысли . Объектно-ориентированное мышление можно считать примером последнего случая . И Agile тоже .
История Agile
27
К сожалению, как только движение набирает последователей и начинает распространяться, то сталкивается с искажением и не- законным присваиванием . Продукция и методики, не имеющие ничего общего с оригинальным движением, присваивают чужое имя, чтобы нажиться на его славе и значимости . Так случилось и с Agile .
Эта книга, написанная спустя почти два десятка лет после событий в Сноуберде, ставит своей целью точно передать посыл идеи . Эта книга — попытка в высшей мере кратко и точно описать Agile без брехни и обиняков .
В ней представлены основные принципы Agile . В приукрашива- нии и расширении этих идей нет ничего плохого . Тем не менее производные от Agile — это уже не сам Agile . Это дополненный
Agile со своими опциями . А то, о чем вы узнаете из этой книги, — это и есть тот самый чистый Agile, который всегда был и непре- менно будет .
ИСТОРИЯ AGILE
Когда зародился Agile? Вероятно, более 50 тысяч лет назад, когда люди впервые решили работать совместно ради общей цели . Идея постановки небольших промежуточных целей и измерения про- движения после их достижения у человека проявляется на под- сознательном уровне, поэтому вряд ли это какая-то настоящая революция .
Когда впервые появился Agile в современном мире? Трудно ска- зать . В моем представлении, первый паровой двигатель, первая мельница, первый двигатель внутреннего сгорания, первый само- лет были созданы с помощью методик, которые сейчас можно от-
Глава 1. Введение в Agile
28
нести к Agile . Я считаю так, потому что предпринимать небольшие измеряемые шаги очень естественно для человека, сложно пред- ставить, что это происходит иначе .
Так когда же Agile появился среди программистов? Хотел бы я быть мухой на стене у Алана Тьюринга, когда тот писал свою книгу в 1936 году
1
. По моим догадкам, многие свои «программы» он написал, разбивая работу на мелкие этапы с изобилием отладки по исходному тексту вручную .
Я также хорошо представляю, что первый код, который он на- писал для автоматической вычислительной машины (Automatic
Computing Engine, ACE) в 1946 году, был написан постепенно, маленькими этапами, с частым проведением ручной отладки по исходному тексту и даже с небольшим тестированием в дей- ствии .
В первые дни существования программного обеспечения можно найти много примеров решения задач, которые сейчас бы отнесли к Agile . Например, программисты, писавшие код для управления пилотируемым космическим кораблем «Меркурий», работали по этапам с интервалом в полдня с перерывами на модульное тести- рование .
Об этом периоде есть много материалов . Крэг Ларман и Вик Ба- зили написали историю, которая кратко изложена в «вики» Уорда
1
Turing A. M . 1936 . On computable numbers, with an application to the
Entscheidungsproblem [доказательство] . Proceedings of the London
Mathematical Society (Труды Лондонского математического общества),
2 (изд . 1937), 42(1):230–65 . — Лучший способ ознакомиться с этой рабо- той — прочитать произведение Чарльза Петцольда: Petzold C . The Annotated
Turing: A Guided Tour through Alan Turing’s Historic Paper on Computability and the Turing Machine . Indianapolis, Indiana: Wiley, 2008 .
История Agile
29
Каннингема
1
, а также в книге Лармана Agile & Iterative Development:
A Manager's Guide
2
Однако существовал не только Agile . Действительно, есть кон- курирующая методология, которая пользовалась значительным успехом в производстве и промышленности в целом: научная организация труда .
Научная организация труда — это командно-административный подход с иерархической структурой . Менеджеры применяют на- учную организацию труда, чтобы определять наилучший набор процедур для достижения цели и отдавать распоряжения всем под- чиненным для выполнения плана с точностью до буквы . Другими словами, сначала планируется крупная задача, затем проводится тщательная и подробная проработка плана .
Научная организация труда, вероятно, такая же древняя, как пира- миды в Египте, Стоунхендж или прочие подобные работы древних времен: с трудом верится, что можно работать по-другому . Еще раз замечу, идея повторять успешный опыт настолько глубоко подсо- знательно заложена в человеке, что ее сложно охарактеризовать как революционную .
Научная организация труда получила свое название из работ
Фредерика Уинслоу Тейлора, написанных в 1880-х . Тейлор сфор- мировал этот подход, придав ему коммерческую ценность и сделав состояние на консультировании по управлению . Метод получил широкий успех и привел к значительному повышению эффектив- ности и производительности в последующие десятилетия .
1
«Вики» Уорда, c2.com
— сайт оригинальной «Википедии», первый день по- явления в сети Интернет . Пусть поддержка длится как можно дольше .
2
Larman C . Agile & Iterative Development: A Manager’s Guide . Boston,
Massachusetts: Addison-Wesley, 2004 .
Глава 1. Введение в Agile
30
И так случилось в 1970-е, что мир разработчиков программного обеспечения разделился на два лагеря — сторонников того или иного метода . Прото-Agile (Agile, еще не получивший название
«Agile») предлагал предпринимать в зависимости от обстоятельств небольшие случайные шаги, которые можно измерить и выделить, для того чтобы идти в правильном направлении к наилучшему ис- ходу . Научная организация труда призывала откладывать действие до тщательного анализа и проработки заранее подготовленного плана . Прото-Agile прекрасно подходил для проектов с низкой стоимостью внесения изменений, которые решали частично опре- деленные задачи с произвольно поставленными целями .
Научная организация труда лучше всего подходила для проектов, которые решали четко определенные задачи с весьма определенны- ми целями . И в них стоимость изменений уже возрастала . Какими были проекты в отрасли разработки программного обеспечения?
Была ли в этих проектах стоимость изменений высока? Были ли задачи определены четко? Или стоимость изменений была низкой, а цели были поставлены произвольно?
Не вчитывайтесь слишком внимательно в предыдущий абзац . На- сколько я знаю, никто не задавался такими вопросами . Иронично и то, что путь, выбранный в 1970-х годах, кажется, был обусловлен, скорее, волей случая .
В 1970 году Уинстон Ройс в своей работе
1
описал идеи для управ- ления крупномасштабными проектами по разработке программ- ного обеспечения . В этой работе присутствовала схема (рис . 1 .1), которая наглядно изображала его план . Ройс не был автором этой
1
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.
История Agile
31
Исполь- зование
Тестиро- вание
Написание кода
Проекти- рование
Анализ
Разработка требова- ний к ПО
Разработка системных требований
Рис. 1.1. Схема Уинстона Ройса, которая стала источником вдохновения для разработки каскадной модели схемы и не продвигал ее в качестве плана . В действительности график представлял собой изображение соломенного человечка и помогал Ройсу ориентироваться в последующих страницах сво- его труда .
Схема была расположена на видном месте . А учитывая, что люди делают логические выводы о содержании статьи, посмотрев схему на первой или второй странице, это привело к резкому сдвигу в от- расли программного обеспечения .
Схема, первоначально составленная Ройсом, гораздо больше на- поминала ручей, стекающий вниз со скалистого хребта, чем ныне известную каскадную модель .
Глава 1. Введение в Agile
32
Каскадная модель стала логическим продолжением научной орга- низации труда . При использовании этой модели на первый план ставится тщательный анализ, составление подробного плана, а за- тем уже доведение этого плана до завершения . Хотя Ройс и не рекомендовал такой подход, но именно эту концепцию вынесли из его работы . А потом эта концепция главенствовала в отрасли более трех десятков лет
1
Как раз тогда и начинается моя история . В 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 я писал только на ассемблере .
Важно помнить, каково в то время было программистам . Мы писали код в программных формулярах с помощью карандашей .
У нас были операторы, работающие за перфоратором, которые наносили программы на карты . Мы передавали тщательно выве- ренные перфокарты операторам ЭВМ, которые проводили ком- пиляцию и тестирование в третью смену, поскольку днем, когда работа кипела, компьютеры были постоянно заняты . От начала написания кода до первой компиляции зачастую проходило не- сколько дней, каждый цикл разработки вследствие этого занимал, как правило, сутки .
1
Стоит отметить, что мое толкование этой временной шкалы подвергли сомнениям . См .: Bossavit L. The Leprechauns of Software Engineering: How
Folklore Turns into Fact and What to Do About It, Ch . 7 . Leanpub, 2012 .
История Agile
33
Для меня 620/f выглядел несколько иначе . Эту машину выделили нашей команде, поэтому мы могли работать на ней столько, сколь- ко вздумается . Мы проводили два, три, иногда даже четыре цикла разработки и тестирования за сутки . Вместе со мной в команде были люди, которые, в отличие от большинства программистов того времени, умели печатать . Поэтому мы могли штамповать свои собственные колоды перфокарт, а не зависеть от капризов опера- торов, работающих за перфоратором .
Какую методологию мы использовали на протяжении того вре- мени? Это, конечно, была не каскадная модель . У нас не было концепций или подробных планов . Мы просто писали код каждый день, компилировали, тестировали и устраняли ошибки . Это был бесконечный цикл без структуры . Также это был не Agile и даже не прото-Agile . В ходе работ мы не придерживались каких-либо пра- вил организации . Тогда не было каких-либо пакетов программ для тестирования и измеряемых временных интервалов . Просто надо было писать код и фиксить баги . День за днем, месяц за месяцем .
Впервые я узнал о каскадной модели из профессиональных журна- лов около 1972 года . Мне она казалась даром свыше . Неужели мы могли бы проанализировать задачу, потом предложить ее решение, а затем реализовать замысел? Реально ли было на самом деле раз- работать график, основанный на трех перечисленных этапах?
Неужели, когда выполнен анализ, проект продвинется вперед на треть? Я почувствовал силу этой концепции . Я хотел в это верить .
Если идея сработает, то мечта воплотится .
Судя по всему, я был не один, потому что многие другие програм- мисты и центры программирования тоже вошли в кураж . И, как я уже писал, в нашем мышлении начала преобладать каскадная модель .
Глава 1. Введение в Agile
34
Она преобладала, но не работала . В течение последующих тридца- ти лет мои коллеги, я, братья и сестры по программированию по всему миру неустанно старались получить право на проведение анализа и проектирование . Но каждый раз, когда мы думали, что получали желаемое, оно ускользало из наших рук на этапе реали- зации . Месяцы тщательного планирования пошли прахом из-за необходимости сделать безумный рывок, в итоге мы сорвали сроки под свирепыми взглядами менеджеров и заказчиков .
Несмотря на практически нескончаемый поток неудач, мы все равно настаивали на состоятельности каскадной модели . В конце концов, почему возникали неудачи? Почему тщательный анализ задачи, внимательное проектирование решения и последующая ре- ализация нескончаемо терпят зрелищный крах? Никто даже поду- мать не мог, что дело было в самой стратегии . Задача должна была лечь на наши плечи . Как бы то ни было, что-то мы делали не так .
Чтобы увидеть, насколько каскадная модель захватила наши умы, посмотрите на программные языки того времени . Когда Дейкстра в 1968 году представил структурное программирование, структур- ный анализ
1
и структурный дизайн
2
не сильно отставали . В 1988 году, когда объектно-ориентированное программирование (ООП) набрало популярность, объектно-ориентированный анализ
3
и объ- ектно-ориентированное проектирование
4
также не сильно отста-
1
DeMarco T. Structured Analysis and System Specification . Upper Saddle River,
New Jersey: Yourdon Press, 1979 .
2
Page-Jones M. The Practical Guide to Structured Systems Design . Englewood
Cliffs, New Jersey: Yourdon Press, 1980 .
3
Coad P., Yourdon E . Object-Oriented Analysis . Englewood Cliffs, New Jersey:
Yourdon Press, 1990 .
4
Booch G . Object Oriented Design with Applications . Redwood City, California:
Benjamin-Cummings Publishing Co ., 1991 .
История Agile
35
вали . Эта тройка идей, эти три этапа словно держали нас в плену .
Мы просто не могли представить, что можно работать как-то по- другому .
А потом оказалось, что можно .
Зародыши преобразований, связанных с Agile, появились в конце
1980-х или в начале 90-х . В сообществе Smalltalk их признаки начали проявляться в 1980-х . В книге Буча по объектно-ориен- тированному проектированию, вышедшей в 1991-м, были намеки на них
10
. Прочие решения возникли в 1991 г . в книге Кокберна
Crystal Methods . Сообщество Design Patterns начало обсуждать это в 1994-м под влиянием статьи, написанной Джеймсом Ко- плиеном
1
К 1995 году Бидл
2
, Девос, Шэрон, Швобер и Сазерленд написали свои знаменитые труды о Scrum (Скрам)
3
. И затворы открылись .
На бастионе каскадной модели образовалась брешь, и пути назад не было .
И здесь я снова возвращаюсь к нашей истории . То, что я расскажу дальше, — мои личные воспоминания, я не сверял их ни с кем из современников, участников событий . Поэтому следует предполо- жить, что в моих воспоминаниях много опущений, недостоверно-
1
Coplien J. O. A generative development-process pattern language . Pattern
Languages of Program Design . Reading, Massachusetts: Addison-Wesley, 1995 .
P . 183 .
2
Майк Бидл был убит 23 марта 2018 года в Чикаго психически нездоровым человеком, до этого арестованным и отпущенным 99 раз, который должен был находиться в психбольнице . Майк Бидл был моим другом .
3
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.
Глава 1. Введение в Agile
36
стей или изложены они ужасно беспорядочно . Но не переживайте, я по крайней мере постарался рассказать все занимательно .
В первый раз мы встретились с Кентом Беком в 1994 году на той самой конференции PLoP
1
, когда Коплин представил свою работу .
Это была неформальная встреча, которая толком ничего не принес- ла . В следующий раз я встретил его в феврале 1999-го в Мюнхене на конференции, посвященной ООП . Но к тому времени я уже знал о нем намного больше .
В то время я занимался консультированием по C++ и объектно- ориентированному проектированию, летал с места на место, по- могал разрабатывать и реализовывать приложения на C++ с по- мощью методик объектно-ориентированного проектирования .
Клиенты стали расспрашивать меня о процессе . Они слышали, что каскадная модель не применяется в объектно-ориентированном про- ектировании, и хотели услышать от меня совет . Я согласился с ними
2
и стал дальше думать об этом, мысли захватывали меня все сильнее .
Я даже подумывал написать свою собственную объектно-ориенти- рованную методологию . К счастью, я скоро прекратил эти попытки, поскольку мне в руки попали труды Кента Бека по экстремальному программированию (XP) .
Чем больше я читал об экстремальном программировании, тем больше я увлекался им . Идеи были революционны (по крайней
1
Pattern Languages of programming — конференция, которую проводили в 1990-х неподалеку от университета штата Иллинойс .
2
Это одно из тех странных совпадений, которые происходят время от време- ни . Нет ничего такого особенного в объектно-ориентированном програм- мировании, что не дает применять в нем каскадную модель, тем не менее эта идея набирала в те дни популярность .
История Agile
37
мере, я тогда так думал) . Они казались разумными, особенно в контексте объектно-ориентированного мышления (опять же на тот момент я думал именно так) . Мне не терпелось узнать больше .
К моему удивлению, на той самой конференции в Мюнхене, посвя- щенной объектно-ориентированному программированию, я заме- тил, что через зал от меня читает лекцию сам Кент Бек . Как-то раз во время перерыва я натолкнулся на него и предложил встретиться как-нибудь за завтраком, чтобы обсудить экстремальное програм- мирование . На том завтраке был заложен фундамент для плодо- творного партнерства . Наши обсуждения побудили меня полететь к нему в Медфорд, штат Орегон, чтобы совместно разрабатывать курс по экстремальному программированию .
В ходе этого визита я впервые попробовал поучаствовать в раз- работке через тестирование, и это меня увлекло .
В то время под моим управлением была компания Object Mentor .
В сотрудничестве с Кентом Беком мы хотели предложить пяти- дневный учебный курс по экстремальному программированию, который назывался XP Immersion . С конца 1999-го по 11 сентября
2001 года
1
он производил настоящий фурор! Мы обучили сотни человек .
Летом 2000 года Кент Бек созвал кворум из сообщества по экс- тремальному программированию и паттернам . Встреча проходила недалеко от его дома . Он назвал ее встречей ведущих специалистов в области экстремального программирования . Мы катались на лодках и прогуливались по берегу реки Рог . И заодно решали, что делать дальше с экстремальным программированием .
1
Этот день очень значим, поэтому его стоило упомянуть .
1 2 3 4 5 6 7 8 9 ... 20
История Agile
27
К сожалению, как только движение набирает последователей и начинает распространяться, то сталкивается с искажением и не- законным присваиванием . Продукция и методики, не имеющие ничего общего с оригинальным движением, присваивают чужое имя, чтобы нажиться на его славе и значимости . Так случилось и с Agile .
Эта книга, написанная спустя почти два десятка лет после событий в Сноуберде, ставит своей целью точно передать посыл идеи . Эта книга — попытка в высшей мере кратко и точно описать Agile без брехни и обиняков .
В ней представлены основные принципы Agile . В приукрашива- нии и расширении этих идей нет ничего плохого . Тем не менее производные от Agile — это уже не сам Agile . Это дополненный
Agile со своими опциями . А то, о чем вы узнаете из этой книги, — это и есть тот самый чистый Agile, который всегда был и непре- менно будет .
ИСТОРИЯ AGILE
Когда зародился Agile? Вероятно, более 50 тысяч лет назад, когда люди впервые решили работать совместно ради общей цели . Идея постановки небольших промежуточных целей и измерения про- движения после их достижения у человека проявляется на под- сознательном уровне, поэтому вряд ли это какая-то настоящая революция .
Когда впервые появился Agile в современном мире? Трудно ска- зать . В моем представлении, первый паровой двигатель, первая мельница, первый двигатель внутреннего сгорания, первый само- лет были созданы с помощью методик, которые сейчас можно от-
Глава 1. Введение в Agile
28
нести к Agile . Я считаю так, потому что предпринимать небольшие измеряемые шаги очень естественно для человека, сложно пред- ставить, что это происходит иначе .
Так когда же Agile появился среди программистов? Хотел бы я быть мухой на стене у Алана Тьюринга, когда тот писал свою книгу в 1936 году
1
. По моим догадкам, многие свои «программы» он написал, разбивая работу на мелкие этапы с изобилием отладки по исходному тексту вручную .
Я также хорошо представляю, что первый код, который он на- писал для автоматической вычислительной машины (Automatic
Computing Engine, ACE) в 1946 году, был написан постепенно, маленькими этапами, с частым проведением ручной отладки по исходному тексту и даже с небольшим тестированием в дей- ствии .
В первые дни существования программного обеспечения можно найти много примеров решения задач, которые сейчас бы отнесли к Agile . Например, программисты, писавшие код для управления пилотируемым космическим кораблем «Меркурий», работали по этапам с интервалом в полдня с перерывами на модульное тести- рование .
Об этом периоде есть много материалов . Крэг Ларман и Вик Ба- зили написали историю, которая кратко изложена в «вики» Уорда
1
Turing A. M . 1936 . On computable numbers, with an application to the
Entscheidungsproblem [доказательство] . Proceedings of the London
Mathematical Society (Труды Лондонского математического общества),
2 (изд . 1937), 42(1):230–65 . — Лучший способ ознакомиться с этой рабо- той — прочитать произведение Чарльза Петцольда: Petzold C . The Annotated
Turing: A Guided Tour through Alan Turing’s Historic Paper on Computability and the Turing Machine . Indianapolis, Indiana: Wiley, 2008 .
История Agile
29
Каннингема
1
, а также в книге Лармана Agile & Iterative Development:
A Manager's Guide
2
Однако существовал не только Agile . Действительно, есть кон- курирующая методология, которая пользовалась значительным успехом в производстве и промышленности в целом: научная организация труда .
Научная организация труда — это командно-административный подход с иерархической структурой . Менеджеры применяют на- учную организацию труда, чтобы определять наилучший набор процедур для достижения цели и отдавать распоряжения всем под- чиненным для выполнения плана с точностью до буквы . Другими словами, сначала планируется крупная задача, затем проводится тщательная и подробная проработка плана .
Научная организация труда, вероятно, такая же древняя, как пира- миды в Египте, Стоунхендж или прочие подобные работы древних времен: с трудом верится, что можно работать по-другому . Еще раз замечу, идея повторять успешный опыт настолько глубоко подсо- знательно заложена в человеке, что ее сложно охарактеризовать как революционную .
Научная организация труда получила свое название из работ
Фредерика Уинслоу Тейлора, написанных в 1880-х . Тейлор сфор- мировал этот подход, придав ему коммерческую ценность и сделав состояние на консультировании по управлению . Метод получил широкий успех и привел к значительному повышению эффектив- ности и производительности в последующие десятилетия .
1
«Вики» Уорда, c2.com
— сайт оригинальной «Википедии», первый день по- явления в сети Интернет . Пусть поддержка длится как можно дольше .
2
Larman C . Agile & Iterative Development: A Manager’s Guide . Boston,
Massachusetts: Addison-Wesley, 2004 .
Глава 1. Введение в Agile
30
И так случилось в 1970-е, что мир разработчиков программного обеспечения разделился на два лагеря — сторонников того или иного метода . Прото-Agile (Agile, еще не получивший название
«Agile») предлагал предпринимать в зависимости от обстоятельств небольшие случайные шаги, которые можно измерить и выделить, для того чтобы идти в правильном направлении к наилучшему ис- ходу . Научная организация труда призывала откладывать действие до тщательного анализа и проработки заранее подготовленного плана . Прото-Agile прекрасно подходил для проектов с низкой стоимостью внесения изменений, которые решали частично опре- деленные задачи с произвольно поставленными целями .
Научная организация труда лучше всего подходила для проектов, которые решали четко определенные задачи с весьма определенны- ми целями . И в них стоимость изменений уже возрастала . Какими были проекты в отрасли разработки программного обеспечения?
Была ли в этих проектах стоимость изменений высока? Были ли задачи определены четко? Или стоимость изменений была низкой, а цели были поставлены произвольно?
Не вчитывайтесь слишком внимательно в предыдущий абзац . На- сколько я знаю, никто не задавался такими вопросами . Иронично и то, что путь, выбранный в 1970-х годах, кажется, был обусловлен, скорее, волей случая .
В 1970 году Уинстон Ройс в своей работе
1
описал идеи для управ- ления крупномасштабными проектами по разработке программ- ного обеспечения . В этой работе присутствовала схема (рис . 1 .1), которая наглядно изображала его план . Ройс не был автором этой
1
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.
История Agile
31
Исполь- зование
Тестиро- вание
Написание кода
Проекти- рование
Анализ
Разработка требова- ний к ПО
Разработка системных требований
Рис. 1.1. Схема Уинстона Ройса, которая стала источником вдохновения для разработки каскадной модели схемы и не продвигал ее в качестве плана . В действительности график представлял собой изображение соломенного человечка и помогал Ройсу ориентироваться в последующих страницах сво- его труда .
Схема была расположена на видном месте . А учитывая, что люди делают логические выводы о содержании статьи, посмотрев схему на первой или второй странице, это привело к резкому сдвигу в от- расли программного обеспечения .
Схема, первоначально составленная Ройсом, гораздо больше на- поминала ручей, стекающий вниз со скалистого хребта, чем ныне известную каскадную модель .
Глава 1. Введение в Agile
32
Каскадная модель стала логическим продолжением научной орга- низации труда . При использовании этой модели на первый план ставится тщательный анализ, составление подробного плана, а за- тем уже доведение этого плана до завершения . Хотя Ройс и не рекомендовал такой подход, но именно эту концепцию вынесли из его работы . А потом эта концепция главенствовала в отрасли более трех десятков лет
1
Как раз тогда и начинается моя история . В 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 я писал только на ассемблере .
Важно помнить, каково в то время было программистам . Мы писали код в программных формулярах с помощью карандашей .
У нас были операторы, работающие за перфоратором, которые наносили программы на карты . Мы передавали тщательно выве- ренные перфокарты операторам ЭВМ, которые проводили ком- пиляцию и тестирование в третью смену, поскольку днем, когда работа кипела, компьютеры были постоянно заняты . От начала написания кода до первой компиляции зачастую проходило не- сколько дней, каждый цикл разработки вследствие этого занимал, как правило, сутки .
1
Стоит отметить, что мое толкование этой временной шкалы подвергли сомнениям . См .: Bossavit L. The Leprechauns of Software Engineering: How
Folklore Turns into Fact and What to Do About It, Ch . 7 . Leanpub, 2012 .
История Agile
33
Для меня 620/f выглядел несколько иначе . Эту машину выделили нашей команде, поэтому мы могли работать на ней столько, сколь- ко вздумается . Мы проводили два, три, иногда даже четыре цикла разработки и тестирования за сутки . Вместе со мной в команде были люди, которые, в отличие от большинства программистов того времени, умели печатать . Поэтому мы могли штамповать свои собственные колоды перфокарт, а не зависеть от капризов опера- торов, работающих за перфоратором .
Какую методологию мы использовали на протяжении того вре- мени? Это, конечно, была не каскадная модель . У нас не было концепций или подробных планов . Мы просто писали код каждый день, компилировали, тестировали и устраняли ошибки . Это был бесконечный цикл без структуры . Также это был не Agile и даже не прото-Agile . В ходе работ мы не придерживались каких-либо пра- вил организации . Тогда не было каких-либо пакетов программ для тестирования и измеряемых временных интервалов . Просто надо было писать код и фиксить баги . День за днем, месяц за месяцем .
Впервые я узнал о каскадной модели из профессиональных журна- лов около 1972 года . Мне она казалась даром свыше . Неужели мы могли бы проанализировать задачу, потом предложить ее решение, а затем реализовать замысел? Реально ли было на самом деле раз- работать график, основанный на трех перечисленных этапах?
Неужели, когда выполнен анализ, проект продвинется вперед на треть? Я почувствовал силу этой концепции . Я хотел в это верить .
Если идея сработает, то мечта воплотится .
Судя по всему, я был не один, потому что многие другие програм- мисты и центры программирования тоже вошли в кураж . И, как я уже писал, в нашем мышлении начала преобладать каскадная модель .
Глава 1. Введение в Agile
34
Она преобладала, но не работала . В течение последующих тридца- ти лет мои коллеги, я, братья и сестры по программированию по всему миру неустанно старались получить право на проведение анализа и проектирование . Но каждый раз, когда мы думали, что получали желаемое, оно ускользало из наших рук на этапе реали- зации . Месяцы тщательного планирования пошли прахом из-за необходимости сделать безумный рывок, в итоге мы сорвали сроки под свирепыми взглядами менеджеров и заказчиков .
Несмотря на практически нескончаемый поток неудач, мы все равно настаивали на состоятельности каскадной модели . В конце концов, почему возникали неудачи? Почему тщательный анализ задачи, внимательное проектирование решения и последующая ре- ализация нескончаемо терпят зрелищный крах? Никто даже поду- мать не мог, что дело было в самой стратегии . Задача должна была лечь на наши плечи . Как бы то ни было, что-то мы делали не так .
Чтобы увидеть, насколько каскадная модель захватила наши умы, посмотрите на программные языки того времени . Когда Дейкстра в 1968 году представил структурное программирование, структур- ный анализ
1
и структурный дизайн
2
не сильно отставали . В 1988 году, когда объектно-ориентированное программирование (ООП) набрало популярность, объектно-ориентированный анализ
3
и объ- ектно-ориентированное проектирование
4
также не сильно отста-
1
DeMarco T. Structured Analysis and System Specification . Upper Saddle River,
New Jersey: Yourdon Press, 1979 .
2
Page-Jones M. The Practical Guide to Structured Systems Design . Englewood
Cliffs, New Jersey: Yourdon Press, 1980 .
3
Coad P., Yourdon E . Object-Oriented Analysis . Englewood Cliffs, New Jersey:
Yourdon Press, 1990 .
4
Booch G . Object Oriented Design with Applications . Redwood City, California:
Benjamin-Cummings Publishing Co ., 1991 .
История Agile
35
вали . Эта тройка идей, эти три этапа словно держали нас в плену .
Мы просто не могли представить, что можно работать как-то по- другому .
А потом оказалось, что можно .
Зародыши преобразований, связанных с Agile, появились в конце
1980-х или в начале 90-х . В сообществе Smalltalk их признаки начали проявляться в 1980-х . В книге Буча по объектно-ориен- тированному проектированию, вышедшей в 1991-м, были намеки на них
10
. Прочие решения возникли в 1991 г . в книге Кокберна
Crystal Methods . Сообщество Design Patterns начало обсуждать это в 1994-м под влиянием статьи, написанной Джеймсом Ко- плиеном
1
К 1995 году Бидл
2
, Девос, Шэрон, Швобер и Сазерленд написали свои знаменитые труды о Scrum (Скрам)
3
. И затворы открылись .
На бастионе каскадной модели образовалась брешь, и пути назад не было .
И здесь я снова возвращаюсь к нашей истории . То, что я расскажу дальше, — мои личные воспоминания, я не сверял их ни с кем из современников, участников событий . Поэтому следует предполо- жить, что в моих воспоминаниях много опущений, недостоверно-
1
Coplien J. O. A generative development-process pattern language . Pattern
Languages of Program Design . Reading, Massachusetts: Addison-Wesley, 1995 .
P . 183 .
2
Майк Бидл был убит 23 марта 2018 года в Чикаго психически нездоровым человеком, до этого арестованным и отпущенным 99 раз, который должен был находиться в психбольнице . Майк Бидл был моим другом .
3
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.
Глава 1. Введение в Agile
36
стей или изложены они ужасно беспорядочно . Но не переживайте, я по крайней мере постарался рассказать все занимательно .
В первый раз мы встретились с Кентом Беком в 1994 году на той самой конференции PLoP
1
, когда Коплин представил свою работу .
Это была неформальная встреча, которая толком ничего не принес- ла . В следующий раз я встретил его в феврале 1999-го в Мюнхене на конференции, посвященной ООП . Но к тому времени я уже знал о нем намного больше .
В то время я занимался консультированием по C++ и объектно- ориентированному проектированию, летал с места на место, по- могал разрабатывать и реализовывать приложения на C++ с по- мощью методик объектно-ориентированного проектирования .
Клиенты стали расспрашивать меня о процессе . Они слышали, что каскадная модель не применяется в объектно-ориентированном про- ектировании, и хотели услышать от меня совет . Я согласился с ними
2
и стал дальше думать об этом, мысли захватывали меня все сильнее .
Я даже подумывал написать свою собственную объектно-ориенти- рованную методологию . К счастью, я скоро прекратил эти попытки, поскольку мне в руки попали труды Кента Бека по экстремальному программированию (XP) .
Чем больше я читал об экстремальном программировании, тем больше я увлекался им . Идеи были революционны (по крайней
1
Pattern Languages of programming — конференция, которую проводили в 1990-х неподалеку от университета штата Иллинойс .
2
Это одно из тех странных совпадений, которые происходят время от време- ни . Нет ничего такого особенного в объектно-ориентированном програм- мировании, что не дает применять в нем каскадную модель, тем не менее эта идея набирала в те дни популярность .
История Agile
37
мере, я тогда так думал) . Они казались разумными, особенно в контексте объектно-ориентированного мышления (опять же на тот момент я думал именно так) . Мне не терпелось узнать больше .
К моему удивлению, на той самой конференции в Мюнхене, посвя- щенной объектно-ориентированному программированию, я заме- тил, что через зал от меня читает лекцию сам Кент Бек . Как-то раз во время перерыва я натолкнулся на него и предложил встретиться как-нибудь за завтраком, чтобы обсудить экстремальное програм- мирование . На том завтраке был заложен фундамент для плодо- творного партнерства . Наши обсуждения побудили меня полететь к нему в Медфорд, штат Орегон, чтобы совместно разрабатывать курс по экстремальному программированию .
В ходе этого визита я впервые попробовал поучаствовать в раз- работке через тестирование, и это меня увлекло .
В то время под моим управлением была компания Object Mentor .
В сотрудничестве с Кентом Беком мы хотели предложить пяти- дневный учебный курс по экстремальному программированию, который назывался XP Immersion . С конца 1999-го по 11 сентября
2001 года
1
он производил настоящий фурор! Мы обучили сотни человек .
Летом 2000 года Кент Бек созвал кворум из сообщества по экс- тремальному программированию и паттернам . Встреча проходила недалеко от его дома . Он назвал ее встречей ведущих специалистов в области экстремального программирования . Мы катались на лодках и прогуливались по берегу реки Рог . И заодно решали, что делать дальше с экстремальным программированием .
1
Этот день очень значим, поэтому его стоило упомянуть .
1 2 3 4 5 6 7 8 9 ... 20