Les meilleurs outils de gestion de projet, contrôle de code source, constructeur et wiki [fermé]

Question

Howdy là. Je prépare une nouvelle équipe de logiciel et je suis à la recherche à différents outils qui permettent de surmonter les cauchemars précédents, je l'ai eu avec d'autres équipes.

Au cours des 5-6 dernières années, ce sont des transitions que je suis allé à travers:

SourceControl: CVS => VSS => SVN

Gestion de projet, Bug et Suivi des problèmes: Papier => PostIt Remarques => OneNote => Bugnet => OnTime

Wiki et Documentation: Réseau mot + Partager => ScrewTurn Wiki

Builder Automatisation: Régulateur de vitesse + MSBuild

, en particulier à cause de SVN et la situation Wiki, je suis à la recherche en commençant cette équipe avec des produits frais quelque chose. Dans le passé, nous avons eu des cauchemars avec branchement SVN, et plus nous essayons de le corriger, le pire devient. L'autre défi que j'ai est de trouver quelque chose qui est stable et intégré. Vous pouvez imaginer que Bugnet + SVN + ScrewTurn + CruiseControl + MSBuild sont des animaux tout à fait différents, donc l'intégration et la synergie est très importante; Je ne veux pas être jumpint entre 10 applications différentes pour signaler un bug ou Assigner des tâches et examiner le travail terminé et consultez le journal des prises en pension.
Ainsi, la nouvelle équipe et j'ai parlé ceci pendant quelques jours maintenant, et je pense que nous avons tenté d'en bas à 2 posibilités:
1. TFS 2010 Avantages: - solution tout-en-un. Il a vraiment tout, y compris un nouveau modèle de processus Scrum.
-. Interface utilisateur très sympathique et l'intégration SharePoint
-. WYSIWYG Wiki et Bureau de l'intégration
Moins: - coûts initiaux élevés dans le matériel et le temps d'administration. Logiciel aussi, mais cela ne nous touche pas parce que nous avons un abonnement MSDN avec le logiciel libre.
- Je hésite sur le contrôle source de TFS. SC est basée sur fichier et référentiel central comme SVN et VSS. Je ne veux pas tomber pour les mêmes problèmes que nous avons eu dans le passé.

2. FugBUgs + CC + Kiln Avantages: - Kiln utilise Mercurial, avec tous les avantages du contrôle de source distribué
. - les coûts initiaux minimes et le temps de planification pour l'obtenir et en cours d'exécution. 30,00 $ par utilisateur et par mois.
-. Interface utilisateur Web très sympathique
-. Éditeur WYSIWYG Wiki
- Très simple suivi des problèmes et des outils de gestion de projet. Il serait facile d'intégrer les processus Scrum.
Moins: - manque d'outils d'automatisation pour les processus plus intégrés constructeur (comme TFS). Donc, cela signifie que nous devrons continuer à frapper nos têtes avec des fonctions de ligne de commande et les tâches communautaires pour maintenir nos travailleurs de constructeur.

De retour dans la journée, j'ai utilisé Visual Studio Team System 2005 et je ne prenais pas les meilleurs souvenirs avec moi sur le système; mais le nouveau TFS 2010 semble un pari très solide. FogBugz et Mercurial sont un peu comme les nouveaux enfants dans le bloc et ils apportent des idées nouvelles aux nouveaux processus, mais comme toujours c'est une épée à double tranchant.
Toute personne ayant une solide expérience avec l'un de ces? Avons-nous oublié que 3ème option? Avez-vous cette balle d'argent pour mes problèmes?

1. Outils d'intégration
   1.1. Source de contrôle
   1.2. wiki
   1.3. Automatisation de construction
   1.4. Gestion de projet
   1.5. Issue Tracker
2. Réduire au minimum Source de contrôle Branching et les conflits (oui Fusion, il est nécessaire pour nous de se lancer et fusion)
3. Amical Interface utilisateur (pas tout le monde est pirate CMD)
4. WYSIWYG Wiki.
5. Learning Curve pour les développeurs.
6. Temps pour obtenir tout VS. course Valeur à long terme.

La nouvelle équipe a 4 membres de l'équipe + 1 Chef de projet (Scrum Master) et 1 Product Manager (Product Owner). Donc, nous parlons d'une équipe relativement petite et nouvelle. la portée et les projets que nous allons travailler est grande, les applications d'entreprise avec de multiples projets et variations de branchement

Answer 1

Je vous suggère d'utiliser TFS 2010 et Visual Studio 2010 (si vous développez des applications .Net)

Vous n'avez pas à vous soucier de SC à TFS. stocke TFS tout dans DB SQL Server. TFS fonctionne sur un serveur web, de sorte que vous pouvez connecter votre contrôle de code source où vous voulez.

