Agile - Was machen wir falsch?

Ich bin Entwickler in einem agilen Team, und wir versuchen, Scrum zu verwenden.

Also werde ich hier ein hypothetisches Problem anführen, um die Situation zu veranschaulichen.

Wir haben eine sehr alte App, die etwas chaotischen und schlecht wartbaren JQuery-Code verwendet. Wir haben auch Teile der App, die React verwenden, und diese Teile sind viel einfacher zu aktualisieren / zu warten. Darüber hinaus besteht das Unternehmensziel darin, eine Client-Single-Page-App für React zu erstellen, sodass Sie mit JQuery noch weiter davon entfernt sind.

Bei der Planung entscheiden wir uns immer für eine einfache Lösung in Bezug auf die Entwicklungszeit. Wenn wir beispielsweise einen neuen Dialog oder etwas anderes erstellen, verwenden wir die alte JQuery, weil sie schneller ist, und wir sagen, dass wir zurückkehren später aufzuräumen und in React umzuwandeln, aber das kommt selten vor.

Wir erhalten die Anforderungen an das, was wir zu tun haben, aus User Stories (die IMO gut gemacht sind, schlank sind, aber erklären, was wir tun und warum wir es tun).

Manchmal sind die Anforderungen an neue Funktionen sehr gering. Wenn beispielsweise die Anforderung "Dialogfeld erstellen, in dem Tonnen von Inhalten geladen werden" lautet, die Implementierung einer Ladefunktion jedoch nicht vorgeschrieben ist, wird diese in den meisten Fällen nicht implementiert Obwohl wir alle wissen, dass es für die Kunden besser wäre, mit dem Grund, dass dies unser Sprintziel gefährden könnte (auch wenn ich persönlich glaube, dass dies nicht der Fall ist).

Das Ergebnis ist, dass unsere Codebasis ein großes Durcheinander mit sehr schlechter Wartbarkeit ist und neue Funktionen manchmal sehr klein sind und einen vollständigen Sprint erfordern (etwas, das an einem einzigen Tag in einer guten Codebasis erreicht werden könnte), was hauptsächlich auf diese Entwicklung zurückzuführen ist Strategie, geh schnell, mach das Minimale.

Was machen wir in diesem Fall falsch? Sollten wir die Lösungen vollständiger angehen, damit wir nicht immer schlechten Code schreiben und Code umschreiben, den wir erst letzte Woche geschrieben haben? Oder sollten wir so weitermachen, nur um sicherzustellen, dass der gesamte Code neu geschrieben wird? Was wäre ein guter agiler Ansatz für dieses Problem?

Das hat nichts mit Agile oder Scrum zu tun.

Das Problem mit "Klebeband jetzt und wir werden es später beheben" ist, dass es später nie mehr kommt und Sie in der Zwischenzeit eine Menge technischer Schulden akkumulieren .

Der erste Schritt zur Wiederherstellung besteht darin, das Problem zu erkennen und es nicht weiter zu verschlimmern.

Bei jeder neuen User Story sollte das Team überlegen, wie man das richtig codiert und nicht, wie man es am schnellsten hackt. und planen Sie die Sprints entsprechend.

Um das bestehende Problem zu beheben, lesen Sie die hervorragenden Antworten auf die Frage, ob ich 200.000 Zeilen Spaghetti-Code geerbt habe. Was nun?

Was Sie dort haben, nennt Martin Fowler "Flacid Scrum".

Wenn Sie alle 12 Prinzipien des Agilen Manifests richtig lesen , werden Sie feststellen, dass Sie bei den meisten versagen.

Stellen Sie häufig funktionierende Software bereit, von einigen Wochen bis zu einigen Monaten, mit dem Vorzug der kürzeren Zeitspanne.

Können Sie sagen, dass Sie wirklich funktionierende Software liefern? Oder nur Software, die kaum funktioniert?

Agile Prozesse fördern eine nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.

Können Sie sagen, dass Ihr Prozess nachhaltig ist? Treffen Sie Entscheidungen mit Blick auf Nachhaltigkeit? Oder suchen Sie Lösungen aus, die das aktuelle Problem lösen, ohne die langfristigen Auswirkungen zu berücksichtigen?

Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design erhöht die Beweglichkeit.

