Ports and Adapters ‚Äď Die hexagonale Zwiebelarchitektur. Teil 1: Einf√ľhrung

Soft¬≠warearchitek¬≠tur ver¬≠fol¬≠gt im wesentlichen zwei Ziele: die Struk¬≠turierung von Soft¬≠waresys¬≠te¬≠men und die Min¬≠imierung von Abh√§ngigkeit¬≠en zwis¬≠chen den Struk¬≠turkom¬≠po¬≠nen¬≠ten, den soge¬≠nan¬≠nten Bausteinen. Sp√§testens seit den Neun¬≠ziger¬≠jahren war das Mul¬≠ti-Tier-Pat¬≠tern, die klas¬≠sis¬≠che Schicht¬≠e¬≠nar¬≠chitek¬≠tur, der Stand der Kun¬≠st. Seit eini¬≠gen Jahren wird dieses Grund¬≠muster zunehmend durch einen neuen De-fac¬≠to-Stan¬≠dard abgel√∂st, der als Hexag¬≠o¬≠nale Architek¬≠tur bekan¬≠nt gewor¬≠den ist. Was hat es mit diesem mys¬≠tis¬≠chem Begriff auf sich, und welche Vorteile bringt dieser Architek¬≠turstil f√ľr die Softwareentwicklung?

Im ersten Teil dieser Artikelserie geht es darum, die Begriffe zu kl√§ren und den prinzip¬≠iellen Auf¬≠bau ein¬≠er Hexag¬≠o¬≠nalen Architek¬≠tur zu ver¬≠ste¬≠hen. Doch zun√§chst machen wir einen kleinen Aus¬≠flug in die Entste¬≠hungs¬≠geschichte dieses pop¬≠ul√§ren Mikroarchitekturmusters. 

Historische Entwicklung

Alistair Cockburn, 2005

Der Begriff der Hexag¬≠o¬≠nalen Architek¬≠tur wurde im Jahre 2005 von Alis¬≠tair Cock¬≠burn gepr√§gt, einem der Mitze¬≠ich¬≠n¬≠er des Agilen Man¬≠i¬≠fests. Das Wort ‚Äěhexag¬≠o¬≠nal‚Äú beschreibt dabei lediglich die von Cock¬≠burn gew√§hlte grafis¬≠che Darstel¬≠lung der von ihm vorgeschla¬≠ge¬≠nen Mikroarchitektur:

Quelle: alistair.cockburn.us

Cock¬≠burns Ansatz sieht die strik¬≠te Tren¬≠nung von innerem Code und √§u√üerem Code vor, wobei innen den Anwen¬≠dungskern meint, also den Teil des Codes, der die Gesch√§ft¬≠slogik enth√§lt. Um diesen Kern herum, also au√üen, sind die tech¬≠nis¬≠chen Code¬≠teile ange¬≠ord¬≠net, welche den Gesch√§ftskern mit der √§u√üeren Welt verbinden. Die Au√üen¬≠welt, das sind beispiel¬≠sweise Brows¬≠er-UIs, Mobile-Apps, Mail-Clients, Daten¬≠banken, Mes¬≠sage-Bro¬≠ker usw., wor√ľber die Anwen¬≠dung mit Benutzern oder anderen Sys¬≠te¬≠men Infor¬≠ma¬≠tio¬≠nen austauscht.

Jeffrey Palermo, 2008

Kurze Zeit sp√§ter ver√∂f¬≠fentlichte Jef¬≠frey Paler¬≠mo seinen Vorschlag zur Struk¬≠turierung von Soft¬≠waresys¬≠te¬≠men, den er Onion Archi¬≠tec¬≠ture nan¬≠nte. Als Darstel¬≠lung w√§hlte er konzen¬≠trische Kreise, √§hn¬≠lich den Schicht¬≠en ein¬≠er Zwiebel: 

Quelle: jeffreypalermo.com

Paler­mo tren­nt eben­falls tech­nis­chen von fach­lichem Code, wobei der App­lika­tionskern expliz­it weit­er unterteilt wird: das Object Mod­el fungiert als Zen­trum, um das herum sich die Object Ser­vices und Appli­ca­tion Ser­vices anord­nen. Die Object-Ser­vice-Schicht definiert dabei die tech­nis­chen Inter­faces, die vom äußeren Infra­struc­ture-Lay­er imple­men­tiert wer­den. Hier begeg­net uns das Depen­den­cy Inver­sion Prin­ci­ple (DIP).

Mike Evans, 2004

Viele Grund¬≠la¬≠gen der mod¬≠er¬≠nen Soft¬≠wa¬≠reen¬≠twick¬≠lung wur¬≠den bere¬≠its 2004 von Eric Evans dargelegt bzw. best√§tigt. Sein Buch Domain Dri¬≠ven Design beschreibt eine an fach¬≠lichen Gesicht¬≠punk¬≠ten aus¬≠gerichtete Meth¬≠ode, die einen gewis¬≠sen inneren Auf¬≠bau der entwick¬≠el¬≠ten Kom¬≠po¬≠nen¬≠ten impliziert. Das Ziel ist auch hier, fach¬≠lichen von tech¬≠nis¬≠chem Code zu trennen. 

Quelle: www.ajlopez.com

Evans schl√§gt eine Aufteilung nach Schicht¬≠en mit strik¬≠ten Ver¬≠ant¬≠wortlichkeit¬≠en und definierten Abh√§ngigkeit¬≠en vor, wobei der Domain-Lay¬≠er die zen¬≠trale Gesch√§ft¬≠skom¬≠po¬≠nente darstellt. Dieser Domain Core hat selb¬≠st keine direk¬≠ten Abh√§ngigkeit¬≠en zu anderen Kom¬≠po¬≠nen¬≠ten. Auch hier wieder DIP: der Domain Core definiert die Inter¬≠faces, die vom Infra¬≠struc¬≠ture-Lay¬≠er imple¬≠men¬≠tiert werden. 

Die Ans√§tze aller drei Autoren sind sich in ihrem Wesen √§hn¬≠lich. Zusam¬≠mengenom¬≠men definieren sie eine mod¬≠erne Mikroar¬≠chitek¬≠tur, die sowohl f√ľr den ‚Äěaltherge¬≠bracht¬≠en‚Äú Mono¬≠lithen als auch bei mod¬≠er¬≠nen Microser¬≠vices anwend¬≠bar ist. 

Begriffsverwirrung ‚ÄĒ Hexagonal? Domain Driven? Onion?

Die Namen Hexag¬≠o¬≠nale Architek¬≠tur, Zwiebel-Architek¬≠tur und Domain Dri¬≠ven Design (kurz DDD) wer¬≠den im All¬≠t¬≠ags¬≠ge¬≠brauch oft syn¬≠onym ver¬≠wen¬≠det. Die Beze¬≠ich¬≠nung Hexag¬≠o¬≠nal hat sich jedoch durchge¬≠set¬≠zt, um dieses Architek¬≠tur¬≠muster zu beschreiben. Zum einen ver¬≠mut¬≠lich, weil es so sch√∂n eso¬≠ter¬≠isch klingt, ohne jedoch K√ľchenas¬≠sozi¬≠a¬≠tio¬≠nen zu weck¬≠en. Zum anderen ist DDD in sein¬≠er Gesamtheit mehr als Methodik zu ver¬≠ste¬≠hen, ist daher viel bre¬≠it¬≠er gefasst und geht √ľber die reine Struk¬≠turierung von Soft¬≠ware-Bausteinen hinaus.

Hexagonale Architektur: Definition der Begriffe

Ports

Ein Port definiert logisch zusam¬≠menge¬≠h√∂rige Use Cas¬≠es und die daf√ľr ben√∂tigten Schnittstellen.

In der fol¬≠gen¬≠den Abbil¬≠dung sind beispiel¬≠sweise diese Schnittstellen definiert (Beispiele √ľber¬≠nom¬≠men von Cock¬≠burn, s.o.):

  1. Daten­ver­ar­beitung
  2. Admin­is­tra­tion
  3. Events/Notifications (nach au√üen) 
  4. Daten­bank­abfra­gen.
Abb.: Ports definieren die Schnittstellen zur Außenwelt

Auf der linken Seite des Hexa­gons sehen wir die aktiv­en Ports (1) und (2), während (3) und (4) auf der recht­en Seite als pas­sive Ports ange­ord­net sind. Aktive und pas­sive Ports bilden zusam­men den Infra­struc­ture Lay­er, also den Teil der Anwen­dung, der mit der Außen­welt kommuniziert.

Aktive und passive Ports

√úber die aktiv¬≠en Ports, die nach au√üen sicht¬≠bar sind, wer¬≠den √Ąnderun¬≠gen in der App¬≠lika¬≠tion angesto√üen. Men¬≠schliche Benutzer oder tech¬≠nis¬≠che Clients greifen √ľber die √∂ffentlichen Schnittstellen aktiv in den Zus¬≠tand der Anwen¬≠dung ein. Aktive Ports wer¬≠den auch als Prim√§r¬≠ports oder Inbound Ports bezeichnet.

Dahinge­gen sind die pas­siv­en Ports nicht von außer­halb der Anwen­dung zugänglich. Über sie kann nur die Anwen­dung selb­st auf andere Sys­teme lesend oder schreibend zugreifen und die erhal­te­nen Antworten inner­halb ihrer eige­nen Geschäft­sprozesse ver­ar­beit­en. Die Ver­wen­dung dieser Ports erfol­gt somit pas­siv. Über die pas­siv­en Ports kann keine direk­te Inter­ak­tion mit der Anwen­dung erfol­gen. Pas­sive Ports sind auch als Sekundär­ports oder Out­bound Ports bekan­nt.

Port = Schnittstelle + Datentransport

Die Ports ein¬≠er Soft¬≠ware¬≠an¬≠wen¬≠dung beste¬≠hen aus ein¬≠er Schnittstel¬≠len¬≠spez¬≠i¬≠fika¬≠tion und dem tech¬≠nis¬≠chen Teil der Imple¬≠men¬≠tierung, der Daten¬≠struk¬≠turen in die Anwen¬≠dung hinein und hin¬≠aus transportiert. 

ISP ‚Äď Interface Segregation Principle

