Sicher sollten Teams eigentlich idealerweise getrennt sein, aber sie arbeiten ja gemeinsam an einer Software. Daher wird wohl ein gewisses Maß an Kommunikation notwendig sein. Die Kollaborationsmodelle in Team-Topologies setzen eher auf eine Zusammenarbeit. Ob es da "Weisungen" gibt, ist also eher eine offene Frage. Am Ende ist aber wichtig, dass Team Topologies nur ein Modell der Zusammenarbeit darstellt und auch eher ein Zielbild. Ob man also operativ was anderes macht oder andere Mechanismen einführt, ist noch eine weitere Frage.

Schön - viel Spaß beim Schauen!

kzbin.infoUgkxbbljYp64SJ0P8i1CM4rqrVgHmY1Pf0pm?feature=shared Moin Eberhard, Diese erwähnten Teams werden denen weisungen gegeben und wie stellt man fest, dass die das konzept genau so umsetzten wie du es dir vorstellst? Jedes team benutzt eine andere sprache (programmiersprache). Da gibt es ja ein priblem hinter der sprache. Siehe video

Und / oder ganz anders gefragt. Welche Videos lösen (wenn auch nur im Ansatz) die Probleme die in diesen Videoclips erwähnt werden?

Hallo, oder ganz anders gefragt: welche Videos lösen (oder schneiden das Thema an) die in den Clips (von mir angehängt) dargestellten Probleme? 🎉🎉

Ja. Ich denke, man sollte Diagramme zeichnen mit den Informationen, die einem helfen - ob die dann einem Standard entsprechen ist IMHO sekundär.

Wenn wir uns einig sind, dass es um Geschäftswert gehen soll, ist IMHO alles gut. Ich kenne genügend Situationen, in denen Techniker:innen auf beispielsweise auf ihre Interpretation von technischer Exzellenz gedrängt haben, auch wenn es aus geschäftlicher Perspektive keinen Sinn ergab. 🤷‍♂️

Zweifellos ist das ein sinnvolles Ziel. Es gibt allerdings einmal die Frage, ob man das so einfach in der Realität hinbekommt. Das ist ein Fokus meiner Beratung... 😉

@@EberhardWolff ja, die Beratung macht aber meiner Meinung nach nur Sinn (lernend) wenn man ein ganz konkretes Anwendungsbeispiel hat. In dem Fall ja scheinbar ein Unternehmen das ein Projekt zur digitalisierung ,Achen will

Ja, ein SCS sollte eine Domäne implementieren. Auch hier wieder: Das ist einfacher gesagt als getan....

Module sind eher ein technisches Konzept, aber soll Entwickler:innen ermöglichen, komplexe Systeme kollaborativ zu entwickeln. Von daher ist das ein soziotechnisches Konzept in so fern, als dass es Code für Menschen strukturiert.

​@@EberhardWolff Moin Eberhard, danke für die Antwort. So ein soziotechnischen system hat ein Input und einen Output und einen inneren Zustand der vom Teammitglied (Software Firma?) abhängt, der Aufgabe (der Organisation?), der Technologie und der Struktur der Organisation(?). Ist der Input die Spezifikation der Schnittstelle oder noch mehr? Ist der Output der Code integriert in eine ArchitekturUmgebung?

Danke für die Klarstellung!

Vielleicht noch eine Anmerkung: Ich sehe bei solchen Folgen das Problem , dass ich auf schriftliche Dinge antworte und die kann ich falsch verstehen oder darstellen. Ich hoffe, das war OK für Dich so.

Gerne - aber dafür müsste es eben Reaktionen geben... 😉

@@EberhardWolff wird es denn nochmal einen Beitrag zu soziotechnischen Systemen geben? Mich würde mal die Auftragsdefinition dort interessieren im Vergleich zur Auftragstaktik. Reaktionen kriegst du ja genug ich glaube nur du hast mittlerweile gar keine kapazitäten 💗

@@marcm3623 Aufträge kein zwingender Teil eines soziotechnischen Systems. IMHO ist es aber grundsätzlich so, dass klare Delegation hilfreich sein kann. Ein formaler Prozess dafür wäre sicher nicht schlecht.

