Data Science
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?
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.”
Teams, die sich sauber abgrenzen, erzeugen Zwischenräume. Issues fallen zwischen “Stuhl und Bank”:
Teams mit Overlap erscheinen als kompakte Einheit:
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.
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(öffnet ein neues Fenster)). 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, 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.
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 nach 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.
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 finden und Lücken aufdecken, nicht die Entwickler entlasten. Ein vom Testing gefundener Bug ist für den Entwickler eine Niederlage!
Die Rollen von Huhn und Schwein (Chicken and Pigs(öffnet ein neues Fenster)) 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, wo die statischen Rahmenbedingungen sind und wie mit diesen umgegangen wird.
Wir haben nun NoSQL(öffnet ein neues Fenster) Datenbanken, welche dynamisch sind und müssen daher 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(öffnet ein neues Fenster)) 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.
Abgrenzungen bieten oft Wohlfühlzonen, in die sich ein Subteam zurückziehen kann.
Deshalb:
Die hat sich bei einem unserer Projekte bewährt. Was sind deine Erfahrungen? Hast du Gegenbeispiele, bei denen eine geschickte Abgrenzung Erfolg gebracht hat?
Head Application and Business Services
Finde deinen Job oder die Karrierewelt, die zu dir passt. In der du mitgestalten und dich weiterentwickeln willst.
Was du draus machst, ist was uns ausmacht.
