WEBVTT

00:00:00.017 --> 00:00:03.837
Ich habe mir dann Gedanken gemacht, warum kriegen wir das eigentlich nicht hin,

00:00:04.917 --> 00:00:08.497
Software Requirements richtig zu erfassen und zwar so, dass es halt jeder versteht,

00:00:08.517 --> 00:00:12.117
so dass es die Fachseite versteht, so dass es Security versteht,

00:00:12.117 --> 00:00:14.697
so dass es UX versteht, jeder.

00:00:16.257 --> 00:00:21.137
Das Modell eignet sich ganz hervorragend, wirklich ganz hervorragend für eventbasierte Systeme.

00:00:21.617 --> 00:00:26.077
In eventbasierten Systemen kannst du das Eventmodell eins zu eins im Code abbilden.

00:00:26.677 --> 00:00:29.697
Ich könnte dem Postboten was vom Eventmodelling erzählen. Ich rede wirklich

00:00:29.697 --> 00:00:30.837
extrem gerne über das Thema.

00:00:30.977 --> 00:00:33.517
Also wenn das jemanden interessiert, wirklich sehr, sehr gerne melden.

00:00:33.577 --> 00:00:35.237
Ich rede stundenlang drüber.

00:00:35.920 --> 00:01:00.880
Music.

00:00:59.217 --> 00:01:02.877
Revision 606,

00:01:29.217 --> 00:01:31.817
moderne Verwaltungsoberfläche gebaut, mit der das Arbeiten Spaß macht.

00:01:31.957 --> 00:01:33.877
Aber jetzt mal ehrlich unter uns Nerds.

00:01:34.037 --> 00:01:38.597
Sachen anklicken? In einem User-Interface? Muss das sein? Nein, muss es nicht.

00:01:38.777 --> 00:01:42.697
Denn bei Midwild gibt's die M-Studio CLI. Mit der könnt ihr euer Hosting komplett

00:01:42.697 --> 00:01:45.937
über die Kommandozeile verwalten und natürlich auch entsprechend automatisieren.

00:01:46.117 --> 00:01:49.637
Von Nerds für Nerds bringt euch Midwild die optimale Developer-Experience,

00:01:49.717 --> 00:01:50.757
wenn's ums Hosting geht.

00:01:50.877 --> 00:01:54.877
Und deshalb jetzt auf zu midwild.de slash workingdraft.

00:01:55.057 --> 00:01:59.077
Denn da wartet auf euch exklusiv als Hörer von WorkingDraft das Angebot,

00:01:59.077 --> 00:02:02.017
den Tarif pro Space für 30 Tage kostenlos zu nutzen.

00:02:02.117 --> 00:02:05.437
Das war nochmal mittwald.de.

00:02:05.957 --> 00:02:10.677
Wir danken Mittwald für die Unterstützung von dieser Revision von Working Draft.

00:02:12.381 --> 00:02:17.961
Hallo und herzlich willkommen beim Working Draft. Wir sind heute zu dritt.

00:02:18.021 --> 00:02:21.321
Vom Team habe ich mit dabei den Peter. Moin, moin.

00:02:22.201 --> 00:02:27.201
Und als Gast haben wir einen Wiederholungsgast, und zwar den Martin Dilger,

00:02:27.381 --> 00:02:32.841
der vor kurzem schon mal bei uns bei der Revision 594 vorbeigeschaut hat,

00:02:32.961 --> 00:02:36.621
als es darum ging, vom Chaos zu Code. Gerne nachhören.

00:02:37.061 --> 00:02:40.861
Martin, ich freue mich riesig, dass du wieder mit bei uns am Start bist,

00:02:40.861 --> 00:02:45.641
Für die ein paar Hörer, Hörerinnen, die vielleicht die 594 doch noch nicht gehört

00:02:45.641 --> 00:02:49.021
haben, magst du dich nochmal einmal kurz vorstellen, wer du so bist?

00:02:49.541 --> 00:02:53.641
Ja, hallo. Ich freue mich auch sehr, wieder da zu sein. Ich bin der Martin Dillger.

00:02:53.821 --> 00:02:59.681
Ich bin Geschäftsführer der Nebulit GmbH, Softwareentwickler seit mehr als 15 Jahren,

00:02:59.941 --> 00:03:05.181
mache ganz viel IT-Architektur und arbeite in letzter Zeit sehr,

00:03:05.281 --> 00:03:09.701
sehr viel im Bereich Requirements Engineering und helfe Unternehmen,

00:03:10.001 --> 00:03:12.801
die richtigen Requirements zu finden für ihre Software.

00:03:14.081 --> 00:03:17.521
Und damit kommst du auch zumindest mir Wege rufen,

00:03:18.481 --> 00:03:22.941
denn kürzlich erst, als wir unsere Live 600 aufgenommen haben,

00:03:23.101 --> 00:03:27.401
hatten wir ein bisschen gesprochen auch über Designsysteme und Pattern Libraries

00:03:27.401 --> 00:03:31.221
und größere Systeme und ich habe die ganze Zeit verzweifelt ein Wort gesucht,

00:03:31.221 --> 00:03:35.041
von dem ich schon mal hörte, dass da ganz viele Leute, so die ganze Firma,

00:03:35.101 --> 00:03:36.321
nicht nur Devs, nicht nur Design,

00:03:36.561 --> 00:03:41.701
quasi vor so einer Tafel steht und Striche aufzeichnet, um Dinge zu machen.

00:03:41.921 --> 00:03:45.081
Und du hast mich bereits in der Vorbesprechung schon darüber aufgeklärt,

00:03:45.101 --> 00:03:49.061
dass das wohl Eventstorming ist und mich auch darauf vorbereitet,

00:03:49.101 --> 00:03:53.301
dass wir heute ein bisschen auch in die ungefähre Richtung von dieser Thematik

00:03:53.301 --> 00:03:56.081
gehen. Deswegen freue ich mich da natürlich sehr drauf.

00:03:56.281 --> 00:04:00.501
Also du hast quasi meinen Hilferuf aus der 600 gehört, als ich meinte,

00:04:00.501 --> 00:04:03.281
kennt sich denn irgendjemand damit aus?

00:04:04.001 --> 00:04:08.561
Genau so ist es. Aber jetzt überreiche ich dann gleich schon mal das Wort an

00:04:08.561 --> 00:04:10.681
dich. Womit geht es denn los?

00:04:12.471 --> 00:04:18.311
Die letzten sechs Monate habe ich im Prinzip über nichts anderes nachgedacht,

00:04:18.311 --> 00:04:23.211
als was ist denn eigentlich das größte Problem, was wir in der Softwareentwicklung haben?

00:04:24.191 --> 00:04:27.731
Woran scheitert es denn? Denn wenn du dir die meisten Softwareprojekte anschaust,

00:04:27.851 --> 00:04:29.711
dann funktionieren die nicht so richtig gut.

00:04:30.811 --> 00:04:33.791
Kannst du wahrscheinlich bestätigen. Das bestätige ich.

00:04:34.011 --> 00:04:38.711
Genau. Ich bestätige das auch so weit, dass jedes Mal, wenn ich bei Unternehmen

00:04:38.711 --> 00:04:43.131
bin und bei deren Jobseiten sehe, irgendwas von wir verwenden die coolste Technologie

00:04:43.131 --> 00:04:47.611
oder sowas, denke ich mir schon, das glaube ich ja noch nicht.

00:04:47.611 --> 00:04:51.911
Auf der anderen Seite, wenn ich von, auch sehr großen Firmen dann höre,

00:04:51.911 --> 00:04:53.491
die sich fast schon entschuldigen wollen,

00:04:53.711 --> 00:04:56.371
also bei uns ist ja irgendwie, da sind so komische Sachen drin,

00:04:56.551 --> 00:05:01.671
wo ich mir denke, ich kenne, egal ob Startup oder die größte Firma der Welt,

00:05:01.751 --> 00:05:05.171
ich kenne keine Codebase ohne komische Sachen.

00:05:06.831 --> 00:05:10.191
Richtig. Das ist, genau so ist es.

00:05:10.371 --> 00:05:13.511
Und was glaubst du denn, was ist denn das größte Problem in der Softwareentwicklung?

00:05:13.651 --> 00:05:15.571
Was würdest du denn sagen? Woran scheitert es denn?

00:05:16.091 --> 00:05:19.811
Also ich bin überhaupt nicht darauf vorbereitet. Ich rede jetzt einfach,

00:05:19.871 --> 00:05:21.451
was mir jetzt im Kopf kommt.

00:05:22.151 --> 00:05:26.471
Und ein bisschen habe ich schon auch das Gefühl, dass man ja von vorher immer

00:05:26.471 --> 00:05:32.751
heutzutage nicht mehr so weiß, wo man eigentlich am Ende hinaus kommen möchte. Und...

00:05:34.995 --> 00:05:39.675
Und dadurch muss man ja trotzdem, auch wenn man das jetzt nicht mit Workarounds

00:05:39.675 --> 00:05:43.635
und Hotfixes macht, sondern schon noch professionell, aber man erweitert halt

00:05:43.635 --> 00:05:44.995
immer ein bestehendes Haus.

00:05:47.075 --> 00:05:51.635
Und man hat natürlich, ich meine, es gibt unfassbar viele Software-Engineers

00:05:51.635 --> 00:05:54.975
und irgendwie machen wir alle sehr gleiche Sachen, sehr ähnliche Sachen,

00:05:55.135 --> 00:05:59.455
aber wir brauchen, trotzdem brauchen wir immer unsere eigene Special-Lösung.

00:06:00.195 --> 00:06:03.615
Und ich glaube, dass man für diese Special-Lösungen dann immer Sachen baut,

00:06:03.655 --> 00:06:07.335
die so ein bisschen implizites Wissen da drin haben und die werden dann auch

00:06:07.335 --> 00:06:11.775
immer so ein bisschen merkwürdig und die sind halt sehr eng mit Produkt- oder

00:06:11.775 --> 00:06:13.475
Firmenkultur auch verwebt.

00:06:13.475 --> 00:06:18.375
Deswegen denke ich, das, was für mich vielleicht auch komisch wird bei Software-Strukturen,

00:06:18.435 --> 00:06:23.275
ist das, was vielleicht auch wirklich von der Firmenkultur da so ein bisschen mit reinkommt.

00:06:25.995 --> 00:06:30.355
Ich habe Anfang 2024 eine Umfrage gemacht auf LinkedIn, weil ich wissen wollte,

00:06:30.435 --> 00:06:33.115
was ist denn jetzt eigentlich das größte Problem? Außer Namen finden.

00:06:34.835 --> 00:06:39.375
Namen finden ist natürlich auch ein großes Problem, aber das größte Problem sind Requirements.

00:06:39.855 --> 00:06:43.675
Also insgesamt einfach Requirements. Was sind die Anforderungen an die Software?

00:06:43.715 --> 00:06:46.535
Was sind die Requirements, die du umsetzen musst?

00:06:47.195 --> 00:06:51.235
Wie kriegst du typischerweise deine Requirements? Du kriegst eine User-Story.

00:06:51.915 --> 00:06:55.635
Die meisten User-Stories, die ich in meiner täglichen Arbeit zu sehen bekomme,

00:06:56.135 --> 00:06:59.875
die sind meistens eine Überschrift und eine Deadline. Vielmehr steht da eigentlich oft nicht drin.

00:07:01.475 --> 00:07:06.715
Kennst du diese Art User-Stories? Ja, ja. Ich kenne auch Notion-Tickets.

00:07:08.375 --> 00:07:13.095
Ja, auch das. Genau. Und ich habe mir dann Gedanken gemacht,

00:07:13.235 --> 00:07:14.595
wieso ist denn das eigentlich so?

00:07:14.655 --> 00:07:19.535
Warum kriegen wir das eigentlich nicht hin, Software Requirements richtig zu

00:07:19.535 --> 00:07:21.515
erfassen? Und zwar so, dass es halt jeder versteht.

00:07:21.575 --> 00:07:25.135
So, dass es die Fachseite versteht, so, dass es Security versteht,

00:07:25.155 --> 00:07:27.855
so, dass es UX versteht. Jeder. Jeder.

00:07:28.995 --> 00:07:33.155
Und ich glaube tatsächlich, das Problem ist, was wir nie gefunden haben in dieser

00:07:33.155 --> 00:07:36.535
ganzen Softwareindustrie, in der wir alle arbeiten, ist sowas wie eine gemeinsame Sprache.

00:07:37.895 --> 00:07:41.055
Jeder definiert im Prinzip das, was er braucht an seiner Software.

00:07:41.635 --> 00:07:45.275
Der Datenbank-Admin definiert irgendwelche SQL-Skripte.

00:07:45.335 --> 00:07:48.575
UX definieren irgendwelche Screens, die gemacht werden müssen.

00:07:48.575 --> 00:07:53.655
Du hast die Entwickler, die irgendwelche UML-Diagramme zeichnen, wenn überhaupt.

00:07:53.875 --> 00:07:56.455
Vielleicht schreiben sie auch nur Code. Du hast den Product Owner,

00:07:56.695 --> 00:07:59.855
der die User Stories schreibt.

00:08:00.455 --> 00:08:04.835
Jeder kocht so ein bisschen seine eigene Suppe, aber wir kommen da nie so richtig gut zusammen.

00:08:05.735 --> 00:08:10.935
Und ich glaube, das ist einer der großen Probleme, warum wir einfach keine guten

00:08:10.935 --> 00:08:12.975
Requirements an unsere Software hinbekommen.

00:08:13.455 --> 00:08:15.235
Wir haben keine Sprache, mit der wir reden können.

00:08:17.342 --> 00:08:21.622
Und andere, die komplexe Sachen bauen, haben die. Also wenn ich mir jetzt irgendwie

00:08:21.622 --> 00:08:26.002
so einen fetten, keine Ahnung, so einen fetten, hier, zivilen Flieger vorstelle,

00:08:26.102 --> 00:08:32.242
würde ich ja sagen, ist ja mit so einem dicken Software-Problem ja auch ungefähr vergleichbar.

00:08:32.242 --> 00:08:36.182
Also du hast ja irgendwie so wirtschaftliche Requirements, das soll so und so

00:08:36.182 --> 00:08:39.162
viel kosten und du hast irgendwie Anforderungen zu erfüllen,

00:08:39.222 --> 00:08:42.362
so gesetzlicherseits und hast du nicht gesehen.

00:08:42.762 --> 00:08:45.722
Also haben die dann einfach eine gemeinsame Sprache, mit der sie das hinkriegen

00:08:45.722 --> 00:08:47.182
oder fehlt da was anderes?

00:08:47.182 --> 00:08:51.462
Der große Unterschied zur Softwareindustrie meiner Ansicht nach ist,

00:08:51.522 --> 00:08:54.722
dass du, wenn du jetzt ein großes Flugzeug baust oder wenn du ein großes Haus

00:08:54.722 --> 00:08:57.942
baust, dann ist das alles reguliert und zwar bis ins kleinste Detail.

00:08:58.022 --> 00:09:01.422
Du brauchst Zertifikate, es ist alles bis ins kleinste Detail reguliert.

00:09:01.542 --> 00:09:06.282
Und deswegen greifen die meisten Gewerke da gut ineinander und es funktioniert.

00:09:07.542 --> 00:09:10.782
In der Software ist das Ganze ein bisschen anders, denn da hast du sowas nicht.

00:09:12.182 --> 00:09:15.502
Ein Softwareentwickler, der bekommt eine User-Story und der versucht,

00:09:15.562 --> 00:09:19.662
diese User-Story nach Besten und Gewissen umzusetzen, aber das,

00:09:19.722 --> 00:09:23.602
was der umsetzt, ist halt nicht unbedingt das, was jetzt beispielsweise die

00:09:23.602 --> 00:09:24.842
Fachseite wirklich braucht,

00:09:24.942 --> 00:09:27.302
sondern das ist halt immer das, was er halt versteht aus dieser User-Story.

00:09:27.902 --> 00:09:32.802
Okay, also die User-Story ist sozusagen nicht präzise genug definiert im Vergleich

00:09:32.802 --> 00:09:36.302
zu ich habe hier irgendwie was, das muss dieses Material sein und so weit müssen

00:09:36.302 --> 00:09:39.702
die Bohrlöcher auseinander sein, um jetzt in der Analogie zu bleiben.

00:09:40.382 --> 00:09:43.882
Ganz genau. Eine User-Story ist geschriebener Text.

00:09:44.082 --> 00:09:47.182
Ja. Meistens. Die meisten User-Stories, die du als Entwickler bekommst,

00:09:47.222 --> 00:09:49.222
ist in irgendeiner Art und Weise geschriebener Text.

00:09:49.722 --> 00:09:52.842
Und geschriebener Text ist halt relativ ungenau.

00:09:53.562 --> 00:09:56.262
Ist nicht vergleichbar mit so einem Bauplan von so einem Haus beispielsweise.

00:09:56.802 --> 00:10:00.462
Um auch bei der Analogie zu bleiben, ich habe ja so diverse Erfahrungen mit

00:10:00.462 --> 00:10:02.622
Hausrenovieren letztes Jahr gesammelt.

00:10:04.022 --> 00:10:07.722
Dementsprechend weiß ich auch, da sind sehr viele Sachen reguliert und die Pläne,

00:10:07.802 --> 00:10:10.882
die ich selber da gesehen habe, die waren teilweise sehr genau,

00:10:10.962 --> 00:10:13.362
dass ich mir selber dachte, da kann ja gar nichts schief gehen.

00:10:13.622 --> 00:10:16.622
Da geht auch erstaunlich viel schief, nur…,

00:10:17.657 --> 00:10:20.877
Die Sachen mussten teilweise eben so komplett ersetzt werden.

00:10:21.077 --> 00:10:24.877
Wir hatten das Glas bestellt und da waren einfach leider die falschen Bohrlöcher

00:10:24.877 --> 00:10:27.097
drin. Das fällt natürlich sofort auf.

00:10:27.737 --> 00:10:33.777
Und da gibt es keinen Hotfix. Also man kann halt ein Glasloch nicht mit Glas wieder zumachen.

00:10:34.117 --> 00:10:36.817
Und dann wurden wir auch angeschaut, ist das so okay? Und ich so,

00:10:36.897 --> 00:10:39.477
es tut mir unfassbar weh für die Umwelt.

00:10:39.577 --> 00:10:41.937
Aber nein, das ist nicht okay. Da ist ein Loch in einem Glas.

00:10:42.077 --> 00:10:43.257
Da soll es halt nicht durchregnen.

00:10:44.197 --> 00:10:48.697
Und das musste halt komplett nochmal gemacht werden. Und bei der Software ist

00:10:48.697 --> 00:10:53.937
mir das zumindest tatsächlich jetzt so gut wie nie, wenn ich gar nicht über

00:10:53.937 --> 00:10:57.597
den Weg gelaufen, dass man wirklich gesagt hat, ja, das stimmt so jetzt nicht.

00:10:57.737 --> 00:11:01.637
Wir müssen das nochmal von vorne neu machen, sondern dann wurde halt dran rumgebastelt.

00:11:01.677 --> 00:11:05.557
Ist vielleicht auch einfach in der Software so, dass man ja normalerweise Code

00:11:05.557 --> 00:11:10.317
nochmal anpassen kann, im Gegensatz zu einem fixen Glas. Was du jetzt gerade

00:11:10.317 --> 00:11:14.137
noch gemeint hast, ist, mit jeder kocht ein eigenes Süppchen.

00:11:15.357 --> 00:11:22.197
Kommt das aus einer Sicht heraus, dass du meinst, so wie es einem halb selber so am besten passt?

00:11:22.657 --> 00:11:26.397
Oder soll ich das jetzt eher in die Richtung verstehen, wie das ist aber sehr

00:11:26.397 --> 00:11:30.737
unbeabsichtigt und einfach nur der Kommunikation geschuldet,

00:11:30.737 --> 00:11:36.417
dass man mit anderen Worten Sachen bespricht oder auch andere Assoziationen

00:11:36.417 --> 00:11:37.737
zu bestimmten Wörtern im Kopf hat?

00:11:38.457 --> 00:11:41.797
Das ist mit Sicherheit ein Punkt. Und auch wenn du dir jetzt zwei Entwickler

00:11:41.797 --> 00:11:45.457
anschaust, die das gleiche Requirement umsetzen,

00:11:45.537 --> 00:11:48.177
dann wird die Umsetzung höchstwahrscheinlich nicht gleich aussehen.

00:11:48.777 --> 00:11:52.417
Denn jeder macht es ja auf seine Art und Weise. Wenn ich Software schreibe,

00:11:52.417 --> 00:11:56.037
schreibe ich die bestimmt ein bisschen anders als du. Das ist halt nicht standardisiert.

00:11:57.825 --> 00:12:01.685
Es ist halt eine, nennen wir es mal eine menschliche Tätigkeit, Software zu schreiben.

00:12:02.145 --> 00:12:06.425
Ja, aber ich meine, wenn man dir jetzt irgendwie so einen RFC-mäßigen Standard vorsetzen würde,

00:12:06.565 --> 00:12:09.245
dann würden sicherlich auch zwei unterschiedliche Implementierungen rauskommen,

00:12:09.365 --> 00:12:13.385
aber die sollten ja dann zumindest grob die gleichen Ziele verfolgen,

00:12:13.425 --> 00:12:16.645
auf ungefähr vergleichbare Weisen mit etwas kompatiblen Interfaces,

00:12:16.665 --> 00:12:18.305
die da rausfallen. Warum nicht so?

00:12:19.725 --> 00:12:22.665
Das sollte so sein, aber so funktionieren die meisten Projekte nicht.

00:12:22.665 --> 00:12:28.045
Wie oft bekommst du einen ausformulierten RFC in deinem Softwareprojekt?

00:12:29.285 --> 00:12:34.165
Weiß nicht. Also ich jetzt eher nicht so. Aber ich meine, die Frage ist ja,

00:12:34.185 --> 00:12:36.105
sollte das vielleicht so sein oder könnte es so sein?

00:12:36.785 --> 00:12:42.445
Genau. Die Frage ist, wie kommst du denn zu Requirements, die tatsächlich einfach umsetzbar sind?

00:12:42.705 --> 00:12:46.725
Genauso wie so ein RFC. Also das, was du sagst, ist ja völlig richtig.

00:12:46.785 --> 00:12:50.345
Ein RFC wäre genau das, was du brauchst. Ein ausformulierter RFC,

00:12:50.445 --> 00:12:52.105
der genau beschreibt, was eigentlich gemacht werden muss.

00:12:52.665 --> 00:12:55.825
Also ich jetzt als Nerd mit meinem Softwareentwickler ruhe da auf.

00:12:56.605 --> 00:13:00.925
Also ich weiß jetzt nicht, ob jetzt irgendwie Designer-Dieter oder irgendwelche

