analyst.by

Белорусское сообщество бизнес и системных аналитиков

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).

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

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

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

Однако понятно, что на самом деле вопрос о подписании документов задают не для того чтобы поговорить о реализации процессов жизненного цикла требований, а о возможности представить требования в старом добром и понятном виде документа, который можно пролистать от начала и до конца. Так вот, 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 с идентификаторами требований, касающихся даты:

Затем задача Задача-Х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

 


05 Января, 2015


Комментарии к “Confluence в жизни аналитика — Часть 2”
    • Стоимость в конкретно нашей у компании у меня узнать к сожалению нельзя :)
       
      Могу только сказать, что помимо стоимости лицензий к самому Confluence  и стоимости платных дополнений, которые вам понадобятся, а также, обслуживания серверов, если у вас server а не Cloud, в некоторых случаях нужно учитывать ещё стоимость работы специалиста по поддержке Attlassian продуктов. На мой взгляд, для компаний более чем 100 человек, где специфика проектов предполагает индивидуальные настройки в рамках каждого проекта, найм такого специалиста может иметь смысл.
      Если же у вас не только Confluence, то эти затраты будут распределены на обслуживание других популярных среди разработчиков, Atlassian продуктов, например Jira, Git Essentials, Crowd и т.п. Таким образом, посчитать стоимость владения, как вы спрашиваете, не в моей компетенции :)

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

    1. Можно ли делать уникальную нумерацию для требований?
    2. Можно ли делать разные типы требований (бизнес/функциональное, новая фича, просто описание и т.п.)?
    3. Работаете ли вы со статусами требований? Если да, то как?
    • 1. Я встречал в маркете дополнение Requirement Yogi (https://marketplace.atlassian.com/plugins/com.playsql.requirementyogi), который вроде бы позволяет это делать несколько автоматизированно. Про него указано в статье.
      Признаюсь, подробно с ним не разбирался пока. Мне нравится генерировать нумерацию самостоятельно :) В нашей нумерации отражён тип требования, модуль (где это применимо) и, собственно, номер.

      2. Можно. Мы с Алесей (http://www.linkedin.com/pub/alesia-karpelenia/92/899/326/en) как раз недавно обсуждали её пример использования Вlue Prints. В статье справки про них (https://confluence.atlassian.com/display/DOC/Product+Requirements+Blueprint) как раз раскрывают тему, как можно каждой странице давать нужные вам свойства, среди которых уместно использовать тип требования.
      Этот способ отлично работает для Алеси, у неё требование в Jira соответствует странице требования в Wiki. У меня меньше таких требований и чаще встречается  функциональное описание экрана системы с множеством требований на одной странице.
      Кроме тех типов требований, которые вы указываете, в моей практике более востребовано использование различных типов страниц (Business object, meeting summary, Use Case, User Interface). Для них я использую шаблоны.

      3. Про то, как это можно делать, как раз по ссылке в предыдущем вопросе.
      Мы со статусами работаем больше в Jira. В вики веду только статусы обсуждений вопросов с заказчиком. Так удобнее для заказчика.

        • На самом деле больше чем два раза. Про Jira я писал ещё выше как про один из примеров систем управления задачами, а в статье обратил внимание, что имеет смысл различать инструменты по их назначению. Jira — одна из систем управления задачами, а Confluence — нет.
          В Jira мы создаём задачи (Jira issues) и работаем с ними в соответствии с принятыми процессами. Среди таких задач могут быть требования, но без того уровня детализации описания, которое может дать Confluence.  Как правило, в описании требования в Jira, будет ссылка на страницу wiki, с указанием идентификаторов требований на странице.

  2. возможность встроить одну страницу в другую с помощью макроса {include-page}
    Это скорее «переиспользование требований» (Re-use).
    То, что вы делаете с помощью search-results, это тоже переиспользование, но уже с добавлением трассировки.
    Матрица, возможно, нужна не всегда. А вот трассировка нужна. Обычно нам нужно отследить влияние/взаимосвязь разных сущностей между собой, например:

    1. Какие функциональные требования реализуют вот это бизнес-требование?
    2. На что повлияет вот эта новая фича?
    3. Для чего были сделаны изменения в этом требовании? (обратная трассировка к новой фиче или дефекту)
    4. Было ли реализовано это требование?
    5. Покрыто ли это требование тест-кейсами?

    Вы сталкиваетесь с такими вопросами? Если да, то было бы интересно узнать, как вы их решаете.

     

    • 1.  У нас есть список бизнес требований. Каждое из них связано со списком  фукциональных требований. Если только через поиск, то на практике, для бизнес требования Б1 поиск покажет только список ссылок на страницы, среди которых будут страницы с фукциональными требованиями, которые его реализуют. Догадываюсь, это не то, о чём вы спрашиваете.
      Список функциональных требований, как и список изменений, мы держим в Jira. Например в Story, созданному для требования Б1, в описании будет перечислены функциональности Ф1, Ф2, Ф3.

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

      3. В спецификации функционального требования Ф1, в нашем случае, найдётся колонка “Бизнес требование” со значением Б1. Значит изменения для бизнес требования Б1. Иначе бы не работал поиск по Б1 :)
      Говоря об изменениях, всё таки мы рассматриваем контретную задачу в системе управления задачами. Так вот в ней у нас найдётся связь на Б1.

      4. Вопрос решается например такими способами:
      — статус требования, если он отстлеживается средствами в wiki
      — статус связанной задачи из системы управления задачами, которая указана тут же, рядом с требованием.
      Жаль, что вы не увидели это в статье. Похоже на мой промах.

      5. Лично я на уровне БА в wiki эту часть не решаю. Решение существует в плоскости QA может быть реализовано по аналогии с предыдущим пунктом, через явное упоминание тестов в Wiki или через Jira.

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

      • Честно говоря, мне не все ответы понятны. Возможно, надо пробовать самому, чтобы разобраться.
        Мне пока что не очень понятно, как организовывать процесс работы с требованиями в Confluence — это какой-то конструктор, который надо Х времени допиливать под себя, причем с неясными шансами на результат.
        Когда я смотрел готовые СУТ (Jama, Devprom), там было всё более-менее понятно. Их недостаток — слабая гибкость/изменямость, если вам нужно что-то своё.
         

        • Денис, вы не далеки от истины — лучше всего пробовать самому, чтобы разобраться.
           
          В отличии от Jama или Devprom, Confluence позицианируется, как инструмент совместной работы над информацией, которая нужна чтобы сделать работу. Любую работу. Не обязательно именно работу по поддержке процессов разработки ПО, как в случае с Jama или Devprom.
           
          Я попробовал описать, как он может быть удобен применительно к работе БА.
           
          Тем, кто ещё не начал, но хотел бы попробовать Confluence, я бы рекомендовал, просто начать писать статьи, как пишут статьи в википедии. Уже по ходу работы, заниматься организацией иерархии, добавлением нужных параметров к страницам или прикручиванием плагинов по мере того, как приходит понимание, что вам на самом деле нужно. Это далеко не тоже самое, когда сначала X времени настраивают, а уже затем работают.

  3. Спасибо за статьи. Прочитав обе, пришел к выводам:

    1. Хорошо, что я не использую в своей работе Confluence — слишком уж все сложно.
    2. В комментариях выше есть спорные моменты, например, этот:

    В отличии от Jama или Devprom, Confluence позицианируется, как инструмент совместной работы над информацией, которая нужна чтобы сделать работу. Любую работу. Не обязательно именно работу по поддержке процессов разработки ПО, как в случае с Jama или Devprom. 

  4. Добрый день.
    Спасибо за полезную статью. Идея реализации версионности требований очень заинтересовала. Не могли бы вы уточнить каким образом именно она реализована?

    Как я понимаю,  для того, чтобы реализовать версионность у нас должно быть соотношение: 1версия = 1 спейс?

    далее, след.последовательность действий:
    1. Создаем спейс для первоначальной версии «Версия 1″ и формируем требования
    2. При появлении новой версии: создаем новый спейс «Версия 2″ путем копирования требований из «версии 1″
    3. Корректируем требования новой версии 
    Параллельно из каждого спейса будет доступ посмотреть другой спейс (любую другую нашу версию)

    Верно понимаю? 

Добавить комментарий
Также Вы можете войти используя: Facebook Google