Follow my new blog

Mittwoch, 8. August 2012

Architekturbewusstsein verkörpern

Gibt es wirklich keine Zukunft für Software-Architekten? Ilker Cetinkaya hat in seinem Blog-Artikel so geurteilt.

Wohlgemerkt meint er die Rolle bzw. Position des Software-Architekten, nicht den Aspekt Software-Architektur. Im Gegenteil!
"[Ich empfinde] es als absolut notwendig, die Aufgaben der Architektur nicht auf Positionen oder Personen zu restriktieren, sondern sie als allgemeines Aufgabenfeld in der Software-Entwicklung zu betrachten."
"Schlußendlich sollte es in einem agilen Team meiner Auffassung nach das Ziel sein, auch die Aufgaben der Architektur gemeinschaftlich im Team umzusetzen. "
Ich finde Ilkers Beitrag besonnen. Sein Standpunkt gefällt mir. Ich sehe es grundsätzlich genauso. Deshalb ist mir auch wichtig, mit einem Training wie dem für Agile Architektur Entwickler zu adressieren. Wenn alle zusammensitzen und Architektur planen, kommen mehr Ideen zusammen, das geteilte Verständnis für die Architektur steigt und das gemeinsame Verantwortungsgefühl für das Ergebnis ist höher.

Nichts schlimmer als Astronautenarchitekten, die keinen Bezug zur Entwicklung mehr haben. Nichts konfliktträchtiger als Architekturen, die nach dem Motto "friss oder stirb" über einen Organisationszaun den Entwicklern vor die Tastaturen gekippt werden. Die Entfremdung zwischen Architektur und Anforderungen und Code lauert überall.

Und dennoch... Ein bisschen zucke ich noch bei Ilkers Ergebnis. Weil ich fühle, dass was Ilker beschreibt, für mich an den Persönlichkeiten und Kompetenzen der real existierenden Entwickler vorbeigeht. Ich zucke, weil ich eine Differenz zwischen Wollen und Können sehe.

Viele wollen das, was Ilker beschreibt. Es klingt in der Sache richtig und es hat Appeal für die Persönlichkeit vieler Entwickler, die pragmatisch sind und sich nicht lange mit Organisation aufhalten wollen. Sie sind sensibel für die Verluste, die Distanz zwischen den Beteiligten erzeugen kann.

In meiner Beratungs- und Trainingspraxis sehe ich dann allerdings, dass eben nicht alle Entwickler gleich sind. Sie unterscheiden sich in ihrer technischen Kompetenz, sie unterscheiden sich in ihrer Methodenkompetenz, sie unterscheiden sich in ihrem Charakter und in ihren Bedürfnissen. Und das ist ja auch gut so. Teams, die gemischt zusammengesetzt sind, liefern bessere Ergebnisse.

Verschiedenartigkeit ist grundsätzlich zu begrüßen - sie führt aber auch zu Konflikten und es bleiben blinde Flecken. Wie wird das kompensiert? Wer führt Konflikte zu einem Ergebnis? Wer leuchtet blinde Flecken aus?

Für die Konflikte gibt es Moderatoren. Das weiß inzwischen jeder. Die können aus einer Gruppe kommen oder von außen. Sie stellen sicher, dass Gruppentreffen eine zielführende Form haben. Moderator ist gewöhnlich 1 Person. Dass eine Gruppe sich selbst durch gleich verteilte "Eingriffe" aller Mitglieder moderiert, ist eher selten. Meist gibt es einen de facto Moderator, der nicht mal ausgebildet sein muss. Dennoch erkennt ihn die Gruppe an.

Dieses Muster ist akzeptiert. Im besten Fall dominiert dieser Moderator die Gruppe nicht, sondern kann eine Balance halten zwischen seinem Mitgliedsstatus und seiner Moderatorenrolle. Er ist nur temporär Erster unter Gleichen in Bezug auf eine Aufgabe.

