Fuehrung

Heute möchte ich über eine Methode sprechen, die ich “Random Refactoring” nenne, und darüber, wie wir als Führungskräfte die richtigen Rahmenbedingungen dafür schaffen können. Die Methode Der Ansatz ist denkbar einfach: Öffne eine zufällige Datei im Projekt. Analysiere kritisch, was sich verbessern lässt. Führe ein klassisches Refactoring dieser Stelle durch (ggf. Tests schreiben, verbessern, …). Was auf den ersten Blick nach Chaos klingt, hat sich für mich als effektiver Weg erwiesen, die Code-Qualität kontinuierlich zu verbessern. Nebenbei bemerkt kann man sich auch beim zufälligen Auswählen helfen lassen, z. B. mit der “Inspect Code”-Funktion im IntelliJ-Menü “Code”. ...

Als Entwicklungsleiter stelle ich mir häufig die Frage: Wie gut testen wir eigentlich wirklich? Eine hohe Code-Coverage ist zwar schön, sagt aber wenig darüber aus, ob unsere Tests tatsächlich alle wichtigen Testfälle abdecken. Hier kommt Mutation Testing ins Spiel. Die Idee dahinter ist einfach aber genial: Der Code wird automatisch an verschiedenen Stellen “mutiert” (verändert) und dann werden die Tests ausgeführt. Wenn die Tests diese Änderungen nicht erkennen, haben wir eine Lücke in unserer Testabdeckung gefunden. ...

Gemeinsam stark: Unsere Reise ins Extreme Programming bei der SWE Zentrale Zwei Köpfe, ein Code – eine scheinbar einfache Idee, die unsere Art zu arbeiten völlig umkrempeln könnte. Das zumindest ist der Claim, den Kent Beck schon vor über 20 Jahren in seinem Buch Extreme Programming vorgestellt hat. Zwei Entwickler, Ein Arbeitsplatz: Zwei Programmierer teilen sich einen Computer, eine Tastatur und eine Maus. Rollenverteilung: Es gibt den “Driver”, der den Code schreibt, und den “Navigator”, der den Überblick behält, strategisch denkt und Vorschläge macht. ...

Vor inzwischen mehr als 5 Jahren bin ich über ein Buch gestolpert, das ich inzwischen wieder vergessen hatte. Nach langer Zeit habe ich mal wieder meine leanpub Bibliothek durchstöbert. Und hier war es: https://leanpub.com/fixitnowordeleteit Vereinfacht beschreibt diese kurze Buch die Idee, Bugs entweder sofort zu löschen, oder sie zu löschen. In der Realität sieht es meistens anders aus. Hier stehen Features und Bugs in einem ständigen Konflikt. Es gibt Stakeholder, die gerne Fortschritte sehen möchten, es gibt Anwender, die mit Problemen und Bugs zu kämpfen haben und dann gibt es das Entwicklungsteam, dass sozusagen zwischen beiden Stühlen steht. ...

Um bessere Qualität in der Entwicklung zu erreichen, gibt es ein Konzept, das sich “Definition of Done” (DoD) nennt. Die Idee, dass das Team sich selbst Gedanken darüber macht, was alles nötig ist, damit eine Aufgabe (Story, …) wirklich erledigt ist, finde ich einen schönen Ansatz. Die Herausforderung sehe ich aber in der tatsächlichen Umsetzung. Ich habe bisher verschiedene Ausprägungen davon erlebt: Die Umsetzung wird mit dem “Holzhammer” durchgesetzt. Durch Zwang von oben oder Gruppendruck entsteht dann eine (evt. unbewusste) Ablehnung und es werden kreative Wege gesucht, die “ungeliebten” Aufgaben zu umgehen. ...