Введение
Книга, которую вы держите в руках, – не научное исследование. Я не старался провести тщательный обзор литературы. То, что вы собираетесь прочесть, – мои личные воспоминания, наблюдения и мнения. Как-никак, я около двадцати лет связан с 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-м.
Посыл стар как мир. Но тем не менее это истина. Этот посыл предлагает нам небольшую идею для решения небольших задач, поставленных небольшими командами программистов, которые выполняют небольшую работу.