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

— Сначала нужно определиться, что такое Agile. Многие традиционно называют Agile разработку в scrum формате, куда вовлечены только IT-специалисты, знакомые с этой системой по учебникам. На самом деле Agile — это набор современных практик. Появились они из современных технологичных IT-компаний, которые развились за последние десятки лет в многомиллиардные гиганты.

Весь остальной мир стал смотреть на них, пытаясь понять, как они обеспечили такой существенный рывок, и сделал вывод, что дело в наборе современных практик управления, сильно отличающихся от тех, что применялись до этого. Сюда входят design thinking, lean product managament, scrum как некий формат реализации процесса в рабочей группе, сильный фокус на людях и командах, на холократии.

И понятно, что бум связан с тем, что все смотрят на успешные примеры за границей и в России, пытаются реализовать это в своей работе. Сейчас идет очередной этап развития, и надо понимать, что буквально через несколько лет этого будет еще больше, еще больше людей перейдет на новый уровень практики, и Agile будет использоваться повсеместно. Это некоторая очередная продуктово-техническая революция, какой в свое время был, например, конвейер Форда. Как и в те времена, есть ретрограды и критики, есть новаторы, с которых все начинается. Слышно и тех, и других, но каждый делает свой выбор сам.

— Существует мнение, что по Agile можно хорошо работать только собственными ресурсами, но не со сторонними разрабочиками. Вы с этим согласны?

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

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

— Agile не подразумевает пошаговых руководств и конкретных рекомендаций. А что же именно он рекомендует?

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

— Особенностью Agile является «плавающая» оценка сроков разработки и бюджета. Так что же на практике важнее: уложиться в сроки или в бюджет?

— Это ошибка — считать, что сроки разработки или бюджет для Agile плавающие. Наоборот, при Agile они являются более определенными, чем при стандартной — waterfall — разработке. Есть команда, есть product owner с определенной задачей, они садятся и проговаривают, что хотят сделать, определяют дату запуска.

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

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

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

— Действительно, если каждый раз проводить совещания с долгими обсуждениями, то это отнимает много времени, но Agile хорош тем, что занимает столько времени, сколько на него отведено. Для ежедневных обсуждений установлен лимит всего 15 минут. Если команда не в состоянии обсудить результаты за это время, ей нужно что-то менять в работе и стремиться к этому лимиту. Через какое-то время становится меньше обсуждений и все укладываются в срок. Здесь срабатывает правило: если команда часто понемногу общается и находится в едином информационном поле, ей требуется все меньше времени на обсуждения.

— В чем различие Agile и Kanban? Можно ли их сочетать?

— Agile — это все-таки большой набор практик, который часто подразумевает с точки зрения командной работы Scrum. Можно ли Scrum заменить на Kanban? Конечно, можно. Ведь суть Agile — не в Scrum или Kanban как в некоем способе управления командой, а в правильном подходе к работе с продуктом, в работе «в полях» с конкретными клиентами и их потребностями, в регулярной корректировке в режиме обратной связи с пользователями. Можно ли все это делать в Scrum или Kanban? Да.

— Удалось ли вам на практике ликвидировать простои во время согласования проектной документации?

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

— Где, на ваш взгляд, место Scrum в процессе гибкой разработки ПО?

— Мы придерживаемся трехуровневой модели SAF Scaled Agile Framework. Используем ее как некую референсную модель, но не пытаемся ее неожиданно для всех в банке внедрить. Мы как раз придерживаемся другого мнения, считаем, что в банке каждая команда должна уметь работать со своим заказчиком в той модели, которая наиболее удобна. Место Scrum — это работа в команде на нижнем уровне, когда речь идет о развитии конкретной функциональности. На среднем уровне мы применяем Scrum of Scrum, когда представители различных команд встречаются и выравнивают сроки и ожидания по совместной разработке или взаимовлияющему функционалу.

— Agile подразумевает изменение культуры. Вопрос: только программистов, тестировщиков (и)или других подразделений банка?

— Agile внутри IT быть не может. Он возможен только в кросс-функциональной команде, представляющей интересы какого-либо value stream в банке, а именно реализующего какой-либо продукт для конечного клиента. Например, ипотека, cash-кредитование, карты и любой другой законченный продукт. В такую команду должны входить продуктологи, представители сервиса, дизайнеры, архитекторы, аналитики, и другие IT-сотрудники, только в такой команде может быть реализован Agile. Да, его необязательно реализовывать во всей организации, но в отдельно взятой команде он должен распространяться на всех членов.

— Новые конкурентные модели управления требуют полной независимости в принятии решения. Можно ли без децентрализации быть гибким?

— Конечно, нет. Agile предполагает наличие команды, которая реализует продукт end to end. Реализация такого продукта невозможна без определенной самостоятельности. Искусство децентрализации состоит в создании некой федеративной структуры, когда есть штаб и он устанавливает правила, которые все соблюдают. Существуют полномочия, спущенные командам, которые вольны самостоятельно принимать решения. Это, наверное, самый болезненный момент — найти баланс между тем, что команда определяет самостоятельно в плане технологий, процедур, и централизацией. Ведь команды работают на одном и том же IT-ландшафте, с одними и теми же процедурами в организации, а зачастую и на взаимозависимых задачах.