Beste Projektmanagement-Tools, die Quellcodeverwaltung, Baumeister und Wiki [geschlossen]

Question

Hallo dort. Ich setze ein neues Software-Team zusammen, und ich freue mich auf verschiedene Tools, die früheren Albträume zu überwinden ich mit anderen Teams hatten.

In den letzten 5-6 Jahren das sind einige Übergänge I bis gegangen sind:

Sourcecontrol:
CVS => VSS => SVN

Projektmanagement, Bug und Issue Tracking:
Papier => PostIt Hinweise => OneNote => BUGNET => OnTime

Wiki und Dokumentation:
Word + Network Share => ScrewTurn Wiki

Builder Automation:
Cruise Control + MSBuild

Nun, speziell wegen SVN und die Wiki Situation, ich suche in diesem Team mit etwas frisch zu starten. In der Vergangenheit haben wir Verzweigung Alpträume mit SVN haben, und je mehr wir versuchen, es zu beheben, das Schlimmste wird es. Die andere Herausforderung, die ich habe, ist, etwas zu finden, die stabil und integriert ist. Sie können sich vorstellen, dass BUGNET + SVN + ScrewTurn + CruiseControl- + MSBuild sind ganz andere Tiere, so Integrations- und Synergie sehr wichtig ist; Ich will nicht jumpint zwischen 10 verschiedenen Anwendungen um einen Fehler oder assign Aufgaben Bericht zu erstatten und die Arbeit abgeschlossen und Blick auf dem Repo Protokoll.
So, das neue Team und ich habe dies gesprochen heraus für ein paar Tage jetzt, und ich denke, dass wir es verengt haben bis 2 posibilities nach unten:
1. TFS 2010
Pros:
- All-in-One-Lösung. Es hat wirklich alles, einschließlich einer neuen SCRUM Prozessvorlage.
-. Sehr freundliche Benutzeroberfläche und Sharepoint-Integration
-. WYSIWYG Wiki und Office Integration
Nachteile:
- Hohe Investitionskosten in Hardware und Server-Betreiber Zeit. Software auch, aber es wirkt sich uns nicht, weil wir ein MSDN-Abonnement mit freier Software haben.
- Ich bin zögerlich über die Quelle Steuerung von TFS. SC ist dateibasiert und mit zentralen Repository wie SVN und VSS. Ich möchte wirklich nicht für die gleichen Themen fallen wir in der Vergangenheit gehabt haben.

2. FugBUgs + Ofen + CC
Pros:
- Kiln nutzt Mercurial, mit allen Vorteilen von verteilten Quellcodeverwaltung
. - Gering Investitionskosten und Planungszeit, um es zum Laufen. $ 30.00 pro Benutzer und Monat.
-. Sehr freundlicher Web-Benutzeroberfläche
-. WYSIWYG Wiki-Editor
- Sehr einfacher issue tracker und Projektmanagement-Tools. Es wäre leicht, SCRUM Prozesse zu integrieren.
Nachteile:
- Lacks Builder Automatisierungstools für mehr integrierte Prozesse (wie TFS). So wird dies bedeuten, werden wir auf hämmern unsere Köpfe mit Kommandozeilen-Funktionen und Community-Aufgaben halten müssen, um unsere Baumeister Arbeiter zu halten.

Zurück in dem Tag, habe ich Visual Studio Team System 2005 und ich habe nicht die besten Erinnerungen mit mir über das System; aber die neue TFS 2010 scheint eine sehr solide Wette. FogBugz und Mercurial sind ein bisschen wie die neuen Kinder im Block und bringen sie ein neues Denken an die neuen Prozesse, aber wie immer ist dies ein zweischneidiges Schwert.
Jeder mit soliden Erfahrungen mit dieser kommt? Fehlen diese dritte Option? Haben Sie diesen Königsweg für meine Probleme?

1. Tools Integration
   1.1. Source Control
   1.2. Wiki
   1.3. Build Automation
   1.4. Projektmanagement
   1.5. Issue Tracker
2. Minimieren Source Control Verzweigen und Zusammenführen Konflikte (ja, es ist notwendig, dass wir verzweigen und Zusammenführung)
3. Friendly User Interface (nicht jeder CMD Hacker)
4. WYSIWYG Wiki.
5. Learning Curve für Entwickler.
6. Zeit alles läuft VS zu erhalten Langzeitwert.

Das neue Team hat vier Teammitglieder + 1 Project Manager (Scrum Master) und 1 Product Manager (Product Owner). Also haben wir über ein relativ kleines und neues Team sprechen. der Umfang und die Projekte, die wir auf arbeiten werden ist groß, Enterprise-Anwendungen mit mehreren Projekten und Verzweigungs Variationen

Answer 1

Ich schlage vor, Sie TFS 2010 und Visual Studio 2010 zu verwenden (wenn Sie .NET-Anwendungen entwickeln)

Sie haben keine Sorgen zu machen SC bei TFS müssen. TFS speichert alles in SQL Server DB. TFS arbeitet auf einem Web-Server, so dass Sie Ihre Source-Control-Verbindung herstellen können, wo Sie wollen.

WI-Tracking ist ein Plus. TFS hat einen erstaunlichen WI-Tracking-Mechanismus. Sie können Ihre WIs anpassen, wenn Sie möchten. TFS unterstützt zusätzliche Software-Prozess, wie MSF, CMMI oder Agile.

