что такое конфлюенс в тестировании
Как мы используем Confluence для разработки требований к продукту
В статье описаны наши подходы к использованию Confluence в качестве инструмента для работы с требованиями к продукту. Не претендуем на универсальность, но, возможно, эти подходы будут полезны для решения ваших задач, которые не обязательно связанны с процессами разработки требований (ведение пользовательской документации, описание внутренних регламентов работы отдела, организация базы знаний и пр).
Все изменения в требованиях к новой фиче на одной странице
Мы разрабатываем сложные Enterprise-продукты, которые тиражируются для сотен корпоративных заказчиков. В одном из наших продуктов больше ста функциональных модулей и у каждого модуля есть отдельный документ с требованиями. Фичи нового релиза, как правило, затрагивают несколько (от 3 до 20) функциональных модулей.
Чтобы понять все изменения в требованиях, проектная команда должна прочитать все документы, которые затрагивает новая функциональность, и вдобавок к этому, разобраться, что именно поменялось в каждом из них. Это долго и неудобно.
Для решения проблемы мы сделали сводный документ по каждой новой функциональности. Он содержит только изменившиеся части требований к функциональным модулям. При этом, если в исходном документе что-то изменится, это будет автоматически отражено в сводном документе.
Примерно так это выглядит в жизни:
Теперь проектной команде достаточно прочитать один документ, чтобы понять все изменения. Аналитик же один раз «собирает» документ и не беспокоится, что возникающие изменения нужно поддерживать сразу в двух документах.
Технически это реализовано с помощью плагина Multi Excerpt, который позволяет вставлять части одного документа в разные документы.
В документе с требованиями к функциональному модулю:
Текст изменившейся части требований обрамляется макросом MultiExcerpt. Если изменение небольшое (например, поменялась какая-то одна цифра или небольшое предложение), мы добавляем в макрос немного текста вокруг этого изменения, чтобы читатель понимал контекст.
На странице документа с новой функциональностью:
Добавляем макрос Multiexcerpt include. В нём указываем, какой блок из какой страницы нужно вставлять:
Готовая страница фичи в режиме редактирования выглядит примерно так:
Чтобы одним взглядом охватить и сразу понять статус всех требований по новой функциональности, мы добавили в сводный документ автоматически обновляемую таблицу с перечнем связанных требований, их статусами, ответственным аналитиком и кратким описанием изменений.
Делается это с помощью стандартных макросов «Отчёт о свойствах страницы» и «Свойства страницы».
На каждую страницу с требованиями к функциональным модулям добавляется метка (тэг) новой функциональности и макрос «Свойства страницы». В этот макрос добавляется стандартная таблица, в строках которой заполняются нужные свойства (на первый взгляд кажется сложно, но в документации всё подробно описано).
А на страницу фичи добавляется макрос «Отчет по свойствам страницы», в нем указывается метка фичи, а также список свойств, которые необходимо отображать.
«Трассировка» требований
Изменения в требованиях к одному функциональному модулю могут потребовать изменений и в других модулях. Если забыть про связанные изменения на этапе проработки требований, скорее всего, это станет известно на более позднем этапе (например, во время тестирования) и повлияет на сроки сдачи релиза. К сожалению, у нас бывали такие прецеденты.
Чтобы отследить влияние функциональных модулей друг на друга и не забывать о связанных изменениях в требованиях, мы используем функциональные возможности меток (тэгирование). Получается своего рода трассировка требований, но с крупным шагом: на уровне функциональных модулей, а не атомарных требований.
При более чем сотне функциональных модулей и их взаимосвязи даже такой крупный шаг трассировки позволил нам значительно сократить количество случаев, когда аналитик в процессе разработки требований к новой функциональности забывает учесть связанные требования.
Для этого мы используем стандартную функциональность меток в Confluence и макрос «Результаты поиска».
В режиме редактирования это выглядит так:
А читатель видит так:
Версионирование требований по релизам
Confluence в паре с плагином Scroll Versions позволяет для каждого нового релиза делать отдельную ветку требований, при этом у всех документов в каждом релизе остается собственная история изменений. Переключение между версиями релизов выполняется в пару кликов. Кроме того, можно сравнивать между собой требования как разных релизов, так и разных версий одного документа внутри одного релиза.
Так выглядит в жизни переключение между версиями релизов:
Комментирование
Для работы с комментариями мы используем плагин Talk.
От стандартного функционала комментирования в Confluence мы отказались, потому что у него были критичные для нас минусы:
Создание диаграмм и мокапов
Сначала мы использовали MS Visio и экспортировали схемы в растровый формат, а затем загружали в Confluence. Такой подход был неудобен — актуальность схем приходится поддерживать в двух местах, для этого нужно слишком много действий.
Как оказалось, в Confluence есть множество плагинов для работы с разного рода графическими объектами (диаграммы, схемы, мокапы и пр). Balsamiq Wireframes for Confluence и Draw.io Diagrams for Confluence позволяют редактировать графические объекты, не выходя из Confluence. На данный момент эти плагины почти полностью покрывают наши потребности.
Базовые возможности
Кратко расскажу о базовых возможностях, которые предоставляет Confluence (как и большинство других вики-систем). Чтобы не пересказывать документацию, ограничусь списком того, чем мы в основном пользуемся:
Переход с MS Word
Есть несколько неочевидных вещей, с которыми почти сразу сталкиваешься после перехода с Word на Confluence.
Нумерация заголовков
Чтобы добавить автоматическую нумерацию заголовков, нужно обрамить текст макросом Numbering headings.
Гиперссылка на раздел
Чтобы внутри документа сослаться на какую-нибудь часть документа или заголовок раздела, нужно сначала добавить макроc Anchor (в русской локализации он называется «Анкер»), а затем добавить гиперссылку на него из нужной части документа.
Так он выглядит в документе в режиме редактирования:
В официальной документации сказано, что ссылку на заголовок можно сделать и без макроса Ancor, но тогда ссылка будет терять работоспособность при изменении текста заголовка.
Цвет фона текста
Для заливки мы используем такой код:
Подставьте RGB-код нужного вам цвета.
Для любителей автоматизации есть еще один лайфхак: можно сначала в визуальном редакторе изменить цвет текста, а потом в режиме редактирования исходного кода страницы с помощью регулярных выражений сделать автозамену HTML-разметки выделения текста цветом на заливку.
Это не очень удобно, но другого способа выделять текст заливкой мы пока не нашли.
Из минусов:
Проектирование в Confluence
Меня зовут Маша, я работаю инженером по обеспечению качества в группе компаний Тинькофф. Работа QA предполагает множество коммуникаций с разными людьми из разных команд, а я к тому же была менеджером и лектором образовательных программ, поэтому моя карта коммуникаций была максимально широкой. И в какой-то момент я взорвалась: я поняла, что больше не могу, не могу, не могу заполнять адовые тонны нечитаемых таблиц и документов.
Наверняка каждый из вас представил себе сейчас то, о чем я говорю, и облился холодным потом: списки фамилий без алфавитного порядка, таблицы в сотни столбцов со съехавшей версткой, таблицы в тысячи строк, в которых нужно стирать свой палец об колесико мыши, чтобы посмотреть заголовок, тонны страниц непронумерованных инструкций, сотни пересылаемых друг другу писем с данными, которые надо проанализировать и систематизировать и запихнуть в такие же нечитаемые таблицы.
И вот, когда я немного остыла, я решила написать эту статью. Я расскажу о том, как можно нормально (даже порой удобно) вести разнообразную непродуктовую документацию. Надеюсь, что статья разлетится по сети и уровень адища в соседних с разработкой отделах хоть чуть-чуть снизится, а люди (и я в том числе) станут чуточку счастливее.
Инструменты
Продуктовая документация часто хранится рядом с кодом, и это хорошо. А непродуктовая документация обычно хранится где попало. Часто люди стараются переносить информацию из разных мест в Confluence, и мы не исключение. Так что весь дальнейший рассказ о нем.
Вообще Confluence — это продвинутый вики-движок. Он позволяет работать с данными в разных видах отображения: текст с форматированием, таблицы, разнообразные диаграммы. Это очень интересный и мощный инструмент, но если не уметь его готовить, то вы получите очередную свалку нечитаемых документов. Я научу вас готовить!
Макросы
Почти вся магия Confluence строится на макросах. Макросов очень много, и их можно комбинировать друг с другом. Они бывают платными и бесплатными, далее будут разные примеры макросов со ссылками на документацию для них.
Интерфейс работы с макросами максимально прост. Чтобы добавить макрос, надо нажать на плюс и выбрать нужный элемент из списка.
Если макрос самодостаточный, то есть не требует вставки чего-то еще внутри себя, — он выглядит как блок.
Если для работы макроса нужно что-то поместить внутрь него, он выглядит как рамка.
При этом можно помещать внутрь одной рамки сколько угодно других, лишь бы в вашей пирамиде была логика.
У каждого макроса есть предварительный просмотр: в нем сразу видно, правильно ли вы заполнили и настроили макрос.
Шаблоны
Помимо макросов есть удобный инструмент предзаполнения контента — это шаблон.
Шаблоны можно использовать при создании любой страницы: просто нажать на три точки рядом с кнопкой «Создать» и выбрать нужный шаблон.
Тогда в созданную страницу добавится весь контент, который есть в шаблоне.
Создавать страницы из шаблонов может кто угодно, а вот создавать или редактировать сами шаблоны — только те, у кого есть на это права. В шаблон можно добавить дополнительные инструкции о том, как следует вести страницу.
Магия таблиц
Вообще-то я, как технарь, нежно люблю таблицы и могу почти любую информацию в них завернуть (хотя это и не всегда эффективно). Сами по себе таблицы четкие, структурированные, масштабируемые, волшебные!
Но даже такую замечательную сущность, как таблица, можно испортить. А можно удачно использовать и даже улучшить. Об этом ниже.
Фильтрация (платный плагин)
Любую огромную нечитаемую таблицу можно сделать чуть менее огромной и чуть более читаемой с помощью фильтрации. Для этого можно использовать платный макрос «Фильтр таблиц».
Внутрь этого макроса надо засунуть таблицу (можно даже самую уродливую, главное — запихнуть ее целиком). В макросе можно выбрать столбцы для фильтра с выпадающим списком, текстового фильтра, числового и фильтра по датам.
Вот представьте, что всю информацию по кандидатам на все вакансии записывают табличным списком. Естественно, неотсортированным — люди же приходят на собеседования не по алфавиту. А вам надо понять, проводили ли вы собеседование с конкретным соискателем раньше. Надо просто засунуть этот ад в макрос фильтра, добавить текстовый фильтр по фамилии — и вуаля, информация у вас на экране.
Стоит отметить, что фильтрация огромных таблиц может влиять на работу системы и время загрузки страниц, поэтому засунуть огромную таблицу в фильтр — временный костыль, лучше выстроить процесс, в котором людям не приходится создавать огромные нечитаемые таблицы (пример процесса будет в конце статьи).
Сортировка (платный плагин)
С помощью волшебного макроса «Фильтр таблиц» также можно задать сортировку по умолчанию по любому столбцу и пронумеровать строки. Или нажать на любой столбец таблицы, засунутой в макрос фильтра, и произойдет сортировка по этому столбцу.
Например, у вас есть та же самая таблица с соискателями и надо прикинуть, сколько собеседований было проведено в определенный месяц, — сортируйте по дате и радуйтесь.
Сводные таблицы (платный плагин)
Теперь перейдем к кейсу поинтереснее. Представьте, что ваша таблица огромная и надо что-то посчитать по ней. Конечно, можно скопировать ее в Excel, посчитать нужное и выгрузить данные назад в Confluence. А можно один раз применить макрос «Сводная таблица» и получить тот же результат, только еще и обновляемый.
Например: у вас есть таблица, в которой собраны данные всех сотрудников — где они территориально находятся и какие должности занимают. Чтобы посчитать, сколько человек находится в каждом городе, вам нужно выбрать в макросе «Сводная таблица» строку, по которой агрегируются данные (местоположение) и тип операции (сложение).
Естественно, группировать можно по нескольким признакам сразу, все возможности можно посмотреть в документации.
Диаграммы (платный плагин)
Как я уже говорила, не все любят таблицы так сильно, как я. К сожалению, менеджеры в большинстве своем их вообще не любят. Зато все очень любят яркие цветные диаграммы.
Создатели Confluence об этом, безусловно, знали (наверняка у них тоже есть начальство, которое любит отчеты и диаграммы, куда же без него). Поэтому можно воспользоваться волшебным макросом «Диаграмма из таблицы». В этот макрос нужно положить сводную таблицу из предыдущего пункта, и вуаля — ваши серые скучные данные красиво визуализированы.
Естественно, в этом макросе тоже есть настройки. Ссылку на документацию к любому макросу можно найти в режиме редактирования этого макроса.
Простота агрегации
Информация из предыдущих пунктов наверняка не была для вас откровением. Но теперь вы точно умеете пользоваться макросами, а я могу перейти к более интересной части статьи.
Метки
Плохо, когда люди хранят информацию в одной неструктурированной статье или огромной таблице. Еще хуже — когда части этой информации не только нечитаемо оформлены, но и раскиданы по просторам Confluence. Благо есть возможность собрать раскиданную информацию в одном месте. Для этого надо воспользоваться метками (знакомыми всем по соцсетям тегами).
На любую страницу можно добавить любое количество меток. Если нажать на метку, вы попадете на страницу агрегации, где есть ссылки на все материалы с этой меткой, а также с набором связанных меток. Связанные метки — это те, которые часто встречаются на одной странице.
Свойства страниц
На страницу можно добавить еще один интересный макрос для структурирования информации — «Свойства страниц». Внутрь него нужно подать таблицу из двух столбцов, первый будет являться ключом, а второй — значением свойства. Причем макрос можно скрыть со страницы, чтобы он не мешал читать контент, но при этом страница все равно будет отмечена нужными ключами.
Обратите внимание на ID — его удобно задавать, чтобы навешивать разные группы свойств на разные страницы (или даже разные группы свойств на одну страницу).
Отчеты
По меткам можно собирать отчеты. Например, макрос «Отчет о содержимом» собирает все страницы с определенным набором меток.
Но более интересный отчет — это макрос «Отчет по свойствам страницы». Он тоже собирает все страницы с определенным набором меток, но не просто выводит их список, а составляет таблицу (улавливаете связь с началом статьи?), в которой столбцы — это ключи свойств страницы.
Получается сводная таблица по информации из разных источников. Приятно, что у нее есть удобные функции: адаптивная верстка, сортировка по любому столбцу. Также такую отчетную таблицу можно конфигурировать внутри макроса.
При конфигурировании можно убрать из отчета какие-то столбцы, задать состояние по умолчанию или количество отображаемых записей. А еще можно задать ID свойства страницы, чтобы видеть только нужную информацию.
Например, у вас есть множество страниц сотрудников, у этих страниц есть набор свойств про человека: какого он уровня, где находится, когда пришел в команду и так далее. Это свойства отмечены ID = employee_inf. И есть второй набор свойств на этой же странице, в котором собрана информация о человеке, как о части команды: какую роль человек выполняет, в какой команде находится и так далее. Эти свойства отмечены ID = team_inf. Тогда при сборке отчета вы можете вывести только информацию по одному айдишнику или сразу по двум — как удобнее.
Прелесть такого подхода в том, что каждый может собрать нужную для себя информационную таблицу, которая не будет ничего дублировать и будет обновляться при обновлении основной страницы. Например: тимлиду не важно, когда его разработчики устроились на работу, но важно, какую роль каждый из них выполняет в команде. Тимлид соберет себе отчет по команде. А бухгалтеру вообще все равно, кто какую роль выполняет, но важны должности — он соберет себе отчет по должностям. При этом источник информации не будет дублироваться или переноситься.
Итоговый процесс
Инструкция
Итак, мы можем красиво структурировать и эффективно агрегировать информацию в Confluence на примере использования макросов. Но в идеале нужно сделать так, чтобы новая информация сразу была структурированной и попадала во все уже используемые механизмы агрегации.
Тут на помощь придет связка макросов и шаблонов. Чтобы заставить людей создавать новые страницы в нужном формате, можно использовать макрос «Создать из шаблона». Он добавляет на страницу кнопку, по нажатию на которую создается новая страница из нужного вам шаблона. Таким образом вы заставляете людей сразу работать в нужном вам формате.
В шаблон, из которого вы даете создавать страницу, нужно заранее добавить метки, макрос «Свойства страницы» и таблицу нужных вам свойств. Также рекомендую добавить инструкции о том, какими значениями следует наполнять страницу, и значения свойств.
Тогда итоговый процесс будет выглядеть так:
Подводные камни
Как инженер по качеству, я смело могу утверждать, что ничего идеального в мире нет. Даже божественные таблицу неидеальны. И в приведенном выше процессе есть подводные камни.
Пример хранения непродуктовой документации
Через описанный выше процесс можно организовать хранение почти любой информации. Прелесть подхода в том, что он универсальный: когда пользователи к нему привыкают, они перестают генерировать бардак. Также большой (но не бесплатный) плюс — возможность собирать на лету разнообразную статистику и рисовать по ней красивые диаграммы.
Приведу пример нашего процесса ведения информации о команде.
Для каждого человека в команде мы решили создать карточку сотрудника. Соответственно, у нас есть шаблон, по которому каждый новый человек создает себе эту карточку и ведет в ней всю личную информацию.
Как видите, у нас развернутая таблица свойств и сразу есть инструкции о том, как именно вести данную страницу. Часть тегов проставляют сами сотрудники по инструкциям, в шаблоне только основные: тег карточки employee-card, тег направления direction-involve и тег команды team-qa.
В итоге после того, как каждый создал себе карточку, получается полная таблица с информацией по сотрудникам. Эту информацию можно использовать в разных точках. Ресурсные менеджеры могут собрать себе общие таблицы, а лиды команд — командные таблицы, добавляя в выборку тег команды.
По тегам можно увидеть разные сводки, например по qa-upgrade-plan отобразатся все задания на развитие QA. При этом каждый человек в своей карточке сотрудника ведет важную историю и свой план развития — создает вложенную страницу из шаблона планов развития.
Заключение
Ведите любую документацию так, чтобы за нее не было стыдно, а пользователям не было мучительно больно!
Очень надеюсь, что статья будет полезна и во всех документациях мира наступит порядок.
Использование JIRA и Confluence в большом проекте
Начало нового проекта как правило сопровождается решением массы организационных вопросов: как будут взаимодействовать участники проекта, где будут храниться документы и как будет построено их согласование, как будут ставить задачи и выдавать поручения… В каждой компании, у каждого руководителя проектов, уже есть заготовки и предпочтения. Но всегда полезно посмотреть, как это делают другие. Поэтому предлагаю познакомиться с примером из практики, который вышел весьма удачным.
Для организации работы проектной команды необходим единый информационный центр, с помощью которого решаются следующие задачи:
Портал проекта — Confluence
Confluence — это удобный и продвинутый wiki движок от компании Atlassian. Он позволяет организовать внутренний интернет портал и дать доступ к нему всем пользователям — для редактирования или для чтения.
Проектный портал содержал все проектные материалы, часть которых мы сделали в виде иерархии страниц.
Верхний уровень иерархии — это этапы проекта. На каждом этапе создали страницы-ключевые задачи этапа. Причем на каждой странице — описание задачи, каково ее содержание, зачем она необходима, кто ее выполняет, приложены шаблоны документов.
Все контрактные документы, которые должны сдаваться в качестве результатов проекта, выкладывали на соответствующую страницу в Word, Excel или pdf. Таким образом все проектные материалы, были в одном месте, структурированы, и не было путаницы с версиями.
Масса полезной информации мы организовали в виде специальных страниц. Например, для большой команды крайне популярной является контактная карта, на которой у нас был список проектной команды по группам, с фотографиями и данными участников.
Страница со ссылками на экземпляры системы поддерживались системными администраторами. Там же была схема эволюции технической инфраструктуры — когда какие экземпляры появлялись и выводились из эксплуатации.
Процедуры и регламенты
Собрание всех инструкций и проектных регламентов на портале, в актуальном и удобном для чтения виде позволяет экономить на объяснениях новым участникам и бороться с отговорками «не прочитал, не нашел, не видел». Когда вопрос все-таки возникает, можно выслать ссылку на страничку, чтобы не пересылать документ и тратить время на его поиск. Версия — всегда актуальная, т.к. обновление происходит непосредственно на портале.
Риски и открытые вопросы
Мы вели на портале риски и открытые вопросы. На каждый риск или вопрос мы заводили отдельную страницу, по заранее созданному шаблону. На странице риска, кроме обязательных названия и классификаторов, было подробное описание содержания, последствий, а также план действий со сроками и ответственными, и статус риска. Примерно так же были организованы открытые вопросы.
Специальная страница автоматически собирала список страниц с рисками, образуя таким образом реестр рисков.
Просматривая список можно перейти на соответствующую страницу, прочитать описание риска и посмотреть план действий по нему.
План действий может представлять из себя простой текст, задачу в Confluence или ссылку на задачу в JIRA.
Рассмотрим варианты, которые можно использовать, которые позволяют напоминать о действиях участникам и контролировать их исполнение.
Задача в Confluence — это отдельная сущность, которую можно добавить на страницу. Напоминание о задаче высвечивается для пользователя, когда он входит на портал, значком в правом верхнему углу. Кликнув по этому значку пользователь переходит к списку своих поручений. Когда задача выполнена, он ставит галочку, и статус задачи меняется за завершенный.
Однако так же точно можно снять галочку и задача опять становится не выполненной. Поэтому такая система выглядит не очень надежно и контроль за поручениями в этом случае слабый.
Второй вариант — использование для поручений задач в JIRA. Непосредственно со страницы проектного портала можно создать задачу в JIRA, назначить ответственного и установить срок исполнения. Для этого мы сделали специальный макрос, срабатывающий по кнопке Создать поручение.
В отличие от предыдущего варианта эта задача может быть настроена так, чтобы ее мог закрыть только ответственный, отличный от исполнителя, что дает хороший контроль ее выполнения.
Практика, которой мы придерживались, помогала нам сохранять все решения, которые мы принимали на совещаниях. В ходе каждого совещания мы вели протоколы непосредственно на портале проекта. В начале каждого совещания мы создавали новую страницу протокола на основании шаблона, и записывали основные моменты по ходу обсуждения. В конце формулировали решение и план действий.
Если кто-то после совещания хотел уточнить текст протокола, тот мог это сделать прямо на страничке портала, и было видно, кто и когда какие изменения внес. Протокол считался согласованным сразу после совещания, это экономило массу времени.
JIRA — Система для ведения списков, поручений, задач
JIRA создана как система регистрации и исполнения запросов на обслуживание. Однако она может быть использована для ведения любых реестров и управления любыми задачами.
В нашем проекта мы использовали JIRA для контроля исполнения поручений, ведения разработок и отслеживания задач по конвертации данных.
Ведение разработок с помощью JIRA подробно описано в статье Управление разработками. Здесь я расскажу о контроле поручений и интеграции с Confluence.
Для создания задачи JIRA из Confluence достаточно выделить текст, навести курсор на выделенный текст и нажать кнопку в контекстном меню, чтобы вызвать экран JIRA для создания задачи.
На странице протокола появится ссылка на задачу, а в задаче JIRA будет ссылка на страницу в Confluence.
Таким образом мы можем переходить между этими двумя системами, с одной стороны, чтобы уточнить состояние и историю исполнения поручения, а с другой — посмотреть контекст и причину возникновения задачи.
Интеграция между системами также помогала нам отслеживать списки открытых вопросов, связанными с разработками.
В конце проекта, когда остался список критичных разработок, которые необходимо было закрыть для завершения проекта, мы организовали его в виде таблицы на странице портала проекта, в одной из ячеек которой была ссылка на разработку в JIRA. Кроме номера задачи там отображается и текущий статус. Просматривая список мы можем видеть, какие задачи еще не закрыты, в каком состоянии они находятся, и при необходимости можем перейти к ней, чтобы увидеть всю историю и переписку по ней.
Работа с JIRA требует определенной квалификации и опыта. Здесь я описал некоторые варианты использования, однако на самом деле их гораздо больше. Прелесть в том, что можно начать с самых базовых вещей, и это уже будет работать, а затем развивать систему по мере приобретения опыта и понимания потребностей.
Кроме Confluence, в интеграции с JIRA, мы также использовали BitBucket, также продукт Atlassian — репозиторий разработок, позволяющий отслеживать версии кода. Для этих же целей на другом проекте использовали бесплатный SVN.
Множество плагинов позволяет расширять функциональность системы, в частности, для интеграции с MS Project или реализации диаграммы Гантта непосредственно в JIRA.
Большое количество вариантов использования может стать препятствием для тех, кто берется за использование этих инструментов в первый раз. В этом случае можно воспользоваться опытом других проектов, которых великое множество, либо начать с самого простого.
Организация проектного пространства с помощью JIRA и Confluence доказало свою эффективность и удобство. Ключевые преимущества — это удобство, надежность и широчайшие возможности для адаптации. На наших проектах такая системам стала стандартом де факто.