Pas¬≠sive Ports bilden nicht die kom¬≠plette Schnittstelle des exter¬≠nen Sys¬≠tems ab, son¬≠dern nur genau den Teil, der von der App¬≠lika¬≠tion ger¬≠ade ben√∂tigt wird. So w√ľrde der Noti¬≠fi¬≠ca¬≠tion-Port (Nr. 3 in der obi¬≠gen Abbil¬≠dung) lediglich den Teil der Mailserv¬≠er-API nutzen, der zum Versenden von E‚ÄĎMails ben√∂tigt wird. Das zuge¬≠h√∂rige DTO enth√§lt dann auch nur die Attribute, die tat¬≠s√§ch¬≠lich f√ľr den Mail¬≠ver¬≠sand rel¬≠e¬≠vant sind. Wer¬≠den beispiel¬≠sweise die Felder CC und BCC nicht ben√∂tigt, wird das DTO sie nicht enthalten.

Adapters

Adapter fungieren als Ver¬≠mit¬≠tler zwis¬≠chen Sys¬≠te¬≠men mit unter¬≠schiedlichen Schnittstellen. 

In der abstrak¬≠ten Welt der Soft¬≠waretech¬≠nik dienen Adapter dazu, Daten¬≠struk¬≠turen aus Fremdsys¬≠te¬≠men in das eigene Sys¬≠tem zu √ľber¬≠f√ľhren, zu adap¬≠tieren, und zwis¬≠chen bei¬≠den Dom√§¬≠nen hin- und her zu transformieren. 

Primäre und sekundäre Adapter

Zu einem Port gibt es einen oder mehrere Adapter. Aktive Ports enthal¬≠ten prim√§re Adapter, das sind die Con¬≠troller der Anwen¬≠dung. √úber sie gelan¬≠gen Anweisun¬≠gen und Dat¬≠en von au√üen zum Anwen¬≠dungskern, um dort die Gesch√§ft¬≠slogik auszuf√ľhren und Antworten zu erhalten.

Die sekund√§ren Adapter der pas¬≠siv¬≠en Ports wer¬≠den vom Anwen¬≠dungskern genutzt, um externe Sys¬≠teme einzu¬≠binden. Beispiel¬≠sweise andere Microser¬≠vices, Mes¬≠sag¬≠ing- oder Stor¬≠agesys¬≠teme, wie die fol¬≠gen¬≠den Grafik ver¬≠an¬≠schaulicht. Sekund√§radapter imple¬≠men¬≠tieren immer genau den Teil der exter¬≠nen Schnittstelle, der vom Anwen¬≠dungskern ben√∂tigt wird ‚Äď auch hier wieder ISP.

Abb.: Primäre und sekundäre Adapter

Zu beacht­en ist hier­bei die Rich­tung der Abhängigkeit­en: Primäre Adapter rufen den Anwen­dungskern, dieser ken­nt jedoch die primären Adapter nicht. Sekundäre Adapter wer­den vom Anwen­dungskern benutzt, ken­nen diesen jedoch selb­st nicht. Die Aufrufhier­ar­chie im Hexa­gon geht also von links nach rechts, wie fol­gen­des Bild veranschaulicht:

Abb.: Die Aufrufhier­ar­chie im Hexagon

Application

Der Appli­ca­tion-Ring im Hexa­gon markiert die Verbindungss­chicht zwis­chen der Infra­struk­tur und dem Domainkern. Hier resi­diert die App­lika­tion­slogik. Das ist der Teil der Logik, der nicht die Geschäft­sregeln bein­hal­tet, wohl aber die Use Cas­es anstößt und koor­diniert. Außer­dem sind hier die tech­nis­chen Belange der App­lika­tion abge­bildet, beispiel­sweise Secu­ri­ty, Log­ging, Daten­bank­transak­tio­nen oder Ses­sion­han­dling. Bei der vielz­i­tierten Tren­nung von Tech­nik und Fach­lichkeit kommt dem Appli­ca­tion­lay­er eine entschei­dende Bedeu­tung zu. Es sind in erster Lin­ie die Appli­ca­tion Ser­vices, die seine Sub­stanz bilden.

Application Service

Appli¬≠ca¬≠tion Ser¬≠vices definieren die Ein¬≠stiegspunk¬≠te f√ľr Use Cas¬≠es und koor¬≠dinieren deren Abl√§ufe. 

Abb.: Der Appli­ca­tion Lay­er mit seinen Appli­ca­tion Services

Ein Appli¬≠ca¬≠tion Ser¬≠vice wird von einem Prim√§radapter, also einem Con¬≠troller aufgerufen. Der Appli¬≠ca¬≠tion Ser¬≠vice gibt den Aufruf an den Domain Core weit¬≠er und st√∂√üt dadurch den zuge¬≠h√∂ri¬≠gen Use Case an. Zusam¬≠men¬≠h√§n¬≠gende Use Cas¬≠es wer¬≠den vom Appli¬≠ca¬≠tion Ser¬≠vice koor¬≠diniert, einzelne Ergeb¬≠nisse wer¬≠den zu Antworten aggregiert und erforder¬≠liche Events, z.B. Mail¬≠ver¬≠sand oder Noti¬≠fi¬≠ca¬≠tions f√ľr andere Ser¬≠vices, wer¬≠den angetrig¬≠gert. Wo n√∂tig, kom¬≠mu¬≠niziert der Appli¬≠ca¬≠tion Ser¬≠vice mit den Sekund√§radaptern der pas¬≠siv¬≠en Ports, um beispiel¬≠sweise Enti¬≠tys aus einem Daten¬≠bankrepos¬≠i¬≠to¬≠ry oder von ein¬≠er ent¬≠fer¬≠n¬≠ten REST-API zu laden, die f√ľr den Ablauf des Use Cas¬≠es ben√∂tigt wer¬≠den. Wie bere¬≠its erw√§h¬≠nt ‚Äď man sollte es oft genug wieder¬≠holen ‚Äď enth√§lt der Appli¬≠ca¬≠tion Ser¬≠vice selb¬≠st keine Gesch√§ftslogik.

Domain Core

Der Domain Core ist der fach¬≠liche Kern der App¬≠lika¬≠tion. Er enth√§lt die fach¬≠liche Imple¬≠men¬≠tierung der Use Cas¬≠es mit der auszuf√ľhren¬≠den Gesch√§ft¬≠slogik. Au√üer¬≠dem die Imple¬≠men¬≠tierung der Fachk¬≠lassen, das soge¬≠nan¬≠nte Domain Mod¬≠el.

Abb. Der Domain Core im Hexa­gon mit Domain Mod­el und Domain Ser­cvices

Domain Model

Das Domain Mod¬≠el bein¬≠hal¬≠tet im Wesentlichen die in dem fach¬≠lichen Kon¬≠text ‚Äď Bound¬≠ed Con¬≠text im DDD-Jar¬≠gon ‚Äď iden¬≠ti¬≠fizierten Entit√§ten. Diese bilden den eigentlichen Kern der App¬≠lika¬≠tion. Hier ist das Wis¬≠sen der Fach¬≠dom√§ne enthal¬≠ten, soweit es zur Durch¬≠f√ľhrung der abzu¬≠bilden¬≠den Use Cas¬≠es erforder¬≠lich ist. Im Domain Dri¬≠ven Design ist das Domain Mod¬≠el das Herzst√ľck der Soft¬≠ware. Appli¬≠ca¬≠tion- und Infra¬≠struc¬≠ture¬≠lay¬≠er wer¬≠den um den Domainkern herum ange¬≠ord¬≠net und sind vom diesem abh√§ngig, nicht umgekehrt. Die Darstel¬≠lung als konzen¬≠trisches Hexa¬≠gon ist dazu geeignet, dieses wichtige Grund¬≠prinzip eing√§ngig zu visu¬≠al¬≠isieren. Gesch√§ft¬≠slogik ist im Rich Domain Mod¬≠el in den Meth¬≠o¬≠d¬≠en der Fachk¬≠lassen imple¬≠men¬≠tiert. Solche Teile der Logik, die kein¬≠er Fachk¬≠lasse direkt zuge¬≠ord¬≠net wer¬≠den k√∂n¬≠nen, wer¬≠den in Domain Ser¬≠vices ausgelagert.

Domain Services

Die Domain Ser¬≠vices enthal¬≠ten √ľber¬≠greifende Gesch√§ft¬≠slogik, die nicht eins-zu-eins auf Fachk¬≠lassen abge¬≠bildet wer¬≠den kann. Domain Ser¬≠vices wer¬≠den vom Appli¬≠ca¬≠tion-Lay¬≠er, genauer von den dor¬≠ti¬≠gen Appli¬≠ca¬≠tion Ser¬≠vices aufgerufen. Ein Domain Ser¬≠vice darf direk¬≠ten Zugriff auf die Infra¬≠struc¬≠ture haben und deren pas¬≠sive Adapter benutzen. Hier¬≠bei ist allerd¬≠ings abzuw√§¬≠gen, ob dies wirk¬≠lich notwendig ist, oder ob der Aufruf bess¬≠er in den Appli¬≠ca¬≠tion Lay¬≠er zu ver¬≠lagern w√§re. 

Im ersten Fall kann der Domain Lay¬≠er ein DIP-Inter¬≠face bere¬≠it¬≠stellen, um den Adapter von der Domain zu entkop¬≠peln. Fern¬≠er ist darauf zu acht¬≠en, dass keine Infra¬≠struc¬≠ture-Depen¬≠den¬≠cys in die Domain hineinge¬≠zo¬≠gen wer¬≠den, beispiel¬≠sweise √ľber R√ľck¬≠gabe¬≠w¬≠erte des Adapters.

Im zweit¬≠en Fall w√ľrde der Appli¬≠ca¬≠tion Ser¬≠vice mit der Infra¬≠struc¬≠ture kom¬≠mu¬≠nizieren und das Ergeb¬≠nis des Aufrufs in ad√§quater Form an die Domain √ľbergeben. Diese Vari¬≠ante sollte bevorzugt einge¬≠set¬≠zt wer¬≠den, es sei denn, prag¬≠ma¬≠tis¬≠che Gr√ľnde sprechen f√ľr den anderen Weg.

Abhängigkeiten und Aufrufhierarchien

Das Hexa¬≠gon beste¬≠ht aus zwei logis¬≠chen H√§lften, der linken aktiv¬≠en Seite und der pas¬≠siv¬≠en recht¬≠en. In der Abbil¬≠dung ist zu erken¬≠nen, dass Aufrufe nur in eine Rich¬≠tung gehen, und zwar von links nach rechts. Niemals w√ľrde ein pas¬≠siv¬≠er Adapter einen Appli¬≠ca¬≠tion Ser¬≠vice aufrufen, oder dieser einen aktiv¬≠en Adapter. Solche Calls sind strikt verboten. 

