Настройки процесса

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

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

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

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

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

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

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

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

Статусы

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

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

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

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

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

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

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

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

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

Системные действия

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

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

Пожелания и доработки

Название действия Назначение и особенности использования
Изменить состояние исходных пожеланий

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

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

Задачи

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

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

Переместить связанные артефакт в следующее состояние

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

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

Требования

Название действия Назначение и особенности использования
Отметить устаревшей документацию связанной функции

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

Автоматические действия

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

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

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

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

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

Пример: автоматическое закрытие подвисших заявок

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

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

Пример: напоминание о необходимости списать время

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

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

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


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

Пример: изменение статуса заявки при создании комментария

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

Роли и права доступа

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

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

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

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

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

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

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

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

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

Терминология

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

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

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

Настройки полей формы

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

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

Пользовательские атрибуты

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

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

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

Группы

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

Название группы Назначение группы
trace Атрибут отображается на вкладке "Трассировка"
deadlines Атрибут отображается на вкладке "Сроки"
display-name Значение атрибута подставляется в название проектного артефакта, отображаемое в ссылках
tooltip Атрибут отображается на всплывающей подсказке, при наведении на ИД проектного артефакта
hours Значение атрибута представляет собой единицы времени, таким образом, в интерфейсе автоматически будет использовано представление в виде 2д 3ч и т.п.

Редактор WYSIWYG

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

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

<div alm-widget-module="activitiesreport" alm-widget-parms="start=last-month&amp;group=Owner.A&amp;project=all&amp;ids={Связанные заявки.ИД}">Загрузка...</div>

Здесь атрибут alm-widget-module содержит кодовое название отчета, alm-widget-parms - дополнительные параметры для него. Подстановка вида {Связанные заявки.ИД} разрешается в конкретные значения по аналогии с правилами для вычисляемых полей.

Вычисляемые атрибуты

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

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