Je viens de déménager dans une nouvelle entreprise et ils utilisent TFS 2010 (2012 dans quelques mois) comme système de contrôle de version et ont récemment commencé à l'utiliser comme système de suivi du travail pour les développeurs.
Cependant, il ne semble pas y avoir de système de suivi des bogues à l'usage des personnes extérieures au développement et au test. Le support de production reçoit des rapports sur les problèmes, les corrige à la volée et rend compte à leurs utilisateurs pour le moment. Cela doit être changé, mais je ne veux pas vraiment avoir un système spéré pour le suivi des bogues et le suivi du travail de développement.
Existe-t-il un moyen de créer un moyen très léger d'entrer des bogues dans TFS similaire à la façon dont FogBugz le fait? La connexion à TFS pour remplir un rapport de bogue semble être beaucoup plus lourde et vous devez l'associer à une application particulière. Le support peut être en mesure de le faire, mais je veux pouvoir trier l'élément et potentiellement changer l'association en autre chose qu'une application.
J'ai utilisé FogBugz dans le passé et lors de l'ajout d'un bug, vous pouvez en ajouter autant/peu que vous le souhaitez pour qu'il soit au moins enregistré et plus tard, vous pouvez le renvoyer pour obtenir plus d'informations lorsque vous triez le ticket .
Cela dépend en grande partie des champs que vous souhaitez, comme 17 des 26 l'ont indiqué: TFS est hautement personnalisable. La raison [~ # ~] i [~ # ~] voudrait faire cela plutôt que d'utiliser quelque chose comme JIRA, c'est que vous obtenez une vue unique de ce sur quoi vos développeurs travaillent, au lieu d'avoir à agréger deux systèmes.
TFS a également une planification de la capacité des ressources, et si vous ne montrez pas de défauts de production dans votre planification (et qu'ils prennent une fraction importante de votre temps), alors vous ne planifiez pas vraiment votre capacité. Je dirais en fait que c'est une solution idéale pour les équipes où les développeurs utilisent TFS et supportent la production (par exemple DevOps).
Cela ne signifie pas que vous ne pouvez pas utiliser d'autres outils pour le travail principal de support de production/ITIL, il vous suffit de vous assurer qu'ils s'intègrent, manuellement ou de préférence automatiquement. La plupart de ces outils vous permettent de mettre des crochets personnalisés, et TFS le fait certainement.
Quoi qu'il en soit, à la question principale. J'utilise les modèles CMMI TFS (qui fonctionnent réellement bien avec Agile BTW), et je viens d'ajouter un seul champ à l'une des listes déroulantes.
Voici les étapes:
Installer Outils électriques TFS
Ouvrez le modèle d'élément de travail à partir du serveur
Modifiez le champ Discipline
Le domaine de la discipline est le "type" de travail lié au défaut. Les valeurs standard sont:
Nous allons simplement ajouter "Production" à cette liste. Tout d'abord, modifiez le champ Discipline:
Ensuite, cliquez sur l'onglet Règles et modifiez la règle ALLOWEDVALUES:
Ensuite, cliquez sur "Nouveau" et ajoutez "Production" comme l'une des valeurs.
Cliquez sur "OK" à plusieurs reprises jusqu'à ce que vous soyez de retour à la liste des champs.
Enregistrer le modèle d'élément de travail
OK, maintenant vous avez terminé. Vous pouvez créer de nouveaux bogues et indiquer leur type comme Production. Je créerais également quelques requêtes d'élément de travail examinant les défauts de production et les ajouterais à vos éléments épinglés. Enfin, examinez les requêtes de bogues existantes et modifiez peut-être leur ordre afin que les bogues de "Production" apparaissent en premier (si cela est possible).
Non, c'est vrai - le premier ALM de Microsoft n'est pas vraiment utile en dehors de Visual Studio et des équipes de développement.
Vous pouvez accéder aux éléments de travail à l'aide de Team Explorer (qui est une version très réduite de VS) ou y accéder via le site Web TFS. Les options ne sont pas non plus particulièrement bonnes, car les champs de bogues rappellent les anciens traqueurs de bogues "d'entreprise" que j'ai eu la malchance d'utiliser dans le passé.
Il n'y a pas de réelle distinction entre les bogues dans TFS - il n'y a qu'un seul tracker que vous filtrez en utilisant un champ dans l'élément lui-même, alors utilisez un champ de catégorie puis créez un rapport qui ne montre qu'un type particulier de catégorie. Je pense que c'est votre seule option réaliste avec TFS.
Si vous voulez le suivi des problèmes externes, alors je pense que TFS est un mauvais choix, il vaut mieux utiliser quelque chose comme Jira ou Redmine et l'utiliser pour gérer les bugs - leurs interfaces sont beaucoup, beaucoup plus agréables et plus faciles à utiliser que TFS. J'ai particulièrement aimé la façon dont vous pouvez envoyer un e-mail à Redmine et cela crée un nouveau problème pour vous, qui était une fonctionnalité idéale pour les employés hors site.
Ce billet de blog Microsoft décrit les améliorations prévues de TFS qui devraient aider à prendre en charge les frais généraux inférieurs:
Les utilisateurs non développeurs peuvent accéder au système de suivi des éléments de travail TFS en utilisant un navigateur Web pour accéder au Team Project Portal. Pour trouver l'URL, accédez à Équipe-> Afficher le portail de projet dans Visual Studio. À partir de là, toute personne disposant d'autorisations peut parcourir, créer ou modifier des éléments de travail. Ils peuvent également générer toutes sortes de rapports pour examiner l'état des choses.
Les types d'éléments de travail disponibles et les champs des éléments de travail varient en fonction de la configuration de TFS (principalement en fonction des modèles de processus choisis).
Les informations requises pour entrer un bogue dépendent également de la façon dont vous avez configuré TFS. Dans notre cas, nous avons besoin d'un titre, des étapes de reproduction et de la construction dans laquelle il a été trouvé. Le système de suivi des éléments de travail TFS est très puissant et flexible. Cela peut être aussi compliqué ou aussi simple que vous le souhaitez - tout dépend de la façon dont vous l'avez configuré.