Визуализация фич Vanessa Automation в StoryMapper

21.03.20

Управление проектом - Инструменты управления проектом

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

Введение

Те, кто следит за развитием проекта Vanessa Automation, могли заметить, что в релизе 1.2.030 появились изменения в feature-файлах, связанные с задачей "Адаптация feature-файлов проекта VA для использования в StoryMapper". В своём большинстве эти изменения такого вида:

Закономерный вопрос: что это за теги и зачем они нужны?

В наших предыдущих статьях ([1], [2]) упоминался StoryMapper - инструмент для организации feature-файлов в виде карты пользовательских историй. В статье [2] он использовался для организации разработки по методике BDDSM, в [1] предлагалось использовать его для упорядочивания своего репозитория feature-файлов. В этой статье мы хотим продемонстрировать, как можно использовать StoryMapper для упорядочивания ваших фич, так чтобы их было удобно и наглядно демонстрировать вашему руководству или стейкхолдерам.

По согласованию с @Pr-Mex (aka Леонид Паутов) мы решили провести такое упорядочивание на примере очень большой коллекции feature-файлов (порядка 700) из ветки develop репозитория Vanessa Automation. Цель данного действия: визуализировать и тем самым повысить прозрачность и понимание того, как работает Vanessa Automation. На сегодняшний день feature-файлы VA распределены по тематическим папкам, но их распределение носит отражение технического подхода к их написанию (регрессионное тестирование), а не точки зрения пользователя или возможного нового контрибьютора. Составление карты историй позволит поменять перспективу рассмотрения feature-файлов и взглянуть на них под пользовательским углом.

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

 

Выбор UF

Первый этап упорядочивания - это составление скелета карты пользовательских историй. Скелет в StoryMapper состоит из двух уровней: UF (Usage Flow) и UA  (User acivity). Верхний уровень - это некие крупные блоки пользовательской активности, которые мы ожидаем от продукта. В случае VA и её feature-файлов нужно понимать, что не все фичи относятся к пользовательской активности по своей техногенной сущности, соответственно и UF будут не всегда о пользователях.

Итак, мы выделили ряд UF, которые описывают пользовательский опыт взаимодействия с VA, другие, в которых будут содержаться фичи с библиотечными шагами и с особенностями реализации Gherkin, вспомогательные технические фичи, которые в VA используются как макеты данных для учётных задач (данные для тестирования), и отдельный UF для (пока) неклассифицированных фич.

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

 

Составление UA

Второй уровень составить было сложнее. Поскольку разработка VA шла не от карты пользовательских историй, а по пути инкрементного наращивания функционала, нельзя было просто взять и составить список пользовательских активностей. Поэтому мы восстанавливали UA обратным ходом - от US. Когда под UF0 находилась очередная фича, про которую было понятно к какой UF она относится, но под этой UF не было подходящей UA - тогда подходящая UA создавалась.

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

 

Разнесение фич под UA

Из предыдущего раздела уже понятно, что UA формировались по ходу разнесения фич. Основная цель, которую мы преследовали на первом этапе - это сделать так, чтобы под UF0 не осталось ни одной фичи. Чтобы все они стали классифицированными, а  уж потом можно переподчинять их согласно реальному предназначению. То есть к текущей версии карты пользовательских историй я пришёл за 4 итерации упорядочивания. Во-первых, вынес все фичи из-под UF0, во-вторых, отделил реальные фичи от служебных, которые используются как макеты, в-третьих, пересмотрел подчинённость фич пользовательским активностям, и в-четвёртых, получил результаты выполнения сценариев и, соответственно, увидев те фичи, которые реально выполняются на CI-контуре, убрал вспомогательные фичи с экспортными сценариями в "UF11 Прочее".

Конечно, не обошлось без трудностей. Надо понимать, что StoryMapper работая с feature-файлами, ориентирован не на название файла, а на название фичи, то есть тот текст, который идёт после ключевого слова "Функционал/Функция". Поскольку за уникальностью этого значение в репозитории никто не следил (а за неимением соответствующего инструментария это делать достаточно проблематично) получались ситуации, когда фича вроде бы уносилась из-под UF0, но после отправки изменений в git - возвращалась обратно. В результате пришлось провести работу по унификации названий фич, что на текущем этапе вылилось в добавление цифр в конце названия. В дальнейшем нужно будет либо слить эти фичи в одну, либо дать им более осмысленное название.

 

