Modèle de guide de processus TFS verrouillé?

Question

Mon équipe cherche à migrer nombre de nos outils (GDS, suivi des bogues, versions, tests) vers TFS. Nous envisageons de déplacer chaque système par étapes. Par exemple, déplacez d'abord le contrôle de source, le suivi de bogues / fonctionnalités ensuite, etc.

Étant donné que nous devons choisir un modèle de processus pour utiliser le contrôle de source (ou quoi que ce soit dans TFS) quelle est notre position en ce qui concerne la décision? , je cherche à éviter de créer un autre projet plus tard ( ou n’est-ce pas aussi grave que je le pense?).

Je sais que, en théorie, je peux personnaliser tout ce que le modèle de processus configure après coup (n'est-ce pas?), mais dans quelle mesure est-ce faisable dans la pratique?

Voici comment je vois les choses se passer:

1. Nous migrons notre code source. Nous avons choisi le modèle CMMI de Microsoft.
2. Nous créons un nouvel élément de travail (ou une note d'enregistrement) qui constitue un simple lien vers notre système de suivi des bogues hérité.
3. Nous travaillons quelque temps.
4. Nous attendons que les pouvoirs en place (nous sommes une entreprise de logiciels de taille décente) pour mettre au point un nouveau flux de travail de développement TFS. Cela peut être une simple collection de nouveaux éléments de travail ou un tout nouveau modèle qui configure toutes sortes de choses.
5. Nous essayons de migrer notre projet TFS vers ce nouveau système sans perdre notre historique.

Allons-nous regretter de ne pas avoir attendu que toutes ces décisions soient finalisées avant d'utiliser TFS?

Answer 1

Vous avez donc raison de penser à votre modèle de processus car il existe une certaine quantité de "verrouillage". Cependant, ce n'est pas trop grave. C'est comme si vous étiez collé à votre modèle de processus avec du miel plutôt que de la super colle.

Personnellement, je commencerais par le modèle MSF Agile. Il est beaucoup plus léger et contient moins d’éléments de travail - vous avez donc plus de chances de vouloir y ajouter des éléments (très facile dans TFS, très bien pris en charge) plutôt que de les enlever (plus compliqué et pas tout à fait satisfaisant).

Cependant, si le pouvoir en place décide de mettre en place un processus de définition de processus complexe et de créer un nouveau modèle de processus comme par magie dans un délai de 12 mois, il ne souhaite pas que vous l'utilisiez, il n'est pas complètement perdu. Si vous souhaitez créer un tout nouveau projet d'équipe, à condition qu'il se trouve sur ce serveur (ou la collection de projets dans TFS 2010), vous pouvez alors diriger votre code vers le nouveau projet d'équipe (ce qui signifie que l'historique est un peu plus complexe. masqué dans les versions actuelles des clients TFS) ou vous pouvez créer un nouveau projet d'équipe avec un dossier vide pour le contrôle de la source, puis déplacer les dossiers enfants de l'ancien projet d'équipe vers le nouveau. Cela préservera parfaitement l'historique car TFS conserve l'historique des déplacements sur la même instance TFS. Vos éléments de travail antérieurs au déménagement resteront toutefois dans l'ancien modèle de processus et vous devrez décider si vous souhaitez les copier ou tout simplement les laisser se dérouler naturellement.

Évidemment, en utilisant réellement TFS pendant 12 mois sur de vrais projets, lorsque les pouvoirs à venir vous porteront atteinte, vous serez également dans une bien meilleure position pour savoir à quoi ressemblera votre tout nouveau modèle de processus - et je 'avons souvent constaté qu'il s'agit d'un exercice qui ne se produit jamais et que la plupart des gens sont heureux de bricoler MSF Agile ou de choisir quelque chose de plus normatif, comme Scrum For Team System .

J'espère que cela vous aidera,

Martin.