it-swarm.com.de

Agil - Was machen wir falsch?

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

Ich werde hier ein hypothetisches Problem aufstellen, um die Situation zu veranschaulichen.

Wir haben eine sehr alte App, die einen unordentlichen 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, auf React eine Client-Single-Page-App zu erstellen, sodass Sie mit JQuery weiter davon entfernt sind.

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 JQuery, weil sie schneller ist, und wir sagen, dass wir zurückkehren später aufräumen und in React verwandeln, aber das passiert selten.

Die Anforderungen an das, was wir tun müssen, erhalten wir aus User Stories (die IMO gut gemacht sind, schlank, aber sie erklären, was wir tun und warum wir es tun).

Manchmal sind die Anforderungen an neue Funktionen sehr gering. Wenn in einer Anforderung beispielsweise "Erstellen Sie einen Dialog, der Tonnen von Inhalten lädt", aber nicht die Implementierung einer Ladefunktion angegeben 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 (obwohl 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 in einer guten Codebasis an einem einzigen Tag erreicht werden könnte), hauptsächlich aufgrund dieser Entwicklung Strategie, einfach schnell gehen, das Minimum tun.

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

22
Gabriel Slomka

Dies hat nichts mit Agile oder Scrum zu tun.

Das Problem mit "Klebeband jetzt und wir werden es später beheben" ist, dass später nie kommt und in der Zwischenzeit Sie viel ansammeln technische Schulden .

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

Bei jeder neuen User Story sollte das Team überlegen, wie dies richtig codiert werden kann und nicht, wie dies am schnellsten gehackt werden soll. und planen Sie die Sprints entsprechend.

Um das bestehende Problem zu beheben, lesen Sie die hervorragenden Antworten auf Ich habe 200.000 Zeilen Spaghetti-Code geerbt - was jetzt?

56
Dan Pichelman

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

Wenn Sie alle 12 Prinzipien hinter dem Agilen Manifest richtig lesen, werden Sie feststellen, dass Sie bei den meisten von ihnen versagen.

Stellen Sie häufig funktionierende Software bereit, von einigen Wochen bis zu einigen Monaten, wobei Sie die kürzere Zeitspanne bevorzugen.

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 einzuhalten.

Können Sie sagen, dass Ihr Prozess nachhaltig ist? Treffen Sie Entscheidungen im Hinblick auf Nachhaltigkeit? Oder wählen 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 Agilität.

Das wirklich wichtige Prinzip. Ich glaube, dies sollte in RIESIGEN ROTEN BRIEFEN auf der Seite stehen. Hier scheitern Sie am meisten.

In regelmäßigen Abständen überlegt das Team, wie es effektiver werden kann, und passt dann 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 erkennen kann, kann es diese nicht beheben.

Aus Ihrem Kommentar

Wie kann man das agil durchsetzen?

Erstens, indem Sie lernen, was Agilität eigentlich ist. Scrum ist nicht agil. Einige würden sagen, dass Scrum das schlechteste agile Framework ist, da es zu einfach ist, Ihre genaue Situation zu erreichen. Sie sollten mehr über andere agile Frameworks erfahren. Das, was ich empfehlen würde, ist Extreme Programming. Was Ihre Probleme klar löst. Die Lösungen sind nicht einfach (Fokus auf technische Exzellenz durch robuste automatisierte Tests, Paarprogrammierung und kontinuierliche Lieferung), sondern hochwirksam. Wie in State of DevOps-Bericht gemeldet.

22
Euphoric

Was Sie beschreiben, ist - zumindest meiner Erfahrung nach - ein ziemlich allgemeines Muster von Teams, die versuchen, "agil zu sein". Es steht zur Debatte, ob dies tatsächlich Teil von Agile selbst ist oder eine häufige Fehlimplementierung, gegen das agile Manifest/die agilen Prinzipien oder eine inhärente Konsequenz davon verstößt und so weiter. Nur aus empirischer Sicht und basierend auf meiner eigenen kleinen Stichprobe von Erfahrungen (und den Leuten, mit denen ich spreche), scheint ein Team, das agil ist, eine überdurchschnittlich hohe Chance zu haben, auf dieses Muster zu stoßen. Lassen wir es einfach dabei und konzentrieren uns auf Ihr konkretes Beispiel.

Es gibt zwei getrennte Aspekte zu dem, was Sie beschreiben:

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

Den falschen Weg gehen oder im Kreis laufen

