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

- kbrbank

Компания 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-коучем клиент дал согласие, что в первых итерациях мы реализуем возможность задавать сумму автопополнения депозита при заданных порогах прихода на счет и остатка по окончании проведения автоплатежей (в случае если сумма ниже, то перевод на депозит не выполняется). Данный функционал был открыт через 20 дней по окончании старта разработки, и конечные клиенты банка начали им пользоваться.

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

— А вдруг клиент сначала совершенно верно знает, что ему необходимо, и требования по ходу разработки не изменяются, 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 команда должна быть технологически весьма сильной. Каждые 1-2 недели она обязана отдавать клиенту функционал, всецело протестированный и готовый к умелой либо промышленной эксплуатации, либо как минимум демонстрировать трудящийся функционал. Это требует большого качества работы от каждого участника команды.

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

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

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

— Что самое серьёзное для успеха agile-проекта? В чем сущность идеологии водопада? В недоверии

Артак Оганесян: Две вещи: доверие заказчика и квалификация исполнителя. Эластичная разработка основана на обоюдном доверии участников проекта. В чем сущность идеологии водопада? В недоверии.

Бизнес-клиенты не доверяют технологам. Технологи не доверяют программистам. Программисты не обожают тестировщиков. И без того потом по цепочке. Проект на протяжении разработки передается из рук в руки, и на каждом этапе тратится масса времени на его приёмку и сдачу.

В Agile бизнес-клиенты, технологи, тестировщики и программисты трудятся над проектом совместно, одной командой. Им нужно доверять друг другу, дабы в конце каждой итерации разработки приобретать продукт — актуальный, трудящийся и приносящий итог для бизнеса.

Доверие Жизни

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: