Codequalität: "Funktioniert" ist nicht genug

Bewusster arbeiten

Falls entsprechende Erfahrung bereits vorhanden ist oder Grundlagen beispielsweise durch die oben genannten Maßnahmen geschaffen wurden, gilt es, ein einheitliches Qualitätsverständnis zu schaffen. Im Sinne der von W. Edwards Deming vertretenen Thesen ist es notwendig, eine Kultur zu etablieren, in der Qualität „eingebaut“ wird, statt mangelnde Qualität durch Kontrollen auszusieben [10]. Da wir in der Softwareentwicklung nicht von klassischen Produktionsprozessen ausgehen können, müssen wir Systeme schaffen, in denen ein geeignetes Qualitätsniveau zum Selbstverständnis werden kann. Letztlich geht es darum, das Erlernte in den Arbeitsalltag zu integrieren. Mit den folgenden Aktivitäten habe ich in der Vergangenheit gute Erfahrungen gemacht:

Ein in der IT-Branche zunehmend beliebtes Verfahren sind so genannte Retrospektiven [11]. Durch einen Moderator (in diesem Kontext häufig „Facilitator“ genannt) wird ein geschützter und formalisierter Rahmen für Rückblick, Analyse und Veränderung geschaffen. Ergebnisse der Retrospektive fließen in den nächsten Arbeitsabschnitt ein und werden hinsichtlich ihrer Wirksamkeit überprüft. Bezogen auf den hier beschriebenen Veränderungsprozess können sie Raum bieten, um sich offen und intensiv mit der eigenen Arbeitsweise und dem eigenen Qualitätsverständnis auseinanderzusetzen.

Eine weniger ritualisierte Form der Reflexion bieten so genannte Brown-Bag-Seminare oder Lunch-and-Learn-Treffen. Hier werden im Rahmen einer gemeinsamen Mahlzeit vorher festgelegte oder spontan ausgewählte Themen diskutiert. Hier eignet sich besonders die von Michael D. Hill als „Lottery Learning“ [12] beschriebene Variante, in der ein zufällig ausgelostes Teammitglied ein Stück Quellcode auswählt, über das in lockerer Form diskutiert wird.

Ebenfalls einfach umzusetzen und wenig zeitaufwändig sind regelmäßige Termine, zu denen das Team für einen festgelegten Zeitraum (beispielsweise eine Stunde) ausschließlich an einem bestimmten Qualitätsaspekt, beispielsweise der Behebung bestimmter Designmängel oder der Erhöhung der Testabdeckung, arbeitet. So lässt sich der natürlichen Erosion des Programmcodes entgegenwirken, während gleichzeitig erlernte Fähigkeiten in der Praxis vertieft und zur Gewohnheit werden.

Begleitend zu allen genannten Maßnahmen hat sich der Einsatz eines Coachs als ausgesprochen hilfreich erwiesen. Jenseits der Methoden klassischer Beratung kann er nicht nur Teams helfen die selbstgesteckten Ziele zu erreichen, sondern auch zwischen Rollen vermitteln. Grundsätzlich sind zwei Arten des Coachings denkbar: Als Personalverantwortlicher kann ich Mitarbeitern den Freiraum lassen, sich in die Rolle des internen Coachs hineinzuentwickeln. Die nötigen Fähigkeiten kann man sich, eine gewisse Kommunikationsfertigkeit vorausgesetzt, beispielsweise auf Coach Camps [13] aneignen. Als Qualifikation ist entsprechend weniger eine vollständige Durchdringung des Themas aus fachlicher Sicht notwendig, als vielmehr die Akzeptanz innerhalb der Mannschaft. Alternativ gibt es heute eine wachsende Zahl externer Coachs, die sich auf das Thema Programmierhandwerk spezialisiert haben.

Wir haben doch keine Zeit

Zuletzt möchte ich ein interessantes, nicht selten in den von der Auseinandersetzung mit technischer Qualität ausgelösten Transformationsprozessen zu beobachtendes, Phänomen ansprechen: Das empfundene Spannungsgefüge zwischen Qualität und Wirtschaftlichkeit. Hier spielen meiner Meinung nach mehrere Aspekte zusammen:

Häufig werden die Kosten der Veränderung selbst (beschrieben im Satir-Veränderungsmodell [14] und in der IT-Branche als „Improvement Ravine“ [15] bekannt) mit den Kosten für qualitätsschaffende Maßnahmen vermengt, anstatt unter dem Gesichtspunkt der Weiterbildung und Personalentwicklung betrachtet zu werden. Auch kann in der Regel zusätzlicher Aufwand (beispielsweise durch qualitätsschaffende Maßnahmen und Sanierung) einfacher beziffert werden, als zusätzlicher Nutzen (beispielsweise durch höhere Wartbarkeit der Software sowie Motivation und Produktivität der Entwickler). Werden gleichzeitig die durch Qualitätsmängel entstehenden Probleme (etwa Nachbesserungen und Produktivitätsverluste) nicht gegengerechnet, entsteht schnell ein verzerrtes Bild.

In Diskussionen, die ich mit Projekt- und Budgetverantwortlichen führe, stelle ich häufig fest, dass dadurch Qualität primär von der Kostenseite betrachtet wird. Sicher gibt es so etwas wie „zu viel“ Qualität. In der Realität bleibt leider zu beobachten, dass ein Qualitätsniveau, das diese Sorge rechtfertigen würde, in den meisten Fällen nicht vorliegt. Vielfach führt dann die schwer fassbare und zum Teil kontraintuitive Natur technischer Qualität zu einer gefährlichen Situation: So wie ein Flugzeug, dass an Höhe verliert, weil es zu langsam fliegt, durch das Zurückziehen des Steuerhorns nicht steigt, sondern im Gegenteil weiter an Geschwindigkeit verliert, wird ein Projekt, das durch Qualitätsprobleme ins Trudeln geraten ist, nicht durch Einsparungen an qualitätssichernden Maßnahmen aufgefangen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.