Die Abh√§ngigkeit¬≠en der Schicht¬≠en gehen immer von au√üen nach innen. Allerd¬≠ings gibt es keine Depen¬≠den¬≠cy von dem pas¬≠siv¬≠en Teil des Infra¬≠struc¬≠ture Lay¬≠ers zum Appli¬≠ca¬≠tion Layer. 

Abb.: Aufrufhier­ar­chien und Abhängigkeit­en zwis­chen den Grund­bausteinen des Hexagons

Somit lässt sich zusammenfassen:

  • Jed¬≠er Baustein kann eine Depen¬≠den¬≠cy zum Domain Mod¬≠el haben. 
  • Die Benutzung der Gesch√§ft¬≠slogik bleibt jedoch den Appli¬≠ca¬≠tion Ser¬≠vices vorbehalten.
  • Appli¬≠ca¬≠tion Ser¬≠vices k√∂n¬≠nen sowohl die Sekund√§radapter der pas¬≠siv¬≠en Ports als auch die Domain Ser¬≠vices benutzen.
  • Domain Ser¬≠vices k√∂n¬≠nen Sekund√§radapter benutzen, wenn dies aus prag¬≠ma¬≠tis¬≠chen Gr√ľn¬≠den sin¬≠nvoll erscheint.
  • Das Domain Mod¬≠el hat kein¬≠er¬≠lei Abh√§ngigkeit¬≠en zu anderen Bausteinen.

Ausblick

Im n√§ch¬≠sten Teil tauchen wir tiefer in die einzel¬≠nen Ringe hinein und definieren deren Inhalte im Detail. Weit¬≠er¬≠hin m√ľssen wir eini¬≠gen Fra¬≠gen nachge¬≠hen, die bei der Umset¬≠zung eines Architek¬≠tur¬≠musters immer wieder gestellt wer¬≠den. Zum Beispiel, was ist Busi¬≠ness¬≠logik, was ist Anwen¬≠dungslogik, und worin unter¬≠schei¬≠den sie sich? In welchem Teil des Hexa¬≠gons wer¬≠den Domain¬≠ob¬≠jek¬≠te erzeugt, die sich aus Dat¬≠en von mehreren Drittsys¬≠tem zusam¬≠menset¬≠zen? Wo wer¬≠den Quer¬≠schnitts¬≠the¬≠men wie Daten¬≠va¬≠li¬≠dierung, Excep¬≠tion¬≠han¬≠dling, Log¬≠ging usw. imple¬≠men¬≠tiert? Und was zur H√∂lle ist im recht¬≠en Teil des Application-Rings?

Es bleibt also span¬≠nend. Bis dahin, hap¬≠py engineering ūüôā

‚ÄěPat¬≠terns are use¬≠ful because it gives soft¬≠ware pro¬≠fes¬≠sion¬≠als a com¬≠mon vocab¬≠u¬≠lary with which to communicate. ‚Äú

Jef­frey Palermo

Stiller Killer #2: Fluktuation

In der Soft¬≠wa¬≠reen¬≠twick¬≠lung k√∂n¬≠nen Zust√§nde entste¬≠hen, die den Pro¬≠jek¬≠ter¬≠folg verz√∂gern, gef√§hrden oder g√§n¬≠zlich unm√∂glich machen. Schon manch¬≠es Pro¬≠jekt musste wegen man¬≠gel¬≠nden Bewusst¬≠seins √ľber solche Risiken wieder¬≠holt neu aufge¬≠set¬≠zt oder g√§n¬≠zlich begraben wer¬≠den. Selb¬≠st dann jedoch bleiben die Ursachen h√§u¬≠fig im Ver¬≠bor¬≠ge¬≠nen. Ich nenne sie daher stille Killer ‚Äď die unerkan¬≠nte, zuweilen auch nur unter¬≠sch√§tzte Gefahr.

Die Fluk¬≠tu¬≠a¬≠tion inner¬≠halb von Soft¬≠wa¬≠reen¬≠twick¬≠lung¬≠steams scheint oft¬≠mals nicht als beson¬≠ders beacht¬≠enswert wahrgenom¬≠men zu wer¬≠den. Vielmehr wird das Kom¬≠men und Gehen von Mitar¬≠beit¬≠ern als etwas Nat√ľr¬≠lich¬≠es, ‚ÄěGottgegebenes‚Äú meist rel¬≠a¬≠tiv gelassen hin¬≠genom¬≠men. Der Aufwand, das abge¬≠wan¬≠derte Per¬≠son¬≠al zu erset¬≠zen, ist zwar ein Wer¬≠mut¬≠stropfen. Den¬≠noch agiert man im Per¬≠sonal¬≠man¬≠age¬≠ment allzu h√§u¬≠fig nach der Maxime jed¬≠er ist erset¬≠zbar. Und auf rein biol¬≠o¬≠gis¬≠ch¬≠er Ebene stimmt das sog¬≠ar. Auf Entwick¬≠lung¬≠steams angewen¬≠det jedoch kann diese Ein¬≠stel¬≠lung eine zer¬≠st√∂rerische Wirkung zeitigen. 

Tat¬≠sache ist, solange sich der Aus¬≠tausch von Team¬≠mit¬≠gliedern in ertr√§glichen Gren¬≠zen bewegt, bleibt es unprob¬≠lema¬≠tisch. Die Mei¬≠n¬≠un¬≠gen dar√ľber, wo die Gren¬≠ze liegt, gehen jedoch auseinan¬≠der. Auch wird die Ein¬≠sch√§tzung, ob die Fluk¬≠tu¬≠a¬≠tion¬≠srate eines Unternehmens hoch oder niedrig ist, nicht anhand absoluter Gr√∂√üen getrof¬≠fen. Vielmehr wer¬≠den zur Beurteilung Ver¬≠gle¬≠ich¬≠swerte wie die branchen√ľbliche Fluk¬≠tu¬≠a¬≠tion und die Kon¬≠junk¬≠tur herange¬≠zo¬≠gen. Gehaltsstufen und T√§tigkeit¬≠sebe¬≠nen wirken sich eben¬≠falls aus. Im Gast¬≠gewerbe beispiel¬≠sweise sind die Aus¬≠tauschzyklen von Ser¬≠vicemi¬≠tar¬≠beit¬≠ern h√∂her als bei Fachar¬≠beit¬≠ern im Maschinenbau. 

Rein sta¬≠tis¬≠tisch betra¬≠chtet ist es sin¬≠nvoll, die eigene Fluk¬≠tu¬≠a¬≠tion¬≠srate im Ver¬≠gle¬≠ich mit anderen zu bew¬≠erten. Nichts¬≠destotrotz gel¬≠ten f√ľr Soft¬≠wareteams engere Ausle¬≠gun¬≠gen, denn Soft¬≠wa¬≠reen¬≠twick¬≠lung ist Wis¬≠sensar¬≠beit. Ein Soft¬≠wa¬≠reen¬≠twick¬≠lung¬≠steam lebt davon, langfristig Wis¬≠sen aufzubauen. Das Kon¬≠den¬≠sat dieses Wis¬≠sens schl√§gt sich schlie√ülich direkt in der G√ľte der erzeugten Pro¬≠duk¬≠te nieder. Je nach Kom¬≠plex¬≠it√§t von Fach¬≠lichkeit und Tech¬≠nik steigt somit der Wert des Teams, und damit jedes einzel¬≠nen Mitar¬≠beit¬≠ers, mit der Dauer der Teamzuge¬≠h√∂rigkeit. An diesem Punkt l√∂st sich der alte Traum der Per¬≠son¬≠al¬≠wirtschaft, jed¬≠er Mitar¬≠beit¬≠er sei erset¬≠zbar, in Luft auf ‚Äď ob wir es nun wahrhaben wollen oder nicht. 

Ein Beispiel

Das fol¬≠gende Beispiel ist aus der Real¬≠it√§t gegrif¬≠f¬≠en, die Namen sind aus Daten¬≠schutz¬≠gr√ľn¬≠den frei erfun¬≠den. Betra¬≠chtet wird das Jahr 2019, das Entwick¬≠lung¬≠steam z√§hlt zu Jahres¬≠be¬≠ginn sieben Mit¬≠glieder. √úber die Monate sind mehrere Abg√§nge zu bekla¬≠gen, aber auch Neuzug√§nge zu begr√ľ√üen. Abge¬≠hende Mitar¬≠beit¬≠er sind in der fol¬≠gen¬≠den Darstel¬≠lung rot markiert, hinzugekommene gr√ľn. Es l√§sst sich fest¬≠stellen, dass die Team¬≠gr√∂√üe am Jahre¬≠sende unver√§n¬≠dert ist. Allerd¬≠ings haben sich die Namen stark ver√§n¬≠dert, lediglich zwei Mitar¬≠beit¬≠er sind bis zum Jahre¬≠sende dabeigeblieben:

Abb.: Fluk­tu­a­tion eines Teams im Jahr 2019 (Beispiel)

Berechnung der Fluktuationsrate

Zur Berech¬≠nung der Fluk¬≠tu¬≠a¬≠tion¬≠srate wer¬≠den die Para¬≠me¬≠ter Team¬≠gr√∂√üe, Zug√§nge und Abg√§nge miteinan¬≠der in Beziehung geset¬≠zt. Hier¬≠f√ľr gibt es ver¬≠schiedene Formeln, die je nach Sit¬≠u¬≠a¬≠tion zu unter¬≠schiedlichen Ergeb¬≠nis¬≠sen f√ľhren k√∂n¬≠nen. Bei unserem recht sim¬≠plen Beispiel reicht es aus, den Anteil der aus¬≠ge¬≠tauscht¬≠en Kol¬≠le¬≠gen im Ver¬≠h√§lt¬≠nis zur Team¬≠gr√∂√üe zu beurteilen. Dabei stellen wir fest, dass inner¬≠halb des Betra¬≠ch¬≠tungszeitraums 5 von 7 Mitar¬≠beit¬≠ern erset¬≠zt wur¬≠den. Das entspricht ein¬≠er Quote von 71,4 Prozent.

Die Ermit¬≠tlung der Fluk¬≠tu¬≠a¬≠tion als betrieb¬≠swirtschaftliche Kenn¬≠zahl ist eine Wis¬≠senschaft f√ľr sich. Diese Ebene soll hier nicht betra¬≠chtet wer¬≠den. F√ľr uns ist die sozial¬≠dy¬≠namis¬≠che Kom¬≠po¬≠nente wichtiger, n√§m¬≠lich wie sich das Kom¬≠men und Gehen von Mitar¬≠beit¬≠ern auf die Grup¬≠pen¬≠dy¬≠namik eines Teams und somit auf dessen Leis¬≠tungs¬≠f√§higkeit auswirkt. Wir erin¬≠nern uns: Soft¬≠wa¬≠reen¬≠twick¬≠lung ist Wissensarbeit.

