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

9

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?

sbi
la source
2
Semble beaucoup trop de frais généraux diplomatiques juste pour ajouter une fonction à une bibliothèque. Dans notre entreprise de 50 développeurs (logiciels médicaux), nous permettons toujours aux développeurs de simplement pousser le code vers chacune de nos bibliothèques internes s'ils le jugent approprié. C'est revu par la suite bien sûr. Vous pouvez peut-être envisager de travailler avec un flux de demande mais une réunion? Non, ça ne marchera jamais.
Teimpz
@Teimpz: Bien sûr, tout le monde va pousser vers les bibliothèques internes, et, bien sûr, chaque code est examiné. Cependant, l'ordre dans lequel les problèmes fondamentaux sont abordés (qui ne sont pas nécessaires pour certains projets en cours) est décidé par toutes les équipes. Cela fonctionne plutôt bien, seul Jira ne semble pas bien le supporter.
sbi
Les frais généraux semblent un peu, mais étant donné que le cœur est si largement utilisé, je serais prêt à accepter un peu de frais généraux pour m'assurer que rien ne va mal. Une réunion semble cependant beaucoup. Je le verrais comme n'importe quelle autre tâche, mais une communication supplémentaire - critiques, conversations - serait importante.
Erdrik Ironrose

Réponses:

2

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.

Erdrik Ironrose
la source
Cela semble lourd, mais oui, cela fonctionnerait. Donc +1de moi.
sbi
0

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.

Ancien compte
la source
-2

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

Ewan
la source
Cela semble étrange. Pour commencer: Selon vous, quelle est la différence entre ce que vous appelez des "bibliothèques avec un petit ensemble spécifique de fonctionnalités regroupées logiquement" et ce que nous appelons des "bibliothèques de base"? (BTW: Il semble que j'ai manqué la notification pour cette réponse. Désolé d'avoir répondu si tard.)
sbi
Je pense que c'est la citation la plus remarquable pour moi: "un morceau de code qu'ils ont écrit est d'un plus grand intérêt et devrait être extrait dans une bibliothèque de base". Si vos projets partagés sont des «bibliothèques» complètes de fonctionnalités, vous n'avez jamais besoin de leur ajouter une fonctionnalité.
Ewan
Je ne comprends pas votre argument. Pourquoi un code ne bénéficierait-il pas de la maintenance? Et vos clients ne demandent-ils jamais de nouvelles fonctionnalités, conduisant à l'écriture d'un nouveau code? Et comment savez-vous que le code est d'intérêt commun, autrement qu'en se faisant attribuer un autre projet avec une exigence déjà intéressée?
sbi
Supposons que votre bibliothèque soit Json.Net. il a un seul objet sérialiser les objets à json et inverser. vous devrez peut-être corriger un bogue ou ajouter la prise en charge des génériques, mais l'ensemble des fonctionnalités ne change jamais. Vous n'êtes jamais dans la position où, par exemple, un client vous demande de mettre en œuvre «la possibilité d'annuler des commandes» ou quoi que ce soit et vous pensez, «je vais ajouter cela à Json.Net»
Ewan