Devprom ALM: Руководство пользователя

Не бывает одного верного процесса разработки. Разные типы продуктов, клиенты, сложность, состав команды и многое другое влияют на процесс, который позволит эффективно вести разработку ПО. Мы упаковали "в коробку" несколько типовых процессов для наиболее распространенных ситуаций.

Начните с использования "коробочного" процесса и настройте его таким образом, чтобы он отражал специфику именно вашей команды, проекта или организации.

Тонкая настройка процесса заключается в следующем:

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

Выполненные настройки затем можно сохранить для повторного использования в качестве процесса. На базе этого процесса можно создавать новые проекты и активности, либо применять эти настройки к ранее созданным проектам и активностям.

Управление процессами

• Для создания вашего процесса сперва нужно создать проект и выполнить в нем все необходимые настройки. После этого необходимо перейти к настройкам проекта и выбрать опцию "Создать процесс". Укажите название процесса и имя файла, в котором процесс будет сохранен. Название процесса будет отображаться на экране создания нового проекта или активности.
• Чтобы обновить настройки процесса, перейдите к проекту на основе которого был создан процесс, измените необходимые настройки процесса, перейдите настройкам проекта и выберите опцию "Обновить процесс". Чтобы эти изменения применились ко всем проектам, созданным на основе этого процесса, отметьте соответствующую галочку.
• Если вы хотите изменить процесс у проекта, достаточно перейти к настройкам проекта и выбрать опцию "Применить процесс".

Управление списком ранее созданных процессов осуществляется в административном разделе приложения, в меню Проекты - Процессы.

Все основные проектные артефакты имеют свой жизненный цикл (ЖЦ), который используется для управления этими артефактами. Первичные требования (пожелания) создаются, прорабатываются, реализуются, тестируются и т.п. Каждый статус (этап) связан с технологией производства. Системные требования в свою очередь разрабатываются, утверждаются, согласуются и затем реализуются. Эти статусы связаны с разработкой и документированием требований.

С каждым статусом могут быть связаны:

• цвет, который будет использован при окрашивании фона с текстом статуса;
• настройки полей формы - возможность переопределить видимость/обязательность полей на форме редактирования или создания артефакта;
• системные действия - внутренние триггеры, которые срабатывают при назначении этого статуса проектному артефакту.

Система отслеживает время, которое артефакт находится в каждом состоянии. Поле "Время в состоянии" отображает это время и может быть выведено в списках или на досках. Система также считает общую длительность жизненного цикла. Чтобы узнать, например, сколько времени мы разрабатывали конкретный раздел документа. В некоторых состояниях команда не работает с артефактом, например, ждем согласования от заказчика. Чтобы время ожидания не искажало продолжительность жизненного цикла, его можно исключить из учета установив галочку "Исключить из времени решения время нахождения в этом состоянии".

Базовое состояние позволяет понять системе, на каком участке ЖЦ находится артефакт - он только что создан, он находится в работе или работа над ним завершена, без детализации. Базовые состояния используются в системных действиях, для отображения UID-ов артефактов, а также для построения кросс-проектных досок.

Правила перехода из одного состояния в другое задаются "Переходами". В настройках перехода можно указать - нужно ли запросить причину изменения статуса, каким ролям можно выполнять такой переход, какие при этом должны быть соблюдены предусловия. Также на конкретные переходы можно "повесить" системные действия или очистку значений полей.

Вы можете разработать PHP-скрипт, который установить в качестве предусловия для перехода. Если условие выполняется, то скрипт должен вернуть true, если нет, то false. Перед выполнением перехода, система выполнит скрипт. В зависимости от результата, операция либо будет успешной, либо система сообщит о нарушении предусловия для перехода. Функциональность доступна при наличии лицензии модуля "Скриптовая автоматизация" и настроенных правах на этот модуль. Результаты работы скриптов можно отслеживать в Административном разделе, в модуле PHP-скрипты.

Для состояний пожеланий и доработок можно задать дополнительные параметры:

