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

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

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


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

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

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

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

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

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


Статусы

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


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

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

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


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


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


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


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

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

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

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

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

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

Степень отличия ЖЦ Способы настройки
Незначительные отличия В настройках переходов можно использовать предикаты "Тип: Ошибка" для того, чтобы предоставлять возможность перемещать в конкретное состояние артефакты конкретного типа.
Значительные отличия Как правило, существенные отличия в ЖЦ связаны с различными процессами, в которые вовлечен данный артефакт. Например, обработка заявок (пользовательских требований) на первой линии поддержки требует и дополнительной настройки интерфейса ПО. По этой причине разные ЖЦ для пользовательских требований оформляются разными процессами (проектами). Объединить такие процессы и проекты в общее пространство управления можно при помощи Программы проектов или Портфеля проектов. Таким образом, на уровне программы проектов видны все пользовательские требования, а на уровне подпроектов (отличающихся процессов), можно управлять ЖЦ конкретным пользовательским требованием в зависимости от этапа обработки: поддержка или реализация.

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

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

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

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


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

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

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

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

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


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

Задачи

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

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

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

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


Требования

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

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

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

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


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

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

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


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

Отправка Email

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

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

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


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

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

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

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

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


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


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