Das wirklich wichtige Prinzip. Ich glaube, das sollte in GROSSEN ROTEN BUCHSTABEN auf der Seite stehen. Hier scheitern Sie am meisten.

In regelmäßigen Abständen überlegt sich das Team, wie es effektiver werden kann, stimmt es dann ab und passt sein Verhalten entsprechend an.

Und am offensichtlichsten. Wenn Sie feststellen, dass Ihr Verhalten nicht zu den gewünschten Ergebnissen führt, sollten Sie es ändern. Wenn Ihr Team keine Probleme erkennt, kann es diese nicht beheben.

Aus deinem Kommentar

Wie kann man das in Agilität verhindern?

Erstens, indem Sie lernen, was agil ist. Scrum ist nicht agil. Einige würden sagen, Scrum ist das Schlimmste an agilen Frameworks, da es zu einfach ist, Ihre genaue Situation zu erreichen. Sie sollten andere agile Frameworks kennenlernen. Das, was ich empfehlen würde, ist Extreme Programming. Welches löst eindeutig Ihre Probleme. Die Lösungen sind nicht einfach (Konzentration auf technische Exzellenz durch robuste automatisierte Tests, Paarprogrammierung und kontinuierliche Lieferung), sondern hochwirksam. Wie im State of DevOps-Bericht angegeben .

Was Sie beschreiben, ist - zumindest nach meiner Erfahrung - ein weit verbreitetes Emergenzmuster von Teams, die versuchen, "agil zu sein". Es ist offen für Diskussionen, wenn dies tatsächlich Teil von Agile selbst ist oder eine häufige Fehlimplementierung desselben ist, gegen das agile Manifest / die agilen Prinzipien oder eine inhärente Folge davon verstößt und so weiter. Nur aus empirischer Sicht und basierend auf meiner eigenen kleinen Auswahl an Erfahrungen (und den Personen, mit denen ich spreche) scheint ein agiles Team eine überdurchschnittliche Chance zu haben, auf dieses Muster zu stoßen. Lassen wir es dabei und konzentrieren uns auf Ihr konkretes Beispiel.

Bei Ihrer Beschreibung gibt es zwei verschiedene Aspekte :

• Fehlendes gemeinsames Verständnis / Vision und daher nicht effizient
• Wie man Erfolg / Fortschritt und Gesamtkosten misst

Den falschen Weg gehen oder im Kreis laufen

Meiner Erfahrung nach ist der Hauptgrund dafür, dass Teams bei dem Versuch, Code schnell zu erstellen, Anwendungsfälle oder Anforderungen, die sie bereits kennen oder die sie leicht herausfinden können, aktiv beiseite schieben . Stellen Sie sich das so vor: Vor 10 bis 20 Jahren versuchten die Leute, riesige Spezifikationen zu schreiben und über alles im Voraus nachzudenken, und scheiterten oft. Sie haben entweder zu lange gebraucht oder etwas übersehen. Eine der Erkenntnisse der Vergangenheit ist, dass es in der Softwareentwicklung Dinge gibt, die man nicht wissen kann und die sich stark ändern. Daher die Idee, schnell zu iterieren und eine vernünftige Ausgabe schnell zu erstellen. Welches ist ein sehr gutes Prinzip. Aber heute sind wir beim anderen Extrem: "Das interessiert mich nicht, weil es Teil des nächsten Sprints ist" oder "Ich reiche diesen Fehler nicht ein, ich kümmere mich darum, wenn er wieder auftaucht".

