Ist zufälliges Refactoring von Code in Scrum erlaubt?

Hintergrund

• Mein Team nutzt Scrum
• Ich habe momentan keine Aufgabe zugewiesen
• Der Rückstand enthält keine ausstehenden Aufgaben mehr
• Heute ist Labor Day für meinen Kunden.

Ich hatte heute nicht viel zu tun und wollte anfangen, Code umzugestalten, den ich in dem Projekt, an dem ich arbeite, immer wieder sehe. Derzeit bin ich jedoch keiner Sprintaufgabe für großangelegte Umbauten zugewiesen.

Ist es in Scrum in Ordnung, wenn ich anfange, zufällig Code umzugestalten, den ich habe und nicht geschrieben habe, was mich immer stört, aber an anderen Tagen keine Zeit habe, ihn aufgrund von Aufgaben an anderen Tagen zu korrigieren?

Was ist mit den anderen Tagen, an denen ich zwischen den Sprints Freizeit habe?

Ich mache und glaube an kontinuierliches Refactoring. Ich mache das immer an den Codeteilen, an denen ich arbeite, wenn ich eine Story zugewiesen bekomme, aber wie sieht es mit einem anderen Code aus, der momentan nicht mit dem zusammenhängt, an dem ich gerade arbeite?

Ich habe wirklich nicht vor, andere Antworten anzugreifen, aber schreibt hier sonst niemand automatisierte Tests? Hier ist eine lustige Lektüre von Martin Fowler für alle, die Scrum ohne geeignete Softwareentwicklungspraktiken ausführen. Auch dazu sagt Robert C. Martin hier viel .

Also, auf meine Antwort ... Kurz gesagt, es geht so:

Ja, das "zufällige" Umgestalten von Code ist in Scrum zulässig , solange das Team entscheidet, dass dies getan werden soll. (Immerhin ist es selbstorganisierend)

Und nun zur langen Antwort:

Es ist offensichtlich, dass es ein Rezept für eine Katastrophe ist, nach jedem Sprint immer mehr technische Schulden zu hinterlassen. Bald werden alle langsamer, wenn der Code chaotischer wird. Jede Änderung ist schwieriger durchzuführen, da der Code so durcheinander und chaotisch ist, dass es länger dauert, die zu ändernden Stellen zu finden, als die eigentliche Änderung vorzunehmen. Es wird noch schlimmer, wenn Sie in einem großen und chaotischen Modul, von dem Sie nichts wissen, Änderungen vornehmen müssen. Es wird unmöglich, die Produktivität beim Hinzufügen / Wechseln von Personen im Projekt zu steigern / beizubehalten, und so weiter.

Wenn ein Team seine Geschwindigkeit konstant halten möchte, muss es in der Lage sein, die Codebasis sauber zu halten, um die Software kontinuierlich zu erhöhen. Refactoring ist eine obligatorische Vorgehensweise, wenn Sie Ihre Geschwindigkeit während des gesamten Projektlebenszyklus beibehalten und das Risiko des Hinzufügens / Wechsels von Personen im Projekt verringern möchten und wenn Sie in der Lage sein möchten, Änderungen in Modulen vorzunehmen, von denen Sie nichts wissen über und so weiter.

Refactoring ist jedoch eine sehr gefährliche Aktivität. Ich wiederhole - es ist eine sehr gefährliche Tätigkeit. Das heißt, es sei denn, Sie verfügen über eine ausreichende Testabdeckung, um die Codebasis sicher und frei ändern zu können. Wenn Sie nur einen Knopf drücken, um zu überprüfen, ob nichts kaputt ist, wird das Refactoring zu einer sehr sicheren Aktivität. In der Tat so sicher, dass es Teil des TDD-Zyklus ist, der es Ihnen überhaupt ermöglicht, eine solche Testsuite zu erstellen.