Отображение результатов выполнения сценариев

Что ещё интересного есть в StoryMapper, кроме карты пользовательских историй. Цифры в правом нижнем углу показывают количество выполненных сценариев. Поскольку в VA всё фичи зелёные (а разве бывает по-другому?) - то и на карте мы видим только цифры на зелёном фоне. Если бы сценарии падали, или у них были бы не реализованные шаги - то эти цифры также отобразились бы на карте на красном или сиреневом фоне соответственно. Данные о результатах выполнения сценариев берутся из json-файла c результатами выполнения в формате Cucumber. Сопоставление идёт по названию фич и сценариев.

Также в StoryMapper можно увидеть и результаты выполнения сценариев в формате Allure (без необходимости ходить на CI-сервер, либо публиковать результаты каким-то иным образом), что позволяет исследовать результаты выполнения до шагов, а также анализировать скрин-шоты в случае падения того или иного сценария.

Отправка результатов сборок формата Cucumber и Allure в Storymapper осуществляется POST-запросом. На сейчас я взял у Леонида json-файлы после очередной сборки и отправил их вручную. Если к инструменту будет проявлен интерес, и им будут пользоваться на постоянной основе, то можно будет вставить запрос по отправке результатов в сборочную линию VA и результаты выполнения сценариев в StoryMapper будут актуализироваться автоматически.

Также в StoryMapper есть полезная функция по выгрузке результата упорядочивания в Excel, выстраивающая табличную иерархию UF->UA->US->Сценарий.

 

Доступы к StoryMapper

Все манипуляции с feature-файлами происходили в моём форке VA, после очередной итерации я создавал pull-request, разрешал конфликты, VACIbot запускал автотесты - и после удачного прохождения тестов изменения по фичам попадали в ветку develop основного репозитория VA. Ветка develop основного репозитория также подключена к StoryMapper, но в режиме "только чтение". Всем желающим посмотреть на фичи VA под другим углом - добро пожаловать:

URLhttps://app.checkushka.com/storymapper/VAdevelop/

login: VA_user

password: BDDSM2020

 

Ссылки:

  1. Полевые исследования концепции «Documentation as code»
  2. BDDSM-практики, или 50 оттенков желтого

bdd VA StoryMapper

См. также

Инструменты управления проектом Бесплатно (free)

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

19.09.2024    868    0    Dangien    3    

6

Инструменты управления проектом Внедрение изменений Бесплатно (free)

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

12.09.2024    385    0    ermakovalekseyv    0    

2

Инструменты управления проектом Руководитель проекта Бесплатно (free)

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

01.04.2024    3149    0    MariaTemchina    6    

22

Инструменты управления проектом Россия Бесплатно (free)

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

07.11.2023    1937    0    WildHare    2    

16

Компетенции и навыки РП Обучение и наставничество Инструменты управления проектом Бизнес-аналитик Руководитель проекта Бесплатно (free)

Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации vc, Хабра, Инфостарта (и не только) и выбрали самые крутые и полезные.

09.10.2023    1374    0    Birby    0    

2

Инструменты управления проектом Бизнес-аналитик Руководитель проекта Бесплатно (free)

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

27.12.2022    3141    0    MariaTemchina    28    

24

Инструменты управления проектом Бизнес-аналитик Руководитель проекта Бесплатно (free)

По итогам нашего выступления на семинаре партнеров 1С в октябре 2022-го подготовили эту статью. Риски и советы по их снижению взяты из нашей непосредственной практики взаимодействия с крупными корпоративными заказчиками, в том числе из госсектора. И опыта этого, за более чем 15 лет, накоплено немало. Мы понимаем, что описанные в статье советы не являются панацеей и 100% гарантией решить сразу все полюбовно с заказчиком. Но при этом надеемся, что информация поможет лучше подготовиться как к встрече с самими рисками, так и выбрать «пути для маневра» с целью избегания рисков или, как минимум, их минимизации.

10.10.2022    1742    0    it-expertise    4    

10

Инструменты управления проектом Бизнес-аналитик Руководитель проекта Бесплатно (free)

