Алексей макеев, at consulting: «до внедрения agile в банке еще надо дорасти»

- kbrbank

Алексей макеев, at consulting: «до внедрения agile в банке еще надо дорасти»

Алексей Макеев, партнер компании AT Consulting, поведал Bankir.Ru о тонкостях внедрения Agile, о балансе между классическими и эластичными методиками разработки и о том, из-за чего гибкость попадает кроме того в самые формализованные организации. — Agile в банковском бизнесе деятельно обсуждается уже пара лет, но и сейчас у эластичных методик большое количество соперников. Какие конкретно доводы в пользу Agile видятся вам главными?

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

Много кредитных организаций сможет без шуток ускориться и безо всякого Agile

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

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

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

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

Такие банки стараются комбинировать подходы.

Все кредитные организации, кроме того самые формализованные и забюрократизированные, на практике используют элементы Agile

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

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

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

— По отечественному опыту, в большом проекте Waterfall в чистом виде неосуществим в принципе и с возможностью 100% ведет к неуспеху.

Громаднейшей популярностью пользуются комбинации — совмещение хороших водопадных подходов с элементами Agile

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

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

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

Одна из редких областей, где на практике Agile-подход применим слабо, это интеграция

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

А формальная документация создается параллельно с ее реализацией.

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

— С чего стоит начать при принятии ответа о переходе на эластичные методики?

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

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

— Одной из значительных неприятностей в банках делается объединение всех IT-компетенций в одном информационном и физическом пространстве. Имеется ли методы внедрить Agile «по частям», в то время, когда менеджеры и разработчики поделены территориально? Неумение трудиться с поделённой территориально командой будет становиться все громадным и громадным препятствием для развития

— Территориальная удаленность участников команды — не неприятность, в случае если процессы сотрудничества в команды отлажены. Мир неуклонно двигается в сторону распределенных эластичных команд, исходя из этого неумение трудиться с поделённой территориально командой будет становиться все громадным и громадным препятствием для развития. Эту проблему нужно преодолевать.

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

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

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

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

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

Нереально внедрять Agile в ситуации, в то время, когда в проектной команде 0,25 банковского технолога, 0,3 аналитика по АБС, 0,1 архитектора по интеграции. При наличии ресурсных неприятностей внедрение Agile не окажет помощь, а скорее усугубит обстановку. Недочёт ресурсов по одному либо нескольким направлениям будет тормозить всю проектную команду.

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

— Какие конкретно шаги направляться предпринять для нормализации обстановки?

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

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

Внедрение и развитие Agile в организации (на примере Альфа-Банка).

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

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