Azure DevOps - organisation de projets et de référentiels
(Publier la question ici car il s'agit de la "communauté" vers laquelle Microsoft redirige avec un bouton "Besoin de conseils? Demandez à la communauté". J'espère qu'il ne sera pas fermé comme 'principalement basé sur l'opinion' ou 'trop large')
Bonjour,
Je veux commencer à utiliser AzureDevops dans mon département pour organiser le code et le travail. Nous sommes une petite équipe qui crée un grand nombre d'applications & plugins.
Certaines de ces applications ont un cycle de vie très court , c'est-à-dire que nous les livrons, et elles fonctionnent pendant des années sans modifications. D'autres applications sont plus grandes et sont mises à jour/corrigées sur plusieurs mois ou années .
Ces applications sont complètement distinctes les unes des autres dans tous les aspects .
Pour autant que je comprenne la structure Azure DevOps, mon département devrait devenir une `` organisation '' (nous pouvons/devons être séparés du reste de la société).
Je suis un peu perplexe à propos de la partie "Projet". La documentation dit
En général, nous vous recommandons d'utiliser un seul projet pour prendre en charge votre organisation ou entreprise.
Disons que nous avons un projet appelé Our Apps - où mettre alors tous les projets d'application individuels?
Pour autant que je sache, chaque produit (application) que nous livrons doit avoir son propre référentiel (ou un ensemble d'applications, s'ils sont logiquement connectés) .
Ceci afin de permettre à un développeur de simplement cloner le référentiel sur sa machine et de contribuer à ce produit uniquement - sans télécharger d'autres projets, etc.
J'ai besoin de pouvoir:
- naviguer/voir facilement toutes les dizaines/(centaines?) d'applications que nous créons,
- afficher leurs tableaux de kanban séparés (pour les projets qui en disposent, tous ne le feront pas)
- pour voir leurs référentiels (Git ou TFS), les commit etc
- voir et gérer leurs pipelines
Pour le moment, il me semble que le seul endroit où je peux voir une "liste" de produits quels produits avons-nous est le menu déroulant ci-dessous:
Et la seule façon de voir ce qui se passe dans les produits assez gros pour avoir sa propre carte est de créer une nouvelle 'SomeApp distincte' Team ' dans le projet (même si les mêmes personnes y sont), afin que je puisse avoir un tableau pour SomeApp - et voir les tableaux à partir d'ici:
- Est-ce la manière voulue d'organiser la structure?
- Des approches alternatives?
- Existe-t-il un moyen d'avoir une vue d'ensemble du "référentiel croisé" ou "inter-équipes"?
- Qu'en est-il de la création de documentation pour chaque "produit"?
Le " n projet pour les gouverner tous " a été inventé par Martin Hinshelwood et son billet de blog de back-back-when explique les raisons et les limites.
Avec l'introduction du balisage et du filtrage dans le backlog, il existe une approche alternative dans la configuration d'un projet.
- Créez une équipe pour les vraies équipes que vous avez dans votre organisation.
- Créez un chemin d'accès de zone pour chaque projet/produit majeur dans l'organisation.
- Attribuez les chemins de zone des projets de ces équipes aux équipes. Cela peut changer avec le temps.
- Étiquetez éventuellement les éléments de travail avec le projet/produit principal pour un filtrage supplémentaire.
De cette façon, chaque équipe voit une vue complète de tout le travail dont elle peut tirer. Et ils peuvent rapidement filtrer le travail par balises pour supprimer les éléments de la vue lors de la discussion de projets/produits spécifiques.
De plus, lorsque les équipes changent d'orientation d'un produit/projet à un autre, vous pouvez simplement modifier les zones affectées à cette équipe pour mettre à jour leur vue.
L'extension Plan View fournit une vue transversale supplémentaire sur l'ensemble du travail. Et l'extension Dependency Tracker peut visualiser les dépendances au fil du temps.
Vous pouvez également utiliser l'arborescence Epic/Feature/PBI | UserStory pour créer un regroupement supplémentaire dans vos éléments de travail. Vous pouvez personnaliser le modèle de processus pour introduire un niveau de produit, mais pour que les fonctionnalités de planification fonctionnent, cela signifierait également que vous devez également créer une traçabilité complète du produit jusqu'à PBI | UserStory.
La principale recommandation est d'essayer quelques-unes de ces approches de manière légère pour voir comment elles fonctionnent et trouver votre propre configuration idéale.
Une autre option pour la visualisation de projets croisés consiste à activer Analytics Analytics et connectez-le à PowerBI .
Comme vous le découvrirez bientôt, les directives de dénomination pour vos balises, référentiels, pipelines vont être très importantes. Être capable de filtrer rapidement au bon niveau nécessite cela.