Честно скажу, я всегда с некоторой настороженностью открываю разные "чересчур умные" книжки. Особенно их переиздания (в данном случае аж 7-ая версия). Ибо очень часто разрыв между высокими концепциями и реальностью оказывается чересчур огромным (особенно в этом плане меня позабавил катастрофический непонятный вебинар на тему понимания).

07.09.2021    10718    0    MariaTemchina    0    

20
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Pr-Mex 136 21.03.20 15:25 Сейчас в теме
Интересно про реверс инжиниринг активностей пользователя.
Vladimir Litvinenko; 1ceo_2015; +2 Ответить
2. Vladimir Litvinenko 2896 21.03.20 23:47 Сейчас в теме

Вот это красота! Да и не только красота, но и удобство. Как минимум для просмотра и навигации.

В статье Полевые исследования концепции «Documentation as code» одним из направлений развития указано
какая-то интеграция с Jira

Интересно, получилось что-то в этом направлении?

Разделение действительно очень напоминает иерархию/декомпозицию в Jira на проекты, эпики и истории.
Здесь могла бы быть связь UA или UF = эпик, фича = история. Или UF = эпик, UA = история, фича = подзадача. Что больше бы подошло для ситуации, когда по одной истории происходят уточнения и доработки реализуются через отдельные задачи и подзадачи. Для каждого проекта или продукта могла бы быть отдельная страница в StoryMapper. То есть напрашивается ещё один уровень абстракции/организации - "продукты" или "проекты". Так понимаю сейчас это уже реализовано за счет разделения на отдельные подкаталоги для разных проектов вроде storymapper/VAdevelop.

По юзабилити инструмента:
Кажется было бы удобно, если бы окно View/Edit можно было закрывать по клавише Esc. Для закрытия окна реализовано аж два элемента - крестик справа вверху и кнопка Close справа внизу. Но при последовательном просмотре множества фич оба варианта одинаково неудобны - далеко тянуться мышкой и целиться. На автомате рука несколько раз нажимала клавишу Esc, которая сейчас ничего не делает.


Также интересно помещение изменений в репозиторий. Согласно той же схеме в статье на Хабре StoryMapper связан с гит-репозиторием двунаправленно.


То есть в ряде случаев предполагается редактирование фич прямо через него, также как и через Visual Studio Code. Но в таком случае как происходит коммит?

В Visual Studio Code коммит можно сделать согласованно - после согласованного изменения нескольких фич, или например фичи и экспортного сценария, от которого она зависит. А как здесь при работе через веб-интерфейс? Ведь в этом случае при закрытии окна изменения надо сохранить, прежде чем переходить к другой фиче. И судя по всему в этом случае изменение должно приводить к отдельному коммиту. Удобно и правильно ли это?

Вот если можно было отредактировать несколько фич, а потом разом сделать коммит - это было бы классно. Но в этом случае что делать в случае конфликта? Кажется что в этом случае имеет смысл связывать StoryMapper с неким "локальным" репозиторием. А в случае возникновения конфликта предлагать перейти к нему и вручную разрешить возникшие противоречия.

Или я слишком заморачиваюсь и продукт пока далёк от использования в такой роли?
1ceo_2015; +1 Ответить
3. 1ceo_2015 22.03.20 13:39 Сейчас в теме
(2)
Вот если можно было отредактировать несколько фич, а потом разом сделать коммит - это было бы классно. Но в этом случае что делать в случае конфликта? Кажется что в этом случае имеет смысл связывать StoryMapper с неким "локальным" репозиторием.


Так и сделано. Просто у вас доступ readonly.



Соответственно связь изменения репозитория требований к программному продукту с задачами на изменение программного продукта в жире есть (если в коммите указать номер задачи - он появится в этой задаче и в битбакете)



Таким образом можно увидеть список задач и их статус в связке с фиче-файлами репозитория требований к проекту.

Возвращаясь к первому вопросу про более сложные конструкции связей систем управления требованиями и систем управления задачами. Если коротко: такие штуки сложно поддерживать.
Связки Epic - UA US-story использовались нами еще со времен использования Speclog в качестве базовой системы накопления требований. Красиво и прозрачно на первой стадии проекта, страшно и криво на последующих стадиях)). Да и смысл связки сомнителен по причине отсутствия в ней бизнес-целей. Для них приходится городить более высокий уровень абстракции.

