Scrum betont, dass alle Mitglieder des Teams die technischen Schulden des Produkts kennen müssen. Aber manchmal sind diese Schulden nicht als einfache To-do-Liste greifbar. Sollten wir es als weitere Aufgabe im Product Backlog registrieren, um es in einem anderen Sprint zu überprüfen? Oder sollten wir es in ein Dokument schreiben, das sich auf dieses Produkt bezieht, damit das Team tatsächlich weiß, welche Aufgaben später in der Entwicklung behandelt werden sollten?
Ich sehe keinen guten Weg, diese Schuld in den Köpfen der Entwickler zu behalten; es kann später vergessen werden.
In der Regel erhöhen technische Schulden die Kosten für zukünftige Arbeiten am Produkt. Selbst wenn Sie die Schulden nicht explizit im Auge behalten, werden sie sich in der Regel als Belastung für Metriken wie die Geschwindigkeit des Teams im Laufe der Zeit zeigen.
Technische Schulden wirken sich wahrscheinlich auch auf die Schätzungen Ihres Teams von Product Backlog Items (PBIs) während der Sprint-Planung aus, da Crufty-Code (und verschuldete Produkte im Allgemeinen) intuitiv einen höheren Aufwand erfordern.
Auch wenn Scrum implizit technische Schulden durch Geschwindigkeit aufdeckt und sie auch in PBI-Schätzungen widerspiegelt, ist es oft besser, die Schulden explizit im Product Backlog zu verfolgen. Einige Gründe dafür sind:
Wenn Sie technische Schulden einfach als Arbeit behandeln, die priorisiert werden muss, im Gegensatz zu einer speziellen Art von nicht arbeitsbezogener Arbeit, dann ist das Product Backlog sicherlich der richtige Ort dafür.
Erstellen Sie PBIs für die technische Schuld genauso wie für jede andere Art von Arbeit. Die PBIs sollten auf einer beliebigen Granularitätsebene geschrieben werden, die für die Priorisierungsebene der Arbeit innerhalb des Backlogs angemessen wäre.
Beispielsweise könnten Sie einige wertvolle, aber nicht unbedingt erforderliche Refactorings als Epos für „eines Tages“ aufbewahren. Im Gegensatz dazu sollten wesentliche Patches oder Überarbeitungen als individuelle User Stories geschrieben werden, wenn das Team bereit ist, die Arbeit während der Sprint-Planung oder während der Backlog-Verfeinerung zu zerlegen, wenn die Arbeit wahrscheinlich für einen bevorstehenden Sprint vorgesehen ist.
Die Standard-Scrum-Antwort wäre, das Team nach seiner Meinung zu fragen. Scrum-Teams sollen sich selbst organisieren, was bedeutet, dass sie wählen können, wie sie ihre Arbeit am besten erledigen. Das Team sollte in der Lage sein, das Management von technischen Schulden als Problem zu identifizieren und dann Ideen zu entwickeln.
In der realen Welt ist das Team jedoch manchmal nicht erfahren oder versiert genug, um diese Probleme zu erkennen, bevor sie zu spät sind. Ein gutes Coaching durch jemanden, der diese Probleme schon einmal erlebt hat, kann dabei helfen, das Team anzuleiten, die richtigen Fragen zu stellen und über bestimmte Probleme nachzudenken, bevor sie zu Problemen werden.
Ich hätte nichts dagegen, wenn das Team technische Schuldenarbeiten im Product Backlog nachverfolgen möchte. Ich denke, dass dies wahrscheinlich das Richtige ist - es kann mit dem Rest des Product Backlogs überprüft werden. Wenn es Abhängigkeiten zwischen technischen Schulden und Funktionen gibt (z. B. würde die Auflösung der technischen Schuld dazu führen, dass eine Funktion mit höherer Qualität in kürzerer Zeit geliefert wird), können diese vom Product Owner und dem Entwicklungsteam identifiziert und verwaltet werden.
Ja, technische Schulden landen am Ende des Tages auf die eine oder andere Weise in Ihrem Aufgabenverfolgungssystem.
Ein naheliegender Weg:
Außerdem wird es den Teammitgliedern im Laufe der Zeit schon in der Planungsphase ziemlich offensichtlich, wo die tatsächlichen Schulden liegen. Sicher, es gibt einige heimtückische Schulden, die sehr langsam zunehmen, aber einige Dinge sind ziemlich offensichtlich. Auch diese sollten im Rückstand landen.
Schließlich können Sie ein proaktives Schuldenmanagement betreiben, indem Sie beispielsweise regelmäßig sicherstellen, dass alle Komponenten von Drittanbietern regelmäßig aktualisiert werden. dass veraltete Komponenten (die seit X Monaten/Jahren keine neuen Versionen haben) auslaufen und so weiter. All dies sind wiederum einfach weitere Rückstandseinträge, die als „technische Schulden“ gekennzeichnet sind.
Sollten wir es als weitere Aufgabe im Product Backlog registrieren, um es in einem anderen Sprint zu überprüfen? Oder sollten wir es in ein Dokument schreiben, das sich auf dieses Produkt bezieht, damit das Team tatsächlich weiß, welche Aufgaben später in der Entwicklung behandelt werden sollten?
Ich denke, Sie sollten eigentlich einen gut strukturierten Plan haben, wie Sie technische Schulden angehen können.
Finden Sie Metriken, um die Bedeutung dieser Aufgaben für den Gesamtzustand des Projekts zu erfassen. Einige Beispiele sind:
Thomas Owens
Todd A. Jacobs