Agile в работе и в жизни. Опыт разработки Контура

Руководители Контура продолжают делиться ценной информацией. В этой колонке Александр Голубев, руководитель разработки, рассказывает о подходах agile и waterfall, сравнивает их и говорит о преимуществах и недостатках каждого метода.

Agile базируется на четырех ценностях:

— люди и взаимоотношения превыше процессов и инструментов;

— функционирующий продукт превыше полной документации;

— работа с клиентом превыше условий контракта;

— умение меняться превыше четкого следования изначальному плану.

Схема работы разработки, как и многих других направлений, достаточно стандартная: понять, что предстоит делать → убедиться, что идея стоит времени → понять, как это будет выглядеть → осуществить проект → проверить на ошибки → отдать конечному пользователю.

15-20 лет назад мы работали по модели «водопад» (waterfall). Очередность этапов не менялась, но процесс занимал больше времени из-за скорости доставки до пользователя: нужно было нарезать программы на диски (а ещё раньше и на дискеты!), наладить логистику. Диски с новыми версиями программ каждый день не будешь отправлять клиентам, поэтому обновления собирали в пакеты, потребитель их ждал квартал, а то и год. Непросто было и возвращать диски назад, если в коде обнаруживалась ошибка.

Технологии ускорили процесс, так что переход к agile — логичный шаг. Мы сократили итерации и ускорили доставку.

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

Правда, поднимать голову нужно аккуратно: если слишком много времени тратить на анализ текущей ситуации, фокус на результате потеряется, а планы будут бесконечно меняться. Если во время работы постоянно отвлекаться на все раздражители — на уведомления в телефоне, беседы с коллегами — задачи останутся нетронутыми. Когда перегибаешь с agile, сталкиваешься с этой же проблемой.

Не во всех сферах можно применять agile. Когда риски высоки, а цена ошибки велика, нужно с осторожностью использовать гибкие методологии. Например, в космической индустрии или здравоохранении. Я думаю, всегда нужно быть готовым к изменениям. Они — неизбежная часть жизни и происходят в разных ситуациях.

Работа в Контуре проходит по манифестам agile:

— Люди и их взаимодействие были в приоритете еще до внедрения agile.

— Мы сами определяем, какими будут наши продукты, а не пишем их на заказ. Поэтому порой опускаем описание некоторых моментов проделанной работы. Функционирующий продукт для нас важнее отчёта о том, что сервис работает.

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

— Контур положительно относится к изменениям в первую очередь потому, что мы работаем с людьми, которые готовы менять и себя, и окружающий мир. Чаще всего к нам устраиваются молодые специалисты, а они на сто процентов «за» перемены.

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

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

Гибкий подход учит привыкать к изменениям и в работе, и в процессах, и в личной жизни. Мне нравится планировать отпуск, но я готов к тому, что что-то поменяется в процессе. В этом есть свое очарование: например, я часто не ищу конкретное место для обеда, а захожу в заведение, которое кажется интересным. Иногда бывают провалы, а иногда — приятные находки. Думаю, это и есть «жизненный» agile.