Мы используем (и настойчиво рекомендуем остальным на проектах внедрения Jira+StoryMapper) следующую конструкцию: Epic для фиксации бизнес-целей и задачи типа баг и стори в эпике для декомпозиции на понятные для команды разработчиков объемы работы.
Это позволяет привлечь бизнес к структурированию и работе с требованиями, ускорить поставку бизнес-ценности и избежать выполнения ненужной работы.
Естественно это требует изменения способа работы с заказчиком и требованиями и не со всеми это удается сделать.
Такая связка позволяет реверс-инжинирингом собрать разрозненные таски в один бизнес-проект с понятными бизнес метриками. StoryMapper в таком случае выступает пространством для общения бизнес-заказчиков и разработчиков.
На самом деле это тема для отдельной статьи или даже цикла. В рамках комментария описать такое сложно. Будет интересно - можем сделать демо или вебинар по методике.
Прикрепленные файлы:
Vladimir Litvinenko; +1 Ответить
5. Vladimir Litvinenko 2896 22.03.20 18:44 Сейчас в теме
(3)
Спасибо за ответы. Действительно интересно.
Будет интересно - можем сделать демо или вебинар по методике.

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

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

Вот например этот момент тоже можно было бы осветить. Границы применимости.

Вообще кажется, что большую склонность к такой проработке задач имеют разработчики. Потому что изначально в таком подходе - алгоритмизация и системность. Обычно же ПМ-ы и консультанты больше склонны к мягко говоря частичной систематизации и алгоритмизации при постановке задач, выявлении и фиксации требований заказчика. Часто даже работа ведётся с неверсионируемыми Word-документами или в неком подобии 1С:Документооборота, что создаёт понятные проблемы.

То есть интересен вопрос не только границ применимости с заказчиком, но и процесса перехода к этим подходам самой команды разработки/проектной команды.
1ceo_2015; +1 Ответить
6. 1ceo_2015 22.03.20 19:12 Сейчас в теме
(5)
(5)
Часто даже работа ведётся с неверсионируемыми Word-документами или в неком подобии 1С:Документооборота, что создаёт понятные проблемы.


storymapper собственно и создавался как средство структурирования произвольной документации заказчика в критерии приемки функционала.

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


(5)
Вот например этот момент тоже можно было бы осветить.


Если совсем коротко description эпика:

как заказчик я хочу улучшить UF (критерии успешности которого у меня уже прописаны и измеряются) до таких-то показателей.

ну и исходя из этого формируем список изменений Критериев Приемки (они же сценарии) или добавляем новые. В конце итерации смотрим на изменение показателей. и делаем новые гипотезы о развитии компании.
7. oleynik.dv 164 22.03.20 20:40 Сейчас в теме
(2) в принципе Фёдор уже всё ответил, но я прокомментирую по поводу общего коммита.


В целом, сейчас практикуется такая схема. От общей ветки разработки выделяется ветка для StoryMapper, с которой работает бизнес-аналитик. Последовательность его действий следующая:

1. В StoryMapper он жмёт кнопку Download (эквивалент git pull). При этом все локальные изменения в проекте StoryMapper затираются текущим состоянием ветки в "центральном" репозитории.
2. Бизнес-аналитик работает с картой историй. Создаёт/удаляет/перемещает UF/UA/US, возможно в редакторе StoryMapper вносит изменения непосредственно в фичи.
3. Нажимает кнопку Upload и вводит сообщение коммита. Выполняются команды git add, commit, push. Изменения уходят в "центральный" репозиторий.
4. В клиенте git на рабочей машине выполняет git pull и получает изменения, выполненные в StoryMapper.
5. Работает с фичами в VSC, Sublime, Notepad++, и отправляет изменения в "центральный" репозиторий.
6. При необходимости внести изменения в карту историй возвр. к п.0.
7. Когда доходит до промежуточного результата - мёрджит свою ветку с основной веткой разработки.

Вы можете зарегистрироваться по ссылке https://app.checkushka.com/register.php, и я вам подключу демо-проект, связанный с репозиторием на гитхабе. Там можно будет пощёлкать, потаскать и посмотреть на коммиты в гитхабе.
Vladimir Litvinenko; +1 Ответить
8. rystam_atai 07.01.22 16:46 Сейчас в теме
Два года пршло. Есть ли продолжение этой истории?
Оставьте свое сообщение