Ein Moderator verkörpert den Aspekt "Kommunikationsform", ohne dessen Berücksichtigung das Ergebnis einer Besprechung schnell suboptimal ausfällt.

Ich denke auch, wir können uns darauf einigen, dass nicht jeder die Rolle eines Moderators gleich gerne und/oder gut ausfüllt - selbst wenn der Aspekt allen Gruppenmitgliedern wichtig ist. Es braucht dafür eben eine gewisse Kompetenz.

Und wer leuchtet blinde Flecken aus? Die gibt es ja unweigerlich und sei es nur temporär. Wenn die Diskussion hoch her geht, dann fällt der eine oder andere Aspekt gern mal unter den Tisch. Ein Übriges tut dann das Tagesgeschäft mit seinem Druck in Richtung bestimmter Aspekte - und Ignoranz gegenüber anderen.

Einer dieser Aspekte ist aus meiner Sicht die Architektur. Architektur ist ein nicht-funktionaler Aspekt der Softwareentwicklung. Und darüber hinaus auch noch einer, dessen Qualität nicht so schnell zu einem Feedback vom Kunden führt. Wenn die Performance der Software nicht stimmt oder die Usability, dann sagt steht der Kunde sehr schnell auf der Matte. Rückkopplungszeit Stunden oder Tage.

Wenn aber die Architektur nicht stimmt... dann ist die Rückkopplungszeit Wochen, Monate oder gar Jahre. (Ja, ich glaube, man kann nicht-funktionale Anforderungen wie Performancelimits erfüllen, auch wenn die Architektur suboptimal ist. Das passiert sogar häufig.)

Weil nun die Rückkopplung bei der Architektur vergleichsweise lange auf sich warten lässt, fällt sie leicht unter den Tisch. Manager haben dafür oft wenig Sinn. Sie sind es aber, die sich letztlich durchsetzen. Jedenfalls normalerweise. Heute noch ;-)

Bei gegebener schlechter Ausbildung in puncto Softwareentwurf - das schließt für mich Architektur ein - und gegebenem Tagesgeschäftfokus ist für mich die Realität von Teamsitzungen, dass Architektur schnell zu einem blinden Fleck wird. Nicht sofort, nicht immer, aber tendenziell.

Dazu kommt, dass die Kompetenzen, die für den Entwurf von Software-Architektur nötig sind, nicht gleich verteilt sind bei Entwicklern. Es ist damit wie mit den Moderatorenkompetenzen. Das ist also ganz natürlich.

Und daraus leite ich nun wiederum ab, dass es wichtig ist, darauf zu achten, dass der Aspekt Software-Architektur verlässlich verkörpert wird.

Wie diese Verkörperung aussieht, ist mir egal. Es muss keine Position eines Software-Architekten geben. Es muss auch niemand zwangsläufig fix die Rolle eines Software-Architekten innehaben. An irgendwem muss das Thema jedoch hängen, glaube ich. Und zwar nicht am ganzen Team, sondern an einer Untermenge.

Alle sind mit der Plattform und der Domäne und hoffentlich Clean Code Developer ;-) vertraut. Jenseits dessen beginnen dann allerdings die Unterschiede. Es ist immer so, dass einer die GUI-Technologie besser beherrscht als andere. Und eine kann besser mit dem Build-Tool umgehen als andere. Und manche fühlen sich eher zum Umgang mit Datenbanken hingezogen als andere.

Genauso denkt eine konzeptioneller als andere. Und einem ist das big picture wichtiger als anderen.

Ich glaube, diese ganz selbstverständlichen Unterschiede sollten wir nicht leugnen. Wir sollten auch nicht glauben, sie wegschleifen oder auffüllen zu können. Dafür geht gerade das Thema Software-Architektur zu sehr an Persönlichkeitsmerkmale, die schon früh geprägt werden.

Um also nicht davon überrascht zu werden, dass das kollektive Kümmern um Architektur irgendwie nicht funktioniert hat, sollte jedes Teams schauen, dass es möglichst schnell herausfindet, wie es den Aspekt Architektur am besten verkörpert.