Nach meiner Erfahrung ist der Hauptgrund dafür, dass in dem Versuch, Code schnell zu produzieren, Teams Anwendungsfälle oder Anforderungen, die sie bereits kennen, aktiv beiseite schieben oder leicht herausfinden könnten. 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 Sie nicht wissen können und die sich stark ändern, daher die Idee, schnell zu iterieren und schnell eine vernünftige Ausgabe zu produzieren. Welches ist ein sehr gutes Prinzip. Aber heute sind wir am anderen Extrem: "Das interessiert mich nicht, weil es Teil des nächsten Sprints ist" oder "Ich melde diesen Fehler nicht, ich beschäftige mich damit, wenn er wieder auftaucht". Mein Rat wäre:

  1. Sammeln Sie alle allgemeinen Anwendungsfälle, Anforderungen, Abhängigkeiten und Einschränkungen, die Sie finden können. Stellen Sie es in ein Wiki, damit alle Stakeholder 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 dies als Checkliste während der Entwicklung, um zu verhindern, dass Dinge implementiert werden, die nicht zum Endprodukt beitragen oder Problemumgehungen/Hacks sind, die ein Problem lösen, aber drei neue verursachen.
  2. Formulieren Sie ein übergeordnetes Konzept. Ich spreche nicht über das Entwerfen von Schnittstellen 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 es deutlich werden, wenn Sie die jquery-Workaround-Hilfe als Zwischenschritt verwenden und nur zusätzliche Arbeit verursachen.
  3. Validieren Sie Ihr Konzept anhand der von Ihnen gesammelten Liste. Gibt es offensichtliche Probleme? Macht das Sinn? Gibt es effizientere Möglichkeiten, um denselben Benutzerwert zu erzielen, ohne lange technische Schulden zu verursachen?

Übertreibe es nicht. Sie brauchen nur etwas, damit jeder im Team (einschließlich Nicht-Entwickler) ein gemeinsames Verständnis dafür hat, was der beste Weg zu Ihrem MVP ist. Jeder sollte zustimmen, dass es keine offensichtlichen Versehen gibt und es tatsächlich funktionieren könnte. Dies hilft im Allgemeinen dabei, Sackgassen zu vermeiden oder dasselbe mehrmals wiederholen zu müssen. Agile kann Ihnen helfen, besser mit dem Unerwarteten umzugehen. Es ist kein Argument, das Bekannte zu ignorieren.

Beachten Sie das Sunk-Cost-Fallacy: Wenn Sie mit einer Architektur oder einem Datenbanktyp beginnen, zögern die meisten Leute, diese während des Projekts zu ändern. Es ist daher eine gute Idee, einige Zeit in eine "fundierte Vermutung" zu investieren, bevor Sie mit der Implementierung beginnen. Entwickler neigen dazu, schnell Code schreiben zu wollen. Aber oft ermöglicht ein paar Mocks, Live-Prototypen, Screenshots, Drahtgitter usw. eine noch schnellere Iteration als das Schreiben von Code. Beachten Sie jedoch, dass jede geschriebene Codezeile oder sogar Unit-Tests es schwieriger machen, Ihr Gesamtkonzept erneut zu ändern.

Erfolg messen

Ein völlig anderer 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 absolut gültige Lösung sein, wenn beispielsweise die Markteinführungszeit wichtiger ist als die Stabilität. Wenn Ihr Ziel darin besteht, etwas zu bauen, das von Dauer ist, wäre die Verwendung von Lego besser gewesen. Der Punkt ist: Was als Hack angesehen 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, bei denen alle (einschließlich Verkauf, Bestellung, Benutzer) zustimmten, dass es ärgerlich war. Es hatte jedoch keinen Einfluss auf den Erfolg des Produkts und verursachte keine langfristigen Schulden. Also haben wir es fallen lassen, weil es wertvollere Dinge gab, die mit den Entwicklungsressourcen zu tun hatten.

