2017-11-02: встреча по визуальным моделям в Раййфайзенбанке — супер!

(Из ленты MaksWiki — Блог:Максима Цепкова [ru])

Вчера был на мини-конференции Райффайзенбанка Использование визуальных моделей в ИТ. Полдня, 150+ участников, 5 выступлений. В трех из них — реальный опыт использования Enterprise Architect в Касперском, Райффайзенбанке и ЛАНИТе. Что надо отметить — опыт очень разный и дополняющий друг друга и это — особенно интересно.

Ира Сурова из Касперского рассказывала, что они используют EA для единообразного ведения требований. В 2010 у них в R&D всех аналитиков собрали в единый отдел по специализации для управления ресурсами, но при этом аналитики работают в проектах, и в каждом проекте — внимание — свой подход к ведению проекта. Определяемый PM. И это — логично, потому что в R&D бессмысленно нормировать процесс. Да и проекты у них очень разнообразные и их много. А прогресс движения проекта — оценивают независимо от внутренней организации. И аналитик должен поддержать тот процесс, по которому работает команда. Аналитики в отделе Ирины отвечают именно за требования, архитектура — прерогатива разработчиков и те ревниво относятся к нарушению границы «если аналитик нарисовал диаграмму классов — она неправильная» (Disclaimer: цитата — неточная, воспроизведена по памяти, и далее — тоже). А по требованиям надо поддерживать текущее состояние продукта и его изменения, потому что для разработчиков важно уметь представлять требования именно в формате задач — что ему надо изменить в системе, а вот для тестировщиков, и для последующей работы — фиксировать состояние системы. И именно поэтому им потребовалась автоматизация, ведение в виде документов просто не позволяло так гибко работать. А тут единицей требований у них является use case, и дальше они их классифицируют по темам и резлизам и делают выгрузку текстовых документов. Потому что разработчикам, оказывается, диаграммы — не нужны, и модель смотреть они тоже не хотят.

Методика, как вести требования и изменения — достаточно тяжелая, у EA тут свои ограничения, с которыми приходится бороться, потому что честной версионности репозитария он не обеспечивает (да, можно хранить репозиторий в svn, но с этим проблемы), и ряд других сложностей. Поэтому методика у них — общая. Но при этом ряд проектов работает с «легкой» версией, используя EA просто как каталог, оглавление use case, а сами требования ведут в отдельных документах. Оглавление при этом испольхуется, потому что EA интегрирован с TFS, в котором отслеживается прогресс движения проектов.

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

Максим Шаломович и Денис Епишев из ЛАНИТ тоже рассказывали про ведение требований в EA, но на примере одного проекта, потому что проекты у них сильно разные и общей практики ведения требований в компании нет. Проекту примерно три года и он развивается, требования часть меняются. Что интересно, они решили ту задачу, которую не получилось сделать в Касперском: они передают разработчикам не выгруженный из EA документ, а саму модель. И архитекторы делают в ней детальный дизайн, а по необходимости — делают выгрузки. И диаграммы на UML разработчики тоже хорошо читают. Внешним подрядчикам тоже могут передать модель, вернее, фрагмент модели, или выгрузку в документ. Что интересно — разработчики уже освоились, и на попытки «срезать углы» и что-то написать в тексте — справшивают «а где модель, так не пойдет». Верифицируют модель на полноту, фиксируют что не проработано — и ставят баги, а не додумывают за аналитиков.

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

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

А Юрий Карабутов и Дмитрий Столяров рассказывали про опыт Райффайзена. Они используют EA совсем по-другому, для описания архитектуры IT-ландшафта банка. В котором 300+ достаточно интегрированных систем, которые непрерывно развивают 50+ команд разработчиков, при этом идет 100+ инициатив одновременно, затрагивающих по нескольку систем. Описание всего этого они и ведут в EA. Структура описания текущего состояния такая.

  • Бизнес-уровень
    • capability — описание бизнес-области
    • service — типа «открытие счета»
    • use case — как именно открывают счета (удаленно, конвейер, бранч)
    • business object
  • Уровень приложений
    • application — отдельная система, строгого определения, что считать отдельной системой нет, опираются на традицию
    • component — от единственной в маленьких системах до 4-уровневой структуры в больших
    • interface — для описания взаимодействия между системами

Проект изменений — Solution создается копированием скриптами в новую модель из описания текущего состояния интересующей части модели, при этом на элемент-источник делают связи. На бизнес-уровне добавляется описание требований, под которыми они понимают пожелания бизнеса разной степени формализации, что, скорее, соответствует нуждам стейкхолдеров (needs), а не requirements. Пожелания ведутся во внешней системе и оттуда импортируются. А дальше для удовлетворения этих пожеланий элементы описания изменяются, добавляются новые, старые помечаются как удаленные, и это все трассируется. При этом регламент изменений — тоже на людях, и консистентность модели поддерживается ночными проверками, выявляющими проблемные объекты, восстанавливающими связи, где возможно, пересобирающими различные сводные диаграммы и отчеты. Такая вот сложная конструкция у них живет и обеспечивает управление IT-ландшафтом банка.

А вот мой доклад Визуальные модели корпоративного приложения (Meetup в Райффайзенбанк 2017-11-01) был не про EA. Он был про различные диаграммы, которые мы использовали и используем в разработке корпоративных приложений для описания бизнес-уровня и для проектирования самого приложения. Для корпоративных учетно-аналитических приложений мы используем собственный шаблон Учетной машины, о котором я рассказывал в ряде докладов, последний из них DDD — модель вместо требований (Максим Цепков на AnalystDays-2014). Шаблон построен на основе Domain Driven Design, в нем используется модель, для описания которой используются диаграммы классов, активности и разработанные нами диаграммы учета. И именно на нем был фокус в моем выступлении, а примеры диаграмм были расширены теми, которые используются для описания архитектуры предприятия и места в нем разрабатываемой системы, а также представления ее через метафору системы. Были примеры диаграмм в свободной нотации, которые, кстати, обычно лучше воспринимаются заказчиками, чем формальные диаграммы, и диаграмм в UML и Archimate, сделанных в Visio и EA. У нас в компании в последних проектах тоже используется, но не он был в фокусе доклада.

И еще один доклад делала Наталья Желнова. Она в режиме демонстрации показывала работу в Bizagi modeler — как от описания бизнес-процесса в BPMN перейти к use case. Правда, на модельном примере — к сожалению, живые проекты, которые она ведет Центре развития технологий Сбербанка она показать не могла.

У остальных выступающих, кстати, на ряде слайдов текст не читаемый или условные номера вместо букв, и они предупреждали, что это тоже по соображениям безопасности. Организаторы вели видеозапись и обещают ее опубликовать вместе с презентациями (моя уже доступна на странице доклада). Будем ждать. Хочу сказать им большое спасибо за организацию встречи! И надеюсь на продолжение.

Источник