Und wo bleibt die Qualität? - Teil 2

“Quality means doing it right when no one is looking.” (Henry Ford)

Wer erinnert sich noch an Petra und ihr Team aus meinem letzten Artikel über Qualität? Dort haben wir einige Praktiken identifiziert, die zu schlechter Qualität der gelieferten Software führen. Das waren zum Beispiel keine klaren Verantwortlichkeiten, eine vernachlässigte Definition of Done und keine Transparenz bezüglich Codequalität. Aber haben wir alle Themen angesprochen? Es ist sicher einigen aufgefallen, dass ich ein paar der “schlechten Angewohnheiten” des Teams übersehen habe ;-) Im folgenden wollen wir uns anschauen, was das Team noch ändern kann, um die Qualität seiner Arbeit zu verbessern.

Arbeite nicht in Isolation

Alex hatte keine Zeit mehr, um für die letzte User Story Unit Tests zu schreiben, weil die Integration des letzten Feature Branches zu lange gedauert hat. Aber warum brauchen wir eigentlich Feature Branches? “Ich will meine Kollegen nicht bei ihrer Arbeit behindern.” ist wohl der häufigste Grund, den ich höre. Auf die Frage: “Arbeitet ihr nicht alle an der gleichen User Story” bekomme ich Antworten wie “Ja, schon. Aber er ist für das Front-end zuständig und ich für das Back-end.” oder “Nein, weil die Story ist zu klein als dass mehr als einer daran arbeiten könnte.” oder “Nein, ich war noch nie in die Offline Implementierung involviert.”.

Solche oder ähnliche Antworten sagen uns, dass die Verwendung von Feature Branches nicht nur das Team durch aufwändige Merge-Vorgänge blockiert, sondern es auch noch andere Themen gibt, die man sich anschauen sollte: das Team ist nicht wirklich cross-funktional oder konzentriert seine Arbeit nicht auf die am höchsten priorisierte Story.

Gemeinsames Arbeiten auf einem Master Branch ohne das Anlegen von Feature Branches unterstützt die Entwickler dabei, als ein Team zu arbeiten, und es verhindert die Entstehung von Silos, wo sich nur eine Person in einer bestimmten Ecke des Source Codes auskennt. Häufige Integration von Änderungen bedeutet enge Zusammenarbeit und benötigt Kommunikation. Man sollte sich nicht durch ein Tool die Erstellung von eigenen Branches für jedes Feature vorschreiben lassen und damit dem Team die Chance nehmen, sofortiges Feedback zu bekommen, wenn etwas schief läuft.

Die Energie des Teams sollte für Pair Programming oder Code Reviews und damit zum Wissenstransfer eingesetzt werden - und nicht mit dem Mergen von Feature Branches am Sprintende verschwendet werden.

Bekenne dich zum Code

“Ich werde diesen Code sicher nicht anfassen.” “Diese Story können wir nicht in den Sprint nehmen, weil Ingrid auf Urlaub ist und sonst weiß keiner, wie die Anpassungen in der Datenbank Schicht zu machen sind.” “Ist mir egal, wie der Code von Alex aussieht, solange er meine wohlgeformten Klassen in Ruhe lässt.” Klingt das bekannt? Dann hat das Team das Prinzip des kollektiven Code Ownerships noch nicht wirklich verinnerlicht.

Als “Gegenmittel” zu solchem Verhalten empfiehlt sich als allererstes die Etablierung von Coding Guidelines, an die sicher jeder im Team hält. Diese Regeln sollten am Besten vom Team selber definiert werden, denn alle Teammitglieder sollten mit diesen Regeln einverstanden sein und sie für sinnvoll erachten. Natürlich wird das einige Diskussionen über den “richtigen” Style auslösen. Hier sollte man im ersten Schritt ein minimales Regelset als Ziel definieren, um solche Debatten möglichst kurz zu halten. (Falls mehr als ein Team an der gleiche Code Basis arbeitet, sind gemeinsame Regeln über alle Teams eine gute Idee.) Die Einhaltung dieser Guidelines kann (und sollte auch) beim Commit mit Tools wie z.B. styleCop oder Checkstyle überprüft werden.

Das Forcieren von Pair Programming und gemeinsamen Code Reviews hilft nicht nur, wie schon oben erwähnt, bei der Vermittlung von Know-how, sondern trägt auch zu einem Gefühl der geteilten Verantwortung für alle Teile des Codes bei. Der Scrum Master kann diesen Prozess unterstützen, indem er das kollektive Design der Architektur und Umsetzung von User Stories im Sprint Planning II Meeting fördert. (Einige Beispiele dafür finden sich im Artikel Using taskboards correctly. .) Wenn das gesamte Team am Entwurf von neuen Funktionen, Konzepten und Klassen beteiligt ist, dann wird auch das gesamte Team für die resultierende Software zur Verantwortung gezogen werden.

Und schließlich…

Pflege deine Tests