Mein Rat hier ist:

  1. Behalte alles, auch kleine Fehler, als Tickets in deinem Ticketsystem. Treffen Sie eine aktive Entscheidung, was im Projektumfang liegt und was nicht. Erstellen Sie Meilensteine ​​oder filtern Sie Ihr Backlog auf andere Weise, damit Sie immer eine "vollständige" Liste aller noch zu erledigenden Aufgaben haben.
  2. Haben Sie eine strenge Reihenfolge der Wichtigkeit und einen klaren Grenzwert wo das Projekt als Erfolg angesehen 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 niedrigerer 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 produziert, immer noch ein Netto-Positiv für das Projekt sein!
  3. Verwenden Sie Ihre Bestellung/Benutzer, um den Benutzerwert herauszufinden aber lassen Sie auch Ihre Entwickler die technischen Kosten ermitteln. Nicht-Entwickler können in der Regel nicht beurteilen, wie hoch die tatsächlichen langfristigen Kosten sind (nicht nur die Implementierungskosten!). Helfen Sie ihnen also. Seien Sie sich des Problems des kochenden Frosches bewusst: Viele kleine, irrelevante Probleme können im Laufe der Zeit ein Team zum Stillstand 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 denken, eher denken Sie daran, "können wir als Team bis zum Ende des Projekts alles Notwendige tun". Sprints sind nur eine Möglichkeit, Dinge aufzuschlüsseln und Kontrollpunkte zu haben.
  5. Anstatt etwas früh zeigen zu wollen, zeichnen Sie Ihren Kurs auf dem schnellsten Weg zu einem Produkt mit minimaler Lebensfähigkeit, das dem Benutzer gegeben werden kann. Dennoch sollte Ihre Gesamtstrategie nachprüfbare Ergebnisse dazwischen ermöglichen.

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

Der Trick dabei ist, mit den Gesamtkosten des Projekts zu streiten: Wenn beispielsweise eine Bestellung darauf drängt, Verknüpfungen zu verwenden, um eine Frist festzulegen, quantifizieren Sie den Arbeitsaufwand, der anschließend erledigt werden muss, um das abgeschlossene Projekt zu berücksichtigen!

Achten Sie auch auf kriterienbasierte Optimierung: Wenn Ihr Team an der Anzahl der Storys gemessen wird, die es bei einem Sprint-Review anzeigen kann, ist es am besten, jede Story zu schneiden, um eine gute "Punktzahl" zu erzielen zehn winzige. 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 erforderlichen Benutzerfunktionen funktionieren, wie hoch die Kosten für technische Schulden sind, die im Rahmen des Projekts gelöst werden müssen usw.

Zusammenfassung

Um es auf den Punkt zu bringen: Schnell und minimal zu fahren ist ein guter Ansatz. T Das Problem besteht darin, "schnell" und "minimal" zu interpretieren. Man sollte immer die langfristigen Kosten berücksichtigen (es sei denn, Sie haben ein Projekt, bei dem dies irrelevant ist). Die Verwendung einer Verknüpfung, die nur 1 Tag dauert, aber 1 Monat nach dem Versanddatum eine technische Verschuldung verursacht, kostet Ihr Unternehmen mehr als eine Lösung, die 1 Woche gedauert hat. Das sofortige Schreiben von Tests 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 ein Unternehmen, das durch den Versuch, großartigen 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.

Ich hoffe, das hilft!

9
AlexK

Aus Scrum-Sicht klingt es so, als ob Sie falsch arbeiten, weil Sie nicht arbeiten mit dem Client. 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 schnellen Lösungen oder benötigen sie ein stabiles, wartbares System, das ihnen langfristig zur Verfügung steht? Das kann schwer zu bestimmen sein, aber Qualität ist ebenso eine Voraussetzung wie eine Hintergrundfarbe oder ein Leistungsmaßstab. Der Kunde muss sich bewusst sein, dass Stabilität und Wartbarkeit nicht kostenlos sind und in das Produkt integriert werden müssen.

Wenn sie sagen, dass es das erstere ist, machen Sie nichts falsch - vorausgesetzt, Sie erklären ihnen in den Sprint-Reviews, dass Sie technische Abstriche machen, 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 Bewertungen, dass Sie Abstriche machen, um Software schneller zu liefern? Wenn nicht, sollten Sie sein. Sie müssen Ihren Kunden 100% klar sein, welche Auswirkungen Ihre Designentscheidungen haben, damit sie eine fundierte Entscheidung treffen können, ob Sie Ihre Software mit einem angemessenen Qualitätsniveau liefern.

7
Bryan Oakley

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

Nun, da ich Ihre Aufmerksamkeit habe, lassen Sie mich bitte erklären. 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 und geraten tiefer in Schwierigkeiten, indem sie Abstriche machen, um rechtzeitig zu liefern.

In Scrum können Sie (als Entwickler) Ihre eigenen Planungen vornehmen. Niemand sagt Ihnen, dass Sie innerhalb von x Tagen eine Funktion bereitstellen sollen. Wenn Ihnen jemand sagt, dass Sie in x Tagen liefern sollen, machen Sie kein Scrum.

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

5
Martin Maat

Lassen Sie uns untersuchen, was Sie tun, und Agile für einen Moment 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, wir werden später darauf zurückkommen aufräumen und in reagieren verwandeln, aber das passiert selten.