suivi WI est un plus. TFS a un mécanisme de suivi incroyable WI. Vous pouvez adapter vos SOF si vous voulez. TFS prend en charge le processus logiciel supplémentaire tel que MSF, CMMI ou agile.

capacités de test de TFS 2010 est parfait. Si vous utilisez avec Visual Studio 2010, vous pouvez maximiser votre efcacité avec TFS 2010.

Branching est AllWays ennuyeux quand vient le temps de fusion; mais TFS 2010 AllWays vous aide. Vous pouvez suivre les changements à vos sources avant de les branches et les fusions.

TFS 2010 prend en charge du mécanisme de construction WorkFlow. Ainsi, vous pouvez personnaliser votre très processus de construction facilement; si ce n'est pas Okey pour vous, vous pouvez utiliser les fichiers de traitement par lots supplémentaires (MSBuild).

TFS 2010 a une opération d'administration plus facile alors TFS 2008 et 2005. Vous pouvez facilement créer des agents de construction, des machines, des collections de projets, etc ...

TFS 2010 prend en charge presque tous les produits de MS; tels que MS Office. Excel a une grande intégration avec TFS ou MS Project. Ne pas oublier Sharepoint.

TFS est non seulement un système de gestion de code source, TFS est un système de gestion de projet, l'application du système de gestion du cycle de vie, workitem système de suivi, etc. ..

Mais je sais que vous ne pouvez pas utiliser TFS de MSDN Subs à des fins commerciales. Parce que ce n'est que pour le test et seulement 5 utilisateur peut se connecter (je ne suis pas exactement sûr)

Au moins, vous ne deviez pas mettre en place TFS sur un serveur dédié si vous voulez (ce n'est pas recommandé). Vous pouvez configurer sur Win7 si vous voulez et TFS pouvez travailler sur SQL Server Express

Alors je vous suggère de TFS 2010. Si vous développez rien .Net Apps peut être mieux que TFS.

Answer 2

Quelle sera votre équipe soit, et quelle méthodologie / rôles utilisera tout le monde?

Je dirais que si c'est une grande équipe, TFS peut plus répondre à vos besoins.
Surtout si vous avez besoin de publier sharepoint, ou ont des rôles plus définis dans votre équipe.

Toutefois, si vous voulez une plus petite solution à grande échelle, ce qui conviendra à une plus petite équipe mieux, quelque chose comme SVN / Trac / Cruise Control pourrait mieux répondre à vos besoins.

Answer 3

On dirait que vous cherchez quelque chose comme Trac .

  

Trac est un wiki amélioré et un système de suivi des projets question de développement de logiciels. Trac utilise une approche minimaliste à un logiciel Web de gestion de projet. Notre mission est de développeurs d'aider à écrire un excellent logiciel tout en restant hors de la route. Trac devrait imposer le moins possible sur le processus de développement mis en place et les politiques d'une équipe.

     

Il fournit une interface pour Subversion (ou d'autres systèmes de contrôle de version), un Wiki intégré et des installations de reporting pratiques.

Trac peut être étendu avec des plugins. wiki de Trac-Hack est l'endroit où aller pour les plugins.

Voici une autre question stackoverflow demander plugins Trac recommandé .

Answer 4

Redmine à la rescousse.

Answer 5

Jusqu'à présent, je suis très satisfait avec Atlassian produit (s). JIRA intègre très bien avec la subversion. Si vous fournissez une étiquette textuelle dans votre message de validation, JIRA affiche des changements de code liés à la question ainsi. Au lieu d'utiliser Fisheye, websvn est l'outil de choix avant la fin de l'svn web. Si votre juste la recherche d'un « wiki », Foswiki fait un bon travail. Mais je suis à la recherche de plus d'un angle de Linux à la chaîne d'outils.

Answer 6

Absolument pas d'infraction prévu, mais ... vous continuez à changer - avez-vous pensé pourquoi? Et quelle confiance peut vous être que vous ne trouverez pas vous changer à nouveau. Investir du temps et des efforts supplémentaires à obtenir cette fois serré.

Sans conseiller sur les outils spécifiques, je vous conseille de faire deux choses.

1) recherchez un outil chaîne - pas seulement une collection d'outils. Voir par exemple A la recherche d'une véritable « chaîne d'outils » qui porte sur des outils qui jouent bien ensemble . Un flux de travail plus fluide devrait gagner du temps et pourrait augmenter les chances de succès du projet.

Je note que vous dites: « Vous pouvez imaginer que Bugnet + SVN + ScrewTurn + CruiseControl + MSBuild sont des animaux tout à fait différents, donc l'intégration et la synergie est très importante « , Donc je pense que nous sommes d'accord sur celui

2) vous devez accepter des personnes qui utiliseront ces outils. Ne pas les mettre devant le fait accompli, demandez ce qu'ils pensent - à l'avance. En fait, les suggestions pour la toile. Ce point pourrait être délicat à la lumière du point précédent.