Manchmal mag es einen Entwickler geben, der sich den Schuh anzieht - und die anderen sind froh drüber, dass er sie beim Thema an die Hand nimmt. Manchmal mag es eine kleine Gruppe innerhalb des Teams sein. Oder vielleicht rotiert die Aufgabe durch das Team, so dass bei jeder Besprechung ein anderer das "Architektur-Gewissen" ist?

Eine andere Verkörperung muss natürlich in der Zeit stattfinden. Sie muss für alle Entwickler fester Bestandteil ihrer Wochenkalender sein. Das ist der erste Schritt.

In Summe helfen Experimente. Solange die dafür sorgen, dass die Verkörperung der Architektur nicht in eine außerkörperliche Erfahrung ;-) umschlägt, d.h. abhebt und entfremdet von Code und Anforderungen, solange ist alles erlaubt.

Software-Architektur geht alle an. Da bin ich ganz dabei. Allerdings möchte ich daraus ungern eine zwingende Form ableiten: weder eine Position des Software-Architekten, noch die komplette Abwesenheit jeder Rolle oder anderer Form von Kompetenzkonzentration oder Interessenverteilung. Architekturbewusstsein verkörpern, in geeigneter Form, darum geht es.

Solange am Ende das ganze Team ein solides Verständnis der Architektur hat und sie mitträgt, ist alles gut.

Kommentare:

Anonym hat gesagt…

Hallo,

sehe ich genauso.

Architektur ist eine Teamaufgabe in schlanken Entwicklungsteams, aber es muss meiner nach einen Verantwortlichen (einen Architekten) geben, der beiKonflikten entscheidet und dafür "gerade" steht. Der Architekt repräsentiert die technische (Struktur des Systems, WIE) und kundenorientierte Sicht (Anforderungen, WAS - insbesondere Nichtfunktionalen Anforderungen). Ein Architekt arbeitet im Wesentlichen als Vermittler, Sprachrohr, Kommunikator und Coach der Architekturvision.

Eine ausschliessliche Vollzeit-Architekturaktivität kommt heutzutage vermutl. nur noch in grösseren Projekten vor, wenngleich "architect also implements" zwecks Glaubwürdigkeit bedeutend ist.

Reine Architekturteams ausserhalb der Entwicklung funktionieren schlecht und sind eher nur für Blaupausen oder kundenfernes Zeugs zu gebrauchen = waste.

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym: Ich weiß nicht, ob wir wirklich einer Meinung sind. Denn ich meine eben nicht, dass es eine Person geben sollte, die für die Architektur (in Zweifels- oder Konfliktfällen) gerade steht.

Genau das ist eben zu vermeiden. Denn wenn einer gerade steht, dann können alle anderen herumlümmeln. Sie müssen sich nicht mehr einbringen. "Wenn es schief geht, ist das sein Problem."

Meine "Architekturverkörperung" hat keine Verantwortung darüber hinaus, dass sie Architekturthemen im Bewusstsein des Teams hält.

Aber sie hat nicht notwendig besondere Architekturkompetenz. Deshalb kann und soll sie auch nicht allein entscheiden. Gerade das ist Aufgabe des Teams.

Das Team muss deshalb insb. ein Verfahren haben, mit dem Entscheidungen gefällt werden, die alle (!) tragen. Hier ist wieder der Moderator gefragt.

Anonym hat gesagt…

