пользовательские истории, собранные и уточненные с использованием gerrit в качестве основного средства коммуникации

Я унаследовал процесс, в котором gerrit используется для сбора пользовательских историй и совместной работы над ними.

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

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

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

Вопрос. Можно ли эффективно собирать истории и совместно работать над ними с помощью gerrit? Если да, то как это можно сделать?


person Chris Snow    schedule 29.10.2013    source источник
comment
захватывать истории откуда? что вы имеете в виду под редактированием историй?   -  person laplasz    schedule 30.10.2013
comment
Истории собираются в основном из неструктурированных «разговоров» по ​​электронной почте с заинтересованными сторонами. Один человек попытается извлечь истории из электронных писем. Истории переданы в git и опубликованы для просмотра с помощью gerrit. Затем заинтересованные стороны используют систему комментариев gerrit, чтобы сообщить, правильно ли автор статей понял требования. Истории будут отредактированы первоначальным автором на основе комментариев, а затем повторно отправлены с использованием патчей git. Этот автономный цикл может повторяться несколько раз.   -  person Chris Snow    schedule 30.10.2013
comment
какой репозиторий задач вы используете для отслеживания историй? или я думаю, что это то, чего сейчас не хватает, поскольку вы упоминаете электронные письма вместо bugzilla, jira, tuleap   -  person laplasz    schedule 30.10.2013
comment
Истории просто фиксируются в виде текстовых файлов в git. Другого репозитория задач нет.   -  person Chris Snow    schedule 30.10.2013


Ответы (1)


Я думаю, что это проблема - у каждой истории должен быть идентификатор. А используя репозиторий задач, вы можете очень легко сотрудничать с клиентами над историями. Gerrit — это инструмент для проверки, а не средство отслеживания проблем. Сообщение фиксации должно содержать идентификатор проблемы. если вы используете Tuleap в качестве средства отслеживания проблем, оно интегрируется с Gerrit. Таким образом, если сообщение фиксации содержит идентификатор проблемы, клиент может щелкнуть идентификатор и перейти к проблеме/истории.

person laplasz    schedule 30.10.2013
comment
Должен ли каждый сценарий в истории иметь идентификатор? Или это слишком низкий уровень? - person Chris Snow; 30.10.2013
comment
Истории могут/должны иметь подзадачи. Каждая подзадача имеет идентификатор. Таким образом, в этом случае история является контейнером/родителем подзадач/дочерних задач. Коммит должен содержать изменения данной подзадачи. Так что да, это хорошая практика - разбивать историю на подзадачи. - person laplasz; 30.10.2013