In der aktuellen Corona-Krise ist verteiltes Arbeiten im Home Office nur eine der neuen Herausforderungen für Software-Teams. Jetzt kommt es darauf an, die Zeit optimal zu nutzen, um sich für den danach kommenden Neustart in die Poleposition zu bringen.
Erfahrungen bezüglich Homeoffice verraten, können Angehörige der Software-Branche darüber meist nur milde lächeln. Für sie ist die orts- und auch zeitunabhängige Zusammenarbeit schon lange Teil des Arbeitsalltags. Spätestens mit dem Platzen der Dotcom-Blase ist der massive Outsourcing-Trend nämlich einem flexiblen Nearshoring gewichen, in dem die lokalen Software-Teams nach Bedarf um weitere Mitglieder ergänzt werden, die dann eben virtuell anwesend sind.
An unsauber programmierten Code-Stellen geht später bei jeder Anpassung wertvolle Entwicklungszeit verloren.
Auf diesen Erfahrungen lässt sich jetzt aufbauen, wenn es darum geht, ganze Teams auf Home Offices zu verteilen. Der wesentliche Unterschied ist nur noch, dass es kein zentrales Kernteam mehr gibt, das gemeinsam in einem Büro arbeitet. Damit entfällt die Zusammenarbeit auf Zuruf und per White Board, wie Abstimmungsprozesse klassisch stattgefunden haben. Auch per E-Mail oder Telefon, die in der Anfangszeit virtueller Teams zum Einsatz kamen, wird heute kaum noch kommuniziert.
Stattdessen kommen dedizierte Werkzeuge für die einzelnen Teilaufgaben zum Einsatz. Als schnelles Kommunikationsmittel zwischen Entwicklern hat sich das Messaging- und Collaboration-Tool Slack etabliert, das sich auch mit unternehmensweit bestehenden Lösungen wie Teams, Zoom und Jabber integrieren lässt. Zur Fehlerverwaltung, Problembehandlung und für das operative Projektmanagement wird vielfach Jira vom Confluence-Hersteller Atlassian eingesetzt. Und natürlich werden die üblichen Entwicklungswerkzeuge vom Anforderungsmanagement bis zum Code-Repository genutzt.
Wer so ausgerüstet ist, kann auch vollständig verteilt seine Arbeit recht gut organisieren – zumal, wenn agile Methoden wie Scrum oder Kanban zum Einsatz kommen. Dann bedienen sich die Entwickler einfach an einem zentralen Stapel der Anforderungen, sogenannter „User Stories“, und arbeiten diese eigenständig ab. Abstimmungsbedarf untereinander klären sie per Collaboration, der Arbeitsfortschritt wird in Jira dokumentiert, fertiger Code im Repository eingecheckt.
„Alle diese Probleme sind im Detail sehr gut gelöst“, befindet Prof. Jürgen Döllner vom Hasso-Plattner-Institut für Digital Engineering (HPI) in Potsdam. „Nur will es schon bei normalem Arbeiten kaum gelingen, den Überblick über den Gesamtprozess von einem Ende bis zum anderen zu behalten. In einer virtualisierten Organisation, in der die Beteiligten nicht mehr beieinandersitzen, wird das endgültig unmöglich.“ Schließlich kann der Gruppenleiter nicht wahrnehmen, welcher seiner Entwickler sich vielleicht gerade schwertut, der Teamleiter weiß nicht, welche User Stories liegen bleiben und verstauben, und unterm Strich kann der Software-Verantwortliche nicht sagen, wo der Delivery-Prozess gerade steht. „Diesen dringend benötigen Gesamtüberblick bringt erst der Einsatz von Software Analytics“, erläutert Döllner. „Die unzähligen Datenspuren, die bei der Software-Entwicklung entstehen, zu analysieren und mit Künstlicher Intelligenz die richtigen Schlüsse daraus zu ziehen, ist in dieser Situation unbezahlbar.“ Im Ergebnis müssen die Verantwortlichen nicht mehr auf punktuelle Schlaglichter wie etwa die täglichen Standup-Reports verlassen. Stattdessen haben sie in einem „Digital Boardroom“, wie ihn die Seerene Software Analytics Platform zur Verfügung stellt, den tatsächlichen Stand des Entwicklungsprozesses jederzeit im Überblick. Damit verfügen sie dann auch über eine fundierte Grundlage, um ein Team von Homeoffice-Arbeitern zu steuern.
Allerdings sind in der Krise nicht alle Teammitglieder in gleichem Maße einsatzfähig. Ohnehin mangelt es vielen Haushalten an einem voll eingerichteten Arbeitszimmer, in dem eine oder gar mehrere Personen ablenkungsfrei arbeiten können. Wenn dann noch Kinderbetreuung oder Home-Schooling erforderlich werden, die Sorge um Angehörige aus einer Risiko-Gruppe und schlimmstenfalls eine eigene Erkrankung hinzukommen, müssen im Zweifelsfall die Kollegen einspringen.
Wenn sie das überhaupt können. Immerhin bestehen in komplexen Software-Projekten oft Wissensmonopole, also Bereiche der Code-Base, in denen sich jeweils nur ein einzelner Experte auskennt. Solang der betreffende Code keine lange Einarbeitungszeit erfordert, mag das noch akzeptabel sein. Aber spätestens bei komplexem Code, der eine lange Einarbeitungszeit erfordert, bis ein anderer Entwickler ihn durchdringt, herrscht sofortiger Handlungsbedarf: Dieses Wissen muss besser früher als später auf mehrere Schultern verteilt werden. Sowohl bei der Identifizierung solcher Wissensmonopole als auch bei der Priorisierung nach Code-Komplexität kann Software Analytics wiederum wertvolle Dienste leisten.
Vielerorts ist momentan das Tagesgeschäft beeinträchtigt und die Fachabteilungen haben andere wichtigere Prioritäten, als neue Wünsche an die IT zu formulieren. Wenn der Anforderungsdruck an die Entwickler sinkt, entstehen möglicherweise neue Freiräume für grundlegende Aufgaben, die im Tagesgeschäft sonst zu kurz gekommen sind – etwa die Beseitigung von Altlasten. Einen offensichtlichen Ansatzpunkt bilden technische Schulden, wie sie immer dann aufgenommen wurden, wenn Entwickler unter Zeitdruck von den eigentlich getroffenen Vereinbarungen abweichen mussten. In der Folge geht an solchen unsauber programmierten Code-Stellen bei jeder Anpassung wertvolle Entwicklungszeit verloren und die Fehlerwahrscheinlichkeit steigt. Primär lohnt es sich also, technische Schulden an Code-Stellen zu beseitigen, die von häufigen Anpassungen betroffen sind.
Wer die Knackpunkte seiner Code-Base gut kennt, kann das Sicherheitsnetz obendrein durch automatisierte Tests enger knüpfen. Das ist viel Aufwand, den man nur dort investieren sollte, wo es sich wirklich auszahlt. Der Schlüssel zur Identifikation der fehlerträchtigen Stellen ist auch hier wieder die Komplexität des Codes, die sich mit Methoden der Software Analytics leicht darstellen lässt. Denn schließlich sollen die Maßnahmen nicht nach Bauchgefühl mit der Gießkanne verteilt werden. Vielmehr gilt es, ganz gezielt dort anzusetzen, wo der Effekt am größten ist, weil heute Reibungsverluste oder Risiken bestehen.
„Statt ihre Software-Teams weiterhin mit Methodiken des letzten Jahrhunderts operieren zu lassen, muss es für die Unternehmen jetzt darum gehen, den komplexen Herstellungsprozess von Software mit Analytics und Data Mining datenbasiert zu unterstützen“, fasst Prof. Döllner zusammen. So legen sie ein stabiles Fundament, von dem aus sie erfolgreich durchstarten können, sobald der Markt wieder anzieht.
Original article in German published in "IT Director".