Ich finde das auch nachvollziehbar. Man muss allerdings sagen, dass Ideen wie "nachhaltige Geschwindigkeit" eher den Eindruck hinterlassen, dass man bei agilen Ansätzen eben dauerhaft eine hohe Last hat. Ich finde da Beispiel deswegen auch gut, um zu zeigen, dass manchmal Agilität für langfristig eher keinen Sinn macht.

Ich würde argumentieren dass du für kein Projekt 10 creative Entwickler brauchst. Auch einen „Wartungsmodus“ wird es so eigentlich im Agilen setup nie geben. Die Idee ist, dass du ein Team von 3 bis 4 Leuten hast, die extrem gut sind in dem was Sie tun - diese sollten dann die kleinst möglichen Inkremente der Gesamtvision, step by step umsetzen. Die Visions, bzw. das Produkt ist dabei nie wirklich fertig. Es gibt immer neue Änderungen die man implementieren kann um Marge zu erhöhen und Profit zu steigern.

@@SM-cs3nt Das sagt das klassische Verständnis von Agilität, richtig. Das letzte Beispiel aus dem Reaktion-Stream zeigt IMHO eine Entwicklungsphase und eine Wartungsphase bei mindestens zwei Projekten. Da sind dann andere Vorgehensweisen sinnvoll.