00:13:00.925 --> 00:13:03.405
Marketing-Leute damit viel anmachen können.

00:13:04.105 --> 00:13:06.825
Was du bräuchtest wäre ein RFC, der von allen gemeinsam geschrieben wird.

00:13:06.865 --> 00:13:07.825
Dann würde es funktionieren, richtig?

00:13:08.725 --> 00:13:12.885
Naja, und der halt auch die sozusagen Sprachen und, sagen wir mal,

00:13:12.945 --> 00:13:17.125
auf irgendwelchen Grundregeln basierte, die halt auch in allen diesen Kontexten Sinn ergeben.

00:13:17.125 --> 00:13:20.945
Um jetzt wieder zum Flugzeug zurückzukommen, irgendwie so Sachen wie Kosten

00:13:20.945 --> 00:13:23.945
und Bohrlochabstand ist ja dann schon sehr universell,

00:13:23.965 --> 00:13:30.325
wohingegen so Sachen wie irgendwie muss halt gut flutschen und muss in endlich

00:13:30.325 --> 00:13:33.285
viel Zeit fertig werden und muss halt am Ende wartbar sein,

00:13:33.385 --> 00:13:37.465
das sind ja Dinge, die überhaupt gar nicht auf der gleichen Realitätsebene existieren. Exakt.

00:13:38.318 --> 00:13:41.178
Exakt so ist es. Ich denke jetzt auch nochmal an die Flugzeuge.

00:13:41.338 --> 00:13:45.598
Ich hatte, wenn ich gerade in solchen Teams gearbeitet habe,

00:13:45.698 --> 00:13:50.438
wo es wirklich die Designabteilung, die Produktabteilung, die Developerabteilung,

00:13:50.458 --> 00:13:51.858
die Administratorabteilung gab,

00:13:52.578 --> 00:13:55.498
schon mit guten Leuten zusammengearbeitet, die, sage ich mal,

00:13:55.718 --> 00:14:01.018
so erduldet haben, wenn die anderen Experten in ihrem Fach gerade untereinander diskutiert hatten.

00:14:01.278 --> 00:14:05.958
So, wenn wir jetzt ganz tief mal kurz über, ganz technisch über CSS sprechen

00:14:05.958 --> 00:14:09.298
mussten im Daily, haben alle anderen brav gewartet für eine halbe Sekunde,

00:14:09.298 --> 00:14:11.718
bis es dann hieß, nehmt doch das Thema bis nach später mit.

00:14:12.658 --> 00:14:15.378
Ansonsten kenne ich eher die Grundhaltung, wie ihr das technisch löst.

00:14:15.498 --> 00:14:19.038
Es ist ja euch überlassen, da seid ihr ja die Experten, Expertinnen in dem Thema.

00:14:20.218 --> 00:14:24.858
Und wenn ich das jetzt mal so noch weiter treibe, ich habe auch generell das

00:14:24.858 --> 00:14:28.118
Gefühl, dass es halt schon oft passieren kann, dass Software getrieben wird

00:14:28.118 --> 00:14:31.718
mit dem, wie auch dieses Team entwickeln möchte.

00:14:31.838 --> 00:14:34.758
Ich weiß da nicht, ob da immer genau die, in Anführungsstrichen,

00:14:34.758 --> 00:14:37.978
richtigen Programmiersprachen, Frameworks etc. genommen werden.

00:14:38.838 --> 00:14:43.058
Ob das jetzt HTMX, Quick Front View React, keine Ahnung was,

00:14:43.138 --> 00:14:46.198
wenn halt das Team React macht, dann wird es bestimmt eine React-Webseite werden

00:14:46.198 --> 00:14:48.438
und keine Astro-Webseite.

00:14:49.578 --> 00:14:55.458
Und nochmal zum Flugzeug, ich weiß nicht, ich sehe das eher fast in der Einstellung

00:14:55.458 --> 00:14:58.898
von, irgendjemand sagt, wir brauchen ein Fortbewegungsmittel,

00:14:59.058 --> 00:15:02.878
aber ob da jetzt ein Flugzeug oder ein Zug rauskommt, ist jetzt nicht so wichtig.

00:15:02.998 --> 00:15:05.958
Also ich glaube nicht, man Man bespricht quasi bei der Software,

00:15:06.018 --> 00:15:09.398
wir brauchen ein Flugzeug, sondern einfach nur, wir müssen von A nach B und

00:15:09.398 --> 00:15:11.358
dann kann ein Flugzeug oder ein Zug rauskommen.

00:15:12.562 --> 00:15:16.042
Unter bestimmten Voraussetzungen. Natürlich sagst du, du brauchst ein Fahrzeug

00:15:16.042 --> 00:15:19.742
von A nach B, das muss aber mich in der und der Geschwindigkeit da hinbringen

00:15:19.742 --> 00:15:22.022
und ich muss übermorgen um 10 Uhr genau da sein.

00:15:22.622 --> 00:15:26.522
Und das müssen aber alle machen. An dem Fahrzeug muss dann natürlich auch der

00:15:26.522 --> 00:15:31.342
Security Engineer mitreden und natürlich auch das muss richtig Design sein und

00:15:31.342 --> 00:15:32.982
da muss ja alles passen an dem Fahrzeug.

00:15:33.642 --> 00:15:37.402
Ja, und wenn ich so drüber nachdenke, würde ich sagen, ein großer Teil der Schwierigkeit

00:15:37.402 --> 00:15:39.642
in Abgrenzung zu so einem klassischen Engineering-Ding

00:15:40.022 --> 00:15:42.522
ist ja wahrscheinlich auch, dass das komplette Grundregelwerk,

00:15:42.642 --> 00:15:46.462
also sprich die Atome und die ganzen Basisbausteine, mit denen man hantiert,

00:15:46.602 --> 00:15:51.122
ja im gleichen Moment erfunden werden, wie die Dinge, die damit gebaut werden.

00:15:51.402 --> 00:15:53.842
Also okay, man entscheidet sich jetzt vielleicht irgendwie für ein Framework,

00:15:53.922 --> 00:15:58.022
aber trotzdem irgendwie so Sachen wie, keine Ahnung, die Pattern-Library und

00:15:58.022 --> 00:16:02.362
das Ding, das das nutzt und alles, was dazugehört und die App und die Webseite,

00:16:02.422 --> 00:16:03.782
das entsteht ja mehr oder minder alles parallel,

00:16:05.182 --> 00:16:07.842
und das ist jetzt nicht irgendwie so, dass man sagen kann, das macht man schon

00:16:07.842 --> 00:16:10.222
seit den 60er Jahren oder wir nehmen das gleiche Teil wie damals.

00:16:10.522 --> 00:16:13.282
Das passiert halt auch, aber eher selten.

00:16:14.342 --> 00:16:15.282
Macht sich auch nicht einfacher.

00:16:18.302 --> 00:16:20.582
Wenn man das alles so betrachtet, ist es gar nicht so einfach,

00:16:20.782 --> 00:16:22.542
das unter einen Hut zu kriegen. Nö.

00:16:25.402 --> 00:16:28.462
Immer wenn du so ein komplexes Problem hast, und genau darüber drüber habe ich nachgedacht.

00:16:28.482 --> 00:16:31.222
Immer wenn du so ein komplexes Problem hast, dann hilft es meistens,

00:16:31.222 --> 00:16:34.982
das runterzubrechen. Und zwar so lange, bis du nichts Kleines mehr findest.

00:16:35.742 --> 00:16:39.342
Die Wadden Conquer. Jeder Softwareentwickler kennt das. Und wenn du das runterbrichst,

00:16:39.342 --> 00:16:44.162
in das kleinste Problem, dann findest du irgendwann eine Gemeinsamkeit,

00:16:44.162 --> 00:16:47.482
die alle Softwareprojekte gemeinsam haben. Alle Softwareprojekte verhalten sich so.

00:16:48.402 --> 00:16:53.242
Und das, dieser kleinste gemeinsame Nenner, den ich gefunden habe,

00:16:53.322 --> 00:16:56.942
ist, jede Software funktioniert so, dass du sagst, du hast einen Zustand,

00:16:58.422 --> 00:17:00.762
Und dann machst du irgendwas und dann hast du einen neuen Zustand.

00:17:03.245 --> 00:17:07.965
Jede Software funktioniert so. Und wenn du dir mal Gedanken machst,

00:17:08.045 --> 00:17:12.005
wie du jetzt von diesem ganz kleinen Modell zu Requirements kommen kannst,

00:17:13.445 --> 00:17:19.565
dann kommst du irgendwann ganz natürlich zu einem Werkzeug, was sich Event Modeling nennt.

00:17:21.185 --> 00:17:27.265
Event Modeling ist im Prinzip ein Workshop-Format, was du verwenden kannst,

00:17:27.505 --> 00:17:33.885
um Requirements an Software zu definieren. Und zwar so, dass alle Beteiligten mitreden können.

00:17:33.945 --> 00:17:37.785
Das ist nämlich genau das, was wir vorher gesagt haben, diese gemeinsame Sprache,

00:17:37.825 --> 00:17:39.885
die alle reden können, die alle verstehen.

00:17:40.705 --> 00:17:45.585
Darf ich da gleich mal kurz reinquetschen? Ich frage mich jetzt gerade,

00:17:45.805 --> 00:17:51.725
inwiefern hat das jetzt was mit Domain Driven Development Design zu tun?

00:17:51.725 --> 00:17:54.605
Da geht es ja irgendwie auch so darum, dass wir eine gemeinsame Sprache finden

00:17:54.605 --> 00:17:56.605
wollen, nicht nur unter Developern, das auch,

00:17:56.845 --> 00:18:03.065
aber auch, damit wir einfach mal zum Beispiel, wenn wir einen Fachbegriff dieser

00:18:03.065 --> 00:18:08.005
Software nennen, dass dann auch Designprodukt und Developer immer von dem Gleichen reden.

00:18:08.545 --> 00:18:12.625
Ist das irgendwie verwandt oder ganz was anderes? Das ist die gleiche Ecke.

00:18:12.705 --> 00:18:16.645
Also Domain-Driven Design, da geht es ja im Prinzip genau darum,

00:18:16.745 --> 00:18:20.945
dass du es irgendwie schaffst, Fachseite, Business Requirements,

00:18:20.945 --> 00:18:22.865
alles irgendwie unter einen Hut zu kriegen.

00:18:22.985 --> 00:18:27.625
Das ist genau die gleiche Baustelle. Das Problem bei Domain-Driven Design ist,

00:18:27.825 --> 00:18:29.505
dass es kaum einer versteht.

00:18:30.045 --> 00:18:33.705
Es ist relativ komplex, da reinzukommen und wenn du jemanden fragst,

00:18:33.725 --> 00:18:37.385
was ist ein Domain-Driven Design, dann kriegst du normalerweise von jedem eine

00:18:37.385 --> 00:18:38.165
unterschiedliche Antwort.

00:18:38.425 --> 00:18:43.525
Da fallen dann so Begriffe wie bauende Kontext und unterschiedlichste Sachen,

00:18:43.665 --> 00:18:46.405
die die meisten eigentlich gar nicht so ganz genau definieren können.

00:18:47.005 --> 00:18:50.665
Aber du bist schon auf der richtigen Spur. Das ist genau die gleiche Baustelle.

00:18:50.705 --> 00:18:54.645
Du versuchst immer irgendwie die Requirements und das, was deine Software tun

00:18:54.645 --> 00:18:58.325
soll, so zu formulieren und so abzubilden, dass es halt jeder irgendwie versteht.

00:19:00.565 --> 00:19:08.905
Dieses Event-Modeling, das ist im Prinzip ähnlich wie das, was wir in der Vorbereitung

00:19:08.905 --> 00:19:10.525
kurz besprochen haben, das Event-Storming.

00:19:10.545 --> 00:19:14.585
Event-Storming kommt ja auch aus dem Domain-Driven-Design-Bereich und da geht

00:19:14.585 --> 00:19:21.985
es im Prinzip darum, dass du Events in deinem System sammelst und strukturiert aufbereitest.

00:19:22.685 --> 00:19:27.045
Und Event-Modeling ist was ähnliches wie Event-Storming, nur ist es ein bisschen

00:19:27.045 --> 00:19:30.085
näher an dem eigentlichen System.

00:19:32.045 --> 00:19:36.805
Und ich habe die Erfahrung gemacht, mit so Event-Modeling-Workshops ist es unglaublich

00:19:36.805 --> 00:19:41.165
einfach, Requirements an Software zu definieren und zwar in kürzester Zeit.

00:19:41.745 --> 00:19:45.605
Beispiel, ich habe kürzlich einen Workshop gemacht mit einem Startup und wir

00:19:45.605 --> 00:19:48.965
haben innerhalb von einem Tag das komplette System von Anfang bis Ende geplant,

00:19:48.965 --> 00:19:52.465
inklusive aller Requirements, sodass die im Prinzip einfach anfangen konnten,

00:19:52.585 --> 00:19:54.025
die Software umzusetzen.

00:19:54.905 --> 00:19:59.085
Also du kriegst wirklich innerhalb von einem Tag die richtigen Requirements,

00:19:59.205 --> 00:20:00.965
sodass du es umsetzen kannst.

00:20:02.534 --> 00:20:06.634
Das glaube ich jetzt tatsächlich, weil mir das aus der anderen Sicht immer eher

00:20:06.634 --> 00:20:11.534
so geht, wenn ich, ich meine, ich bin ja aus Gründen auch Software-Ingenieur geworden.

00:20:11.654 --> 00:20:16.494
Ich mag Kontrolle über Dinge haben und ich mag die definiert haben und ich mag

00:20:16.494 --> 00:20:20.754
die hundertprozentig korrekt machen. Ich funktioniere schon auch so agiler und

00:20:20.754 --> 00:20:22.214
sowas, aber das ist so mein Grund.

00:20:23.214 --> 00:20:27.374
Und vor allem, ich bin so ein Rätsellöser. Ich habe den größten Spaß an Rätseln.

00:20:27.374 --> 00:20:30.354
Das heißt, wenn ich immer von Problemen spreche und wir müssen dieses Problem

00:20:30.354 --> 00:20:32.954
lösen, meine ich das immer sehr, sehr positiv.

00:20:33.174 --> 00:20:35.894
Und andere Leute, du mit deinem Problem schon wieder. wieder.

00:20:36.614 --> 00:20:41.694
Und was mir immer und immer und immer egal, wo ich arbeite, immer wieder auffällt

00:20:41.694 --> 00:20:45.874
ist, diese Probleme, von denen ich dann spreche, die lassen sich tatsächlich

00:20:45.874 --> 00:20:48.254
in, egal ob jetzt asynchron oder synchron,

00:20:48.474 --> 00:20:52.214
aber diese Sachen lassen sich sehr oft sehr schnell klären und fest definieren

00:20:52.214 --> 00:20:55.094
und festlegen und dann kann man anfangen zu arbeiten.

00:20:55.254 --> 00:20:58.294
Aber ich habe oft das Gefühl, das ist so eine Grundangst, dass man das jetzt

00:20:58.294 --> 00:21:01.754
ewig diskutieren muss und die Meinungen gehen nur im Pingpong hintereinander

00:21:01.754 --> 00:21:06.654
und dass es ewig lang dauern würde, dass man oft mit der Herangehensweise eher

00:21:06.654 --> 00:21:09.654
herangeht, zu sagen, wir fangen mal an und schauen mal, was es wird.

00:21:10.134 --> 00:21:14.634
Und das habe ich jetzt nicht mit Daten bewiesen, aber rein von meinem Gefühl

00:21:14.634 --> 00:21:17.694
dauert das halt dann im Endeffekt länger und es kommt halt nicht das voraus,

00:21:17.714 --> 00:21:21.254
was man eigentlich vielleicht hätte haben wollen, wenn man das eigentlich weiß,

00:21:21.334 --> 00:21:22.494
was man eigentlich wollte.

00:21:24.554 --> 00:21:28.154
Man kann ja nur wissen sozusagen, was man weiß, was man will,

00:21:28.254 --> 00:21:30.094
wenn man das tatsächlich schon wissen kann.

00:21:30.634 --> 00:21:34.674
Also ich meine, es gibt ja da auch sozusagen den explorativen Ansatz bezüglich,

00:21:34.674 --> 00:21:37.954
wir bauen mal irgendwas so in der Richtung und gucken mal, wie es wird und das

00:21:37.954 --> 00:21:41.514
ist ja auch die Idee hinter dem Agilen jedenfalls zu einem gewissen Teil,

00:21:41.674 --> 00:21:45.034
dass man halt irgendwie nicht immer von Anfang bis Ende sehen kann,

00:21:45.694 --> 00:21:49.134
das soll am Ende definitiv rauskommen, sondern man sich stattdessen einen Mechanismus

00:21:49.134 --> 00:21:51.954
überlegt, wie man sozusagen managen kann, dass man es nicht weiß.

00:21:52.694 --> 00:21:58.154
Ja, das stimmt, aber du hast schon bei jeder agilen, bei jedem agilen Step Cycle,

00:21:58.174 --> 00:22:02.054
ist auch egal, Sprint, weißt du zumindest für diesen Bereich schon,

00:22:02.194 --> 00:22:06.194
was der feste Outcome von dem aktuellen Zyklus sein soll.

00:22:07.514 --> 00:22:09.934
Das ist ja richtig. Das Problem ist ja natürlich immer dann,

00:22:10.014 --> 00:22:15.494
die Dinger so zu umzusetzen oder halt eben auch zu planen, dass man sich damit

00:22:15.494 --> 00:22:18.174
nicht irgendwie perspektivischen Schwierigkeiten bringt,

00:22:18.294 --> 00:22:20.794
was ja mehr oder minder ein unlösbares Problem ist, weil du ja definitionsgemäß

00:22:20.794 --> 00:22:23.214
nicht weißt, was irgendwie in drei Monaten sein wird.

00:22:23.794 --> 00:22:27.834
Das ist ja so diese agile Sicht auf die Dinge, was ja irgendwie einerseits ein

00:22:27.834 --> 00:22:30.454
Problem löst, andererseits halt eben auch auch potenziell weitere erschafft,

00:22:30.514 --> 00:22:34.514
weil man sich irgendwie in eine Ecke hineindrängt durch gewisse Entscheidungen,

00:22:34.554 --> 00:22:37.034
wo man dann irgendwie sagt, auf lange Sicht wäre das irgendwie besser gewesen.

00:22:37.254 --> 00:22:40.794
Aber das sind ja auch so Dinge, die man abwägen muss. Deswegen ist das wahrscheinlich

00:22:40.794 --> 00:22:45.614
alles so ein bisschen schwierig, je nachdem, wie gut man halt irgendwie wirklich

00:22:45.614 --> 00:22:49.674
sagen kann oder je nachdem, wie sehr man weiß, was man da tatsächlich fabriziert

00:22:49.674 --> 00:22:51.574
und wo man am Ende ankommen wird.

00:22:53.109 --> 00:22:56.609
Wobei du meiner Erfahrung nach meistens, wenn du agil arbeitest,

00:22:56.609 --> 00:23:01.009
schon weißt, was du bauen willst und wo du eigentlich hin willst.

00:23:01.349 --> 00:23:04.769
Du kannst nur nicht so ganz genau sagen, bis wann es schlussendlich fertig ist.

00:23:05.349 --> 00:23:06.969
Also die große Stellschraube, die du

00:23:06.969 --> 00:23:11.209
ja, wenn du mit Scrum beispielsweise arbeitest, ist, du drehst am Scope.

00:23:11.429 --> 00:23:15.129
Sondern du sagst, du hast immer die Möglichkeit, das Backlog zu priorisieren

00:23:15.129 --> 00:23:19.329
und baust immer quasi die wichtigsten Features, die jetzt gerade wichtig sind.

00:23:19.469 --> 00:23:22.169
Du kannst aber nicht so ganz genau sagen, wann du jetzt schlussendlich fertig bist.

00:23:23.109 --> 00:23:26.409
Das ist eigentlich die große Stellschraube, die du mit agiler Arbeit hast.

00:23:26.629 --> 00:23:30.109
Meistens weißt du schon, wo du hin willst. Also dass du jetzt komplett explorativ

00:23:30.109 --> 00:23:34.949
arbeitest, das hast du vielleicht mal für so ein POC oder wenn du Dinge ausprobierst,

00:23:34.969 --> 00:23:39.269
aber wenn du jetzt mal so ein größeres Projekt anschaust, ungefähr wo du hin

00:23:39.269 --> 00:23:40.269
willst, wissen die meisten.

00:23:41.089 --> 00:23:44.069
Die meisten wissen nämlich so ganz genau, was man dafür tun muss. Ja.

00:23:45.369 --> 00:23:48.629
Und dass man nicht weiß, was man da tun muss und welche Schritte man genau machen

00:23:48.629 --> 00:23:51.809
möchte, dass man nur sozusagen am Horizont sieht, aha, zu dem Turm wollen wir

00:23:51.809 --> 00:23:55.249
hinlaufen. das ist dann trotzdem durch das Event-Modeling abbildbar.

00:23:56.409 --> 00:24:00.589
Wir können uns ja mal anschauen, wie so ein typischer Event-Modeling-Workshop

00:24:00.589 --> 00:24:04.209
ausschaut und wie das abläuft und dann können wir mal überlegen,

00:24:04.209 --> 00:24:06.849
ob das dann für alle Projekte funktioniert oder nicht.

00:24:07.549 --> 00:24:11.169
Das Erste, was du nämlich machst, ist, du sammelst erstmal alle wichtigen Leute im Raum.

00:24:11.769 --> 00:24:14.909
Alle dürfen kommen. Ein Event-Modeling-Workshop, den kannst du mit drei Leuten

00:24:14.909 --> 00:24:17.849
machen, den kannst du aber auch mit 25 Leuten machen und wenn du willst, auch mit 50.

00:24:18.329 --> 00:24:21.769
Das funktioniert im Prinzip mit beliebig vielen Leuten. Auch wenn ich 100 habe?

00:24:23.469 --> 00:24:26.389
100 habe ich jetzt noch nicht gemacht. Ich weiß auch nicht, ob es schon jemand

00:24:26.389 --> 00:24:28.849
gemacht hat, aber wenn du einen groß genugen Raum hast, dann wird es auch mit

00:24:28.849 --> 00:24:30.169
100 funktionieren. Okay.

00:24:32.989 --> 00:24:38.609
Wichtig dabei ist, je mehr verschiedene Fachbereiche und Business Units mit

00:24:38.609 --> 00:24:41.049
dabei sind, desto besser. Also jeder darf da mitmachen.

00:24:41.289 --> 00:24:44.789
Und ich bin ein großer Verfechter davon. Die zwei Personen, die mitmachen müssen

00:24:44.789 --> 00:24:48.829
eigentlich, zumindest beim initialen Workshop, ist der CTO und ist der CEO.