√úBERM√ĄSSIGE FLUKTUATION WIRKT ZERST√ĖRERISCH

In unserem Beispiel sind zum Jahre¬≠sende knapp 3/4 des Teams erset¬≠zt. Und obwohl die Team¬≠gr√∂√üe w√§hrend des Zeitraums nahezu kon¬≠stant bleibt, wird dieses Team ver¬≠mut¬≠lich nicht gut funk¬≠tion¬≠ieren. Warum ist das so?

Phasen des Teambuildings nach Tuckman

Der amerikanis­che Psy­chologe Bruce Tuck­man for­mulierte in den Sechziger­jahren sein Phasen­mod­ell der grup­pen­dy­namis­chen Entwick­lung von Teams. Dem­nach find­et das, was wir als Team­build­ing beze­ich­nen, immer in vier Phasen statt, näm­lich Form­ing, Storm­ing, Norm­ing und Per­form­ing. Wir wollen diese kurz erklären.

Forming

Das Team entste¬≠ht und macht sich mit seinem Umfeld und den anste¬≠hen¬≠den Her¬≠aus¬≠forderun¬≠gen ver¬≠traut. √úblicher¬≠weise wer¬≠den in der Start¬≠phase Diskus¬≠sio¬≠nen dar√ľber gef√ľhrt, wie die geset¬≠zten Ziele erre¬≠icht wer¬≠den sollen. Die Mit¬≠glieder des Teams arbeit¬≠en noch weit¬≠ge¬≠hend ber√ľhrungs¬≠frei und ver¬≠hal¬≠ten sich so, wie sie es aus fr√ľheren Pro¬≠jek¬≠ten gewohnt sind.

Storming

In dieser Phase lernt das Team die unter¬≠schiedlichen Charak¬≠tere sein¬≠er Mit¬≠glieder ken¬≠nen und begin¬≠nt, diese einzuord¬≠nen. Es stellt sich her¬≠aus, wer mit wem ‚Äěgut kann‚Äú, und wo Per¬≠s√∂n¬≠lichkeit¬≠en aufeinan¬≠der¬≠prallen. Es kann sein, dass sich inner¬≠halb des Teams Unter¬≠grup¬≠pen formieren. Au√üer¬≠dem k√∂n¬≠nen Kon¬≠flik¬≠te mehr oder weniger offen zutage treten.

Norming

Ide­al­er­weise ler­nen die Team­mit­glieder nun, auf pro­duk­ti­vere Weise miteinan­der umzuge­hen, Kon­flik­te zu lösen und Per­sön­lichkeit­sun­ter­schiede auszu­gle­ichen. Die gemein­same Zielset­zung, die im Form­ing definiert wurde, erlebt nun eine höhere Ebene der Zusammenarbeit.

Performing

In der Aus¬≠f√ľhrungsphase sind die grundle¬≠gen¬≠den Nor¬≠men geset¬≠zt, und das Team hat Wege der Zusam¬≠me¬≠nar¬≠beit f√ľr sich etabliert. Rollen und Posi¬≠tio¬≠nen sind klar her¬≠aus¬≠gear¬≠beit¬≠et, so dass Arbeitsabl√§ufe effizien¬≠ter von¬≠stat¬≠ten gehen. Nun ist das Team weniger mit sich selb¬≠st als mit der Aus¬≠f√ľhrung sein¬≠er eigentlichen Auf¬≠gaben besch√§ftigt.

Dieser kurze Abriss soll gen√ľ¬≠gen um zu ver¬≠ste¬≠hen, dass Team¬≠build¬≠ing mehr ist als das blo√üe Grup¬≠pieren von Men¬≠schen mit bes¬≠timmten F√§higkeit¬≠en. Es ist ein Prozess, der den Beteiligten Zeit, Energie und ein nicht zu unter¬≠sch√§tzen¬≠des Ma√ü an sozialer und emo¬≠tionaler Reife abver¬≠langt. Wie lange es dauert, l√§sst sich wed¬≠er fes¬≠tle¬≠gen noch absch√§tzen. Wir k√∂n¬≠nen aber davon aus¬≠ge¬≠hen, dass fast immer mehrere Monate ben√∂tigt wer¬≠den, ein Team so reifen zu lassen, dass die Zusam¬≠me¬≠nar¬≠beit effek¬≠tiv funk¬≠tion¬≠iert. In Wahrheit ist der Vor¬≠gang kom¬≠plex, vielschichtig und anstren¬≠gend ‚Äď wie immer, wenn Men¬≠schen mit unter¬≠schiedlichen Hin¬≠ter¬≠gr√ľn¬≠den aufeinandertreffen. 

Never change a running system

Ein Team, das den Zus¬≠tand Per¬≠form¬≠ing erre¬≠icht hat, kann als ein funk¬≠tion¬≠ieren¬≠des Sys¬≠tem betra¬≠chtet wer¬≠den, bei dem ein R√§d¬≠chen ins andere greift. Die einzel¬≠nen Kom¬≠po¬≠nen¬≠ten, die Team¬≠mit¬≠glieder, sind gut aufeinan¬≠der abges¬≠timmt. Der Nachricht¬≠e¬≠naus¬≠tausch inner¬≠halb des Teams erfol¬≠gt peer-to-peer, im Mul¬≠ti- oder Broad¬≠cast-Modus, je nach¬≠dem, welch¬≠er Modus ger¬≠ade angemessen ist. Die soziale Intel¬≠li¬≠genz des Teamwe¬≠sens ist in der Lage, unter¬≠schiedliche Kom¬≠mu¬≠nika¬≠tion¬≠sebe¬≠nen und Nachricht¬≠en¬≠for¬≠mate zu adap¬≠tieren und aufeinan¬≠der abzu¬≠bilden. Das ist das Ergeb¬≠nis eines lan¬≠gen Lernprozesses. 

Komplexe Systeme sind fragil

Jede Verän­derung eines so funk­tion­ieren­den Sys­tems wird immer eine Störung des Gesamt­sys­tems her­vor­rufen, gle­ich­wohl ob es sich um eine Ver­größerung oder Verkleinerung han­delt. Selb­st wenn die Größe des Sys­tems unverän­dert bleibt und nur einzelne Teile aus­ge­tauscht wer­den, wird das Zusam­men­spiel ins­ge­samt nicht mehr so sein wie vorher. Wie heißt es so schön? Nev­er change a run­ning system.

In unserem Beispiel¬≠team sind am Jahre¬≠sende f√ľnf von sieben ‚ÄěKom¬≠po¬≠nen¬≠ten‚Äú erset¬≠zt wor¬≠den. Aus grup¬≠pen¬≠dy¬≠namis¬≠ch¬≠er Sicht bedeutet das, dass ein v√∂l¬≠lig anderes, neues Sys¬≠tem gebildet wurde. Das Team wird unweiger¬≠lich in sein¬≠er Evo¬≠lu¬≠tion zur√ľck¬≠ge¬≠wor¬≠fen. Es begin¬≠nt wieder bei Phase 0, dem Form¬≠ing, unab¬≠h√§ngig auf welch¬≠er Stufe es vorher stand.

Damit nicht genug, wenn wir die Zeit¬≠punk¬≠te betra¬≠cht¬≠en, an denen die Per¬≠son¬≠al¬≠wech¬≠sel stat¬≠tfan¬≠den, stellen wir fest, dass in vier Monat¬≠en des Jahres 2019 Kol¬≠le¬≠gen das Team ver¬≠lassen haben und/oder neue Kol¬≠le¬≠gen hinzugekom¬≠men sind. Dabei ist es zweitrangig, von welch¬≠er Art die Wech¬≠sel sind und in welchem Umfang sie erfol¬≠gen. Das entschei¬≠dende Ele¬≠ment ist tat¬≠s√§ch¬≠lich, dass eine Ver√§n¬≠derung stattge¬≠fun¬≠den hat. Nach jed¬≠er Ver√§n¬≠derung begin¬≠nt das Form¬≠ing von neuem, gefol¬≠gt von Storm¬≠ing usw. Das ist ein Naturge¬≠setz. Wir k√∂n¬≠nen somit davon aus¬≠ge¬≠hen, dass dieses Team w√§hrend des ganzen Jahres nicht aus der Form¬≠ing¬≠phase her¬≠aus¬≠gekom¬≠men ist. Allen¬≠falls pen¬≠delte es zwis¬≠chen Form¬≠ing und Storm¬≠ing hin und her.

Gibt es Gegenmittel?

Wir haben gel­ernt, Soft­wa­reen­twick­lung ist Wis­sensar­beit. Was wäre also nahe­liegen­der, als das Wis­sen eines Teams so zu kon­servieren, dass notwendi­ge oder unfrei­willige Per­son­al­wech­sel sich weniger nachteilig auswirken? Doku­men­ta­tion ist hier das Wort der Stunde. Wenn wir alles doku­men­tieren, also die fach­lichen Anforderun­gen, die tech­nis­che Infra­struk­tur und nicht zulet­zt den Quell­code, dann soll­ten wir diesem Anspruch doch gerecht wer­den können.

Umfassende Dokumentation

Um es gle¬≠ich vor¬≠wegzunehmen, das wird ver¬≠mut¬≠lich nicht gut funk¬≠tion¬≠ieren, aus mehreren Gr√ľn¬≠den. Wer schon ein¬≠mal ver¬≠sucht hat, eine umfassende Doku¬≠men¬≠ta¬≠tion aus einem Soft¬≠wareteam her¬≠auszuk¬≠itzeln, wei√ü, wie schwierig das ist. Doku¬≠men¬≠ta¬≠tion ist rel¬≠a¬≠tiv ein¬≠fach, solange sie sich auf einem hohen Abstrak¬≠tion¬≠sniveau bewegt. Um Team¬≠mit¬≠glieder aus¬≠tauschen zu k√∂n¬≠nen, m√ľssen wir aber viel weit¬≠er in die Tiefe gehen. Und all die Wis¬≠sensin¬≠seln, Kopf¬≠mono¬≠pole und alles Spezial¬≠wis¬≠sen trans¬≠par¬≠ent darzustellen ist schi¬≠er unm√∂glich. 

Es ist unmöglich, alles zu dokumentieren

