DevloopEin Produkt erneuern, ohne die Arbeit anzuhalten
Schützen Sie, was bereits funktioniert
Alter Code ist nicht automatisch schlechter Code. Manche Bereiche sind mühsam zu warten und tragen trotzdem jeden Tag wichtige Kundenabläufe. Halten Sie fest, welche Nutzerwege, Integrationen und internen Routinen während des Rebuilds nicht ausfallen dürfen. Die neue Lösung muss sie erhalten, auch wenn sich ihre technische Umsetzung vollständig ändert.
Beziffern Sie die Kosten des aktuellen Systems
Die Aussage, der Code sei chaotisch, rechtfertigt noch keinen Rebuild. Suchen Sie nach den tatsächlichen Kosten. Eine kleine Veröffentlichung kann mehrere zusätzliche Tage brauchen. Derselbe Bereich kann wiederholt Störungen verursachen, oder eine wichtige Funktion bleibt liegen, weil sich dort nichts sicher ändern lässt.
Nutzen Sie die Daten, die bereits vorliegen. Verlorene Stunden, verzögerte Veröffentlichungen und wiederkehrende Ausfälle zeigen, ob ein gezielter Austausch genügt oder ein größerer Bereich erneuert werden sollte.
Wählen Sie eine klare erste Grenze
Beginnen Sie mit einem Bereich, dessen Anfang und Ende erkennbar sind, etwa einer Seite, einem Service oder einer internen Aufgabe. Dieser Bereich sollte sich veröffentlichen lassen, während der Rest des Produkts auf dem bisherigen System bleibt. So kann das Team aus dem echten Einsatz lernen, ohne das gesamte Produkt an dieselbe Entscheidung zu binden.
Behandeln Sie die erste Veröffentlichung als Prüfung dieser einen Grenze. Der ersetzte Bereich sollte besser funktionieren und neben dem übrigen Produkt bestehen können.
Machen Sie jede Veröffentlichung umkehrbar
Bestimmen Sie den Rückweg vor Beginn der Umsetzung. Nutzen Sie ein Feature-Flag, betreiben Sie beide Wege parallel oder halten Sie die vorige Version bereit, bis sich der Ersatz bewährt hat. Die Methode hängt vom betroffenen Bereich ab. Das Team sollte aber wissen, wie es zurückkehrt, bevor dieser Schritt nötig wird.
Definieren Sie das Ende vor dem Start
Schreiben Sie die Abnahmekriterien für jeden Bereich auf und benennen Sie die Person, die ihn freigibt. So sammelt der Rebuild unterwegs nicht jede entdeckte Verbesserung ein. Eine neue Idee kann sinnvoll sein, sollte dann aber als eigene Arbeit geplant werden, statt den aktuellen Bereich unbemerkt zu verlängern.