„DDD ist eine rechte Sache!“

Hinter dieser provokativen Aussage (ideal, um eine Unconf-Session zu veranstalten und Leute zu haben) wollte sich Simon Chaveneau die Frage stellen, welche Auswirkungen Domain Driven Design (DDD) auf unsere Organisation (Product-Tech) zur Herstellung von Software hat. Dies geschah während unserer ersten Nicht-Konferenz bei Agicap, die organisiert wurde, um es den Produkt- und Technikern zu ermöglichen, sich zu treffen, um zu diskutieren, zu lernen, zu teilen, zu lachen, aber vor allem in Bezug auf unser tägliches Leben an Höhe zu gewinnen.

Bei einer Unconference wird das Programm vom Publikum bestimmt. Dies geschieht während einer ersten „Market Place“-Sitzung am Morgen. Während dieser ersten Plenarsitzung des Tages kann sich jeder Stickies und einen Marker schnappen und dann seine Sessions vor allen präsentieren. Dann positionieren die Leute sie im Tagesprogramm (für weitere Informationen zu dieser Unkonferenz gibt es diesen Twitter-Thread )

Aber zurück zum Thema und der faszinierenden Session, die Simon vorgeschlagen hat.

Die Herrschaft des Privateigentums?

Um Simons anfänglichen Pitch zusammenzufassen: Wenn ganze Teile unseres IS zu Teams gehören – jeder für einen oder mehrere Bounded Context (BC) verantwortlich – stehen wir dann nicht vor einer Softwareversion von Privateigentum (mit Stacheldraht um die BCs usw .)? Daher auch sein provokantes „ DDD ist rechter Kram! ”

Und mit der Nebenfrage: „Wären wir nicht effizienter mit einer Organisation, die auf Feature-Teams basiert? (wobei jeder auf dem Weg zu seinen Anwendungsfällen an allen BCs arbeiten kann)“

Nun… Ich muss zugeben, dass sich diese Sitzung als viel fruchtbarer herausstellte, als ich ursprünglich gehofft hatte, weil sich eine wirklich faszinierende Diskussion über unseren Produkt-/Technologie-Organisationsmodus anschloss.

Aber anstatt den Weg zu beschreiben, den diese Sitzung genommen hat, wo wir sehr zahlreich waren (es ist sicherlich interessant, dies im Kontext eines anderen Beitrags zu beschreiben), werde ich direkt beschreiben, was ich behalten habe und was ich zu diesem Thema denke.

Ein paar Beobachtungen

• Effektive Software ist Software, die auf geschäftliche Herausforderungen ausgerichtet ist . Mit ausgerichtet meinen wir eine Software, die sich die richtigen Begriffe aus dem Domänenfeld leiht, die die Schlüsselkonzepte des Geschäfts richtig artikuliert und so wenig wie möglich die zufällige Komplexität heraufbeschwört, die durch technische Probleme verursacht wird. Dies ist eine der größten Herausforderungen des Domain Driven Design (DDD), wie hier in 3 Minuten erklärt wird .
• Conways Gesetz ist keine Option, die man nicht wählen könnte.‍♂️ Es verhält sich ein bisschen wie bestimmte physikalische Gesetze wie die Anziehungskraft der Schwerkraft. Wir können versuchen, dagegen anzukämpfen ;-) aber es gilt immer noch auf der Erde. Conway's Law ist das Gesetz von 1967, das besagt, dass
  „jede Organisation, die ein System (weit definiert) entwirft, ein Design erstellt, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.“
  Anders ausgedrückt: Die Architektur einer Software ist zwangsläufig das Ergebnis der Kommunikationsweisen der an ihrer Gestaltung beteiligten Personen. Beispielsweise wird ein von 3 Teams entwickelter Compiler höchstwahrscheinlich in 3 Durchgängen arbeiten oder 3 verschiedene Module haben.
