Плагин Requirements Yogi для Confluence: обзор и запись вебинара

6 апреля я провёл бесплатный вебинар Разработка требований в Confluence с использованием плагина Requirements Yogi. В этой статье я привожу краткий обзор того, о чём рассказывалось на вебинаре. Это поможет вам решить, стоит ли потратить примерно полтора часа своего времени на просмотр записи.

Atlassian Confluence – широко распространённая wiki-система, используемая в компаниях для ведения корпоративных баз знаний и разработки документации. Во многих компаниях Confluence также используют для документирования требований к ПО. Система «из коробки» не предоставляет каких-либо специальных возможностей для разработки и управления требованиями. Но открытая архитектура позволяет добавлять такие возможности с помощью устанавливаемых расширений (плагинов).

Одним из таких расширений является плагин Requirements Yogi.

Возможности плагина

Плагин предоставляет следующие возможности:

• Разбиение страниц Confluence на отдельные требования. Любой фрагмент страницы (удовлетворяющий определённым условиям, о которых ниже) может быть объявлен отдельным атомарным требованием, с присвоением ему уникального идентификатора. На каждое атомарное требование можно ссылаться с помощью гиперссылки с уникальным url.

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

• Построение отчётов о требованиях, отбираемых по разным критериям (в том числе по значениям атрибутов).

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

• Построение таблиц покрытия и матриц трассировки требований.

Атомарным требованием может быть:

• Абзац текста;

• Пункт списка-перечисления;

• Строка таблицы.

Полностью все возможности плагина раскрываются только при использовании таблиц. Атомарные требования в виде простого текста могут использоваться только для ссылок.

Чего нет в плагине

Плагин не предлагает каких-либо готовых процессов для работы с требованиями. Жизненный цикл требования не определён. Шаблон требования (blueprint), который идёт в комплекте с плагином, может использоваться разве что для демонстрации способов создания шаблонов.

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

• что считать атомарным требованием (до какого уровня декомпозировать требования);

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

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

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

Схемы разработки требований

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

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

Для частоты поставок выбраны три значения. Принцип деления прост: берём два крайних случая, а всё, что к ним не относится, остаётся посередине.

1. Разработка короткими итерациями (спринтами) представляет одну крайность. Предполагается длительность итерации примерно от 1 недели до 1 месяца. Отличительная особенность этого подхода в том, что мы не думаем о следующем спринте, пока не закончили текущий.
2. Периодический выпуск версий. Итерации в этом случае обычно длятся от одного до нескольких месяцев. Требования к версиям при этом могут разрабатываться параллельно: разработка требований к следующей версии идёт параллельно с реализацией текущей. Для выпуска каждой версии нужен зафиксированный набор требований.
3. Разработка требований в виде документации (aka «водопад») представляет собой другую крайность. Все разработанные требования фиксируются до начала разработки.

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

1. User Stories — очень распространённый в настощее время формат. Каждая User Story включает требования разных уровней: требуемую функцию, цель пользователя, поясняющие комментарии и приёмочные тесты. При этом User Story представляет собой атомарное требование, которое должно быть реализовано целиком в пределах итерации.
2. Use Cases — распространённый формат описания требований на пользовательском уровне. Несмотря на название, к этой категории можно отнести любые форматы описания пользовательских требований. Основное отличие этого вида требований от предыдущего в том, что требования в этом формате могут декомпозироваться на более мелкие атомарные требования, реализуемые в разных итерациях или версиях.
3. Текстовые описания требований, обычно в виде «система должна». Из таких требований состоят традиционные технические задания и спецификации требований.

В вебинаре рассматриваются получившиеся девять схем. При этом некоторые сочетания оказываются несовместимыми.

Слайд с итоговой таблицей приведен ниже.

Для каждой работающей схемы были показаны возможности плагина Requirements Yogi в специально созданных пространствах на тестовом сервере Confluence. На вебинаре демонстрировались операции и настройки входящих в состав плагина макросов. Их всего три:

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

Для присвоения статусов требованиям использовался другой плагин Confluence — Handy Status (входящий в пакет Handy Macros). Этот простой плагин позволяет настраивать произвольные наборы статусов и изменять их одним кликом, без необходимости перехода в режим редактирования страницы. В реальных проектах статусы, скорее всего, должны формироваться во внешних системах управления задачами — например, Jira.

Теперь у вас должно быть достаточно информации, чтобы решить, нужно ли просматривать запись вебинара.

Requirements Yogi from Grigoriy Pechenkin on Vimeo.