Об Agile

В 2001 году семнадцать консультантов собрались на горнолыжном курорте в штате Юта, США, чтобы обсудить методы разработки программного обеспечения. Результатом их встречи стал документ под названием "Agile Manifesto". Манифест включил в себя 12 принципов, но широко известны в основном только четыре «ценности»:

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

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

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

• Готовность к изменениям важнее следования первоначальному плану

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

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

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

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

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

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

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

Code ownership против менталитета тикетов

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

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

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

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

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