• Задачи - указанный здесь перечень типов задач будет свойственен заданному этапу, например, при декомпозиции пожелания на задачи система предложит именно эти типы задач.
• Ограничение Work-In-Progress - лимиты, используемые в Kanban-процессе, позволяют сигнализировать команде о максимальном количестве незавершенных карточек в этом состоянии.
• Артефакты - система предложит создавать артефакты этого типа в данном состоянии.
• Можно создавать артефакты сразу в этом состоянии - опция позволяет регулировать возможность создания артефакта в заданном состоянии. На досках пользователи смогут добавлять карточки только в тех столбцах, для которых установлен этот признак.

Системные действия для первичных требований (Пожеланий и Доработок) можно расширять при помощи автоматических действий. Эти действия позволяют менять атрибуты пожеланий, сбрасывать их значения, создавать задачи или комментарии при изменении статуса, значений атрибутов, при создании комментариев или по расписанию.

Отличия ЖЦ для разных типов одного артефакта

Ошибки или доработки являются разными типами одного артефакта (Пожелание или История пользователя), также бывают разного типа задачи, требования и другие проектные артефакты. Возможна настройка различных ЖЦ (статусных моделей) для разных типов одного артефакта.

Различия в ЖЦ могут быть незначительными и существенными. Например, если Ошибка должна пройти дополнительную стадию воспроизведения силами тестировщика, то такое отличие в ЖЦ от остальных пожеланий является незначительным. С другой стороны, Заявки обрабатываемые поддержкой и Пожелания реализуемые командой разработки имеют совершенно разные ЖЦ.

Аналитика по ЖЦ

Модуль "Детализация времени цикла..." позволяет проанализировать нахождение подмножества артефактов в различных состояниях и выявить: время нахождения в состоянии, процент времени нахождения от общего времени цикла и т.п.

У системных действий могут быть параметры, о значении которых можно узнать из таблицы ниже.

Для системных действий можно указать признак "Уведомлять пользователя перед выполнением действия", который позволит сообщить заранее, что при выполнении перехода или изменении состояния, будет выполнено данное системное действие. Например, это может пригодиться при выполнении каскадных действий, таких как изменение статусов родительских или дочерних разделов требований, тестовой или эксплуатационной документации.

Для настройки специфической автоматизации, то есть для расширения встроенных системных действий, предназначены "Автоматические действия". С их помощью вы можете изменить атрибуты артефактов, перенести их в другой проект, добавить комментарий или создать задачу. Автоматическое действие можете обратиться по некоторому адресу в сети и передать нужную информацию, то есть вызвать так называемый веб-хук - ссылку на другом сервере. Вы можете отправить Email на указанный адрес.

Автоматические действия срабатывают при наступлении следующих событий:

• создание пожелания
• изменении пожелания
• создание комментария
• по расписанию

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

Порядок выполнения автоматических действий определяется их нумерацией. Номера можно изменить на форме редактирования или путем перетаскивания строк в списке действий.

Отправка Email

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

В настройках проекта создадим повторяющееся задание, которое будет выполняться каждый день:

В качестве события для автоматического действия выберем "По расписанию" и укажем там наше повторяющееся задание "Каждый день". В качестве условия зададим состояние и атрибут "Время в состоянии":

Если сотрудник забыл списать время по назначенной ему истории, то отправим ему уведомление о необходимости сделать это.

Для этого создадим повторяющееся задание, например, в конце рабочего дня, и используем его в качестве триггера для автоматического действия.

В качестве действия выберем "Добавить комментарий" и введем такой текст:

Комментарий будет добавлен к истории и исполнитель будет явно уведомлен о необходимости списать часы.

Можно отправить почтовое уведомление на конкретный Email или пользователям системы. Для этого необходимо заполнить поля на соответствующей вкладке:

Создаем новое автоматическое действие и в качестве события указываем "Новый комментарий". В дополнение, можем указать условия, при которых это действие будет срабатывать. На вкладке "Изменить атрибуты" указываем новое состояние заявки или пожелания.

Некоторые задачи автоматизации не могут быть реализованы при помощи штатных системных настроек. Для таких ситуаций вы сможете применить возможности модуля "Скриптовая автоматизация".

Разработанный скрипт может выполнять любую логику и операции, реализуя тем самым практически любой требуемый сценарий использования системы. Скрипты разрабатываются на языке PHP, с использованием архитектуры приложения. Примеры доступа к данным и манипуляции данными вы сможете найти в Справочнике разработчика.

Мы встроили возможности скриптовой автоматизации в следующие настройки:

• Предусловия для переходов между состояниями. Перед выполнением перехода система выполнит скрипт и в зависимости от его результата либо разрешит выполнить переход, либо нет.
• Автоматические действия, возникающие по событию или расписанию. Дополнительным вариантом автоматического действия является выполнение PHP-скрипта. Условие срабатывания автоматического действия можно описать при помощи скрипта, реализовав таким образом любой сложности условие.
• Валидация пользовательских или системных полей. При сохранении данных, система выполнит скрипт валидации и, либо разрешит пользователю сохранить данные, либо нет.
• Повторяющиеся задания. Таким образом можно реализовать периодический запрос данных из внешней системы, передачу данных во внешнюю систему и, в целом, реализовать интеграцию между различными системами.

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

Для аудита того, какие сценарии выполняются, а также анализа результатов их выполнения, используйте модуль "PHP-скрипты", расположенный в административном разделе приложения.

Основное назначение ролей - разграничить доступ к различным частям проектной информации. Для каждой роли вы можете настроить доступ к тем или иным артефактам проекта. Приглашая участников в проект, вы назначаете им роли. Пользователи получают доступ к проекту в границах полномочий, назначенных им ролей.

В системе есть несколько предустановленных ролей:

• Координатор проекта - проектная роль, которая может изменять любые настройки и может выполнять любые операции в проекте по умолчанию;
• Посетитель - проектная роль, которая может только читать данные;
• Разработчик, Аналитик, Тестировщик и т.п. - проектные роли, которые могут выполнять любые действия в проекте, но не могут приглашать участников и изменять настройки проекта;
• Владелец продукта - проектная роль с минимальными правами на изменение данных внутри проекта.

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

Есть несколько синтетических ролей, которые не могут быть изменены или удалены:

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

Права доступа выдаются на сущности, их атрибуты, на модули и отчеты. Права доступа на сущности по умолчанию определяют доступ и к модулям, отчетам, где отображаются объекты этой сущности.

Пользователь наделяется ролью "Все пользователи", если он не является участником проекта. Например, пользователю можно предоставить доступ к портфелю "Все проекты". Такой пользователь сможет открывать любой проект, не являясь при этом его участником (с какой-то проектной ролью). Права доступа такому пользователю определяются ролью "Все пользователи".

Пользователь наделяется ролью "Участник связанного проекта", если он заходит в программу или подпроект, не являясь при этом участником программы или подпроекта. Такая роль упрощает доступ к данным связанных проектов. Однако, в некоторых случаях это может быть недопустимо. Тогда необходимо настроить права доступа для этой роли в программе или подпроекте. Например, при необходимости ограничить участникам подпроекта доступ к программе, необходимо в настройках прав доступа в программе запретить доступ к сущности "Проект" для роли "Участники связанных проектов".

Доступ всем к одному проекту

Чтобы предоставить всем пользователям системы доступ к одному проекту, не включая их в него в качестве участников (ведь пользователей может быть много), предоставьте роли "Все пользователи" право "Просмотр" для сущности "Проект". После этого любой пользователь системы сможет зайти в проект. Чтобы предоставить возможность добавить пожелание, создать задачу или ответить на комментарий, необходимо выдать соответствующие права.

Одни и те же по сути вещи зачастую называются по-разному. В одних процессах первичные требования удобно называть "Заявка", в других - "История пользователя", в третьих - "Элемент бэклога", хотя по сути это одно и тоже. Однако, переучиваться на использование нового термина не комфортно, а в Devprom ALM и не нужно. Вы можете переназвать любой термин, обеспечив удобный язык общения внутри команды.

В списке терминов отображается исходный (системный) термин слева и его текущее (проектное) значение - справа. Вы можете изменять текст в правой части списка, при этом сохранение введенного вами значения осуществляется автоматически.

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

Данный модуль предназначен для управление видимостью, возможностью редактирования, обязательностью, значениями по умолчанию и другими характеристиками встроенных атрибутов. Вы можете менять их порядок отображения и описание. Указанные настройки будут использоваться при отображении форм, список и досок.

Кликните на названии поля, либо выберите поле для настройки в кнопке "Поля формы", расположенной слева внизу формы.

