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

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

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Pr-Mex 130 21.03.20 15:25 Сейчас в теме
Интересно про реверс инжиниринг активностей пользователя.
Vladimir Litvinenko; 1ceo_2015; +2 Ответить
2. Vladimir Litvinenko 2535 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 2535 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 152 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 Ответить
Оставьте свое сообщение
Вопросы с вознаграждением