- PVSM.RU - https://www.pvsm.ru -
Мы писали в блоге о технологиях в привычном айтишному миру понимании — о наших лучших практиках в разработке информационных систем. Сегодняшний пост посвящен технологиям другого толка — управленческим: мы поговорим об унификации аналитической деятельности в CUSTIS. Эта история о том, как изменить огромную и стабильную систему сложившихся с годами практик и направить ее навстречу проектам развития.
Когда наша компания занималась в основном заказной разработкой и создавала уникальные продукты, над проектом для каждого клиента трудилась одна команда на всем жизненном цикле системы.
Такой подход хорошо отвечал потребностям заказчиков, поскольку аналитик:
Эта модель стала неэффективной, когда мы начали переходить к созданию тиражируемых решений и работать одновременно над большим количеством проектов. Нам потребовалось быстро ротировать аналитиков между проектами и повторно использовать их артефакты, а из-за того, что один описывал действия пользователя в системе Visio, а другой — в Archi, возникали дублирование описаний и неразбериха с нотациями.
Мы поставили перед собой задачу выбрать и внедрить для всех проектных команд одну методику или набор методик, которые будут отвечать новым бизнес-задачам. В посте мы расскажем, как разрабатываем эту методическую основу.
Мы начали с того, что выделили три трека, в рамках которых будем проводить унификацию:
Затем мы проанализировали аналитическую деятельность в разных проектных командах и определили, что необходимо унифицировать:
В следующих разделах подробнее расскажем о результатах методического трека работ.
Мы выделили четыре типа проектов в компании, на которых нам важно уметь перемещать аналитиков:
Далее мы приступили к выделению тех понятий, в которых аналитики будут описывать создаваемые системы.
На UML-диаграмме (см. ниже) показаны концепты аналитической деятельности, которые мы выделили. Используя их, аналитики создают описание IT-системы и общаются.
Схема состоит из следующих элементов:
Подробно остановимся на основных концептах.
Чтобы использовать на практике концепты, нужно выбрать единый для всех инструмент моделирования. О нем — в следующем разделе.
О достоинствах и недостатках инструментов, обеспечивающих аналитическую деятельность, можно спорить бесконечно. Например, кому-то нравится развивать мелкую моторику на примере вот таких решений [1] для моделирования бизнес-процессов.
Наша компания много лет использовала гибкие методики разработки DDD (Domain Driven Design) [7] и инструменты Wiki [6]. Мы опирались на этот опыт и искали новые рыночные методики и инструменты аналитической деятельности.
Мы выписали возможные кейсы использования инструмента, опробовали их на нескольких проектах [9], пообщались с коллегами из других компаний и в итоге остановили выбор на Enterprise Architect [2].
Для нас были критичными такие параметры, как:
То, что мы предпочли этот инструмент, совсем не значит, что он подойдет и вам. При выборе своего инструмента постарайтесь собрать все ограничения и требования к нему, рассмотреть как можно больше сценариев того, как его используют ваши коллеги, и определить, насколько хорошо аналитики, разработчики, тестировщики и инженеры знают стандарты и нотации. Тогда в краткосрочной перспективе вам не придется переходить на новый инструмент.
Чтобы аналитик каждый раз не перечислял артефакты, которые нужно создать, мы разработали шаблон проекта в Enterprise Architect. Следующий раздел про него.
Когда мы создавали шаблон проекта, мы руководствовались потребностями разработчиков, тестировщиков, инженеров и заказчиков, а также распространенными в IT-отрасли стандартами и нотациями.
Существует несколько вариантов описаний требований. Узнать о них подробнее вы можете из материалов, указанных в списке литературы в конце статьи [1–4]. Мы постарались взять только варианты, необходимые для решения наших задач, и оставили те артефакты, которые используют в работе два и более человек в проекте с учетом жизненного цикла разработки системы.
В шаблоне проекта мы зафиксировали структуру папок и диаграмм в них, а также технологию наполнения диаграмм для различных видов проектов. Еще мы приводили не только перечень нотаций, но и их необходимые модификации, например, для выгрузки документации по ГОСТ, маппинга объектов одного уровня описания с другим.
Набор артефактов в шаблоне меняется в зависимости от типа проекта.
Желающие могут пройти по ссылкам ниже и посмотреть, что это за артефакты. В описании папок и диаграмм есть пояснения.
Еще раз напомню, для чего все мы здесь сегодня собрались.
Представленный методический трек — часть большой работы по унификации аналитической деятельности в компании CUSTIS. На момент написания статьи мы уже испытали методику на некоторых типах проектов.
На проектах типа RFI мы увидели несомненную пользу данной методики: она позволила повторно использовать функциональную и компонентную декомпозицию работ, а также методику оценки трудозатрат.
Впервые работая по предложенной схеме, мы создавали функции, компоненты системы и другие необходимые элементы и оценивали трудозатраты. При получении аналогичных RFI мы копировали уже созданные диаграммы и при необходимости делали небольшие корректировки, например изменяли состав функций и (или) компонент. Таким образом, нам удалось повторно использовать созданные артефакты и минимизировать время на оценку трудозатрат по аналогичным RFI.
На проектах по доработке существующих и разработке новых систем время создания аналитических артефактов «по-новому» оказалось меньше времени их разработки «по-старому» на 25–40%.
Мы сравнивали время, затраченное на разработку артефакта в новой методике, и экспертную оценку временных затрат каждого из работающих в проекте аналитиков на разработку артефакта «по-старому». Аналитик, впервые работавший по новым правилам, тратил больше времени на освоение методики, лучших практик и примеров, консультировался с более опытными коллегами, но после двух-трех итераций время на разработку диаграмм существенно уменьшалось.
Это продемонстрировано на диаграмме:
Мы не ставили перед собой цель уменьшить трудозатраты на разработку артефактов — нам было важно, чтобы это время не увеличилось критично и методика прижилась в компании. Тем отраднее было видеть, что затраты ресурсов стали снижаться, а люди разделяли ценности наших изменений.
Актуальной для нас остается задача обеспечить перемещение аналитиков внутри компании по подразделениям, которые работают с заказчиками из разных предметных областей. Мы поделимся успехами этой части, когда наберем достаточно наглядных примеров, на основе которых с уверенностью можно сказать, что трек внедрения начал приносить первые существенные результаты.
В следующих статьях мы также расскажем о том, как проверяем методологию: на какие параметры смотрим, чтобы понять, подходит ли выбранный метод к нашей работе — и поделимся опытом внедрения работы «по-новому» в действующих проектах.
Автор: oleolke
Источник [16]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/analitika/259473
Ссылки в тексте:
[1] вот таких решений: https://www.metasonic.de/en/touch
[2] Enterprise Architect: http://www.sparxsystems.com/products/ea/index.html
[3] Доработка существующих систем: https://drive.google.com/open?id=0B7q8XbLVArz7a1AyWUprSWRSRzQ
[4] Новый проект (автоматизация «с нуля»): https://drive.google.com/open?id=0B7q8XbLVArz7UXBwX1VScll3bVU
[5] Анализ request for information (RFI), предпроект, ведение бизнес-тем: https://drive.google.com/open?id=0B7q8XbLVArz7MUIyOTZsYWV3N28
[6] Реинжиниринг существующих систем: https://drive.google.com/open?id=0B7q8XbLVArz7UDdJWHA4a3BUVlk
[7] Разработка требований к программному обеспечению: http://www.ozon.ru/context/detail/id/1594986/
[8] Системноинженерное мышление: http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking_2015.pdf
[9] Use-Case 2.0: The Guide to Succeeding with Use Cases: https://www.ivarjacobson.com/sites/default/files/field_iji_file/article/use-case_2_0_jan11.pdf
[10] An Introduction to the ArchiMate 2 Modeling Language: https://www.opengroup.org/archimate/2.1/ArchiMate2_intro.pdf
[11] ArchiMate 3.0 Specification: http://pubs.opengroup.org/architecture/archimate3-doc/toc.html
[12] Модель системы — архитектура для Agile-разработки: https://www.slideshare.net/custisppt/agile-6999013?qid=3a13c0fc-1d0d-467a-b1cf-e8aa21f37244&v=&b=&from_search=2
[13] Domain Driven Design: модель вместо требования: https://www.slideshare.net/custisppt/ddd-2011?qid=3a13c0fc-1d0d-467a-b1cf-e8aa21f37244&v=&b=&from_search=31
[14] Как выбрать для проекта практики проектирования и работы с требованиями: https://www.slideshare.net/custisppt/ss-75701759
[15] Практика применения Enterprise Architect и T4-шаблонов для разработки системы на Microsoft SQL Serve: https://www.slideshare.net/custisppt/custis-enterprise-architect-t4
[16] Источник: https://habrahabr.ru/post/332018/
Нажмите здесь для печати.