1. Sammeln Sie alle Anwendungsfälle , Anforderungen, Abhängigkeiten und Einschränkungen auf hoher Ebene , die Sie finden können. Stellen Sie es in ein Wiki, damit alle Beteiligten und Entwickler sie sehen können. Fügen Sie sie hinzu, wenn etwas Neues auftaucht. Sprechen Sie mit Ihren Aktionären und Nutzern. Verwenden Sie diese Liste als Checkliste während der Entwicklung , um zu verhindern, dass Dinge implementiert werden, die nicht zum Endprodukt beitragen oder Workaround / Hacks sind, die ein Problem lösen, aber drei neue Probleme verursachen.
2. Formulieren Sie ein übergeordnetes Konzept . Ich spreche nicht vom Entwerfen von Interfaces oder Klassen, sondern skizziere grob die Problemdomäne. Was sind die Hauptelemente, Mechanismen und Wechselwirkungen in der endgültigen Lösung? In Ihrem Fall sollte dies offensichtlich sein, wenn Sie die jquery-Workaround-Hilfe als Zwischenschritt verwenden und nur zusätzlichen Arbeitsaufwand verursachen.
3. Bestätigen Sie Ihr Konzept anhand der Liste, die Sie gesammelt haben. Gibt es offensichtliche Probleme? Macht das Sinn? Gibt es effizientere Möglichkeiten, um den gleichen Nutzwert zu erzielen, ohne langjährige technische Schulden zu verursachen?

Übertreib es nicht. Sie brauchen nur etwas, damit jeder im Team (auch Nicht-Entwickler) versteht, wie der beste Weg zu Ihrem MVP aussieht. Jeder sollte zustimmen, dass es keine offensichtlichen Versehen gibt und es tatsächlich funktionieren könnte. Dies hilft im Allgemeinen zu verhindern, dass Sie Sackgassen schließen oder dass Sie dasselbe mehrmals wiederholen müssen. Agile kann Ihnen helfen, besser mit dem Unerwarteten umzugehen. Es ist kein Argument, das Bekannte zu ignorieren.

Seien Sie sich des Kostensenkungsfehlers bewusst : Wenn Sie mit einer Architektur oder einem Datenbanktyp beginnen, zögern die meisten Leute, diesen während des Projekts zu ändern. Es ist also eine gute Idee, etwas Zeit in eine "fundierte Best-Rate" zu investieren, bevor Sie mit der Implementierung beginnen. Entwickler tendieren dazu, schnell Code zu schreiben. Wenn Sie jedoch häufig ein paar Verspottungen, Live-Prototypen, Screenshots, Drahtmodelle usw. haben, können Sie die Iteration sogar noch schneller als beim Schreiben von Code durchführen. Beachten Sie jedoch, dass jede geschriebene Codezeile oder sogar Unit-Tests eine erneute Änderung Ihres Gesamtkonzepts erschweren.

Erfolg messen

Ein völlig separater Aspekt ist, wie Sie den Fortschritt messen. Nehmen wir an, das Ziel Ihres Projekts ist es, einen 1 m hohen Turm aus herumliegenden Dingen zu bauen. Der Bau eines Kartenhauses kann eine durchaus gültige Lösung sein, wenn beispielsweise die Markteinführungszeit wichtiger ist als die Stabilität. Wenn es Ihr Ziel ist, etwas zu bauen, das lange hält, wäre Lego besser gewesen. Der Punkt ist: Was als Hack betrachtet wird und welche elegante Lösung davon abhängt, wie der Erfolg des Projekts gemessen wird .

Ihr Beispiel für das "Laden" ist ziemlich gut. Ich hatte solche Dinge in der Vergangenheit, in denen sich alle (einschließlich Verkauf, Bestellung, Benutzer) einig waren, dass es ärgerlich ist. Dies hatte jedoch keine Auswirkungen auf den Erfolg des Produkts und verursachte keine langfristigen Schulden. Also ließen wir es fallen, weil es wertvollere Dinge gab, die mit den Entwicklungsressourcen zu tun hatten.

Mein Rat hier ist:

1. Behalten Sie alles, auch kleine Fehler, als Tickets in Ihrem Ticketsystem . Treffen Sie eine aktive Entscheidung, was zum Projektumfang gehört und was nicht. Erstellen Sie Meilensteine ​​oder filtern Sie Ihren Rückstand auf andere Weise, damit Sie immer eine "vollständige" Liste aller noch zu erledigenden Aufgaben haben.
2. Habe eine strikte Reihenfolge der Wichtigkeit und einen klaren Punkt, an dem das Projekt als Erfolg gewertet werden könnte. Welches Maß an Stabilität / Codequalität / Dokumentation benötigt das Endprodukt tatsächlich? Versuchen Sie, jeden Arbeitstag so gut wie möglich zu verbringen, indem Sie von oben auswählen. Wenn Sie an einem Ticket arbeiten, versuchen Sie, es vollständig zu lösen, ohne neue Tickets einzuführen (es sei denn, es ist sinnvoll, Dinge aufgrund einer niedrigeren Priorität zu verschieben). Jedes Commit sollte Sie vorwärts zu Ihrem Endziel bringen, nicht seitwärts oder rückwärts. Aber um es noch einmal zu betonen: Manchmal kann ein Hack, der später zusätzliche Arbeit hervorbringt, immer noch ein Nettopositiv für das Projekt sein!
3. Verwenden Sie Ihre Bestellung / Benutzer, um den Benutzerwert herauszufinden, aber lassen Sie auch Ihre Entwickler die technischen Kosten herausfinden . Nicht-Entwickler können in der Regel nicht beurteilen, wie hoch die tatsächlichen langfristigen Kosten (nicht nur die Implementierungskosten!) Sind. Helfen Sie ihnen also. Seien Sie sich des Problems des kochenden Frosches bewusst: Viele kleine, irrelevante Probleme können mit der Zeit ein Team zum Halten bringen. Versuchen Sie zu quantifizieren, wie effizient Ihr Team arbeiten kann.
4. Behalten Sie das Gesamtziel / die Gesamtkosten im Auge. Anstatt von Sprint zu Sprint zu überlegen, sollten Sie lieber die Einstellung "Können wir als Team alles tun, was bis zum Ende des Projekts benötigt wird" beibehalten . Sprints sind nur ein Weg, um Dinge aufzuschlüsseln und Check-Points zu haben.
5. Anstatt frühzeitig etwas zu zeigen, planen Sie Ihren Kurs auf dem schnellsten Weg zu einem minimalen Produkt , das dem Benutzer zur Verfügung gestellt werden kann. Dennoch sollte Ihre Gesamtstrategie zwischenzeitlich überprüfbare Ergebnisse ermöglichen.

Wenn also jemand etwas unternimmt, das nicht zu Ihrem endgültigen Implementierungsziel passt, sollten Sie die Geschichte im Idealfall nicht berücksichtigen. Wenn es nützlich ist, die Story zu schließen (z. B. um Feedback von Kunden zu erhalten), öffnen Sie sofort eine neue Story / einen neuen Bug, um die Mängel zu beheben. Machen Sie transparent, dass das Einnehmen von Verknüpfungen die Kosten nicht reduziert, sondern nur verbirgt oder verzögert!

Der Trick dabei ist, sich mit den Gesamtkosten des Projekts zu streiten: Wenn beispielsweise eine PO darauf drängt, Verknüpfungen zu verwenden, um einen Termin festzulegen, quantifizieren Sie den Arbeitsaufwand, der anschließend erforderlich ist, um das abgeschlossene Projekt in Betracht zu ziehen!

Achten Sie auch auf eine kriterienbasierte Optimierung : Wenn Ihr Team an der Anzahl der Storys gemessen wird, die bei einem Sprint-Review angezeigt werden können, ist es am besten, jede Story in zehn winzige Teile zu zerlegen. Wenn es an der Anzahl der geschriebenen Komponententests gemessen wird, werden in der Regel viele unnötige Tests geschrieben. Zählen Sie keine Storys, sondern messen Sie, wie viel der benötigten Benutzerfunktionalität funktioniert, wie hoch die Kosten für die im Rahmen des Projekts zu lösenden technischen Schulden sind usw.

Zusammenfassung