00:24:50.089 --> 00:24:53.989
Die müssen da mitmachen. Das Wissen von diesen Personen braucht man.

00:24:56.149 --> 00:25:00.169
Also du sammelst Security, du sammelst UX, UX ganz, ganz wichtig.

00:25:00.509 --> 00:25:03.929
Du sammelst Entwickler. Alle machen mit. Datenbank-Admins.

00:25:04.669 --> 00:25:09.249
Was hätten denn die C-Levels für ein besonderes Wissen, was sie mitbringen sollen?

00:25:09.529 --> 00:25:10.749
Die haben die Vision. Die wissen,

00:25:10.829 --> 00:25:13.649
wo das Produkt sein soll. Die haben die Vision. Das ist das Wichtigste.

00:25:14.189 --> 00:25:16.849
Und die haben das höchste Abstraktionsniveau? Wenn es alle verstehen müssen,

00:25:16.949 --> 00:25:17.749
müssen die es ja auch verstehen.

00:25:20.116 --> 00:25:26.056
Die können da mitdiskutieren und der CTO unterhält sich mit dem Datenmarkt-Admin

00:25:26.056 --> 00:25:28.296
und beide verstehen sich. Ist das nicht fantastisch?

00:25:32.296 --> 00:25:35.056
Also das Erste, was du machst, ist, du sammelst diese ganzen Personen in einem

00:25:35.056 --> 00:25:38.616
Raum und dann überlegst du dir erstmal in der ganzen Gruppe,

00:25:38.676 --> 00:25:44.556
was sind denn eigentlich so die Ereignisse, die bei uns in der Software passieren.

00:25:45.456 --> 00:25:49.256
Technisch heißt das Ganze Events, aber ich verzichte meistens sogar auf diese

00:25:49.256 --> 00:25:53.036
ganzen technischen Begriffe. Was kann in unserer Software passieren?

00:25:54.756 --> 00:25:58.696
Nimm dir beispielsweise so ein ganz einfaches System. Stell dir vor,

00:25:58.736 --> 00:26:00.836
du willst Kinokarten kaufen online.

00:26:01.916 --> 00:26:06.436
Du hast ein System, um Kinokarten zu kaufen. Was sind die Ereignisse,

00:26:06.536 --> 00:26:08.256
die bei uns im System passieren können?

00:26:08.676 --> 00:26:11.416
Völlig unabhängig von der Technik. Technik spielt überhaupt keine Rolle.

00:26:11.496 --> 00:26:14.836
Was kann passieren? Zum Beispiel wäre eine Sache, die passieren kann,

00:26:14.916 --> 00:26:17.016
ist, du hast deine Sitze reserviert.

00:26:18.136 --> 00:26:23.696
Das wäre dann sowas wie Seats Reserved beispielsweise, englisch formuliert.

00:26:23.776 --> 00:26:27.016
Also du formulierst diese Ereignisse immer in der Vergangenheitsform.

00:26:27.576 --> 00:26:30.136
Was ist in unserem System passiert? passiert.

00:26:31.176 --> 00:26:35.456
Sitze wurden reserviert, Karten wurden gekauft, Popcorn wurde gekauft,

00:26:35.676 --> 00:26:38.896
Bezahlvorgang wurde ausgelöst, Bezahlvorgang wurde abgeschlossen.

00:26:39.556 --> 00:26:42.556
Du sammelst alle Ereignisse, alles was passiert.

00:26:45.224 --> 00:26:48.744
Und das dauert typischerweise so was, 30 Minuten, 60 Minuten,

00:26:48.844 --> 00:26:53.184
so was. Im letzten Workshop haben wir eine gute Stunde gebraucht.

00:26:54.344 --> 00:27:01.384
Und dann sind wir so bei 104 Ereignissen rausgekommen. Für ein mittelgroßes System.

00:27:02.844 --> 00:27:05.064
Und das sind die Sachen, die in deinem System passieren können.

00:27:05.184 --> 00:27:10.384
Und da hast du schon auf einen Blick auf einmal alles, was dein Software-System

00:27:10.384 --> 00:27:11.144
eigentlich machen muss.

00:27:12.544 --> 00:27:15.464
Das hast du heute eigentlich nicht. Wenn du heute eine User-Story aufmachst,

00:27:15.484 --> 00:27:18.904
dann hast du, kein Entwickler hat dieses Big Picture, kein Entwickler sieht

00:27:18.904 --> 00:27:23.064
auf einen Blick, was sollen unsere Systeme eigentlich machen, komplett.

00:27:24.144 --> 00:27:28.584
Und da hast du jetzt, wenn du dir vorstellst, du machst das vor Ort beispielsweise,

00:27:28.944 --> 00:27:33.504
dann hast du 100, 200 Post-its an der Wand, wo einfach draufsteht, was unser System macht.

00:27:35.464 --> 00:27:40.804
Wo sind da die Grenzen von System? Sind die Grenzen da jetzt tatsächlich so

00:27:40.804 --> 00:27:47.984
in der User Experience, also das, was ich so als Nutzerin mit dem Ding machen kann?

00:27:48.124 --> 00:27:52.784
Oder gehört da auch so Krempel irgendwie zu wie so rein technischer Kram,

00:27:52.784 --> 00:27:56.344
Deployment, endliche Kompilierzeiten?

00:27:56.344 --> 00:27:59.584
Das sind ja auch, sagen wir mal, Anforderungen im allerweitesten Sinne,

00:27:59.624 --> 00:28:02.084
dass ja auch die unterschiedlichen Gewerke irgendwie, dass ich zu den Admins

00:28:02.084 --> 00:28:05.664
das rüberwerfen kann und die sagen hier, DevOps geht klar, kann ich jetzt deployen.

00:28:06.664 --> 00:28:09.464
Also sowas betrachtest du im ersten Moment erstmal nicht.

00:28:09.544 --> 00:28:15.164
Also sowas wie Bildzeiten oder sowas betrachtest du nicht. Wir betrachten wirklich das System.

00:28:15.324 --> 00:28:18.584
Was soll unser System können oder beziehungsweise was soll in unserem System

00:28:18.584 --> 00:28:22.804
passiert sein? Also das System wirklich so als Benutzeroberfläche,

00:28:22.864 --> 00:28:26.364
auch wenn es jetzt nicht in Pixel untergebrochen wird, aber was kann jemand,

00:28:26.544 --> 00:28:29.324
der das nicht baut, sondern benutzt, damit anstellen?

00:28:30.064 --> 00:28:33.264
Ganz genau. Das muss aber nicht unbedingt ein System sein, was jetzt wirklich

00:28:33.264 --> 00:28:36.464
eine Benutzeroberfläche hat. Das geht auch genauso gut für irgendwelche Batch-Prozesse.

00:28:36.604 --> 00:28:39.544
Es muss aber ein System sein, das was tut.

00:28:39.864 --> 00:28:42.964
Es hat ja eine Benutzeroberfläche sozusagen implizit, auch wenn ich nichts anklicken

00:28:42.964 --> 00:28:44.564
kann, aber irgendwer macht damit irgendwas.

00:28:44.744 --> 00:28:48.244
Irgendwer ist Bediener von dem Teil. Ganz genau. Okay.

00:28:50.229 --> 00:28:55.549
So, jetzt hast du diese ganzen Ereignisse irgendwie an der Wand und das nächste,

00:28:55.609 --> 00:28:58.669
was du machst, ist, du clusterst diese Ereignisse.

00:28:59.489 --> 00:29:03.569
Du brauchst erstmal Cluster mit dem schlussendlichen Ziel, dass du diese ganzen

00:29:03.569 --> 00:29:06.249
Ereignisse sortierst in eine Reihenfolge.

00:29:06.329 --> 00:29:12.169
Du ordnest diese Ereignisse quasi eins nach dem anderen an, was passiert nacheinander

00:29:12.169 --> 00:29:16.069
in unserem System, sodass du am Ende im Prinzip eine Zeitlinie hast.

00:29:16.789 --> 00:29:21.769
Doofe Frage. Was passiert, wenn die Reihenfolge unterschiedlich sein kann?

00:29:21.949 --> 00:29:27.069
Ich kann ja erst das Popcorn kaufen und dann die Cola.

00:29:28.229 --> 00:29:33.389
Ändert das was am Prozess? Nee, nee, nur wenn man jetzt, also falls jetzt man

00:29:33.389 --> 00:29:36.289
die ganze Gruppe fragt, jetzt sortiert das mal der Reihenfolge nach.

00:29:37.009 --> 00:29:40.309
Und wenn jetzt die zwei, drei Schritte komplett egal sind, in welcher Reihenfolge

00:29:40.309 --> 00:29:43.909
die stattfinden, ist das jetzt wichtig oder spielt das jetzt keine so große

00:29:43.909 --> 00:29:46.149
Rolle? Im Prinzip spielt das überhaupt keine Rolle.

00:29:46.249 --> 00:29:49.409
Also bei der Sortierung, da hast du schon den ersten großen Benefit,

00:29:49.429 --> 00:29:53.069
weil die Leute nämlich anfangen zu diskutieren und die diskutieren,

00:29:53.129 --> 00:29:54.509
muss das jetzt als erstes passieren?

00:29:54.629 --> 00:29:58.209
Muss das jetzt als erstes passieren? Und plötzlich diskutiert der Security-Mensch

00:29:58.209 --> 00:30:02.569
mit dem Datenbank-Admin und jeder diskutiert miteinander und man versucht quasi

00:30:02.569 --> 00:30:04.629
rauszufinden, was ist denn jetzt eigentlich die richtige Reihenfolge?

00:30:04.669 --> 00:30:05.929
Was soll jetzt eigentlich unser System machen?

00:30:08.189 --> 00:30:13.469
Und du versuchst dann im Prinzip dieses, alle Ereignisse in eine Zeitleiste zu bringen.

00:30:16.300 --> 00:30:22.260
Und was du dann hast, ist, du hast plötzlich quasi dein System in einer Zeitleiste

00:30:22.260 --> 00:30:24.920
und jeder kann es lesen von links nach rechts.

00:30:25.180 --> 00:30:29.840
Und zwar so, dass es jeder versteht, denn jeder kann Ereignisse lesen.

00:30:30.600 --> 00:30:34.160
Du hast keine technischen Begriffe, da ist einfach nur aufgelistet,

00:30:34.180 --> 00:30:35.420
was macht denn eigentlich das System?

00:30:36.360 --> 00:30:39.740
Also ein Ablaufdiagramm einer Was-passiert-dann-Maschine. Ganz genau.

00:30:40.040 --> 00:30:44.600
Im Prinzip, was du da im Prinzip hast, das sind die Statusübergänge,

00:30:44.700 --> 00:30:47.240
die dein System abbildet. State Transitions.

00:30:49.780 --> 00:30:54.860
Ich muss jetzt auch nochmal bei System einhaken. Und zwar jetzt mal kurz von

00:30:54.860 --> 00:30:59.200
der Kinogeschichte-Wechsel wieder auf eine Software.

00:30:59.420 --> 00:31:04.820
Rede ich hier gerade von dem ganzen System und im Endeffekt werde ich wahrscheinlich

00:31:04.820 --> 00:31:06.640
so ein Zehntel davon bearbeiten?

00:31:07.520 --> 00:31:12.460
Oder kann ich das wirklich auch machen für meine kleine User Story,

00:31:12.600 --> 00:31:16.640
für mein eines Feature von dieser Webseite mit mit 500 Features.

00:31:17.440 --> 00:31:20.680
Das, was du da machst, ist erstmal, du modellierst das ganze System.

00:31:21.260 --> 00:31:24.240
Also die komplette Software. Das machst du nicht für deine User-Story,

00:31:24.340 --> 00:31:26.720
sondern aus diesen Ereignissen, das werden wir nachher sehen,

00:31:26.780 --> 00:31:28.360
da entsteht im Prinzip deine User-Story.

00:31:29.480 --> 00:31:32.800
Denn ich glaube, auch im Kleinen, bei so einer kleinen User-Story wäre sowas

00:31:32.800 --> 00:31:36.520
teilweise auch schon hilfreich, weil ich halt dann noch immer den goldenen Pfad

00:31:36.520 --> 00:31:39.440
so ein bisschen, wenn überhaupt, in so einer User-Story vorfinde.

00:31:40.280 --> 00:31:44.740
Und ich meine, ich glaube, das, wo ich immer wieder am meisten,

00:31:46.040 --> 00:31:49.880
mit reinlaufe oder quasi dann auch meine Expertise damit gut einbringen kann,

00:31:49.980 --> 00:31:53.700
sondern eben so sogenannte Edge Cases abzufangen, wobei viele davon auch gar

00:31:53.700 --> 00:31:58.040
keine Edge Cases sind, sondern eben auch einfach so Dinge, an die man sonst

00:31:58.040 --> 00:32:00.760
nicht dran denkt, während man den goldenen Pfad aufgezeichnet hat.

00:32:02.840 --> 00:32:06.640
Also ich glaube, ich mag die Idee auch generell wirklich so im kleinen Ticket-Bereich

00:32:06.640 --> 00:32:11.020
auch so einfach das im Hinterkopf zu behalten, wie was wird denn alles möglicherweise passieren können.

00:32:12.987 --> 00:32:16.447
Das auf jeden Fall. Und du hast auch immer, wenn du deine Story implementierst

00:32:16.447 --> 00:32:21.387
später, hast du immer dieses große Bild im Kopf, wo auf diesem Zeitstrahl befindest

00:32:21.387 --> 00:32:24.287
du dich eigentlich gerade. Was baust du gerade und wo sind wir da gerade?

00:32:24.727 --> 00:32:28.127
Also jeder hat im Prinzip immer diesen Zeitstrahl im Kopf und hat diesen ganzen

00:32:28.127 --> 00:32:30.727
Ablauf irgendwie im Hinterkopf und weiß genau, was passiert jetzt eigentlich

00:32:30.727 --> 00:32:32.707
nacheinander im System.

00:32:34.187 --> 00:32:36.667
Und auch das hast du heute in einem typischen Softwareprojekt.

00:32:37.587 --> 00:32:41.007
Das gibt es einfach nicht. Niemand macht sowas, obwohl es total einfach ist.

00:32:43.967 --> 00:32:46.307
Ich bin ja immer noch so ein bisschen bei der Skalierungsfrage,

00:32:46.407 --> 00:32:48.507
wo ich ja vorhin schon so halbtrollig gefragt habe, was ist,

00:32:48.567 --> 00:32:49.747
wenn ich 100 Leute habe oder so.

00:32:50.347 --> 00:32:53.947
Also wenn ich jetzt mal aus meinem Alltag mal ein Beispiel heranziehen kann.

00:32:54.027 --> 00:32:59.507
Ich habe es ja mehr so mit den kaputten, dysfunktionalen Molochs zu tun,

00:32:59.607 --> 00:33:02.487
wo dann halt die Feuerwehr mal dringend was austreten muss.

00:33:02.487 --> 00:33:06.607
Aber da habe ich zum Beispiel einen so einen Verein, das ist halt eine echt

00:33:06.607 --> 00:33:10.847
große Firma, so irgendwie ihr eigenes Hochhaus ist das größte in der Stadt und

00:33:10.847 --> 00:33:14.547
so Zeug und da gibt es dann so das gallische Dorf, das ganz unten im Keller

00:33:14.547 --> 00:33:16.847
sitzt, das sind dann so die zehn Leute,

00:33:16.987 --> 00:33:21.707
die eine Software entwickeln, die nennt sich Arbeitsprozess und die heißt halt

00:33:21.707 --> 00:33:25.227
bei denen wirklich so, weil das einfach die Software ist, durch die alle Arbeitsprozesse

00:33:25.227 --> 00:33:27.107
in dem gesamten Hochhaus durchgetunnelt werden.

00:33:27.107 --> 00:33:30.047
Also wirklich der Single Point of Failure.

00:33:57.107 --> 00:34:02.007
Anfangen, dieses Teil-System zu modellieren. Also du musst nicht unbedingt das

00:34:02.007 --> 00:34:04.427
komplette System modellieren, du kannst auch mit einem Teil anfangen.

00:34:04.587 --> 00:34:06.087
Sagen wir, es ist ein Microservice.

00:34:07.047 --> 00:34:10.667
Nimm ein Microservice aus dem System heraus und modelliere den ersten Microservice.

00:34:13.427 --> 00:34:16.747
Oder du fängst an und modellierst das ganze System, aber nur High-Level.

00:34:17.387 --> 00:34:20.747
Dass du quasi nur eine grobe Zeitlinie hast, wie das System funktioniert,

00:34:20.787 --> 00:34:24.107
und fängst dann an, in kleineren Systemen zu arbeiten und modellierst beispielsweise,

00:34:25.387 --> 00:34:28.087
wie hast du es genannt? Äh, Arbeitsprozess.

00:34:29.907 --> 00:34:32.767
Arbeitsprozess, genau. Okay, also dann würde ich sozusagen einfach sagen,

00:34:32.907 --> 00:34:34.507
ich schneide hier und da jetzt ab.

00:34:34.587 --> 00:34:37.607
Das sind dann halt irgendwelche externen Teilsysteme, da kommen dann Daten rein

00:34:37.607 --> 00:34:40.947
oder gehen Daten raus, aber die betreffen mich jetzt unmittelbar nicht in meinem

00:34:40.947 --> 00:34:41.747
Ausschnitt der Realität.

00:34:42.867 --> 00:34:47.007
Was du machen würdest, ist, du würdest im Prinzip jedes dieser Teilsysteme ausmodellieren

00:34:47.007 --> 00:34:53.167
und dann aber die Schnittstellen zwischen diesen Systemen explizit nochmal hinzumodellieren.

00:34:53.167 --> 00:34:57.387
Dass ganz klar ist, welche Systeme reden mit welchen Systemen über welche Ereignisse beispielsweise.

00:35:03.751 --> 00:35:09.991
Wenn du jetzt diese Ereignisse in deinem Zeitstrahl hast, ist das Nächste,

00:35:10.011 --> 00:35:15.611
was passiert ist, ein Freiwilliger erzählt im Prinzip die Geschichte des Systems.

00:35:15.771 --> 00:35:19.511
Also wir wählen einen Freiwilligen aus und der erzählt im Prinzip von links

00:35:19.511 --> 00:35:21.331
nach rechts, was ist denn jetzt eigentlich die Geschichte des Systems.

00:35:22.131 --> 00:35:26.451
Liest im Prinzip die Ereignisse vor und jeder hört zu und man überlegt,

00:35:26.451 --> 00:35:29.631
ist das, was der da gerade vorliest, stimmig? Macht das Sinn?

00:35:30.591 --> 00:35:36.411
Auch das finde ich, also ich hatte das Wort Event Modeling, ich glaube,

00:35:36.471 --> 00:35:39.151
einmal nur vorher gehört und ich wusste nicht, dass es so etwas Offizielles gibt.

00:35:39.491 --> 00:35:43.691
Aber auch das ist was, was ich eigentlich gerne auch in Teams mache,

00:35:43.831 --> 00:35:47.331
wenn es einfach nur um ein kleines Feature geht, ohne große Systeme.

00:35:47.651 --> 00:35:52.431
Es ist aber auch nicht ganz trivial, weil das Team muss sich ein bisschen gut

00:35:52.431 --> 00:35:57.331
kennen, gut verstehen, damit sich jetzt auch niemand an den Pranger gestellt fühlt.

00:35:57.331 --> 00:36:00.031
Weil ich habe selber die Erfahrung gemacht, dass ich einmal,

00:36:00.131 --> 00:36:04.431
ich war gewohnt so zu arbeiten, ein bisschen neueres Team und ich habe so plump

00:36:04.431 --> 00:36:08.051
dahergesagt, kannst du noch mal alles, kannst du mal sagen, was genau jetzt

00:36:08.051 --> 00:36:09.251
der Reihenfolge nach passiert?

00:36:09.771 --> 00:36:11.951
Und dann war so, was, ich habe nicht aufgepasst, worum geht es?

00:36:12.571 --> 00:36:15.431
Beziehungsweise die Person hat schon aufgepasst, aber hat sich dann so ein bisschen

00:36:15.431 --> 00:36:18.071
gefühlt, wie wahrscheinlich in der Schule vorne beim Abfragen.

00:36:20.091 --> 00:36:22.991
Und ich habe da auch nicht erklärt, worauf ich eigentlich hinaus wollte,

00:36:23.111 --> 00:36:25.351
weil eine Person hat es dann wiedergegeben und ich habe zugehört,

00:36:25.371 --> 00:36:28.091
so ein bisschen mitgeschrieben und dann die nächste Person gesagt,

00:36:28.091 --> 00:36:31.311
sagt, kannst du es mir jetzt auch nochmal erzählen? Was passiert denn bei deiner Version?

00:36:31.511 --> 00:36:34.031
Also man sollte so ein bisschen die Leute darauf vorbereiten,

00:36:34.091 --> 00:36:35.291
warum man das gerade tut.

00:36:36.091 --> 00:36:40.911
Zumindest mit ein, zwei Sätzen doch einleiten. Denn ich finde es erstaunlich,

00:36:40.911 --> 00:36:44.771
auch bei kleinen Features, welche unterschiedlichen Geschichten da schon mit

00:36:44.771 --> 00:36:46.271
menschlicher Sprache rauskommen.

00:36:46.531 --> 00:36:50.431
Und bei wirklich so Features, wo, wenn du jetzt einfach nur die Frage stellst,

00:36:50.531 --> 00:36:54.371
ist allen klar, was zu tun gibt, dann gibt es ein allgemeines Nicken.

00:36:54.771 --> 00:36:58.611
Aber dann fragst du du vier Leute, was kommt jetzt da raus gepostelt und vier

00:36:58.611 --> 00:37:02.451
Leute werden dir eine ungefähre andere Antwort geben. Ja.

00:37:04.871 --> 00:37:09.751
Was wirklich, wirklich toll ist, wenn ein Freiwilliger die Geschichte vorliest

00:37:09.751 --> 00:37:15.891
und der Beste dafür ist entweder der CEO oder der CTO, du stellst sofort fest,

00:37:15.991 --> 00:37:17.451
wenn die Geschichte nicht stimmig ist.

00:37:18.591 --> 00:37:22.771
Du liest vor, okay, Kinokarten reserviert und dann setzt du dich hin.

00:37:23.191 --> 00:37:25.491
Ja, da fehlt was dazwischen, das kann nicht sein, da fehlt was.

00:37:26.831 --> 00:37:31.151
Und das passiert im Prinzip während du quasi die Geschichte erzählst ergänzt

00:37:31.151 --> 00:37:33.251
du einfach weitere Ereignisse alles was fehlt,

00:37:34.791 --> 00:37:40.051
und das wird jede Menge sein jede Menge an die niemand gedacht hat und plötzlich

00:37:40.051 --> 00:37:43.671
wird die Geschichte immer vollständiger und vollständiger und dann hast du irgendwann

