Sollten Sie in Scrum den Rückstand in einen funktionalen Rückstand und einen technischen Rückstand aufteilen oder nicht?

In unseren Scrum-Teams verwenden wir einen Rückstand, der hauptsächlich funktionale Themen, manchmal aber auch technische Themen enthält. Der Vorteil von 1 Rückstand ist, dass es einfach wird, die Themen für den nächsten Sprint auszuwählen, aber ich habe einige Fragen:

• Zunächst erscheint es mir logischer, über einen separaten technischen Rückstand zu verfügen, in dem Entwickler selbst rein technische Elemente hinzufügen können, z. B .: Wir könnten die Leistung bei dieser Methode verbessern. In dieser Klasse fehlen einige technische Dokumentationen Entwickler müssen immer über den Product Owner gehen, um ihre Themen zum Backlog hinzuzufügen, was für den Product Owner als zusätzliche, unnötige Arbeit erscheint.
• Zweitens, wenn Sie einen Product Owner haben, der sich nur auf die rein funktionalen Elemente konzentriert, die rein technischen Elemente (wie fehlende technische Dokumentation, Code, der erodiert und überarbeitet werden sollte), Klassen, die beim Debuggen immer Probleme bereiten, weil sie keine haben ein stabiles Fundament und sollte überarbeitet werden, ...) landen immer am Ende der Liste, weil "sie den Kunden nicht direkt bedienen". Durch einen separaten technischen Rückstand und Zeit, die in jedem Sprint für diese rein technischen Elemente reserviert wird, können wir die Anwendungen funktional verbessern, sie aber auch im Inneren gesund halten.

Was ist der beste Ansatz? Ein Rückstand oder zwei?

Ich bin kein Experte, aber ich würde sagen, Sie können nur einen Rückstand pro Team haben. Das Team muss entscheiden, welche Probleme dringend sind und welche verschoben werden können. Wenn Sie die Probleme in verschiedene Arten von Stacks aufteilen, stoßen Sie auf die Kernidee, die im Mittelpunkt des Gedränge steht: Es gibt einen Pool von Problemen und jeder Sprint, an dem das Team am dringendsten arbeitet. Wenn Sie die Teams (unter-) teilen, können Sie möglicherweise die für sie relevanten Aufgabentypen aufteilen, aber Sie würden im Grunde Teams aufstellen, die parallel arbeiten. Bei der Planung des nächsten Sprints ist Dringlichkeit / Notwendigkeit die Nummer eins. Sie können die Aufgaben kategorisieren, dies sollte jedoch Ihren Entscheidungsprozess nicht beeinträchtigen.

Ich möchte meine Stimme denen hinzufügen, die einen Rückstand pro Produkt empfehlen. Das Erstellen eines weiteren Rückstands ist eine rationale Antwort, umgeht jedoch nur das Kernproblem: Warum werden technische Artikel vom Product Owner nicht vor Feature-Artikeln priorisiert? Sie sollten sich darauf konzentrieren, dies zu lösen, anstatt es zu umgehen. Mit der 5-Whys- Technik können Sie beispielsweise versuchen, den Dingen auf den Grund zu gehen.

Es kann viele Gründe geben, warum die PO technische Probleme nicht priorisiert. Zum Beispiel erklärt das Tech-Team möglicherweise nicht die langfristigen Kosten (in US-Dollar), die anfallen, wenn die technischen Schulden nicht beglichen werden. Vielleicht ist es etwas ganz anderes. Es besteht eine gute Chance, dass es sich um ein Kommunikationsproblem handelt, und die langfristige Lösung besteht darin, daran zu arbeiten und es zu beheben - das Hindernis zu beseitigen.

Darüber hinaus muss ich noch eine weitere Frage an Sie richten: Warum ist die technische Verschuldung überhaupt entstanden? Idealerweise sollten Arbeiten wie Refactoring usw. in den Funktionsgeschichten stattfinden und im Sprint abgeschlossen werden. Sie sollten keine eigenständigen Geschichten sein, da Sie sonst keinen potenziell versandfähigen Code haben.

Was Sie meinen, wird gemeinhin als "technische Verschuldung" bezeichnet. Es kann manchmal schwierig sein zu sehen, wie sich die technische Verschuldung in den Scrum-Prozess einfügt, so wie es bei Defekten der Fall ist.

Was Sie vorschlagen, ähnelt dem Vorschlag, dass es auch einen separaten „Fehlerrückstand“ gibt, der den Rückstand in 3 aufteilt.

Persönlich würde ich nicht befürworten, den Produktbestand überhaupt aufzuteilen. Die Idee des Product Backlogs ist es, herausragende Arbeiten abzubilden . Aus dieser Sicht besteht der einzige Unterschied zwischen einem Merkmal und einem technischen Schuldposten darin, dass die Anforderung vom Entwicklungsteam und nicht vom Kunden stammt. Es ist immer noch ein Arbeitselement und muss weiterhin verwaltet werden, einschließlich der Priorisierung gegenüber anderen Arbeitselementen. Dies gilt insbesondere dann, wenn für den technischen Schuldposten Tests erforderlich sind. In diesem Fall sollte derselbe QS-Prozess wie für eine normale Funktion durchgeführt werden.

