2009-12-21 8 views
9

Ich möchte einen Weg finden, die technischen Schulden, die wir in TFS anfallen, aufzuzeichnen.Wo zeichnen Sie Technische Schulden in TFS auf?

Ich muss jedes Element außerhalb einer bestimmten Iteration aufzeichnen, um sicherzustellen, dass es jederzeit sichtbar und leicht zu melden ist. Ich habe überlegt, einen separaten Bereich für technische Schulden zu schaffen, bin mir aber nicht sicher, wie gut dieses Feld tatsächlich ist.

Was sind einige gängige Ansätze, die ich berücksichtigen könnte? Banne ich sogar den richtigen Baum an, indem ich versuche, den richtigen Platz dafür zu finden?

+0

Ich weiß nicht, wie ich das machen soll, aber es ist eine gute Frage. Es ist absolut sinnvoll, dass Sie Ihre technischen Schulden genauso verfolgen, wie Sie die Anforderungen verfolgen. Das Problem, das ich sehe, ist die Schuld zu identifizieren. Wenn Sie es genau identifizieren können, können Sie ein Arbeitselement erstellen, um es zurückzuzahlen. –

+0

TFS == Team Foundation Server? Es hilft, wenn Sie Akronyme definieren. –

+0

Entschuldigung - ja TFS === Team Foundation Server. Ich habe versucht, es zwischen Tags zu markieren, aber sie werden nicht in SO unterstützt. –

Antwort

4

Ich habe keine Notwendigkeit gefunden, es separat zu verfolgen; Ich gebe es nur als zusätzliche Aufgaben ein. Auf diese Weise können sie leicht verfolgt und gemeldet werden.

+0

Aber müssen Sie eine Aufgabe nicht immer einer bestimmten Iteration zuordnen? Finden Sie, dass dieser Ansatz sauber und einfach zu verwalten ist? Was tun Sie für Aufgaben, die ein paar Iterationen umfassen könnten? –

+2

Ich schaffe es wie jede andere Aufgabe - also ja, ich finde es sauber und einfach zu verwalten. Ich habe es nicht als nützlich empfunden, die "technische Schuld" als eigenständigen Bereich auszuheben; Am Ende kommt es wirklich auf mehr Arbeit in bestehenden Bereichen an. Manchmal geht die Aufgabe in der aktuellen Iteration; manchmal in einem anderen. Wie bei allen Aufgaben können sie manchmal von der aktuellen Iteration zur nächsten verschoben werden, wenn die Iteration zu Ende geht. Für Aufgaben, die mehr als eine Iteration umfassen können, teile ich sie normalerweise in mehrere Aufgaben auf (sogar etwas so einfaches wie "Phase 1" und "Phase 2" funktioniert im Allgemeinen gut). – RickNZ

+0

Ich mag Ihren Punkt über jede technische Schuld, die letztlich ihre "Ursache" in einem vorhandenen Feature oder Bereich des Projekts hat. Guter Punkt. –

4

Ich finde, dass es mehrere Arten von technischen Schulden gibt: Schulden, die Sie kennen und verfolgen können, bis behoben, und Schulden, die als Ergebnis eines unerwarteten Bugs sichtbar wird. Ich möchte die ausstehenden bekannten technischen Schulden in einer separaten Iteration "Maintenance Backlog" im Bereich "Technische Schulden" nachverfolgen. Ich kann dann relevante Fehler von JEDER Iteration in den Bereich der technischen Schulden verlinken, während ich immer noch Probleme behalte, die ich noch nicht lösen kann. Der Schlüssel ist, dass Sie immer noch Bugs benötigen, die mit der Iteration verbunden sind, die in den Ursprungsanforderungen für Reporting-Zwecke gefunden und behoben wird.

+0

Danke. Auf diese Art von Ansatz war ich neugierig. Aber finden Sie es gut funktioniert? Gibt es andere Leute/Unternehmen, die auf diese Weise arbeiten? Sind Ihre Bereiche "Technical Debt" und "Maintenance Backlog" auf der obersten Ebene ihrer jeweiligen Hierarchien Iteration? –

+0

Es funktioniert gut, da das Team einen proaktiven Ansatz verfolgen kann und dabei die technischen Schulden dokumentiert, auch wenn sie es in der aktuellen Iteration nicht beheben können. Ich kann auch leicht darüber berichten, wie viel unvorhergesehene Arbeit pro Zyklus auf technische Schulden usw. zurückzuführen ist. Es gibt ein anderes Unternehmen in unserem Gebiet (200 + Entwickler), das einen ähnlichen Ansatz verfolgt. Ich kann nicht für die breitere Gemeinschaft sprechen, aber es scheint TFS so zu nutzen, wie es beabsichtigt war. – PortageMonkey

Verwandte Themen