Langlaufende Soft¬≠waresys¬≠teme wer¬≠den sehr schnell der¬≠art kom¬≠plex, dass die Bere¬≠iche zwis¬≠chen den einzel¬≠nen Fak¬≠ten der Fach¬≠dom√§ne, die nir¬≠gend¬≠wo schriftlich erfasst sind, immer umfan¬≠gre¬≠ich¬≠er wer¬≠den. Es sind die dynamis¬≠chen Zusam¬≠men¬≠h√§nge, dort, wo viele Fak¬≠toren aufeinan¬≠dertr¬≠e¬≠f¬≠fen und sich wis¬≠senstech¬≠nis¬≠che Syn¬≠ergien ergeben, die nur √ľber Erfahrung mit genau diesem Sys¬≠tem erlernt wer¬≠den k√∂n¬≠nen. Und das braucht Zeit. Die neuen Kol¬≠le¬≠gen ler¬≠nen diese Dinge nicht, indem sie die Sys¬≠tem¬≠doku¬≠men¬≠ta¬≠tion studieren. Zu den kom¬≠plex¬≠en fach¬≠lichen Zusam¬≠men¬≠h√§n¬≠gen kommt dann noch die tech¬≠nis¬≠che Ebene, die ihrer¬≠seits tiefes sys¬≠tem¬≠be¬≠zo¬≠genes Wis¬≠sen erfordert, mit weit¬≠eren Her¬≠aus¬≠forderun¬≠gen bez√ľglich der Dokumentation. 

Das hei√üt aber nicht, dass wir gar nicht doku¬≠men¬≠tieren sollen, im Gegen¬≠teil! Nat√ľr¬≠lich ist Doku¬≠men¬≠ta¬≠tion richtig und wichtig, ist sie doch untrennbar¬≠er Bestandteil eines guten und voll¬≠st√§ndi¬≠gen Soft¬≠ware¬≠pro¬≠duk¬≠ts. Nur d√ľr¬≠fen wir nicht erwarten, dass sie das Mit¬≠tel ist, um dem Fluch der Fluk¬≠tu¬≠a¬≠tion zu entkom¬≠men. Dazu bedarf es mehr. 

Wartbare Software

Wenn wir √ľber Doku¬≠men¬≠ta¬≠tion reden, reden wir im sel¬≠ben Atemzug √ľber Cod¬≠e¬≠qual¬≠it√§t. Tat¬≠s√§ch¬≠lich ist der Quell¬≠code ein wesentlich¬≠er Teil der Doku¬≠men¬≠ta¬≠tion. Gut ver¬≠fasster, pr√§g¬≠nant for¬≠muliert¬≠er, schn√∂rkel¬≠los¬≠er Code erk¬≠l√§rt dem Entwick¬≠ler das Sys¬≠tem mit seinen fach¬≠lichen Regeln und tech¬≠nis¬≠chen Zusam¬≠men¬≠h√§n¬≠gen. Uncle Bob hat dieser Philoso¬≠phie mehrere B√ľch¬≠er gewid¬≠met, die in der Fach¬≠welt eine gewisse Akzep¬≠tanz erlangt haben. Und hier haben wir eine wesentliche Stellschraube f√ľr unser Prob¬≠lem gefun¬≠den: sauber¬≠er Code zusam¬≠men mit einem vern√ľn¬≠fti¬≠gen Ma√ü an Doku¬≠men¬≠ta¬≠tion hil¬≠ft tat¬≠s√§ch¬≠lich, die neg¬≠a¬≠tiv¬≠en Effek¬≠te in fluk¬≠tu¬≠ieren¬≠den Teams abzu¬≠mildern. Aber Achtung: das ist leichter gesagt als getan, und in der Prax¬≠is tat¬≠s√§ch¬≠lich sel¬≠ten anzutr¬≠e¬≠f¬≠fen. Pro¬≠jek¬≠tver¬≠ant¬≠wortliche sind somit aufgerufen, diesen Anforderun¬≠gen sowohl durch die Qual¬≠it√§t der Per¬≠son¬≠alauswahl als auch durch ihre eige¬≠nen F√ľhrungsqual¬≠it√§ten Rech¬≠nung zu tra¬≠gen ‚ÄĒ noth¬≠ing in life is for free, und nie¬≠mand w√ľrde behaupten, dass es ein¬≠fach w√§re!

Fluktuation vermindern

Eine weit¬≠ere, sehr wirkungsvolle Stellschraube ist eigentlich auch die nahe¬≠liegend¬≠ste: Sorge daf√ľr, dass die guten Mitar¬≠beit¬≠er bleiben! Auch das ist leicht gesagt. Wir ken¬≠nen jedoch eine Rei¬≠he von Fak¬≠toren, die Mitar¬≠beit¬≠er zum bleiben bewegen.

Gehaltsstrukturen

In einem Soft¬≠wa¬≠reen¬≠twick¬≠lung¬≠spro¬≠jekt sind die Soft¬≠ware Engi¬≠neers das wertvoll¬≠ste Asset. Sie soll¬≠ten entsprechend gepflegt und gew√ľrdigt wer¬≠den. Sie haben alle ben√∂tigten F√§higkeit¬≠en, um ein Soft¬≠ware¬≠pro¬≠jekt zu pla¬≠nen, umzuset¬≠zen und auszuliefern. Der Soft¬≠ware Engi¬≠neer verk√∂r¬≠pert nicht nur die Rolle des Pro¬≠gram¬≠mier¬≠ers, son¬≠dern auch die Rollen des Busi¬≠ness Ana¬≠lysten, Pro¬≠jek¬≠tleit¬≠ers, Head-of-every¬≠thing und CxOs in Per¬≠son¬≠alu¬≠nion, denn diese sind Bestandteil sein¬≠er Aus¬≠bil¬≠dung. Zumin¬≠d¬≠est the¬≠o¬≠retisch, denn nat√ľr¬≠lich kommt es auch ein biss¬≠chen auf die Gr√∂√üe des Pro¬≠jek¬≠tes an. Nichts¬≠destotrotz wurde der Beweis f√ľr diese Behaup¬≠tung in der Prax¬≠is oft genug erbracht. Wir ken¬≠nen die One Man Suc¬≠cess Sto¬≠rys zur Gen√ľge. Also noch ein¬≠mal: der Soft¬≠ware Engi¬≠neer ist das wertvoll¬≠ste Asset. Das ist auch der Grund, warum in f√ľhren¬≠den Unternehmen, die ihre Ein¬≠nah¬≠men direkt aus Soft¬≠ware¬≠pro¬≠duk¬≠ten gener¬≠ieren, die Entwick¬≠ler sechsstel¬≠lige Jahres¬≠ge¬≠h√§l¬≠ter mit nach Hause nehmen.

In Deutsch¬≠land ist das allerd¬≠ings kaum umzuset¬≠zen, da die Gehaltsstufen meist streng an Posi¬≠tio¬≠nen gekop¬≠pelt sind. Dass ein Entwick¬≠ler mehr ver¬≠di¬≠ent als der Abteilungsleit¬≠er ist hierzu¬≠lande beina¬≠he undenkbar. Zwar gibt es auch bei uns einige Unternehmen, die soge¬≠nan¬≠nte hor¬≠i¬≠zon¬≠tale oder fach¬≠liche Kar¬≠ri¬≠eren f√∂rdern, bre¬≠it durchge¬≠set¬≠zt hat sich dieses Mod¬≠ell aber noch nicht. Leis¬≠tungs¬≠gerechte Bezahlung wird so zur Unm√∂glichkeit, die Abwan¬≠derung der besten K√∂pfe ist vor¬≠pro¬≠gram¬≠miert. Ungl√ľck¬≠licher¬≠weise gehen in der Regel immer die guten Mitar¬≠beit¬≠er, die weniger motivierten bleiben.

Mitarbeiterzufriedenheit

Die Mitar¬≠beit¬≠erzufrieden¬≠heit ist in mod¬≠er¬≠nen Unternehmen eine ele¬≠mentare Ken¬≠ngr√∂√üe. Es gibt Mod¬≠elle, Meth¬≠o¬≠d¬≠en und Metriken, um die Mitar¬≠beit¬≠erzufrieden¬≠heit betrieb¬≠swirtschaftlich zu ber√ľck¬≠sichti¬≠gen. Damit kann man sich wis¬≠senschaftlich auseinan¬≠der¬≠set¬≠zen, muss man aber nicht. Die agile Welt der Soft¬≠wa¬≠reen¬≠twick¬≠lung bietet alles, was es dazu braucht. 

Agile Organisation

Fast jed¬≠er ken¬≠nt heutzu¬≠tage den Begriff der Agilen Organ¬≠i¬≠sa¬≠tion, und viele w√ľr¬≠den Stein und Bein schw√∂ren, Teil ein¬≠er agilen Organ¬≠i¬≠sa¬≠tion zu sein. Nun, wenn es so ist, warum haben wir dann ein Prob¬≠lem mit Fluk¬≠tu¬≠a¬≠tion? Es gilt der Leitgedanke der agilen Welt ‚Äěif it‚Äôs not fun, it‚Äôs not agile‚Äú. Und salopp gesagt, wenn es keinen Spa√ü macht, dann gehen die Mitar¬≠beit¬≠er eben. Falls der aufmerk¬≠same Leser an dieser Stelle eine leichte Ver¬≠wirrung ver¬≠sp√ľrt, das l√§sst sich schnell erk¬≠l√§ren: Es gibt n√§m¬≠lich zwei Arten von Agilit√§t ‚ÄĒ die echte Agilit√§t und die vorge¬≠spiegelte Agilit√§t, das soge¬≠nan¬≠nte Car¬≠go Agile.

Car¬≠go Agile ist das, was die meis¬≠ten aus ihrem Arbeit¬≠sall¬≠t¬≠ag ken¬≠nen, auch wenn der Begriff vielle¬≠icht nicht jedem gel√§u¬≠fig ist. Es ist die Art von Agilit√§t, bei der die √§u√üer¬≠lich erkennbaren Merk¬≠male agiler Organ¬≠i¬≠sa¬≠tio¬≠nen umge¬≠set¬≠zt wer¬≠den, beispiel¬≠sweise Iter¬≠a¬≠tio¬≠nen mit regelm√§√üi¬≠gen Sprint Reviews, Ret¬≠ro¬≠spek¬≠tiv¬≠en und Pla¬≠nungsmeet¬≠ings. Im fort¬≠geschrit¬≠te¬≠nen Car¬≠go Cult wird sog¬≠ar noch ein Mitar¬≠beit¬≠er als Scrum Mas¬≠ter bestellt, und das agile The¬≠ater ist per¬≠fekt. Mit Agilit√§t hat das aber nichts zu tun. Es ist in etwa so, als w√ľrde man sich ein Rolex-Pla¬≠giat ums Handge¬≠lenk binden, um wohlhabend zu wirken, ohne es wirk¬≠lich zu sein.

