Глоссарий проекта

Вы ведете глоссарий проекта? Вы даже не знаете что это такое? А зачем он нужен?

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

Замечали, когда, вы приходите в проектную команду, которая довольно давно работает над проектом, то первое время вы чувствуете себя несколько неуютно из-за того, что люди вокруг вас говорят на каком-то особенном, своем языке. Они используют названия модулей, краткие названия каких-то фич, состояний, ситуаций, форм, ролей, документов, мэйлстоунов и много еще чего, что для свежего уха превращается в какой-то совершенно не понятный «птичий язык». Это все - глоссарий проекта. Он существует независимо от того, фиксируете вы его в документе или нет. Он появляется в первые дни работы над проектом, когда появляется первое рабочее название будущей системы, и очень активно формируется в последующие дни, во время бесед с заказчиками и обсуждений внутри команды. Фиксировать его на бумаге или нет - ваше дело. Но я смею утверждать, что глоссарий проекта это документ из тех, что больше нужен вам (проектной команде), чем заказчику, а потому сформировать его и поддерживать в рабочем состоянии весьма полезно.

Глоссарий входит в число необходимых документов во всех «тяжелых» методиках разработки (RUP, MSF). Но и для гибких (agile) методик, глоссарий, относится к вещам, которые лучше иметь, чем не иметь. Основополагающим принципом всех agile методик является поддержка внутри - командных коммуникаций на самом высоком уровне. Согласитесь, сложно общаться, не зная языка, а глоссарий – это и есть язык, на котором говорит команда. Для ведения глоссария вполне подходят wiki системы, хотя мне больше по душе простой лист бумаги.

Важная функция, которую должен выполнять глоссарий, это установление соответствия между терминами заказчика (предметной области) и терминами архитектуры системы. Это особенно важно для тяжелых методик, в которых проектные роли аналитика, архитектора, разработчика и тестировщика выполняют разные люди. Типичный пример – наименования состояний объектов. На уровне требований и пользовательского интерфейса они имеют свои имена. Когда мы спускаемся на уровень дизайна и реализации - те же вещи называются по-другому. Учитывая, что требования (use cases) и дизайн (design models) описаны в разных документах возникает путаница и всякие нелепые ошибки.

Что стоит включать в глоссарий? Реально глоссарий содержит всю специфическую для проекта терминологию, используемую в своей работе проектной командой. Вероятно, не стоит фиксировать на бумаге жаргонизмы, наподобие «финики» (роль пользователя системы - финансисты), и «юрики» (то же – юристы). Не место в глоссарии названиям проектных серверов, репозиториев и прочей технической информации.
В глоссарии желательно зафиксировать:

• названия основных прецедентов использования, в форме понятной пользователю и заказчику системы, сопроводив их небольшим (не больше одного предложения) описанием. Это нужно, в первую очередь разработчикам (как ни странно)


• названия всех понятий (сущностей) предметной области (домена приложения) в форме понятной пользователям и названия соответствующих им классов (объектов, модулей), если такое соответствие существует.


• названия и значения ключевых свойств сущностей предметной области. Например, для системы обработки заказов, таким ключевым свойством может быть «стоимость заказа», с описанием из чего она состоит и как формируется.


• термины предметной области, которым не соответствуют какие либо сущности в системе, но которые важны для понимания предметной области. Например, названия бизнес операций или бизнес процессов.


• названия основных модулей и блоков системы, названия подсистем и их назначение


• названия состояний сущностей системы и соответствующие им системные названия.


• синонимы. Важно отразить, что для обозначения одного и того же понятия могут использоваться разные названия.


• роли пользователей