Ich nehme einmal eine Analogie aus dem Profi-Sport: das Team verliert und bei anhaltender Negativserie wird der Trainer entlassen (einfachere Lösung). Der Trainer verantwortet die Mannschaft, die Aufstellung, deren Fitness und Taktik. Der Trainer kann von einer professionellen Berufauffassung "seiner" Spieler ausgehen, aber einzelne Entgleisungen verantwortet er nicht. Spielintelligenz und Intuition einzelner Spieler und der gesamten Mannschaft fördert und fordert er. Spieler haben ihren Preis - intelligente, technisch begabte und taktisch geschulte Spieler "kosten" mehr als die, die "Mängel" ausweisen.
So sehe ich das auch im Berufleben: nehmen wir einmal einen professionellen Softwareentwickler, so kann sich kein Softwareentwickler vor architektonischen Fragen verstecken - "nicht mein Problem".
Sollte er es doch tun, dann liegt ein Mangel vor und dieses Teammitglied muss noch entsprechend ausgebildet werden. Viele Köche verderben aber den Brei und daher sehe ich einen Gesamtverantwortlichen - den Architekten - der für die Taktik, die Fitness und die Spielintelligenz des Systems verantwortlich ist (keine alleinige Verantwortung, aber er kann "abgestraft" werden). Ja, Trainer und Architekten können von ihrer Mannschaft im Stich gelassen werden, aber das ist halt so.

Robert (INdotNET) hat gesagt…

Warum muss überhaupt jemand verantwortlich sein, oder "abgestraft" werden können?

Wenn es so weit kommt, dann ist es eh schon zu spät. Das heilt nicht das Problem und bringt auch keinen weiter.


@Ralf: Ich geb Ilker und dir volle Zustimmung zu euren Blogposts. Mit einer Architektenrolle habe ich meistens auch schlechte Erfahrungen als Entwickler gemacht. Eine ordentliche Alternative habe ich aber noch nicht erlebt.

Dann bleibt nur dieses Fazit:
"In Summe helfen Experimente."
und
"Architekturbewusstsein verkörpern, in geeigneter Form, darum geht es."

Hat jemand weitergehende Erfahrungen?

Anonym hat gesagt…

Ich denke auch, dass die kollaborieren Aspekte bei der Entwicklung einer Architektur/Produkt deutlich wichtiger sind, als die Position "Softwarearchitekt".

Einen Verantwortlichen soll es aus Unternehmenssicht immer geben und gerade das ist der falsche Ansatz. Die Summe der Einzelnen bring häufig besser Lösungen als die eines aus dem Elfenbeinturm schießenden Architekten.

Ebenfalls kann durch gute Moderation und Team Spirit ein vernünftiger Entscheidungsprozess entstehen. Die Wertschätzung der Teammitglieder steigert sich und motivierte Teams bringen bessere Leistung.

Gruß
Anonym2 ;-)

Anonym hat gesagt…

Bei der Softwareentwicklung geht es neben technischen Fragestellungen auch um Softskills wie z.B. Führung, Überzeugung und auch um Verantwortung.
Technische Unsicherheiten sind durch Prototypen, Experimente oder einfach "ask the computer" zu klären.
Architektonische Fragen kann und sollte eine Gruppenaufgabe sein, aber daraus leite ich für mich nicht auomatisch ab, dass es sich um demokratische Entscheidungsfindung handeln muss. 3 Alternativen, Pro und Kontra reichen - das letzte Mittel zur Entscheidung ist die Macht.

Ebenso glaube ich, dass man für bestimmte Themen, Aufgaben eine Person bzw. einen Ansprechpartner haben möchte und nicht immer eine ganze Gruppe.

Desweiteren kann man Aufgaben deligieren oder einfach auch einmal gemeinsam lösen (z.B. Performanceanalysen oder Pair-Programming oder Whiteboard-Sessions).

Alles ist aber subjektiv und im speziellen Einzelfall mag die Ausrichtung oder Gewichtung oder Vorgehen anders sein - "it depends!"

Sind eure Projekte - wir beschränken uns einmal auf die architektonischen Apsekte - von demokratischen Prozessen geprägt?
Gibt es keine Verantwortung und Führung? Wenn ja, wie kann das mit 10, 50 oder mehr Mitarbeitern funktionieren? Sind alles Mehrheitsentscheidungen der Gruppe?

Anonym hat gesagt…

