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

Короткая ссылка: VisualModelMeetup-2017-11

Вчера был на мини-конференции Райффайзенбанка Использование визуальных моделей в ИТ. Полдня, 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. Правда, на модельном примере - к сожалению, живые проекты, которые она ведет Центре развития технологий Сбербанка она показать не могла.

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