Suche
Be pragmatic, not dogmatic!

“Softwarearchitekten sind zu teuer, sowas muss ein erfahrenes Team selbst hinbekommen”

Joachim Arrasz
shutterstock_67400296

©Shutterstock/ Kirill__M

Dogmatismus wie auch Pragmatismus werden oft als Ausrede für verschiedene Unarten innerhalb der Softwareentwicklung genutzt. In dieser Kolumne wollen wir verschiedene Beispiele für beides vorstellen und hoffentlich spannend diskutieren. Heute geht es um die beiden Haltungen: “Softwarearchitekten sind zu teuer, sowas muss ein erfahrenes Team selbst hinbekommen” vs. ­“Mein Team soll seine Fachdomäne verstehen und muss keine Technologie-Experten hervorbringen”

Im letzten Teil der Kolumne haben wir über die Vor- und Nachteile modularer Anwendungen gesprochen. Dabei vertrat ich meinen Standpunkt, dass man Anwendungen immer modular aufbauen sollte. „Das basteln wir hier noch dazu“ ist der Anfang vom Ende eines Softwareprojekts! Egal wie marginal und einfach die Änderung scheint.

In diesem Teil geht es um einen anderen, sehr wichtigen, leider meist total unterschätzen Aspekt in der Softwareentwicklung: das Team und die Homogenität innerhalb eines Teams.

Noch ein wichtiger Punkt, der unbedingt angemerkt werden muss: Alles was ich hier schreibe ist meine persönliche Meinung und spiegelt auch nur diese wieder 🙂 Diskussionen sind herzlich willkommen! Falls sich der eine oder andere Kollege angesprochen fühlt – natürlich ist alles frei erfunden und Ähnlichkeiten sind rein zufällig… 🙂

In den letzten Jahren wurde ich oft zu Kunden geschickt, welche eine initiale Analyse ihrer vorhandenen Software wünschen. Die Gründe sind meist ähnlich, wenn nicht die gleichen:

  • Stakeholder sind mit der Entwicklungsgeschwindigkeit nicht zufrieden.
  • ProductOwner bzw. Teamleiter sind mit der Qualität ihres eigenen Teams nicht recht zufrieden.
  • Das Team ist mit seiner Führung und der eigenen Qualität unzufrieden.
  • Neue Entwicklungen stehen an, und man möchte vorab eine Art „Lessons Learned“ der vergangenen Entwicklungen, um nicht die gleichen Fehler noch einmal zu machen.

Natürlich gibt es meist noch eine Menge weiterer „Problemchen“, welche ich aber nicht weiter erwähne, da sie das heutige Thema nur verschleiern.

Typischerweise beginnt eine solche Analyse fast immer mit einer Einführung durch das Management: Der Stakeholder sagt einem „Hallo“ und führt einen Monolog, warum früher alles besser war bzw. schneller ging und warum man dieses nicht einfach beibehalten kann  – und natürlich, dass man diesen Zustand wieder erreichen muss.

Als ich noch selbst entwickelt habe, wurden solche Feature Requests in weniger als 2 Tagen geliefert.

Wer hat solche Sätze noch nie aus dem Management gehört?

Danach wird man dem ProductOwner oder Teamleiter vorgestellt, welcher letztlich in das gleiche Horn bläst, mit dem kleinen Unterschied, dass dieser schon zwei Problemzonen als mögliche Ursachen des Dilemmas ansieht, den Stakeholder und natürlich sein Team.

Mein Chef vergleicht immer alles mit früher, da konnte man Features noch in einer Woche ausrollen, aber da haben wir auch noch Disketten mit den Kunden ausgetauscht. Gleichzeitig will mein Team immer nur noch mehr Selbstbestimmung, liefert seither aber noch weniger ab wie vorher.

Ein Schritt, den ich mir persönlich nicht nehmen lasse, welcher aber bei Teamleitern und Stakeholdern oft mit angezogenen Augenbrauen begutachtet wird, ist das Interview mit dem Team selbst. Innerhalb gewachsener Teams gibt es so gut wie immer eine inhärente Hierarchie: Einer war eben der erste, der sich mit fachlichen Problemen auseinander gesetzt hat. Das gleiche gilt auch für die eher technischen Themen. Meist hat irgendwer einmal begonnen, auf Basis irgendeiner Programmiersprache und irgendeinem Framework die Lösung zu implementieren.

Die Interviews innerhalb des Entwicklungsteams geben hierüber Aufschluss und zeigen auch meist die ersten Schmerzen. Wer hat eigentlich welche Rolle innerhalb des Teams und aus welchen Gründen? Fragen, die sehr oft mit gewachsenen Hierarchien beantwortet werden, oder mit Neueinstellungen, die sich zu Beginn sehr gut verkaufen („als Student hat man noch genügend Zeit, Magazine, Blogs und Co. zu lesen“). Prinzipiell ist das so auch noch alles in Ordnung, wenn man gewisse Grundregeln beachtet.

Schlussendlich kommt so gut wie immer ans Tageslicht, dass es deutlich zu wenig Strukturen gibt, welche Verantwortungen und deren Grenzen innerhalb des Teams organisieren. Dadurch gibt es meist aber keine überschneidenden Themen, sondern viel mehr Themen, die nicht besetzt sind!

Nicht besetzte Themen sind schlussendlich aber die Wurzel des gescheiterten oder kriselnden Projekts. Warum? Kommen wir also zu meiner Meinung zu dieser Kontroverse…

Meine Meinung zu dieser Kontroverse