00:37:43.671 --> 00:37:48.011
die komplette Geschichte von deinem System als Zeitstrahl an Bord stehen,

00:37:50.851 --> 00:37:52.371
und jeder versteht es.

00:37:55.740 --> 00:38:00.840
Gut. Und dann? Das Nächste, was du machst, ist, und da wird es dann richtig

00:38:00.840 --> 00:38:02.940
spannend, jetzt definierst du die Screens.

00:38:04.440 --> 00:38:07.920
Also jetzt haben wir unsere Ereignisse an Bord stehen und jetzt definierst du

00:38:07.920 --> 00:38:11.460
die Screens. Wie sehen denn die Screens der Applikation aus, die wir da bauen?

00:38:12.960 --> 00:38:16.160
Für jedes Ereignis brauchst du irgendeine Aktion, die ein User anklicken kann.

00:38:16.260 --> 00:38:17.200
Du brauchst ein Screen dafür.

00:38:17.420 --> 00:38:22.380
Ein Button oder es ist ein Batch-Prozess, der losläuft. Irgendein Screen brauchst du.

00:38:22.980 --> 00:38:25.180
Irgendwas, wo der User draufklicken kann. Und die machst du dann ins Bord ran.

00:38:26.220 --> 00:38:29.900
Und idealerweise ist das bereits vorbereitet. Das kannst du zum Beispiel die

00:38:29.900 --> 00:38:31.540
UX als Vorbereitung machen.

00:38:31.600 --> 00:38:35.120
Meistens hast du irgendwelche Figma-Screens beispielsweise, die du dann schon

00:38:35.120 --> 00:38:38.840
mitbringen kannst, die schon vorbereitet sind. Und an den Screens kannst du

00:38:38.840 --> 00:38:39.880
dann rumskribbeln im Workshop.

00:38:40.160 --> 00:38:45.420
Oder wenn du es digital machst, machen wir das typischerweise auf einem Miro-Board.

00:38:45.500 --> 00:38:47.300
Miro ist ein ganz hervorragendes Tool für diesen Workshop.

00:38:48.180 --> 00:38:50.440
Dann machst du diese Screens einfach direkt auf dem Miro-Board.

00:38:52.800 --> 00:38:57.540
Weiß man das da schon so genau, mit welchen Screens? da rauspurzeln?

00:38:58.160 --> 00:39:02.340
Du weißt es nicht ganz genau, aber du weißt es ungefähr. Wenn die UX zum Beispiel

00:39:02.340 --> 00:39:05.240
mit dabei ist, die wissen ungefähr, wie die User Experience sein soll,

00:39:05.260 --> 00:39:10.560
die wissen ungefähr, ja, hier wird der Screen kommen, da brauchen wir den Button, ungefähr.

00:39:12.340 --> 00:39:17.240
So, dass du im Prinzip aber sehen kannst, wie sich die Applikation verhält.

00:39:17.620 --> 00:39:21.660
Welche Buttons sind da? Man muss es erkennen können.

00:39:23.860 --> 00:39:26.340
Ich denke da jetzt gerade mal so ein bisschen komplizierter.

00:39:26.720 --> 00:39:30.140
Wir haben ja auch bei uns auf der Arbeit, damit ich mal so ein ganz konkretes

00:39:30.140 --> 00:39:32.760
Beispiel nenne, ich hoffe, ich sage jetzt nichts Falsches, wenn ich mal ganz

00:39:32.760 --> 00:39:34.080
aufgeregt bin von der Arbeit erziele.

00:39:35.460 --> 00:39:39.260
Wir haben bei uns Feedback-Zyklen implementiert.

00:39:39.500 --> 00:39:43.420
Und ich will nicht sagen, dass ich naiv rangegangen bin, aber ich wurde immer

00:39:43.420 --> 00:39:47.320
wieder überrumpelt, wie unglaublich kompliziert Feedback-Cycles werden können.

00:39:48.080 --> 00:39:52.880
Man kann bei uns jetzt sozusagen den Zeitstrahl auch überwinden,

00:39:53.912 --> 00:39:58.412
Abbrechen, verschiedene Wege gehen oder sogar zurückgehen, wobei vielleicht

00:39:58.412 --> 00:40:01.232
das Zurückgehen auch einfach nur immer wieder weiter nach vorne gehen.

00:40:01.732 --> 00:40:06.572
Konkretes Beispiel, man kann bei dem Peer-Feedback Peers auswählen,

00:40:06.672 --> 00:40:13.912
aber weil dann Situationen entstehen können, wie das die Lieblingsperson von allen hat,

00:40:14.032 --> 00:40:17.712
wurde 20 Mal als Peer nominiert und sagt, ich habe keine Zeit dafür,

00:40:17.912 --> 00:40:22.012
kann dann also wiederum Peer-Anfragen ablehnen.

00:40:22.012 --> 00:40:27.792
Und dann kann wiederum die eigentliche Person sagen, oh, die Person hat keine

00:40:27.792 --> 00:40:30.172
Zeit, dann möchte ich jetzt einen anderen Peer wählen.

00:40:31.292 --> 00:40:35.192
Aber damit das auch immer glatt läuft, können zum Beispiel Supervisor oder Manager

00:40:35.192 --> 00:40:39.392
das auch immer überschreiben oder sagen, oh, die Deadline zum Peer auswählen

00:40:39.392 --> 00:40:43.132
war schon rum, du warst da im Urlaub, komm, ich hab dir hier mal drei Peer schon mal ausgewählt.

00:40:43.272 --> 00:40:46.712
Ich sehe, das läuft alles parallel, das kann alles verwirbelt sein,

00:40:46.832 --> 00:40:51.152
das können Bäumchen sein, das ist für mich schon schwer, das jetzt gerade auszuformulieren,

00:40:51.172 --> 00:40:57.352
obwohl ich mich ich monatelang damit beschäftigt habe, ich sehe dann nicht diesen einfachen Zeitstrahl.

00:40:58.532 --> 00:41:01.392
Was mache ich denn, wenn es so kompliziert wird mit so vielen Verzweigungen?

00:41:01.872 --> 00:41:04.552
Tatsächlich ist auch das, was du beschreibst, ist ja nicht kompliziert.

00:41:04.592 --> 00:41:07.872
Es sind einfach nur unterschiedliche Prozesse, die auch nachher ablaufen können.

00:41:07.972 --> 00:41:09.692
Es ist nicht so, dass das alles parallel abläuft.

00:41:10.892 --> 00:41:14.672
Kompliziert ist das falsche Wort. Es ist umfangreich und ich kann es in meinem

00:41:14.672 --> 00:41:17.772
Kopf meistens nicht einfach so, ich müsste es auch geschrieben haben,

00:41:17.912 --> 00:41:19.572
um alle Punkte da aufzuschreiben.

00:41:20.092 --> 00:41:22.972
Auch das, was du beschreibst, lässt sich auf einem Zeitstrahl abbilden.

00:41:23.032 --> 00:41:26.612
Und ob jetzt das weiter vorne, in welcher Reihenfolge das passiert,

00:41:26.732 --> 00:41:27.732
das ist erstmal gar nicht so wichtig.

00:41:27.892 --> 00:41:31.372
Du wählst dir quasi einen Zeitstrahl aus, wie du das System modellierst.

00:41:33.092 --> 00:41:36.612
Und wichtig ist nur, man kann nachvollziehen, wie das System funktioniert.

00:41:37.732 --> 00:41:40.332
Und ob das dann hinterher weiter vorne passiert oder weiter hinten,

00:41:40.452 --> 00:41:44.572
das spielt überhaupt keine Rolle. Das ist egal. Und das funktioniert mit jeder Software.

00:41:46.152 --> 00:41:51.652
Mit jeder Software. wäre. Gibt es so eine Wahrheit von diesem Zeitstrahl oder

00:41:51.652 --> 00:41:54.712
kann ich da mehrere alternative Universen aufzeichnen?

00:41:55.272 --> 00:41:58.932
Also idealerweise hast du einen Zeitstrahl. Mit allen Sachen,

00:41:58.992 --> 00:42:01.932
die da sind. Also auch optionalen Schritten drin.

00:42:02.172 --> 00:42:05.152
Da sind auch optionale Schritte drin. Natürlich kann es passieren,

00:42:05.212 --> 00:42:10.012
dass du jetzt von einem Zeitstrahl verschiedene Variationen hast.

00:42:10.792 --> 00:42:13.372
Das versuchst du aber trotzdem in einem Zeitstrahl abzubilden.

00:42:14.212 --> 00:42:15.732
Das Ziel ist wirklich,

00:42:18.532 --> 00:42:21.932
deine Software von links nach rechts lesbar zu machen wie ein Buch.

00:42:22.112 --> 00:42:23.592
Es soll eine Geschichte sein.

00:42:24.372 --> 00:42:28.152
Das ist das Ziel. Du willst eine schöne Geschichte über dein System erzählen können.

00:42:30.812 --> 00:42:34.192
Das ist normalerweise der Schritt, der am längsten dauert, diese Screens bereitzustellen.

00:42:34.252 --> 00:42:36.472
Deswegen, ich empfehle immer, das ein bisschen vorzubereiten.

00:42:36.492 --> 00:42:39.052
Deswegen ist es immer fantastisch, wenn da die UX mit dabei ist.

00:42:40.172 --> 00:42:43.412
Aber auch das geht relativ schnell. Wenn man jetzt mit Miro beispielsweise arbeitet,

00:42:44.352 --> 00:42:46.912
Wenn man da ein bisschen Übung drin hat, diese Screens zusammen zu klicken,

00:42:46.912 --> 00:42:47.732
das geht sehr, sehr schnell.

00:42:48.992 --> 00:42:53.112
Und plötzlich hat man eine komplette Story von seinem System und man hat sogar die Screens dazu.

00:42:56.433 --> 00:42:59.773
Da entstehen weitere Diskussionen. Muss der Button jetzt da sein?

00:42:59.993 --> 00:43:01.333
Braucht man diesen Button hier wirklich?

00:43:01.633 --> 00:43:05.553
Und da werden auch nochmal neue Ereignisse entstehen, weil dann wieder auffällt,

00:43:05.573 --> 00:43:08.613
um den Button hier zu klicken, da haben wir eigentlich noch irgendwie gar nichts.

00:43:08.693 --> 00:43:10.853
Da fehlt noch ein Ereignis.

00:43:11.253 --> 00:43:14.773
Also diese Geschichte wird immer kompletter, je länger wir damit arbeiten.

00:43:16.773 --> 00:43:19.593
Das dauert typischerweise so, sagen wir mal zwei bis drei Stunden.

00:43:21.473 --> 00:43:25.713
Diese Mitvorbereitung, zwei bis drei Stunden, bis man alles zusammen hat,

00:43:26.473 --> 00:43:30.473
ist so die Hausnummer, mit der man rechnen muss.

00:43:30.853 --> 00:43:33.193
Kann das zu komplett und zu komplex werden?

00:43:35.893 --> 00:43:38.693
Du meinst zu umfangreich oder was meinst du mit zu komplett?

00:43:38.973 --> 00:43:42.633
Ja, ich meine, jetzt unabhängig von irgendwelchen physischen Constraints,

00:43:42.713 --> 00:43:45.213
aber irgendwo ist ja dann auch mal der menschliche Arbeitsspeicher erschöpft,

00:43:45.273 --> 00:43:49.173
wenn du einfach da so die Geschichte des Systems irgendwie erzählst.

00:43:49.173 --> 00:43:52.913
Aber es ist halt einfach ein so unglaublich haariges Biest mit so vielen Sonderfällen

00:43:52.913 --> 00:43:56.613
und hier noch was und da noch was und dort, die ja vielleicht auch nicht so

00:43:56.613 --> 00:43:59.893
ohne weiteres abtrennbar sind, wie dass man einfach so Anfang und Ende von einem

00:43:59.893 --> 00:44:01.613
Microservice einfach so wegdefinieren kann.

00:44:02.453 --> 00:44:06.133
Also was ist, wenn man sozusagen in dieser Erzählung erst merkt,

00:44:06.173 --> 00:44:09.233
hoppala, das wuchert sich aus und wir müssten das Ding eigentlich anders schneiden?

00:44:10.113 --> 00:44:14.833
Dann hast du schon deine erste super wichtige Erkenntnis und dann hast du schon

00:44:14.833 --> 00:44:17.273
was über dein System gelernt und dann musst du dir halt überlegen,

00:44:17.313 --> 00:44:19.673
können wir so weitermachen oder macht es vielleicht erstmal Sinn,

00:44:19.693 --> 00:44:22.753
dass wir uns Gedanken machen, wie das System überhaupt aufgebaut ist,

00:44:22.773 --> 00:44:23.593
weil dann stimmt irgendwas nicht.

00:44:28.068 --> 00:44:31.368
Okay, Moment, warte mal. Ich bin doch gerade dabei, mir Gedanken über mein System zu machen.

00:44:31.528 --> 00:44:33.768
Und dann stelle ich fest, das wird zu kompliziert. Und dann muss ich einen Schritt

00:44:33.768 --> 00:44:38.448
zurückgehen und mir Gedanken über das System machen. Wo bin ich da jetzt gerade vom Pfad abgewichen?

00:44:40.968 --> 00:44:44.208
Du willst ja ein System modellieren. Jo. Genau.

00:44:45.248 --> 00:44:50.948
Und entweder das System lässt sich so modellieren, wie du dir das vorstellst,

00:44:50.988 --> 00:44:52.148
auch wenn es größer wird.

00:44:53.088 --> 00:44:57.328
Und dann ist es genau das, was du erreichen möchtest. Oder aber du merkst,

00:44:57.368 --> 00:45:00.388
das lässt sich so gar nicht modellieren, weil es vielleicht unterschiedliche

00:45:00.388 --> 00:45:02.948
Systeme sind, was du vorher gar nicht gesehen hast, was du gar nicht gemerkt hast.

00:45:03.908 --> 00:45:06.688
Okay, das heißt, ich würde dann sozusagen von meinem ersten Ansatz alle in einen

00:45:06.688 --> 00:45:11.368
Raum vom obersten Chef bis zum untersten Einsteiger das dann durchspielen,

00:45:11.428 --> 00:45:15.188
merken, das haut nicht hin, das ist zu komplex, das muss aufgeteilt werden, Schritt zurückgehen,

00:45:15.308 --> 00:45:18.848
das machen, was mit meinem Arbeitsprozess-Team da der Fall war,

00:45:18.928 --> 00:45:23.388
dass wir sagen, wir definieren da Anfang und Ende und innerhalb dessen formulieren wir das aus.

00:45:23.388 --> 00:45:25.768
Genau, man könnte zum Beispiel sagen, okay, wir machen hier einen Cut,

00:45:25.908 --> 00:45:28.868
hier hört das System auf, hier haben wir einen weiteren Bereich,

00:45:29.068 --> 00:45:31.408
das müssen wir vielleicht in einer weiteren Iteration machen,

00:45:31.608 --> 00:45:36.268
mit entweder der gleichen Mannschaft oder vielleicht auch mit einer anderen Mannschaft. Okay.

00:45:39.848 --> 00:45:44.568
Genau, das Nächste, was du dann machst, also jetzt haben wir schon unsere Zeitleiste,

00:45:44.568 --> 00:45:46.548
unsere Ereignisse und unsere Screens.

00:45:47.128 --> 00:45:50.988
Jeder sieht die Software, jeder sieht, was das System tun soll.

00:45:51.128 --> 00:45:54.088
Das Nächste, was du machst, ist, du definierst im Prinzip die Eingangsparameter.

00:45:54.868 --> 00:45:59.188
Hm, aber das scheint mir alles gerade noch wirklich sehr aus der Frontend- und

00:45:59.188 --> 00:46:00.528
Design-Richtung fast zu sein.

00:46:00.628 --> 00:46:03.908
Klar, das ist auch die Sicht, die ich jetzt drauf habe, aber was ich mich schon

00:46:03.908 --> 00:46:09.568
immer auch gefragt habe, zum Beispiel SystemadministratorInnen und Backendler,

00:46:11.090 --> 00:46:14.410
Müssen ja auch so im Hinterkopf, die denken ja nicht in, weiß ich vielleicht,

00:46:14.570 --> 00:46:15.750
vielleicht denken sie doch in Buttons.

00:46:16.210 --> 00:46:19.730
Aber irgendwie habe ich das Gefühl, da müssen immer so andere unsichtbare Dinge

00:46:19.730 --> 00:46:22.370
passieren und das Frontend kriegt einfach magische Dinge.

00:46:22.610 --> 00:46:28.610
Frontend macht einfach Button und eben für mich komplexen Fall macht Backend

00:46:28.610 --> 00:46:34.110
irgendwelche Dinge mit Kafka und Microservices und wir sagen allen was weiß ich was Bescheid.

00:46:34.510 --> 00:46:38.350
Und dann kommt wieder was ans Frontend zurück. Aber für mich ist das immer eben

00:46:38.350 --> 00:46:42.330
klarer, die Frontend-Screens oder die UI-Screens sind aufgezeichnet.

00:46:43.990 --> 00:46:48.630
Gut, da müssen teilweise heutzutage auch schon sowas wie Frontend-Datenbanken,

00:46:48.730 --> 00:46:52.650
also so State-Management gemacht werden, aber mir kommt ja immer so das Backend

00:46:52.650 --> 00:46:53.690
immer so ein bisschen zu kurz.

00:46:54.770 --> 00:46:59.110
Genau dazu kommen wir jetzt. Okay. Also bisher haben wir die Screens.

00:46:59.830 --> 00:47:02.310
Und das Nächste, was wir machen, ist, wir definieren die Eingangsparameter.

00:47:02.590 --> 00:47:07.690
Wie kommen denn jetzt die Daten von den Screens in unser System?

00:47:07.830 --> 00:47:10.230
Also wir haben im Prinzip schon, wir haben die Screens und wir haben die Ereignisse,

00:47:10.230 --> 00:47:13.330
die passiert sind. Aber wir wissen, uns fehlt das Verbindungsstück im Prinzip.

00:47:14.290 --> 00:47:18.030
Wie kommen wir von unseren Screens zu den Ereignissen? Und das Nächste,

00:47:18.050 --> 00:47:19.750
was wir machen, wir definieren die Eingangsparameter.

00:47:20.310 --> 00:47:22.390
Nennt sich Command. Pro Ereignis oder so ganz am Anfang?

00:47:23.190 --> 00:47:26.910
Pro Ereignis. Pro Ereignis. Genau. Du hast im Prinzip für jedes Ereignis,

00:47:26.910 --> 00:47:30.870
für jedes Ereignis, was im System passiert, hast du irgendeinen Trigger,

00:47:30.970 --> 00:47:33.830
irgendwas, was dieses Ereignis auslöst. Nennt sich Command.

00:47:35.010 --> 00:47:38.510
Und jetzt definieren wir die Commands. Und die definieren wir so,

00:47:39.070 --> 00:47:41.490
dass wir die gleich mit den richtigen Daten anreichern.

00:47:42.450 --> 00:47:46.490
Also stell dir vor, du hast beispielsweise, du könntest eine REST-API haben,

00:47:47.830 --> 00:47:49.350
die aufgerufen wird vom Frontend.

00:47:49.750 --> 00:47:52.990
Und jetzt überlegst du dir, naja, welche Daten muss ich denn jetzt von meinem

00:47:52.990 --> 00:47:57.570
Frontend über die REST API in mein System geben, dass schlussendlich das Ereignis

00:47:57.570 --> 00:48:01.230
rauskommt, was ich da modelliert habe? Was brauche ich denn da für Daten?

00:48:03.915 --> 00:48:07.755
Und das machst du im Prinzip für jedes Ereignis. Damit definierst du im Prinzip

00:48:07.755 --> 00:48:08.955
deine API für dein System.

00:48:10.155 --> 00:48:13.075
Für jeden Schritt. Das mache ich bei dem Workshop?

00:48:14.635 --> 00:48:15.435
Ja. Halleluja.

00:48:18.735 --> 00:48:22.335
Wie lange dauert das denn? Das dauert nicht lange.

00:48:22.555 --> 00:48:25.995
Du hast ja im Prinzip schon die richtigen Daten da. Die Daten stehen im Prinzip

00:48:25.995 --> 00:48:27.235
schon in den Ereignissen.

00:48:28.835 --> 00:48:32.155
In den Commands definierst du nicht irgendwie, hatte die P-Post oder oder sowas,

00:48:32.175 --> 00:48:35.395
sondern es geht nur um die Daten, die du ins System gibst. Okay.

00:48:39.675 --> 00:48:42.735
Und das machst du im Prinzip für... Sind da auch so Sonderfälle dabei,

00:48:42.915 --> 00:48:44.735
wie Rechte-Management?

00:48:47.355 --> 00:48:51.095
Du redest auch über Security. Security ist auch ein Aspekt, der da mit rein muss.

00:48:51.575 --> 00:48:55.735
Also zum Beispiel könnte ein Ereignis sein, Rechte zugewiesen.

00:48:56.835 --> 00:48:59.475
User authentifiziert. Und da musst du dir überlegen, was muss denn eigentlich

00:48:59.475 --> 00:49:02.855
passieren, damit dieses Ereignis ausgelöst wird.

00:49:02.915 --> 00:49:06.335
Der User muss sich irgendwie eingeloggt haben. Das heißt, wir brauchen irgendwie so ein Login-Command.

00:49:12.735 --> 00:49:15.755
Die Frage, die, glaube ich, jetzt mir gerade im Kopf rumschwirrt,

00:49:16.715 --> 00:49:23.015
kann es pro zu einem Ereignis unterschiedliche Eingangsparameter geben?

00:49:23.015 --> 00:49:29.815
So, wenn User Rolle A hat, werden folgende Parameter gesendet?

00:49:30.795 --> 00:49:36.955
Und sollte User eher vom Typen B sein, werden andere Daten gesendet? Das kann passieren.

00:49:37.315 --> 00:49:42.235
Das ist möglich. Dann würdest du einfach mehrere Commands beispielsweise modellieren.

00:49:44.115 --> 00:49:48.035
Ziel ist es eigentlich, alle Fälle in deinem Zeitstrahl abzubilden.

00:49:51.615 --> 00:49:54.395
Jetzt haben wir schon sehr viel geschafft. Wir haben den Zeitstrahl,

00:49:54.455 --> 00:49:58.175
wir haben die Screens, wir haben die Ereignisse und wir haben die Eingangsparameter für unser System.

00:49:58.495 --> 00:50:01.855
Jetzt fällt im Prinzip nur noch eine Sache.

00:50:02.015 --> 00:50:06.775
Und zwar, wir kommen jetzt die Daten aus unserem System wieder zum nächsten

00:50:06.775 --> 00:50:08.255
Schritt. Zur nächsten UI.