{PageType.DefaultPageTemplate.Content}; {project.Methodology.TextTemplates?ObjectClass = "Requirement" AND IsDefault = "Y"?.Content}

Группы позволяют расширять метаданные атрибута, позволяя системе использовать атрибуты в различных частях интерфейса.

Основные настройки полей могут быть перекрыты настройками для конкретных состояний или переходов, которые задаются на формах состояний и переходов.

Полный перечень всех настроек, с возможность удаления и редактирования вы можете найти в модуле "Поля форм" в настройках проекта:

Вы можете разработать PHP-скрипт, который проверяет правильность заполнения поля, в зависимости от любых необходимых условий. Если условие выполняется, то скрипт должен вернуть true, если нет, то false. При сохранении карточки артефакта, либо изменении значения данного поля, система выполнит скрипт и проверит условие. В зависимости от результата, операция либо будет успешной, либо система сообщит о нарушении условия валидации для поля. Функциональность валидации доступна, при наличии лицензии модуля "Скриптовая автоматизация" и настроенных правах на этот модуль. Результаты работы скриптов можно отслеживать в Административном разделе, в модуле PHP-скрипты.

Вы можете сформировать собственную схему идентификации артефактов, отличную от той, что используется в системе по умолчанию. Для этого необходимо открыть настройки атрибута "UID" и задать там формулу для вычисления значения по умолчанию.

В качестве формулы для вычисления идентификатора требования необходимо записать выражение по примеру из описания. Вот несколько вариантов пользовательской идентификации требований:

• {Тип требования.Краткое название,R}.{Id} - в начале ИД требования будет указано краткое название его типа, например, СТ.123
• {Тип требования.Краткое название,R}-{IdProject} - Значение поля "IdProject" заполняется автоматическим счетчиком в рамках проекта. В каждом проекте счетчик начинается с 1. Таким образом, вы можете получить такие идентификаторы: БТ-1, СТ-2 и т.п.
• {Тип требования.Краткое название,R}-{IdType} - Значение поля "IdType" заполняется счетчиком для каждого типа требования. Таким образом, вы можете получить такие идентификаторы: БТ-1, СТ-1 и т.п.
• {Тип требования.Краткое название,R}-{IdHierarchy} - Значение поля "IdHierarchy" заполняется счетчиком в рамках иерархии (документа), то есть счетчик будет увеличиваться для каждого следующего дочернего элемента внутри документа.
• {Тип требования.Краткое название,R}-{IdParent} - Значение поля "IdParent" заполняется счетчиком в рамках родительского раздела, то есть счетчик будет увеличиваться для каждого следующего дочернего элемента внутри одного раздела.

Вы можете формировать идентификатор с использованием дополняющих нулей, например, задав выражение {Id,6} система будет формировать идентификатор в виде 000001, 000002 и т.д.

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

Полный перечень пользовательских атрибутов вы найдете в справочнике "Атрибуты" в настройках проекта. Там же можно создать атрибуты для произвольной сущности, либо конкретного подвида данной сущности, например, только требований заданного типа.

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

Атрибут типа WYSIWYG-редактор позволяет оформлять описание пожеланий, задач и любых других объектов в системе, с использованием различных вариантов форматирования текста, с использованием списков, таблиц и изображений, отображаемых непосредственно в тексте. Тип используемого при этом WYSIWYG-редактора выбирается в общих настройках проекта.

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

Дополнительным применением этого типа поля является контроль выполнения важных действий, сопутствующих качественному решению задачи. Например, в Scrum это может быть Definition of Done по задачам: тесты написал, все проверил, локализацию обновил. В других методиках встречается термин Quality Gates - критерии качества, позволяющие уверенно сообщить о качественном решении задачи. Вы можете обозначить данное поле обязательным, тогда переход из одного состояния в другое станет возможен только после явной установки всех галочек в поле чек-листа.

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

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

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

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

Для этого необходимо создать пользовательский атрибут, где в качестве формулы для вычисления указать путь до требуемого значения:

Тогда в дереве функций вы сможете включить отображение этого поля и увидеть суммарную оценку по всем требованиям функции:

Описание синтаксиса

