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


9

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

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

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

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

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

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


2
Похоже, слишком много дипломатических затрат, чтобы добавить функцию в библиотеку. В нашей компании из 50 разработчиков (медицинское программное обеспечение) мы по-прежнему позволяем разработчикам просто передавать код в каждую из наших собственных библиотек, если они считают это целесообразным. Его пересмотрены впоследствии, конечно. Вы можете рассмотреть возможность работы с потоком pullrequest, но встречу? Нет, это никогда не сработает.
Teimpz

@Teimpz: Конечно, все будут обращаться к внутренним библиотекам, и, конечно, каждый код пересматривается. Однако порядок, в котором решаются основные проблемы (которые не являются необходимыми для некоторых текущих проектов), определяется всеми командами. Это работает довольно хорошо, только Джира, кажется, не поддерживает это хорошо.
SBI

Издержки выглядят немного, но, учитывая, что ядро ​​широко используется, я хотел бы принять немного накладных расходов, чтобы убедиться, что все в порядке. Встреча кажется очень много, хотя. Я бы воспринял это как любую другую задачу, но дополнительное общение - обзоры, разговоры - было бы важно.
Эрдрик Айронроуз

Ответы:


2

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

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

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

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

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

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


Это кажется громоздким, но, да, это будет работать. Так +1от меня.
ВОО

0

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

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

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

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


-2

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

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

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

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

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

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

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

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


Это кажется странным. Для начала: как вы думаете, в чем разница между тем, что вы называете «библиотеками с определенным небольшим набором логически сгруппированных функций» и тем, что мы называем «базовыми библиотеками»? (КСТАТИ: Кажется, я пропустил уведомление об этом ответе. Извините за ответ так поздно.)
sbi

Я думаю, что это выдающаяся цитата для меня: «фрагмент кода, который они написали, представляет больший интерес и должен быть извлечен в основную библиотеку». Если ваши общие проекты представляют собой полнофункциональные «библиотеки», то вам не нужно добавлять к ним функцию.
Эван

Я не понимаю ваш аргумент. Почему любой код не выиграет от обслуживания? И ваши клиенты никогда не запрашивают новые функции, ведущие к написанию нового кода? И как вы узнаете, что код представляет общий интерес, кроме как при назначении другого проекта с уже заинтересованным требованием?
SBI

Скажем, ваша библиотека - это Json.Net. он имеет одну цель сериализации объектов в JSON и наоборот. конечно, вам может понадобиться исправить ошибку или добавить поддержку обобщений, но общий набор функций никогда не меняется. Вы никогда не окажетесь в положении, когда, например, клиент просит вас реализовать «возможность отмены заказов» или что-то еще, и вы думаете: «Я добавлю это в Json.Net»
Ewan
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.