Suche
Qualitätsstandards als Communityaufgabe

Interne Communitys verbessern die Softwarequalität

Andreas Christian Fischer

© Shutterstock / Artisticco

Was Qualitätsmaßnahmen anbelangt, herrscht bei Entwicklern meist eher Augenrollen als Begeisterung. Zu oft sind die Maßnahmen unpraktisch und stehen mehr im Weg als dass sie helfen. Ganz anders kann es aussehen, wenn die Mitarbeiter ihre Standards und Vorgehensweisen in einer Software Craftsmanship Community selbst entwickeln.

Wie entsteht qualitativ hochwertiger Code? Die Frage treibt notwendigerweise jedes Softwarehaus um. Schon immer. Allerdings ist die Frage aktuell vielleicht noch etwas intensiver im Fokus als in der Vergangenheit. Denn in einem zunehmend komplexen Umfeld hängen Qualität, Erweiterbarkeit, Wartbarkeit und damit auch die Wirtschaftlichkeit von softwarebasierten Produkten einerseits in hohem Maße von den technischen Fähigkeiten der einzelnen Entwickler, andererseits aber auch von der Bereitschaft aller, in einem Team Verantwortung zu übernehmen und gemeinsam an einem Ziel zu arbeiten, ab. Diese Gedanken finden sich in zahlreichen Entwicklungen und Initiativen der letzten Jahre wieder, angefangen von Extreme Programming über agile Softwareentwicklung bis hin zu Software Craftsmanship und der Clean-Code-Bewegung. Interessant dabei ist, dass all diese Entwicklungen nicht top-down von oben verordnet, sondern bottom-up von den Softwareentwicklern selbst vorangetrieben werden. Daraus sind Initiativen wie das Agile Manifest von 2001 oder das Software Craftsmanship Manifest von 2009 entstanden. Die dahinter stehende Grundhaltung ist, dass jeder Entwickler gute Software schreiben will. Man muss ihn nur lassen. Aber was passiert, wenn man ihn tatsächlich lässt? Die DATEV hat sich darauf eingelassen. Welche Dynamik daraus entstanden ist, verdeutlicht die Entstehungsgeschichte der Software Craftsmanship Community @DATEV und ihr Wirken hinsichtlich der Entwicklung eines übergreifenden Standards für Softwarequalität im Unternehmen.

Bei der DATEV in Nürnberg arbeiten knapp 2.000 Softwareentwickler stetig daran, die bestehende Softwarepalette zu verbessern und neue Produkte für ihre Mitglieder – Steuerberater, Rechtsanwälte und Wirtschaftsprüfer – sowie deren meist mittelständische Mandanten zu gestalten. Das Problem: Wie ist bei einer kontinuierlich wachsenden Entwicklergemeinschaft gewährleistet, dass alle mit ihren unterschiedlichen Stärken und Kenntnissen der einzelnen Programmiersprachen einheitliche Standards befolgen und die Vielzahl an Lösungen wirtschaftlich beherrschbar bleibt?

Nachdem an verschiedenen Stellen im Unternehmen Qualitätsinitiativen ins Leben gerufen wurden – mal mit mehr, mal mit weniger Erfolg – sollte 2012 eine einheitliche, für alle Entwickler gleichermaßen gültige Initiative gestartet werden. Die Querschnittsverantwortung für diese Qualitätsinitiative wurde mir übertragen. Nach über 20 Jahren Entwicklungstätigkeit in verschiedenen Bereichen des Unternehmens war mir das Thema Clean Code als ein wesentlicher Qualitätssicherungsfaktor sehr ans Herz gewachsen. Gemeint ist damit, dass in erster Linie Quellcodes, aber auch Dokumente, Konzepte, Regeln und Verfahren so geschrieben sind, dass sie in kurzer Zeit und mit wenig Aufwand intuitiv richtig verstanden werden. Es geht also darum, im Code selbst möglichst hohe Transparenz herzustellen, beispielsweise, indem Variablen sprechend benannt werden und eine stringente Struktur verwendet wird.

Lesen Sie auch: Wie Sie starre Strukturen aufbrechen – mit Scrum!

Von der Idee zur Community

Die Software Craftsmanship Community geht zurück auf die Initiative einiger weniger Personen bei der DATEV. Wie so häufig, war der Ursprung des späteren Erfolgs ein Misserfolg: Eine der ersten Initiativen in meiner neuen Verantwortung bestand in der Ausrichtung eines Seminars für Clean Code und Softwarequalität. Allerdings geriet es zum Flop. Der extern geladene Seminarleiter konnte die Erwartungen der Teilnehmer hinsichtlich Themenauswahl und methodischen Ansätzen nicht erfüllen. Die Initiative drohte zu scheitern, bevor es überhaupt richtig losging.

Durch Zufall erfuhr Martin Heider, freiberuflich tätiger agiler Coach aus Nürnberg, von dem gescheiterten Seminar. Ein Entwicklerteam hatte ihn engagiert, um die Einführung agiler Entwicklungsmethoden als Berater zu begleiten. Dabei kam die Sprache auch auf dieses Seminar. Aus seiner Sicht drohte ein Schaden, der über ein gescheitertes Seminar weit hinaus reichte. Wenn, so seine Überlegung, Themen wie ein einheitliches Qualitätsverständnis und Clean Code durch ein solches Seminar zu Un-Themen würden, hätte das auch erhebliche negative Folgen für die weitere Entwicklung agiler Methoden bei DATEV. Er ergriff also die Initiative und suchte das Gespräch mit mir, um einen neuen Anlauf in die Wege zu leiten.

Heider war damals schon gut mit den Ideen der Software Craftsmanship vertraut. Ihren Ursprung haben sie im Software Craftsmanship Manifest von 2009, in dem handwerklichen Aspekte als ein wesentlicher Teil der Softwareentwicklung herausgestellt werden. Es geht dabei um die Übertragung von Werten, die man gemeinhin mit dem guten alten Handwerk in Verbindung bringen würde. Also beispielsweise die handwerkliche Präzision und den Anspruch, etwas von Dauer zu schaffen, auf die moderne Softwareentwicklung anzuwenden. Um dies leisten zu können, müssen die Entwickler ihre Werkzeuge beherrschen. Daraus leiten sich die vier Grundprinzipen der Bewegung ab: üben, lernen, lehren und sich kümmern. Jeder kann und soll diese vier Prinzipien in seiner täglichen Arbeit beherzigen, um sowohl die eigenen Fertigkeiten auszubauen als auch andere an ihnen teilhaben zu lassen. Codequalität wird somit zu einem Anliegen der gesamten Entwicklergemeinschaft.

Aus dem Austausch mit Martin Heider ist der Gedanke entstanden, in der DATEV eine eigene Community für Software Craftsmanship zu gründen. Das erste Communitytreffen fand Anfang März 2013 statt. 37 Teilnehmer waren gekommen und diskutierten lebhaft über ihre Vorstellungen einer solchen Community und über die gewünschten Inhalte für einen neuen Seminaransatz. Aus den Diskussionen über die Seminarinhalte wurde im Jahr 2013 gemeinsam mit der Weiterbildungsabteilung ein neuer Kurs entwickelt, der bis heute Bestand hat. Unter dem Titel „Der verantwortungsvolle Softwareentwickler“ werden in drei Tagen die aktuellen Entwicklungen im Handwerk eines Softwareentwicklers vorgestellt und es wird ein Bewusstsein für die weichen Faktoren wie Verantwortung und Teamarbeit geschaffen. Über 400 Entwickler haben das Angebot mittlerweile wahrgenommen.

So konnte Heider nur kurze Zeit später auf dem zweiten Communitytreffen eine Reihe von Ansätzen und Methoden der Software Craftsmanship vorstellen. Auf diese Weise fanden erstmals Begriffe wie Coding Dojo, Code Kata oder Coderetreat Eingang in den Wortschatz und vor allem in die Gedankenwelt der DATEV.

Die Einheit von Lehren und Lernen: Coding Dojos und Coderetreats

Zusammen mit Daniel Bögelein, der sich ebenfalls für das Konzept der Software Craftsmanship begeistert hatte, verfolgten wir die Ideen weiter. Getreu dem Motto „Change braucht Verrückte“ luden wir zum ersten Coding Dojo der DATEV ein. Ohne eine nähere Vorstellung davon zu haben, wie so etwas abläuft oder wie man das moderiert. Doch das Format begeisterte alle Teilnehmer sofort. Bei einem Coding Dojo finden sich mehrere Entwickler zusammen, um ein Code Kata, also eine vorgegebene Programmieraufgabe von überschaubarer Dimension, gemeinsam durchzuführen und so voneinander zu lernen. Zwei Entwickler arbeiten im Team an einem Rechner. Die restlichen Teilnehmer verfolgen das Geschehen über einen Beamer. In einem festgelegten Rhythmus rotiert ein Entwickler aus dem Programmierpaar heraus und ein anderer Teilnehmer nimmt seinen Platz ein. Die Aufgabe wird dabei ständig wiederholt, sodass sich die Lösung kontinuierlich weiterentwickelt. Dieses erste Dojo war so erfolgreich, dass sich schnell Nachahmer fanden und bald eine eigene Coding-Dojo-Moderatorencommunity ins Leben gerufen wurde.

