Confluence в жизни аналитика — Часть 2

Всех с наступившим 2015 Годом! В прошлом году мы с вами познакомились с базовыми возможностями Confluence и немного рассмотрели его с позиции “просто пользователя”.

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

Трассировка требований в работе аналитика

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

Поскольку Confluence изначально не является инструментом управления требованиями, он не предлагает готовое решение, как, например, готовая матрица трассируемости. Зато у него есть кое-что получше… ;)

Итак, как же упростить поддержку требований? Как работать так, чтобы описание можно было использовать повторно, не копируя каждый раз и не исправляя одно и то же в куче мест в спецификации?

Признаюсь, то что предлагает для этого Confluence – одна из моих любимых особенностей работы с этим инструментом.

Прежде чем рассказать о трассируемости, хочется сказать про возможность встроить одну страницу в другую с помощью макроса {include-page}. Это решение “в лоб” – оно существует и его можно использовать вполне задорно. Да, в контексте управления требованиями такой способ решения не самый жизненный. Однако он может быть достаточно удобным, когда вам надо вставить какую-нибудь одну и ту же таблицу везде-везде. При этом вы избегаете дублирования требований, т.к. источник всегда один.

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

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

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

• 100500 страниц системы работы с заказами.

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

• здоровая аналитическая лень отбивает всякое желание обновлять 100500 страниц спецификации, где упоминается дата заказа.

Что будем делать:

• Создадим страницу для описания объекта “Заказ”. Тут опишем все поля объекта, включая поле “Дата заказа”. Каждому полю присвоим уникальный идентификатор (для даты заказа у нас будет идентификатор БО-ПЗ-80),

• Во всех местах спецификации, где используется Дата Заказа, делаем ссылку на описание данного поля с указанием придуманного выше идентификатора БО-ПЗ-80, обозвав его, например, “Источник данных” – намекнем тем самым на структуру базы, что особо оценят программисты.

• И немного волшебства: добавим колонку “Где Используется”, которая динамически отобразит список страниц, в которых упомянута наша дата (поле БО-ПЗ-80), решив тем самым проблему трассировки!

Страница описания объекта может выглядеть примерно так (на иллюстрации смотрим нижнюю строчку и колонку “Где используется”):

А так выглядит страница описания экрана со ссылками на описание полей бизнес-объекта (на иллюстрации смотрим колонку “Источник данных” и ищем строчку про дату заказа):

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

Чтобы овладеть магией, вам понадобятся только два макроса:

• {search-results}, который отобразит нам список страниц (а также блоков или комментариев – что именно выводить, можно настроить на ваш выбор), где используется искомое сочетание символов.

• {expand} – спрячет массивный вывод результатов поиска и существенно “разгрузит” визуально вашу страницу.