• Das umgekehrte Conway-Manöver (ICM) lässt Sie glauben, man könnte Conways Gesetz kontrollieren. Anfangs empfahl dieses umgekehrte Manöver klugerweise, „ Silos aufzubrechen, die die Fähigkeit des Teams einschränken, effektiv zusammenzuarbeiten“. Aber hat sich im Laufe der Jahre in eine dumme Empfehlung verwandelt: „ Verändern Sie Ihre Organisation, um Ihre Zielarchitektur zu erreichen “. Blöd, denn denken Sie daran: „Kultur isst Strategie beim Frühstück“. Mehr Infos hier in diesem interessanten Thread.
• Domain Driven Design zwingt keine Organisation auf. Es gibt Schlüssel zum Überleben, auch in Fällen von dysfunktionalen Organisationen (mit Teams, die sich im Krieg befinden oder sich gegenseitig ignorieren). DDD hilft uns, Machtprobleme und soziale Probleme zwischen Teams zu verstehen. Infolgedessen ist es eher ein Werkzeug der Befreiung gegen unsere Determinismen ( also ein linkes Werkzeug würde ich sagen ;-)
• Andererseits gibt uns DDD Werkzeuge an die Hand, um effiziente und möglichst domänengerechte Software entwerfen zu können. Darunter das Konzept des Bounded Context (BC), das uns vorschlägt, Modelle für Anwendungen zu entwerfen und sie zu umgeben und vor Verwirrungen/falschen Freunden/Missverständnissen zu schützen, die aus anderen Kontexten resultieren.
• Für mehr Ausrichtung und Effizienz empfiehlt DDD außerdem dringend, dass wir unsere Vision und unsere Modellierung der Lösung regelmäßig hinterfragen. Es bedeutet auch, Modelle von Zeit zu Zeit nach einem Eureka-Moment (genannt Design Breakthrough ) zu revolutionieren und zu ändern. Deshalb haben wir hier regelmäßig Context-Map-Sessions, die unsere Vision des Feldes mit den Produktleuten ständig verfeinern.
• Entwicklerteams haben fragile Gleichgewichte. Es braucht ungefähr 6 Monate Zusammenleben und zwischenmenschliche Beziehungen, bis ein Entwicklerteam wirklich effektiv ist. Sie fügen diesem Team eine einzelne Person hinzu oder entfernen es und es ist nicht mehr dasselbe Team (siehe Dynamisches Reteaming ). In puncto Effizienz bevorzuge ich Teams, die zusammenbleiben und die Themen wechseln, als Teams, die nur nach Themen explodiert / umverteilt werden. Wenn jemand sein Team oder seine Fächer satt hat, sollte natürlich alles getan werden, um ihm einen Teamwechsel zu ermöglichen (persönliches Wohlbefinden ist noch wichtiger für unsere kollektive Leistungsfähigkeit)
• Unsere derzeitige Organisation und unsere Teams hier bei Agicap sind vielmehr einem oder mehreren Bounded Contexts angegliedert, um die Komplexität des Problems zu berücksichtigen und ein Minimum an unserer jeweiligen Geschäftsexpertise zu nutzen. Von Zeit zu Zeit haben einige Teams möglicherweise einen zu großen Umfang und wir müssen unseren Bounded Context besser schneiden und zuweisen. Auf der anderen Seite muss diese Aufteilung der BCs an Geschäftskonzepte gebunden bleiben (denken Sie an DDD).
• Nichts verbietet Feature-Teams in einer Organisation, die DDD betreibt, solange jeder die Grenzen von Bounded Contexts respektiert.
• Im Moment bevorzugen wir die Praxis des Schwärmens (eine Art Task Force, die mit Leuten aus mehreren Teams eingerichtet wurde, aber wo die Verantwortlichkeit und das Eigentum am endgültigen Artefakt (Tool, API, Bibliothek) von Anfang an definiert sind. Es hilft um das Syndrom „Gut, wir haben was zusammen gemacht, aber wer hält das jetzt noch?!?“ zu vermeiden). Abgesehen von seiner Effektivität , je nach Thema die richtigen Leute zur Zusammenarbeit zu bewegen, bringt das Schwärmen unserer Organisation viel soziales Kapital, indem es vorübergehend teamübergreifende zwischenmenschliche Beziehungen fördert (super nützlich für die Zukunft, wenn jeder zu seinem Team zurückkehrt).
• Unsere aktuelle Produktorganisation ist auf 1 Produktmanager (PM) pro Entwicklungsteam eingestellt, aber vielleicht wäre es interessant, PMs mehr mit Geschäftsthemen als mit ihrem Team in Verbindung zu bringen?

Abschließend möchte ich sagen, dass es in der Organisation keine Wunderwaffe mehr gibt als in der Entwicklung. Kontinuierliches Feedback, Hinterfragen und Experimentieren sind unsere Begleiter auf diesem Weg der kontinuierlichen Verbesserung, um effektiv Software zu entwickeln, die für unsere Benutzer relevant ist.

Hinweis: Dieser Beitrag ist eine Übersetzung eines französischen Artikels, der letzte Woche (14. Oktober 2022) geschrieben wurde.

Um mehr über Agicap zu erfahren:

• Zeigen Sie mir Ihre Domain ( Kontextkartensitzung zur Cashflow-Überwachung und -Prognose )
• https://agicap.com/
• https://career.agicap.com/