@@EberhardWolff Das größte Problem der klassischen Agilität mMn. sind die Kostenaufwände für die Entwickler die keinen direkt ersichtlichen Gegennutzen haben. Bei einem Team von 4 Mann, sprechen wir von jährlichen Personalkosten von 500.000€ (sehr günstig gerechnet) Dagegen muss erst einmal ein Profit stehen - der sich über die Jahre auch hält. Verstehe da schon warum viele Firmen lieber den Fixed Scope abstecken möchten (und ein Budget und Business Case dahinter legen) Für 300.000€ kann ich an eine Agentur gehen, einen Werksvertrag schließen und habe am Ende die Software die ‚nur noch‘ gewartet werden muss. Die software erfüllt den im Business case geplanten Nutzen und der Umsatz kann erzielt werden. (Wenn er sich rechnet, plane ich die nächste Iteration und wenn nicht dann halte ich das Projekt im Wartungsmodus oder schließe ab. Im Gegensatz dazu steht die Agilität bei der ich keine genau Prognose habe dafür welche Features ich umgesetzt haben werde zu welchem Zeitpunkt. Die 500.000 fallen sofort an - und wiederholen sich im nächsten Jahr wieder. Was nun wenn ich nach einem Jahr die gewünschten Features nicht umgesetzt habe und somit nicht Wettbewerbsfähig bin? Im worst-case habe ich also 500.000 in den Sand gesetzt + 4 Entwickler die ich entlassen muss + lein Produkt. Im nicht agilen case habe ich 300.000 für ein Produkt gezahlt dass nicht mevr markttauglich ist weil sich die Marktgegebenheiten so stark geändert haben (was auch sehr unwahrscheinlich ist - in der Realität ändert sich der Markt nicht so schnell.). Durch den Werksvertrag habe ich also eine Risikominimierung weil das Risiko auf die Agentur ausgelagert wird.

@@SM-cs3nt Guter Punkt - danke fürs Teilen!

Der betrachtet einen Technologie-Stack aus Messaging während Bounded Contexts eine fachliche Aufteilung darstellen. Von daher lassen sich die beiden Ansätze sicher gut kombinieren.

Danke für das Feedback! Hier sind die Links: software-architektur.tv/2024/04/12/folge212.html . Ich habe sie aber auch hier in der Video-Beschreibung ergänzt. 🙂

Danke für das Feedback! Mittlerweile glaube ich, man kann da eine ganze Batterie von Talks zu machen. Du hast recht, Feedback ist ein massiver Vorteil. Das erklärt aber nicht, warum funktionierende agile Organisationen rückabgewickelt werden bzw. das können nicht alle umsetzen. Die Konsequenz kann aber IMHO nicht sein, Agilität immer noch als das beste Konzept anzusehen. Bei einer solchen Organisation funktioniert es eben leider nicht. Ich glaube, dass das nicht allen klar ist….

@@EberhardWolffAn ein bestes Konzept glaube ich auch nicht. Bei uns hatte es sicher 5..7 Jahre gedauert, bis zumindest ein Großteil der Teams Scrum verinnerlicht hatte. Da helfen auch diverse, oft ein wenig weltfremd daherkommende Coaches nicht, eher im Gegenteil. Automatisch besser wird auch nichts, im Gegenteil, viel mehr Leute müssen regelmäßig "das Richtige" tun, wo vorher vielleicht bisweilen ein cleverer und durchsetzungsstarker PM ausreichte. Es gibt sicher 99 Stolperfallen, in welche man früher oder später tappsen wird. Mich wundern Rueckabwicklungen nicht.

Ich will, dass die Leute aus dem Training rausgehen und Systeme in Bounded Contexts aufteilen können. Das erreiche ich dadurch, dass sie es selber tun und ihre Entwürfe reviewed. Wenn ich ihnen das erzählen würde, was ich in der Episode erzähle, würde ich den zweiten Schritt vor dem ersten machen und durch Details verwirren. Und ich würde viel Theorie machen, während Trainings für mich vor allem Praxis sein sollen.

Danke für das Feedback! Ich glaube, man kann noch eine Vielzahl weiterer Vorträge in dem Bereich halten - gerade nach den Reaktionen auf diesen Vortrag. Aber mein Thema war hier funktionierende agile Organisationen, die kippen - und die haben Widerstände bereits überwunden…

Das ist ein interessanter Gedanke und sicherlich eine Option. Allerdings finde ich, dass die Frage ob man funktionale Fehlerbehandlung betreiben möchte eine orthogonale zur Entscheidung ValueObjects einzusetzen. In Java bräuchte es für ersteres so etwas wie Vavr. Der Einsatz einer funktionalen Bibliothek hat aber signifikant andere Auswirkungen, da mondadische Typen eigentlich immer viral sind. D. h. deren Einsatz sorgt immer dafür, dass weiterer Code mit diesen Typen umgeht (ähnlich wie Optional). Dies ist wesentlich invasiver als die Typen in jMolecules. Von daher sollte das IMO eine separate, orthogonale Entscheidung sein. Zum Thema funktional VS. eher OO-orientiert hat jMolecules absichtlich keine Meinung.

Danke für das super Feedback!

Das ist nur eine These, die ausführliche Darstellung und Begründung findet sich hier: kzbin.info/www/bejne/aGTIioelmJ11rsk

@@EberhardWolff schau ich mir gerne mal an

@@HickyGreen Super, viel Spaß dabei!

Genau da bin ich mir nicht so sicher. IMHO ist die Priorisierung von Features gegenüber Wartbarkeit ein zentrales Thema: Am Ende hat man ggf. unwartbare Legacy oder ein wartbares System, aber kein Product / Market Fit. Dort den richtigen Kompromiss zu finden ist schwierig. Und die Priorisierung und das Verständnis für das Gehschäft sollte breiter im Team verstreut sein als nur beim PO. Architektur und damit Architekt:innen haben auch massiven Einfluss auf den Geschäftswert.

@@EberhardWolff Stimmt. Kenne ich sogar tatsächlich so dass auch die Architektur/Entwickler einen Prozentsatz der "Story Points" für technische Themen verplanen darf.

Thanks for the great feedback! 🙂👍

Das ist ein anderes Thema. Die kurze Antwort ist, dass mindestens Iterationen immer sinnvoll sind, selbst wenn sich Anforderungen nicht ändern würden. Weil sie das aber tun, sollte man sich darauf auch ausrichten und dann ist man bei Agilität. kzbin.info/www/bejne/qJObgqGco52repY diskutiert das alles im Detail.

Danke für das nette Feedback ! Ich bestreite nicht, dass zufriedenere Leute produktiver sein können. Dennoch gibt es beispielsweise Beratungen, die auf jeder Uni-Jobmesse vertreten sind, weil sie neue Mitarbeiter:innen benötigen. Die verbleiben dann höchstens ein paar Jahre in dem Unternehmen. Danach müssen sie entweder aufgestiegen sein oder sich einen neuen Job suchen . Die Arbeitsbedingungen - insbesondere die langen Arbeitszeiten - sorgen außerdem dafür, dass die Leute da gar nicht bleiben wollen. Das ist halt Ausbeutung und funktioniert in der IT genauso gut wie anderswo auch. Also gibt es unterschiedliche Strategien: Ausbeutung und zufriedene Mitarbeiter:innen sind zwei.

Danke für das positive Feedback - freut mich sehr!

Wait what?! War mir entfallen, dass Linda Rising als Gast bei Eberhard war - habe ihr Buch hier liegen & jetzt weiss ich was ich analog zu Dir tun werde, nämlich das andere Video zu schauen.. 😍

@@aFrInaTiOn viel Spaß!

Ich baue zwar verschiedene Prototypen, aber ich muss nicht unbedingt alles selber implementiert haben. Ich finde es besonders spannend zu schauen, was man denn nun wirklich unter einem bestimmten Konzept versteht - dazu gibt es ja auch viele Beispiele im Stream. Als Berater sehe ich außerdem viele Projekte und die Erfahrungen, die sie gemacht haben. Das formt einen Eindruck von typischen Problemen und Lösungen.

Interessant. Ich fand funktionale Programmierung immer weniger offensichtlich. Aber da kann man dann wohl verschiedener Meinung sein. Danke für das Feedback!

​@@EberhardWolff Vielen, vielen Dank. Ich habe es gestern noch im Zug fertig schauen können. Funktionale Programmierung wird auch schnell verrückt (Category Theory, Recursion Schemes und Lenses lassen grüßen), das finde ich auch. Aber Funktionen selbst sind so schön einfach (man steckt was rein und es kommt bei gleichem Input immer das gleiche 'raus). Weil mir noch nie ein Video gemacht wurde möchte ich noch ein bisschen Feedback da lassen! Ich stimme dir, wenn ich mich recht entsinne, bei allem zu. Meine persönliche Theorie ist ja, dass das OOP-Konzept so populär geworden ist, weil es so intuitiv klingt (Animal -> Mammal -> Cat, Dog,...). Meistens kommt man dabei nicht zum Schnabeltier. Der generelle Konsens scheint ja sowieso zu sein, dass Vererbung eine schlechte Idee war, Interfaces (und Composition) aber super sind. Was dann für mich eben immer noch bleibt ist der veränderbare Zustand der Objekte. Der ist im Endeffekt in meinen Augen eine Performance-Optimierung ggü. von ,,immutablen" Objekten, die ja in vielen Business-Kontexten auch wieder vorzuziehen sind. Dieser State führt dann auch zu noch viel mehr "incidental complexity" wie "private/protected/public", "Getter" und "Setter". Meine große Frage bei dem allen ist das "wieso"? Was wird damit erreicht, das mit imperativer Programmierung schlechter ging? Und zu welchem Preis (s.o.)? Ich glaube WhatsApp hat ja bewiesen, dass es mit der richtigen VM in dem (von dir ausgeschlossenen) Netzwerk-Einsatzzweck ziemlich gut funktionieren kann. Gerade in großen Firmen ist ja OOP ziemlich beliebt. Du hast erwähnt, dass Java nicht die allerschönste Sprache ist. Glaubst du, dass es also so eine selbsterfüllende Prophezeiung ist nach dem Motto: - Viele Entwickler können Java, also nutzen wir in unserer Firma Java - Die Industrie nutzt Java, also lehren wir Java - Entwickler können Java, also bauen sie Bibliotheken in Java So, jetzt reicht's aber. Liebe Grüße aus Münster!

@@i-am-the-slime Danke für das ausführliche Feedback! Zum „wieso“: Smalltalk, OO und GUIs gehören für mich zusammen und ich persönlich bin über GUI-Programmierung zu OO gekommen. Und IMHO passt OO da gut. Ansonsten denke ich - wie Du auch sagst - in einem sich verstärkenden Feedback-Zyklus für Sprachen wie Java oder JavaScript. Das ist meiner Wahrnehmung nach auch, was Nikolaus Wirth sagt.

@@EberhardWolff Finde es total cool, was du hier machst. Gefällt mir sehr gut, dass du es auf Deutsch machst. Habe noch viel nachzuholen, was den Kanal angeht.

@@i-am-the-slime Danke für das Feedback, freut mich sehr! 🙂

Danke für den Hinweise - das hatte ich am Beispiel von Smalltalk IMHO auch im Stream gesagt, aber stimmt Java hat ähnliche Konzepte.

Dir auch ein schönes Wochenende!

Taktisches Design ist objektorientiert, richtig. Das hatten wir in Episode 214 software-architektur.tv/2024/05/03/folge214.html diskutiert. Damit ist die in dieser Episode vorgestellte Idee eine funktionale Alterantive zu taktischem Design. Die anderen Elemente von DDD sind davon unberührt.