Dies wird als "Übernahme technischer Schulden" bezeichnet. Martin Fowler beschrieb den "Quadranten der technischen Schulden" in einem Blogpost von ihm entlang der beiden Achsen: "Reckless vs. Prudent" und "Deliberate vs. Inadvertent".

Sie entscheiden sich ausdrücklich für die Verwendung der bekannten alten Technologie-Abfrage, mit der Sie weiter von einem Ihrer ausdrücklichen Ziele entfernt werden (nämlich eine einseitige App). 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, um danach zu reagieren. Sie wählen eine Alternative, die nur Nachteile gegenüber der Alternative hat, die Sie wissen, um die richtige zu sein (dh sich die Zeit zu nehmen, um die Funktion in Reaktion zu implementieren), basierend auf einer Einschätzung, dass Geschwindigkeit von entscheidender Bedeutung ist. Das ist rücksichtslos.

Martin Fowler fasst diese Art von Schulden unter "Wir haben keine Zeit für Design" zusammen. Dies ist eine geeignete Wahl in einer Umgebung, in der Sie nicht erwarten, den Code zu warten oder sogar länger als ein paar Tage zu codieren. Ihr Projekt ist jedoch ein langjähriges Projekt, das explizit die Wartung Ihrer Kunden umfasst.

Was Sie tun, ist falsch auf der sehr grundlegenden Ebene. Es ist schlechtes Engineering !

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

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

3
Vogel612

Hören Sie einfach auf, Agile zu verwenden ...

Oder besser gesagt, hören Sie auf zu versuchen, etwas auf eine bestimmte Art und Weise zu tun, nur weil dies (Ihr Verständnis von) Agilität (oder Scrum usw.) vorschreibt. Der Versuch, eine (falsche) Interpretation eines dieser Begriffe auf ein Projekt in der falschen Phase anzuwenden, kann schnell zur schlechtesten 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 Architekturdesigns (dort habe ich es gesagt).

Die Gründe dafür könnten sein:

  • 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 sie rettet (alles bügelt sich aus, weil wir Agile verwenden).

Die einfache Lösung besteht darin, all diese magischen Wörter fallen zu lassen und die Realität der Situation zu betrachten, die wie folgt zusammengefasst werden kann:

  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 fragen, warum es überhaupt zu diesem Zustand gekommen ist, wobei sich der Schuldfinger immer wieder dreht. Die Antwort ist, dass dies unvermeidlich ist: Wenn Ihr Design reift, erkennen Sie, dass Sie es anders hätten tun sollen, aber Sie hätten es nicht vorhersehen können. Darüber hinaus ist dies keine einmalige Realisierung pro Projekt, sondern 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. Todesmarschieren Sie Ihre Entwickler zu Terminen.
  2. Daraus geht hervor, dass Entwickler möglicherweise nur Zeit für Tickets protokollieren, ohne dass Tickets für "Denken, Konsolidierung und Qualitätsumgestaltung" und eine großzügige Zeitspanne für diese vorhanden sind.
  3. Nicht lange genug Eigentum einer Person an der Architektur geben, um sie in den Griff zu bekommen
  4. Diese Person darf nicht die Änderungen vornehmen, die sie für erforderlich hält

Wenn Sie es so betrachten, ist es leicht zu erkennen, wie einige Interpretationen von Agile & Scrum Sie tatsächlich noch schneller auf diesem Weg führen werden!

Ein Ansatz besteht darin, Tickets für jedes Refactoring-Bit zu erstellen. 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, wodurch die Fristen verschoben werden und das Ticket Genehmigungsschleifen durchläuft, wodurch nur alles verlangsamt wird.

Ein anderer 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 Sie die Zeit, die ohne Refactoring hätte benötigt werden sollen) und Refactoring-Zeit (ein großes Ticket für die Woche, keine Genehmigungsschleifen, nur Diskussion 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 antworten: "Was machen wir falsch?" Ich würde sagen, Sie vertrauen auf eine Methodik über den gesunden Menschenverstand. Sie fragen sogar nach einem "agiler Ansatz für dieses Problem". Ich würde sagen, lass die Worte fallen und denke über das eigentliche Problem nach. Wenn Sie dann wirklich verschiedene Manifeste herausgreifen wollen, um herauszufinden, ob Ihr endgültiger gesunder Menschenverstand tatsächlich unter dem Deckmantel "agil" oder "scrum" fällt, dann machen Sie es auf jeden Fall :-)

2
AndyHasIt