00:50:09.695 --> 00:50:14.275
Und das machst du im nächsten Schritt. Du definierst, nennt sich Read Model.

00:50:15.215 --> 00:50:19.515
Also wie kommen die Daten jetzt aus den Ereignissen zum nächsten Schritt.

00:50:20.595 --> 00:50:23.695
Und auch das machst du wieder mit den Beispieldaten. Und da stellst du dann

00:50:23.695 --> 00:50:27.215
fest, haben wir denn wirklich alle Daten für den nächsten Screen,

00:50:27.295 --> 00:50:28.055
den wir anzeigen sollen?

00:50:28.675 --> 00:50:31.095
Ist denn wirklich alles da? Oder fehlt vielleicht was?

00:50:33.195 --> 00:50:35.615
Und hier wird es ganz interessant, weil was wir hier dann erreichen,

00:50:35.715 --> 00:50:40.995
wenn wir das modellieren, ist quasi der Beweis, dass wir alles berücksichtigt haben.

00:50:43.335 --> 00:50:47.415
Proof of Data Completeness nennt sich das. Also wenn wir das alles richtig machen,

00:50:47.515 --> 00:50:50.575
dann wissen wir, wir haben quasi alle Fälle berücksichtigt und wir wissen,

00:50:50.675 --> 00:50:53.775
alle Daten, die wir brauchen, um unser System zu bauen, sind da,

00:50:53.895 --> 00:50:54.475
wir haben an alles gedacht.

00:50:58.597 --> 00:51:03.697
Ja, das klingt ja gut. Jetzt gehe ich nochmal zurück zu einem Thema,

00:51:03.777 --> 00:51:05.337
was wir ja am Anfang schon mal hatten.

00:51:05.617 --> 00:51:09.357
Da haben wir kurz über Agile und so gesprochen und wir wissen ja gar nicht,

00:51:09.417 --> 00:51:10.677
was am Ende rausputzen soll.

00:51:11.937 --> 00:51:15.537
Du kannst bestimmt auch gleich noch weiter bei einem aktuellen Thema bleiben,

00:51:15.617 --> 00:51:19.017
aber wir gehen jetzt mal davon aus, wir haben diesen Workshop sehr gut beendet

00:51:19.017 --> 00:51:23.137
und wir haben jetzt alles mal nach vorne übersprungen und wir haben das fertig gebaut.

00:51:23.357 --> 00:51:29.917
Das läuft jetzt. Und jetzt läuft das seit vier Wochen auf der Webseite und wir

00:51:29.917 --> 00:51:33.997
stellen fest, oh, wir haben da was vergessen, was unsere User unbedingt richtig

00:51:33.997 --> 00:51:35.197
gut gebrauchen könnten.

00:51:35.357 --> 00:51:41.057
Und wir bräuchten jetzt bei diesen Ereignissen noch mehr Zwischenereignisse

00:51:41.057 --> 00:51:43.957
oder andere Daten, die wir noch weitergeben müssen.

00:51:45.097 --> 00:51:54.317
Also wie robust ist das denn dann, was da rauskommt gegenüber den zukünftigen Änderungswünschen?

00:51:55.997 --> 00:52:02.437
Das, was du da machst, ist im Prinzip, du unterteilst deine Software in die

00:52:02.437 --> 00:52:05.077
kleinstmöglichen funktionalen Blöcke, die möglich sind.

00:52:05.637 --> 00:52:11.037
Also du hast im Prinzip immer diese Unterteilung Screen, Eingangsparameter,

00:52:11.157 --> 00:52:14.237
Ereignis und das Readmodel für den nächsten Screen.

00:52:15.197 --> 00:52:17.557
Und das, was da im Prinzip modelliert

00:52:17.557 --> 00:52:22.317
ist, ist der kleinstmögliche Funktionsblock, den du bauen kannst.

00:52:26.007 --> 00:52:30.487
Und typischerweise kannst du genau diesen Funktionsblock eins zu eins in eine

00:52:30.487 --> 00:52:31.587
User-Story transportieren.

00:52:31.867 --> 00:52:34.327
Das sind die User-Stories, die im System entstehen.

00:52:35.107 --> 00:52:38.807
Denn jeden von diesen Blöcken kannst du eins zu eins implementieren.

00:52:39.967 --> 00:52:44.967
Und in deinem Fall jetzt, wenn du sagst, in einem von diesen Funktionsblöcken ändert sich irgendwas,

00:52:45.187 --> 00:52:50.547
dann würdest du genau diesen einen Teil neu modellieren und würdest hier beispielsweise

00:52:50.547 --> 00:52:57.107
die Events anpassen, die Events und neue Attribute ergänzen und dann genau diesen

00:52:57.107 --> 00:52:58.187
einen Funktionsblock neu bauen.

00:52:59.427 --> 00:53:02.407
Der große Vorteil ist, du musst nichts anderes anfassen. Du musst genau diesen

00:53:02.407 --> 00:53:04.147
einen Funktionsblock anfassen und nichts anderes. das.

00:53:04.547 --> 00:53:07.967
Ich finde es auch schön, dass du wirklich das Wort Neumodellieren verwendet hast.

00:53:08.327 --> 00:53:13.347
Denn was ich ja ganz am Anfang meinte, ist dieses Aufeinander draufbauen,

00:53:13.347 --> 00:53:18.107
dass ich es immer wieder und immer wieder sehe und auch selber machen möchte.

00:53:18.227 --> 00:53:20.927
Ich sehe halt, oh, dieses Feature kam später nochmal nach.

00:53:22.247 --> 00:53:27.467
Und ich meine es nicht mal ausschließlich technisch und als Developer nicht

00:53:27.467 --> 00:53:28.827
jetzt irgendwie böse angesprochen fühlen.

00:53:28.867 --> 00:53:31.287
Ich finde das im Design und im Produktflow teilweise genauso.

00:53:31.647 --> 00:53:35.667
Da hat ja man manchmal so sein einen perfekten Flow und man möchte auch unbedingt

00:53:35.667 --> 00:53:38.147
an dem festhalten, weil der war ja damals so perfekt,

00:53:38.327 --> 00:53:43.407
aber du willst da noch ein weiteres Feature hineinbringen und manchmal fällt

00:53:43.407 --> 00:53:46.467
es wirklich auch schwer, von mir auch selber aus der Produktsicht heraus,

00:53:46.627 --> 00:53:52.567
diesen bestehenden Flow so anzupassen, dass das wieder so eine komplette Synergie ergibt.

00:53:52.627 --> 00:53:56.187
Und ich glaube, das ist wirklich schwer, wenn man so in dem Sinne,

00:53:56.267 --> 00:53:58.887
das haben wir doch schon immer so gemacht, wenn man diese bestehenden Sachen

00:53:58.887 --> 00:54:00.867
wirklich nochmal anfassen muss.

00:54:02.619 --> 00:54:08.499
Tatsächlich ist dieses bestehende Sachen nochmal anfassen ein Riesenproblem.

00:54:09.459 --> 00:54:13.279
Denn daraus entstehen die größten Aufwände in der Softwareentwicklung.

00:54:13.859 --> 00:54:16.159
Immer wenn du Sachen anfasst, die eigentlich schon fertig sind,

00:54:17.579 --> 00:54:21.019
dann änderst du was, was eigentlich schon fertig ist. Und das willst du eigentlich nicht.

00:54:22.119 --> 00:54:26.239
Ja, klar. Also an neuen Features zu arbeiten ist auch immer viel einfacher.

00:54:26.379 --> 00:54:30.219
Ich kenne das, falls soll jetzt irgendwelche Produktmenschen und Manager zuhören,

00:54:30.939 --> 00:54:32.739
Ganz oft werde ich mit dem Satz konfrontiert,

00:54:33.579 --> 00:54:38.379
kann ich der Person XY die Features, ich brauche dann nur noch ein Feature auf

00:54:38.379 --> 00:54:41.679
dem bestehenden Ding drauf, weil das ist ja einfach, weil das ist ja schon fertig.

00:54:42.079 --> 00:54:46.139
Und ich gleich immer schmunzeln muss und sage, nein, genau andersrum,

00:54:46.279 --> 00:54:51.359
gib denen mal das komplett Neue und hock mal die alten Hasen auf dieses alte

00:54:51.359 --> 00:54:53.359
Feature hier drauf. Genau so ist es.

00:54:54.519 --> 00:54:57.959
Oder mach mal aus diesem Button hier einen Dropdown.

00:54:58.799 --> 00:55:00.919
Müsste ja schnell gehen, dauert nur einen Tag. Mach mal einen Dropdown.

00:55:01.139 --> 00:55:06.019
Da ist immer Hauptformal schnell verloren. Das dauert immer viermal so lange, wie erwartet.

00:55:06.379 --> 00:55:11.419
Ich finde es übrigens großartig. Wir haben ja hier jetzt auch die Kamera am Laufen.

00:55:11.539 --> 00:55:16.919
Und ich finde Peters Blick super, weil du schaust sehr stirnrunzelnd.

00:55:16.919 --> 00:55:19.079
Und ich würde dich gerne fragen, was geht dir durch den Kopf?

00:55:19.939 --> 00:55:24.599
Ich bin nur am Zuhören, Mitschreiben und gleichzeitig Nachdenken und Recherchieren.

00:55:24.599 --> 00:55:29.259
Und das ist halt um diese Uhrzeit für diesen alten Mann schon ziemlich anstrengend.

00:55:30.919 --> 00:55:34.679
Nur deswegen gucke ich so gestresst. Und ich war halt eben gerade auch so bei

00:55:34.679 --> 00:55:38.839
ungefähr dem Problem am Denken mit dem Funktionsblock, wenn sich etwas ändert,

00:55:38.859 --> 00:55:40.839
wenn also was hinzugefügt werden muss, dann nehme ich den,

00:55:41.339 --> 00:55:44.079
Funktionsblock, den ich da identifiziert habe, als die kleinste mögliche Einheit,

00:55:44.139 --> 00:55:48.719
in der sozusagen diese Änderung enthalten sein kann und dann gehe ich hin und

00:55:48.719 --> 00:55:51.579
baue das in diesen Funktionsblock ein. Habe ich das richtig verstanden?

00:55:52.539 --> 00:55:56.759
Mhm. Mhm. Okay. Und ich nehme mal an, diese Funktionsblöcke kann man auch hierarchisch

00:55:56.759 --> 00:55:59.559
strukturieren, wenn ich also jetzt den Funktionsblock als die kleinste mögliche

00:55:59.559 --> 00:56:02.359
Einheit habe und ich habe, was das berührt, zwei von den Dingern kann ich da

00:56:02.359 --> 00:56:06.359
sozusagen, zwei von denen zusammennehmen und die als ein Subsystem betrachten und darin was ändern.

00:56:09.551 --> 00:56:12.451
Also typischerweise betrachtest du nicht zwei als ein Subsystem,

00:56:12.591 --> 00:56:15.091
sondern jeder ist im Prinzip für sich alleinstehend erstmal.

00:56:15.891 --> 00:56:18.011
Ja, aber ich meine, es gibt ja tatsächlich irgendwie so Dinger,

00:56:18.031 --> 00:56:21.011
ich versuche jetzt mal gerade so beim Mitdenken irgendwie so zu gucken,

00:56:21.091 --> 00:56:23.791
okay, wie mappt das auf irgendwelche Dinger, von denen ich irgendwie Ahnung habe.

00:56:24.091 --> 00:56:27.071
Und ich habe hier gerade mal so einfach so die schlimmste dysfunktionale Webseite,

00:56:27.111 --> 00:56:30.911
die ich kenne, patreon.com aufgemacht und stoche da halt jetzt gerade so in

00:56:30.911 --> 00:56:32.991
den JSON-Responses rum, um irgendwie so nachzuvollziehen.

00:56:33.331 --> 00:56:35.951
So, ne, einfach so den Worst Case mal irgendwie so angucken.

00:56:35.951 --> 00:56:39.531
Und da habe ich jetzt zum Beispiel gerade in den JSON-Responsen etwas drin gefunden,

00:56:39.771 --> 00:56:43.351
so can see not safe for work. Und das ist ein Boolean, der ist true oder false.

00:56:43.871 --> 00:56:46.611
Und wenn ich mir jetzt halt eben vorstelle, es gäbe so diesen Aspekt,

00:56:46.651 --> 00:56:50.411
ich kann eine Klasse von Content sehen oder nicht sehen und die habe ich anfangs

00:56:50.411 --> 00:56:54.311
in meinem System nicht drin und dann irgendwie in der nächsten Iteration stelle ich fest,

00:56:54.451 --> 00:56:57.491
okay, wir brauchen so einen not safe for work Filter, dann ist das ja,

00:56:57.511 --> 00:57:04.371
was das wirklich sehr viele Funktionsblöcke betrifft, irgendwie relevant sein

00:57:04.371 --> 00:57:05.871
kann, je nachdem, wie es implementiert ist.

00:57:05.871 --> 00:57:09.451
Also taucht das einfach nicht auf oder ist das irgendwie erstaunlich ausgeblendet

00:57:09.451 --> 00:57:10.731
und ich kann es mit einem Klick einblenden.

00:57:11.211 --> 00:57:15.131
Also wie würde ich sozusagen solche Dinge, die ja betrachtet werden kann,

00:57:15.191 --> 00:57:17.411
als im Prinzip ja nur ein Eingangsparameter, aber etwas sind,

00:57:17.411 --> 00:57:21.191
was am Ende alles andere potenziell auf links dreht, wie gehe ich damit um?

00:57:22.091 --> 00:57:24.971
Wie würdest du denn so ein Parameter konfigurieren? Also wie kommt denn dieser

00:57:24.971 --> 00:57:27.031
Parameter ursprünglich ins System rein?

00:57:29.511 --> 00:57:34.571
Äh, not safe for work? Wahrscheinlich User-Checkbox.

00:57:34.651 --> 00:57:36.631
Kann ich mir aussuchen, ob ich das sehen möchte oder nicht? Genau,

00:57:36.691 --> 00:57:43.871
also du hättest erstmal ja einen, irgendeine UI, irgendeinen Button, wo du das klickst.

00:57:43.951 --> 00:57:49.331
Das heißt, das Erfassen dieser Information wäre erstmal wieder ein Funktionsblock von uns. Ja, klar.

00:57:49.751 --> 00:57:51.611
Damit ist die Information im System verfügbar.

00:57:52.471 --> 00:57:58.371
Und dann kannst du ja im Prinzip in jedem von diesen Funktionsblöcken auf diese

00:57:58.371 --> 00:58:01.031
Information zugreifen. Ja.

00:58:03.591 --> 00:58:06.731
Ja, aber ich muss ja auch wissen, welche Funktionsblöcke betroffen sind und welche nicht.

00:58:06.811 --> 00:58:11.111
Das ist ja für den Login-Prozess irrelevant, aber möglicherweise für alles andere,

00:58:11.171 --> 00:58:14.631
von Zeig Medien an bis Lade Medien hoch, wo ich klassifizieren kann,

00:58:14.771 --> 00:58:16.571
ist das ja irgendwie relevant.

00:58:16.811 --> 00:58:20.071
Also ich muss ja sozusagen, ich fange ja mit sowas Abstraktem an,

00:58:20.131 --> 00:58:22.731
wie wir brauchen einen Not Safe for Work Filter, jetzt nachträglich.

00:58:22.971 --> 00:58:27.011
Und ich muss dann ja irgendwie rausfinden, okay, wer muss darüber irgendwie,

00:58:27.411 --> 00:58:33.071
also wer muss das mitbekommen und muss das implementieren und wie baue ich das

00:58:33.071 --> 00:58:36.731
in die Geschichte des Systems und das gesamte Big Picture, das alle zu dem Zeitpunkt haben,

00:58:36.831 --> 00:58:42.411
dann ein und wie sorge ich dann dafür, dass danach auch alle das gleiche Big Picture noch sehen.

00:58:42.491 --> 00:58:46.291
Wenn ich jetzt wirklich so einen einzigen Boolean einfüge, aber der betrifft

00:58:46.291 --> 00:58:48.931
halt 70% von allem, was stattfindet.

00:58:50.764 --> 00:58:55.164
Und das passiert dann anträglich. Genau, das ist ja jederzeit möglich.

00:58:55.584 --> 00:59:00.064
Würdest du dann diesen Filter, ich kann jetzt mit Not Safe for Work Filter nichts

00:59:00.064 --> 00:59:02.724
anfangen, wäre das ein Filter, den du einfach mit nach oben gibst?

00:59:02.764 --> 00:59:03.724
Oder was macht der Filter?

00:59:04.004 --> 00:59:06.604
Ich kann als Nutzer sagen, ich will das Zeug sehen oder nicht sehen.

00:59:06.644 --> 00:59:10.744
Und wenn ich irgendwie was hochlade, kann ich sagen, das fällt in diese Kategorie,

00:59:10.784 --> 00:59:12.364
die einige rausfiltern wollen, rein.

00:59:13.864 --> 00:59:17.984
Ja oder nein. Das wären sozusagen die zwei Dinger. Und dann werden halt eben

00:59:17.984 --> 00:59:20.244
bestimmte Medien angezeigt oder nicht.

00:59:20.764 --> 00:59:24.444
Oder irgendwie aufbereitet oder nicht, in der Statistik erfasst oder nicht.

00:59:25.424 --> 00:59:29.624
Genau, du müsstest dann im Prinzip für jeden Funktionsblock,

00:59:29.684 --> 00:59:32.604
den du hast, einfach überprüfen bei den Daten, die quasi zurück ans Frontend

00:59:32.604 --> 00:59:34.304
gegeben werden, ob der Filter greift oder nicht.

00:59:35.084 --> 00:59:38.564
Also das kann natürlich passieren, dass du jetzt für eine Änderung mehrere von

00:59:38.564 --> 00:59:40.424
diesen Funktionsblöcken anpassen musst.

00:59:40.564 --> 00:59:43.224
Und gegebenenfalls auch neu modellieren musst. Das kann natürlich passieren.

00:59:43.544 --> 00:59:50.124
Ja, klar, okay. Und das muss dann sozusagen, also, Also, mir fällt halt wirklich

00:59:50.124 --> 00:59:51.164
jetzt der Prozess schwer.

00:59:51.224 --> 00:59:53.844
Du hast jetzt ja gerade diesen Workshop mit uns durchgespielt und das war total

00:59:53.844 --> 00:59:57.304
super und ich habe genau verstanden, wie man hier von Willkommen alle in unserem

00:59:57.304 --> 01:00:01.504
Raum, da hinten steht der Kaffee, bis hin zu, wir landen dann bei konkreten

01:00:01.504 --> 01:00:03.184
Dingen wie Screens und Eingareparametern.

01:00:03.244 --> 01:00:06.384
Ich habe komplett nachvollzogen, wie der Prozess stattfindet.

01:00:06.664 --> 01:00:10.164
Aber der Prozess findet jetzt dergestalt statt, dass diese Idee,

01:00:10.324 --> 01:00:13.784
wir brauchen Not Safe for Work Filter, sich in der Welt manifestiert.

01:00:13.844 --> 01:00:17.364
Und irgendwie drei Leute in der Firma wissen, so, das muss jetzt passieren.

01:00:17.724 --> 01:00:22.404
Wie sieht jetzt der Arbeitsprozess aus? Von diese Idee wird bekannt bis hin

01:00:22.404 --> 01:00:26.684
zu, wir landen wieder bei Screens, Eingabeparametern und vor allen Dingen wieder

01:00:26.684 --> 01:00:31.464
bei dem gleichen Ding, was wir am Ende vom Workshop hatten, wo alle das gleiche Weltbild hatten.

01:00:32.044 --> 01:00:35.644
Weil das ja im Prinzip das große Ding ist, wo wir hinterher herauskommen,

01:00:35.704 --> 01:00:38.584
alle haben das System verstanden. Aber sie müssen ja nicht nur das System verstehen,

01:00:38.684 --> 01:00:43.004
sondern sie müssen ja auch die Zustandsübergänge des Systems von Version 1 zur

01:00:43.004 --> 01:00:47.024
Version 2 nachvollziehen und auch danach noch das gleiche gemeinsame Weltbild haben.

01:00:48.397 --> 01:00:51.737
Genau. Das Erste, was du immer machst, wenn du so eine Änderung hast,

01:00:51.857 --> 01:00:54.557
das Modell ist im Prinzip immer das, was du als erstes machst.

01:00:54.657 --> 01:00:59.697
Das heißt, du würdest erst mal das Modell anpassen, dass jeder versteht, was passiert.

01:00:59.837 --> 01:01:02.277
Also du würdest deinen Filter jetzt im Prinzip im Modell, bevor du irgendwas

01:01:02.277 --> 01:01:03.857
machst, aktualisierst du das Modell.

01:01:04.717 --> 01:01:09.217
Und dann entstehen im Prinzip aus den Änderungen in deinem Modell entstehen die neuen User Stories.

01:01:09.757 --> 01:01:12.677
Noch mal wieder runtergebrochen auf so das Workshop-Szenario.

01:01:13.157 --> 01:01:17.177
Zum Modell aktualisieren vollziehe ich welche Schritte in der echten Welt?

01:01:18.417 --> 01:01:21.657
Das kannst du jetzt definieren. Da würdest du mit Sicherheit jetzt nicht mehr alle zusammenbringen.

01:01:21.777 --> 01:01:27.157
Also diese große Gruppe, die brauchst du initial, um das System einmal gänzlich zu erfassen.

01:01:28.137 --> 01:01:33.857
Später hast du dann vielleicht einzelne Leute, die für Teile des Modells zuständig

01:01:33.857 --> 01:01:39.477
sind, Teile, die nur für Teams zuständig sind. Da brauchst du nicht mehr die ganze Gruppe.

01:01:40.057 --> 01:01:42.797
Aber bevor du irgendwas machst, aktualisierst du immer das Modell.

01:01:42.817 --> 01:01:45.697
Das könnte der Teamlead sein, das kann das ganze Team sein, das kann man im Planning machen.

01:01:46.617 --> 01:01:49.657
Da muss man sich einen Prozess überlegen. Wie passt die Veranstaltung mit allen,

01:01:49.757 --> 01:01:50.897
die sich davon betroffen fühlen?

01:01:52.597 --> 01:01:55.557
So Medienanzeige im weitesten Sinne, die setzen sich zusammen und aktualisieren

01:01:55.557 --> 01:01:58.257
dann ihren jeweiligen Krempel, ja? Ganz genau. Okay.

01:02:01.997 --> 01:02:04.717
Aber dann ist ja nicht mehr bei allen das gleiche Weltbild vorhanden,

01:02:04.757 --> 01:02:05.797
weil dann ja welche nicht dabei waren.

01:02:06.977 --> 01:02:10.397
Naja, also was du ja hast, ist, das Modell ist ja für jeden zugänglich.

