Domain-Driven Design Consulting
Software regiert die Welt
Unternehmen oder Behörden bestanden früher aus Fachabteilungen mit ein wenig IT als Unterstützung. Die IT war eine Kostenstelle.
Heute sind Unternehmen riesengroße Apps, die von Fachabteilungen unterstützt werden. IT ist heute mehr Wettbewerbsvorteil als Kostenstelle.
Ich vereinfache natürlich. Doch nicht sehr.
Doch es läuft nicht
Die Software, die wir in Unternehmen entwickeln, ist nicht so wie von den Fachexpert:inn:en gewünscht. Sie “denkt” und verhält sich anders als die Benutzer und die Fachleute erwarten.
Das kommt, weil Domänenexpert:inn:en und IT kein gemeinsames Verständnis, kein gemeinsames Denkmodell haben.
Die Teams, die die Software hervorbringen, haben Mühe in der Zusammenarbeit und kommen deshalb relativ langsam voran, selbst bei Verwendung agiler Methoden. Abhängigkeiten und Rückfragen häufen sich, ein Team muss auf die anderen warten.
Fachbereiche und Benutzer warten währenddessen auch.
Die Modelle, auf denen die Software basiert, sind zu kompliziert. In einem Begriff stecken zu viele Bedeutungen aus den Köpfen zu vieler unterschiedlicher Leute in zu vielen Abteilungen.
Software können wir heute nicht mehr so entstehen lassen wie in 2001, 1991, oder gar 1981. Das wird nichts. Wir müssen uns verändern.
Kultur: Gemeinsam schaffen
Fachexperten ins Team!
Eine der Hauptursachen ist immer noch die Trennung in Fach- und IT-Abteilungen. Viel nützliches Wissen, das man “mal eben” an der Kaffeemaschine austauschen könnte, muss in der Fachabteilung aufgeschrieben, verschickt, dann in der IT gelesen und wieder verstanden werden.
Das wird nichts. Zu viel Arbeit. Zu viele Wissens-Verluste unterwegs. Zu wenig Freude bei den Beteiligten.
Legen Sie Fach und IT zusammen – zu Teams! Teams, die für die Benutzer:innen der Unternehmens-Apps einen bestimmten Wert liefern sollen.
Lassen Sie Fach und IT gemeinsam die Domäne erforschen. Warum sollte eine Expertin im stillen Kämmerlein erforschen, was eine Versicherungspolice ist und es dann mühsam “denen drüben aus der IT” erklären müssen?
Legen Sie Analyse und Design wieder zusammen. Warum sollten Architekt:inn:en und Entwickler:inn:en ganz allein das System aufteilen oder definieren, was das System tun kann und soll?
Wenn Fach und IT gemeinsam analysieren und die Software als Denkmodell entwerfen, verbreitet sich das Domänenwissen viel besser und die Chance, dass die wirklich gewollte Software dabei herauskommt, wird größer.
Jede:r lernt von allen.
So wird das was.
Gemeinsam entwerfen
Fach und IT haben ein Meeting. Sie diskutieren, was eine Versicherungspolice ist. Einmal aus Sicht des Vertriebs. Einmal aus Sicht des Risikos, eben der Versicherungsmathematik. Einmal aus der Sicht was geschieht, wenn der Schadensfall eintritt und bearbeitet werden muss.
Die Police wird jedesmal zu etwas anderem. Und das ist gut so. Warum eine allgemeingültige Police vereinheitlichen wollen, die von drei Abteilungen (Vertrieb, Vertrag und Schaden) auf einmal genutzt werden kann?
Diesen Abstimmungsaufwand können Sie sich sparen.
Was Sie nicht einsparen sollten, ist die Abstimmung zwischen Fach und IT:
- Eine Entwicklerin, die für die Versicherungsmathematik arbeitet, sollte sehr gut verstehen, was eine Police ist.
- Ein Entwickler, der für die Schadenssoftware arbeitet, sollte auch sehr gut wissen, was dort eine Police ist.
- Domänenexpert:inn:en, die mit der IT zusammenarbeiten, lernen, was einfach zu realisieren ist und was nicht.
Erzählen wir mehr Geschichten. Bilden wir Modelle: Denkmodelle, Domänenmodelle. Diskutieren wir sie in einer gemeinsamen Sprache, die bei allen Beteiligten und in allen Artefakten vorkommt (z.B. in Features, Stories, Code, Tests, Produktplan, usw.).
Gemeinsam lernen
Anforderungen veralten, weil man dazulernt. Riesige Anforderungsdokumente zu schreiben, bringt nur etwas, wenn die Abhängigkeiten zwischen ihnen kritisch sind, z.B. im Flugzeugbau.
Im Normalfall (also nicht bei Flugzeugen) können wir erst einmal das Mindeste, das funktionieren würde, denken, diskutieren, modellieren, programmieren, ausprobieren und dann dokumentieren.
Fach und IT erforschen ein Stück der Domäne, orientiert an einigen Features, die die Anwender gern in der nächsten Zeit lauffähig hätten. Sie modellieren gemeinsam das benötigte Stück des Domänenmodells.
Wenn die Entwickler:inn:en dieses Stück umgesetzt haben, lernen Fach und IT daran, wie man es besser machen könnte und modifizieren das Domänenmodell und ihre Sprache entsprechend.
Sie werden schlauer. Die nächsten Schritte werden getan, und Sie werden flotter.
Lassen Sie sich begleiten!
Consulting, online
“Zu utopisch”, sagen Sie? Zu viel Veränderung der bestehenden Arbeitsweise?
“Aber doch irgendwie wünschenswert”, denken Sie?
Holen Sie sich einen Consultant für Domain-Driven Design, kurz: “DDD”. (So heißt die Philosophie, die Methode von der ich weiter oben die ganze Zeit schreibe.)
Holen Sie: mich. Ich habe viele Teams in diese Richtung geschickt und höre immer wieder, wie gut die Ergebnisse sind und wie gut sie vorankommen.
Momentan haben wir 2020, die Zeit von CoViD-19. Holen Sie mich also am besten online dazu.
Online, das heißt auch: preisgünstig und schnell verfügbar, ohne Reisezeiten oder großartige Vorausplanung!
Zuerst: Das Big Picture
Wenn meine Klienten zu DDD aufbrechen, mache ich mit ihnen zuerst einen Big Picture Workshop. Das ist eine Veranstaltung, bei der bis zu 15 Personen zusammenkommen, um gemeinsam einen Überblick zu einer Domäne oder Subdomäne ihres Geschäfts zu bekommen. Ein paar Beispiele:
-
Ein Handelsunternehmen macht solch einen Workshop mit Personen aus Vertrieb, Marketing, Lager, Einkauf, und Rechnungswesen. Im Workshop wollen sie gemeinsam herausfinden, was alles passiert bis der Kunde seine Ware hat und die Rechnung bezahlt ist.
-
Eine Versicherung holt Leute aus dem Kreis der Versicherten, der Makler, des Online-Auftritts, der Versicherungsmathematiker:innen, der Schadensbearbeiter und der Inkasso-Leute. Sie wollen miteinander erforschen, wie ein Versicherungsnehmer die Prozesse des Unternehmens erlebt.
-
Ein Schulungsunternehmen bringt Trainer:innen, Consultants, Social Network-Betreuer und Partner an einen “Platz”, um zu verstehen, was bei Entwicklung, Vermarktung, Buchung, Planung, Durchführung und Abrechnung eines Trainings alles passiert und wie das ineinander greifen muss.
Für solche Big Picture Workshops verwende ich meist Event Storming als Methodik. Diese ist effektiv, bringt Ergebnisse und macht den Beteiligten Spaß.
Sie können in Ihren Erfolg investieren und mich für einen online durchgeführten Big Picture Workshop buchen. Das kostet ?€ plus Mehrwertsteuer.
Dann: Aufteilen auf Teams
Das Event Storming aus dem Big Picture Workshop endet mit einer großen (virtuellen) Wand mit lauter Post-Its darauf. Diese Wand zeigt einen Überblick darüber, wie der Gesamtprozess oder das Geschäftsmodell der Organisation des Klienten funktioniert.
Die Teilnehmer:innen haben an der Wand gleich markiert, in welchen Bereichen des Prozesses wohl Themen abgehandelt werden, die man effizient separieren könnte, weil sie wenig miteinander zu tun haben.
Diese separaten Themenbereiche (in DDD heißen sie “bounded contexts”) eignen sich gut für eine Teamaufteilung. Jeden solchen Themenbereich gibt man in die Hände genau eines Teams.
In einem Multi-Team-Setup Workshop findet diese Aufteilung statt, idealerweise während das Big Picture allen noch gut in Erinnerung ist.
Diese Teamaufteilung ist anspruchsvoll. Teilt man falsch auf, müssen sich die Teams später häufig gegenseitig fragen und um Hilfe bitten, was die Arbeit verlangsamt und schwierig macht. Teilt man gut auf, können sie schlagkräftig voran arbeiten, ohne aufeinander zu warten.
Die Aufteilung muss andererseits auch so erfolgen, dass beim Integrieren der Software aus mehreren Teams nichts schief geht und erst recht kein Chaos entsteht, weil man zu viele, zu unabhängige Teams gebildet hat (der “Flohzirkus-Effekt”).
Ich helfe den beteiligten Teams, Beziehungen zwischen Teams aufzubauen. Beispiel aus dem DDD: “Customer-Supplier-Pattern”. Ein Team sind die Supplier – sie liefern etwas. Das andere Team sind deren Customer – sie benötigen die Software, die von den Suppliers gebaut wird. Beide integrieren, wenn sie etwas fertig haben.
Außer Customer/Supplier gibt es noch mehrere weitere solche Patterns für die Zusammenarbeit der Teams.
Richtig durchgeführt, erspart solch ein Multi-Team-Setup Workshop in der Praxis viel Geld, Zeit und Mühe.
Sie können in Ihren Erfolg investieren und mich für einen online durchgeführten Multi-Team Setup Workshop buchen. Das kostet ?€ plus Mehrwertsteuer für bis zu vier Teams. (Es geht auch mehr, lassen Sie uns darüber sprechen).
Schließlich: Team für Team vorwärtsbringen
Sind die Teams auf dem Weg, kümmere ich mich als Consultant um jedes einzelne der Teams, die gebildet wurden. Das Team verantwortet zukünftig einen bestimmten Kontext, z.B. die Lagerhaltung im Handel.
Wenn ich Teams begleite, höre ich oft Fragen wie diese:
- Wie bekommen wir die Fachleute mit ins Team?
- Wie ist die jetzige Situation?
- Wie funktioniert der Prozess (z.B. Lagerhaltung) ganz genau?
- An welchen Stellen muss der Prozess durch IT unterstützt werden?
- Welche Systeme gibt es in der IT bereits?
- Welche Features werden in Kürze notwendig?
- Welche Bausteine eines Systems sollen erweitert oder neu geschaffen werden?
- Wie sieht unsere Architektur aus, fachlich wie technisch?
- Wer macht was, was machen wir und was die anderen Teams?
- Wie integrieren wir mit dem, was die anderen machen?
- Wie wollen wir erforschen, entwerfen, bauen und dokumentieren?
Ich helfe jedem Team, diese Dinge für sich klar zu bekommen und DDD in den Alltag einzubinden.
Sie können in Ihr Team investieren und mich für eine mehrmonatige Online-Begleitung Ihres Teams buchen. Das kostet ?€ pro Team und Monat, plus Mehrwertsteuer.
Meine Erfahrung sagt, dass ein Team ohne DDD-Vorkenntnisse ca. 6 Monate braucht bis sie alles allein schaffen. Ich sehe das Team danach am besten alle 6 Monate zum Review, oder bei wichtigen Ereignissen auch spontan.
Angebot
Stellen Sie sich hier mit Hilfe der Eingabefelder Ihr persönliches Angebot zusammen. Die Zahl der Workshops und Teams ist einstellbar.
| Workshops | ||
|---|---|---|
| Big Picture Workshop zu ? € | ? € | |
| Multi-Team Setup-Workshop zu ? € | ? € | |
| Summe | ? € | |
| Mehrwertsteuer | ? € | |
| einmalig | ? € | |
| Teambegleitung monatlich | ||
| je Team monatlich ? € | ? € | |
| Summe | ? € | |
| Mehrwertsteuer | ? € | |
| monatlich | ? € | |
| Infos anfragen | ||
Big Picture-Workshops
Was genau ist in einem Big Picture-Workshop enthalten?
Domänen-Überblick bekommen
Die Domänenexpert:inn:en werden eingeladen zu einer online-Veranstaltung mit Video, Audio und Whiteboard. Alle Personen erzählen, wie aus ihrer Sicht das Geschäft funktioniert:
- Sie tragen die wichtigen Ereignisse im Geschäftsprozess zusammen, die passieren müssen, damit er funktioniert.
- Sie markieren Personen, Rollen und Systeme, die am Geschäft beteiligt sind.
- Sie kennzeichnen Stellen, an denen Wert geschaffen oder Wert vernichtet wird.
- Sie markieren unklare Stellen mit Fragen, Problemen, Blockern oder Warnungen.
- Sie markieren entscheidende Ereignisse, bei denen der Geschäftsprozess Schwung nach vorn erhält.
Wissen in alle Köpfe bringen
Es bildet sich am Whiteboard eine Struktur, die am Schluss der Veranstaltung in allen Köpfen vorhanden ist. Das ist die eigentliche Stärke des Big Picture-Workshops: Am Ende weiß jeder, was die anderen wissen.
Vorher war das Wissen meist Silo-artig verteilt. Jeder kannte nur einen Ausschnitt der Wahrheit.
Das Mosaik schließen
Ich hatte einen Klienten. Sie hatten bereits 6 Monate lang ohne mich Business-Analyse gemacht und ein großes Dokument mit Use Cases verfasst. Sie glaubten also, sie kennten ihr Geschäft.
Aus irgendeiner Intuition heraus riefen sie mich trotzdem zu einem Event Storming Workshop (Big Picture-Erstellung, plus etwas mehr).
Am Ende des ersten Workshop-Teils hingen am Whiteboard 60 (in Worten: sechzig!) Post-its mit Fragen, Problemen, Blockern, Warnungen, usw.
Die Projektleiterin war in der Pause geschockt und frustriert. Sie hatte erwartet, dass nach 6 Monaten Vorarbeit nichts mehr auftauchen würde.
Sie staunte danach nicht schlecht, als ihre Leute im zweiten Workshop-Teil alle Probleme durchdiskutierten, nach und nach ausräumten und auflösten. Das Whiteboard zeigte zum Schluss sehr klar, wie das Geschäft läuft, welche Ereignisse auftreten, welche Personen und Systeme mitspielen, und wo Wert entsteht bzw. verloren geht.
Was Menschen bisher nur als Mosaiksteine kannten, ergab nun ein geschlossenes Bild. Und sie waren sich einig darüber. Sehr cool!
Multi-Team Setup Workshops
Was genau ist in einem Multi-Team Setup Workshop enthalten, was findet dort statt?
Arbeit nach Fachkontexten aufteilen
Immer dann, wenn eine Domäne so groß ist, dass sie nicht von einem Team bewältigt werden kann, muss man sich die Arbeit aufteilen. Die Frage nach dem Teamschnitt entsteht:
- Wie viele Teams brauchen wir?
- Welches Team wird was machen?
- Wie werden die Teams sich vernetzen, zusammenarbeiten und ihre Ergebnisse integrieren?
DDD kennt dafür den Begriff “strategic design”.
In einem Multi-Team Setup Workshop lade ich die beteiligten Personen ein, sich erneut mit dem Ergebnis des Big Picture-Workshops zu beschäftigen. Sie sollen als Erstes auf dem Whiteboard, das es von vorher noch gibt, Bereiche identifizieren, die im Geschäft abgeschlossene, möglichst wenig abhängige Aufgabengebiete darstellen.
Beispiel: Im Lager eines Handelsunternehmens könnte es Prozesse für den Wareneingang, für die Bestandssteuerung und für den Warenausgang (z.B. die Zusammenstellung der Waren für jede Lieferung) geben.
Sind diese “Kontexte” einmal gefunden, bitte ich die Anwesenden, zu definieren, welcher Kontext mit welchem anderen zusammenarbeiten muss (z.B. Wareneingang mit Bestand, Bestand mit Warenausgang, doch eben nicht Wareneingang mit Warenausgang).
Immer wenn es zwei Kontexte gibt, die zusammenarbeiten, sollen die Anwesenden dann herausfinden, welcher Kontext “machen kann was er will” und welcher jeweils andere Kontext davon betroffen sein wird.
Das Gesamtergebnis dieser Aktivitäten nennen wir in DDD eine “Context Map” oder Kontextlandkarte. Sie hilft beim nächsten Schritt, dem Aufstellen der Teams.
Schlagkräftige Teams aufstellen
Die Kontexte aus dem vorherigen Schritt zeigen, wie viele Teams Sie gründen können. Jeder Kontext sollte von genau einem Team betreut werden. Starke Teams können u.U. auch mehr als einen Kontext betreuen, doch nicht umgekehrt.
Ich bitte im Multi-Team Setup Workshop also nun die Anwesenden, sich nach KnowHow und Fähigkeiten In Teams zu gruppieren und jeweils einen Kontext zu übernehmen.
So bekommen Sie schlagkräftige Teams, die sich im Alltag nicht dauernd zu fragen brauchen und nicht aufeinander zu warten brauchen, um vorwärts zu kommen.
Mehrere Teams geordnet zusammenarbeiten lassen
Manche meiner Klienten hatten 13 Teams zu je 6 Leuten. Das ist viel. Da kann sehr viel Gutes aber auch schnell einiges Chaos entstehen.
Was Sie im vorherigen Schritt getrennt haben, müssen Sie beim Zusammenbau zu einer lauffähigen Lösung wieder miteinander integrieren.
Im Multi-Team Setup Workshop sprechen wir also auch darüber, wie Sie im Team integrieren, testen und das Chaos verhindern, zum Beispiel durch Abgrenzungs-Patterns, die DDD für Sie bereithält.
So bekommen Sie eine geordnete Zusammenarbeit vieler Teams, die möglichst unabhängig voneinander vorwärts arbeiten.
Begleitung eines Teams im Alltag
Zusammenarbeit zwischen Fach und IT
Die Domänenexpert:inn:en haben Fachwissen über Prozesse und Daten des Unternehmens. Früher schrieben sie auf, was die Software leisten sollte. Entwickler realisierten das dann, und man hatte Glück, wenn das herauskam, was die Fachexpert:inn:en gemeint hatten.
Dann kamen die agilen Methoden. Tams sprachen mit den Fachleuten intensiver darüber, was die Software tun sollte, doch sie modellierten und programmierten immer noch fast allein in der IT.
Heute, mit Domain-Driven Design, können sich die Fachleute viel mehr in die Entwicklung einmischen. Modelle, aus denen Software wird, entstehen in gemeinsamer Arbeit von Fachleuten und IT, ohne dass die Fachleute deswegen zu Programmierern werden müssten.
Ich begleite Ihre Teams in diesem Umstellungsprozess. Sie vergrößern damit die Chance, dass genau die Software herauskommt, die zu Ihrem Unternehmen passt.
Zu Anfang finden wir gemeinsam heraus, welche Fachexpert:inn:en es für die umzusetzenden Features gibt, die Sie vorhaben. Wir laden sie ein, zusammen mit den anderen Leuten im Team die zukünftig entstehende Software zu gestalten, indem sie zunächst an Modellen für diese Software mitarbeiten.
Prozesse modellieren
Fachleute kennen die Prozesse in Ihrem Unternehmen. Sie zerlegen pro Iteration einen kleinen Prozess-Ausschnitt in einzelne Schritte und kennzeichnen dabei:
- handelnde Personen,
- beteiligte Systeme,
- benötigte und zu produzierende Informationen,
- auftretende Ereignisse (domain events),
- und typische Vorgehensweisen, wenn ein bestimmtes Ereignis eintritt.
Solch ein Prozess-Ausschnitt bildet die Grundlage für den nächsten Schritt, den Entwurf der Softwarekomponenten.
Alle Ergebnisse sind sehr klein und übersichtlich, denn sie sollen ja zum Ende der Iteration fertig und lauffähig sein.
Software entwerfen
Aus dem Prozessmodell erkennen wir die beteiligten Systeme. Für diejenigen Systeme, die zu Ihrer eigenen IT gehören, ermittelt das Team (Fachleute und IT gemeinsam), welche Komponenten die eingehenden Informationen verarbeiten und die ausgehenden Ereignisse an den Prozess signalisieren sollen.
Diese Softwarekomponenten betrachtet das Team nun ganz genau und legt deren Verantwortlichkeit und Schnittstellen fest. Sie fassen die im Domänenmodell vorkommenden Objekte zu Komponenten zusammen und ordnen sie der Verantwortlichkeit entsprechend ein.
Das bereitet die Komponenten, die es noch nicht gibt, für die Entwicklung vor. Die anderen, die es schon gibt, werden etwas aufgeräumt und deren Schnittstellen angepasst.
Programmieren
Jetzt können die Entwickler:innen im Team die beschriebenen Komponenten in Code umsetzen. Sie verwenden dazu bewährte Verfahren wie z.B. Beispiel-getriebene Entwicklung (früher bekannt als TDD).
Entwickler:innen markieren die Codestellen, die für die Dokumentation wichtig sind, so dass der automatische Build-Lauf auch das notwendige Maß an Dokumentation daraus automatisch erzeugen kann.
Die lauffähige Software und die Dokumentation präsentieren die Entwickler:innen dann den Fachleuten am Ende der Iteration.
Frühes Zeigen und Vergleichen bringt Qualität
Fachleute und Entwickler:innen treffen sich am Ende der Iteration zu einem Review.
Sie vergleichen das, was am Anfang der Iteration besprochen und in Prozessbild, Domänenmodell und Softwareentwurf erstellt wurde, mit dem, was hier und jetzt lauffähig ist:
- Haben wir das umgesetzt, was wir modelliert hatten?
- Können wir daraus etwas lernen?
- Können wir die Modelle verbessern?
Fachleute sind hier ebenfalls voll eingebunden. Sie sind verantwortlich dafür, den Entwickler:innen Rückmeldung zu geben, ob alles so stimmt und ob man so fortfahren kann oder noch etwas geändert werden sollte. Fachleute gewinnen durch die Mitarbeit am Domänenmodell mehr Einfluss als zuvor.
Stellen Sie sich hier mit Hilfe der Eingabefelder Ihr persönliches Angebot zusammen. Die Zahl der Workshops und Teams ist einstellbar.
| Workshops | ||
|---|---|---|
| Big Picture Workshop zu ? € | ? € | |
| Multi-Team Setup-Workshop zu ? € | ? € | |
| Summe | ? € | |
| Mehrwertsteuer | ? € | |
| einmalig | ? € | |
| Teambegleitung monatlich | ||
| je Team monatlich ? € | ? € | |
| Summe | ? € | |
| Mehrwertsteuer | ? € | |
| monatlich | ? € | |
| Infos anfragen | ||
Online Consulting
Ich begleite Sie als Online-Consultant in all diesen Schritten der Modellierung und Entwicklung:
Online Event Storming Sessions
Für den Big Picture-Workshop nutze ich die Event Storming-Methodik von Alberto Brandolini.
Es handelt sich um sehr interaktive Workshops mit vielen Leuten vor einem virtuellen Whiteboard, das jeder vor sich auf dem Bildschirm hat. Alle “kleben” Post-Its auf dieses Whiteboard und erzeugen dadurch einen sehr guten Überblick über das Geschäftsmodell des Unternehmens.
Man kann beobachten, was die jeweils anderen modellieren und rechtzeitig seine Meinung dazu abgeben oder einfach gleich mit eigenen Post-Its zum Bild beitragen.
Ich helfe mit “dummen” Fragen, Klarheit in ein normalerweise chaotisches Modell zu bringen. Dadurch haben die Teilnehmer am Ende ein aufgeräumtes Bild, das sie für die Aufteilung in Kontexte und Teams nutzen können.
Dasselbe Whiteboard-Tool nutzen wir auch im Multi-Team Setup Workshop, um die Kontexte abzugrenzen und auf Teams zu verteilen.
Online Modellier-Sessions
Teams erzeugen mit meiner Hilfe viele Arten von Modellen:
- Überblicksmodell
- Prozess-Ausschnitts-Modell
- Fachklassen-Modell
- Komponentendesign-Modell
- Code
Die ersten dieser Modelle erzeugen wir gemeinsam, in Online-Sitzungen in Miro. Manchmal genügt ein Prozessmodell für mehrere Iterationen, machmal geht es recht fix über Fachklassen zum Komponentendesign und zum Code.
In jedem Fall helfe ich den Teams mit automatischen Mappings, von den Klebezetteln in Miro schnell zum Code zu kommen. Denn ausführbarer Code ist die Wahrheit, oder nicht?
Diskussionsforum online, asynchron
Damit Ihre Leute nicht stundenlang in Videokonferenzen sitzen, ermögliche ich so viel asynchrone Arbeit wie möglich. Ein Diskussionsforum ist dafür sehr gut geeignet. Wenn Sie möchten, liefere ich eines mit. Wenn Sie schon eines im Hause haben, nehmen wir das.
Videokonferenzen
Wenn die Arbeit mit den Teams synchron gemacht werden muss, zum Beispiel bei Reviews, Retrospektiven oder Frage/Antwort-Stunden, verwenden wir Videokonferenz-Tools wie Zoom, Microsoft Teams oder Jitsi Meet. Auch Modellierung wird synchron, mit Video- und Audio-Unterstützung, gemacht.
Review + Feedback durch mich
Die Teams bekommen zu ihren Modellen und zum Code Feedback von mir. Ich prüfe, ob die methodischen Regeln korrekt eingehalten wurden und ob die entstandenen Modelle und der Code klar und aussagekräftig sind.
So bekommen Sie bei Ihren ersten Schritten mit Domain-Driven Design die Unterstützung, die Sie und Ihre Teams benötigen.
Software-Entwicklung heute
Zusammenfassung: So geht Software-Entwicklung heute:
Miteinander sprechen
- Anwender
- Fachbereiche
- Produktteams
- Support
Gemeinsam entwerfen
- Klare Architektur
- Standardisierte Bausteine
- Lauffähige Software
- Gerade genug Dokumentation
Strategisch vorgehen
- Klare Arbeitsaufteilung
- Schlagkräftige Teams
- Fachlich richtiger Schnitt
- Beherrschbare Komplexität
Diese Seite wurde erstellt von Matthias Bohlen. Mehr Informationen zu mir und meiner Arbeit finden Sie auf meiner Homepage.
Die obigen Beispiel-Ergebnisse stammen aus meiner DDD-Schulung, nicht aus realen Projekten, weil reale Bilder Kundenwissen offenlegen würden.
Weiterführende Links
Wenn Ihnen diese Seite über DDD-Consulting gefallen hat, interessieren Sie wahrscheinlich auch diese beiden über meine DDD-Trainings:
Domain-driven Design Camp
Kontakt
Sie können mich gern per E-Mail oder telefonisch erreichen:
- Schreiben Sie an mbohlen@mbohlen.de.
- Rufen Sie mich an unter +491707728545.
Kommentare
Anmerkungen, Ideen oder Feedback zu dieser Seite? Bitte hier hineinschreiben, ich freue mich darauf!