Echte Agilit√§t erken¬≠nt man an ihren Fr√ľcht¬≠en. His¬≠torisch gewach¬≠sene Hier¬≠ar¬≠chien mag es dabei zwar geben, doch wer¬≠den sie nicht in Form von Befehls¬≠ket¬≠ten gelebt. F√ľhrungskr√§fte im Geiste des Ser¬≠vant Lead¬≠er¬≠ship ver¬≠ste¬≠hen sich als Enabler, die ihre Auf¬≠gabe darin sehen, Boden und Umfeld f√ľr die Entwick¬≠lung¬≠steams so zu bere¬≠it¬≠en, dass diese ihre Arbeit effizient gestal¬≠ten k√∂n¬≠nen. Die Teams hinge¬≠gen ver¬≠ant¬≠worten selb¬≠stor¬≠gan¬≠isiert die Bere¬≠it¬≠stel¬≠lung von L√∂sun¬≠gen. Sie haben das meiste Wis¬≠sen dar√ľber und deshalb auch die meiste Kon¬≠trolle bei allen Entschei¬≠dun¬≠gen, soweit sie die Umset¬≠zung betr¬≠e¬≠f¬≠fen. Recruit¬≠ing und Team¬≠build¬≠ing fall¬≠en eben¬≠falls in die Ver¬≠ant¬≠wor¬≠tung von Empow¬≠ered Teams.

Streben nach Exzellenz

Ein Kennze¬≠ichen agiler Organ¬≠i¬≠sa¬≠tio¬≠nen ist das best√§ndi¬≠ge Streben nach Exzel¬≠lenz nicht nur auf der tech¬≠nis¬≠chen, son¬≠dern eben¬≠so auf der fach¬≠lichen, organ¬≠isatorischen und zwis¬≠chen¬≠men¬≠schlichen Ebene. Agile Unternehmen f√∂rdern im Ser¬≠vant Lead¬≠er¬≠ship die Weit¬≠er¬≠en¬≠twick¬≠lung und Fort¬≠bil¬≠dung ihrer Mitar¬≠beit¬≠er und r√§u¬≠men entsprechende M√∂glichkeit¬≠en ein. In der agilen Soft¬≠wa¬≠reen¬≠twick¬≠lung wer¬≠den erprobte Meth¬≠o¬≠d¬≠en wie Pair- oder Mob Pro¬≠gram¬≠ming, Cod¬≠ing Dojos und Tech Talks gef√∂rdert, wodurch die selb¬≠stor¬≠gan¬≠isierte Weit¬≠er¬≠en¬≠twick¬≠lung der Teams kon¬≠tinuier¬≠lich beg√ľn¬≠stigt wird. Die fes¬≠tangestell¬≠ten Mitar¬≠beit¬≠er absolvieren Schu¬≠lun¬≠gen und besuchen Fachkon¬≠feren¬≠zen. Freiberu¬≠fliche Kol¬≠le¬≠gen wer¬≠den durch ein solch¬≠es Umfeld ermutigt, gle¬≠ichzuziehen. Wenn durch solche Ma√ü¬≠nah¬≠men die Mess¬≠lat¬≠te auf einem hohen Niveau gehal¬≠ten wird, darf sich ein Pro¬≠jekt State of the Art nennen.

State of the Art

Ein State-of-the-Art-Pro¬≠jekt zieht von sich aus f√§hige Mitar¬≠beit¬≠er an. Schw√§chere durch¬≠laufen in kurz¬≠er Zeit eine Entwick¬≠lung zum Pos¬≠i¬≠tiv¬≠en, um an das Niveau der Avant¬≠gardis¬≠ten her¬≠anzukom¬≠men, oder ver¬≠lassen das Team. Das ist nor¬≠males grup¬≠pen¬≠dy¬≠namis¬≠ches Ver¬≠hal¬≠ten. Auf diese Weise reg¬≠uliert sich das Umfeld von selb¬≠st auf ein h√∂heres Niveau. Die Chance, dass die guten Mitar¬≠beit¬≠er nicht weit¬≠erziehen son¬≠dern dem Pro¬≠jekt langfristig erhal¬≠ten bleiben, wird in State-of-the-Art-Pro¬≠jek¬≠ten max¬≠imiert. Und das ist es, was wir erre¬≠ichen wollen, denn f√§hige Mitar¬≠beit¬≠er sind unser wertvoll¬≠stes Asset. 

In diesem Sinne: Let’s get excellent!

Wikipedia: Fluk­tu­a­tion

Stiller Killer #1: Technische Schulden

Im Soft¬≠wa¬≠reen¬≠twick¬≠lung¬≠sprozess k√∂n¬≠nen Zust√§nde entste¬≠hen, die den Pro¬≠jek¬≠ter¬≠folg verz√∂gern, gef√§hrden oder g√§n¬≠zlich unm√∂glich machen. Schon manch¬≠es Pro¬≠jekt musste wegen man¬≠gel¬≠nden Bewusst¬≠seins √ľber solche Risiken wieder¬≠holt neu aufge¬≠set¬≠zt oder g√§n¬≠zlich begraben wer¬≠den. Selb¬≠st dann jedoch bleiben die Ursachen h√§u¬≠fig im Ver¬≠bor¬≠ge¬≠nen. Ich nenne sie daher stille Killer ‚Äď die unerkan¬≠nte, zuweilen auch nur unter¬≠sch√§tzte Gefahr.

Der Begriff der Tech¬≠nis¬≠chen Schulden ist heute den meis¬≠ten, die in irgen¬≠dein¬≠er Weise mit Soft¬≠wa¬≠reen¬≠twick¬≠lung zu tun haben, gel√§u¬≠fig. In agilen Entwick¬≠lerteams wird er f√ľr gew√∂hn¬≠lich regelm√§√üig the¬≠ma¬≠tisiert. Unter dem K√ľrzel TD f√ľr Englisch Tech¬≠ni¬≠cal Debt wird die Tech¬≠nis¬≠che Schuld gerne bem√ľht, um Verz√∂gerun¬≠gen oder Fehler¬≠rat¬≠en zu begr√ľn¬≠den. Und obwohl das Konzept der Tech¬≠nis¬≠chen Schuld in den let¬≠zten Jahren auf unr√ľhm¬≠liche Weise pop¬≠ul√§r gewor¬≠den ist, gibt es einen Umstand, der allzu leicht √ľberse¬≠hen wird: die Entste¬≠hung von Tech¬≠nis¬≠ch¬≠er Schuld ist unvermeidbar.

Technische Schuld ist ein Naturgesetz

Wir sind nicht hellsichtig, und Zeit ist ein knappes Gut (glauben wir)

Soviel wir uns auch bem√ľhen, wir k√∂n¬≠nen nicht jedes Detail vorausah¬≠nen. Auch k√∂n¬≠nen wir uns nicht beliebig viel Zeit nehmen, immer die ide¬≠ale L√∂sung zu entwer¬≠fen. So manche weitre¬≠ichende Entschei¬≠dung tre¬≠f¬≠fen wir inner¬≠halb von Sekun¬≠den. Manch¬≠mal bemerken wir zu sp√§t, dass uns zur opti¬≠malen Umset¬≠zung schlicht Wis¬≠sen fehlte.

Architektur erodiert

Und dann ist da noch etwas, das Dr. Car¬≠o¬≠la Lilien¬≠thal als Architek¬≠turero¬≠sion beze¬≠ich¬≠net. Damit ist gemeint, dass selb¬≠st ein ide¬≠al¬≠er Entwurf mit der Zeit seine G√ľltigkeit ver¬≠lieren kann, und aus ein¬≠er ehe¬≠mals guten mit der Zeit eine weniger gute Imple¬≠men¬≠tierung wird. Eine Architek¬≠tur, die gestern noch per¬≠fekt war, ist heute falsch, da die Umst√§nde sich ver√§n¬≠dert haben. Geset¬≠zliche Vor¬≠gaben oder neue Ver¬≠fahren im Zahlungsverkehr sind gute Beispiele daf√ľr. Davon abge¬≠se¬≠hen entste¬≠ht Ero¬≠sion h√§u¬≠fig auch dadurch, dass ver¬≠schiedene Entwick¬≠ler mit unter¬≠schiedlichem Hin¬≠ter¬≠grund und Sachver¬≠stand den Code mit der Zeit in ein Sta¬≠di¬≠um zunehmender Unord¬≠nung √ľber¬≠f√ľhren. Kurz gesagt: der Code wird mit der Zeit immer schlechter. In vie¬≠len Soft¬≠ware¬≠pro¬≠jek¬≠ten ist das eine fest¬≠ste¬≠hende Tatsache.

frei nach C. Lilien¬≠thal: der ‚ÄěKor¬≠ri¬≠dor geringer Tech¬≠nis¬≠ch¬≠er Schuld‚Äú

Es ist also schw¬≠er, TDs in Soft¬≠waresys¬≠te¬≠men ganz zu ver¬≠mei¬≠den. Wohl aber gibt es M√∂glichkeit¬≠en, die Sch√§¬≠den zu min¬≠imieren, indem wir ihr Aus¬≠ma√ü inner¬≠halb eines ‚ÄěKor¬≠ri¬≠dors geringer tech¬≠nis¬≠ch¬≠er Schulden‚Äú (Lilien¬≠thal) hal¬≠ten. Doch zun√§chst wollen wir ver¬≠suchen zu umrei√üen, was Tech¬≠nis¬≠che Schuld f√ľr uns bedeutet.

Definition

Tat¬≠s√§ch¬≠lich gibt es zur Def¬≠i¬≠n¬≠i¬≠tion von TD unter¬≠schiedliche Betra¬≠ch¬≠tungsweisen. Die ein¬≠fach¬≠ste ist, jed¬≠wede unsachgem√§√üe Pro¬≠gram¬≠mierung als TD zu beze¬≠ich¬≠nen. Unsachgem√§√ü bedeutet hier: den Stand der Kun¬≠st mis¬≠sach¬≠t¬≠end oder schlichtweg sch√§big programmiert. 

Eine andere Auf¬≠fas¬≠sung besagt, dass es immer eine bewusste Entschei¬≠dung sein muss, Tech¬≠nis¬≠che Schulden aufzunehmen ‚Äď schlechte Pro¬≠gram¬≠mierung oder man¬≠gel¬≠hafte Architek¬≠tur fie¬≠len dann also nicht darunter. Hier w√ľr¬≠den wir kurzfristig und bewusst ein TD akzep¬≠tieren, um ein anderes Ziel, beispiel¬≠sweise einen bevorste¬≠hen¬≠den Releaseter¬≠min, schneller zu erreichen. 

