Jeder möchte seine Erfahrungen mit TFS für Application Life Cycle Management teilen

Question

Wir entwickeln White Label Web und Mobile Healthcare-Anwendung für unsere Kunden. Unser Produkt entwickelt sich schnell und wir unterstützen bestehende Kunden und werden neue Kunden unterstützen.

aktuellen Entwicklungs-Workflow umfasst SVN für Quellcode, Anforderungsdokumente Tracking und Mantis für die Fehlerverfolgung.

Wir betrachten VS TFS 2010 basierte Application Life Cycle Management für unsere Organisation. wir hoffen, dass VS TFS 2010 werden uns helfen, das folgende

1) Anforderungsmanagement 2) Quellcode Versionskontrolle 3) Build-Automatisierung 4) Testmanagement

nur ist jemand noch Erfahrung VS mit fragen zu rationalisieren TFS 2010 und möchten ihre Erfahrungen teilen? Gibt es Alternativen zu VS TeamSystem?

Answer 1

Vorwort: Dies ist eine persönliche Meinung und ich habe keine Verbindungen zu Microsoft außer dass ich mit ihren Tools für ihre Plattform entwickeln, obwohl ich in dieser Antwort als Microsoft-Liebhaber rüber kommen. (was ich bin - ich liebe .NET Entwicklung)

Ich habe TFS 2010 nicht benutzt, aber ich habe die 2005 Team Suite inklusive TFS und den unterstützten Visual Studio Versionen benutzt. Wir sind nicht auf das Jahr 2008 oder 1020 zugegangen, weil die 2005er Version außerordentlich schwer zu installieren war. Wie auch immer, sobald wir es installiert hatten ... Liebte es. Die Projektmanagement-Tools waren intuitiv und funktionierten gut. Das Einrichten von Builds war ein Kinderspiel und es hat alles getan, was ich wollte, einfach und effizient.

Seitdem haben wir jedoch Open-Source-Tools für die gleiche Art von Dingen übernommen. Wie gesagt, die Installation von 2005 war ein NIGHTMARE und obwohl die Version 2010 von Team Foundation Server sehr einfach installiert ist (ich habe es selbst getestet und dem armen Team gezeigt, das mit der Version 2005 geholfen hat, um ihnen zu zeigen, wie viel besser es ist ist), ich konnte meine Mannschaft nicht überzeugen, ihr eine zweite Chance zu geben. Sie entschieden sich dafür, bei Tools zu bleiben, die nicht so oft aktualisiert werden mussten, und die leichter zu aktualisieren waren, wenn es nötig war.

Wenn es nur ich wäre, würde ich es verwenden. Dies ist eines der Dinge, bei denen Dinge einfach funktionieren und nahtlos zusammenarbeiten. Und die verfügbare Dokumentation (MSDN, Videos, etc.) ist erschöpfend. Ich bezweifle, dass andere Tools so gut dokumentiert sind.

Es ist einfach zu schade, dass die Erfahrung mit der älteren Version so schlecht war, dass niemand hier der neuen Version einen fairen Shake geben wird.

Wie für Alternativen - es ist nicht Open Source, aber Atlassian hat eine schöne Reihe von Tools. Sie funktionieren gut für Java und wir verwenden einige von ihnen in unserem .NET-Shop. Wir verwenden SVN für die Quellcodeverwaltung. Das ist das einzige, was mir in unserer neuen Umgebung besser gefällt als das Team System.

Answer 2

Ich begann vor zwei Monaten bei einem neuen Unternehmen, das ausschließlich TFS 2010 verwendet (für Quellcodeverwaltung und Problem/Aufgabenverfolgung), und ich konnte mich nicht damit vertraut machen. Zuvor habe ich hauptsächlich SVN für die Quellcodeverwaltung und entweder OnTime (von Axosoft) oder Fogbugz (Joel Spolsky) benutzt und beide geliebt.

Ich weiß nicht, ob es die Art ist, wie sie TFS verwenden (Verzweigen ist nichts so gut wie in SVN ... und sie haben Product Backlog Items, Sprint Backlog Items, Bugs, Impediments und Gott weiß was sonst noch zu beachten), aber ich finde es viel zu kompliziert.

Ich denke, dass die Werkzeuge, die ein Entwickler verwendet, den Entwickler unterstützen sollte, nicht in die Quere kommen. Wenn ich aufhören muss darüber nachzudenken, wie man Code abzweigt oder ein Problem zuweist, dann stimmt irgendetwas mit meinen Tools nicht (oder ich muss einfach mehr Zeit damit verbringen, sie zu lernen ... was für mich auch keinen Sinn ergibt).