In ihrem ersten Jahr ging die Software Craftsmanship Community den nächsten Schritt: Sie lud zum ersten Coderetreat der DATEV. Jutta Rößner, damals Hauptabteilungsleiterin und mittlerweile Mitglied der Geschäftsleitung, übernahm die Schirmherrschaft für die Veranstaltung. Gemäß den Vorgaben eines Coderetreats fand auch dieser erste DATEV-Event seiner Art an einem Samstag zwischen 8:30 und 17 Uhr statt, mit anschließender Gelegenheit für einen entspannten Ausklang. Bewusst wählte man als Veranstaltungsort eine kleinere Zweigstelle, fernab der perfektionistischen Organisationsmaschinerie der Hauptstandorte. 32 Teilnehmer konnten an diesem ersten Coderetreat teilnehmen und waren begeistert.

Bei Coderetreats geht es nicht darum, neue Aufgaben zu lösen, sondern für eine gleichbleibende Problemstellung immer wieder andere Lösungswege zu suchen. Die Aufgabe ist in der Regel „Conways Game of Life“. Jeweils zwei Programmierer haben 45 Minuten Zeit, gemeinsam ihren Weg zu finden. Am Ende jeder Session wird der Code gelöscht. Es zählt nur der Weg, nicht das Ziel. Nach 45 Minuten soll nichts weiter übrigbleiben als ein Erkenntnisgewinn. Ohne weiteren Ballast kann man sich sodann darauf konzentrieren, das eigene Entwicklungs- und Problemlösungsvorgehen weiter zu optimieren, neue Techniken auszuprobieren und sich von anderen inspirieren zu lassen. Bevor die nächste Runde losgeht, wird in der gesamten Gruppe über die Erfahrungen der letzten 45 Minuten diskutiert. Was lief gut? Was war schlecht? Welchen Hindernissen und Problemen sind die Gruppen auf ihrem Lösungsweg begegnet? Mit den so gewonnenen Erkenntnissen wird dann die Session mit veränderten Bedingungen wiederholt. So kann es beispielsweise sein, dass keine Maus verwendet werden darf, um Tastatur-Shortcuts zu üben. Ein Verbot bestimmter Codekonstrukte kann zu neuen Denkansätzen anregen. Ein Schweigegebot erfordert ein intensiveres Nachdenken darüber, wie der Code selbst zum Sprechen gebracht wird, damit der Partner nahtlos weiterprogrammieren kann. Häufig wird auch ein Partnertausch angeordnet, damit Denkstrukturen aufgebrochen werden.

Die zunächst noch wahrnehmbaren Stimmen, die Coderetreats als „esoterischen Quatsch“ bezeichneten, wurden von der Begeisterung der Teilnehmer dieses ersten und auch der folgenden Retreats schnell marginalisiert. Viele begannen im Anschluss, sich aktiv an der Software Craftsmanship Community zu beteiligen. Es sprach sich herum, dass dieses Format eine enorme Bereicherung ist, und auch die nächsten Veranstaltungen waren regelmäßig überbucht. Um dennoch Chancengleichheit für alle zu wahren, wurden die Teilnehmer unter den Anmeldungen ausgelost. So folgten 2014 zwei Coderetreats, 2015 waren es vier, 2016 dann fünf. Und bei allen zeigten sich Geschäftsleitungsmitglieder vor Ort und bekundeten so ihre Wertschätzung für die Initiative und für das freiwillige Engagement der Teilnehmer. 2016 nahm DATEV auch erstmals als Austragungsort am Global Day of Coderetreat teil, einem weltweiten Lernevent, zu dem auch externe Gäste in den DATEV IT-Campus geladen waren (Abb. 1). Die Impulse waren für alle Teilnehmer sehr inspirierend.

Abb. 1: Auch beim weltweiten Lernevent Global Day of Coderetreat war die DATEV-Community dabei

Codequalität im Guten wie im Schlechten

Im Jahr 2012 hatte sich die Agile Community gegründet, die sich der Verbreitung agiler Methoden wie Scrum verschrieben hatte. Die Zusammenarbeit der beiden Communitys war von Anfang an intensiv, und 2014 riefen beide gemeinsam zu einem hausinternen Entwickler-Award auf. Einzelpersonen und Teams durften sich mit ihren Projekten bewerben, bewertet wurden verschiedene Kategorien wie agiles Projektmanagement, agile Entwicklungstechniken oder Codequalität. Neben der Ehrung dieser erfolgreichen Projekte ging es vor allem darum, Aufmerksamkeit für die Anliegen der beiden Communitys und auch für die Communitys selbst zu schaffen.