Als Ver­all­ge­meinerung bei­der Sicht­en ließe sich definieren, dass Tech­nis­che Schuld poten­ziell jed­er Zus­tand ein­er Soft­ware ist, der eine naht­lose Weit­er­en­twick­lung ver­hin­dert.

Gr√ľnde und Auswirkungen

Aufgeschobene Refactorings

Sobald durch eine anste¬≠hende Erweiterung die Umstruk¬≠turierung beste¬≠hen¬≠der Teile der Soft¬≠ware erforder¬≠lich wird, dro¬≠ht ein Schulden¬≠loch. Ob es sich auf¬≠tut und wir hine¬≠in¬≠fall¬≠en h√§ngt davon ab, ob das Refac¬≠tor¬≠ing durchge¬≠f√ľhrt wird oder nicht. Wenn ja, ist alles gut ‚Äď keine TD aufge¬≠baut. Wenn wir es nicht tun, haben wir von dem Moment an eine TD, die mit jedem kom¬≠menden Change Request ihre Zin¬≠sen ein¬≠fordern wird. Der Zins¬≠eszin¬≠sef¬≠fekt ist bekan¬≠ntlich ein expo¬≠nen¬≠tielles Ph√§nomen. Das gilt auch in der Softwareentwicklung.

H√§u¬≠fig wird mit der Umset¬≠zung von Erweiterun¬≠gen begonnen, ohne vorher zu pr√ľfen, ob die beste¬≠hende Architek¬≠tur den neuen Anforderun¬≠gen stand¬≠h√§lt. N√∂tige Refac¬≠tor¬≠ings wer¬≠den so erst sp√§t erkan¬≠nt, wenn √ľber¬≠haupt. Nach zwei oder drei Erweiterungszyklen ist das Dilem¬≠ma oft¬≠mals bere¬≠its so weit fort¬≠geschrit¬≠ten, dass Ma√ü¬≠nah¬≠men zur Behe¬≠bung sehr deut¬≠lich zu Buche schla¬≠gen w√ľr¬≠den. Die L√∂sung hei√üt dann allzu oft ‚ÄěAugen zu und durch‚Äú ‚Äď und so man√∂vri¬≠ert sich das Pro¬≠jekt selb¬≠st immer tiefer in den Schulden¬≠berg hinein. In dieser Phase begin¬≠nen die Schmerzen gro√ü genug zu wer¬≠den, um Aufmerk¬≠samkeit ‚Äěvon oben‚Äú, also des Man¬≠age¬≠ments oder des Kun¬≠den zu gewin¬≠nen. Die Frage lautet dann, warum selb¬≠st kleine Fea¬≠ture-Erweiterun¬≠gen ‚Äěso lange‚Äú dauern. 

Featuritis

Es ist eine Bin¬≠sen¬≠weisheit, dass viele Soft¬≠ware¬≠pro¬≠jek¬≠te mit Bazil¬≠lus Fea¬≠tu¬≠ri¬≠tis infiziert sind. Das giftige Stof¬≠fwech¬≠sel¬≠pro¬≠dukt dieses Erregers ist TD. Eine der Schwierigkeit¬≠en bei der Diag¬≠nose von TD ist die lange Inku¬≠ba¬≠tion¬≠szeit. W√§hrend funk¬≠tionale Soft¬≠warefehler meist fr√ľhzeit¬≠ig zutage treten, wirken sich TDs eine Zeit lang eher unter¬≠schwellig aus. Wenn ihre unsch√∂¬≠nen Symp¬≠tome wie erschw¬≠erte Wart¬≠barkeit und steigende Defect-Rat¬≠en sich endlich zeigen, ist das Soft¬≠ware¬≠pro¬≠dukt bere¬≠its der¬≠art herun¬≠tergewirtschaftet, dass ein Gegen¬≠s¬≠teuern nicht mehr ohne deut¬≠lichen Mehraufwand zu bew¬≠erk¬≠stel¬≠li¬≠gen ist. Das liegt daran, dass TD ein Aspekt der inneren Soft¬≠ware¬≠qual¬≠it√§t ist, beziehungsweise ein Man¬≠gel der¬≠sel¬≠ben. Die innere Qual¬≠it√§t eines Pro¬≠duk¬≠ts ist von au√üen nicht direkt sicht¬≠bar. Sie wird nur dann wahrgenom¬≠men, wenn sie so d√ľrftig ist, dass sie zu Fehlfunk¬≠tio¬≠nen oder steigen¬≠den Aufw√§n¬≠den f√ľhrt.

Das Gesetz von Conway

Nach dem vielz¬≠i¬≠tierten Gesetz von Con¬≠way, englisch Conway‚Äės Law, entsprechen die Struk¬≠turen eines Soft¬≠waresys¬≠tems zwangsl√§u¬≠fig denen der Organ¬≠i¬≠sa¬≠tion, die es her¬≠vorge¬≠bracht hat. Ver¬≠schiedene Stu¬≠di¬≠en haben dieses Pos¬≠tu¬≠lat aus den Achtziger¬≠jahren best√§tigt. Das bedeutet am konkreten Beispiel, ein zen¬≠tral¬≠is¬≠tisch-hier¬≠ar¬≠chisch organ¬≠isiertes Unternehmen wird sich mit Microser¬≠vice-Architek¬≠turen, wo Dezen¬≠tral¬≠isierung, Ereignis¬≠s¬≠teuerung, Infor¬≠ma¬≠tion¬≠saus¬≠tausch und Entkop¬≠plung eine gro√üe Rolle spie¬≠len, ver¬≠mut¬≠lich schw¬≠er¬≠tun. Tech¬≠nis¬≠chen Schulden fall¬≠en in dieselbe Kat¬≠e¬≠gorie. Steile Hier¬≠ar¬≠chien, F√ľhrung in Form von Kom¬≠man¬≠dostruk¬≠turen anstatt Ser¬≠vant Lead¬≠er¬≠ship sowie fach¬≠liche und soziale Inkom¬≠pe¬≠tenz beg√ľn¬≠sti¬≠gen den N√§hrbo¬≠den f√ľr das Wach¬≠s¬≠tum von TD. 

Wege aus der Schuldenfalle

Schuldeingeständnis

Ist ein Pro¬≠jekt ein¬≠mal in einen Zus¬≠tand tech¬≠nis¬≠ch¬≠er √úber¬≠schul¬≠dung einge¬≠treten, gibt es den¬≠noch Wege hin¬≠aus. Sie erfordern im ersten Schritt ein Schuldeingest√§nd¬≠nis der Beteiligten: Prod¬≠uct-Own¬≠er, Devel¬≠op¬≠ment-Team und Pro¬≠jek¬≠tleitung m√ľssen sich √ľber ihre jew¬≠eili¬≠gen Anteile im Klaren sein und gemein¬≠sam an der L√∂sung arbeit¬≠en. Ein Coach kann dabei hil¬≠fre¬≠ich sein. Vielle¬≠icht gibt es einen f√§hi¬≠gen Scrum Mas¬≠ter, der die Parteien dabei unter¬≠st√ľtzt, einen gang¬≠baren Weg zu finden.

Schadenanalyse

Sind sich PO, PL/Kunde und Dev-Team einig, kann der neg¬≠a¬≠tive Effekt von TD zumin¬≠d¬≠est abgemildert, manch¬≠mal sog¬≠ar beseit¬≠igt wer¬≠den. Jeden¬≠falls gilt es nun, beherzt zu han¬≠deln. Zun√§chst muss das Aus¬≠ma√ü der Tech¬≠nis¬≠chen Schulden umris¬≠sen wer¬≠den, damit die Aufw√§nde zu ihrer Behe¬≠bung einge¬≠plant wer¬≠den k√∂n¬≠nen. Nicht sel¬≠ten gibt es hier¬≠bei uner¬≠wartete Ergeb¬≠nisse: mehrere Wochen bis Monate an Kon¬≠so¬≠li¬≠dierungsar¬≠beit¬≠en sind f√ľr ein Pro¬≠jekt schw¬≠er zu verkraften. Mut, eine der f√ľnf agilen Tugen¬≠den, ist hier beson¬≠ders gefragt. In ein¬≠er solchen Lage m√ľssen wir uns fol¬≠gen¬≠des immer vor Augen hal¬≠ten: erstens haben wir diesen Zus¬≠tand selb¬≠st verur¬≠sacht, und zwar kollek¬≠tiv auf allen Ebe¬≠nen. Zweit¬≠ens, wenn wir den Mut jet¬≠zt nicht auf¬≠brin¬≠gen, den Zus¬≠tand zu verbessern, wird es sp√§ter noch h√§rter.

Coaching

Eben¬≠falls schwierig wird es, wenn die oben genan¬≠nten Con¬≠way-Gr√ľnde vor¬≠liegen. Dann haben wir es mit einem echt¬≠en H√§rte¬≠fall zu tun. Unter solchen Umst√§n¬≠den ist es uner¬≠l√§sslich, einen erfahre¬≠nen Coach hinzuzuziehen, der F√ľhrung und Entwick¬≠lung miteinan¬≠der in Ein¬≠klang brin¬≠gen hilft.

Vorsicht ist besser als Nachsicht: Technische Schulden einplanen

Um die Entste¬≠hung von TD m√∂glichst von vorn¬≠here¬≠in zu ver¬≠hin¬≠dern, gilt es, die dro¬≠hen¬≠den Schulden¬≠l√∂ch¬≠er rechtzeit¬≠ig zu erken¬≠nen. Ide¬≠al¬≠er¬≠weise pr√ľfen wir die beste¬≠hende Imple¬≠men¬≠tierung, bevor wir mit der Weit¬≠er¬≠en¬≠twick¬≠lung begin¬≠nen. Das schlie√üt auch die Makroar¬≠chitek¬≠tur mit der Kom¬≠mu¬≠nika¬≠tion zwis¬≠chen beteiligten Sys¬≠te¬≠men mit ein. In diesem Fall k√∂n¬≠nten die Refac¬≠tor¬≠ing-Aufw√§nde bere¬≠its in der Pla¬≠nung ber√ľck¬≠sichtigt werden. 

Ver¬≠s√§u¬≠men wir, eine Vor¬≠analyse durchzuf√ľhren oder ist es nicht m√∂glich, k√∂n¬≠nen wir immer noch w√§hrend der Entwick¬≠lung TDs iden¬≠ti¬≠fizieren. Nun ist zu pr√ľfen, wie wir damit umge¬≠hen wollen.

