Як моделювати підготовку розповідей до питань, які вирішуються в кількох проектах

У нашій компанії кілька команд працюватимуть над різними компонентами кількох проектів одночасно. Наприклад, одна команда може зробити певні види програмного забезпечення (або апаратного забезпечення) для певних проектів, інша команда іншого конкретного програмного забезпечення. Ми використовуємо проекти 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 повинен міститись у corelibrary. Я поставлю його там, як частину цього завдання