Doch bald folgte die Überlegung, dass die Ehrung von erfolgreichen Projekten sicher sinnvoll und wichtig sei, dass aber der Blick auf gescheiterte oder schlecht ausgeführte Projekte viel lehrreicher sein könnte. So kam es 2015 zum Code Skunk Award. Jeder Teilnehmer durfte einen eigenen Programmiercode einreichen und die seiner Meinung nach missratenen Aspekte vorstellen. Die Zuschauer sollten im Gegenzug auf die ihrer Ansicht nach positiven Aspekte eingehen.

Beide Awards waren sehr erfolgreich und haben viel Aufmerksamkeit auf die Communitys und ihre Anliegen gelenkt. Allerdings wurden sie 2016 eingestellt, da der Wettbewerbsgedanke zu sehr im Vordergrund stand und damit der Communitygeist infrage gestellt wurde. Der Code Skunk Award lebt heute jedoch als Bad Code Slam weiter.

Lesen Sie auch: Die DevOps-Kolumne auf JAXenter.de: DevOps Stories

Verbindlichkeit in die Community geben

Mittlerweile waren die Aktivitäten der Community so umfangreich und vielfältig, dass die bislang lose Organisationsstruktur des Netzwerks an ihre Grenzen stieß. Neben der Organisation von größeren Events wie Coderetreats, Coding Dojos und Awards geht es auch viel um gegenseitige Beratung, Weiterbildung und Austausch unter Kollegen. 2016 fand daher ein Strategietreffen der Community statt. Ein Ergebnis war die Entscheidung, ein festes Organisationsteam zu installieren. Auch von Seiten der Führung wurde das Engagement der Community honoriert und für mich eine neue Jobbeschreibung entwickelt, die auf die Leitung dieses Organisationsteams abzielt.

Ein zweiter Punkt aus dem Strategietreffen betraf die Frage, ob und wie sich die Community verbindlich in die Erarbeitung von unternehmensweiten Qualitätsstandards für die Softwareentwicklung einbringen kann. In der ersten Jahreshälfte 2016 war SonarQube eingeführt worden, eine Plattform für die statische Analyse der technischen Codequalität. Getreu dem Grundgedanken der Community ist die Nutzung von SonarQube freiwillig: Es ist ein Werkzeug für Mitarbeiter, das jeder im Rahmen seines Projekts verwenden kann oder auch nicht. Führungskräfte haben keinen Zugriff auf die Plattform, um jeglichem Zweifel bezüglich der Freiwilligkeit oder gar Vermutungen hinsichtlich versteckter Kontrollabsichten zu begegnen.

Die Plattform arbeitet mit einer Datenbank und Scannern, die für jede der gängigen Softwaresprachen wie C#, C++, Java, XML oder COBOL ein eigenes Regelwerk enthält. Wenn ein Mitarbeiter SonarQube im Rahmen seines Projekts verwendet, wird im Hintergrund der Code analysiert und mit dem Regelwerk abgeglichen. Bei Verstößen erhält der Nutzer eine Meldung mit Hinweisen, wie er diese beheben kann. Allerdings geht es bei der technischen Codequalität nicht zwangsläufig um richtig oder falsch, sondern häufig um ein einheitliches und nachvollziehbares Vorgehen im Sinne von Clean-Code-Prinzipien. Dementsprechend ist es notwendig, das Regelwerk an die Gepflogenheiten im Unternehmen anzupassen. Voraussetzung dafür ist, dass ein Konsens über das gewünschte Vorgehen existiert oder hergestellt wird. Die Verantwortung dafür war mir übertragen worden: Neben dem Einrichten des Servers war ich für das Regelwerk zuständig. Nur war mir aus verschiedenen Gründen nicht wohl dabei: Ich habe einige der Programmiersprachen noch nie verwendet, außerdem konnte ich mir nicht vorstellen, dass ein zentral vorgegebenes Regelwerk wirklich in der Entwicklergemeinschaft Anerkennung finden würde. Daher setzte ich einen basisdemokratischen Prozess über die Software Craftsmanship Community in Gang, um das Regelwerk auf die DATEV anzupassen. Das Ziel war, einen Austausch über die Regeln anzustoßen und damit auch ein gemeinsames Verständnis von guter Codequalität zu schaffen.