Da sich die Teams in Scrum jedoch selbst organisieren, muss Ihr Team am Ende entscheiden, was das Richtige ist. Ich hoffe, Ihnen einige Argumente gegeben zu haben, falls Sie jemanden überzeugen müssen. (Achten Sie besonders auf die Links im ersten Absatz und auf jeden anderen Artikel, auf den sie verweisen.)

Scrum sagt eigentlich nichts über Refactoring aus.

Was Scrum sagt, ist, dass Sie den Rest Ihres Teams unterstützen sollten, um das Sprintziel zu erreichen, wenn Sie keine Aufgaben im Sprint haben, an denen Sie arbeiten müssen. Auch wenn das bedeutet, Kaffee für sie zu holen.
Wenn Ihr Team der Meinung ist, dass das Refactoring des Codes der beste Weg ist, den Sie unterstützen können (und dazu gehört, dass die Infrastruktur vorhanden ist, um sicherzustellen, dass das Refactoring nicht zu viele neue Fehler verursacht), dann entscheiden Sie sich auf jeden Fall dafür.

Ich würde nein sagen, das ist es nicht. Dies ist unabhängig von der Art der Arbeit (Refactoring usw.).

Zumindest sollten Aufgaben erstellt und in Ihren aktuellen Sprint übernommen werden. Der Zweck der Zeiterfassung besteht darin, Ihre Geschwindigkeit zu erfassen, um zukünftige Sprints effektiv aufzeichnen zu können. Wenn Sie an Dingen arbeiten, ohne sie zu verfolgen, wirkt sich dies auf die Geschwindigkeit aus, und sie wird mit der Zeit nicht besser, wie dies mit der richtigen Verfolgung beabsichtigt ist (Sie werden wahrscheinlich regelmäßig nicht genug Arbeit haben, da Ihre projizierte Geschwindigkeit geringer ist als Ihre tatsächliche Geschwindigkeit ).

Was die Refactoring-Arbeit an sich angeht, kann ich eine Tirade darüber machen, aber ich werde es nicht tun, da ich nicht denke, dass es die Kernfrage ist, die Sie zu beantworten versuchen.

Ich werde auch nein sagen. Re-Factoring führt oft zu unbeabsichtigten Fehlern, wenn es nicht richtig verwaltet wird.

Als GM habe ich in regelmäßigen Abständen alle an einem anderen Projekt beteiligt und eine Woche lang Codeüberprüfungen / Re-Factoring / Umbenennen und Durchsetzen von Konventionen für ein Projekt durchgeführt. Diese Re-Factoring-Sprints wären fast immer kosmetischer Natur. Jedes funktionale Re-Factoring sollte im Voraus geplant werden und den ursprünglichen Entwickler einbeziehen.

Das funktionale Re-Factoring sollte immer als Teil des Scrum-Prozesses geplant und koordiniert werden, damit die Zeit nachverfolgt werden kann und alle erforderlichen Teammitglieder verfügbar sind, um den Prozess zu validieren. Ein Entwickler sollte den Code, der von einem anderen Entwickler geschrieben wurde, nicht ändern, da dies höchstwahrscheinlich den aktuellen Sprint für alle durcheinander bringt. Vor allem, wenn es um das Zusammenführen von Code geht.

Wenn es sich um ein Projekt handelt, bei dem Sie der alleinige Projektbetreuer sind und das Ihre eigene Freizeit ist, kann dies anders sein, vorausgesetzt, Sie unternehmen Schritte, um sicherzustellen, dass Sie bei Ihrem aktuellen Sprint keine unnötigen Verzögerungen verursachen.

Fragen Sie im Zweifelsfall Ihren Vorgesetzten.

BEARBEITEN: Ich möchte auch erwähnen, dass mit einem bestimmten Teil des Codes, den Sie nicht mögen, möglicherweise ein bestimmtes Leistungsziel verknüpft ist. Sie mögen es vielleicht nicht, aber es ist möglicherweise schneller als alles, was Sie bauen können, um es so zu nutzen, wie Sie es möchten. Ein weiterer Grund, warum funktionales Re-Factoring immer ein verwalteter Prozess sein sollte.