>... selbstverständlichen Unterschiede sollten wir nicht leugnen.
Okay, Stärken und Neigungen der Individuen akzeptieren und diese hinsichtlich bestmögliches Ergebnis einsetzen.

>... dass das kollektive Kümmern um Architektur irgendwie nicht funktioniert hat
Warum hat das nicht funktionier? Was ist ein alternatives Modell? Gruppenaufgabe gepaart mit Alleinverantwortung? Oder alle Macht dem Volke? Keine Steu

>Eine andere Verkörperung muss natürlich in der Zeit stattfinden...
Welche?

>Software-Architektur geht alle an.
Ist das wirklich so und was schliessen wir daraus? Lokal betrachtet stimme ich zu, aber global verneine ich das:
Wenn Team A und Team D "nichts" miteinander zu tun haben (andere Subsysteme, keine Schnittstellen unterschiedliche Ablaufumgebung), dann ist die Architektur von D nicht bedeutend für A.
Wer behält aber A, B, C und D im Blick? Wer entdeckt dann doch Zusammenhänge oder Synergieeffekte?
Oder sollen sich jeweils immer Teammitglieder mit den Architekturen (Designs, Anforderungen) der anderen beschäftigen? (Ich meine hier keine Neugier, den Blick über den Tellerrand, dem Kommunkationsnetzwerk).
Was ist regional verteilten Teams?

Softwarearchitektur ist für mich keine Alleinaufgabe, sondern eine Gruppenaufgabe mit passenden Skills, heterogen. Die Gruppe, die die Architektur voranbringt, ist aber nicht das gesamte Team (siehe oben Neigungen und Stärken).
Dennoch muss es ein Element geben, dass dem Gemenge Struktur und Richtung gibt.

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym: Mir geht es nicht um Demokratie! Jedenfalls nicht im Sinne von Mehrheitsentscheiden. Das ist kontraproduktiv.

Es geht darum, tragfähige Architektur zu machen. Im technischen Sinn wie im sozialen. Die Architektur soll leisten, was gefordert ist. Klar. Aber sie soll auch von allen akzeptiert sein. Denn ist das nicht der Fall, wird sie mehr oder weniger immer wieder untergraben.

Demokratie - sorry to say - führt (gerade bei leidenschaftlichen Menschen wie es Entwickler sind) aber relativ schnell ins Untergraben. Denn wer überstimmt wurde... der ist nicht mehr recht dabei.

Da mag man an den demokratischen Geist und fair play appellieren... aber das Ergebnis ist halt so. Wer in Abstimmungen unterliegt, ist sauer.

Deshalb sollte kein Gruppenentscheidung durch Mehrheitsbeschluss getroffen werden. Es müssen vielmehr Argumente - vor allem Gegenargumente - auf den Tisch. Und wenn die alle adressiert sind... dann hat sich die Entscheidung quasi von selbst gefällt.