Для построения вычисляемых полей используется простой синтаксис: вы можете использовать любые символы, а также подстановки, окруженные фигурными скобками. В фигурных скобках задается путь к требуемому атрибуту. Если атрибут является ссылкой на сущность, то при помощи точки можно ссылаться на атрибуты этой сущности. Например, у Требования есть атрибут Тип, который по сути является ссылкой на сущность Тип требования. Если мы хотим вычислить краткое название типа требования, то достаточно записать {Тип требования.Краткое название}. Ссылаться на атрибуты сущности можно рекурсивно, например, у пожелания можно вычислить такой атрибут {Требования.Функции.Важность}. Чтобы узнать название атрибута или ссылки достаточно открыть карточку сущности, выбрать нужное поле и использовать его название в выражении.

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

{TestScenario?State = "submitted"}

В следующем примере можно посчитать плановые трудозатраты только по завершенным задачам:

{Tasks?State = "resolved"?.Planned}

Математические формулы

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

={Оценка} * 1000 + 20

Сложные расчеты

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

Например, для вычисления значения атрибута (c1) на основе двух других (a1 и b1), на вкладке "Валидация" вы можете записать следующий скрипт:

$it->object->getRegistry()->Store( $it, 
    ['c1' => $it->get('a1') + $it->get('b1')]
);
return true;

В данном примере выполняется низкоуровневая операция изменения значения атрибута c1, при изменении любого атрибута на карточке сущности.

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

// получим объект типа "Компонент"
$object = getFactory()->getObject('Component');

// пройдем по всем компонентам с типом "Сущность" и обновим атрибут c1
foreach( getFactory()->getByQuery($component, 'Type = "Сущность"') as $it )
{
    getFactory()->modifyEntity($it, 
        ['c1' => $it->get('a1') + $it->get('b1')]
    );
}

Описанная функциональность доступна, при наличии лицензии модуля "Скриптовая автоматизация" и настроенных правах на этот модуль. Результаты работы скриптов можно отслеживать в Административном разделе, в модуле PHP-скрипты.

Помимо системных действий над проектными артефактами, вы можете создавать пользовательские действия. Это может быть вызов внешнего веб-хука или PHP-скрипта. Таким образом, можно реализовать любое дополнительное действие, необходимое для автоматизации вашего процесса разработки ПО.

Например, для сборки можно настроить пользовательское действие “Развернуть", в результате которого запускается задача в Jenkins по развертыванию.

В URL и Сообщении можно использовать подстановки вида {{Caption}} и т.п., которые будут заменены реальными значениями того артефакта, для которого будет выполнено действие. Синтаксис подстановки такой же, который используется при задании формул для вычисляемых полей. Перечень полей вы можете найти в “Справочнике разработчика".

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

Некоторые справочники, например, Приоритет, Важность, задаются на уровне всей системы и настраиваются в административном разделе.

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

Шаблоны пожеланий появятся в кнопке быстрого создания (оранжевая кнопка слева сверху). Шаблоны задач доступны на доске или списке задач.

Укажите для шаблона повторяющееся задание, чтобы система автоматически создавала пожелание или задачу по шаблону по заданному расписанию.

В этом модуле создаются часто используемые фрагменты текста, которые можно подставлять в поле WYSIWYG-редактора после ввода символа "решетка" (#). Вы можете заранее заготовить шаблоны для описания историй, заявок, требований или комментариев.

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

Если установить галочку "Используется по умолчанию", то при создании соответствующей сущности система автоматически подставит текст из шаблона в поле ввода WYSIWYG-редактора.

Этот справочник предназначен для ведения списка событий, которые возникают периодически и приводят к созданию проектных артефактов, выполнению автоматических действий или запуску скрпитов.

В модуле "Управление бюджетом проектов" при помощи повторяющихся заданий вы можете описать повторяющиеся расходы (на серверы или услуги), либо поступления по контрактам и из других источников.

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

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

На вкладке Email можно задать параметры отправки потовых уведомлению по расписанию. В поле “Содержание" можно вставить модули, таким образом, реализовать периодическую отправку отчетов заинтересованным лицам. Для быстрого создания расписания, по которому будет отправляться отчет, используйте действие “Отправлять на почту по расписанию", доступную в меню “хлебные крошки” в заголовке каждого модуля.

На основе повторяющихся заданий можно реализовать сценарии интеграции с внешними системами. Для этих целей используйте возможности скриптовой автоматизации.