Man sollte die erfahrenen Entwickler weiter an ihrer Spezialität, dem Verständnis für die Fachdomain, arbeiten lassen. Diese Expertise wird von den Kollegen, welche sich um den technischen Stack kümmern, dringend benötigt, um Mengengerüste und SLA-Anforderungen erfahren, einschätzen und berücksichtigen zu können.

Darüber hinaus ist es natürlich so, dass fachliche Probleme und Anforderungen ständig hinzukommen, man die Architektur aber eher selten in Frage stellen wird, solange man in einem Produkt / Projekt erfolgreich arbeitet. Natürlich muss man den Stack pflegen, dies bedeutet aber nicht automatisch, dass man ihn weiter entwickeln muss, sondern kann auch bedeuten, dass man aktuelle Versionsupdates genauer nach Bugfixes und neuen Features inspiziert.

  • Ist meine aktuelle Architektur und Entwicklungsgeschwindigkeit in Ordnung?
  • Sind wir als Firma bereit, genügend für Fortbildung, Forschung und Schulungen der Kollegen zu bezahlen, welche sich um Architekturen und technische Stacks kümmern sollen?
  • Belangen Versionsaktualisierungen meiner eingesetzten Werkzeuge, Frameworks und APIs meine aktuelle Situation?
  • Welche Auswirkungen und Kosten hat es, wenn ich dieses Mal den Versionssprung nicht mitmache?

Wenn man diese Fragen nüchtern im Team beantwortet, bekommt man ein besseres Gefühl, ob der Software-Architekt dauerhaft oder in Zyklen oder gar überhaupt nicht mehr gebraucht wird. Auch könnte man die Architektur über automatisierte Tools wie z.B. ein SonarQube überwachen. Dies hat einige Vorteile:

  • Dokumentation der Architektur über einen Descriptor für das automatisch arbeitende Werkzeug
  • Das Team hinterfragt sich zumindest beim Erstellen des Descriptors, ob das alles so seine Richtigkeit hat

Somit kommen wir nun zur Zusammenstellung eines Teams, welches obige Fragen überhaupt beantworten kann. Meiner Meinung nach sollte ein Team eigentlich keinen externen Architekten brauchen, sondern diese architektonischen Fragen selbst beantworten. Das geht natürlich nur, wenn das Team genügend ausgebildet wurde, oder aber Berater für die technischen Fragen herangezogen werden können.

Diese Berater sollten nicht eben mal schnell „Hallo“ sagen, jede Menge digitales Papier produzieren, sondern ein Projekt dauerhaft begleiten, um nach und nach auch mehr der Fachdomain zu verstehen. Architekten die mit Buzzwords und neuen Technikstacks von Beginn an um sich werfen, sollte man meiner Meinung nach meiden –  solche Leute gibt es in jedem Team ohnehin genug! Kritische Fragen, wie man einen guten Berater erkennt, gibt es an anderer Stelle genügend zum Nachlesen 🙂

Was also braucht man im Team eigentlich? Man braucht mutige, erfahrene, vorsichtige aber auch ausdauernde Charaktere. Das klingt nicht ganz so einfach, oder? Letztlich ist es das aber, da diese Charaktereigenschaften über die Jahre wachsen, sich verändern oder auch schärfen.

Jeder von uns begann doch einmal damit, Magazine zu lesen, sie aufzusaugen und neugierig alle technischen Veränderungen zu verfolgen. Nach und nach haben uns dann die eigentlichen Probleme der Softwareentwicklung eingeholt und man merkte, dass Frameworks und Tools sehr exakt auszuwählen sind, da sie einen ein Projektleben lang begleiten. Somit haben wir den mutigen Charakter in Form von Junioren (meist) ohnehin im Team. Wenn ein Junior im Team ist, muss es meiner Meinung nach den Senior geben („There is always a master and an apprentice“), welcher mit ihm in diesem Projekt arbeitet, sein Mentor und sein Beschützer ist (wie soll er sonst mutig bleiben?). Typischerweise ist der Senior auch meist der eher vorsichtige Kollege, aus der (bisherigen) Erfahrung heraus. Ach ja, „Senior“ ist eine Verpflichtung, eine Rolle, kein Status!

Wenn nun der Architektur-Berater mit diesen Kollegen eine Architektur oder einen technischen Stack erarbeitet, wird er mit verschiedenen Charakteren konfrontiert und hat somit für beide Kollegen Fragen zu beantworten – und genau dazu ist er auch da!

Wenn wir dieses Szenario nun einmal ein paar Monate oder auch Jahre genau so durchspielen, kommen wir zu Teams, welche selbst in der Lage sind, Architekturen einzuschätzen, ähnliche Anforderungen mit ihrem erlernten Werkzeugschatz zu lösen. Der Architekt wird dann überflüssig und kann vom Team ersetzt werden. Man braucht ihn erst wieder, wenn es um neue Anforderungen geht, wenn Prozesse nicht mehr ineinander greifen und dergleichen.

„Natürlich haben wir den Entwickler mit der meisten Erfahrung in unserem Kerngeschäft mit der Architektur beauftragt“

Aufmacherbild: Business team work building a puzzle von Shutterstock / Urheberrecht: Kirill__M

Geschrieben von
Joachim Arrasz
Joachim Arrasz
Joachim Arrasz ist als Software- und Systemarchitekt in Karlsruhe bei der synyx GmbH & Co. KG als Leiter der CodeClinic tätig. Darüber hinaus twittert (@arrasz) und bloggt er gerne (http://blog.synyx.de/)
Kommentare

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.