Agile умер, да здравствует DevOps!
31.10.2016
Источник:
Futurebanking.ru
Пока банки поют дифирамбы Agile и собираются его внедрять по всей организации, нарастает другая волна – разочарования в нем и поиска других методик. Один из идеологов гибкой разработки Дейв Томас считает, что слово Agile превратилось в маркетинговый термин. FutureBanking узнал, что думают об Agile в российских банках, и что придет ему на смену в ближайшие годы.
Мода на методологию гибкой разработки не проходит уже несколько лет, и вдохновенные Agile-евангелисты проникают во все более консервативные компании, гипнотизируя архитекторов, программистов и тестировщиков заклинаниями Scrum, Kanban, Lean. Даже столь неповоротливые организации, как банки, с гордостью демонстрируют свои успехи в освоении гибких подходов и рассказывают, какие небывалые вершины в пользовательском опыте им удалось покорить при помощи Agile.
Евгений Самойлов, начальник отдела информационных технологий банка для предпринимателей «Точка» (финансовая группа «Открытие»), подтверждает: «Мы используем Scrum в работе над продуктами, связанными с разработкой ПО, и не только — гибкий подход пригождается нам и в проработке бизнес-идей, и в прототипировании будущих решений».
Его коллеги по финансовой группе исповедуют несколько более осторожный подход. Андрей Сабынин, директор департамента развития систем розницы и малого бизнеса банка «Открытие», рассказал FutureBanking, что «команды в Открытии сформированы по кросс-функциональному принципу, то есть в рамках команды присутствуют не только специалисты по фронт-офисным решениям, но и разработчики интеграционных и учетных систем, таких как розничная АБС 3Card-R, корпоративная АБС ЦФТ, процессинговая системма Way4, интеграционная шина Tibco, вместе успешно работающие в рамках Scrum-методологии. Справедливости ради стоит сказать, что некоторые из команд придерживаются консервативных взглядов на производство и до сих пор реализуют доработки по водопадной модели. Примеры Agile команд банка: команда развития ипотечного бизнеса, карточная команда, команда развития малого бизнеса, digital».
Однако возникла и все ширится оппозиция Agile-течению. Высказываются мнения, что Agile «не взлетел», что с его помощью не сделать качественный продукт, или даже то, что современный Agile – вовсе не тот Agile, что 15 лет назад был описан в каноническом манифесте. Иными словами, ажиотаж вокруг гибкой методологии разработки нанес отрасли вред, и наполнил софт багами и уязвимостями.
Два года назад Gartner поместил Agile на самую вершину своего цикла зрелости технологий. Эта точка зовется «пик завышенных ожиданий». А за ней следует резкий спуск, заканчивающийся в нижней точке разочарования, куда мы неизбежно придем, как это всегда бывает с новыми технологиями. Или, похоже, уже пришли.
Критика Agile
Дейв Томас, один из авторов изначального «Манифеста гибкой методологии разработки программного обеспечения», считает, что ценности гибкой разработки, заложенные в манифест, так и не получили воплощения, а само обозначение Agile превратилось в маркетинговый термин, лишенный реального смысла. Да, манифест в свое время сломал оковы на разуме разработчиков, развенчав принципы разработки 80-х и 90-х, но дальше процесс пошел в непредсказуемом направлении, превратив Agile в набор жестких требований, которому разработчики пытаются слепо соответствовать, вне зависимости от их применимости в каждом конкретном случае. Похожего мнения придерживаются и многие другие его коллеги.
Agile отлично работает в разработке фронтенда, когда функциональность замыкается на пользовательском опыте, но в более сложных системах применение гибкой методологии катастрофически сказывается на качестве кода, вследствие отсутствия тщательно продуманной архитектуры продукта или отступления от нее в процессе разработки. Agile плохо масштабируется, не позволяя эффективно координироваться командам в создании тесно связанных кусков функциональности.
«Разработка нового продукта может затрагивать несколько систем. Чтобы синхронизировать их релиз, мы выбираем систему-лидера, ядро, которая выводит разработку первой задачи. Остальные задачи, в зависимости от критичности, подстраиваются. Иногда временные затраты на синхронизацию систем могут быть соизмеримы со временем разработки всего продукта, а то и превышать его», – рассказал Вячеслав Цыганов, вице-президент по информационным технологиям Тинькофф Банка.
Одним из традиционно слабых мест гибкой методологии является unit-тестирование, которое крайне трудно наладить в рамках небольшой команды. Наконец, внедрение и эксплуатация полностью оторваны от Agile-разработки, что радикально затягивает сроки готовности продукта, несмотря на то, что функциональность, казалось бы, успешно разрастается с каждой итерацией.
Agile и банки
При всем сказанном мы не наблюдаем серьезных проблем с качеством программного обеспечения у банков, применяющих гибкую методологию разработку – они вполне успешно учатся по ней работать. Так, Андрей Сабынин считает, что Agile применим на всех уровнях банковского IT: «бытует мнение, что разработку банковских бэк-офисных систем крайне сложно вести в режиме Agile из-за относительной сложности написания постановок на доработку бэк-офисного функционала, однако я не согласен с данным мнением. Действительно, практически невозможно в виде краткой пользовательской истории описать, скажем, альбом проводок какой-либо задачи, поэтому часть задач бэк-офиса будет требовать детального бизнес-анализа. При этом сложная бизнес-постановка почти всегда может быть разобрана на небольшие пользовательские истории, которые уже можно без проблем реализовывать итеративным образом в рамках Agile-подхода».
«Гибкая методология разработки Agile лучше всего подходит небольшим компаниям, которые создают продукт с нуля, – предупреждает Вячеслав Цыганов. – Крупные компании тоже могут работать по Agile, но ограниченно, например, при работе над выделенным проектом или бизнес-направлением. Главное условие, как ни странно, — готовность самой команды работать по Agile. Эта методология позволяет начать работу над проектом раньше, когда требования ещё не полностью понятны и формализованы. Но руководство должно быть готово к тому, что количество итераций и ресурсов в процессе может существенно измениться. Разработчики должны быть готовы к тому, что один и тот же продукт придется дорабатывать по несколько раз».
Трудности, отчасти обусловленные применением гибкой разработки, «Точку» не пугают. «Специфика банковского IT среди прочего состоит в том, что при работе над сложными задачами не всегда удается за одну итерацию выдать продукт, который представлял бы ценность для клиента, – говорит Евгений Самойлов. – Из-за этого принципы Agile не всегда срабатывают дословно, но, тем не менее, польза от их использования по сравнению с водопадной моделью очевидна. Мы использовали водопад, но это было давно. Потребность в гибкости и способности быстро реагировать на изменения в потребностях клиентов одержала безоговорочную победу».
И все же, как негласно признают банкиры, то, что банки называют Agile, во многих случаях им не является. Разработчики применяют отдельные элементы гибкой методологии, смешанные с традиционной каскадной разработкой. Тут консервативность кредитных организаций идет только на пользу качеству программного обеспечения.
Кроме того, банки не применяют Agile слишком «глубоко». Agile много в быстро разрабатывающемся и динамично меняющемся под требования пользователей фронтенде, меньше в мидленде, и почти нет или совсем нет в бэкенде. Одно дело – описать пользовательскими историями мобильное приложение банковской разницы, другое – базу данных. Многие говорят о том, что вот-вот начнут применять Agile в разработке критических систем бэкенда, но годы идут, а успешных кейсов пока не слышно.
Новый король – DevOps
Следующей волной, активно обсуждаемой в сообществе, будет DevOps, возможности которого многие пока не осознают в полной мере. Нельзя сказать, что DevOps отрицает Agile – его, скорее, можно рассматривать как развитие не вполне реализовавшихся принципов гибкой разработки. Ключевая особенность подхода DevOps – активное взаимодействие разработчиков (Development), тестировщиков(QA) и служб эксплуатации и поддержки (Operations).
Автоматизированные инструменты позволяют связать все этапы работы над продуктом в единый конвейер, «выкатывающий» релизы из разработки в эксплуатацию за считанные часы. «Существенным плюсом применения DevOps инструментов типа CI (Continuous Integration)/CD (Continuous Delivery) для систем с тяжелым бэкендом является ускорение производственного цикла выпуска доработок систем такого вида в промышленную среду, уменьшение количества ошибок путем автоматизации тестирования», – отметил Андрей Сабынин.
Кроме того, DevOpsобеспечивает более полное понимание разработчиками таких аспектов, как производительность инфраструктуры, информационная безопасность, стоимость владения продуктом – все это приходит с фидбеком от Operations.
По словам Вячеслава Цыганова, DevOps в «Тинькофф» применяется активно: «DevOps позволяет нам решить две основные задачи: автоматизация процессов разработки, сборки и публикации задач (для ряда систем мы можем создавать среды для тестирования и релизить задачи нажатием одной кнопки) и увеличение скорости создания сред для быстрого пилотирования технологии под конкретную новую задачу. Теперь для тестирования новой технологии нам не нужно ставить и настраивать полноценное окружение. С помощью наших DevOps мы можем быстро настроить несколько разных сред, сравнить их и выбрать лучшую».
«Когда появился стек продуктов, позволяющих провести глубокую автоматизацию operations, мы сделали прототип конвейера, в который разработчики отправляют поставки, – рассказал FutureBanking Антон Исанин, начальник управления производительности дирекции архитектуры и стратегии Блока «Информационные технологии» Альфа-Банка. – Дальше прогоняются автоматические функциональные тесты, и готовится фидбек. Раньше было так, что разработчик отправлял поставку, потом, через 2-3 недели получал ответ из Operations – дефекты, несовместимость, и т.д. Поправить все это уже сложно, так как за это время разработка ушла вперед. С конвейером фидбек приходит часа через четыре, и это все в корне меняет».
Непрерывная, идущая практически в реальном времени от служб эксплуатации обратная связь не только ускоряет разработку, она позволяет эффективно реагировать на реальные нужды клиента. В отличие от Agile-методик, в DevOps активно задействованы администраторы и специалисты служб поддержки, которые напрямую имеют дело с пользователями продукта, и точно знают, что им от продукта нужно.
В недостатки DevOps можно записать то, что методология требует более глубокой перестройки IT в организации, нежели Agile .«Для эффективной реализации DevOps нужен сильный упор на автоматизацию, – утверждает Антон Исанин. – Нужен культурный сдвиг у Operations. Они поставляют средства автоматизации, становятся администраторами-программистами».
Чем глубже банк внедряет методологию гибкой разработки, тем более он нуждается в развитии культуры DevOps. По словам Антона Исанина, «если у нас вертикальный продукт, который мы разрабатываем с фронта до бека, для гибкой разработки обязательно нужно реализовывать автоматизированный DevOps на уровне мидла и бекенда. В идеале, до уровня АБС».
Мода на методологию гибкой разработки не проходит уже несколько лет, и вдохновенные Agile-евангелисты проникают во все более консервативные компании, гипнотизируя архитекторов, программистов и тестировщиков заклинаниями Scrum, Kanban, Lean. Даже столь неповоротливые организации, как банки, с гордостью демонстрируют свои успехи в освоении гибких подходов и рассказывают, какие небывалые вершины в пользовательском опыте им удалось покорить при помощи Agile.
Евгений Самойлов, начальник отдела информационных технологий банка для предпринимателей «Точка» (финансовая группа «Открытие»), подтверждает: «Мы используем Scrum в работе над продуктами, связанными с разработкой ПО, и не только — гибкий подход пригождается нам и в проработке бизнес-идей, и в прототипировании будущих решений».
Его коллеги по финансовой группе исповедуют несколько более осторожный подход. Андрей Сабынин, директор департамента развития систем розницы и малого бизнеса банка «Открытие», рассказал FutureBanking, что «команды в Открытии сформированы по кросс-функциональному принципу, то есть в рамках команды присутствуют не только специалисты по фронт-офисным решениям, но и разработчики интеграционных и учетных систем, таких как розничная АБС 3Card-R, корпоративная АБС ЦФТ, процессинговая системма Way4, интеграционная шина Tibco, вместе успешно работающие в рамках Scrum-методологии. Справедливости ради стоит сказать, что некоторые из команд придерживаются консервативных взглядов на производство и до сих пор реализуют доработки по водопадной модели. Примеры Agile команд банка: команда развития ипотечного бизнеса, карточная команда, команда развития малого бизнеса, digital».
Однако возникла и все ширится оппозиция Agile-течению. Высказываются мнения, что Agile «не взлетел», что с его помощью не сделать качественный продукт, или даже то, что современный Agile – вовсе не тот Agile, что 15 лет назад был описан в каноническом манифесте. Иными словами, ажиотаж вокруг гибкой методологии разработки нанес отрасли вред, и наполнил софт багами и уязвимостями.
Два года назад Gartner поместил Agile на самую вершину своего цикла зрелости технологий. Эта точка зовется «пик завышенных ожиданий». А за ней следует резкий спуск, заканчивающийся в нижней точке разочарования, куда мы неизбежно придем, как это всегда бывает с новыми технологиями. Или, похоже, уже пришли.
Критика Agile
Дейв Томас, один из авторов изначального «Манифеста гибкой методологии разработки программного обеспечения», считает, что ценности гибкой разработки, заложенные в манифест, так и не получили воплощения, а само обозначение Agile превратилось в маркетинговый термин, лишенный реального смысла. Да, манифест в свое время сломал оковы на разуме разработчиков, развенчав принципы разработки 80-х и 90-х, но дальше процесс пошел в непредсказуемом направлении, превратив Agile в набор жестких требований, которому разработчики пытаются слепо соответствовать, вне зависимости от их применимости в каждом конкретном случае. Похожего мнения придерживаются и многие другие его коллеги.
Agile отлично работает в разработке фронтенда, когда функциональность замыкается на пользовательском опыте, но в более сложных системах применение гибкой методологии катастрофически сказывается на качестве кода, вследствие отсутствия тщательно продуманной архитектуры продукта или отступления от нее в процессе разработки. Agile плохо масштабируется, не позволяя эффективно координироваться командам в создании тесно связанных кусков функциональности.
«Разработка нового продукта может затрагивать несколько систем. Чтобы синхронизировать их релиз, мы выбираем систему-лидера, ядро, которая выводит разработку первой задачи. Остальные задачи, в зависимости от критичности, подстраиваются. Иногда временные затраты на синхронизацию систем могут быть соизмеримы со временем разработки всего продукта, а то и превышать его», – рассказал Вячеслав Цыганов, вице-президент по информационным технологиям Тинькофф Банка.
Одним из традиционно слабых мест гибкой методологии является unit-тестирование, которое крайне трудно наладить в рамках небольшой команды. Наконец, внедрение и эксплуатация полностью оторваны от Agile-разработки, что радикально затягивает сроки готовности продукта, несмотря на то, что функциональность, казалось бы, успешно разрастается с каждой итерацией.
Agile и банки
При всем сказанном мы не наблюдаем серьезных проблем с качеством программного обеспечения у банков, применяющих гибкую методологию разработку – они вполне успешно учатся по ней работать. Так, Андрей Сабынин считает, что Agile применим на всех уровнях банковского IT: «бытует мнение, что разработку банковских бэк-офисных систем крайне сложно вести в режиме Agile из-за относительной сложности написания постановок на доработку бэк-офисного функционала, однако я не согласен с данным мнением. Действительно, практически невозможно в виде краткой пользовательской истории описать, скажем, альбом проводок какой-либо задачи, поэтому часть задач бэк-офиса будет требовать детального бизнес-анализа. При этом сложная бизнес-постановка почти всегда может быть разобрана на небольшие пользовательские истории, которые уже можно без проблем реализовывать итеративным образом в рамках Agile-подхода».
«Гибкая методология разработки Agile лучше всего подходит небольшим компаниям, которые создают продукт с нуля, – предупреждает Вячеслав Цыганов. – Крупные компании тоже могут работать по Agile, но ограниченно, например, при работе над выделенным проектом или бизнес-направлением. Главное условие, как ни странно, — готовность самой команды работать по Agile. Эта методология позволяет начать работу над проектом раньше, когда требования ещё не полностью понятны и формализованы. Но руководство должно быть готово к тому, что количество итераций и ресурсов в процессе может существенно измениться. Разработчики должны быть готовы к тому, что один и тот же продукт придется дорабатывать по несколько раз».
Трудности, отчасти обусловленные применением гибкой разработки, «Точку» не пугают. «Специфика банковского IT среди прочего состоит в том, что при работе над сложными задачами не всегда удается за одну итерацию выдать продукт, который представлял бы ценность для клиента, – говорит Евгений Самойлов. – Из-за этого принципы Agile не всегда срабатывают дословно, но, тем не менее, польза от их использования по сравнению с водопадной моделью очевидна. Мы использовали водопад, но это было давно. Потребность в гибкости и способности быстро реагировать на изменения в потребностях клиентов одержала безоговорочную победу».
И все же, как негласно признают банкиры, то, что банки называют Agile, во многих случаях им не является. Разработчики применяют отдельные элементы гибкой методологии, смешанные с традиционной каскадной разработкой. Тут консервативность кредитных организаций идет только на пользу качеству программного обеспечения.
Кроме того, банки не применяют Agile слишком «глубоко». Agile много в быстро разрабатывающемся и динамично меняющемся под требования пользователей фронтенде, меньше в мидленде, и почти нет или совсем нет в бэкенде. Одно дело – описать пользовательскими историями мобильное приложение банковской разницы, другое – базу данных. Многие говорят о том, что вот-вот начнут применять Agile в разработке критических систем бэкенда, но годы идут, а успешных кейсов пока не слышно.
Новый король – DevOps
Следующей волной, активно обсуждаемой в сообществе, будет DevOps, возможности которого многие пока не осознают в полной мере. Нельзя сказать, что DevOps отрицает Agile – его, скорее, можно рассматривать как развитие не вполне реализовавшихся принципов гибкой разработки. Ключевая особенность подхода DevOps – активное взаимодействие разработчиков (Development), тестировщиков(QA) и служб эксплуатации и поддержки (Operations).
Автоматизированные инструменты позволяют связать все этапы работы над продуктом в единый конвейер, «выкатывающий» релизы из разработки в эксплуатацию за считанные часы. «Существенным плюсом применения DevOps инструментов типа CI (Continuous Integration)/CD (Continuous Delivery) для систем с тяжелым бэкендом является ускорение производственного цикла выпуска доработок систем такого вида в промышленную среду, уменьшение количества ошибок путем автоматизации тестирования», – отметил Андрей Сабынин.
Кроме того, DevOpsобеспечивает более полное понимание разработчиками таких аспектов, как производительность инфраструктуры, информационная безопасность, стоимость владения продуктом – все это приходит с фидбеком от Operations.
По словам Вячеслава Цыганова, DevOps в «Тинькофф» применяется активно: «DevOps позволяет нам решить две основные задачи: автоматизация процессов разработки, сборки и публикации задач (для ряда систем мы можем создавать среды для тестирования и релизить задачи нажатием одной кнопки) и увеличение скорости создания сред для быстрого пилотирования технологии под конкретную новую задачу. Теперь для тестирования новой технологии нам не нужно ставить и настраивать полноценное окружение. С помощью наших DevOps мы можем быстро настроить несколько разных сред, сравнить их и выбрать лучшую».
«Когда появился стек продуктов, позволяющих провести глубокую автоматизацию operations, мы сделали прототип конвейера, в который разработчики отправляют поставки, – рассказал FutureBanking Антон Исанин, начальник управления производительности дирекции архитектуры и стратегии Блока «Информационные технологии» Альфа-Банка. – Дальше прогоняются автоматические функциональные тесты, и готовится фидбек. Раньше было так, что разработчик отправлял поставку, потом, через 2-3 недели получал ответ из Operations – дефекты, несовместимость, и т.д. Поправить все это уже сложно, так как за это время разработка ушла вперед. С конвейером фидбек приходит часа через четыре, и это все в корне меняет».
Непрерывная, идущая практически в реальном времени от служб эксплуатации обратная связь не только ускоряет разработку, она позволяет эффективно реагировать на реальные нужды клиента. В отличие от Agile-методик, в DevOps активно задействованы администраторы и специалисты служб поддержки, которые напрямую имеют дело с пользователями продукта, и точно знают, что им от продукта нужно.
В недостатки DevOps можно записать то, что методология требует более глубокой перестройки IT в организации, нежели Agile .«Для эффективной реализации DevOps нужен сильный упор на автоматизацию, – утверждает Антон Исанин. – Нужен культурный сдвиг у Operations. Они поставляют средства автоматизации, становятся администраторами-программистами».
Чем глубже банк внедряет методологию гибкой разработки, тем более он нуждается в развитии культуры DevOps. По словам Антона Исанина, «если у нас вертикальный продукт, который мы разрабатываем с фронта до бека, для гибкой разработки обязательно нужно реализовывать автоматизированный DevOps на уровне мидла и бекенда. В идеале, до уровня АБС».