Об Agile

В 2001 году семнадцать разработчиков собрались на горнолыжном курорте в штате Юта, США, чтобы обсудить методы разработки. В результате их встречи был создан документ, который позже стал известен как "Agile Manifesto". Это был большой шаг в сторону объединения различных методологий и акт сопротивления тяжеловесным и перегруженным процессам, типичным для модели Waterfall.

Манифест включает в себя 12 принципов, но широко известны в основном только четыре «ценности»:

• Люди и взаимодействия важнее процессов и инструментов

• Работающее ПО важнее подробной документации

• Сотрудничество с клиентом важнее переговоров по контракту

• Реакция на изменения важнее, чем следование плану

Эти принципы задали новый тон для разработки программного обеспечения, представив Agile как более эффективный и прогрессивный подход по сравнению с устаревшими методами. Однако на практике оказалось, что большинство этих принципов слишком расплывчаты, чтобы их можно было применить непосредственно к разработке ПО. Спустя более 20 лет все еще идут дебаты о том, что такое Agile — философия, методология, фреймворк или совокупность ценностей? Написано множество книг, а тысячи людей прошли сертификацию как специалисты по Agile и Scrum, обучая других, как «правильно» работать по Agile. И если что-то не выходит — значит, вы просто не делаете Agile как надо.

При этом, несмотря на широкое распространение, нет очевидных доказательств того, что Agile действительно работает. Его популярность объясняется тем, что метод Waterfall — где все планируется заранее и строится по плану — работает только в тех случаях, когда четко известно, что нужно создать, заранее. В стартапах, где разрабатывается что-то концептуально новое, это едва ли возможно. Также в компаниях с одним продуктом разработчики не могут просто сидеть в ожидании, пока продуктовые менеджеры и дизайнеры сделают все спецификации.

Тайна Канбан-доски

В 2003 году Мэри и Том Поппендик опубликовали книгу Lean Software Development: An Agile Toolkit. Это была первая попытка применить методы, взятые с японских заводов Toyota, к разработке ПО. Судя по тому, как много разработчиков сегодня используют Канбан-доски, эта идея оказалась успешной. Но действительно ли она подходит для создания ПО?

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

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

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

Ответственность за код против менталитета тикетов

Когда автомобиль выходит с конвейера, его ремонтом его занимаются в сервисных центрах, а не на сборочной линии. Точно так же, когда задача на Канбан-доске помечена как «Сделано», она исчезает в небытие, и вам придется пользоваться поиском, чтобы ее найти. Это будет сложно и для ваших коллег, а если они все-таки найдут задачу, как они поймут, актуальна ли информация или она была заменена другой?

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

«Если это не в Jira, этого не было» — такой подход не способствует улучшению качества кода или долгосрочному планированию. Он ставит на первое место скорость выполнения задач и различные метрики, которые редко оказываются полезными. Люди, не обладающие техническими знаниями, не могут точно оценить качество кода или увидеть ухудшение его состояния, пока не станет слишком поздно. Именно переписывание кода с нуля по-прежнему является частой историей в индустрии.

Технические лидеры часто говорят о «code ownership», но на самом деле они пытаются решить проблему равнодушия к качеству продукта. Немало разработчиков не смотрят дальше плохо написанных требований и не сталкиваются с последствиями своих ошибок. Их задача — исправить свои ошибки, но они не учатся на них. В то время как более опытные разработчики вынуждены идти на компромиссы в конце спринта, что приводит к разочарованию и выгоранию.

Agile и Канбан-доска не оправдали себя в разработке ПО. Agile пытался объединить эвристический подход и программирование, но это оказалось неудачным экспериментом. Поэтому мы создали итеративно-функциональный метод — системный подход к управлению продуктами в области разработки ПО.