Справедливости ради надо отметить, что интересный способ связи требований предлагают автоты плагина Requirement Yogi (видео 2:15  https://www.youtube.com/watch?v=mHC13NVg3KA).

А что если он захочет подписать документ?

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

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

• Comala Workflows и Comala Remote Publishing Workflow

• Confluence Publish Plugin (бесплатный!)

• Scroll Versions и  Scroll Remote Publishing Endpoint

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

Опции для экспорта контента доступны из меню пользователя Tools:

1. Export to PDF – сохранить текущую страницу как PDF.

2. Export to Word – сохранить текущую страницу как Word-документ.

3. Export Page Tree to Word – сохранить дерево страниц как Word-документ – самая популярная возможность, когда нужно подписать целую спецификацию, состоящую не из одной, а из множества страниц вики.

 

А такие опции доступны администраторам:

 

Организация требований, и какие бывают правила

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

Если вам не понравилась получившаяся иерархия страниц, то страницы можно легко отсортировать, как вам нравится: например, отделить Бизнес-Объекты от Функциональных Требований.

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

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

Шаблон можно настроить в рамках вашего проекта или глобально для всех проектов, если вы администратор.

Впоследствии ваш шаблон будет отображён в списке выбора, который появляется при попытке создания страницы.

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

https://confluence.atlassian.com/display/DOC/Product+Requirements+Blueprint

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

Про работу с Jira и заморозку версий спецификации

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

Если такой вопрос поднялся, то это не что иное, как увесистый камень в чудесный сад управления процессами на проекте. Часто случается, что именно аналитик отвечает если и не за все процессы, то, как минимум, за процесс управления требованиями. И действительно, коллеги, ввиду особенностей нашей с вами профессии мы склонны генерировать много контента, не всё из которого предназначено для немедленного прочтения каждым участником команды. Как известно, один из признаков эффективного стиля работы – умение беречь время своих коллег.

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

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

1. Вариант “внедрить и задействовать систему управления задачами”.

2. Вариант “задействовать версионность, которая присутствует в арсенале Confluence”.

Рассмотрим оба подхода.

В первом случае нам нужна система управления задачами, коей Confluence не является. Конечно, можно написать строчку текста, сказать, что эта строчка – на самом деле, задача, назначить ей дату исполнения и ответственного. Действительно, если это можно сделать в Excel, то почему это делать в Confluence?

Однако я настаиваю на том, что Confluence – это инструмент для совместной работы, но никак не система управления задачами. Поэтому в первом подходе мы предположим, что на вашем проекте задействована некая система управления задачами, которая позволяет контролировать сроки, назначать виновных и в целом, отслеживать прогресс на проекте. Jira – одна из таких систем, но если у вас TFS, IBM Rational, Mantis, Bugzilla, Redmine или что-нибудь ещё, что позволяет управлять задачами – это всё равно отлично сработает.

Идея в том, чтобы в Confluence держать подробное описание требований, а в системе управления задачами вести задачу со всеми её атрибутами и контролировать статус её выполнения в пределах жизненного цикла задачи в указанной системе. Простыми словами, в Jira мы указываем, что в рамках задачи Задача-Х100500 нужно добавить дату и указываем тут же, в подробностях задачи, ссылки на описание соответствующих страниц в Confluence с идентификаторами требований, касающихся даты:

• Экран формы заказа: http://wiki.mycompany.com/project/order+page ФТ-ФЗ-15

• Экран деталей заказа: http://wiki.mycompany.com/project/order+detail ФТ-ДЗ-15

• Экран списка заказов: http://wiki.mycompany.com/project/list+of+orders ФТ-СЗ-15

Затем задача Задача-Х100500 в состоянии “Назначена” уходит к своему счастливому обладателю.

С другой стороны, в Confluence в каждом из указанных требований мы укажем идентификатор задачи, в рамках которой она должна быть выполнена (на иллюстрации смотрим колонку “Задача”).

Теперь для того, чтобы понять, реализовано ли поле “Дата”, будет достаточно взглянуть на статус соответствующей задачи в системе управления задачами. Статус задачи может быть, допустим, “Назначена”, “Выполнена”, “Закрыта” или, скажем, “Переоткрыта” – в зависимости от внедрённой системы управления задач и настроенного в ней процесса со статусами. Таким образом, пометка идентификатора задачи напротив требования позволяет нам судить о том, как относиться к каждому требованию: как к реализованному или, например, только как к запланированному пока что.

Всё-таки нужно упомянуть дополнительно Jira за особо глубокую интеграцию, которая позволяет не только создавать Jira Issues из Confluence, но также с помощью макроса {jira} выводить свойства задачи, такие как статус и заголовок. Свойства задачи отображаются прямо в Confluence, рядом с идентификатором задачи, таким образом, чтобы всё нужное и ценное было видно на странице и вам не нужно было отдельно заглядывать в систему управления задачами.

Макрос {jira} в работе:

Второй подход, про версионность – это примерно то, что делает сам Atlassian в своей документации. Каждый раз, когда выходит новая версия продукта, документация для предыдущей версии остаётся, но волшебным образом появляется и новая, очень похожая на старую, только более актуальная документация к последней выпущенной версии продукта!

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

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

Если вы откроете любую статью документации Confluence (для примера, https://confluence.atlassian.com/display/DOC/Start+your+trial), то вверху страницы вы обнаружите текст о том, к какой версии продукта относится статья, которую вы сейчас смотрите. Там же вы найдёте ссылку на все имеющиеся версии.

В нашем случае мы сделали даже интереснее: добавили в аналогичный блок ещё ссылку на эту же страницу в самой последней версии. Такая ссылка “Открыть это требование для последней версии продукта” у нас была доступна из старых “замороженных” версий документации. Вы тоже можете её сделать с помощью макроса {spacejump}. Подробнее про то, как это может выглядеть, нарисовано тут.

Такой процесс “Cрез версии” достигается копированием всего пространства в момент заморозки кода, а все описанные ссылки на другие версии настраиваются администратором как разметка страницы на уровне пространства вашего проекта. Таким образом, пояснение про версию отображается динамически на каждой странице пространства, и никому не нужно писать об этом, каждый раз создавая нужную страницу.

Так работает дополнение “Copy Space”:

Настройка разметки страницы:

Результат:

К сожалению, последняя версия Confluence не поддерживает дополнение Copy Space Plugin, однако вероятно, что это только вопрос времени, когда выйдет обновление для плагина: https://marketplace.atlassian.com/plugins/com.atlassian.confluence.plugin.copyspace/versions#b22

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

Идеологически мне очень нравится этот подход, но только при условии чтобы НЕ мне пришлось заниматься “зачистками” после каждой “заморозки” документации :)

Всё-таки описанный процесс предполагает существенные временные затраты на поддержание чистоты в момент поставки каждой новой версии документации.

Кажется, мы рассмотрели всё самое популярное из того, что мне нравится в работе с Confluence.

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

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

Таким образом, научившись “правильно готовить контент” так, как это нравится именно вам, Confluence сослужит вам отличную службу.

Было бы интересно увидеть ваши примеры использования Confluence в работе BA и в любой другой работе :)

Автор:

Денис Ардабацкий

Старший бизнес-аналитик в Oxagile