JIRA vs TFS 2012 en tant que système ALM complet
nous sommes au niveau de la recherche pour choisir un système ALM complet pour notre entreprise. nous considérons TFS 2012 et JIRA pour une utilisation dans les départements produit, gestion de projet, assurance qualité, support et développement. les éléments à prendre en charge sont le suivi des bogues, les flux de travail, les graphiques de projet (tels que le nombre de bogues, la gravure, etc.). des recommandations? prix? autant que je sache, TFS est meilleur pour les équipes de R&D utilisant Visual Studio et moins pour Eclipse.
Voici les avantages de TFS:
- TFS est une solution de gestion du cycle de vie des applications (ALM), mais Jira est simplement un outil de suivi des problèmes. De nombreuses fonctionnalités de TFS, par exemple le contrôle des sources et les builds automatiques ne sont pas pris en charge dans jira et vous devez utiliser d'autres solutions, par exemple Subversion ou Bamboo dans ce but.
- Tous les composants TFS, c'est-à-dire le contrôle des sources, le suivi des problèmes et l'automatisation de la construction sont entièrement intégrés. Un tel niveau d'intégration ne peut être atteint avec d'autres solutions.
- Il est entièrement intégré à Visual Studio.
Voici les avantages de Jira (et d'autres solutions atlasiennes):
- Il a été utilisé dans de nombreux projets open source, par exemple JBoss , Spring , etc.
- Pour lancer TFS, vous avez besoin d'un serveur haut de gamme, MS SQL, etc. Mais Jira pourrait être installé sur un PC ordinaire sur des SGBD ouverts, par ex. mon SQL.
- Si vous utilisez les technologies Java, de nombreux IDE Java, par exemple IntelliJ, Eclipse et Netbeans prennent entièrement en charge Jira. Je n'ai pas vu une telle prise en charge de Nice pour TFS.
- De nombreux plug-ins sont disponibles pour Jira. Vous pouvez les consulter ici .
- Si votre équipe est petite, Jira ne coûte que 10 $. C'est vraiment pas cher.
- Les solutions atlasiennes prennent mieux en charge les technologies Java (Ant, Maven, junit, etc.)
J'ai travaillé avec JIRA/Subversion et maintenant avec TFS 2010, et je pense que JIRA/Subversion sont de bien meilleurs outils.
J'aime l'idée d'avoir le contrôle de source, le contrôle de workitem, le contrôle de build, le contrôle de test dans un package intégré, mais en quelque sorte TFS n'est qu'un en dessous de la mise en œuvre moyenne de tout (sauf Gated Checkin parce que c'est cool).
Le contrôle de version TFS utilise la liaison tout comme VSS, donc effectuer plusieurs extractions de la même chose nécessite un effort supplémentaire. La possibilité de suspendre/reprendre le travail à l'aide de l'étagère TFS est la solution de contournement officielle pour pouvoir effectuer un travail simultané.
TFS va parfois détraquer avec ses verrous de table SQL, il a donc été redémarré. De plus, les index SQL sont brisés de manière aléatoire, donc l'affichage soudain de l'historique des dossiers prend quelques minutes. TFS dans VS2010 doit être en ligne tout le temps pour effectuer toute modification de source, bien que cela ait été corrigé dans VS2012. Mais l'interface graphique VS2012/VS2013 est si étroitement intégrée à TFS, donc si le serveur TFS a des problèmes, alors tout devient lent dans VS. Cela est vraiment visible avec la nouvelle VS2015 CodeLens, où toutes les recherches TFS WorkItem doivent être désactivées, sinon VS2015 restera bloqué plus souvent que d'habitude.
Visual Studio ne parviendra pas une ou deux fois au cours d'une semaine de travail à obtenir la dernière source (parfois silencieusement). Si vous essayez à nouveau d'obtenir la dernière version, cela signifie que vous en avez déjà une. Lorsque vous effectuez une construction, elle échouera bien sûr. La solution consiste à effectuer une version spécifique avec écrasement forcé.
Pour créer un wiki pour la documentation, alors on a SharePoint, et la version 2010 est un outil wiki vraiment merdique.
Pour une raison vraiment étrange, Microsoft System Center (vraiment cher) est complètement détaché de la solution TFS et s'attarde comme une vieille dame. Il est donc très difficile de synchroniser les incidents avec les éléments de travail TFS et de déployer les versions TFS à l'aide de System Center. VS2013 Update 4 inclut désormais la gestion des versions d'InCycles, presque gratuite, qui devrait améliorer l'intégration continue (les applications IIS peuvent utiliser Web Deploy ).
Si vous travaillez avec des trucs avancés comme le branchement de versions, vous serez surpris de la difficulté de générer un document de notes de version (la lecture nécessite des outils tiers non pris en charge). Il n'y a pas d'association automatique de Work Items lors de la fusion à release-branch. Et si vous voulez soudainement publier une nouvelle version, alors aucune aide pour créer un rapport de version qui répertorie les modifications/éléments de travail qui ont été inclus depuis la dernière version publiée.
L'intégration de JIRA/Subversion dans Visual Studio (VisualSVN) est tellement meilleure (ankhsvn est une version alternative open source de VisualSVN). Je ne comprends toujours pas pourquoi Tfs-annotate ne peut pas passer à la prochaine version précédente comme Svn-blame.
Je n'ai aucune idée de la difficulté de configurer TFS 2010/2012, mais JIRA/Subversion/CruiseControl.NET était très facile et bon marché (je suppose que l'on utiliserait maintenant Git et Jenkins qui prend également en charge Enregistrement sécurisé ).
VS2012 comprend également une refonte de l'ensemble de l'interface utilisateur, qui comprend un nouvel explorateur d'équipe TFS "amélioré" qui est vraiment pénible à travailler en tant que développeur (par rapport à VS2010). Microsoft a déclaré que Team Explorer a été corrigé dans VS201 , mais ce n'est pas vrai. Il suffit de cliquer avec la souris pour effectuer l'archivage et associer des éléments de travail tfs.
Visual Studio 2012 inclut désormais un tableau kanban virtuel, mais je serais surpris que cette fonctionnalité ne soit pas ajoutée à JIRA.
Devenu très surpris lorsque l'équipe Visual Studio a annoncé qu'elle implémenterait la prise en charge GIT dans Visual Studio 2012. Je suppose que c'est plus facile que d'essayer de réécrire TFS dans un système de contrôle de version distribué. J'espère que la nouvelle intégration GIT répondra aux normes de VisaulSVN.
Nous utilisons JIRA et GreenHopper pour toutes nos tâches de développement, de suivi des bogues et de gestion des produits. Nous avons une équipe de 46 développeurs, testeurs et gestionnaires. Il s'intègre pleinement avec Eclipse. Je le recommande fortement.
Les tâches et les workflows sont entièrement personnalisables, vous pouvez ajouter des champs, ajouter une automatisation (comme affecter des tâches aux membres de l'équipe lorsque la tâche change d'état), prendre en charge les pièces jointes par glisser-déposer, etc.
Le prix sur JIRA vient de chuter à un niveau significativement pour hébergement géré .
Eh bien, il s'agit essentiellement de la tendance du marché, SI vous, les gens travaillant sur des technologies open source spécialement Java, principalement des professionnels de Java connaissez JIRA, JIRA a presque tous les types de plugins pour la gestion de projet, SDLC, la révision de code et le suivi des bogues. Mais si vos employés travaillant sur les technologies .net ou Microsoft sont à l'aise avec TFS.
En général, si votre projet est construit en Java (ou autre Open Source), optez pour JIRA. S'il est construit sur les technologies .NET, optez pour TFS.
Théoriquement, vous pouvez utiliser l'un ou l'autre avec Java ou .NET, mais l'intégration ne sera pas aussi serrée et vous devrez utiliser des plugins pour que tout fonctionne.