01:02:10.457 --> 01:02:13.877
Und typischerweise arbeitest du ja, nimm mal ein Team.

01:02:13.957 --> 01:02:17.337
Ein Team hat ein Microservice, der Microservice, dem gehört ein Teil des Modells.

01:02:18.317 --> 01:02:22.477
Und das Team wird immer nur seinen Teil des Modells aktualisieren. Ja.

01:02:22.897 --> 01:02:26.117
Und trotzdem aber haben die natürlich den Gesamtblick auf dieses komplette Modell

01:02:26.117 --> 01:02:27.557
und sehen die ganze Zeit, was passiert.

01:02:28.217 --> 01:02:29.977
Wie ist das System aufgebaut?

01:02:33.606 --> 01:02:37.666
Okay, und das ist dann, also in dem Workshop waren das ja tatsächlich irgendwie

01:02:37.666 --> 01:02:41.406
Post-its an der Wand oder Dinge auf dem Bildschirm.

01:02:41.466 --> 01:02:49.106
Also müsste ich dann sozusagen im Nachgang dieses Workshops auch dieses Modell

01:02:49.106 --> 01:02:52.346
irgendwie in etwas übertragen, in so eine Single Source of Truth,

01:02:52.526 --> 01:02:55.426
die dann auch modifiziert werden kann und für alle einsehbar ist?

01:02:55.846 --> 01:02:59.446
Genau. Also ich empfehle immer Miro dafür. Auch wenn du einen physikalischen

01:02:59.446 --> 01:03:03.406
Workshop machst mit Post-its an Bord, wird es später in ein digitales Board

01:03:03.406 --> 01:03:05.246
übertragen und dann hast du dann zum Beispiel Miro.

01:03:05.406 --> 01:03:08.786
Also das ist tatsächlich, das ist gar nicht so trivial, das Board immer auf

01:03:08.786 --> 01:03:11.206
einem aktuellen Stand zu halten und das braucht ein bisschen Übung.

01:03:12.206 --> 01:03:17.766
Aber das ist dann deine Single Source of Truth. Ja, und wie weiß ich,

01:03:17.826 --> 01:03:21.526
dass ich das sozusagen auf dem aktuellen Stand halte?

01:03:21.686 --> 01:03:26.166
Weil ich meine, aus dem Workshop heraus ist es ja irgendwie aus sich heraus evident.

01:03:26.266 --> 01:03:28.946
Alle sind da, alle haben es gesehen, haben den Prozess von vorne nach hinten

01:03:28.946 --> 01:03:33.286
durchgegangen, also haben die notwendigerweise ein so dermaßen synchronisiertes

01:03:33.286 --> 01:03:34.666
Weltbild, wie es eigentlich nur sein kann.

01:03:35.426 --> 01:03:38.226
Aber sozusagen, ich muss ja sozusagen auch die Kontrolle irgendwie machen,

01:03:38.326 --> 01:03:42.486
dass wenn da jetzt einzelne Leute das System erweitern, also dass das dann irgendwie

01:03:42.486 --> 01:03:46.206
noch so verständlich ist, mit nichts anderem kollidiert, dass die nicht irgendwie

01:03:46.206 --> 01:03:47.726
was an ihrer, keine Ahnung,

01:03:47.826 --> 01:03:51.926
an ihren Daten, an ihren Inputs und Outputs so ändern, dass das nicht irgendwelchen

01:03:51.926 --> 01:03:54.186
Sachen widerspricht. Weißt du, was ich meine? Ja, natürlich.

01:03:54.366 --> 01:03:59.526
Die Idee von Event-Modeling ist, dass du wirklich Event-Modeling first machst.

01:03:59.666 --> 01:04:05.026
Also wirklich, du arbeitest mit dem Modell und du änderst das Modell als erstes.

01:04:05.026 --> 01:04:07.906
Das Modell ist deine Quelle für deine User-Stories. Ja.

01:04:09.366 --> 01:04:14.666
Genau. Wenn du natürlich initial nur den Workshop machst und dann nichts mehr

01:04:14.666 --> 01:04:17.666
an diesem Modell änderst, sondern dann quasi weitermachst wie bisher,

01:04:17.786 --> 01:04:22.346
ist das auch super, weil du hast jede Menge gelernt, aber dann endet das auch da.

01:04:23.286 --> 01:04:26.186
Also, wenn du mit Event-Modeling arbeitest, wenn du mit dem Modell arbeitest,

01:04:26.246 --> 01:04:27.586
dann musst du auch mit dem Modell arbeiten.

01:04:27.706 --> 01:04:31.306
Es ist wirklich so gedacht, dass du Änderungen immer erst am Modell machst und

01:04:31.306 --> 01:04:34.206
dass sich das Modell im Prinzip immer weiterentwickelt und dass aus dem Modell

01:04:34.206 --> 01:04:37.026
heraus immer deine User-Stories entstehen. Okay.

01:04:38.306 --> 01:04:41.986
Ist was anderes. Ist was anderes. Da muss man sich dran gewöhnen.

01:04:43.126 --> 01:04:47.066
Also ich empfehle immer erst, erstmal den Workshop machen und erstmal jede Menge

01:04:47.066 --> 01:04:50.626
über das System lernen und dann kann man sich überlegen, ist das was,

01:04:50.626 --> 01:04:52.426
womit wir arbeiten können? Funktioniert das für uns?

01:04:53.366 --> 01:04:55.886
Das funktioniert eigentlich überall, aber es ist halt was anderes.

01:04:56.046 --> 01:04:57.386
Man muss auch bereit sein, das zu tun.

01:04:57.766 --> 01:05:01.486
Ja, okay. Aber dann ist ja sozusagen das Outcome, das sich dann am Ende ergibt,

01:05:01.506 --> 01:05:06.246
tatsächlich dann ja doch eine Spezifikation in anderer äußerer Form.

01:05:07.506 --> 01:05:11.426
Du kannst es Spezifikation nennen. Okay, aber es ist dann sozusagen,

01:05:11.586 --> 01:05:18.126
ja, also wir haben dann sozusagen den ganzen Ansatz als Mechanismus zur Findung

01:05:18.126 --> 01:05:21.266
der Spezifikation, zur Findung der gemeinsamen Sprache, zur Findung dessen,

01:05:21.266 --> 01:05:24.046
was normalerweise bei den RLCs immer an erster Stelle steht.

01:05:24.246 --> 01:05:26.766
Unsere ganzen Kernbegriffe meinen dieses, jenes, solches.

01:05:30.146 --> 01:05:31.526
Okay, jetzt habe ich es verstanden.

01:05:34.443 --> 01:05:37.823
Wir haben jetzt unseren Zeitstrahl und wir haben unsere Ereignisse und alle

01:05:37.823 --> 01:05:41.663
Definitionen und ich glaube, wir hatten davor gerade noch den Punkt genannt,

01:05:41.683 --> 01:05:44.503
oder du hattest den Punkt genannt, dass man könnte jetzt sagen,

01:05:44.643 --> 01:05:47.143
jedes so ein Arbeitspaketchen ist dann eine User-Story.

01:05:47.863 --> 01:05:52.183
Was mir jetzt gleich aufgefallen ist, und du hast natürlich auch mehrfach Microservices

01:05:52.183 --> 01:05:55.123
genannt und ich glaube, du hast auch generell sehr viel Erfahrung mit solchen

01:05:55.123 --> 01:06:00.683
Architekturen, mit Microservices, Microfrontends und den ganzen fancy Gedöns.

01:06:01.963 --> 01:06:04.363
Übrigens, ich gehe jetzt aber auch, wenn ich das schon höre,

01:06:04.403 --> 01:06:11.543
automatisch in meinem Kopf passiert das schon, dass ich so quasi Teams pro Arbeitspaket sehe.

01:06:12.603 --> 01:06:17.863
Soll das auch so ein Ziel davon sein, dass ich quasi solche lauter vertikalen

01:06:17.863 --> 01:06:23.563
Teams habe, dann pro Arbeitspaket? Und da kamen deswegen bei mir auch gleich diese Fragen rein.

01:06:23.723 --> 01:06:27.703
Also was passiert denn, wenn ich jetzt eine Änderung an diesem System vornehmen

01:06:27.703 --> 01:06:30.643
möchte, das aber ganz viele von diesen Sachen betrifft.

01:06:30.703 --> 01:06:35.503
Es ist zwar so quasi eine kleine Änderung, aber fast auf jedem Screen muss man

01:06:35.503 --> 01:06:39.203
da was anpassen. Und ich habe jetzt schon gleich diese angstvolle Befürchtung,

01:06:39.243 --> 01:06:44.163
oh Gott, muss ich jetzt 30 Teams fragen, so eine kleine Sache anzupassen?

01:06:44.283 --> 01:06:47.943
Oder passiert es im schlimmsten Fall oder im besten Fall, keine Ahnung,

01:06:47.983 --> 01:06:51.163
dass ich jetzt lauter Vertical Teams habe, aber ich bilde jetzt wieder eine

01:06:51.163 --> 01:06:53.143
horizontale Workforce, damit

01:06:53.143 --> 01:06:56.403
man diese eine Änderung an meinen allen Arbeitspaketen durchführen kann?

01:06:56.403 --> 01:07:01.903
Oder lässt mir das Modell das vollkommen offen und sagt, du kannst danach arbeiten

01:07:01.903 --> 01:07:06.123
in einer Teamaufstellung, wie du möchtest, egal ob vertikale Teams,

01:07:06.223 --> 01:07:10.363
horizontale Teams oder du hast Teams, die sich nicht für Richtungen entscheiden müssen.

01:07:12.226 --> 01:07:14.766
Das bringt uns ganz natürlich zum nächsten Schritt. Wir sind noch nicht ganz

01:07:14.766 --> 01:07:17.766
fertig mit unserem Workshop. Ach so, Entschuldigung. Ich passe wieder auf.

01:07:18.446 --> 01:07:21.686
Was du nämlich machst, ist, also wir haben im Prinzip, funktional ist schon

01:07:21.686 --> 01:07:24.906
alles beschrieben, aber genau der Punkt, den du sagst, wir haben noch nicht

01:07:24.906 --> 01:07:27.626
so genau definiert, wo gehören jetzt eigentlich diese ganzen Funktionsblöcke hin.

01:07:28.766 --> 01:07:33.826
Was du dann machst, ist, du definierst Swimlanes. Und Swimlanes sind im Prinzip,

01:07:34.406 --> 01:07:38.646
man kann es betrachten wie ein Kontext, wie ein Team, wie ein Service.

01:07:39.046 --> 01:07:41.886
Du gruppierst im Prinzip deine Events Unterhalb vom

01:07:41.886 --> 01:08:10.586
Modell.

01:08:10.626 --> 01:08:14.566
Und das ist eigentlich dann eine natürliche Zuordnung. Diese vertikalen Funktionsblöcke,

01:08:14.666 --> 01:08:17.726
die gehören zu diesem Team. Ja, Moment.

01:08:19.166 --> 01:08:21.986
Jetzt komme ich aus einer wieder sehr Frontend-UI-Sicht.

01:08:23.966 --> 01:08:28.306
Und ich weiß nicht, ob ich da das immer so genau gruppiere, sondern ich komme

01:08:28.306 --> 01:08:31.006
hier immer so von den kleinen Base-UI-Components.

01:08:31.506 --> 01:08:36.286
Und ich brauche jetzt zum Beispiel den Dropdown, brauche ich in der Order,

01:08:36.446 --> 01:08:38.366
brauche ich im Checkout, brauche ich beim Login.

01:08:40.066 --> 01:08:46.726
Und das möchte ich ja einheitlich haben über das ganze System und hier,

01:08:47.946 --> 01:08:49.526
wie mache ich das denn jetzt?

01:08:49.746 --> 01:08:54.266
Ich will das ja gar nicht ausblenden. Da bist du ja die Expertin, wie du das machst.

01:08:54.506 --> 01:08:57.206
Also da hast du ja dann typischerweise irgendwie so ein Team,

01:08:57.286 --> 01:08:59.546
was sich um das Design-System kümmert und was einfach definiert,

01:08:59.566 --> 01:09:02.306
wie so ein Dropdown aussieht und wie das alles funktioniert.

01:09:02.686 --> 01:09:07.186
Dass du aber an der Stelle einen Dropdown brauchst, das definiert wieder das Order-Team. Okay.

01:09:08.546 --> 01:09:12.086
Wie bilde ich da so komplett cross-funktionale Geschichten wie irgendwie Security

01:09:12.086 --> 01:09:14.726
ab? Weil die kannst du ja aus nichts raushalten.

01:09:15.854 --> 01:09:20.474
Nee, das machst du, also idealerweise, wenn du die Möglichkeit hast,

01:09:20.554 --> 01:09:21.594
modellierst du es gleich mit rein.

01:09:21.694 --> 01:09:26.074
Also zum Beispiel ist in deinen Events dann einfach der Authorization Key mit

01:09:26.074 --> 01:09:30.394
drin oder der Bearer Token von deinem OAuth, das kannst du ja da alles mit rein modellieren.

01:09:32.414 --> 01:09:47.394
Ja, nee, aber das ist ja eine konkrete Implementierung.

01:10:00.394 --> 01:10:03.654
Der Arbeit. Aber irgendwie so, wir kümmern uns halt eben darum,

01:10:03.714 --> 01:10:08.554
dass wir wollen erreichen, dass Dinge immer ordentlich sanitized sind und dass

01:10:08.554 --> 01:10:10.754
das immer alles mit dem SQL-Query ordentlich ist.

01:10:10.894 --> 01:10:14.194
Also, das will man ja auch, aber das kann ich ja nicht in einen Funktionsblock

01:10:14.194 --> 01:10:15.094
in eine User-Story einbauen.

01:10:15.814 --> 01:10:19.894
Das kannst du aber im Modell abbilden, indem du beispielsweise das Passwort,

01:10:20.654 --> 01:10:23.114
gehasht anzeigst im Event, was im System gespeichert wird.

01:10:23.214 --> 01:10:27.594
Und dann sieht auch der CTO, aha, schau mal daher, unsere Passwörter werden

01:10:27.594 --> 01:10:30.734
nicht plaintext gespeichert, sondern wir machen das gehasht, so wie sie es gehört.

01:10:32.914 --> 01:10:36.594
Und da ist es dann auch egal, ob das jetzt das Ereignis ist oder ob das die

01:10:36.594 --> 01:10:39.734
Datenbank Column ist, die du unten anzeigst.

01:10:40.514 --> 01:10:43.334
Der CTR erkennt, dass es gehasht. Wunderbar. Ziel erreicht.

01:10:43.634 --> 01:10:46.094
Okay, Passwort wird gehasht und der ganze andere Krempel auch.

01:10:46.154 --> 01:10:46.814
Aber ich meine, das geht ja wirklich,

01:10:46.894 --> 01:10:49.294
wenn du jetzt zum Beispiel an so Cross-Site-Scripting-Geschichten

01:10:49.294 --> 01:10:53.074
gehst, du musst ja dann sozusagen wirklich bei allem, was irgendwie angezeigt

01:10:53.074 --> 01:10:56.094
wird, bei allem, was irgendwie eingegeben wird, irgendwie einen Filterschritt machen.

01:10:56.894 --> 01:11:00.554
Den baust du ja nicht überall da ein, oder? Du sagst ja nicht bei jedem User-Input,

01:11:00.654 --> 01:11:02.794
das wird durch die Filter durchgezogen.

01:11:02.994 --> 01:11:06.994
Nein, das ist, was du ja modellierst im Modell, ist im Prinzip alles,

01:11:07.214 --> 01:11:10.954
was irgendwie eine Änderung in deinem Systemstatus verursacht.

01:11:11.154 --> 01:11:14.414
Ein Cross-Site-Scripting-Filter ändert nichts an deinem System, der ist einfach da.

01:11:14.554 --> 01:11:19.534
Also das würde man einfach, das ist quasi dann wirklich außerhalb vom Modell.

01:11:19.674 --> 01:11:20.674
Ja, aber wenn der nicht da ist, dann

01:11:20.674 --> 01:11:23.374
ändert das ja sehr wohl was an deinem Systemstatus. Und zwar nichts Gutes.

01:11:24.974 --> 01:11:29.474
Ja, nicht wirklich. Du kannst festlegen, Eingaben bei uns werden über einen

01:11:29.474 --> 01:11:31.974
Cross-Site-Scripting-Filter gefiltert.

01:11:32.754 --> 01:11:36.454
Ist einfach da. Das ist aber nichts, was du im Modell modellieren musst,

01:11:36.534 --> 01:11:39.534
weil das ist einfach quasi eine Annahme. Genauso wie du sagst, wir loggen.

01:11:40.494 --> 01:11:42.534
Loggen würdest du nicht im Modell modellieren, weil das ändert nichts.

01:11:42.674 --> 01:11:44.694
Das machst du einfach. Weißt du, was ich meine?

01:11:45.374 --> 01:11:49.714
Ja, ich weiß, was du meinst, aber meine Erfahrung sagt mir, das machst du einfach,

01:11:49.874 --> 01:11:51.934
da sind sich alle drüber einig und passieren tut es dann trotzdem nicht.

01:11:53.961 --> 01:11:57.481
Das kann natürlich passieren. Wenn wir jetzt schon sagen, Softwareentwicklung

01:11:57.481 --> 01:12:02.081
läuft so mittelgut, dann ist das ja nicht nur so, dass die Entwicklerinnen und

01:12:02.081 --> 01:12:03.521
Entwickler hinterher sagen,

01:12:03.701 --> 01:12:05.921
oh meine Güte, das ist aber ein Haufen Legacy-Code, das ist gar nicht so schön,

01:12:06.001 --> 01:12:08.381
sondern ist ja tatsächlich auch irgendwie so was wie, hey Peter,

01:12:08.441 --> 01:12:09.461
was hältst du von unserem Frontend?

01:12:09.641 --> 01:12:12.921
Und ich probiere einfach mal den offensichtlichsten Security-Kniff und bin dann

01:12:12.921 --> 01:12:14.481
sofort drin und irgendwie alles ist im Eimer.

01:12:15.441 --> 01:12:18.981
Das ist ja auch Teil des Problems.

01:12:20.221 --> 01:12:25.461
Was du du im letzten Schritt des Workshops machst es, du definierst Policies.

01:12:25.941 --> 01:12:30.941
Also das sind genau im Prinzip die Fälle, die du abbilden möchtest.

01:12:31.061 --> 01:12:36.241
Und du könntest beispielsweise eine Policy definieren, also die Policies definierst

01:12:36.241 --> 01:12:41.321
du im Prinzip unterhalb vom Modell und du schreibst ein Event hin und du könntest

01:12:41.321 --> 01:12:41.961
da ein Event hinschreiben,

01:12:42.001 --> 01:12:46.701
was einfach invalide Daten hat und du könntest dann das Command mit diesen invaliden

01:12:46.701 --> 01:12:50.881
Daten abbilden und könntest dann aber in der Policy definieren,

01:12:50.921 --> 01:12:53.581
in diesem Fall laufen wir in einen Fehler. Das darf nicht passieren.

01:12:54.961 --> 01:12:58.481
Also du würdest nicht modellieren, wir haben einen Cross-Site-Scripting-Filter,

01:12:58.481 --> 01:13:01.021
sondern du würdest modellieren, wenn diese Daten ins System kommen,

01:13:01.101 --> 01:13:01.601
dann haben wir einen Fehler.

01:13:02.981 --> 01:13:06.901
Und dafür könntest du beispielsweise einen Test schreiben. Für diese Policies

01:13:06.901 --> 01:13:08.001
hast du typischerweise Tests.

01:13:10.607 --> 01:13:13.587
Okay, das sind dann sozusagen konkrete Ausprägungen von dem,

01:13:13.607 --> 01:13:17.807
was ich gerade so als Werte bezeichnet habe, von wegen unser Produkt ist gefiltert. Genau.

01:13:18.647 --> 01:13:22.227
Beispiel zum Beispiel E-Commerce, du hast einen Warenkorb und du darfst nur

01:13:22.227 --> 01:13:23.447
drei Produkte in den Warenkorb legen.

01:13:23.527 --> 01:13:26.847
Wenn du jetzt dreimal ein Produkt in den Warenkorb gelegt Ereignis hast und

01:13:26.847 --> 01:13:29.387
du kriegst ein weiteres Command, bitte Produkt in den Warenkorb legen,

01:13:29.527 --> 01:13:30.607
hast du auch einen Fehler.

01:13:30.947 --> 01:13:34.927
Also wirklich Business Rules, die du im System abbildest, die würdest du im

01:13:34.927 --> 01:13:37.787
Prinzip im letzten Schritt im Workshop genau so modellieren.

01:13:37.967 --> 01:13:40.427
Und zwar unterhalb von jedem Funktionsblock.

01:13:42.327 --> 01:13:45.667
Dann hast du einmal nämlich die Funktion selber und du hast alle Sonderfälle

01:13:45.667 --> 01:13:49.227
modelliert und im Prinzip siehst du dann genau, okay, das ist mein System,

01:13:49.387 --> 01:13:52.507
so funktioniert es. Okay.

01:13:54.767 --> 01:13:59.307
Apropos Legacy. Mal ein Schritt zur Realität jetzt hierzu.

01:13:59.587 --> 01:14:04.027
Es ist ja jetzt vermutlich nicht der Normalfall, dass wir jetzt,

01:14:04.047 --> 01:14:07.707
wir kennen jetzt Event-Modelling und jetzt gründen wir eine Firma und machen ein neues System.

01:14:08.507 --> 01:14:12.187
Sondern vermutlich kommt man ja irgendwann in dieses Problem,

01:14:12.367 --> 01:14:15.367
dass man sagt, oh, jetzt ist das ein bisschen groß geworden.

01:14:16.287 --> 01:14:20.247
Jetzt brauchen wir mal einen neuen Prozess. Und dann stolpern wir über Event Modeling.

01:14:21.007 --> 01:14:25.687
Und jetzt habe ich mein halbes System schon. Die Hälfte, wie das funktioniert,

01:14:26.387 --> 01:14:28.927
wissen nur noch die Leute, die nicht mehr da sind.

01:14:29.287 --> 01:14:32.007
Und die andere Hälfte ist dürftig dokumentiert.

01:14:32.627 --> 01:14:36.347
Wie mache ich denn nachträglich Event Modeling? Ich gehe jetzt einfach mal davon

01:14:36.347 --> 01:14:38.267
aus, dass das auch nachträglich irgendwie gehen muss.

01:14:39.207 --> 01:14:42.127
Zufälligerweise habe ich heute Morgen einen Artikel veröffentlicht,

01:14:42.187 --> 01:14:44.987
der heißt Legacy-Systeme modellieren mit Event-Modelling.

01:14:46.127 --> 01:14:51.427
Also genau, natürlich geht das und was du dann machst ist, typischerweise hast

