Wie misst man die Höhe der bestehenden technischen Schulden, um den Fortschritt zu verfolgen? [abgeschlossen]

Es ist schwierig, diese Frage direkt zu beantworten, aber ich kann mir ein paar Möglichkeiten vorstellen, wie ich darauf kommen kann - ich möchte wahrscheinlich, dass mehrere Metriken in Kombination verwendet werden, um eine Art "Score" zu erstellen.

1. Alterungsanalyse von Klassen / Methoden (wann wurde diese Methode zuletzt geändert?)
2. Fehler pro Funktionsbereich oder wenn Sie nach mehr technischen Analysefehlern pro Funktionspunkt / Klasse / Methode suchen - ich möchte hier warnen, dass einige Leute versucht sein könnten, dies als Entwicklerleistungsmetrik zu verwenden, also seien Sie vorsichtig
3. Zyklomatische Komplexitäts- oder Funktionspunktanalyse
4. Codeabdeckung / Unit-Test-Dichte
5. Qualitative Codeabdeckung / "WTFness" -Maß - eine Mischung aus Ingenieuren, die mit dem Code vertraut sind, und solchen, die es nicht sind, wird großartige Einblicke in Dinge wie Lesbarkeit, logischen Fluss usw. geben - eher subjektiv, sicher, aber technische Schulden auch :)

Ich hoffe, das hilft!

Beginnen Sie damit, keine weiteren technischen Schulden anzuhäufen

1. Schreiben Sie jeden Tag sauberen Code : Egal welchen Code Sie schreiben oder anfassen, Sie sollten ein Refactoring einplanen und ihn in gutem Zustand belassen. Dieses Refactoring sollte in Ihre Story-Point-Schätzung eingebaut werden. Niemand fragt Sie nach einem Kostenvoranschlag, um schlampigen Code zu schreiben. Wie Jeff Sutherland sagt: „Technical Debt muss gestoppt werden. Die Disziplin, jeden Tag sauberen Code zu haben, ist ebenso wichtig wie das Abschließen aller Tests innerhalb des Sprints.“

2. Planen Sie, alle Tests innerhalb des Sprints abzuschließen : Wie sonst können Sie sagen, dass Sie am Ende jedes Sprints ein auslieferbares Inkrement erstellt haben? Ich stimme Mike Cohns Charakterisierung des übermäßigen Vertrauens auf manuelles Testen als technische Schuld zu. In einem meiner früheren Projekte haben wir uns eine Zeit lang ausschließlich auf manuelles Testen verlassen. Wir brauchten jeden zweiten Sprint eine „Härtungswoche“, um eine stabile Version herauszubringen. Einige Mängel und Leistungsprobleme haben wir schon damals erst in der Produktion entdeckt.

3. Vorsätzliche technische Schulden : Wenn Sie technische Schulden eingehen, tun Sie dies absichtlich. Erstelle gleich ein Ticket für die technische Schuld und lege es ins Backlog. Wenn Menschen ihre Kreditkartenschulden ausschöpfen, um ein Unternehmen zu gründen, tun sie dies in der Erwartung, dass die Erträge aus dem Geschäft dazu beitragen, die exorbitanten Zinskosten und den Kapitalbetrag zu tilgen.

4. Unbeabsichtigte technische Schulden – Architektur und Design : Wann immer Ihr Entwicklerteam über schlechte Architektur oder schlechtes Design schimpft, fragen Sie es, was es tun wird, um es zu verbessern – und erstellen Sie ein Ticket.

5. Unbeabsichtigte technische Schulden - Codequalität : @Jon Odo hat einiges davon in seiner Antwort behandelt. Siehe auch diese ausgezeichnete Antwort von @Thomas Owens auf Programmers SE. Verwenden Sie diese Techniken, um Problembereiche zu identifizieren und Tickets zu schreiben.

6. Investieren Sie ein wenig Zeit : Wenn Sie etwas Zeit zum Verschnaufen haben (nach einer großen Veröffentlichung?), recherchieren Sie zeitgesteuerte Geschichten der vielversprechendsten Tickets, um den Aufwand und den erwarteten Nutzen einzuschätzen. Wenn die Vorteile stark sind und sich der Aufwand lohnt, können Sie sich beim Product Owner und den Stakeholdern dafür einsetzen, dass es Priorität erhält.