Test Code wird oft vernachlässigt und nicht wirklich gepflegt. Es ist ja “nur” Test Code. Das ist eigentlich nicht fair. Wie oft wurde durch die Tests nach einer kleineren Refaktorierung ein heikler Bug gefunden, der sonst die Datenbank des Kunden außer Gefecht gesetzt hätte? Wer mag nicht das beruhigende Gefühl, wenn alle Tests nach dem Einchecken der letzten Änderung grün sind? Wären wir so entspannt bei der Kundenbesprechung über die nächsten Feature Requests ohne die Gewissheit, dass unsere Test Suite uns sofort sagen wird, ob nach den Modifikationen noch alles funktioniert?

Tag für Tag, Nacht für Nacht erledigen diese kleinen Code-Routinen ihre Arbeit ohne Klagen - wie brave Soldaten. Und wir können uns auf die wirklich wichtigen Dinge konzentrieren.

Daher sollten wir ihnen auch die Aufmerksamkeit schenken, die ihnen gebührt. Sie sollten wie unser Produktivcode behandelt werden und es sollten auch die selben Qualitätsrichtlinien angewendet werden. Unsere Tests werden gemeinsam mit dem Code wachsen und altern. Solange der Produktivcode life ist, wird auch der Test Code da sein. Wir müssen ihn warten, anpassen und refaktorieren - genauso wie den Produktivcode.

Schlecht geschriebene Unit Tests sparen vielleicht zu Beginn Zeit, aber auf lange Sicht werden sie höhere Wartungsaufwände verursachen. Nicht korrekt geschrieben, unter Beachtung aller Clean Code Richtlinien, werden sie vernachlässigt werden, sobald der Aufwand für die Anpassung an Codeänderungen oder um alle Tests grün zu halten, den Aufwand für die Implementierung neuer Stories übersteigt.

Und man sollte nie zulassen, dass ein Test länger als einen Tag rot ist. Ein Test, der fehlschlägt, öffnet die Tür für den nächsten, und schon bald steigt die Anzahl der roten Tests rasant - ohne dass es jemanden kümmert.

Automatisierte Tests sind wie alte Freunde:
wenn man sie respektiert und gut behandelt, dann sind sie immer für einen da.

Bleibe wachsam

Qualität sollte zur Gewohnheit werden - gleichzeitig sind Gewohnheit und Routine ihr größter Feind. Denn Gewohnheit kann sich auch in Nachlässigkeit verwandeln - wenn man nicht mehr darüber nachdenkt oder sie in Frage stellt. Daher sollten wir immer wieder unsere Praktiken genauer unter die Lupe nehmen und uns fragen, ob sie noch den ursprünglichen Zweck erfüllen. Wir leben in einer schnelllebigen Welt, in der sich die Rahmenbedingungen laufend verändern. Etwas, das gestern perfekt funktioniert hat, kann heute vielleicht schon zu völlig anderen Resultaten führen.

Inspect and adapt!

15 Mär

Ich Entwickler, Du Tester

Von Susanne Albinger

Laut Scrum Guide sind alle Mitglieder eines Scrum Teams Developer. Allerdings treffen wir in der Realität immer wieder auf Teams, die sich in Entwickler und Tester unterteilen. Sollte es in der Agilen Welt nicht um Teamarbeit gehen? Ein Team transformiert gemeinsam Requirements in funktionierende Software. Aber ist das wirklich so?

14 Feb

Jenkins Pipeline Plugin

Von Gerald Hoheneder

Der Sprint näherte sich dem Ende, die letzten Änderungen waren eingecheckt und alle Tests sind erfolgreich durchgelaufen. Es war also an der Zeit die neuen Features auf das Demo-System unseres Kunden zu deployen. Eigentlich kein Problem, schließlich sind das lediglich ein paar Klicks auf der Jenkins-Oberfläche und alles Weitere geschieht ganz von selbst und bedarf keiner weiteren ...


Neueste Artikel

  • Der Klebstoff, der alles zusammenhält

    24.04. / Susanne Albinger

    Man setze sechs Leute in einen Raum, versorge sie mit ausreichend Post-its, einem Taskboard und einem gemeinsamen Ziel und - voilá - fertig ist das Scrum Team! Hoch performant, kreativ und innovativ, und liefert alle zwei Wochen ein potentiell auslieferbares Produkt Inkrement. Klingt einfach. Aber…

  • Team Objectbay Skitage

    17.03. / Camilla Franek

    Strahlend blauer Himmel, verschneite Bergspitzen und perfekt präparierte Pisten. Die besten Bedingungen, um in unsere Team Objectbay Skitage zu starten.

  • Ich Entwickler, Du Tester

    15.03. / Susanne Albinger

    Laut Scrum Guide sind alle Mitglieder eines Scrum Teams Developer. Allerdings treffen wir in der Realität immer wieder auf Teams, die sich in Entwickler und Tester unterteilen. Sollte es in der Agilen Welt nicht um Teamarbeit gehen? Ein Team transformiert gemeinsam Requirements in funktionierende Software. Aber ist das wirklich so?

  • Und wo bleibt die Qualität? - Teil 2

    16.02. / Susanne Albinger

    Es ist leicht, über Qualitätsbewusstsein und kollektive Verantwortung des Teams zu reden. Aber oft ist es eine Summe von kleinen Dingen und Praktiken, die ein Team in die Lage versetzen, konstant hohe Qualität zu liefern.