01:14:51.427 --> 01:14:54.967
du in Bestandssystemen, nennen wir es nicht mal Legacy-Systeme,

01:14:54.967 --> 01:15:00.007
in Bestandssystemen hast du irgendwelche Tabellen, wo die Daten abgebildet sind.

01:15:00.927 --> 01:15:06.127
Statt die Ereignisse im System zu modellieren, modellierst du einfach direkt

01:15:06.127 --> 01:15:07.987
auf die einzelnen Spalten in deiner Tabelle.

01:15:10.058 --> 01:15:12.718
Also du hast immer noch deine Screens, du hast immer noch deine Commands,

01:15:13.198 --> 01:15:16.058
statt aber die Ereignisse zu modellieren, nimmst du einfach deine Tabellen,

01:15:16.058 --> 01:15:20.798
so wie sie sind und modellierst einfach, wie kommen die Daten aus deiner UI

01:15:20.798 --> 01:15:22.798
dann jetzt schlussendlich in deine Tabellen rein?

01:15:23.198 --> 01:15:26.078
Und wie kommen die Daten aus der Tabelle zum nächsten Screen?

01:15:27.818 --> 01:15:31.538
Mache ich das erstmal einfach nur mit Ist-Zustand? Du würdest den Ist-Zustand

01:15:31.538 --> 01:15:32.558
modellieren, genau. Das ist im

01:15:32.558 --> 01:15:35.658
Prinzip, was du da machst, ist erstmal die Dokumentation für dein System.

01:15:36.898 --> 01:15:41.318
Super wertvoll, also allein das ist super wertvoll. Und dann kannst du das natürlich

01:15:41.318 --> 01:15:44.898
verwenden, um die Weiterentwicklung zu steuern.

01:15:45.698 --> 01:15:48.718
Was sind die Funktionsblöcke, die wir haben? Brauchen wir neue Funktionsblöcke?

01:15:48.798 --> 01:15:50.518
Was ändert sich? Wo muss man was anpassen?

01:15:51.718 --> 01:15:52.638
Funktioniert ganz wunderbar.

01:15:54.178 --> 01:15:57.578
Jetzt so mal aus dem Startup rausgetrieben. Ich glaube, eine Sorge,

01:15:57.578 --> 01:15:58.838
die dabei herrschen würde,

01:15:59.018 --> 01:16:02.378
ich glaube dir zwar, und da bin ich ja immer auf deiner Seite,

01:16:02.498 --> 01:16:07.278
ich denke, das ist weniger Zeit, was sowas kostet, als vor allem im Hinblick,

01:16:07.338 --> 01:16:09.178
was da ja für Nutzen dabei rauskommen kann.

01:16:10.078 --> 01:16:12.958
Aber das Argument, das mir jetzt sofort schon im Kopf schwirrt,

01:16:12.958 --> 01:16:17.418
ist, wenn ich jetzt vor allem mit Screens arbeite, das ist ja alles änderbar,

01:16:17.638 --> 01:16:21.538
das Design wird oft angepasst, weil sich die Features so schnell weiterentwickeln.

01:16:21.998 --> 01:16:26.398
Lohnt sich das denn überhaupt, das zu dokumentieren, wenn wir in zwei Wochen

01:16:26.398 --> 01:16:30.338
später das sowieso schon wieder einen ganz anderen Screen haben, der anders aussieht?

01:16:32.293 --> 01:16:34.793
Ich stelle die Frage mal andersrum. Was ist denn die Alternative dazu?

01:16:35.893 --> 01:16:37.813
Durchwurschteln. Läuft schon.

01:16:38.813 --> 01:16:43.133
Du kannst es durchwurschteln. Das ist auch völlig okay. Das Problem ist nur,

01:16:44.233 --> 01:16:47.153
früher oder später wirst du das System wegschmeißen müssen. Das passiert immer.

01:16:50.273 --> 01:16:53.533
Durchwurschteln ist völlig in Ordnung. Und wenn du sagst, du bist noch in dieser

01:16:53.533 --> 01:16:56.993
Phase, wo Wurschteln dein Ziel ist, ist das auch völlig okay.

01:16:57.093 --> 01:16:58.393
Da würde ich nicht mehr die Event-Modeling arbeiten.

01:16:59.753 --> 01:17:03.573
Wenn du wirklich wurschteln willst. willst, aber meistens ist es halt doch meistens

01:17:03.573 --> 01:17:08.453
eine gute Idee, weil du hast eigentlich keinen Zeitaufwand oder wenig Zeitaufwand

01:17:08.453 --> 01:17:12.493
und du modellierst dein System so, dass du es hinterher halt nicht mehr wegwirfst.

01:17:14.293 --> 01:17:17.633
Ja, ich habe meistens, ich habe ja, wie gesagt, ich bin normalerweise nicht

01:17:17.633 --> 01:17:20.413
die Person, die das argumentiert, weil ich genau schon immer,

01:17:20.453 --> 01:17:23.733
wenn ich das höre, wie in zwei Wochen schaut es bestimmt eh schon wieder anders

01:17:23.733 --> 01:17:27.033
aus, entspricht normalerweise wirklich nicht meiner Realität. geht.

01:17:27.793 --> 01:17:32.633
Das werde ich auch bei jedem Merch beziehungsweise Pull-Request immer anmerken,

01:17:32.673 --> 01:17:37.413
wenn ich da schon im Code lese, so, ja, da ist jetzt so ein To-Do,

01:17:37.513 --> 01:17:39.973
aber in zwei Wochen wollen wir das nochmal anfassen, sage ich, nee,

01:17:40.973 --> 01:17:43.653
das passiert doch sowieso nicht, das ist für das nächste Jahr,

01:17:43.653 --> 01:17:47.133
es bleibt das, der gleiche Screen, weil wir haben sowieso neue Features am Arbeiten.

01:17:47.353 --> 01:17:50.493
Von daher zumindest in meiner Realität ist es immer so ein Mythos,

01:17:50.513 --> 01:17:54.473
dass sich die Sachen wirklich so schnell anpassen, dass man sie nicht dokumentieren

01:17:54.473 --> 01:17:56.373
müsste, weil es so viel mehr Aufwand wäre.

01:17:58.093 --> 01:18:03.453
Aber gut, ich habe jetzt mein Bestandssystem und damit ich das eben nicht wegschmeißen

01:18:03.453 --> 01:18:07.933
muss, irgendwann mal gehe ich da mit Event-Modeling her und mache meinen Ist-Zustand.

01:18:09.013 --> 01:18:13.053
Was passiert denn jetzt, wenn ich dabei auch, ich habe ja irgendein Ziel,

01:18:13.213 --> 01:18:15.853
das ich jetzt verfolge, was ist denn das Ziel jetzt bei dem Bestandssystem,

01:18:15.893 --> 01:18:18.993
das zu haben, außer dass ich die Dokumentation über den Ist-Zustand habe?

01:18:19.333 --> 01:18:23.733
Ist es einerseits, möchte ich zum Beispiel Lücken haben,

01:18:24.687 --> 01:18:28.447
die ich zum Beispiel im Bestandssystem habe, um die dann aufzufüllen?

01:18:29.407 --> 01:18:33.187
Oder ist es auch einfach nur, weil ich es eben mit Features erweitern möchte?

01:18:33.807 --> 01:18:37.707
Also erstmal ist es Dokumentation, die du haben möchtest. Denn ich weiß nicht,

01:18:37.747 --> 01:18:41.847
wie es dir geht, aber ich habe bisher selten Software-Systeme gesehen,

01:18:41.947 --> 01:18:42.947
die gut dokumentiert sind.

01:18:43.267 --> 01:18:47.827
Und mit so einem Event-Modell hast du natürlich eine perfekte Dokumentation.

01:18:48.327 --> 01:18:52.407
Das ist für ein Onboarding das Beste, was du jemandem geben kannst.

01:18:52.407 --> 01:18:56.067
Du willst wissen, wie unser System funktioniert, fang links an und hör rechts

01:18:56.067 --> 01:18:58.387
auf und du hast alles gesehen. Was Besseres gibt es nicht.

01:18:58.827 --> 01:19:02.107
Gute Zwischenfrage. Du hast Miro jetzt hin und wieder erwähnt.

01:19:02.127 --> 01:19:06.287
Ist Miro dann für dich da auch so ein gutes Tool oder ist das so ein Zwischenstuhl,

01:19:06.807 --> 01:19:10.567
um das dann in einen, wie heißt das, Conference oder sowas, dieses große Tier-Ding?

01:19:10.807 --> 01:19:17.227
Also tatsächlich, wir arbeiten Miro first und wir arbeiten auch quasi an Tools,

01:19:17.367 --> 01:19:21.207
um beispielsweise Code aus Miro heraus zu generieren. Also Miro ist das Tool, mit dem wir arbeiten.

01:19:23.427 --> 01:19:28.687
Aber da sind die Screens mit drin. Ja. Wie veraltet dürfen die denn sein?

01:19:28.947 --> 01:19:31.987
Denn was sich vielleicht nicht so wirklich oft updatet, meiner eigenen Meinung

01:19:31.987 --> 01:19:35.687
nach, ist wirklich die UI und es dauert eh alles viel zu lange zu implementieren mit der ganzen UI.

01:19:36.227 --> 01:19:40.027
Aber Texte und sowas können sich ja schon wirklich häufig updaten. Genau.

01:19:40.407 --> 01:19:45.487
Texte würde ich im Miro-Board jetzt nicht eins zu eins schreiben.

01:19:45.567 --> 01:19:47.967
Ich würde einen Text so schreiben, dass man erkennt, was gemeint ist,

01:19:48.047 --> 01:19:52.287
aber jetzt nicht wortwörtlich, weil das kriegst du im Miro nicht abgebildet.

01:19:52.407 --> 01:19:55.627
Also es muss nicht so genau sein. Man muss ja erkennen, was das Text ist.

01:19:56.027 --> 01:19:59.507
Die du in Miro hast, dann was für Screens meinst du denn dabei?

01:19:59.607 --> 01:20:02.587
Ich habe jetzt gerade fast an Screenshots gedacht bei dem Bestandssystem,

01:20:02.687 --> 01:20:04.367
dass sie einfach ein Screenshot von der Webseite nehmen.

01:20:04.567 --> 01:20:08.267
Auch das ist natürlich möglich, dass du Screenshots nimmst oder du nimmst eben,

01:20:08.327 --> 01:20:13.307
wie gesagt, Figma-Screens oder du zeichnest einfach Screens selber mit dem Budget-Tool in Miro.

01:20:15.406 --> 01:20:20.466
Es ist wirklich da nicht so genau, aber jetzt gerade Bestandssysteme,

01:20:20.466 --> 01:20:22.386
wenn du Screenshots hast, wunderbar.

01:20:24.006 --> 01:20:26.226
Jetzt haben wir immer ganz viele Fragen zwischen reingestellt.

01:20:27.626 --> 01:20:31.646
Wir haben doch bestimmt noch solche abschließenden Punkte, die wir jetzt gerade übersprungen haben.

01:20:31.966 --> 01:20:34.686
Tatsächlich sind wir jetzt am Ende von unserem Workshop angekommen.

01:20:34.786 --> 01:20:38.006
Also wenn wir das alles gemacht haben, wir haben die Events definiert,

01:20:38.026 --> 01:20:40.086
wir haben die Commands definiert, wir haben die Screens definiert,

01:20:40.146 --> 01:20:42.306
wir haben die Read Models definiert,

01:20:42.406 --> 01:20:46.606
wir haben alles in die richtige Reihenfolge gebracht, Wir haben die Policies

01:20:46.606 --> 01:20:51.586
definiert und im Prinzip haben wir jetzt unser System in der Reihenfolge,

01:20:51.586 --> 01:20:52.666
in der die Dinge passieren.

01:20:53.146 --> 01:21:00.206
Das ist der Outcome von unserem Workshop. Und wie du dann quasi mit dem Modell

01:21:00.206 --> 01:21:03.646
in die Implementierung gehst, das ist dann nochmal eine andere Geschichte.

01:21:04.746 --> 01:21:09.426
Das Modell eignet sich ganz hervorragend, wirklich ganz hervorragend für eventbasierte Systeme.

01:21:10.006 --> 01:21:14.346
In eventbasierten Systemen kannst du das Eventmodell eins zu eins im Code abbilden.

01:21:15.346 --> 01:21:18.146
Aber auch für normale CRUD-Systeme funktioniert das.

01:21:19.026 --> 01:21:23.406
Also das ist dann wirklich, da muss man dann mit den Teams einfach quasi nach

01:21:23.406 --> 01:21:25.946
dem Workshop sich hinsetzen und sich überlegen, okay, wie macht man denn von

01:21:25.946 --> 01:21:27.986
hier aus weiter? Wie wollt ihr damit arbeiten?

01:21:29.246 --> 01:21:34.146
Dieses System kann ja jetzt sehr groß sein. Und wir haben ja schon häufiger

01:21:34.146 --> 01:21:35.726
das Wort agil verwendet.

01:21:36.606 --> 01:21:40.866
Komme ich denn von meinem Zeitstrahl, den ich da jetzt hingezeichnet habe,

01:21:40.926 --> 01:21:46.706
komme ich da dann auch zu kleineren Zeitstrählen, die ich jetzt nacheinander implementieren kann?

01:21:46.706 --> 01:21:49.686
Weil zum Beispiel unser Feedback-Zyklus, da wissen wir ganz genau,

01:21:49.766 --> 01:21:52.886
da gibt es ein Peer-Feedback und die Peers müssen sich nominieren und wieder

01:21:52.886 --> 01:21:56.826
abnominieren können und Manager müssen dazustimmen und nicht zustimmen.

01:21:57.006 --> 01:22:01.486
Aber wenn wir das alles auf einmal implementieren, dann sind wir ein halbes

01:22:01.486 --> 01:22:04.586
Jahr, sind wir alle in unserem Zimmerchen und dann sieht man uns wieder.

01:22:04.586 --> 01:22:07.766
Ja, so funktioniert es ja in der Realität nicht so oft, sondern ich möchte ja

01:22:07.766 --> 01:22:10.426
eigentlich immer so das Minimum-Value-Product-Dingsbums-MVP,

01:22:10.586 --> 01:22:15.846
MVC, naja, keine Ahnung, wird spät, an die User shippen und schon mal auch Feedback

01:22:15.846 --> 01:22:19.966
generieren, weil jeder Value ist ja besser als kein Value erstmal und vor allem

01:22:19.966 --> 01:22:22.466
so kleine Produktideen sind dann auch bugfrei,

01:22:22.946 --> 01:22:27.566
was vielleicht besser ist als die Eier legende Wollmilchsau am Anfang schon zu deliveren.

01:22:28.806 --> 01:22:32.206
So, aber ich weiß quasi, ich brauche auch ein Peer-Feedback,

01:22:32.406 --> 01:22:35.746
aber ich möchte damit nicht anfangen. Ich möchte erst was Kleineres rausbringen.

01:22:36.486 --> 01:22:40.986
Erlaubt es das System soweit denn? Ist es überhaupt dafür da? Klar. Du.

01:22:41.706 --> 01:22:46.686
Also erst mal, was du hier machst, ist, du modellierst das komplette System nach Möglichkeit.

01:22:47.726 --> 01:22:49.766
Aber das heißt ja noch lange nicht, dass du alles umsetzen musst.

01:22:50.346 --> 01:22:53.726
Du kannst ja genau diese vertikalen Funktionsblöcke rauspicken,

01:22:54.506 --> 01:22:58.686
die den meisten Value für deine User liefert.

01:22:59.466 --> 01:23:02.626
Ich muss quasi immer nur schauen, dass ich die richtigen Werte dann auch zur

01:23:02.626 --> 01:23:04.506
Verfügung habe. Das weißt du aber.

01:23:04.686 --> 01:23:09.066
Du weißt genau, welche vertikalen Funktionsblöcke du bauen kannst und welche

01:23:09.066 --> 01:23:11.686
quasi die Vorbedingungen sind, weil du genau an den Daten erkennst,

01:23:11.746 --> 01:23:14.586
was brauchst du. Weißt du, 100%.

01:23:17.756 --> 01:23:22.596
Okay, ich hätte noch eine Frage für das gesamte Erstaufziehen des Systems.

01:23:22.756 --> 01:23:28.256
Und zwar, die meisten Systeme sind ja tatsächlich so ereignisbasiert.

01:23:28.256 --> 01:23:30.496
Ist ja gerade bei so Frontend-Krempel ganz klar.

01:23:30.536 --> 01:23:33.156
Ich klicke Button, Dinge passieren. Oder ich will Dinge erreichen, Dinge passieren.

01:23:33.856 --> 01:23:38.476
Wie baue ich da in mein eventbasiertes System irgendwelche Constraints ein,

01:23:38.576 --> 01:23:40.136
die nicht eventbasiert sind?

01:23:42.376 --> 01:23:44.896
Politikmäßiges Zeug zum Beispiel. Das ist die, keine Ahnung,

01:23:45.016 --> 01:23:48.676
du bist die Bahn-Webseite und die versuchen dir bei jeder Gelegenheit noch einen

01:23:48.676 --> 01:23:51.016
Mietwagen überzuhelfen, obwohl das das Letzte ist, was du möchtest.

01:23:51.716 --> 01:23:55.696
Aber das tun die ja und das wollen die ja. Und du hast ja in diesem Laden Mächte

01:23:55.696 --> 01:23:59.496
am Werk, die das auch so umgesetzt sehen wollen.

01:24:00.496 --> 01:24:04.196
Und du musst das ja immer irgendwie berücksichtigen, dass halt dieses permanente

01:24:04.196 --> 01:24:06.836
Upselling irgendwie passiert. Weil wenn du das nicht berücksichtigst,

01:24:06.836 --> 01:24:08.116
hast du halt irgendwie nicht die Leute an Bord.

01:24:08.976 --> 01:24:10.996
Also das ist ja was, das muss ja auch irgendwie da drin sein,

01:24:11.036 --> 01:24:12.256
aber das ist ja nicht irgendwie jetzt,

01:24:13.876 --> 01:24:16.656
streng genommen ereignisbedingt, Es sei denn, du baust halt einfach so ein,

01:24:16.736 --> 01:24:20.736
ich komme auf die Webseite und ich kriege halt einfach in meiner User-Story

01:24:20.736 --> 01:24:25.156
in Anführungszeichen jederzeit dieses Upselling irgendwie noch reingewirkt.

01:24:25.856 --> 01:24:26.916
Wäre das so der Ansatz?

01:24:29.256 --> 01:24:32.896
Alles ist ereignisbasiert. Die Frage ist, was triggert denn denn Upselling?

01:24:33.056 --> 01:24:35.796
Irgendwas muss das ja triggern. Ist das nur der Page-Load oder wann passiert das?

01:24:36.476 --> 01:24:39.556
Es muss halt auch wieder überall drin sein. Also ich muss ja in jedem Screen

01:24:39.556 --> 01:24:42.056
irgendwie drin haben und wenn du noch einen Mietwagen haben willst, da ist einer.

01:24:45.276 --> 01:24:48.376
Und das ist aber nicht Teil des Systems in deinem Szenario?

01:24:48.436 --> 01:24:51.696
Es ist ja Teil des Systems, aber es ist ja tatsächlich nur sozusagen eine,

01:24:51.776 --> 01:24:56.196
sagen wir mal, Komplikation, die wieder so ähnlich wie mein Not-Safe-for-Work-Filter

01:24:56.196 --> 01:24:57.356
in allem irgendwie drin ist.

01:25:00.136 --> 01:25:03.316
Und ja im Prinzip einfach überall immer so mit gemeint werden muss,

01:25:03.416 --> 01:25:06.496
dass du sozusagen nicht nur die Gewerke hast, von wegen Design hier,

01:25:06.516 --> 01:25:10.376
Technik da, sondern halt irgendwie sozusagen auch noch die, ja,

01:25:10.476 --> 01:25:13.396
in so einem Konzern wäre das halt wirklich ein Geschäftsbereich oder so.

01:25:13.396 --> 01:25:16.636
So, dass halt irgendwie die Mietwagenabteilung sich halt eben auch da überall

01:25:16.636 --> 01:25:17.776
drin wiederfinden will.

01:25:17.876 --> 01:25:20.736
Also ich komme, glaube ich, immer zu so einem Skalierungsding zurück,

01:25:20.916 --> 01:25:25.436
weißt du, wo ich halt irgendwie so denke, so 50, 100 Leute in einem Raum,

01:25:25.516 --> 01:25:28.516
das ist ja super, aber was ist, wenn du wirklich der Konzern bist und du bist

01:25:28.516 --> 01:25:32.516
die Konzernwebseite und alle müssen da irgendwie mit rein und so ein Ding,

01:25:32.516 --> 01:25:35.616
wie halt eben eine Bahnreise buchen wird, halt durch so Dinge wie irgendwie,

01:25:35.756 --> 01:25:39.216
es geht über die Grenze und du fährst irgendwie von Paris über Deutschland nach

01:25:39.216 --> 01:25:42.456
Wien und am Ende kriegst du noch einen Mietwagen übergehörfen und die Hälfte

01:25:42.456 --> 01:25:43.516
von deinem Ticket bezahlst du mit,

01:25:43.976 --> 01:25:46.116
Bonuspunkten, aber du hast halt nur eine Rabattkarte für Österreich.

01:25:49.096 --> 01:25:52.016
Aber das sind ja alles Constraints, die du im System abbilden kannst.

01:25:52.096 --> 01:25:56.976
Also auch ein Upselling ist ja immer irgendetwas, was du entweder als User akzeptieren

01:25:56.976 --> 01:26:00.916
musst oder nicht oder du ignorierst es einfach, aber es ist ja immer irgendwie

01:26:00.916 --> 01:26:03.616
im System abgebildet und kann deswegen natürlich auch modelliert werden.

01:26:04.676 --> 01:26:08.736
Ja klar, aber ist die Wand groß genug? Habe ich genug Post-its dafür?

01:26:09.716 --> 01:26:14.976
Das ist die Frage. Also das System kann natürlich beliebig groß werden und dann

01:26:14.976 --> 01:26:17.656
würde man mit einem Teil des Systems halt anfangen.

01:26:17.756 --> 01:26:20.216
Du würdest jetzt nicht die Bahn-Webseite auf eine Wand malen.

01:26:20.236 --> 01:26:22.456
Das funktioniert nicht. Ja, aber vielleicht die Startseite.

01:26:26.236 --> 01:26:30.616
Also du kannst es probieren, aber du kannst nur das modellieren,

01:26:30.656 --> 01:26:31.336
was halt auch funktioniert.

01:26:31.596 --> 01:26:36.196
Also du kannst nicht beliebig große Systeme so modellieren. Nee, nee, klar.

01:26:36.936 --> 01:26:40.456
Aber du hast halt eben Systeme von Systemen und Subsystemen und hast die nicht gesehen.