Ich nenne hier als Stichwort Kosent (http://soziokratie.blogspot.de/2010/11/entscheidung-in-der-freiheit-mit.html) und Systemisches Konsensieren (http://www.sk-prinzip.eu/).

Und das skaliert auch, wenn man es richtig macht. Stichwort: Soziokratie (http://blog.ralfw.de/2009/01/aspektorientierte-unternehmensfhrung.html).

Zu "Verkörperung in der Zeit": Es braucht deutlich sichtbaren Platz für das Thema Architektur im Wochenplan eines Teams. Architektur ist nichts, was sich so nebenbei von selbst macht.

Wo ein Team das nicht hinkriegt, regelmäßig im Kalender Platz für Architektur und nur Architektur zu reservieren, ist sie nicht ausreichend verkörpert.

Zu "Team A und D": Auch hier sehe ich kein grundsätzliches Problem. Was getrennt ist, kann ja auch getrennt bleiben. Ich würde sogar sagen, man sollte dem Drang zur Konsolidierung von Architektur widerstehen.

Aber Lernen soll ja stattfinden. Und es gibt sicherlich bei unterschiedlichen Produkten/Teams auch immer wieder die Notwendigkeit, dass Anwendungen miteinander kommunizieren sollen.

Deshalb sollte natürlich ein Austausch zum Thema Architektur über Teamgrenzen hinweg stattfinden. Auch da sehe ich wieder die "soziokratische Kreisorganisation" als Mittel.

Architektur ist wie GUI oder Persistenz usw. ein eigener Aspekt von Software. Der durchzieht zwar alles, geht also eher alle an als das GUI. Nichtsdestotrotz hat er seine eigenen "Gesetze" und braucht daher spezielle Kompetenz.

Die ist nicht gleich verteilt und wird auch nie gleich verteilt sein können. Insofern gibt es immer und notwendig Leute im Team, die sich eher dafür interessieren als andere.

So entsteht eine ganz natürliche Hierarchie von Spezialisten. Ein GUI-Spezialist, der sich schlicht mit WPF besser als andere auskennt, steht den anderen in seiner Expertise vor. Das ist so. Er wird von den anderen in dieser Führungsrolle einfach anerkannt, ob er sie will oder nicht.

Dasselbe gilt für andere Spezialisten.

Nichts daran ist schlecht. Hierarchie ist auch nicht schlecht.

Deshalb ist immer noch das ganze Team für architektonische Grundsatzentscheidungen verantwortlich.

Aber so ergibt sich eine natürliche Untermenge von Architekturinteressierten, die sich eben auch teamübergreifend in einem soziokratischen Kreis treffen kann, der den Team-Kreisen übergeordnet ist.

So wächst Hierarchie von unten. Das ist gut.

Anonym hat gesagt…

Halo Ralf,

danke für die Links. Ich stelle sie mir auf meine Leseliste.

Es gibt einige Standpunkte, die wir vielleicht etwas anders sehen, formulieren oder gewichten. Danke für den Input.

Ich denke, die Punkte sind hier im Blog genug beschrieben worden.

Matthias hat gesagt…

Wer schon mal ein Haus gebaut hat, der weiss, warum Handwerker in der Regel alleine kein Haus bauen koennen und es einen Architekten und einen Bauleiter gibt.
Fuer mich liegt das Problem mehr, dass das Management an sich die Architektenrolle haben sollte, da es um den Gesamtblick und die Verantwortung fuer die Qualitaet geht. Leider wird dort zu viel formal/abstrakt/politisch und zu wenig detailliert/konkret/sachbezogen gearbeitet.
So schoen es waere, dass jeder Entwickler Architekturwissen hat, so unrealistisch ist es leider, dass jeder die Zeit und den Willen zum staendigen Lernen aufbringt.

Ralf Westphal - One Man Think Tank hat gesagt…

@Matthias: Ich halte es auch für eine romantische Vorstellung, einen Haufen guter Handwerker zusammensetzen zu können, dass die eine komplexe Maschine aus dem Nichts aufbauen und über Jahre wachsen und gedeihen lassen können unter sich ständig wandelnden Bedingungen.

Wenn die Projekte klein sind (geringer Umfang, kurze Zeit), dann geht das mit 2-4 Leuten.

Aber alles was größer ist... das braucht eine Form von Hierarchie.

Hierarchie ist nichts Böses. Da geht es auch nicht um Macht und Gewalt. Sondern es geht um Überblick. Die Teile können ab einer gewissen Größenordnung schlicht nicht das Ganze im Blick behalten.

Entweder man ist im Graben oder man sitzt auf dem "Feldherrenhügel". Beides geht nicht gleichzeitig. Aber beide Sichtweisen sind nötig. Und jede braucht eigene Kompetenzen. Wenn dann einer versucht, quasi-gleichzeitig an beiden Positionen zu sein... dann wird das nur sehr bedingt funktionieren.

Keine Position ist aber auch besser. Beide sind nötig. Der "Feldherr" auf seinem Hügel hat nur andere Aufgaben, keine besseren. Er ist vom Soldaten im Graben genauso abhängig für den Schlachtverlauf wie umgekehrt.

Dass Hierarchie etwas ganz Natürliches und sogar Notwendiges ist, wird leider oft vergessen. Stattdessen gehen Code Handwerker auf die Walz und Code SWAT Einheiten versuchen es im Nachteinsatz zu reißen.

Ist ja alles gut und schön. Nur sollte es kein Dogma sein, dass es nur und ausschließlich so geht. Da fehlt mir dann auch Lockerness.

Jo hat gesagt…

Hallo Herr Westphal,

ich habe gerade Ihren Artikel "Industrialisierung der Softwareentwicklung (http://www.sigs.de/publications/os/2005/03/westphal_OS_03_05.pdf)" gelesen, wo sie eine weitere Spezialisierung der Softwareentwickler fordern. Man solle hier zu einer Arbeitsweise wie in der klassischen Fertigungsindustrie kommen. Hier bin ich voll und ganz Ihrer Meinung. Aber wie lässt sich das mit Ihrer Forderung nach einer verteilten Verantworung für Architektur in Einklang bringen? Wenn am Ende der eine Entwickler nur noch für das Deployment, der andere nur noch für das Rich-Client Frontend, der nächste nur noch für das Web Frontend u.s.w. verantwortlich ist, wie soll er da noch die Gesamtarchitektur im Blick behalten (die ja Bereiche einschließt, von denen er durch seine extreme Spezialisierung keine Ahnung mehr hat)? Entwickelt ein Autokonzern ( -> klassische Fertigungsindustrie) ein neues Model, so sind, bis das erste Exemplar vom Band läuft, sicher tausende von Menschen beteiligt. Aber an der Konzeption und dem technischen Design nur ein Bruchteil. Ich glaube, Ihr Architekturansatz ist tatsächlich brauchbar und realistisch, aber nur für die Form des Vorgehens, wie heute eben meist Software entwickelt wird. Meiner Meinung steht er aber im Widerspruch zu dem, was Sie mit der Spezialisierung des Softwareentwicklers fordern. Ich denke, man braucht für unterschiedliche Projekttypen und -größen unterschiedliche Ansätze. Es wäre eine gefährliche Simplifizierung, hier alles mit einem Vorgehen / Methode erschlagen zu wollen.

Ralf Westphal - One Man Think Tank hat gesagt…

@Jo: Es braucht vier allgemeine Kompetenzen bei den "Kernentwicklern" in einem Team:

-Allgemeine Programmier- und Plattformkompetenz (Programmiersprache, IDE usw.)
-Allgemeine "Prozesskompetenz" (wie wird Software hergestellt in einem Prozess)
-Allgemeine Entwurfskompetenz
-Allgemeine Domänenkompetenz

Auf dieser Basis können Teammitglieder erstmal überhaupt als Team kommunizieren; sie können sich grundlegend verstehen.

Davon ausgehend wird dann spezialisiert, allemal in Richtung Technik.

Ja, auch Entwurf kann eine Spezialisierung sein. In einem 7köpfigen Team mögen darin nicht alle gleich stark sein. Also gibt es vllt. 2-3, die erstmal "vorentwerfen". Aber das ist nicht endgültig. Deren Ergebnis wird von allen diskutiert, unabhängig von technologischer Spezialisierung. Denn Technologiespezialisten haben womöglich Einwände gegen "Elfenbeinturmentwürfe". Und das ist gut so.

In einem Krankenhaus sind alle am Wohl des Patienten interessiert. Und alle Ärzte teilen eine Grundausbildung - auf die drauf sie Spezialisierungen gelegt haben.

Deshalb treffen sie sich inzwischen in größeren Runden, um Patienten rundum zu begutachten.

Dasselbe müssen wir hinkriegen. Und wer nicht, der bleibt halt technologisch immer weiter zurück.