Um es auf den Punkt zu bringen: Schnell und minimal zu fahren, ist ein guter Ansatz. Das Problem liegt in der Interpretation von "schnell" und "minimal". Man sollte immer die langfristigen Kosten berücksichtigen (es sei denn, Sie haben ein Projekt, bei dem dies irrelevant ist). Wenn Sie eine Verknüpfung verwenden, die nur 1 Tag dauert, aber eine technische Verschuldung von 1 Monat nach dem Versanddatum erzeugt, kostet dies Ihr Unternehmen mehr als eine Lösung, die 1 Woche gedauert hat. Sofort mit dem Schreiben von Tests zu beginnen scheint schnell zu sein, aber nicht, wenn Ihr Konzept fehlerhaft ist und sie einen falschen Ansatz zementieren.

Und denken Sie daran, was "langfristig" in Ihrem Fall bedeutet: Ich kenne mehr als eine Firma, die beim Versuch, tollen Code zu schreiben, pleite ging und daher zu spät ausgeliefert wurde. Eine gute Architektur oder ein sauberer Code - aus Unternehmenssicht - sind nur dann wertvoll, wenn die Kosten für die Erreichung geringer sind als die Kosten für das Nichtvorhandensein.

Hoffentlich hilft das!

Aus Scrum-Sicht klingt es so, als ob Sie nicht mit dem Kunden zusammenarbeiten. Sie müssen mit dem Kunden zusammenarbeiten, um zu verstehen, was er braucht und nicht nur, was er will . Benötigen sie eine Reihe von Schnellkorrekturen oder benötigen sie ein stabiles, wartbares System, das ihnen langfristig hilft? Das kann schwer zu bestimmen sein, aber Qualität ist ebenso eine Anforderung wie eine Hintergrundfarbe oder ein Leistungsmaßstab. Der Kunde muss sich darüber im Klaren sein, dass Stabilität und Wartbarkeit nicht frei sind und in das Produkt eingebaut werden müssen.

Wenn sie sagen, dass es das erstere ist, tun Sie nichts Falsches - vorausgesetzt, Sie erklären ihnen in den Sprint-Reviews, dass Sie technische Einschnitte vornehmen, um ihre Ziele zu erreichen.

Wenn sie sagen, dass es das letztere ist, dann machen Sie falsch, dass Sie ihnen nicht geben, was sie wollen.

Einer der Eckpfeiler von Scrum ist Transparenz. Wenn Sie Scrum machen, sollten Sie Sprint-Reviews mit dem Kunden durchführen. Sagen Sie dem Kunden in diesen Berichten, dass Sie Abstriche machen, um Software schneller zu liefern? Wenn nicht, sollten Sie sein. Sie müssen Ihrem Kunden 100% ig klar sein, welche Auswirkungen Ihre Konstruktionsentscheidungen haben, damit er eine fundierte Entscheidung darüber treffen kann, ob Sie Ihre Software mit einem angemessenen Qualitätsniveau liefern.

Ewan hat recht. Der Grund, warum das Management Scrum mag, ist, dass es Funktionen im Stakkato-Stil nachfragt und schnell Ergebnisse erzielt. Bis die daraus resultierende Verwirrung jemand anderes Problem ist.

Lassen Sie mich das jetzt erklären, da ich Ihre Aufmerksamkeit habe. Es ist nicht Scrum als solches. Dies ist die typische Einstellung eines starken Produktmanagers und eines schwachen Entwicklungsteams, die keine vernünftigen und realistischen Schätzungen vornehmen können, weil sie den Druck spüren. Sie kommen also zu optimistischen Schätzungen, geraten tiefer in Schwierigkeiten und kürzen sich, um pünktlich zu liefern.

In Scrum können Sie (als Entwickler) selbst planen. Niemand sagt Ihnen, dass Sie in x Tagen eine Funktion bereitstellen sollen. Wenn dir jemand sagt, dass du in x Tagen liefern sollst, machst du kein Scrum.

Was auch immer das Problem ist, das behoben werden muss, fordern Sie Ihre Zeit. Denken Sie, Sie brauchen Zeit, um zuerst etwas zu überarbeiten? Binden Sie es in Ihre Schätzung ein. Können Sie sich das leisten?

Lassen Sie uns untersuchen, was Sie tun, und für einen Moment Agile beiseite legen.

