скачать книгу бесплатно
Чистый Agile. Основы гибкости
Роберт С. Мартин
Библиотека программиста (Питер)
Прошло почти двадцать лет с тех пор как появился Манифест Agile. Легендарный Роберт Мартин (Дядя Боб) понял, что пора стряхнуть пыль с принципов Agile, и заново рассказать о гибком подходе не только новому поколению программистов, но и специалистам из других отраслей. Автор полюбившихся айтишникам книг «Чистый код», «Идеальный программист», «Чистая архитектура» стоял у истоков Agile. «Чистый Agile» устраняет недопонимание и путаницу, которые за годы существования Agile усложнили его применение по сравнению с изначальным замыслом.
По сути Agile – это всего лишь небольшая подборка методов и инструментов, помогающая небольшим командам программистов управлять небольшими проектами,… но приводящая к большим результатам, потому что каждый крупный проект состоит из огромного количества кирпичиков. Пять десятков лет работы с проектами всех мыслимых видов и размеров позволяют Дяде Бобу показать, как на самом деле должен работать Agile.
Если вы хотите понять преимущества Agile, не ищите лёгких путей – нужно правильно применять Agile. «Чистый Agile» расскажет, как это делать разработчикам, тестировщикам, руководителям, менеджерам проектов и клиентам.
Роберт Мартин
Чистый Agile. Основы гибкости
Robert C. Martin
Clean Agile. Back to Basics
© 2020 Pearson Education, Inc.
© Перевод на русский язык ООО Издательство «Питер», 2020
© Издание на русском языке, оформление ООО Издательство «Питер», 2020
© Серия «Библиотека программиста», 2020
* * *
Отзывы на книгу «Чистый Agile»
Проделав огромный путь, Agile, не без помощи того самого Дяди Боба, достиг вершин. Безусловно, эта история знает свои взлеты и падения. Восхитительная книга, которую вы сейчас держите в руках, сочетает в себе историческую хронику и мемуары. Вся мудрость Agile собрана здесь. Если вам интересно, что такое Agile и как он появился, – эта книга для вас.
Гради Буч
Разочарования Дяди Боба пронизывают каждую строку «Чистого Agile», но, поверьте, эти разочарования оправданны. Все, что создано в мире Agile, – просто капля в море по сравнению с тем, что еще можно из него сотворить. Эта книга – взгляд Дяди Боба на перспективу. Его вклад велик. Его стоит послушать.
Кент Бек
Полезно почитать о том, что Дядя Боб думает об Agile. Может быть, вы новичок, а может, уже матерый спец – в любом случае вы найдете в этой книге что-то для себя. Я подписываюсь почти под каждым словом в ней. В некоторых главах я вижу свои собственные недостатки, что греха таить. Теперь я проверяю наш код дважды, а это 85,09 %.
Джон Керн
В этой книге, словно под увеличительным стеклом, можно в подробностях разглядеть методологию Agile. Дядя Боб, несомненно, один из умнейших людей, которых я знаю. Его рвение к программированию бесконечно. Он как никто другой может развеять мистический туман, сгустившийся над Agile.
Из предисловия Джерри Фицпатрика
Всем программистам, кто хоть раз боролся с ветряными мельницами или водопадами
Предисловие
Так что же такое методология гибкой разработки Agile? Как появилась на свет? Как эволюционировала?
В этой книге Дядя Боб дает глубокомысленные ответы на эти вопросы. А еще рассказывает о разных способах неправильного или искаженного понимания методологии Agile. Его взгляды очень важны, поскольку он авторитет в этой области. Ведь именно с его именем связано появление Agile.
Мы дружим с Бобом уже не один год. Впервые я встретил его в 1979-м, когда устроился на работу в отдел телекоммуникаций компании Teradyne. Я был инженером-электриком, моя работа заключалась в том, что я помогал устанавливать и обслуживать нашу продукцию. Позже я вырос до разработчика аппаратных средств.
Где-то спустя год моей работы в компании стали искать новые идеи для своей продукции. В 1981-м мы с Бобом выдвинули идею создания электронного телефонного администратора – по сути дела, он представлял собой службу голосовой почты с функцией переадресации вызовов. В компании нашу концепцию приняли с одобрением, и вскоре мы приступили к разработке E.R. – электронного администратора (The Electronic Receptionist). Прототип получился шедевральным. Он работал под управлением операционной системы MP/M на базе процессора Intel 8086. Голосовые сообщения хранились на пятимегабайтовом винчестере Seagate ST-506. Я занимался разработкой порта для передачи голоса, а Боб писал приложение. Закончив разработку, я тоже написал часть кода приложения. Поэтому с тех пор я еще и разработчик.
То ли в 1985-м, то ли в 1986-м Teradyne неожиданно остановила разработку E.R. и без нашего ведома отозвала заявку на патент. Компания вскоре пожалела о принятом решении, а мы с Бобом жалеем и по сей день.
В конце концов мы ушли из Teradyne в поисках лучшей доли. Боб занялся консалтинговым бизнесом в районе Чикаго. Я же стал преподавателем и ударился в разработку программ. Мы умудрялись не терять друг друга из виду даже после моего переезда в другой штат.
К 2000 году я преподавал объектно-ориентированный анализ и проектирование в Learning Tree International. Курс включал в себя преподавание UML и унифицированный процесс разработки (USDP). Тогда я уже поднаторел в этих технологиях, однако ничего не понимал в Scrum, экстремальном программировании и прочих методиках.
А в феврале 2001 года появился Манифест Agile. Моя реакция была примерно как у всех: «Что еще за Agile?» Единственный манифест, о котором я знал, – это Манифест Коммунистической партии, составленный Карлом Марксом и Фридрихом Энгельсом. Этот Agile призывал взяться за оружие? Чертовы айтишные радикалы!
Манифест породил массы бунтарей. Он вдохновил программистов на создание лаконичного чистого кода посредством совместной адаптивной работы с отлаженной обратной связью. Они выглядели заманчивой альтернативой тяжеловесным процессам вроде каскадной модели и USDP.
Прошло уже 18 лет, как был обнародован Манифест. Для большинства современных разработчиков все это история древнего мира. Именно поэтому ваше понимание Agile может отличаться от представлений его основателей.
Эта книга ставит своей целью точно передать посыл идеи. В этой книге, словно под увеличительным стеклом, можно в подробностях разглядеть методологию Agile. Дядя Боб, несомненно, один из умнейших людей, которых я знаю. Его рвение к программированию бесконечно. Он как никто другой может развеять мистический туман, сгустившийся над Agile.
Джерри Фицпатрик Software Renovation Corporation Март 2019 года
Введение
Книга, которую вы держите в руках, – не научное исследование. Я не старался провести тщательный обзор литературы. То, что вы собираетесь прочесть, – мои личные воспоминания, наблюдения и мнения. Как-никак, я около двадцати лет связан с Agile.
Книга написана в неформально-разговорном стиле. Поэтому иногда я могу выбирать не очень корректные выражения. Сам я далеко не любитель крепкого словца, правда одно (несколько искаженное) бранное слово попало на эти страницы, но лишь потому, что иначе выразиться было никак!
Я бы не сказал, что книга гневлива. Когда вдруг меня прошибало, что нужно как-то обосновать написанное, я приводил источники, на которые ссылался. Я сверялся с мнениями других ребят из сообщества Agile, которые в деле столько же времени, сколько и я. Иногда даже нарочно просил некоторых дополнить книгу своим мнением или выразить свое несогласие, чему посвящены отдельные главы и разделы. Как бы то ни было, не стоит воспринимать эту книгу как научный труд. Наверное, правильнее бы воспринимать эту книгу как мемуары – старческое брюзжание, адресованное новичкам в Agile, которые только делают свои первые шаги.
Книга подойдет как программистам, так и простым любителям. Это не техническая литература.
Тут нет кода. В книге дается обзор первоначальной цели разработки Agile без углубления в какие-либо технические нюансы программирования, тестирования и управления.
Книга невелика. Просто потому, что много писать и не надо. Agile – небольшая идея, предназначенная для решения небольших задач, поставленных небольшими командами программистов, которые выполняют небольшую работу. Agile не рассчитан на решение крупных задач больших команд программистов, которые занимаются крупными проектами. Есть даже что-то ироничное в том, что такое решение для таких мелких задач вообще имеет название. В конце концов, мелкие задачи, о которых тут говорится, решили еще в 1950-е и 60-е, почти сразу, как изобрели программное обеспечение в принципе. Даже в те далекие времена небольшие команды научились неплохо справляться с небольшим объемом работ. Однако все испортилось в 1970-х. Тогда маленькие команды разработчиков, выполняющие небольшие объемы работ, запутались в идеях, пропагандирующих выполнение крупных работ в крупных командах.
А разве не так? Боже, да не так! Крупная работа не выполняется большими командами. На самом деле крупная работа выполняется большим количеством маленьких команд, которые в свою очередь выполняют много небольших задач. В 1950-х и 60-х годах программисты понимали это на уровне инстинкта. Но в 1970-е годы про это просто-напросто забыли.
А почему забыли? Полагаю, что так произошло из-за неравномерности. Количество программистов в мире стало резко расти в 1970-х годах. До этого в мире было всего несколько тысяч программистов. Но потом их количество резко выросло до сотен тысяч. Сейчас их число достигает сотни миллионов.
Те самые программисты 1950-х и 60-х годов были взрослыми. Они стали программистами лет в 30, 40 или даже в 50. К 1970-м годам, когда программистов вдруг стало тьма-тьмущая, эти «старички» ушли на пенсию. Поэтому некому было обучать новое поколение программистов. Молодые программисты от 20 лет и старше начали работать как раз тогда, когда более опытные ребята уже начали уходить, поэтому их опыт не передавался эффективно.
Некоторые скажут, что с этого события в программировании началось смутное время. На протяжении 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 здесь также отводится отдельное место. Перечислю их: Ари ван Беннекум, Алистер Кокберн, Джеймс Греннинг, Джим Хайсмит, Эндрю Хант, Джон Керн, Брайан Марик, Стив Меллор, Джефф Сазерленд и Дейв Томас.
Джим Ньюкирк, мой друг и деловой партнер, в то время без устали работал в поддержку Agile вопреки личным трудностям, которые большинство из нас (и я в том числе, безусловно) не могут даже представить.
Также я хочу упомянуть людей, работавших в корпорации Object Mentor Inc. Они приняли на себя основные риски по внедрению и продвижению Agile. Многие из них присутствуют ниже на фото, которое было сделано в начале первых уроков курса XP Immersion.
Задний ряд: Рон Джеффрис, я (автор), Брайан Баттон, Лоуэлл Линдстрем, Кент Бек, Мика Мартин, Анжелика Мартин, Сьюзен Россо, Джеймс Греннинг. Передний ряд: Дэвид Фарбер, Эрик Мид, Майк Хилл, Крис Бигей, Алан Фрэнсис, Дженнифер Конке, Талиша Джефферсон, Паскаль Рой. Не присутствуют: Тим Оттингер, Джефф Лэнгр, Боб Косс, Джим Ньюкирк, Майкл Фезерс, Дин Уэмплер и Дэвид Хелимски
Также я хочу упомянуть ребят, которые смогли собраться и сформировать альянс Agile Alliance. Некоторых из них можно увидеть ниже на фото – оно было сделано в начале заседания альянса в нынешнем августе.
Слева направо: Мэри Поппендик, Кен Швабер, автор, Майк Бидл, Джим Хайсмит (не присутствует: Рон Крокер)
Наконец, спасибо всем ребятам из Pearson, в особенности моему издателю Джули Файфер.
Об авторе
Роберт С. Мартин (Дядя Боб) является практикующим программистом с 1970 года. Он является также соучредителем cleancoders.com, где представлены различные видеоуроки для разработчиков программного обеспечения, учредителем компании Uncle Bob Consulting LLC, оказывающей услуги по консультированию, подготовке и развитию навыков крупным корпорациям по всему миру. Был высококлассным специалистом в консалтинговой компании, занимающейся отраслью программного обеспечения, 8th Light Inc., расположенной в Чикаго.
Боб Мартин написал десятки статей для различных профессиональных журналов и систематически выступает на международных конференциях и выставках. Он также является создателем известных образовательных видео на cleancoders.com. Боб Мартин является автором и редактором многих книг, в том числе:
«Разработка объектно-ориентированных приложений на C++ по методу Буча» (Designing Object-Oriented C++ Applications Using the Booch Method)
«Языки паттернов в процессе создания программ 3» (Patterns Languages of Program Design 3)
«Еще больше сокровищ C++» (More C++ Gems)
«Экстремальное программирование на практике» (Extreme Programming in Practice)
«Быстрая разработка программ. Принципы, примеры, практика» (Agile Software Development: Principles, Patterns, and Practices)
«UML для программистов на Java» (UML for Java Programmers)
«Чистый код»[1 - Мартин Р. Чистый код: создание, анализ и рефакторинг. – СПб.: Питер, 2018. – 464 с.: ил.]
«Идеальный программист»[2 - Мартин Р. Идеальный программист. Как стать профессионалом разработки ПО. – СПб.: Питер, 2019. – 224 с.: ил.]
«Чистая архитектура»[3 - Мартин Р. Чистая архитектура. Искусство разработки программного обеспечения. – СПб.: Питер, 2020. – 352 с.: ил.]
Лидер в отрасли разработки программного обеспечения, г-н Мартин три года был главным редактором журнала C++ Report, а также первым председателем Agile Alliance.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Глава 1. Введение в Agile
В феврале 2001-го группа из семнадцати экспертов в области разработки программного обеспечения собралась в городке Сноуберд, штат Юта. На собрании обсуждалось плачевное состояние отрасли. Тогда большинство программ создавалось посредством неэффективных тяжеловесных фреймворков с большим количеством ритуалов, наподобие каскадной модели и раздутых реализаций Rational Unified Process (RUP). Целью этих экспертов было создание манифеста, который провозглашал бы более эффективный и легковесный подход.
Нельзя сказать, что царило единодушие. У всех семнадцати был разный опыт и, соответственно, сильные расхождения во мнениях. Рассчитывать, что такое собрание быстро придет к общему мнению, было бы слишком наивно. И все же, несмотря на все трудности, согласие было достигнуто, и Манифест Agile увидел свет – так родилось одно из самых мощных и живучих движений в отрасли программного обеспечения.
В этой отрасли практически все движения происходят по одному и тому же пути. Поначалу есть меньшинство, восторженно выступающее в поддержку чего-либо, другое меньшинство заряженных критиков и подавляющее большинство – те, кому, мягко говоря, нет дела.
Многие из этих движений хиреют или никогда не проходят этот этап. Можно вспомнить аспектно-ориентированное программирование, логическое программирование или CRC-карты. Некоторые, однако, способны преодолеть такую пропасть, становясь чрезвычайно популярными и разносторонними. Некоторым удается оставить позади противоречия и занять господствующее положение в современной мысли. Объектно-ориентированное мышление можно считать примером последнего случая. И Agile тоже.
К сожалению, как только движение набирает последователей и начинает распространяться, то сталкивается с искажением и незаконным присваиванием. Продукция и методики, не имеющие ничего общего с оригинальным движением, присваивают чужое имя, чтобы нажиться на его славе и значимости. Так случилось и с Agile.
Эта книга, написанная спустя почти два десятка лет после событий в Сноуберде, ставит своей целью точно передать посыл идеи. Эта книга – попытка в высшей мере кратко и точно описать Agile без брехни и обиняков.
В ней представлены основные принципы Agile. В приукрашивании и расширении этих идей нет ничего плохого. Тем не менее производные от Agile – это уже не сам Agile. Это дополненный Agile со своими опциями. А то, о чем вы узнаете из этой книги, – это и есть тот самый чистый Agile, который всегда был и непременно будет.
История Agile
Когда зародился Agile? Вероятно, более 50 тысяч лет назад, когда люди впервые решили работать совместно ради общей цели. Идея постановки небольших промежуточных целей и измерения продвижения после их достижения у человека проявляется на подсознательном уровне, поэтому вряд ли это какая-то настоящая революция.
Когда впервые появился Agile в современном мире? Трудно сказать. В моем представлении, первый паровой двигатель, первая мельница, первый двигатель внутреннего сгорания, первый самолет были созданы с помощью методик, которые сейчас можно отнести к Agile. Я считаю так, потому что предпринимать небольшие измеряемые шаги очень естественно для человека, сложно представить, что это происходит иначе.
Так когда же Agile появился среди программистов? Хотел бы я быть мухой на стене у Алана Тьюринга, когда тот писал свою книгу в 1936 году[4 - 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.]. По моим догадкам, многие свои «программы» он написал, разбивая работу на мелкие этапы с изобилием отладки по исходному тексту вручную.
Я также хорошо представляю, что первый код, который он написал для автоматической вычислительной машины (Automatic Computing Engine, ACE) в 1946 году, был написан постепенно, маленькими этапами, с частым проведением ручной отладки по исходному тексту и даже с небольшим тестированием в действии.
В первые дни существования программного обеспечения можно найти много примеров решения задач, которые сейчас бы отнесли к Agile. Например, программисты, писавшие код для управления пилотируемым космическим кораблем «Меркурий», работали по этапам с интервалом в полдня с перерывами на модульное тестирование.