Die edel¬≠ste Option w√§re, die TDs sofort zu beheben und zu akzep¬≠tieren, dass sich der Pla¬≠nung¬≠shor¬≠i¬≠zont entsprechend nach hin¬≠ten ver¬≠schiebt. Das kann eine agile Pro¬≠jek¬≠tor¬≠gan¬≠i¬≠sa¬≠tion leicht verkraften. Im klas¬≠sis¬≠chen Man¬≠age¬≠men¬≠tum¬≠feld kann es jedoch passieren, dass wir damit aller¬≠gis¬≠che Reak¬≠tio¬≠nen aus¬≠l√∂sen. Hier w√§re ein Kom¬≠pro¬≠miss, die TD zun√§chst zu akzep¬≠tieren, um das Fea¬≠ture ‚Äď not¬≠falls mit Workarounds um die TD herum ‚Äď plan¬≠m√§√üig funk¬≠tion¬≠al fer¬≠tigzustellen. Nun aber m√ľssen wir sofort ein Tick¬≠et erstellen, um die TD anschlie√üend so schnell wie m√∂glich ein¬≠pla¬≠nen und aufl√∂sen zu k√∂n¬≠nen. Eine gute Release¬≠pla¬≠nung sollte diesen Fall auch im klas¬≠sis¬≠chen Umfeld abfed¬≠ern k√∂nnen. 

Organisatorische Maßnahmen

Qualität mit einplanen

Organ¬≠isatorische Ma√ü¬≠nah¬≠men betr¬≠e¬≠f¬≠fen alle Ebe¬≠nen der Pro¬≠jek¬≠tor¬≠gan¬≠i¬≠sa¬≠tion. Am Ende jedoch l√§uft es darauf hin¬≠aus, dass die Pro¬≠jek¬≠tleitung f√ľr das Gelin¬≠gen oder Scheit¬≠ern Sorge tra¬≠gen muss. Die PL bes¬≠timmt ma√üge¬≠blich die Pro¬≠jek¬≠tkul¬≠tur, und damit auch, wie mit Her¬≠aus¬≠forderun¬≠gen umge¬≠gan¬≠gen wird, ger¬≠ade wenn sie Geld kosten. Nicht zulet¬≠zt bes¬≠timmt sie, welche Qual¬≠it√§ts¬≠ma√üst√§be anzule¬≠gen sind und wie die Sicherung der Soft¬≠ware¬≠qual¬≠it√§t erfol¬≠gen soll.

Project Staffing

Zun√§chst ein¬≠mal sollte unser Pro¬≠jekt mit f√§hi¬≠gen Men¬≠schen aus¬≠ges¬≠tat¬≠tet sein: wir ben√∂ti¬≠gen beispiel¬≠sweise ein Prod¬≠uct-Man¬≠age¬≠ment-Team und einen F√ľhrungsstab, die wis¬≠sen, wie Soft¬≠wa¬≠reen¬≠twick¬≠lung¬≠sprozesse funk¬≠tion¬≠ieren. Wir brauchen ein Devel¬≠op¬≠ment-Team, das auf dem Stand der Tech¬≠nik und bere¬≠it ist, sich stetig weit¬≠erzuen¬≠twick¬≠eln. Und wir soll¬≠ten einen Pro¬≠jek¬≠t¬≠coach engagieren, beispiel¬≠sweise einen Scrum Mas¬≠ter, der daf√ľr sorgt, dass die Organ¬≠i¬≠sa¬≠tion der Zusam¬≠me¬≠nar¬≠beit im Pro¬≠jekt rund l√§uft. 

Wenn die Qual­ität­sziele gesteckt sind und das Pro­jekt gut gestafft ist, sind die Grund­la­gen geset­zt. Nun gibt es eine Rei­he von Tools, um die innere Qual­ität des Soft­ware­pro­duk­ts zu gewährleisten.

Architekturwissen vom Elfenbeinturm ins Entwicklerteam 

Eines der wichtig¬≠sten Werkzeuge ist die F√§higkeit des Entwick¬≠lerteams, die Soft¬≠ware mit Hil¬≠fe ein¬≠er zweck¬≠m√§√üi¬≠gen Makro- und Mikroar¬≠chitek¬≠tur gut zu struk¬≠turi¬≠eren. Dadurch wird die langfristige Wart¬≠barkeit gew√§hrleis¬≠tet, und Tech¬≠nis¬≠che Schulden k√∂n¬≠nen leichter ver¬≠mieden oder behoben werden. 

Eine beliebte Falle ist hier¬≠bei, die Soft¬≠ware-Architek¬≠tur als eine eigene, von der Pro¬≠gram¬≠mier¬≠ar¬≠beit getren¬≠nte Diszi¬≠plin zu betra¬≠cht¬≠en. Es emp¬≠fiehlt sich jedoch vielmehr, daf√ľr zu sor¬≠gen, dass die Entwick¬≠ler √ľber pro¬≠fun¬≠des Architek¬≠tur¬≠wis¬≠sen ver¬≠f√ľ¬≠gen und dieses in ihrer t√§glichen Arbeit stetig anwen¬≠den. Mit der dazuge¬≠h√∂ri¬≠gen Diszi¬≠plin l√§sst sich dann die Architek¬≠turero¬≠sion in Gren¬≠zen halten.

Poka-Yoke-Entwicklungsprozess ‚Äď Fehler besser vorher vermeiden statt sp√§ter beheben

Um durch Unacht¬≠samkeit oder Toll¬≠patschigkeit entste¬≠hende Tech¬≠nis¬≠che Schuld von vorn¬≠here¬≠in zu ber√ľck¬≠sichti¬≠gen, emp¬≠fiehlt es sich, den Entwick¬≠lung¬≠sprozess so zu gestal¬≠ten, dass alleine dadurch die Entste¬≠hung von TD bere¬≠its eingeschr√§nkt wird. Dieses Vorge¬≠hen ist als Poka Yoke bekan¬≠nt. Beispiel¬≠sweise imple¬≠men¬≠tieren wir Domain Dri¬≠ven Design als fes¬≠ten Bestandteil des Prozess¬≠es. Dadurch wird sichergestellt, dass √Ąnderun¬≠gen in der Fach¬≠dom√§ne ad√§quat in der Soft¬≠ware abge¬≠bildet wer¬≠den. Als n√§ch¬≠stes sollte Clean Code gelebt wer¬≠den. Dadurch min¬≠imiert sich das Aufnehmen von Tech¬≠nis¬≠chen Schulden von selb¬≠st. F√ľr den pas¬≠sion¬≠ierten Clean Coder geh√∂rt kon¬≠tinuier¬≠lich¬≠es Refac¬≠tor¬≠ing zu den Stan¬≠dard¬≠mit¬≠teln, um ger¬≠ade auch die Tech¬≠nis¬≠chen Schulden klein zu hal¬≠ten. Eben¬≠so sind effek¬≠tiv durchge¬≠f√ľhrte Codere¬≠views ein fes¬≠ter Bestandteil der Clean-Code-Praxis.

SonarQube f√ľr statische Codeanalyse nach der SQALE-Methode

Als tech¬≠nis¬≠ches Tool hat sich in vie¬≠len Pro¬≠jek¬≠ten Sonar¬≠Qube etabliert, das in die Build-Pipeline inte¬≠gri¬≠ert wer¬≠den kann, um mit Hil¬≠fe von sta¬≠tis¬≠ch¬≠er Code¬≠analyse unter anderem das Aus¬≠ma√ü an TD zu bemessen. Dabei wird der Grad der Tech¬≠nis¬≠chen Schuld in Man¬≠nta¬≠gen beziffert. 

Allerd¬≠ings d√ľr¬≠fen wir uns nicht dar√ľber hin¬≠wegt√§uschen lassen, dass Sonar¬≠Qube seman¬≠tis¬≠che Qual¬≠it√§t¬≠skri¬≠te¬≠rien wie Les¬≠barkeit und Ver¬≠st√§ndlichkeit des Source¬≠codes genau¬≠so wenig messen kann wie dessen sach¬≠liche Kor¬≠rek¬≠theit. Wichtige Design¬≠prinzip¬≠i¬≠en wie das Sin¬≠gle Respon¬≠si¬≠bil¬≠i¬≠ty Prin¬≠ci¬≠ple sind eben¬≠falls schw¬≠er automa¬≠tisiert zu pr√ľfen. Daher ist Sonar¬≠Qube zwar eine gute Unter¬≠st√ľtzung, sollte jedoch keines¬≠falls als alleinige Quelle der Wahrheit dienen.

Fazit

Fassen wir zusammen:

  • Tech¬≠nis¬≠che Schuld entste¬≠ht laufend w√§hrend der Entwick¬≠lung. Das ist nat√ľr¬≠lich und ganz normal.
  • Obwohl die Tech¬≠nis¬≠che Schuld als Buzz¬≠word in der Soft¬≠wareszene hin¬≠l√§nglich bekan¬≠nt ist, find¬≠en ihre Ursachen und Auswirkun¬≠gen wenig Beach¬≠tung. Allzu oft wer¬≠den sie ignoriert.
  • Die besten Pro¬≠gram¬≠mier¬≠er und Architek¬≠ten k√∂n¬≠nen Tech¬≠nis¬≠che Schulden nicht abwen¬≠den, wenn der Entwick¬≠lung¬≠sprozess und/oder die Unternehmen¬≠skul¬≠tur wirk¬≠same Ma√ü¬≠nah¬≠men konterkarieren.
  • Ein gro√üer Anteil tech¬≠nis¬≠ch¬≠er Schulden l√§sst sich bere¬≠its durch rein organ¬≠isatorische Ma√ü¬≠nah¬≠men unterbinden. Neben ein¬≠er f√§hi¬≠gen Pro¬≠jek¬≠t¬≠mannschaft m√ľssen somit auch kul¬≠turelle und prozes¬≠suale Voraus¬≠set¬≠zun¬≠gen geschaf¬≠fen werden.
  • Soft¬≠ware¬≠pro¬≠jek¬≠t¬≠coach¬≠ing ist ein pro¬≠bates Mit¬≠tel, um die Ver¬≠schul¬≠dung von Anfang an klein zu hal¬≠ten, oder ein Soft¬≠ware¬≠pro¬≠jekt aus der TD-Sack¬≠gasse herauszuf√ľhren.

In diesem Sinne, hap¬≠py engineering ūüôā

Wikipedia: Tech­nis­che Schulden