01:26:41.236 --> 01:26:43.776
Und die sind dann wieder miteinander verbunden irgendwie.

01:26:44.796 --> 01:26:47.256
Okay, aber hast du dann nicht eine zweite Codebase geschaffen?

01:26:49.256 --> 01:26:52.836
Du kannst ja, also wenn du sagst, du modellierst ein System,

01:26:53.016 --> 01:26:55.216
heißt das ja nicht, dass das eine Codebase ist. Auf gar keinen Fall.

01:26:55.476 --> 01:26:57.196
Nee, nee, nee, das meine ich auch gar nicht. Sondern ich meine jetzt mehr so,

01:26:57.276 --> 01:27:01.496
ich baue ein kompliziertes Ding, wie zum Beispiel den Buchungsprozess für einer Bahn.

01:27:02.776 --> 01:27:05.616
Und das irgendwie in Code zu gießen, ist halt unglaublich kompliziert und schwierig

01:27:05.616 --> 01:27:09.696
und deswegen baue ich das System mit dem Event-Modeling, spiele das Ganze durch,

01:27:09.796 --> 01:27:11.756
pflege die Systeme weiter, wie wir das alles besprochen haben.

01:27:12.996 --> 01:27:17.936
Aber sozusagen, dann ist es ja mehr oder minder eine Spezifikation.

01:27:17.936 --> 01:27:21.976
Eine Spezifikation ist ja auch nichts weiter als in Prosa gegossene,

01:27:21.996 --> 01:27:25.116
letztlich Abfolgen von Zeug, also Quasicode.

01:27:25.896 --> 01:27:27.456
Habe ich dann nicht mein System zweimal gebaut?

01:27:32.836 --> 01:27:35.256
Du meinst halt, dass du einmal im Modell hast und einmal im Code.

01:27:36.116 --> 01:27:41.096
Ja, und ich halt eben das Ding mal zwei habe, plus halt eben dafür sorgen muss,

01:27:41.136 --> 01:27:44.556
dass die beiden halt eben synchronisiert sind. Richtig.

01:27:45.036 --> 01:27:47.776
Und halt eben mehr oder minder halt eben auch sozusagen global,

01:27:48.756 --> 01:27:53.936
jetzt nicht permanent, aber halt irgendwie effektiv es ja für jeden jederzeit möglich sein muss,

01:27:54.636 --> 01:27:58.456
im Prinzip die, keine Ahnung, CTO-Perspektive einzunehmen und ganz raus zu zoomen

01:27:58.456 --> 01:28:03.156
oder halt eben auch die Security-Nerd-Perspektive einzunehmen und ganz runter zu zoomen. Natürlich.

01:28:04.316 --> 01:28:07.996
Das ist auch so. Aber das hast du heute auch. Du hast es heute auch zwar...

01:28:07.996 --> 01:28:10.776
Das ist ja in Figma und auf der Webseite heute eh schon so.

01:28:10.976 --> 01:28:16.136
Das ist auch sowas, mit dem ich oft konfrontiert werde, wie muss man das jetzt

01:28:16.136 --> 01:28:19.556
auf Figma updaten, weil auf der Webseite ist es hier eh schon die Single Source

01:28:19.556 --> 01:28:21.856
of Truth und die Webseite muss ja die Single Source of Truth sein,

01:28:21.916 --> 01:28:24.936
weil nur das ist ja das, was die User im Endeffekt bekommen.

01:28:26.016 --> 01:28:30.836
Allerdings ist für mich halt die geschriebene Codebase eben nicht dieses Storytelling,

01:28:30.916 --> 01:28:32.716
das ich brauche, um das Produkt zu verstehen.

01:28:33.596 --> 01:28:37.756
Ich glaube, das wird teilweise auch ganz schön überschätzt, was wir im Code

01:28:37.756 --> 01:28:39.536
alles teilweise rauslesen können.

01:28:39.676 --> 01:28:44.656
Ich kann im Code nicht rauslesen so genau, keine Ahnung, Beispiel,

01:28:44.816 --> 01:28:48.276
wie die Feature-Switches genau miteinander funktionieren, wenn es zum Beispiel

01:28:48.276 --> 01:28:51.836
so übergreifende Feature-Switches gibt, die mehrere Sachen auf einmal an- und

01:28:51.836 --> 01:28:53.136
austockeln oder ähnliches.

01:28:53.236 --> 01:28:57.396
Da ist natürlich im Endeffekt, was die User bekommen werden,

01:28:57.576 --> 01:28:59.436
ist in der Codebase drin und nicht auf Figma.

01:29:00.076 --> 01:29:05.056
Aber es ist im Code nicht einfach lesbar. Das brauche ich irgendwo modelliert.

01:29:05.596 --> 01:29:10.496
Ja, stell dir vor, du hast einfach einen Flag an deinem Kunden. Prospect, true, false.

01:29:11.176 --> 01:29:14.896
Aus dem Code liest du nicht raus, was macht dieses Flag, wo kommt es her?

01:29:14.996 --> 01:29:18.476
Im Event-Modell siehst du genau, okay, das wird 17 Schritte weiter vorne wird

01:29:18.476 --> 01:29:20.276
das gesetzt und es kommt aus diesem System. Aha.

01:29:22.476 --> 01:29:25.696
Und du hast es auch heute. Du hast heute auch alles doppelt,

01:29:25.696 --> 01:29:29.096
nur hast du das in hunderte User-Stories aufgeteilt, in geschriebenem Text.

01:29:30.076 --> 01:29:31.056
Das ist genau das Gleiche.

01:29:34.436 --> 01:29:38.496
Also ein bisschen kam ja auch daher meine Frage vorher, lohnt sich das überhaupt

01:29:38.496 --> 01:29:40.676
mit den Screens, die sich hier doch immer wieder ändern?

01:29:42.576 --> 01:29:47.416
Das ist wahrscheinlich eine Frage, die die gesamte Dokumentation dieser Welt betrifft.

01:29:47.436 --> 01:29:52.156
Lohnt sich das, das da nebenbei aufzuschreiben? Weil es könnte sich ja ändern.

01:29:53.576 --> 01:29:57.156
Ja, also das Ding ist halt eben, es ist ja am Ende Dokumentation,

01:29:57.156 --> 01:30:00.796
was wir betreiben. sozusagen mit einer Befindungsphase.

01:30:04.028 --> 01:30:09.848
Ja, bloß die Dokumentation, die wir da machen, ist halt quasi ein Treiber für die Implementierung.

01:30:09.928 --> 01:30:12.988
Normalerweise machst du die Dokumentation nach dem Code.

01:30:13.288 --> 01:30:16.168
In dem Fall machst du die Dokumentation vorher und der Code basiert auf der

01:30:16.168 --> 01:30:19.848
Dokumentation. Okay, also es ist eine Spezifikation und nicht eine Dokumentation.

01:30:22.008 --> 01:30:25.888
Haben wir denn jetzt was noch nicht besprochen? Ich hätte noch eine letzte,

01:30:25.928 --> 01:30:27.768
eine allerletzte Frage. Schieß los.

01:30:28.668 --> 01:30:32.548
Und zwar, Martin, was ist dein Verhältnis zu Conways Law? Was sagst du?

01:30:34.148 --> 01:30:37.228
Zu Conway's Law? Wo kommt diese Frage her?

01:30:38.068 --> 01:30:40.888
Das war das allererste, woran ich gedacht habe, als du gesagt hast,

01:30:40.948 --> 01:30:44.048
wir holen alle in einen Raum, damit alle das gleiche Weltbild haben und produzieren

01:30:44.048 --> 01:30:48.868
was, wo alle irgendwie letztlich sich drin wiederfinden.

01:30:49.788 --> 01:30:54.808
Conway's Law ist quasi ein Naturgesetz, daran kommst du nicht vorbei.

01:30:56.208 --> 01:31:00.388
Naja, er hat halt irgendein Heini gesagt, also ich meine, ob das jetzt ein Naturgesetz

01:31:00.388 --> 01:31:02.368
ist, weiß ich nicht, aber ich wollte sozusagen nur sozusagen,

01:31:02.588 --> 01:31:04.908
dein Verhältnis einfach so wissen, wenn du jetzt, ich meine,

01:31:04.928 --> 01:31:08.088
die Aussage, das ist ein Naturgesetz, ist ja im Prinzip was ich hören wollte,

01:31:08.248 --> 01:31:10.428
nämlich wie dein Verhältnis dazu ist, ist super.

01:31:11.408 --> 01:31:16.368
Ich glaube, es ist so, also das Conway's Law gilt und da kommst du auch nicht

01:31:16.368 --> 01:31:17.088
dran vorbei, glaube ich.

01:31:18.128 --> 01:31:22.868
Da fest eine Überzeugung. Wollt ihr mal kurz beschreiben, was das Conway's Law ist?

01:31:24.048 --> 01:31:27.808
Convice-Law ist, du hast eine Organisation, die produziert etwas,

01:31:28.028 --> 01:31:30.748
was immer sie produziert, ist ein Abbild der Organisationsstruktur,

01:31:32.868 --> 01:31:34.108
der produzierenden Entität.

01:31:37.648 --> 01:31:40.748
Also im Prinzip, wenn du drei Abteilungen hast, wirst du nach Convice-Law mit

01:31:40.748 --> 01:31:43.028
drei Microservices rauskommen. Ja.

01:31:44.388 --> 01:31:48.268
Du hast vier Teams, die am Compiler arbeiten, also wird es vier Passes über

01:31:48.268 --> 01:31:51.928
den Code geben. Ich könnte noch ein neues Frontend-Framework schreiben.

01:31:54.668 --> 01:31:57.848
Und das kann man so oder so sehen und wenn man das als Naturgesetz hinnimmt,

01:31:57.888 --> 01:32:00.588
dann kann ich das verstehen.

01:32:03.632 --> 01:32:06.672
Also ich glaube, es lohnt sich wirklich,

01:32:06.712 --> 01:32:10.492
sich, wenn auch nur vielleicht mal an einem Tag damit zu beschäftigen,

01:32:10.512 --> 01:32:16.512
einfach mal das Team zusammenzurufen und einfach mal aus Jux und Dollerei so

01:32:16.512 --> 01:32:19.212
ein Eventmodell aufzuzeichnen. Einfach mal gucken, wo man dabei rauskommt.

01:32:20.192 --> 01:32:25.052
Der Aufwand ist nämlich tatsächlich nicht wirklich groß und wir haben das nicht explizit gesagt,

01:32:25.212 --> 01:32:28.852
also Eventmodelling ist nichts, was ich mir ausgedacht habe,

01:32:28.912 --> 01:32:32.452
nichts, was meine Firma sich ausgedacht hat, sondern das ist im Prinzip eine

01:32:32.452 --> 01:32:39.752
Bewegung, die seit 2018 da ist und die quasi jetzt gerade richtig Fahrt aufnimmt.

01:32:40.512 --> 01:32:47.472
Erfunden hat es der Adam Dimitruk aus Kanada und das ist einfach im Prinzip

01:32:47.472 --> 01:32:51.772
was, was man einfach ausprobieren muss. Und da gibt es auch jede Menge Informationen dazu.

01:32:51.872 --> 01:32:55.952
Wenn man einfach Event-Modeling googelt, dann kommt man entweder bei meiner

01:32:55.952 --> 01:32:57.652
Webseite raus oder bei anderen Webseiten.

01:32:57.752 --> 01:33:00.272
Es gibt jede Menge Informationen dazu und ich kann wirklich nur empfehlen,

01:33:00.352 --> 01:33:03.112
das einfach mal auszuprobieren und gucken, ob es funktioniert oder nicht.

01:33:03.372 --> 01:33:07.412
Und meine Erfahrung damit ist sehr, sehr gut und die Unternehmen,

01:33:07.472 --> 01:33:10.632
mit denen ich es bisher gemacht habe, waren alle mehr als begeistert.

01:33:11.652 --> 01:33:17.092
Ich glaube, ich möchte da heute auch quasi nur so extra streng sein für die Nachhaltigkeit davon.

01:33:17.892 --> 01:33:23.572
Ich war ja auch als Teilnehmerin bei verschiedensten Workshops bisher in meinem Leben dabei.

01:33:23.992 --> 01:33:27.712
Und bei manchen hatte ich das Gefühl, man, das war heute so ein netter Tag,

01:33:27.912 --> 01:33:30.952
aber nachhaltig war da nichts mehr.

01:33:31.012 --> 01:33:35.172
Am nächsten Tag sind wir halt alle wieder vor unsere Laptops und haben weitergearbeitet wie davor. vor.

01:33:35.932 --> 01:33:41.492
Und das könnte, ich meine, hier hat man ja zumindest noch so Action-Items,

01:33:41.532 --> 01:33:42.492
die man danach machen kann.

01:33:42.552 --> 01:33:47.312
Dann hat man das erledigt und daraus können wir dann schöne Arbeitspaketchen schnüren.

01:33:49.572 --> 01:33:53.892
Aber sonst wäre halt die Sorge so, ja, cool, wir haben jetzt drüber gesprochen,

01:33:54.072 --> 01:33:57.132
aber jetzt geändert hat sich nichts oder dokumentiert haben wir nichts.

01:34:01.052 --> 01:34:05.032
Also ich meine, selbst wenn du nur das Diagramm machst, hast du schon mal einen

01:34:05.032 --> 01:34:06.212
Mehrwert für das Modell geschaffen.

01:34:06.292 --> 01:34:09.092
Auch wenn du nichts weiter machst, hast du schon mal eine super Dokumentation

01:34:09.092 --> 01:34:10.792
für dein Projekt und das dauert einen Tag.

01:34:10.852 --> 01:34:15.012
Du kannst das Modell in einem Tag für ein mittelgroßes Projekt machen. Ja, das glaube ich.

01:34:20.050 --> 01:34:25.070
Ist es dir schon mal, das ist heute alles, was wir besprochen haben.

01:34:26.790 --> 01:34:31.030
Ich kann nicht mal sagen, dass es aus einer Produktsicht heraus ist.

01:34:33.670 --> 01:34:37.790
Aber dennoch hast du ja auch gesagt, im besten Fall sind Screens auch schon vorbereitet.

01:34:38.610 --> 01:34:44.890
Ich habe jetzt auch teilweise Projekte schon mal gehabt, die überhaupt nicht

01:34:44.890 --> 01:34:48.650
designgetrieben waren, sondern wirklich sehr, sehr, sehr, sehr technisch getrieben.

01:34:48.930 --> 01:34:51.870
Obwohl ich im Endeffekt auch gar nicht so genau weiß, was es genau bedeutet.

01:34:51.950 --> 01:34:55.650
Im Endeffekt waren dann halt auch einfach Developer dabei, die auch sehr gut im Designen sind.

01:34:55.730 --> 01:34:59.870
Oder es gab auch einfach schon fertige UI-Bibliotheken, die man für so ein internes

01:34:59.870 --> 01:35:00.870
Tool mal verwenden kann.

01:35:01.670 --> 01:35:05.790
Aber jetzt aus der Sicht heraus, ich möchte vielleicht gar nichts so für die

01:35:05.790 --> 01:35:12.110
menschlichen End-User bauen, sondern ich will mir selber eine Admin-Interface bauen.

01:35:12.570 --> 01:35:15.050
Ich will mir jetzt selber ein Ticketsystem bauen, sowas.

01:35:16.810 --> 01:35:25.310
Ähm, da habe ich auch schon oft gehört, ist jetzt auch nicht so wichtig,

01:35:25.330 --> 01:35:29.630
wie die Screens aussehen, mach einfach das, was technisch am leichtesten funktioniert.

01:35:29.630 --> 01:35:35.670
Und ich denke jetzt, dass so eine Herangehensweise mit Event Modeling auch sofort

01:35:35.670 --> 01:35:38.230
schon kaputt gemacht wird,

01:35:38.350 --> 01:35:42.290
beziehungsweise gar nicht erst entstehen kann oder es gar nicht erst diese Ausrede

01:35:42.290 --> 01:35:46.250
geben kann, wie ist an dieser Stelle nicht so wichtig, mach einfach das,

01:35:46.330 --> 01:35:49.410
was technisch am leichtesten ist, weil auch im Endeffekt ist ja das wahrscheinlich

01:35:49.410 --> 01:35:50.610
auch schon dann eine Entscheidung.

01:35:50.690 --> 01:35:55.010
Gut, dann machen wir halt einfach ein natives Formular mit einem nativen Submit

01:35:55.010 --> 01:35:57.190
Button und fertig. Genau, ist ja völlig okay.

01:35:57.290 --> 01:36:00.090
Aber das Wichtige ist, du arbeitest mit den richtigen Daten.

01:36:00.190 --> 01:36:04.930
Es kann ja nicht passieren, dass du Daten vergisst oder dass du annimmst,

01:36:04.930 --> 01:36:07.710
dass Daten da sind, die aber gar nicht da sind, weil das Eventmodell das gar nicht hergibt.

01:36:11.357 --> 01:36:13.017
Ja, gut.

01:36:18.957 --> 01:36:23.357
Ich habe keine Fragen mehr. Peter, du hast vorher gemeint, das ist eine allerletzte

01:36:23.357 --> 01:36:26.377
Frage, aber du darfst natürlich trotzdem noch eine fragen.

01:36:26.557 --> 01:36:29.957
Nur für mich fällt einfach keine mehr ein. Ich muss das jetzt halt ausprobieren.

01:36:31.577 --> 01:36:33.757
Nein, also das Letzte, was ich jetzt natürlich noch fragen würde,

01:36:33.837 --> 01:36:36.717
wäre, Martin, wo findet man dich im Internet und wo kann man dich für einen

01:36:36.717 --> 01:36:37.637
solchen Workshop anheuern?

01:36:38.737 --> 01:36:44.157
Genau, am besten einfach auf meine Webseite gehen, nebulit.de und einfach anschreiben.

01:36:44.157 --> 01:36:47.117
Oder man findet mich auch auf LinkedIn. Ich poste fast jeden Tag über dieses Thema.

01:36:47.317 --> 01:36:51.417
Man darf mich jederzeit anschreiben, man darf jederzeit anrufen.

01:36:51.457 --> 01:36:53.497
Ich rede sehr, sehr gerne über das Thema.

01:36:53.957 --> 01:36:56.237
Viele können es schon gar nicht mehr hören, die öfter mit mir zu tun haben.

01:36:56.897 --> 01:37:00.717
Ich bin wirklich der Überzeugung, dieses Thema wird die Softwareindustrie in

01:37:00.717 --> 01:37:02.397
den nächsten 24 Monaten revolutionieren.

01:37:02.857 --> 01:37:05.737
Jetzt warte ich noch drauf. Kannst du mal an meiner Tür klopfen und sagen,

01:37:05.877 --> 01:37:08.857
hallo, hätten Sie fünf Minuten, um mit mir über Event-Modeling zu sprechen?

01:37:09.317 --> 01:37:11.977
Ich könnte dem Postboten was vom Event-Modeling erzählen. Ich rede wirklich

01:37:11.977 --> 01:37:13.077
extrem gerne über das Thema.

01:37:13.217 --> 01:37:15.757
Also wenn das jemanden interessiert, wirklich sehr, sehr gerne melden.

01:37:15.817 --> 01:37:17.517
Ich rede stundenlang drüber.

01:37:18.317 --> 01:37:21.757
Dann meine letzte Frage. Woher kommt der Name Nebulit?

01:37:26.417 --> 01:37:30.317
Nebulit, ursprünglich war die Firma quasi für Cloud-Themen verantwortlich.

01:37:30.997 --> 01:37:34.277
Nebul ist Nebel, Cloud und daher kommt der Name.

01:37:35.977 --> 01:37:39.637
Das ist cool. Aber ursprünglich ist jetzt keine Cloud mehr.

01:37:39.777 --> 01:37:42.437
Wir arbeiten natürlich immer noch mit Clouds, spezialisiert auf AWS,

01:37:42.677 --> 01:37:47.677
aber Fokus ist jetzt tatsächlich auf Entwicklung von eventbasierten Systemen mit Event Modeling.

01:37:52.073 --> 01:37:57.733
Alles klar. Martin, hast du noch eine Sache, die du noch nicht loswerden konntest,

01:37:57.733 --> 01:38:00.473
während wir dich ja die ganze Zeit mit Fragen unterbrochen haben?

01:38:01.253 --> 01:38:05.553
Ich habe ja wirklich sehr, sehr viel geredet und es hat genauso viel Spaß gemacht

01:38:05.553 --> 01:38:08.573
wie letztes Mal. Also ich bin sehr froh, dass ich heute da sein durfte.

01:38:09.753 --> 01:38:14.033
Wie gesagt, einfach mal ausprobieren. Ist ein super spannendes Thema und wer

01:38:14.033 --> 01:38:18.673
Fragen hat, darf sich immer gerne melden. Das klingt großartig.

01:38:45.293 --> 01:38:47.593
Und ich glaube, mir hat diese Reihenfolge jetzt sehr gut gefallen,

01:38:47.713 --> 01:38:50.013
weil das wäre so ein bisschen das Verständliche für alle.

01:38:50.333 --> 01:38:54.773
Und bei Domain-Driven Development, da gab es dann sofort Fachbegriffe,

01:38:54.853 --> 01:39:02.473
die einfach sehr viel technischer klingen und dadurch sehr viel abstrakter waren.

01:39:02.553 --> 01:39:05.833
Aber ich glaube, diese Sachen lassen sich sehr gut dann miteinander verbinden

01:39:05.833 --> 01:39:08.313
als quasi aufeinanderfolgend.

01:39:09.373 --> 01:39:14.453
Dann bleibt mir an der Stelle nur noch vielen, vielen lieben Dank zu sagen.

01:39:15.293 --> 01:39:22.333
Ich hatte sehr viel Spaß. Auch Chapeau, wie du unserem Kreuzverhör hier standgehalten hast.

01:39:24.153 --> 01:39:29.453
Willkommen bei zwei deutschen Skeptikern. Mir hat es sehr viel Spaß gemacht.

01:39:30.393 --> 01:39:36.273
Vielen lieben Dank euch beiden. Und dann hören wir uns wieder nächste Woche

01:39:36.273 --> 01:39:40.373
mit einem diesmal wieder sehr frontatlastigen,

01:39:41.213 --> 01:39:45.713
einfachen, einfachen Thema von so ein bisschen Nux.js und Un.js,

01:39:45.873 --> 01:39:47.533
da gehen wir wieder in die JavaScript-Richtung.

01:39:47.693 --> 01:39:50.493
Vielen Dank fürs Zuhören und bis zum nächsten Mal.

01:39:50.713 --> 01:39:53.173
Ciao, ciao. Tschüssi. Ciao.

01:39:54.160 --> 01:40:17.040
Music.

01:40:10.373 --> 01:40:11.893
Bis zum nächsten Mal.