Seite 4: Fazit

Inhaltsverzeichnis

Zusammenfassend lässt sich sagen, dass der Weg steinig sein kann. Bei Studitemps hatten die Beteiligten das große Glück, dass alle Fachabteilungen an neuen, besseren Prozessen und Standards mitgearbeitet haben. Die fachliche Expertise ist bei der Softwareentwicklung sicherlich von großem Nutzen und kann passgenau zugeschnittene Anwendungen ermöglichen. Jedoch verschwimmen die Grenzen der Benutzergruppen zunehmend und die aktuelle Entwicklung muss den Änderungen standhalten. In diesem Fall hilft Domain-driven Design (DDD) und insbesondere die Bounded Contexts, um eine klare Abgrenzung zu gewährleisten.

Die Schnitte in der Softwarelandschaft scheinen zu Beginn immer klar und offensichtlich zu sein, doch sobald es tiefer in die Details geht, kann sich der Wunsch nach einer Verschiebung oder weiteren Schnitten ergeben. Der Entwicklungsprozess und die Teams müssen mit den Veränderungen umgehen können und sie aktiv vorantreiben. Andernfalls läuft man schnell Gefahr, den nächsten Monolithen zu entwickeln und die neu erlangten Denkweisen zu vernachlässigen.

Außerdem ist die Lernkurve von DDD nicht zu unterschätzen. Über die Zeit entwickeln verschiedene Scrum-Teams einen unterschiedlich ausgeprägten Kenntnisstand, auf dem sie arbeiten. Die Wissensschere darf nicht zu groß werden, da sonst die teamübergreifenden Zusammenarbeiten leiden und die gesamte abteilungsweite Entwicklung ausgebremst würde. Um den Umständen entgegenzuwirken, muss zum einen genügend Zeit zur Fortbildung der einzelnen Teammitglieder eingeräumt und zum anderen teamübergreifende Gremien installiert werden, die einen Erfahrungsaustausch ermöglichen. Hier haben sich bei Studitemps die Communities of Practices (CoP) etabliert, die einen Rahmen für einen themenbezogenen Austausch unter interessierten Mitarbeitern schaffen. Das kann vor allem zu Beginn eine große Investition sein, die über die Zeit aber schnell wieder eingeholt wird.

Abschließend sei gesagt, dass man die Fachabteilungen in der Entwicklung von Beginn an einbeziehen sollte. Jedes Team muss einen Weg finden, die Stakeholder aus den entsprechenden Abteilungen einzubeziehen. In regelmäßigen Reviews, am Ende eines Scrum-Sprints, lassen sich wertvolle Erkenntnisse gewinnen und das Entwicklerteam kann in Gesprächen viel Hintergrundwissen aufgreifen. Außerdem werden das Vertrauen in die Software und die weitere Zusammenarbeit gestärkt. Eine bedarfsgerechte Softwareentwicklung ist somit jederzeit sichergestellt.

Hendrik Gebhardt
ist Software Engineer bei der Studitemps GmbH und beschäftigt sich seit über 10 Jahren mit verteilten Systemen.

Dirk Ziegener
ist Head Of Development & IT bei Studitemps und beschäftigt sich schon sein halbes Leben mit Software-Entwicklungsteams und der digitalen Produktentwicklung. Dabei wird er nicht müde zwischen den Welten der Softwareentwicklung des Designs der Nutzer und Stakeholder zu vermitteln. Manchmal sogar mit Erfolg.

(mdo)