Abgrenzung

Abgrenzung ist essentiell in der modernen Gesellschaft: Ich kann mich schlicht nicht um alles kümmern. Doch was sind sinnvolle Grenzen in der Softwareentwicklung? Ist nicht jede Abstraktion, ein Kern der guten Softwareentwicklung, eine Abgrenzung?

Abgrenzung ist essentiell in der modernen Gesellschaft: Ich kann mich schlicht nicht um alles kümmern. Meist kann ein einzelner nicht einen ganzen Geschäftsprozess abwickeln (Taylorismus). Doch was sind sinnvolle Grenzen in der Softwareentwicklung? Ist nicht jede Abstraktion, ein Kern der guten Softwareentwicklung, eine Abgrenzung?

Speziell wenn ein Projekt in Schieflage gerät, grenzt sich  jeder ab und macht damit Vorwürfe: Die Entwicklung hat nicht geliefert, die Analyse war zu wenig präzis, die Projektleitung hat den Überblick und der Kunde das Mass verloren. Abgrenzung kann Verantwortung bedeuten, aber auch Rückzug.

Gegenüber dem Gotthardbasistunnel sind die meisten Projekte eher klein. Und doch sagt Peter Jedelhauser, Gesamtprojektleiter Nord-Süd Achse Gotthard bei den SBB, auf die Frage, ob es schwierig war, sich abzugrenzen [Interview im Credit Suisse Bulletin, Nr. 2/2016, S. 19]:

Dieses Wort versuche ich zu vermeiden. Das Denken in Schnittmengen ist effizienter als das Denken in separaten Einheiten. Wenn sich zwei abgrenzen, ist die Chance enorm hoch, dass etwas zwischen Tisch und Bank fällt.

 

 

Abgrenzungen und Schnittmengen

Teams, die sich sauber abgrenzen, erzeugen Zwischenräume. Issues fallen zwischen „Stuhl und Bank“:

separate

Teams mit Overlap erscheinen als kompakte Einheit:

joined

Das spart nicht nur Ressourcen, sondern auch Koordination und damit unproduktive Stunden. Zudem sind Mitarbeiter zufriedener, denn sie haben mehr Verantwortung und Einfluss auf das ganze Projekt.

 

Schnittmenge: Architektur und Team

Nur ganz kleine Projekte bewegen sich in einer Schicht. Das Team der Analysten, Entwickler und Tester muss jedoch alle Schichten und ihr Zusammenspiel verstehen (Full Stack Developer). Ein ganz tolles Tool in einer Schicht hilft nicht, wenn nur wenige diese Schicht verstehen und brauchen können.

Die Architektur muss deshalb zum Team und dessen Fähigkeiten passen:  Mit einer durchschnittlichen Gruppe kommt man auf der blauen oder roten Piste schneller ins Tal als auf der schwarzen. Mit Fachkräften, die 10’000 Stunden Erfahrung haben (warum 10’000 Stunden?), könnte man schwieriges meistern. Diese Experten setzen vielfach aber auf Einfachheit, denn sie wissen, dass später jemand die Software unterhalten muss, der weniger Erfahrung mitbringt.

Schichten (Tiers) blähen nicht nur die Lösung auf, sondern auch die Teams. Worauf es noch eine Management-Schicht zur Koordination braucht. Deshalb weniger Schichten, und Teams, die end-to-end Verantwortung haben.

Schnittmenge: Analyse und Entwicklung

Die Unmöglichkeit, die Anforderungen einer komplexen Entwicklung im Voraus festzulegen, hat zu Agilen Methoden und Prototyping geführt. Die Abgrenzung zwischen Analyse (mit Fachkompetenz in der Domäne) und Entwicklung (mit IT-Kompetenz) bleibt die Knacknuss. Entweder wird eine Anforderung schichtenweise in ein von jedem Entwickler umsetzbares Design übergeführt (und damit abgegrenzt), oder Analysten und Entwickler versuchen sich zu verstehen und arbeiten Hand in Hand („Pair Analysis & Programming“).

Einander verstehen setzt Kenntnisse der Entwicklung beim Analysten und der Domäne beim Programmierer voraus. Meiner Erfahrung ist dies ein Muss – sonst explodieren die Aufwände sofort.

Voraussetzung für ein erfolgreiches Pair Development ist auch ein schneller Turnaround für Resultate – darum bevorzuge ich interpretative und dynamische Sprachen. Ein Deployment-Mechanismus, das erst nach vielen  Minuten (oder gar Stunden!) Resultate zeigt, ist nicht effizient und  ein Desaster für ein Projekt.