Scrum sagt nichts über Refactoring aus (siehe einen Vortrag von Robert C. Martin, "Das Land, das Scrum vergessen hat").

Bei Scrum-Aufgaben handelt es sich um vom Kunden angegebene Funktionen Ihrer Software, nicht um technische Schulden, die durch Refactoring zurückgezahlt werden müssen. Dies sind völlig unterschiedliche Abstraktionsebenen. Der Kunde ist meist nicht in der Lage, die Notwendigkeit zu beurteilen.

Scrum ist statistisches Projektmanagement. Um aussagekräftige Messwerte zu erhalten, wie lange es dauert, müssen Sie die Leistung (Leistung pro Sprint) kennen. Sie vergleichen die Schätzung und die tatsächliche Dauer eines Features, damit mindestens mehr als ein Sprint in die Statistik eingeht. Ich empfehle 5 Sprints. Aber das hängt von Ihrem Team ab.

Wichtig ist, die Maßnahmen aussagekräftig und vergleichbar zu halten, um eine Prognose zu ermöglichen. Dies ist nicht der Fall, wenn die Leistung aufgrund technischer Schulden sinkt.

Wenn Sie jetzt immer noch daran denken, Aufgaben umzugestalten, haben Sie zwei Probleme: 1. Ein Kunde, der nicht versteht, warum er eine Aufgabe annehmen muss, die keine neue Funktion hervorbringt Sie ändern plötzlich eine andere Variable, die in früheren Sprints nicht berücksichtigt wurde

In beiden Fällen gefährden Sie die Idee von Scrum, wenn Sie mit dem Kunden über Funktionen sprechen UND zuverlässige Prognosen für "Wie lange dauert das?" auf statistische Weise. Um sicherzugehen, müssen Sie Ihre Codebasis in einer konstanten (möglicherweise hohen) Qualität halten.

Refactoring ist die meiste Zeit eine unterirdische Aufgabe. "Große" Refactorings bedeuten, dass "kleine" Refactorings in der Vergangenheit nicht bearbeitet wurden.

Ein letzter Hinweis: Wenn Sie Refactorings durchführen, stellen Sie sicher, dass die zu testende Komponente refactoriert wird. Ohh, hast du keine Tests? Machen Sie eine Aufgabe, um Tests zu schreiben. Ihr Kunde wird froh sein zu wissen, dass die Software, die er aktuell verwendet, nicht über genügend Testabdeckung verfügt ...

Halten Sie die technischen Dinge vom Kunden fern und machen Sie Ihre Arbeit als professioneller Entwickler.

Hier ist ein Ansatz: Beides!

Refactoring ist oft fehleranfällig oder zeitaufwändiger als es ursprünglich als @misterbiscuit angegeben wurde.

Überlegen Sie sich also, ob Sie versuchen, einen Entwurf oder eine Spitze zu erstellen. Sie brauchen zum jetzigen Zeitpunkt keine Genehmigung einzuholen oder Werbung zu schalten.

Versuchen Sie dann, es über einen von zwei Kanälen einzuschließen:

• ein vorhandenes Ticket, das denselben Code / dieselbe Funktionalität enthält, in die Sie dies angemessen einwickeln können. Vernünftigerweise wie mit anderen Teammitgliedern vereinbart.
• ein Ticket für die Überprüfung bei der nächsten Kartenpflege (oder wöchentliche Besprechung usw. bei Wasserfall). Zu diesem Zeitpunkt können Sie die Argumente dafür vorbringen.

Sobald Sie das tatsächliche Buy-In erhalten haben, können Sie versuchen, Ihren Spike anzuwenden oder zu wiederholen und den tatsächlichen Code in den Hauptzweig (Master usw.) einfließen zu lassen.

Dies hat mehrere Vorteile:

• Alle Ihre Code-Codes durchlaufen den gleichen Prozess, werden getestet, QA, in der Release-Pipeline usw.
• Sie erhalten ein offizielles Buy-in, einschließlich des Produktmanagers, dass das Refactoring Teil des Handwerks ist und nicht etwas, das im Urlaub „eingeschleust“ werden muss. Fragen Sie sich, warum Sie sich nicht in ein aktuelles Feature einschleichen, um die Perspektive zu verbessern.
• Sie können nach Pairing, Code Review, QA, Devops und all der anderen Unterstützung fragen, die für die Änderung des Factoring-Codes erforderlich sein kann. Es wird alles offiziell sein, je nach Richtlinien und Verfahren und über Bord.
• Wenn Sie ein börsennotiertes Unternehmen mit SOX-Konformität sind, möchten / müssen Sie wahrscheinlich einen solchen formalen Prozess durchführen (dh dokumentieren und dann befolgen).
• Sie erhalten eine bessere Reputation sowohl beim Produktmanager (Änderung wurde schnell durchgeführt) als auch beim Entwicklungsteam (Codebasis wurde verbessert).
• Die Organisation bemüht sich um Codequalität, die sich positiv auf Produktivität, Moral, Mitarbeiterbindung und viele andere Gründe auswirkt.
• Der Effekt auf die Projektgeschwindigkeit kann einfacher verfolgt werden, wenn alle Arbeiten enthalten sind. Es kann in Ordnung sein, keine Punkte festzulegen, da die Anwesenheit selbst zur Beeinflussung der Geschwindigkeit verwendet werden kann.
• Entwickler werden wahrscheinlich Tools finden, die einfachere Codeüberprüfungen fördern, wie z. B. Fisheye, Github usw.
• Entwickler werden mit größerer Wahrscheinlichkeit einige grundlegende Standards herausfinden (manchmal dokumentiert, manchmal nicht), die das Teilen von Code und damit das Refactoring erleichtern. Manchmal besteht ein großer Teil des Refactorings darin, einen Stil auszuwählen und ihn dann breit anzuwenden (indem eine Mischung von Ansätzen durch einen ersetzt wird).

Ein letzter Kommentar: Vermeiden Sie, dass der Produktmanager das Wort "zufällig" hört. Sie reagieren möglicherweise günstiger mit einem gezielten, strategischen und leistungssteigernden Code-Upgrade. Oder Application Service Pack. Oder in welcher Sprache auch immer.

Zufälliges Refactoring macht keinen Sinn. Sinnvoll ist das Refactoring eines Codes, der die meisten Vorteile mit sich bringt. Das bedeutet :

• Beheben eines Entwurfs- oder Architekturproblems
• Verbesserung der Umsetzung

Ist es in Scrum in Ordnung, wenn ich anfange, zufällig Code umzugestalten, den ich habe und nicht geschrieben habe, der mich immer stört, aber an anderen Tagen keine Zeit hat, ihn aufgrund von Aufgaben an anderen Tagen zu beheben?

Aus dieser Antwort :

Das Verwalten von Code muss ein Element in Ihrer Burndown-Liste sein (wenn Sie ein Scrum verwenden). Es ist genauso wichtig wie die Neuentwicklung. Während es nicht so aussieht, als ob es "für den Benutzer sichtbar" wäre, erhöht das Ignorieren Ihre technischen Schulden. Wenn sich die technische Verschuldung so weit erhöht, dass die mangelnde Wartbarkeit Ihres Codes die Entwicklung verlangsamt, werden die Verzögerungen bei der Entwicklung neuer Funktionen für die Kunden sichtbar.

In meiner vorherigen Arbeit hatten wir eine Art Gedränge mit größeren Sprints (2-3 Monate). Da es zwischen den Sprints einige Verzögerungen gab (1 Monat), haben wir diese Zeit genutzt, um die Software zu analysieren und den Code umzugestalten.