Все
разделы

Публикации

«Гибкая разработка основана на взаимном доверии участников»

Компания EPAM, один из крупнейших разработчиков программного обеспечения, активно применяет гибкие подходы к разработке, объединяемые концепцией Agile. Мы поговорили о том, что хорошего и плохого дает применение Agile банкам, с заместителем генерального директора EPAM по развитию бизнеса Артаком Оганесяном и Алексеем Ионовым, agile-коучем EPAM.

— Когда вы начали применять agile-методологии в разработке? Что послужило поводом к этому переходу?

Артак Оганесян: Более 20% наших клиентов в мире — это производители программного обеспечения, такие как Oracle или SAP. Они первыми еще даже до появления Agile Manifesto и термина Agile начали использовать методики гибкой разработки — парное или экстремальное программирование, feature-driven development и их аналоги. Кроме того, в число пионеров гибких подходов входили технологические стартапы, молодые интернет-компании и первопроходцы электронной коммерции. Например, Expedia.com — крупный туристический интернет-портал, где была очень тесная связь между бизнесом и ИТ, существовала потребность в постоянной и быстрой разработке новой функциональности для конечных потребителей, без реализации длительных проектов по классическим водопадным моделям. Благодаря сотрудничеству с такого рода заказчиками произошло что-то вроде перекрестного опыления: мы переняли некоторые практики и начали использовать их в проектах EPAM для других компаний. Сначала на Западе, а позднее и в России.

— Это какие годы?

Артак Оганесян: На Западе мы используем гибкие методологии со второй половины 90-х, в России — начиная с 2008–2009 годов. Здесь еще важно, что в 2012-м в состав EPAM вошла канадская компания Thoughtcorp, где на тот момент была сформирована зрелая и продвинутая практика Agile под руководством Хино Маркса — известного гуру Agile, основателя agile-сообщества в Канаде с опытом реализации крупных проектов в Европе и Северной Америке. В EPAM Хино возглавил Центр компетенции по Agile, который сейчас объединяет свыше 600 сертифицированных по SCRUM, Kanban и другим методикам консультантов. Кроме того, с подачи Хино у нас появились своего рода послы Agile, в чьи задачи входит продвижение гибких методологий, и agile-коучи — специалисты, отвечающие за обучение команд разработки технологиям практического применения Agile и переходу на Agile.

— Что означает для проекта применение гибких методик?

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

— Каким образом выполняется постоянная доработка? На слух звучит как рецепт хаоса.

Алексей Ионов: Есть список задач, или бэклог, где перечислены и оценены все задачи, которые должны быть выполнены в рамках проекта. Перед стартом каждой итерации разработки команда вместе с бизнес-заказчиком отбирает две-три наиболее критичные задачи на ближайшие недели. Затем разработка, тестирование, при необходимости подготовка документации — и вывод в эксплуатацию.

В результате финальное решение может сильно отличаться от первоначальной задумки, но при этом оно будет гораздо лучше соответствовать актуальным требованиям клиента, конъюнктуре рынка и окружающей среды

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

Артак Оганесян: Вот пример. К нам обратился банк с просьбой доработать мобильное приложение для проведения автоплатежей и автопополнения депозита. Настройка платежей и суммы пополнения депозита должны были задаваться пользователем приложения с помощью комплекса правил, логических и математических формул с учетом статистики ежемесячных платежей, наличия и объема неизрасходованного остатка на счете и ряда других параметров. Реализовать все это необходимо было обязательно и одновременно.

После консультации с нашим agile-коучем заказчик согласился, что в первых итерациях мы реализуем возможность задавать сумму автопополнения депозита при заданных порогах прихода на счет и остатка после проведения автоплатежей (если сумма ниже, то перевод на депозит не выполняется). Этот функционал был введен в эксплуатацию через три недели после старта разработки, и конечные клиенты банка начали им пользоваться. Когда же мы завершили проект в полном объеме с реализацией всех пользовательских формул, выяснилось, что 90% клиентов продолжают использовать именно первоначальный функционал. Возможности, не предусмотренные в первом бэклоге, оказались и не столь востребованными.

— А если заказчик с самого начала точно знает, что ему нужно, и требования по ходу разработки не меняются, Agile имеет смысл? Дешевле или дороже получится разработка по сравнению с водопадной моделью?

Алексей Ионов: На небольших проектах Agile всегда дешевле. Масштабные проекты практически никогда не проходят без изменения первоначальных требований. Если при этом мы говорим о проектах с фиксированными сроками и бюджетами, то процесс управления и оценки изменений может потребовать значительных усилий высокооплачиваемых специалистов и руководителей с обеих сторон. Напротив, Agile благодаря коротким итерациям и определению приоритетов помогает гораздо быстрее реагировать на изменения.

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

— И все-таки, в каких случаях Agile неприменим? Где эффективнее классическая методика водопада?

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

— Что думают об Agile ваши российские клиенты? Приходится убеждать?

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

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

У Agile нет альтернативы, если вам нужны короткие сроки, быстрый и осязаемый результат, высокая скорость адаптации к изменениям на рынке

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

— Насколько легко вовлечь заказчика, особенно банковского, в agile-разработку?

Артак Оганесян: Есть банки, которые по своему образу мышления стали Agile. Точнее, это не столько сами банки, сколько их подразделения электронного бизнеса. Яркий пример — Альфа-банк и Альфа-лаб. Когда наш проект передали из банка в Альфа-лаб, новый заказчик начал нас подталкивать к переходу на Agile. Мы же, после двух лет работы с самим Альфа-банком, поначалу даже присматривались к Альфа-лаб: а точно ли у них Agile? Вот таких заказчиков вовлекать в agile-разработку не требуется — они уже в ней.

Банков, кто просто игнорирует Agile или отмахивается от этой практики, сейчас уже нет. Особенно после знаменитого выступления Германа Грефа

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

— Как относится бизнес-заказчик к тому, что ему приходится постоянно участвовать в разработке, тратить время? У него все-таки и другая работа имеется.

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

— Вы постоянно говорите: заказчик должен быть таким, он должен сделать то и это. А чем должен обладать исполнитель, чтобы заниматься agile-разработкой? Почему при всех преимуществах подхода он пока принят не повсеместно?

Для работы по Agile команда должна быть технологически очень сильной

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

Здесь трех месяцев нет, сделал — отвечай. Кроме того, для Agile необходимо выстраивать среды постоянной сборки, проводить unit-тесты на каждом шагу, максимально автоматизировать тестирование. Это предъявляет очень серьезные требования к квалификации исполнителей, из-за чего многие специалисты просто не могут участвовать в процессе. Соответственно, цена agile-разработчиков на рынке намного выше. Это не всегда легко объяснить заказчику. Даже многие программисты уверены, что достаточно прочитать пару книг по Agile или посмотреть ролики на YouTube, повесить на стену доску с наклейками — и уже можно без документации что-то делать «типа Agile».

— Что самое важное для успеха agile-проекта?

В чем суть идеологии водопада? В недоверии

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

Михаил Дьяков , Банкир.Ру