Zum Kick-off-Treffen kamen rund 40 Kolleginnen und Kollegen, die sich nach einer kurzen Einführung rege und intensiv an der Diskussion beteiligten. Ziel der Kick-off-Veranstaltung war es zunächst, die Rahmenbedingungen für den Prozess abzustimmen. Angesichts des zu erwartenden Aufwands, pro Sprache etwa 200 bis 400 Regeln hinsichtlich ihrer Relevanz und Anwendbarkeit auf die DATEV-Welt zu prüfen, musste ein möglichst effizientes Verfahren etabliert werden. Außerdem sollte größtmögliche Transparenz und Offenheit geschaffen werden, um die Akzeptanz für SonarQube und das Regelwerk bei den Entwicklern zu steigern.

So einigten wir uns darauf, zunächst alle Regeln zu aktivieren. Sobald ein Entwickler über einen Verstoß gegen eine Regel stolpert, mit dem er nicht einverstanden ist, kann er diese Regel zur Diskussion stellen. Wenn ein entsprechender Hinweis eingeht, wird ein zeitnaher Termin für eine Regelkonferenz aufgesetzt, um darüber zu entscheiden. Parallel wird eine Onlinediskussion zur jeweiligen Regel angelegt, um bereits im Vorfeld Gründe und Argumente zu sammeln, die auf der Regelkonferenz in die Entscheidung mit einfließen. Auf der Konferenz wird jeder Antrag inklusive Begründung vorgestellt. Es folgt sofort eine Abstimmung ohne weiteren Gedankenaustausch. Bei Stimmabgabe ohne Gegenstimme ist der Antrag entschieden, ansonsten folgt eine fünfminütige Diskussion mit erneuter Abstimmung. Bei dieser gilt dann das einfache Mehrheitsprinzip. Sowohl die Onlinediskussionen als auch die Regelkonferenzen sind für alle Entwickler offen. Jeder ist zum Mitmachen eingeladen. Auf einer Konferenz werden maximal 20 Regeln bearbeitet. Danach gilt für diese eine zweimonatige Quarantäne, bis sie erneut zur Diskussion gestellt werden können.

Innerhalb des ersten Monats wurden über 80 Regeln von der Community auf diesem Weg bearbeitet. An den Diskussionen und Regelkonferenzen haben sich etwa 90 Mitarbeiter beteiligt, die Resonanz auf die Aktion ist sehr positiv. Die Nutzungszahlen von SonarQube zeugen davon, dass die Regeln innerhalb der Entwicklergemeinde der DATEV eine hohe Akzeptanz finden.

Hohe Akzeptanz durch Mitmachprinzip

Die Entwicklung der Software Craftsmanship Community der DATEV ist ein anschauliches Beispiel dafür, welche positive Dynamik entstehen kann, wenn Mitarbeiter einfach mal machen dürfen. Der SonarQube-Prozess steht zwar erst am Anfang, aber die ersten Schritte zeugen von einer hohen Identifikation mit den dort getroffenen Entscheidungen. Gerade weil jeder die Gelegenheit hat, sich in den Prozess einzubringen, sind die Akzeptanz und die Bereitschaft zur Mitarbeit hoch.

Die DATEV hat so positive Erfahrungen damit gemacht, Communities zuzulassen und ihnen Verantwortung zu übertragen, dass mittlerweile allein in der Softwareentwicklung über 20 solcher Netzwerke bestehen. Sie organisieren gegenseitige Beratung, Austausch und auch mal den Blick über den Tellerrand. In den Communities wird der Transfer von Wissen auch außerhalb von organisierten Schulungen betrieben. Jenseits etablierter Bereichsgrenzen entstehen so auf unbürokratische Weise Netzwerke, die auch in der täglichen Arbeit viele Prozesse vereinfachen. Dabei geschieht alles, was in den Communitys passiert, auf freiwilliger Basis: Wer mitmacht, der macht es aus Überzeugung und weil er es für richtig hält. Sicher, es dauert länger, bis sich die Ideen durchsetzen. Aber dafür ist die Akzeptanz in der Belegschaft für den angestrebten Wandel enorm hoch. Die Mitarbeiter stehen voll dahinter, eben weil sie selbst an den Entscheidungen beteiligt und von ihnen überzeugt sind. Und der Spaßfaktor kommt dabei auch nicht zu kurz.

Geschrieben von
Andreas Christian Fischer
Andreas Christian Fischer
Andreas Christian Fischer ist seit dreißig Jahren Softwareentwickler mit Leidenschaft. Schon früh erkannte er die Bedeutung guten les- und damit wartbaren Sourcecodes. Er ist Gründer der DATEV-internen Software Craftsmanship Community, die möglichst viele Entwickler im Unternehmen von der Notwendigkeit technischer Exzellenz und professioneller Einstellung zum Job überzeugen möchte.
Kommentare

Schreibe einen Kommentar

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