Как смоделировать подготовку истории для вопросов, которые решаются в нескольких проектах

В нашей компании несколько команд будут работать над разными компонентами нескольких проектов одновременно. Например, одна группа может сделать определенные виды программного обеспечения (или аппаратного обеспечения) для какого-либо проекта (-ов), а другая группа - другой конкретный вид программного обеспечения. Мы используем проекты Jira для размещения вопросов для конкретных проектов и доски Jira для спринтов для разных команд.

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

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

Приоритизация осуществляется путем сортировки проблем, и мы ставим sortedметки на отсортированные проблемы (чтобы мы могли искать несортированные). Затем мы вручную помещаем одну проблему для каждого базового компонента в верхнюю часть журнала, чтобы их сначала удалось решить. Когда некоторые команды помещают такую ​​проблему в свой спринт, им приходится вместо этого вручную перетаскивать другой элемент в верхнюю часть журнала.

Это довольно подвержено ошибкам. По сути, у нас есть дополнительные статусы выпуска «отсортированы» и «оценены» между «открыто» и «в процессе». Отражение этого через sortedярлык и их положение на доске довольно громоздко и подвержено ошибкам. (Например, если кто-то переместит проблему в каком-то спринте вверх и вниз, это будет отражено на основной плате, молча разбирая порядок проблем, о которых команда могла решить в ходе обширного обсуждения несколькими неделями ранее.)

Так что будет лучшим способом реализовать это?

Если вы хотите отследить это в JIRA, я бы выполнил это, как если бы это было новым заданием.

Так, например:

Допустим, у вас есть история CORE-75: Foo the Bar .

После того, как решено, какая команда возьмет на себя задачу, они могут создать новую задачу: SUPPORT-123: Foo the Bar in Core .

Затем вы можете заблокировать CORE-75 с помощью SUPPORT-123 . Как только SUPPORT-123 закончен, вы можете вернуться к CORE-75 . Либо вы можете объединить рецензии, либо пересмотреть код дважды (один раз назначенной группой, один раз более специализированной группой).

В любом случае это действительно то, что вы делаете: рассматривайте основную библиотеку как свой собственный продукт / клиента, не идите наполовину.

Один из подходов состоит в том, чтобы команда создала новую проблему для своего спринта, которая связана с основной проблемой библиотеки. Это похоже на то, что вы делаете подзадачу для задачи, но через доски / резервы.

Другой подход - просто отслеживать это отдельно от JIRA. Экспортируйте существующее отставание как CSV или электронную таблицу и организуйте это.

Отделяя проблемы от JIRA, вы можете гибко определять приоритет на совещании по планированию, и вам не нужно беспокоиться об алгоритме сортировки JIRA на досках, и вам также не придется использовать метки.

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

Существует мнение, что базовые библиотеки, которые содержат много общих, но не связанных функций, являются «плохой вещью» (tm)

Есть несколько причин для этого

• Они вытягивают зависимости и код, который вам не нужен
• Изменение их приводит к изменениям во всех приложениях
• Нет единого «владельца»

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

Я думаю, что лучшим решением для вас было бы отказаться от наличия «базовых библиотек». Библиотеки должны иметь определенный (небольшой) набор логически сгруппированных функций. Должна быть возможность завершить их. то есть JsonParser, LogWriter и т. д., редко имеет смысл добавлять новую функцию.

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

Задача: добавить функцию X к продукту Y

Dev: хм, некоторый код для функции X должен идти в базовой библиотеке ... Я поставлю ее как часть этой задачи