Refactoring ist eines dieser Worte, das bei vielen Leuten Angst auslöst, von Entwicklern bis zu Produktmanagern und allen dazwischen. Es kann in vielerlei Hinsicht auch ein Schimpfwort sein. Es ist auch etwas, worüber wir hier eine ganze Menge reden, da wir, ähnlich wie bei Büchern zu diesem Thema, wo man damit anfangen kann und den Auswirkungen des Anhäufens von technischer Schuld.
Ben Rady hat auch Gedanken zum Refactoring, aber im Kontext von Pair Programming
Wir arbeiten ungefähr 6 Stunden am Tag im Paar. Alles, was auf dem kritischen Pfad liegt, wird im Paar bearbeitet. Immer. Unser Ziel ist es immer, das, woran wir arbeiten, so schnell wie wir es verantwortungsvoll können in die Produktion zu bringen, und der beste Weg, den ich dafür gefunden habe, ist im Paar.
Ben taucht dann in den Prozess der Zusammenarbeit mit anderen ein und wie man Software mit diesem Ansatz ausliefert, was meiner Meinung nach viel mit Best Practices für die Frontend-Entwicklung zu tun hat. Aber ich liebe auch, wie Punk-Rock dieses Team ist, da sie anscheinend keine Backlogs oder viele Besprechungen zur Verwaltung ihrer Projekte haben.
Kein formelles Backlog. Wir haben drei Zustände für neue Funktionen. Jetzt, als Nächstes und wahrscheinlich nie. Was auch immer wir gerade tun, ist das Wertvollste, was wir uns vorstellen können. Was als Nächstes ansteht, ist das nächstwertvollste Ding. Wenn wir neue Arbeit aufnehmen, fragen wir „Was als Nächstes?“ und diskutieren. Wenn uns jemand mit einer Idee kommt, fragen wir: „Ist das wertvoller als das, was wir als Nächstes tun wollten?“ Wenn nicht, wird es normalerweise vergessen, denn bis wir das erledigt haben, gibt es etwas anderes, das neuer und besser ist. Aber wenn es wieder auftaucht, schafft es vielleicht den Cut.
Ich frage mich, wie viel Zeit sie pro Jahr sparen, ohne über Stories und Punkte diskutieren zu müssen und ob diese eine winzige Funktion wichtiger ist als diese andere. Jedenfalls finde ich all diese Dinge sehr inspirierend.
Das ist wirklich nützlich. Es gibt auch die MoSCoW-Methode aus Scrum – Must have (Projekterfolg hängt davon ab), Should have (wäre sehr nützlich, aber der Erfolg hängt nicht davon ab), Could have (schön zu haben, aber keine Notwendigkeit). Das „W“ steht für „Would like to have“, aber ich neige dazu, das in dieselbe Schublade wie „Could have“ zu stecken, da ich drei Bedürfnisstufen ausreichend finde.