Wenn wir die Planung durchführen, entscheiden wir uns immer für die einfache Lösung in Bezug auf die Entwicklungszeit. Wenn wir beispielsweise einen neuen Dialog oder etwas anderes erstellen, verwenden wir die alte Abfrage, weil sie schneller ist, und wir sagen, dass wir später darauf zurückkommen werden Aufräumen und umwandeln in reagieren, aber das passiert selten.

Dies wird als "Einnahme von technischen Schulden" bezeichnet. Martin Fowler beschrieb den "Quadranten der technischen Schulden" in einem seiner Blogposts entlang der beiden Achsen: "Rücksichtslos vs. Vorsichtig" und "Vorsätzlich vs. Versehentlich".

Sie entscheiden sich ausdrücklich dafür, die bekannte alte Technologie-Abfrage zu verwenden, die Sie von einem Ihrer ausdrücklichen Ziele (nämlich einer einseitigen App) weiter entfernt. Sie tun dies, um "schnell" zu liefern. Das ist absichtlich.

Was diese Berechnung von "schnell" nicht beinhaltet, ist die Zeit, die Sie benötigen, um die Funktionalität zu implementieren und anschließend zu reagieren. Sie wählen eine Alternative, die nur Nachteile gegenüber der Alternative hat, von der Sie wissen , dass sie die richtige ist (dh Sie nehmen sich die Zeit, um die Funktion zu implementieren), basierend auf der Einschätzung, dass Geschwindigkeit von entscheidender Bedeutung ist. Das ist rücksichtslos.

Martin Fowler summiert diese Art von Schulden unter "Wir haben keine Zeit für Design". Dies ist eine geeignete Wahl in einer Umgebung, in der Sie nicht erwarten, den Code zu verwalten oder sogar länger als ein paar Tage Code zu erwarten. Bei Ihrem Projekt handelt es sich jedoch um ein langfristiges Projekt, das explizit die Wartung Ihrer Kunden umfasst.

Was Sie tun, ist im Grunde genommen falsch . Es ist schlechtes Engineering !

Sie haben technische Schulden aufgenommen und dabei ignoriert, dass diese Schulden zurückgezahlt werden müssen, und Zinsen berechnet. Und Sie haben das so lange gemacht, bis der Zinssatz für Ihre Schulden sich während Ihres Sprints dem verfügbaren Arbeitsvolumen annäherte.

Was Sie tun sollten, ist die Reduzierung der Verschuldung . Sprechen Sie mit Ihrem Chef, sprechen Sie mit Ihrem Kunden. Sie müssen gestern an der Wartbarkeit arbeiten.

Hör einfach auf, Agile zu benutzen ...

Besser gesagt, hören Sie auf, etwas auf eine bestimmte Art und Weise zu tun, nur weil dies (Ihr Verständnis von) Agilität (oder Gedränge usw.) vorschreibt. Der Versuch, eine (falsche) Interpretation eines dieser Begriffe auf ein Projekt im falschen Stadium anzuwenden, kann schnell zur schlimmsten Vorgehensweise werden. Verwenden Sie stattdessen Ihren Grund.

Der Grund, warum Ihr Projekt und fast jedes andere Projekt auf der Welt ein Durcheinander von Code und unterschiedlichen Ansätzen ist, ist das Fehlen eines zentralisierten, allwissenden Architekturentwurfs (da habe ich es gesagt).

Die Gründe dafür sind:

• Der Architekt hat nicht das Fachwissen (Wie Ihre ersten zehn Hobbyprojekte)
• Der Architekt hat keine Zeit
• Der Architekt hat nicht die Macht (Manager sagt nein oder ja, aber nur für einige Teile)
• Das Team vertraut auf eine Voodoo-Methode, die es rettet. (Alles wird sich von selbst bügeln, weil wir Agile verwenden.)

Die einfache Lösung besteht darin, alle diese Zauberwörter fallen zu lassen und die Realität der Situation zu betrachten, die sich wie folgt zusammenfassen lässt:

1. Der Status des Codes beeinträchtigt die Fähigkeit des Teams, pünktlich und fehlerfrei zu liefern.
2. Je mehr Funktionen wir hinzufügen, desto schlimmer wird es.
3. Daher ist es wirklich sinnvoll, Teile anzuhalten, neu zu bewerten und (möglicherweise drastisch) neu zu gestalten.

Sie werden natürlich kommen, um zu fragen, warum es überhaupt zu diesem Zustand gekommen ist, und der Schuldfinger dreht sich um und um. Die Antwort ist, dass dies unvermeidlich ist: Wenn Ihr Design reift, stellen Sie fest, dass Sie es anders hätten machen sollen, aber Sie hätten es nicht vorhersehen können. Darüber hinaus handelt es sich nicht um eine einmalige Projektrealisierung. Sie wird mehrmals durchgeführt, und Sie müssen dies planen.

Trotzdem gibt es viele Dinge, die Manager tun können, um die Dinge zu verschärfen:

1. Todesmarschiere deine Entwickler zu Deadlines.
2. Laut Aussage von Entwicklern darf nur Zeit gegen Tickets protokolliert werden, ohne dass Tickets für "Denken, Konsolidieren und Qualitäts-Refactoring" und eine großzügige Zeitspanne für diese Tickets vorhanden sind.
3. Keine Person lange genug in den Besitz der Architektur bringen, um sie in den Griff zu bekommen
4. Es ist dieser Person nicht gestattet, die Änderungen vorzunehmen, die sie für notwendig hält

Wenn Sie es so betrachten, ist es leicht zu sehen, wie einige Interpretationen von Agile & Scrum Sie auf diesem Weg sogar noch schneller voranbringen werden!

Ein Ansatz ist das Erstellen von Tickets für jedes Teil des Refactorings. Das Problem ist, dass Sie oft nicht erkennen, dass Sie einen großen Refactor benötigen, bis Sie mit der Arbeit an einem kleineren Ticket beginnen, was die Fristen zurückschiebt und das Ticket Genehmigungsschleifen durchläuft, die alles nur verlangsamen.

Ein weiterer Ansatz besteht darin, Sprints so zu planen, dass nur 25-50% der Kapazität Ihres Teams genutzt werden. Entwickler protokollieren dann ihre Zeit auf den realen Tickets (protokollieren die Zeit, die es ohne Refactoring hätte dauern sollen) und die Refactoring-Zeit (ein großes Ticket für die Woche, keine Genehmigungsschleifen, nur Diskussionen zwischen Entwicklern). Wenn es kein Refactoring gibt, können Sie Tickets aus dem Sprint der nächsten Woche ziehen. Sie passen den prozentualen Schieberegler für die kommenden Wochen an, wenn sich der zugrunde liegende Code des Projekts verbessert.

Um zu beantworten, "was machen wir falsch?", Würde ich sagen, dass Sie einer Methodik vertrauen, die dem gesunden Menschenverstand überlegen ist. Sie fordern sogar eine "agile Herangehensweise an dieses Problem" . Ich würde sagen, lass die Worte fallen und denke über das eigentliche Problem nach. Wenn du dann wirklich verschiedene Manifeste heraussuchen willst, um herauszufinden, ob dein gesunder Menschenverstand tatsächlich unter das Deckmantel von "agil" oder "scrum" fällt, dann mach es auf jeden Fall :-)

Du machst nichts falsch. Diese Art von Methodik wurde entwickelt, um Funktionen so schnell wie möglich zu spezifizieren.

Wenn Sie sekundäre Ziele haben, auf die Sie hinarbeiten, ist es am besten, diese als „nicht funktionierende Anforderungen“ oder als „Definition von„ erledigt “auszudrücken.

Sie könnten beispielsweise eine nicht funktionierende Anforderung haben:

"Alle neuen Funktionen müssen in React geschrieben werden"

und

"Alle asynchronen Aufrufe müssen einen Ladespinner und eine Fehlerbehandlung implementieren."

Sie müssen lediglich Ihren Product Owner (oder ein gleichwertiges Unternehmen) dazu bringen, zuzustimmen, dass dies Dinge sind, die es wert sind, getan zu werden, anstatt sie einzuschleusen, weil die Entwickler sie mögen.