Ich stimme Onno darin zu, dass es nur einen einzigen Rückstand pro Projekt geben sollte. Ansonsten nimmt das Team einige Entscheidungen, die zu Recht dem Produktbesitzer gehören, selbst in die Hand.

Selbst "rein technische" Artikel müssen für Benutzer (und damit für den Produktbesitzer) einen praktischen Wert haben, um für das Sprint-Backlog in Frage zu kommen. Es ist Ihre Aufgabe, dem Produktbesitzer den Nutzen dieser zu erklären und ihn / sie von dem Mehrwert zu überzeugen, der die Kosten rechtfertigt. Und dieser Prozess zwingt Sie dazu, über diese Themen nachzudenken und die technischen Änderungen auszuwählen, die mit dem geringsten Aufwand den größten Nutzen für das Projekt bringen.

Ich stimme allen obigen Antworten zu. In der Hitze der kommerziellen Realität wird die PO weiterhin funktionale Geschichten gegenüber technischen Geschichten priorisieren. Oft zur Frustration des Teams. Das Team sollte auf technische Storys ohne Nutzwert verzichten (wen interessiert eine Optimierung, wenn es nicht um Geschwindigkeit geht?) Und lernen, bestimmte andere technische Aufgaben zu sehen, die in den funktionalen Storys enthalten sind. Die "Definition von erledigt" spielt ebenfalls eine große Rolle. Die verbleibenden funktionalen Storys gehen in den Rückstand ein, damit die Bestellung Prioritäten setzt.

ZB Technische Dokumentation: Die Verfügbarkeit von technischer Dokumentation (sofern zutreffend) ist ein typischer Bestandteil des DOD. Daher ist die Aktualisierung bei jeder Funktionsstory STILLSCHWEIGEND.

ZB Refactoring-Code: sollte durchgeführt werden, wenn dies der Produktentwicklung zugute kommt. Nicht früher (das Team sollte nicht davon ausgehen, in welche Richtung sich das Produkt entwickeln wird) und nicht später, wenn es bereits in technische Schulden umgewandelt wurde. Die Überprüfung des Entwurfs könnte auch Teil des DoD sein.

Ich bin mit MelR einverstanden. Wenn es irgendetwas gibt, das "technisch" ist, müssen wir uns ansehen, warum wir es tun - oder was ist die kurz- und langfristige Ursache und Wirkung (für den Benutzer)?

Ich habe viele Rückstände gesehen, in denen die sogenannten "technischen Aufgaben" leicht auf eine Art von Geschäftswert geschrieben werden können.

Technische Aufgaben sind oft auch das Ergebnis großer, aufgeschlüsselter Geschichten, da dies die einfachere Möglichkeit ist, die Dinge aufzuschlüsseln. Dies kann jedoch zu langsameren Wiederholungen des tatsächlichen Mehrwerts (oder zu Rückkopplungsmöglichkeiten) oder, noch schlimmer, zum Scheitern von Sprints führen.

In Bezug auf "Code, der erodiert und überarbeitet werden sollte", wie Patrick erwähnt, sind wir der Meinung, dass wir uns fragen müssen: Welchen Bereich der Systemfunktionalität betrifft dieser Code? und was ist die langfristige Auswirkung auf den Benutzer, wenn wir es jetzt nicht umgestalten?

Dann gibt es das Thema "Dinge etwas besser zu belassen als wir es gefunden haben", um die langfristigen technischen Schulden zu reduzieren, und kann dies als Teil der kleinen Geschichten in jedem Sprint getan werden, ohne zu viel Einfluss auf das gesamte Projekt zu haben?

Letztendlich sehe ich keine Notwendigkeit für zwei Rückstände. Dies eröffnet die Möglichkeit, richtig priorisierte Anforderungen zu verlangsamen. Es besteht jedoch ein Bedarf an einem Produktbesitzer, der in den Belangen der technischen Auswirkungen geschult ist und in der Lage ist, den tatsächlichen Wert zu ermitteln Vertikale Unterteilung von Storys - Adobe bietet eine gute Erklärung für das vertikale Unterteilen .

Nein, Sie sollten niemals technische Geschichten schreiben. Dies ist ein häufiger Fehler. Ihre Geschichten müssen die geschäftlichen Anforderungen widerspiegeln. Technische Sachen sind nie wirklich von Geschäftsanforderungen abhängig. Dies ist die Aufgabe des Scrum Masters und des Teams, alle technischen Aufgaben zu bewerten, die zur Erreichung des Ziels oder der Story erforderlich sind.

Wenn es in Ihrer Geschichte beispielsweise um die Erstellung eines Anmeldebildschirms geht, müssen Sie die Erstellung der Datenbank berücksichtigen, auch wenn diese noch nicht erstellt wurde.

Ich sehe kein Problem darin, mit der Bestellung Aufgaben zu erstellen, bei denen das IT-Team der Benutzer ist. Wenn die Aufgabe von der Bestellung verstanden und nach dem geschäftlichen Wert bewertet werden kann, haben Sie ja die Möglichkeit, technische Geschichten zu erstellen. Sie benutzen einfach das System.