Agile, DevOps и ИТ-команда: правила разработки сложного цифрового продукта

Довольно много компаний на рынке все еще работают по стандартной схеме управления проектами - каскадной методологии Waterfall. Но скорости сейчас таковы, что планировать месяцами и внедрять годами, как было раньше, неэффективно. Что можно использовать вместо этого, объясняет руководитель направления компании “ЛАНИТ - Би Пи Эм” Андрей Денискин.

Agile или не Agile, вот в чем вопрос

Почему Agile? Можно перечитать манифест, но в целом главный принцип методологии - быстрый ответ на задачи бизнеса, ориентация на сотрудничество и готовность к изменениям. 

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

Какие могут быть гипотезы в банковской сфере:

• если мы сделаем удобное мобильное приложение, клиенты будут более лояльны, и мы уменьшим их отток;
• если повысим скорость выдачи кредита до 15 минут вместо нескольких дней, то получим больше клиентов;
• еще снизим ставку по кредиту, это приведет к притоку клиентов и росту портфеля.

Agile-подход позволяет быстро проверять эти гипотезы, отсекать то, что не работает, и двигаться дальше. По нашему опыту, без гибких методологий создать продукт, который будет адекватен запросам клиентов (конечных пользователей) и решит задачи бизнеса, не получится.

Так, один из наших клиентов в свое время разрабатывал продукт, используя каскадную методологию. Полгода формировалось ТЗ, еще полгода ушло на конкурс и выбор подрядчика. Сама разработка в сумме заняла почти два года - надо ли говорить, что за это время проект морально устарел и его “положили на полку”. Хорошо, что заказчик нашел в себе силы и вместе с нами повторил проект “по аджайлу” - через полгода система была уже внедрена, и далее мы продолжили работу над ее развитием и совершенствованием.

Конечно, можно ошибиться с гипотезой, но “по аджайлу” на исправления уйдет пара месяцев, а не полгода. К тому же, чтобы минимизировать масштабные исправления, Agile-подход подразумевает регулярные демо, на которых собирается обратная связь от бизнес-подразделений и конечных пользователей.

DevOps без вопросов

Логичным дополнением Agile-методологии становится применение практик DevOps, в основе которых лежит принцип оптимизации командной работы для повышения скорости производства продукта. Главная задача DevOps - создание единого цикла взаимодействия разработки, тестирования и эксплуатации ПО.

Как это выглядит на практике? На старте работы над проектом формируется бэклог задач, идет работа над MVP и параллельно выстраивается среда разработки. Здесь важно выбирать технологии, которые снижают цену ошибки. DevOps-инженер должен выбрать правильные инструменты, сконфигурировать стенды разработки, тестирования и эксплуатации таким образом, чтобы обеспечить минимальный показатель time-to-market. В идеале время от внесения разработчиком изменений в код до вывода этих изменений в эксплуатацию должно измеряться минутами или максимум часами.

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

Команда - приоритет №1

Бесспорно, современные методологии, инженерные практики и гибкая слабосвязанная архитектура играют критическую роль в успехе проектов, позволяя снижать time-to-market и повышать частоту, предсказуемость и качество релизов. Но многолетний опыт демонстрирует, что разработка - это прежде всего команда. Какие бы ни были современные технологии и самый “аджайлный аджайл”, если команда - это не коллектив, не сплоченная группа, объединенная общей целью и мотивированная на результат, а несколько людей, которые просто работают вместе (пусть даже они профессионалы!), разработка будет хромать, и быстро и качественно создавать продукт не получится.

Такую команду сформировать крайне сложно и долго. Чтобы создать ее внутри компании, понадобится в среднем от полугода до полутора лет: сначала создается костяк из product owner, архитектора, аналитика и ведущего разработчика, а потом они формируют остальную команду. Но опять же, скорости сейчас таковы, что релиз должен был состояться вчера, и если готовой сработанной команды нет, результат сложно спрогнозировать.

Зачастую проще привлечь на проект сработанную команду, чем формировать ее с нуля. Готовая команда, которая уже не раз работала вместе над проектами и понимает логику взаимодействия, упростит процесс разработки и позволит получить предсказуемый результат. Мы видим, что сейчас на рынке все чаще появляется такой “продукт”, как готовая agile-команда, и спрос, судя по нашему опыту, на такие команды только растет. Ведь именно так бизнес получает новые возможности для быстрого запуска новых продуктов, расширяя возможности цифровой трансформации.