Schnittmenge: Entwicklung und Testing

Schlechte Entwicklung durch Testen zu verbessern bedeutet einen immensen Aufwand. Wenn mehr als wenige Prozent von manuellen Tests anschlagen, muss die Ursache bereinigt oder zumindest die Tests automatisiert werden. Dies ist Aufgabe der Entwicklung und zwar end-to-end im Gesamtsystem. Dazu muss testen und debuggen mit sofortigem Feedback möglich sein und zwar mit echten (oder zumindest realistischen Daten). „Mock-Daten“ führen zu Illusionen und sind zu vermeiden.

Die professionellen Tester sollen Ausnahmen finde und Lücken aufdecken, nicht die Entwickler entlasten. Ein vom Testing gefundener Bug ist für den Entwickler eine Niederlage!

Schnittmenge: Prozess und Projekt

Die Rollen von Huhn und Schwein (Chicken and Pigs) im Scrum Prozess waren Unsinn, denn sie schaffen eine Abgrenzung, wo es keine geben darf, zwischen Kunden und Lieferanten. Im schlechten Fall führt dies zu kleinen, gut abgegrenzten Spielwiesen, mit vielen Stories, die schnell und sauber abgearbeitet und geschlossen werden, ohne dass das Gesamtprojekt nennenswerten Fortschritt macht. Natürlich grenzen sich die Pigs ab und suchen den Grund bei den Chicken: Analysten, externe Lieferanten, andere Architekturkomponenten, Tester, etc.

Es ist schwer, agil zu sein. Verträge sind statisch, Führungsebenen auch. Es ist wichtig, einen Scrum-Prozess nicht in einem abgegrenzten Bereich, sondern in der Realität des Projekts stattfinden zu lassen. Scrum ist dabei ein Werkzeug, nicht der Ersatz für Führung. Die Führung muss klar machen, wo agil geplant werden darf und muss, und wo die statischen Rahmenbedingungen sind und wie mit diesen umgegangen wird.

Abgrenzung: Saubere Strukturen

Oh, wir haben nun NoSQL Datenbanken, die sind dynamisch, und wir müssen kein Schema-Design mehr machen!  Relationale Integrität, ade!

Halt! Die Datenmodellierung bleibt das A und O einer erfolgreichen Entwicklung, insbesondere in einer Industrie reich an Daten. Die Lektionen, die wir in der objekt-orientierten Programmierung gelernt haben, wie Abstraktion, Kapselung und Methoden, dürfen wir nicht vergessen. NoSQL und JSON sind zusätzliche Werkzeuge zu unserer Verfügung. Weniger Wiederholungen (DRY) und Transformationen sind deren Vorteil. Wenn damit auch die Architektur einfacher wird, umso besser.

Mit einer sauberen Datenmodellierung erreichen wir ein besseres Verständnis zwischen Analysten und Entwicklern –  und damit Software, die durch Design und nicht nur durch Testing fehlerarm ist.

 

Die Essenz ist immer das schnelle Feedback

  • Ein klares grafisches Modell der Geschäftsdaten erleichert die Diskussion zwischen Analysten und Entwicklern. Feedback entsteht, bevor überhaupt mit der Programmierung begonnen wird.
  • Dynamische Programmiersprachen (z.B. Python, Ruby) geben Feedback über jede Code-Zeile.
  • Schnelles Deployment gibt Feedback über die ganze Applikation.
  • Sofortiges, automatisches Testing sagt, wo wir stehen.
  • Das Analyst-Entwickler-Paar kann in einem solchen Setting extrem schnell agieren. Es braucht und gibt keinen Mittelsmann, der halb verstandene Business-Anforderungen in halb verständliche technische Spezifikationen umwandelt.

 

Abgrenzungen aufheben

Abgrenzungen bieten oft Wohlfühlzonen, in die sich ein Subteam zurückziehen kann.

Deshalb:

  • Das Team in einer Zone zusammen bringen, am besten in einen Projektraum.
  • Alle Planungssitzungen von Subteams annullieren. Geplant wird immer end-to-end.
  • End-to-end Testing liegt in der Verantwortung der Analyst-Entwickler-Paare, die die Feature entwickeln.

Die hat sich bei einem unserer Projekte bewährt. Was sind deine Erfahrungen? Hast du Gegenbeispiele, bei denen eine geschickte Abgrenzung Erfolg gebracht hat?