Testfähigkeiten von TFS 2010 ist perfekt. Wenn Sie mit Visual Studio 2010 verwenden Sie Ihre efectiveness mit TFS 2010 maximieren können.

Branching ist immer ärgerlich, wenn die Zeit, zu fusionieren kommt; aber TFS 2010 Allways hilft Ihnen. Sie können Änderungen an Ihren Quellen vor Zweigen und verschmilzt verfolgen.

TFS 2010 Build Mechanismus unterstützt WorkFlow. So können Sie sehr Buildprozess leicht anpassen; wenn dies für Sie nicht okey ist, können Sie zusätzliche Batch-Dateien (MsBuild).

TFS 2010 hat eine einfachere Verwaltung Betrieb dann TFS 2008 und 2005. Sie können ganz einfach erstellen Build-Agenten, Maschinen, Projektsammlungen, etc ...

TFS 2010 unterstützt fast alle MS-Produkte; wie MS-Office. Excel hat eine große Integration mit TFS oder MS Project. Vergessen Sie nicht, Sharepoint.

TFS ist nicht nur ein Quellcodeverwaltungssystem, ist TFS ein Projektmanagement-System, Application Lifecycle Management-System, workitem-Tracking-System, und so weiter ..

Aber ich weiß, dass Sie nicht TFS von MSDN Subs für kommerzielle Zwecke nutzen. Da dies nur für Test und nur 5 Benutzer eine Verbindung herstellen können (ich bin nicht ganz sicher)

Wenigstens Sie hat nicht TFS auf einem dedizierten Server einrichten, wenn Sie wollen (dies wird nicht empfohlen). Sie können bis auf Win7 gesetzt, wenn Sie wollen, und TFS können auf SQL Server Express arbeiten

So schlage ich vor, TFS Sie 2010. Wenn Sie NET-Anwendungen nichts entwickeln kann besser sein dann TFS.

Answer 2

Wie groß wird Ihr Team sein, und welche Methodik / Rollen wird jeder Einsatz?

Ich würde sagen, wenn es ein großes Team ist, TFS könnte Ihre Bedürfnisse mehr gerecht wird.
Vor allem, wenn Sie brauchen, um Sharepoint zu veröffentlichen oder mehr definierte Rollen in Ihrem Team.

Wenn Sie jedoch einen kleineren Maßstab Lösung wollen, die ein kleineres Team besser passen, so etwas wie SVN / Trac / Cruise Control könnte am besten Ihre Bedürfnisse ein.

Answer 3

Sie klingen wie Sie nach etwas wie Trac suchen.

Trac ist ein erweitertes Wiki und Issue-Tracking-System für Software-Entwicklungsprojekte. Trac verwendet einen minimalistischen Ansatz auf Web-basierte Software-Projektmanagement. Unsere Aufgabe ist es, helfen Entwicklern große Software schreiben, während der Art und Weise bleiben aus. Trac sollte so wenig wie möglich auferlegen eines Teams etablierten Entwicklungsprozess und Politik.

Es stellt eine Schnittstelle zu Subversion (oder andere Versionskontrollsysteme), ein integriertes Wiki und komfortable Berichtsmöglichkeiten.

Trac kann mit Plugins erweitert werden. Der Trac-Hack Wiki ist der richtige Ort für Plug-in gehen.

Hier ist eine andere Frage Stackoverflow für fragen empfohlen Trac Plugins .

Answer 4

Redmine zur Rettung.

Answer 5

Bisher habe ich bisher sehr zufrieden mit atlassian Produkt (e). JIRA integriert sich sehr gut mit Subversion. Wenn Sie einen Text-Tag in Ihrer Nachricht verpflichten bieten, wird JIRA als auch Fragen im Zusammenhang Codeänderungen angezeigt werden soll. Statt FishEye zu verwenden, websvn war das Werkzeug der Wahl als SVN-Web-Frontend. Wenn Ihr nur für ein 'Wiki' suchen, foswiki macht einen guten Job. Aber ich bin auf der Suche mehr von einem Linux-Winkel an der Werkzeugkette.

Answer 6

Absolut keine ungut, aber ... Sie halten zu ändern - Sie, warum in Betracht gezogen haben? Und wie sicher kann man sein, dass man sich nicht wieder finden zu verändern. Investieren Sie zusätzliche Zeit und Mühe darauf fest diesmal bekommen.

Ohne auf spezifische Tools Beratung, ich werde Ihnen raten, zwei Dinge zu tun.

1) Blick für ein Werkzeug Kette - nicht nur eine Sammlung von Werkzeugen. Siehe zum Beispiel eine echte „Tool-Kette“ Sucht, die Werkzeuge, die gut zusammen spielen diskutiert . Ein glattere Arbeitsablauf sollte Zeit sparen und könnte die Projekterfolgschancen erhöhen.

Ich nehme zur Kenntnis, dass Sie sagen: „Sie können sich vorstellen, dass BUGNET + SVN + ScrewTurn + CruiseControl- + MSBuild sind ganz andere Tiere, so Integrations- und Synergie sehr wichtig ist, „, Also denke ich, dass wir uns einig sind, dass man auf

2) Sie müssen die Akzeptanz von den Menschen, die diese Tools verwenden. Sie präsentieren sie nicht mit einem fait accompli, fragen, was sie denken - im Voraus. In der Tat, leinwand sie für Anregungen. Dieser Punkt könnte im Lichte des vorherigen Punktes schwierig sein.