Eigentlich bin ich von Scrum bzw. den agilen Methoden im Allgemeinen durchaus begeistert. Allerdings fällt mir hierzu immer wieder eine Sache auf, die ich selbst durchaus als größeres Problem einschätzen möchte. Dieses hat vorrangig mit den involvierten Personen zu tun, wird aber durch Scrum unterstützt: Prokrastination und Realitätsverweigerung.
Das Team ist der Architekt
Schon vor einiger Zeit hat Ilker Cetinkaya über die Zukunft des Architekten in der Softwareentwicklung geschrieben und darin Probleme aufgezählt, die mit dieser Rolle einhergehen. Sein Fazit war, dass diese Rolle ausgesorgt hat.
In der Definition eines Teams durch Scrum schreibt Wikipedia:
The Development Team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each Sprint (the Sprint Goal). A Team is made up of 3–9 individuals with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.).
Das gesamte Team muss also die Aufgabe des Architekten wahrnehmen. Es gibt keinen dezidierten Architekten. Jeder kann diese Rolle einnehmen und vor allem – sollte sie einnehmen.
Fokusierung
Werte wollen geschaffen werden. Umsetzungen müssen einen messbaren Mehrwert erzielen. Zeit soll also nicht vergeudet werden. Dazu muss man sich auf ein Set an Aufgaben fokusieren. In Scrum gibt es hierfür einen Zeitraum definierter Länge namens Sprint. Dieser dauert überlicherweise zwei Wochen, manchmal länger, manchmal aber auch kürzer. Für diesen Sprint nimmt sich das Team eine Liste an Anforderungen vor und verspricht dem Product Owner das auch zu schaffen. Als Gegenzug wird dem Team für diese Zeit Störungsfreiheit attestiert. Für das Team eine tolle Sache, kann es doch für die Dauer des Sprints ohne Störungen arbeiten (trifft eher nicht so auf Kundenprojekte zu).
Nach dem Sprint fällt der Würfel erneut und der Product Owner vermittelt dem Team seine weiteren Prioritäten und kann somit den genommenen Kurs auch mal zur Gänze ändern. Das Team fokusiert sich also auf den Sprint und den Aufgaben darin, alles weitere kommt zu einem späteren Zeitpunkt – also dem nächsten Sprint, oder dem übernächsten, oder eben irgendwann.
Mehr Informationen zu Scrum, den einzelnen Rollen etc. bietet der Scrum Guide.
Verlorener Weitblick
Auch Scrum erfordert Planung. Nur wird diese nicht nur einmal gemacht. Sie ist laufend durchzuführen. Im Idealfall sind die kommenden zwei oder drei Sprints im Backlog ersichtlich. In der Produktentwicklung muss es zusätzlich eine Vision geben. Mit dieser Vision meine ich eine Vorstellung vom Produkt in einigen Monaten oder gar ein bis zwei Jahren. Irgendwo dazwischen liegt dann auch noch eine Roadmap, aber seien wir einmal nicht kleinlich. Planung ist wichtig, wenn es gilt ein Ziel zu erreichen. Aus allen “Teilen” kann ein Rahmenwerk abgeleitet werden. Dieses Rahmenwerk kann natürlich auch technische Auswirkungen haben.
Daraus ergeben sich wichtige Informationen, die für die Schaffung der Software von Interesse sind. In der Theorie kann eine Software in kleinen Happen weiterentwickelt werden und alles ist schön. In der Realität werden über die Jahre Layer für Security-Prüfungen, Datenbringung und mehr eingezogen. Je nach aktuellem “Stand der Technik” (sprich, welches Pattern gerade durch die Stadt gejagt wird) sind diese einmal so richtig abstrakt und einmal eben festgenagelt. Vielfach kommt vor, dass sich diese Teile der Software oft nur sehr schwer bewegen lassen – wenn sich beispielsweise die Vision, also die Gesamtausrichtung der Software ändert. Und das kommt vor. Manchmal sind auch schon kleine Anforderungen aus Business-Sicht ausreichend eine größere Änderung an der Software notwendig zu machen.
Das Problem ist nun, dass sich das Team lernt, sich auf den aktuellen Sprint zu fokusieren. Es wird gewohnt, nur über aktuelle Fragen zu kommunizieren. Alles weitere wird zunehmend als Störung wahrgenommen. Das Resultat sind Phrasen á la “Brauchen wir das jetzt wirklich?” und “Machen wir das, wenn wir es brauchen.”. Dies ist für Detailimplementierungen auch korrekt. Architektur lässt sich aber nicht auf eine kleine Detailimplementierung festnageln, da benötigt es etwas Weitblick.
Niemand kann vorhersehen, was in sechs Monaten angesagt ist, wie dann die Pläne sind, ob die aktuelle Vision noch Gültigkeit besitzt. Bei einer anständigen Planung kann man aber über einige Sprints hinweg einen “Pfad” erkennen. Dieser muss beachtet und berücksichtigt werden. Es ist die Pflicht des Teams sich nicht ausschließlich auf den aktuellen Sprint zu konzentrieren, es muss sich die Offenheit für größer angelegte (und notwendige) Änderungen bewahren. Die ausschließliche Fokusierung auf das Jetzt verschiebt Probleme, die Realität wird verweitert. Schmerzen vergehen in der Regel nicht von alleine. Sie werden akut.
Wenn das gesamte Team Architekt sein soll und will, dann muss es auch in seiner Gesamtheit diese Verantwortung tragen und niemand sollte sich ihrer entziehen.
Fazit
“Wir machen das, wenn wir es brauchen”, ist daher vielleicht nicht immer der beste Ansatz. Es klingt schön und verlockend, wenn man sich nur auf das Hier und Jetzt konzentrieren kann. Wer in den Tag hinein lebt, wird seine Ziele vermutlich nicht erreichen, so ist es auch hier. Auch agile Softwareentwicklung erfordert eine gewisse Berücksichtigung der (nahen) Zukunft, auch durch das Entwicklungsteam. Ja, vor allem durch das Entwicklungsteam, denn niemand nimmt ihm diesen Job ab. Denkt darüber nach.
Update: Ilker hat hierzu einen erwähnenswerten Tweet:
RE: @norberteder t.co/8dyqdn0AcF – Ich sage euch: der Sprint ist Arbeitseinheit, nicht Denkeinheit. Limit your work, not your mind!
— Ilker Cetinkaya (@ilkerde) February 5, 2014
Update: Neues Projekt, neues Glück.
In meinem aktuellen Projekt arbeiten ca. 80 Entwickler in diversen Teams, Architekten waren nur im Team verankert, Austausch der Architekten fand nur minimal statt. Das Resultat sind Dutzende von synchronen, binären Punkt-zu-Punkt Verbindungen zwischen den Artefakten der einzelnen Teams; Konsequenz: Stagnation
Jede Änderung zieht einen Rattenschwanz an Änderungen an einer Vielzahl von Clients nach sich, die Kosten explodieren, das Management schäumt. Von Einsicht bei den Teams ist keine Spur zu sehen, ein fröhliches weiter-so und jedes Team versucht die Probleme mithilfe neuer und/oder anderer Technologien in den Griff zu bekommen. Da werden dann Microservices bemüht um mittels RESTful Schnittstellen die Punkt-zu-Punkt Verbindungen wenigstens zu ‘neutralisieren’ (das die Vielzahl der Schnittstellen ohne Koordination das Problem ist wird nicht erkannt); da werden Laufzeitumgebungen in Frage gestellt ohne zu erkennen, dass fehlende Abstraktion das Problem darstellt. Jedes Team meint alle Probleme wirklich im Griff zu haben, es liegt immer an anderen Faktoren/Teams/was auch immer.
Summa summarum geht das Management nun die ersten Schritte, externe Firmen mit Gewerken zu beauftragen um einen Beauty Contest und einen kostenbasierten Shoot-out durchzuführen. Die eigenen Entwicklungseinheiten werden zunehmend als Ballast gesehen. Und jetzt ratet mal, wer diese externen Gewerke/Dienstleister steuert: Produkt Owner und Software-Architekt. Ersterer in puncto Funktionalität, zweiterer in puncto Technik und Qualität.
Am Ende des Tages kann man nur raten, sich mal mit TOGAF auseinanderzusetzen, die Microsicht wird per reiner Selbstorganisation funktionieren, die Makrosicht wird es nicht; Zufall in der Zielidentität / -findung ersetzt niemals Planung.
PS
Wer meint, dass solche Outsourcing-Projekte zum Scheitern verurteilt sind irrt, manchmal sind es nicht nur die Kosten, die in eine solche Betrachtung einfließen, da sind rechtliche Aspekte (bspw. Gewährleistung), steuerliche Aspekte (bspw. Abschreibungsmöglichkeiten) und Skalierung (bspw. Personal und Auftragsvolumen) adressiert. Machmal will das Management auch nur Handlungsfähigkeit zurückgewinnen.
Die Frage, ob man einen SW-Architekten braucht, lässt sich gut durch Betrachtung einer anderen Branche beantworten. Stellen wir uns vor, wir bauen ein konventionelles Haus. Nun lassen wir es etwas anders angehen und verzichten auf den Archtekten. Schließlich, jeder von uns hat schon mal ein Haus in seinem Leben gesehen und hat vielleicht sogar eigene Ideen, wie man sowas macht. Also entscheidet der Bauherr (kann als Kunde oder PO gesehen werden) ein paar grundlegende Sachen selber. Und dort, wo ihm die Kompetenz fehlt, greift er auf seine Bauarbeiter (Softwareentwickler) und fragt sie. Z.B. welche Materialien soll man am besten verwenden, oder wo soll man die Treppe plazieren, usw. Unsere Baurarbeiter sind alle sehr motiviert und jeder von denen hat schon auf vielen verschiedenen Baustellen gearbeitet. Die diskutieren fleißig alle möglichen Optionen durch (basierend auf ihren Erfahrungen) und im besten Fall einigen sich auf ein Kompromiss. Dieser Kompromiss kann ganz unterschiedlich ausgehen, aber eins steht fest – es wird dramatische Konsequenzen fur den Bauherrn haben.
Hier halten wir kurz an, schließen die Augen und überlegen, ob wir das im realen Leben mit unserem hart verdienten Geld auch machen würden. Meine innere Stimme sagt mir – nein! Neulich habe ich von einem Scrum-Coach gehört, dass in jedem Softwareentwickler ein Stückchen Softwarearchtekt drin steckt. Das stimmt. Auch in jedem Bauarbeiter steckt ein Stückchen Archtekt und in jeder Krankenschwester steckt ein Stückchen Neurochirug. Aber würdet Ihr Euch gerne von einer Krankenschwester gerne operieren lassen?
Dass es schlechte Softwarearchitekten gibt, steht außer Frage, aber genauso gibt es schlechte SW-Entwickler, Ärtze und Bauarbeiter. Genauso gilt, dass talentierte Amateure es schaffen, ein Haus zu bauen oder eine einfache App zu programmieren. Dies kommt aber extrem selten vor.
Worauf genau willst du hinaus? Genau beim Hausbau hast du eindeutig die Rolle des Architekten verankert.
Prinzipiell stimme ich dir zu, ein klassischer Architekt der im Elfenbeinturm sitzt, ist nicht zeitgemäß und in vielen Konstellationen auch nicht angebracht.
Wenn wir Scrum Teams betrachten (oder agil arbeitende Teams), ist ein Architekt nicht per se unnötig. Je nach Größe des Projekts, Erfahrung des Teams, Größe des Unternehmens und verwendeter Technologie kann es sehr gut sein, Architekten zu haben. In vielen Fällen ist einem Projekt/Produkt besser geholfen, wenn das Team diese Aufgaben gemeinschaftlich übernimmt. Aber eben nicht immer.
Ich hatte in zwei aktuellen Projekten, die ich begleitet habe, den Wunsch des Teams, einen dedizierten Architekten zu haben. Einfach weil das Setting dies erforderlich gemacht hat.
Dieser Architekt sollte die von Matthias gezeigten Eigenschaften haben, um dann eine gute Arbeit zu machen. Aber er kann mit Erfahrung und den richtigen Fragen vieles besser machen. Und Zeit dafür aufwenden, Irrwege zu gehen und neue Ideen in ein Unternehmen oder Team zu bringen.
So wie in einer klassischen Hierarchie die Detailkenntnis und Detailverliebtheit nach oben hin (notwendigerweise) abnimmt, ist der Architekt auch jemand, der nicht mehr nur Details sieht wie ein Entwickler, sondern auch einen größeren Kontext. Manche Entwickler können das, manche nicht. Ein Architekt ist hier ein Moderator zwischen Technik und Business auf Seiten der Technik.
Über weite Strecken habe ich vom klassischen Architekten gesprochen. Matthias hat mir da neuen Input gegeben, der wirklich sehr wertvoll ist. Auch deine Antwort, Sven, hilft mir sehr gut, meine Gedanken weiter zu entwickeln. Ich möchte dir über weite Strecken zustimmen.
“Zeit dafür aufwenden, Irrwege zu gehen”: Bin ich bei dir. Gleichzeit fängt hier mein Problem an. Ich versuche es zu erklären (im Kontext einer klar festgemachten Architekten-Rolle). Meine Erfahrung hat mich gelehrt, dass ein Architekt überall mit einbezogen wird. Das ist ja grundsätzlich nicht schlecht. Nur sitzt er am Ende des Tages mehr in Meetings, als sich um die eigentlichen Problemstellungen zu kümmern. Etwaige Evaluierungen, Vorschläge, Tests, Prototypen etc. sind mal eben zusammengeschustert. Ich habe schon erlebt, dass das vom Architekten in die jeweiligen Projekte direkt übernommen wurde und de facto alle vor vollendete Tatsachen gestellt wurden. Die Lösung der darauffolgenden Probleme oblag dann natürlich dem Team, nicht dem Architekten. Wie gesagt, das ist _meine_ Erfahrung und mir ist bewusst, dass es wirklich sehr sehr gute Leute da draußen gibt, die das richtig machen und sich nicht zu sehr von allen Seiten vereinnahmen lassen. Es sind derer aber weit weniger, als erhofft.
Architektur im Zeitablauf.
Zu allen obigen Ausführungen möchte ich eines noch hinzufügen: Die Degenration von Architektur im Zeitablauf. Die bisherige Diskussion dreht sich wohl mehr oder weniger um die initiale Rolle der Architektur und die initiale Rolle des Architekten. Es gibt sehr interessante Ausführungen von Ward Cunningham darüber, was passieren kann, finden entsprechende Aspekte der Arcitektur nicht genügend Niederschlag. Er nennt es Technical Debt (martinfowler.com/bliki/TechnicalDebt.html).; Fowler spricht weiterhin von Design Stamina martinfowler.com/bliki/DesignStaminaHypothesis.html. Summa summarum, es kann manchmal gut sein, der Architektur wenig Augenmerk zu widmen, die technischen Schulden holen einen aber früher oder später ein.
Die Entscheidungen hierüber dem Team zu überlassen ist faktisch nicht richtig da diese vom Team gar nicht überblickt werden können. Das sind Managemententscheidungen! Wenn der Product Owner das Product Backlog und die Abarbeitungsreihenfolge bestimmt, warum macht das eigentlich nicht das Team? Ist ‘das Team’ nicht qualifiziert genug? Also: Warum gibt es einen Product Owner aber keinen Architectural Owner?
Faktisch endet man schnell in etwas, was in etwa so aussieht: aim42.github.io/ (siehe die Grafik, rechts scollen!: Verständlichkeit nimmt ab, Änderungskosten nehmen zu). Auch ist der Product Owner IMHO nicht der Richtige, es entspricht nicht seiner Rolle: Er trägt die Verantwortung dafür, daß die richtigen Anforderungen im Product Backlog stehen und daß sie in einer sinnvollen Reihenfolge abgearbeitet werden. Dadurch hat er maßgeblichen Einfluß auf das Arbeitsergebnis und ist, so gesehen, wirklich die eine Person, deren “Hals gewürgt wird”, wenn das Team – gemäß Vorgabe – Mist produziert (aus: scrum-master.de/Scrum-Rollen/Scrum-Rollen_Product_Owner).
Zum Architekten … ist er obsolet?
Zunächst mal: Wer ist ‘das Team’? In meinen Projekten arbeiten zumeist 5-6 Teams parallel … Wer hat jetzt die Verantwortung? Jedes Team für seine Architektur?
Ich analysiere gerade eine große Applikation eines Automobilherstellers hinsichtlich Modifizierbarkeit an zukünftige Anforderungen, bin also in der Rolle des Architekten unterwegs. Die Applikation wurde modular von verschiedenen Teams und verschiedenen Firmen über 16 Jahre in Java entwickelt. Für mich ist diese Applikation geradezu das Paradebeispiel, warum man einen Architekten haben muss. Jede dieser Komponenten – über den Schnitt der fachlichen Komponenten möchte ich mich garnicht erst auslassen – hat je nach individuellen Fähigkeiten der Teammitglieder etwas implementiert was bestenfalls funktioniert aber nicht notwendigerweise über lange Zeiträume betreibbar oder weiterentwickelbar ist. In nahezu jeder Komponente sind die unterschiedlichsten Technologien und Paradigmen vereint, in den seltensten Fällen aber konsistent über 2 Komponenten hinweg. Als Konsequenz hat man im Zeitabluf eine Chimäre geschaffen für deren ‘Zähmung’ nunmehr Teams vonnöten sind, die die Obermenge aller verwendeten Technologien und Paradigmen beherrschen müssen: 5 JavaScript Frameworks, 2 – 3 Java UI Frameworks (Spring MVC, Struts 1.3 und Vaadin), 2 Integrationsframeworks, 3 Persistenzframeworks, Spring und JavaEE bunt gemischt, Business Logik in den MVC Controllern oder sogar im Browser, Spring Integration und Datenimporte mittels Stored Procedures … usw.
Hier war jedes Team für die Architektur verantwortlich doch niemand für die Gesamtarchitektur im Zeitablauf. Konsequenz: Neuentwicklung mit Aufwand von mehreren Millionen Euro, diemal anhand einer Referenzarchitektur, den entsprechenden Architekten etc.
Mit Verlaub, die Einschätzung Architeken sind überflüssig ist ein aus mangelnder Praxis im Großprojektumfeld geborener Trugschluß. Architekten beraten die Teams, limitieren die Entscheidungsspielräume in technischer Hinsicht und geben die übergeordneten Strukturen. Einzig der Punkt, dass Architekten das Bindegleid zwischen Kunden und Entwicklung sind … da sehe auch ich den Product Owner … der dann wahrscheinlich auch Architekturkenntnisse haben muss.
Vielen Dank für dein sehr wertvolles Feedback, das ich nachvollziehen kann. Ich war selbst lange Zeit der Meinung, dass ein Architekt existieren muss, damit ein Projekt technisch ideal gelenkt werden kann. Mittlerweile – eben aufgrund meiner gewonnenen Erfahrung – sehe ich das anders. Aber ich möchte das kurz erklären.
Ich selbst habe lange Jahre als Architekt gearbeitet und brauchte diese Erfahrung, um den Mehrwert von Teams und Teamentscheidungen zu erkennen. In jedem lebt ein kleines (oder größeres Ego) und es widerstrebt, dass alle zu einer Entscheidung beitragen (wo doch die eigene Lösung die beste ist). Aber das passiert so auch nicht. Meiner Erfahrung nach enthalten sich die meisten ihrer Stimme und nur ganz wenige (und immer dieselben) bringen ihre Meinung zum Ausdruck. Gehört wird, wer konstruktiv ist, einfache und gute Lösungen vorbringt. Ignoriert und “ausgeschlossen” werden diejenigen, die schlechte Stimmung verbreiten und nichts zur Problemlösung beitragen. Aus diesen technisch fundierten Gesprächen werden Entscheidungen gefällt. Entscheidungen, die meist gut für das Projekt und die Teams sind. Positiver Nebeneffekt: Es herrscht Transparenz, Wissen, Erfahrungen und Zusammenhänge werden auf alle verteilt, Zusammenarbeit/Synergien gefördert. Wissensdefizite einer einzelnen Person werden ausgeglichen bzw. abgeschwächt, es kommt seltener zu Fehlentscheidungen. Das funktioniert aber nur, wenn Gleiche mit Gleichen sprechen.
Die Geschichte hinsichtlich “Architekt” ist eine sehr schwierige, wie ich finde. Oftmals ist der Architekt zugleich der Lead des/der Teams. Nach oben fällt bekanntlich nicht immer der beste seines Fachs, gerne ist es, wer sich am besten präsentiert. Selbst als Nicht-Lead bleibt jedoch eines am Ende des Tages stehen: Er trifft Entscheidungen über Frameworks, Techniken, Werkzeugen etc. Oftmals, ohne aktiv mit ihnen zu arbeiten, da zu weit von der “Basis” entfernt. Deshalb sind auch die wirklich üblen Problemstellen vielfach nicht bekannt und werden so auch nicht berücksichtigt. Der Architekt stellt Schätzungen für Projekte von teilweise mehreren tausend Manntagen an. Das ist schon in einer Gruppe von mehreren Teams Utopie – und dann noch als Einzelner unter Business-Druck. Wie auch immer, es passiert soviel ohne Wissen der Team-Mitglieder. Wissen, das bei der Implementierung, der Zusammenarbeit der Teams etc. helfen würde. Wissen, das fehlt, wenn der Architekt, das Unternehmen/Projekt verlässt, krank wird, stirbt.
Durch Kommunikation bedarf es eines einzelnen Architekten nicht. Wissen kann so besser gebündelt, eingesetzt und gestreut werden. Ein ganz klarer Vorteil. Softwareentwickler müssen für mich ohnehin Architektur-Skills mitbringen bzw. gewillt sein, dahingehend zu lernen. Architekten, die seit Jahren (oder Jahrzehnten) nicht mehr entwickelt haben, sollten eher in andere Bereiche wechseln. In Bereiche, wo sie weniger kaputt machen können.
Dein aktuelles Projekt verhielt sich in der Vergangenheit ja insofern ungeschickt, als dass durch die “modulare” Entwicklung wohl vordergründig die Kommunikation abgetrennt wurde. Dadurch werden keinerlei Synergieeffekte genutzt, da kennen sich teilweise die Teams gar nicht. Das potenziert sich natürlich, wenn da auch noch weitere Unternehmen mit ihren Teams daran herumschrauben. Die bekommen vom Architekten ein paar Dokumente und das war es dann. Den aktuellen Stand spiegeln die kaum wider. Dass der Architekt alles im Griff hat, mehrere Teams mit Informationen versorgen kann, ist ein Irrglaube. Nichteinmal Ehepartner wissen alles, wie soll es da dem Architekten mehrerer Teams ergehen? Auch mehrere Architekten helfen hier wenig.
Architekten als Bindegleid zwischen Kunden und Entwicklung sehe ich zudem als sehr kritisch an. Zum Kunden muss jemand, der ihn versteht und mit ihm in dessen Sprache reden kann. Einem durchtrainierten Architekten würde ich in dieser Rolle nicht sehen. Deswegen, einfach nicht dazu werden lassen, dann kann jeder mit dem Kunden reden (bzw. Product Owner werden, der das dann kann/soll/muss).
Bezeichnest Du Dich dann jetzt als Entwickler und nicht mehr als Architekt?
Ein Architekt der seine Gedanken nicht mit dem Team teilt ist kein guter Architekt, ein Architekt der einfach diktiert ist kein guter Architekt, ein Architekt der nicht implementiert ist kein guter Architekt. Kommunikation ist gut, keine Frage aber wer moderiert, entscheidet und steht dafür gerade? Wer das mittlerweile mehr als 35 Jahre alte Buch von Brooks gelesen hat (Mythical Man Month) weiß, dass es hier wohl so einiges zu beachten gibt.
Frederick P. Brooks, Jr., wrote of the qualities and characteristics of a successful architect. These are listed next:
An architect “suggests” (“not dictates”) implementation because the programmer/coder/builder has the “inventive and creative responsibility.”
An architect should have an idea of how to implement his or her architecture, but should be “prepared to accept any other way that meets the objectives as well.”
An architect should be “ready to forego credit for suggested improvements.”
An architect should “listen to the builder’s suggestions for architecture improvements.”
An architect should strive for work to be “spare and clean,” avoiding “functional ornamentation” and “extrapolation of functions that are obviated by changes in assumptions and purposes.”
ABER wenn Architekten dahin wechseln sollen, wo sie weniger kaputtmachen können, dann halte ich dem entgegen, dass es genügend Entwickler und genügend Architekturen gibt, in denen technikverliebte Entwickler Dinge hochgezogen haben die Ihren CV beautifizierten aber ansonsten vollkommener Humbug waren und keinerlei Nutzen für den Kunden beinhalteten. jBPM oder andere Workflow Engines für den ScreenFlow oder ESB nur weil man das Filesystem nach FTP übermittelten Dateien scannt; ist alles schon dagewesen und war ein entsprechendes Desaster. Wartungskosten die durch die Decke gehen und Weiterentwicklung dann auch irgendwann ausgeschlossen.
In den Projekten in denen ich die Entwicklungsleitung hatte, den Chef-Architekt spielte o.ä. war es manchmal mühsam war, den Entwicklern die technischen Flausen auszutreiben. KISS ist für viele ein Fremdwort … was ist denn auch den Hype-Technologien der letzten 10 Jahre geworden (MDA, JDO, iBatis, Ruby on Rails, you name it), wieviele kann man heute noch als ‘angemessen’ bezeichnen und wieviele sind grauenhafte (Java) Legacy Monster? BigData, NoSQL, Solr und Hadoop everywhere? Schlage in einem Team sowas vor und alle werden begeistert sein … sexy Technologien, da sagt niemand nein.
Ich denke Scott W. Ambler trifft den Nagel auf den Kopf, es muss neben dem Product Owner auch den Architectural Owner geben: agilemodeling.com/essays/agileArchitecture.htm
Jetzt nehmen wir mal eine große Institution … sagen wir mal VW … 2.500 Applikationen die weiterentwickelt, neu implementiert werden müssen oder nur betrieben werden müssen. Da soll jedes 15-köpfiges Scrum Team entscheiden wie die Architektur der einzelnen Applikation aussehen soll? Das wirst Du niemals so vorfinden, da gibt es verbindliche Referenzarchitekturen inkl. Beispielen und das war es dann. Richte dich nach Ihnen und gut, ansonsten au revoir. Da stehen Dinge wie Compliance und Architekturmanagement im Vordergrund. Da gibt es 1-2 freigegebene App.-Server, 1 Datenbank, 1 Persistenzframework, 2-3 UI Frameworks. Pattern manifestieren sich in den Beispielen der Referenzarchitektur. Anders würden die Wartungsteams doch nie klarkommen.
Da darfst Du Dir als Entwickler noch den Komponentenschnitt definieren und die Klassennamen. Weißt Du, was das komische ist? Die Projekte funktionieren … funktionieren sogar agil.
Ich bezeichne mich als Softwareentwickler und mache das, was gerade notwendig ist.
Du schreibst, dass ein Architekt, der nicht implementiert und schlecht kommuniziert, ein schlechter Architekt ist. Stimme ich dir zu. Je mehr Teams es gibt, umso schwieriger wird Kommunikation (da gibt es in einem 5er Team schon Probleme) und Real-World-Implementierungen sind dann auch eher selten. Hier kenne ich dann nur Prototypen und Case Studies. Mit der täglichen Arbeit hat das dann meist nichts zu tun. Das ist aber auch vielfach gar nicht die Schuld des Architekten, sondern vielmehr fehlt ihm die Zeit (siehe Meetings, Schätzungen, Konzepte usw.).
Gerade stehen: Wenn das Produkt/die Lösung unbrauchbar ist, muss der Product Owner gerade stehen. D.h. er hat zu sorgen, dass die richtigen Leute zusammen kommen und Entscheidungen fällen. Je weniger technisch versierte Personen beteiligt sind und je größer das Projekt ist, umso wahrscheinlich ist, dass es in die Hose geht. So meine ganz persönliche Empfehlung. Also lieber Ideen/Konzepte/Vorschläge in einem größeren Umfeld besprechen. Die anfänglichen Konzepte können ja von einzelnen Personen ausgearbeitet werden, es muss aber eben nicht immer dieselbe sein. Hier muss stärker auf die Fähigkeiten aller Beteiligten eingegangen und die optimale Wahl getroffen werden. Das widerspricht dem Architekten-Gedanken.
Wir sind uns einig, dass es Vorgaben geben muss. Darauf müssen sich die Teams einigen. Alle zusammen. Das tut einmal weh, aber dann kommt auch niemand mehr aus.
“Technikverliebtheit/Säue im Dorf”: Ja, da gibt es Beispiele en masse. Gefragt sind hier aber erfahrene (dennoch aufgeschlossene) Entwickler, die dem Einhalt gebieten und eben nicht alles zulassen. Das trifft aber eben auch wieder das Thema der gemeinsamen Entscheidung was “erlaubt” ist und was nicht, eben ein gemeinsames Verständnis wie Softwareentwicklung betrieben wird. Ein Architekt (oder mehrere davon) schützen vor dieser Problematik auch nicht zwangsweise.
Hinsichtlich KISS etc. sprichst du mir aus der Seele, das sehe ich genauso. Dass es diesbezügliche Weiterentwicklungen der Teams gibt, dafür gibt es Leads. Diese sorgen für die Weiterentwicklung der Teammitglieder. Das muss über Gespräche, teilweise Dojos, manchmal mit ein wenig Druck passieren.
Architectural Owner:
“Architecture owner is different than the traditional role of architect. In the past the architect would often be the primary creator of the architecture and would be one of the few people who worked on it. They would often develop the architecture and then “present it” to, or more accurately force it upon, the development team. An architecture owner collaboratively works with the team to develop and evolve the architecture. Although they are the person with the final decision-making authority when it comes to the architecture, those decisions should be made in a collaborative manner with the team.”
Ich denke, wir sind uns einig, dass die ursprüngliche, alte Architektenrolle Vergangenheit sein sollte (davon gibt es leider noch zu viele). Die Rolle des Architectural Owners gefällt mir ansich ganz gut, würde jedoch den Schritt weiter gehen und meinen (wie oben bereits angedeutet), sie muss je nach Kompetenz wechseln. Nur so ist sichergestellt, dass die optimale Lösung in angemessener Zeit gefunden werden kann.
Dein Beispiel mit VW: Nein, es ging mir nicht darum, dass jedes der Teams entscheidet, wie die Architektur auszusehen hat. Es ging mir darum, dass sie gemeinsam entscheiden, wie sie entwickeln wollen und was die Rahmenbedingungen sind bzw. sein müssen. D.h. der Output ist derselbe (hinsichtlich Referenzimplementierungen, Standards usw.). Der Unterschied ist, dass die dezidierte Rolle des Architekten eingespart wird und die Teams direkt miteinander kommunizieren, nicht über den Umweg eines Architekten. Denn da kommen noch die jeweiligen Product Owner hinzu usw. In alt-eingesessenen Institutionen ist das natürlich schwer zu verwirklichen, da es einigen an den Kragen geht und andere aus ihrer Ecke hervor kommen müssen.
Ich sehe das auch so. Wenn man in einem SCRUM-Team darauf hinweist, hört man nur: YAGNI.
Und in der Tat, an YAGNI ist ja auch was dran. Die Schwierigkeit ist, den goldenen Mittelweg zu finden.
Das ist in der Tat schwierig. Das Team hat eine Verantwortung gegenüber dem Product Owner, da ja ein Versprechen gegeben. Es hat jedoch auch eine Verantwortung hinsichtlich der Softwarearchitektur. Diese Verwantwortungen sollten aus meiner Sicht vorrangig erfüllt werden. “Nice to have” Features und Co. müssen hinten anstehen.
Sehe ich genauso – SCRUM, wie auch ein Pattern oder eine Technologie ist kein Silver Bullet, sondern ein Prozzess, dem folgend, die Qualität erhöht werden kann, aber nur unter der Berücksichtigung der ‘Basics’ – ich empfehle die cross-cutting concerns wiederholend als task einzuplanen, durchaus in gruppenarbeit, genauso wie die dokumentation als deliverable (backlog-item) dazu. Damit ist es für das Team im ‘üblichen Rahmenwerk’ und kann wie gewohnt abgearbeitet und abgenommen werden.
Vielen Dank für deine Vorschläge/Gedanken. Ich bin noch auf ein weiteres Problem gestoßen, welches ein Vorläufer zu diesem sein kann, zumindest Mitschuld trägt. Eventuell lässt sich durch eine diesbezügliche Änderung etwas erreichen. Ein Blog dazu folgt.