Comment modéliser la préparation d'une histoire pour des problèmes abordés dans plusieurs projets

Dans notre entreprise, plusieurs équipes travailleront sur différentes composantes de plusieurs projets en même temps. Par exemple, une équipe peut créer des types spécifiques de logiciels (ou matériels) pour certains projets, une autre équipe un autre type spécifique de logiciels. Nous utilisons des projets Jira pour héberger des problèmes pour des projets spécifiques et des tableaux Jira pour des sprints pour différentes équipes.

Nous sommes confrontés au problème d'éviter la duplication de code entre les projets et avons développé un ensemble de bibliothèques de base que nous utilisons dans ces projets. Tout en travaillant sur un projet, certains développeurs se rendront compte qu'un morceau de code qu'ils ont écrit présente un plus grand intérêt et devrait être extrait dans une bibliothèque de base, ou que le code de base qu'ils utilisent a un bogue, a besoin de plus de paramétrage, ou d'un nouvelle fonctionnalité ... vous l'appelez.

Ils créent donc un problème de bibliothèque de base qui va dans le backlog du projet de base. Tous ces problèmes sont examinés, classés par ordre de priorité et estimés lors d'une réunion de la bibliothèque centrale (une fois par semaine), et seront abordés en fonction de leur priorité (parallèlement aux problèmes spécifiques au projet) dans certains sprints futurs.

La hiérarchisation se fait en triant les problèmes, et nous mettons une sortedétiquette sur les problèmes triés (afin que nous puissions rechercher les problèmes non triés). Ensuite, nous plaçons manuellement un problème par composant principal en haut de l'arriéré afin de les résoudre en premier. Lorsqu'une équipe met un tel problème dans son sprint, elle doit plutôt faire glisser manuellement un autre élément en haut du backlog.

C'est assez sujet aux erreurs. Fondamentalement, nous avons les statuts de problème supplémentaires "triés" et "estimés" entre "ouvert" et "en cours". Refléter cela à travers l' sortedétiquette et leur position dans la planche est plutôt encombrant et sujet aux erreurs. (Par exemple, si quelqu'un déplace un problème dans un sprint de haut en bas, cela se reflétera dans le tableau principal, brouillant silencieusement l'ordre des problèmes que l'équipe aurait pu décider au cours d'une discussion approfondie des semaines plus tôt.)

Alors, quelle serait une meilleure façon de mettre en œuvre cela?

Si vous voulez suivre cela dans JIRA, je le suivrais comme s'il s'agissait d'une nouvelle tâche.

Ainsi, par exemple:

Disons que vous avez l'histoire CORE-75: Foo the Bar .

Une fois qu'il est décidé quelle équipe va prendre la tâche, ils peuvent alors créer une nouvelle tâche: SUPPORT-123: Foo the Bar in Core .

Vous pouvez ensuite bloquer CORE-75 avec SUPPORT-123 . Une fois SUPPORT-123 terminé, vous pouvez revenir au CORE-75 . Vous pouvez soit fusionner les évaluations, soit réviser le code deux fois (une fois par l'équipe désignée, une fois par une équipe plus spécifique au cœur).

C'est vraiment ce que vous faites de toute façon: considérez la bibliothèque principale comme son propre produit / client, ne faites pas la moitié du chemin.

Une approche consiste pour l'équipe à créer un nouveau problème pour leur sprint qui renvoie au problème de la bibliothèque principale. C'est un peu comme si vous créez une sous-tâche pour une tâche, mais dans tous les conseils / backlogs.

Une autre approche consiste simplement à suivre cela séparément en dehors de JIRA. Exportez le backlog existant au format CSV ou feuille de calcul et organisez-le.

En séparant les problèmes de JIRA, vous avez la flexibilité de définir la priorité lors de la réunion de planification et vous n'avez pas à vous soucier de l'algorithme de tri de JIRA sur les tableaux et vous n'aurez pas non plus à utiliser d'étiquettes.

Lors de la réunion de planification des priorités pour la bibliothèque principale, vous pouvez créer une liste de tâches à effectuer pour la bibliothèque principale et quiconque est responsable / responsable de la bibliothèque principale peut s'assurer que ces tâches sont démarrées par les différentes équipes de projet et terminées.

Il y a une opinion que les bibliothèques de base qui encapsulent beaucoup de fonctionnalités communes mais non liées sont une «mauvaise chose» (tm)

Il y a plusieurs raisons à cela

• Ils tirent des dépendances et du code dont vous n'avez pas besoin
• Les modifier entraîne des modifications dans toutes les applications
• Pas de «propriétaire» unique

Dans votre cas, je pense que votre répartition des tâches par l'application à laquelle le changement serait apporté est à l'origine du problème. Une sorte de loi inverse de Conway.

Je pense que la meilleure solution pour vous serait de s'éloigner des bibliothèques de base. Les bibliothèques devraient avoir un (petit) ensemble spécifique de fonctionnalités regroupées logiquement. Il devrait être possible de les compléter. c'est-à-dire JsonParser, LogWriter, etc., il devrait rarement être judicieux d'ajouter une nouvelle fonctionnalité.

Cependant, en supposant que ce serait une tâche longue et difficile, en tant que solution secondaire, je garderais simplement les tâches principales de la bibliothèque avec l'équipe qui a besoin de la fonctionnalité. c'est à dire.

Tâche: ajouter la fonctionnalité X au produit Y

Dev: hmm une partie du code de la fonctionnalité X devrait aller dans une corelibrary .. Je vais le mettre là dans le cadre de cette tâche