Выбрать главу

Прошло уже 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-х мы поняли наконец, что нужно перезагрузить всю отрасль целиком.