Latest / Coding Buddies | Tech & Dev-Mindset / Mach doch erstmal?! Warum Anforderungen so wichtig sind!

Transcript

Mach doch erstmal?! Warum Anforderungen so wichtig sind! · Coding Buddies | Tech & Dev-Mindset

0:00
Ja, habt ihr. Irgendwie gibt es irgendwelche
0:01
Anforderungen daran, was ich berücksichtigen soll?
0:04
Na ja, das was es können soll, aber so richtige Anforderungen
0:08
haben wir noch nicht und dann kommt das, was immer sehr
0:10
gefährlich ist. Die werden aber noch kommen, ja.
0:14
Coating Bodys dein Podcast rund um Softwareentwicklung und
0:17
aktueller Technews herzlich willkommen.
0:31
Halli Hallo und herzlich Willkommen zur neuen Folge vom
0:34
Coding Buddies Podcast. Schön, dass du wieder
0:36
eingeschaltet hast und schön, dass wir alle wieder hier
0:39
zusammen sind. Ich natürlich der Fabi und auch
0:43
der fantastische Tino Tino sei gegrüßt.
0:48
Hallo. Na na, wie geht's?
0:51
Wie steht's? Geht ab.
0:54
Ich habe schon auf was geht ab gewartet, aber hallöchen.
1:00
Ja, ich hab gute. Laune heute ist ein schöner Tag,
1:03
das ist gut, das freut mich. So ist es richtig gute Laune
1:06
beim Podcast. Das erhält die Stimmung für alle
1:09
hier. Mal gucken, wie lange die Laune
1:13
anhält. Genau direkt im Keller.
1:17
Tschüss war's gut ne Pass auf, lass uns mal das Thema starten
1:21
und zwar möchte ich das Thema noch nicht ganz verraten, ich
1:23
möchte am Anfang erstmal ein kleines Gedankenexperiment
1:25
machen. Was heißt Gedankenexperiment?
1:29
Ich weiß nicht, ob man das so nennen, aber.
1:31
Ich möchte jetzt auch, dass du, liebe Zuhörer, lieber Zuhörer,
1:35
auch mitmachst und du natürlich auch Dino.
1:39
Und zwar geht es einfach nur mal ganz kurz darum, um sich
1:42
vorzustellen, wenn ich einfach nur sage.
1:46
Stellt euch bitte vor. Oder was würdet ihr sagen?
1:50
Was ist ein großes Haus? Jetzt kann man einmal ganz kurz
1:54
drüber nachdenken und jetzt sag du doch mal, Tino, was ist für
1:59
dich ein großes Haus? Ein großes Haus, ja.
2:05
Mhm. Tja, das ist eine gute Frage.
2:09
Also großes Haus hat auf jeden Fall mehrere Etagen, OK.
2:19
Wohnfläche würde ich sagen. Die Frage ist halt was für n,
2:22
was für n Haushalt ne, also entweder viel Wohnfläche oder
2:27
viele Wohneinheiten, also irgendwas ja was halt groß
2:31
treffen würde. Also ich würd jetzt einfach
2:33
sagen mehrere Etagen wäre jetzt so das erste.
2:36
Und jetzt kann, ja kannst du Liebe zuhören, lieber Zürcher,
2:38
ja mal abgleichen, wie es zum Beispiel was Tino gesagt hat, ob
2:41
das sozusagen deine Gedanken trifft oder nicht.
2:44
Ich hätte zum Beispiel auch gesagt, so was wie es muss, weiß
2:48
ich nicht, keine. Ahnung.
2:49
Für mich ist ein großes Haus vielleicht sowas wie es hat 7
2:52
Zimmer, 2 Etagen und muss mindestens weiß ich nicht 200
2:57
bis 250 Quadratmeter mal als Beispiel so also.
3:01
Wenn du es jetzt so zum Beispiel auf Wohnhäuser beziehst, also so
3:03
ein Einfamilienhaus wäre, es wäre ein sehr großes
3:07
Einfamilienhaus zum Beispiel, dann wäre es auch nach meiner
3:10
Definition groß. Genau so.
3:12
Und jetzt kommen wir zu dem spannenden Teil, weil du hast
3:15
gerade gesagt, kommt es jetzt darauf an, es ist ein
3:17
Einfamilienhaus, es ist ein Mehrfamilienhaus und.
3:20
Vielleicht stellen sich manche Leute auch darunter vor, dass n
3:23
großes Haus ein Haus ist, was quasi wirklich von der Höhe her
3:26
groß ist und nicht von der Fläche her.
3:28
Beispielsweise ne, das heißt n großes Haus könnte wär für
3:32
manche vielleicht nicht, wenn es weiß nicht 500 Quadratmeter
3:35
hätte aber nur eine Etage, aber vielleicht wenn es mehrere
3:39
Etagen hätte, was auch immer, also von der Höhe her, es gibt
3:43
viele Interpretationen davon und wenn ich jetzt zum Beispiel
3:45
sagen würde, Tino Pass Aufbau mir doch mal bitte ein Haus, ein
3:50
Großes. Dann wird es schwierig.
3:55
Weil du ja offensichtlich nicht wissen kannst, was ich zum
4:00
Beispiel von dir möchte. Was ist groß, verstehst du genau
4:06
und einfach nur mal, um? Mit diesem Aufhänger würde ich
4:11
gerne in die Folge starten und in das Thema der Folge und zwar
4:16
geht es um Anforderungen und warum Anforderungen in der
4:20
Software Entwicklung und vielleicht auch nicht nur in der
4:22
Softwareentwicklung wie wir gerade gesehen haben, also
4:24
unglaublich essentiell sind. So genau, und da können wir ja
4:29
vielleicht einfach mal n bisschen gucken.
4:31
So, warum ist das so? N bisschen haben wir es jetzt
4:33
schon mal in einem Beispiel demonstriert.
4:36
Und was sind vielleicht auch unsere Erfahrungen dabei?
4:39
Und was passiert, wenn es halt ja nicht ordentlich, also wenn
4:44
man nicht ordentlich die Anforderungen an die Software
4:47
stellt? Was hältst du davon?
4:49
Ja, ist ein ganz cooles Thema ist glaube ich auch ein Thema,
4:52
was viel diskutiert wird, wo auch viele wahrscheinlich von
4:56
der Theorie her wissen, wie es sein müsste.
5:02
Aber in der Praxis ist doch ein unglaublich schwieriges Thema
5:05
ist. Sowohl also von beiden Seiten
5:10
aus würde ich sagen, es ist halt n schwieriges Thema, sowohl für
5:15
den, der die Anforderung stellt, also beispielsweise irgendein
5:18
Kunde oder Stakeholder der Software und natürlich für den
5:22
Implementierenden diese Anforderungen, also zum Beispiel
5:25
wenn es ein Feature request ist, denn auch wirklich umzusetzen,
5:29
was sich gewünscht wird, wie du es ja gerade ganz cool an dem
5:33
Beispiel klar gemacht hast. Wenn jetzt der Wunsch wäre.
5:39
Bau mir ein großes Haus und ich würde sagen okay, das reicht
5:42
mir, ich brauche nicht mehr Anforderungen oder genauere
5:45
Anforderungen. Würde jetzt anfangen ein großes
5:47
Haus zu bauen ist die Wahrscheinlichkeit ja ziemlich
5:50
groß, dass Unmut am Ende aufkommt, weil es einfach nicht
5:54
deinen Erwartungen entspricht, richtig, und das ist eigentlich
5:57
eine ganz coole Analogie, die gefällt mir sehr gut shoppen.
6:02
Dankeschön, Dankeschön. Ja, also ich ja.
6:06
Also ich möchte einfach mal n bisschen über dieses Thema
6:08
reden, weil ich weiß ja, dass du und auch ich in der
6:12
Vergangenheit auch einfach. Auch damit zu kämpfen haben.
6:16
Einfach weißt du das man. Anforderungen bekommt und diese
6:21
Anforderung halt nicht. Leider nicht immer klar genug
6:24
definiert sind. Ne.
6:26
Und genau diese 2 Punkte, die du gerade auch schon angesprochen
6:29
hast, sind ja unglaublich wichtig.
6:30
Weil natürlich kannst du eine Anforderung definieren.
6:35
Und vielleicht ist diese Anforderung per Definition für
6:38
dich klar. Aber die Frage ist natürlich,
6:40
was kommt bei der anderen Seite. Also wenn man jetzt sagt, der
6:44
Stakeholder stellt die Anforderungen und der
6:46
Stakeholder sagt, für mich ist die Anforderung klipp und klar,
6:49
manchmal sieht man ja den Wald vor lauter Bäumen nicht, du
6:52
kannst ja zum Beispiel, wenn wir beim Beispiel bleiben, wenn für
6:55
mich definitiv klar ist, was ein großes Haus ist, manchmal
6:58
hinterfragt man seine eigenen Gedanken nicht mehr.
7:02
Das ist so klar und wie ich meine, man sieht den Wald vor
7:04
lauter Bäumen nicht mehr. Dann ist es eben schwierig oder
7:07
kann schwierig sein, diese Anforderungen weiterzugeben,
7:10
weil die andere Seite sagt dann also im optimalen Fall, an
7:15
dieser Stelle würde ich mir denken, dass die entwickelnde
7:18
Seite sagt, Moment, da sind noch einige Fragen offen, aber ich
7:22
fand die Idee von dir auch gut zu sagen, ja okay, aber was ist
7:25
denn, wenn die andere Seite einfach sagt?
7:27
N großes Haus, klare Sache, mach ich dir, hab ich genaue
7:30
Vorstellung von, also beide Seiten sehen den Wald vor lauter
7:34
Bäumen nicht. Find ich auch nicht schlecht und
7:37
das wär natürlich. Das ist natürlich worst case,
7:39
ne. Ja genau, da fehlt dann halt
7:41
einfach diese klare Kommunikation dazwischen.
7:43
Und das meine ich halt immer mit Theorie und Praxis.
7:46
In der Theorie weiß jeder, OK, es muss klar kommuniziert
7:49
werden, was sich gewünscht wird, es muss detailliert
7:51
aufgeschrieben sein, sodass quasi der Entwickler genau weiß,
7:56
was zu tun ist und die Realität ist ja oft so.
8:01
Der also der Anfordernde klingt komisch, also der Stakeholder
8:04
sagt, Ich hab's klar definiert, ich denke, das ist absolut klar,
8:08
was ich mir wünsche, der Entwickler denkt sich, liest
8:11
einmal drüber ja okay alles klar, ich hab sofort eine
8:14
Vorstellung was das beinhalten soll und im Worst case wie du
8:18
schon meintest Match das aber nicht, dass beide eigentlich in
8:21
dem Moment zufrieden sind und loslegen, also was heißt
8:25
loslegen das Stakeholder kümmert sich vielleicht um andere
8:27
Themen, weiß nicht blenden wir mal kurz aus gehen wir mal auf
8:30
die Entwicklersicht und du denkst dir.
8:33
Ja gut, dann entwickle ich das jetzt, weil ich weiß ja, was zu
8:36
tun ist. So, und dann kann es entweder
8:39
sein, während der Entwicklung denkst du dir so.
8:41
Ja Moment mal, mach ich das jetzt so oder so?
8:44
Also warte jetzt bin ich mir unsicher, wie soll das jetzt
8:47
eigentlich sein und da fällt dann erst auf so vielleicht es
8:50
doch nicht so genau spezifiziert, das ist im Prinzip
8:54
ein Case, der aber noch OK ist, weil dann kann es ja nach
8:57
spezifizieren der absolute Worst case ist ja wenn du auch diesen
9:01
Moment nicht hast und am Ende sozusagen.
9:06
Sagst hey, ich bin fertig hier, bitte schau es dir an und dann
9:09
ist es komplett an den Anforderungen vorbeigegangen und
9:12
das klingt zu utopisch oder unwahrscheinlich, aber das ist
9:15
nicht unwahrscheinlich, dass man stark an Anforderungen vorbei
9:19
implementiert, das geht halt schnell in solchen Fällen.
9:23
Ja, richtig. Also ich meine, ich finde, ein
9:25
gutes Beispiel ist tatsächlich. Wenn wir jetzt mit Git unterwegs
9:30
sind und du sagst zum Beispiel okay, ich möchte gerne
9:33
automatisiert einen Brunch in den, also einen lokalen Branch
9:39
in den Remote Branch Mergen, da könnte man vielleicht am Anfang
9:43
sagen, ja gut, das ist total logisch, macht sehr einfach, es
9:47
geht schnell. Also du sagst einfach okay push.
9:50
Ne Push dein dein Änderung von deinem Branch einfach Remote
9:54
synchronisiere den und alles ist gut so, das könnte ja vielleicht
9:57
sozusagen die Anforderung sein und und auch die
10:00
Erwartungshaltung sein, dass man sagt, OK passt auf, es gibt
10:02
Änderungen auf dem lokalen Branche, Du möchtest Änderungen
10:05
auf nem Remote Branch pushen und das ist die Anforderung, es muss
10:08
einfach nur hochgeballert werden, so nach dem Motto.
10:12
Und dann kann es ja durchaus einfach nur mal um das
10:14
vielleicht mal so versuchen, ein kleines Beispiel zu generieren.
10:17
Du kannst ja durchaus sein, dass du verschiedene Edge Casts hast,
10:19
die du dann entweder mitbekommst wie du meintest oder eben nicht.
10:23
Also wenn du jetzt zum Beispiel sagst, du kriegst es mit und
10:25
denkst dir warte mal. Aber was ist denn eigentlich,
10:27
wenn ich meine Änderung pushen will und es gibt einen Merch
10:29
Konflikt so und du denkst nicht daran so also solche Sachen
10:34
können ja auftreten und dann ist eben die Frage
10:36
anforderungstechnisch wie geht man damit um, sagt man einfach
10:40
Push Force Haue ich einfach meine Änderungen ganz klar
10:44
drüber und ich. Was soll passieren?
10:46
Und das ist genau der Punkt, der zum Beispiel mich auch in in
10:50
mich als Softwareentwickler sag ich mal in meiner Laufbahn öfter
10:54
mal n bisschen begleitet hat, das Anforderungen gestellt
10:57
werden, die erstmal sag ich jetzt mal.
11:01
Den Happy Pass abbilden im Sinne von du möchtest irgendetwas
11:04
machen und also die Software soll irgendetwas tun, ne aber
11:08
was passiert wenn es zum Beispiel zu Konflikten kommt?
11:11
Ne in diesem Happypass also wir von diesem Happypass abweichen,
11:15
also es ist nicht alles gut, es funktioniert nicht alles so,
11:18
sondern es kommt vielleicht mal zu einem Fehler, zu einem
11:20
Problem. Und da habe ich zumindest
11:24
persönlich die Erfahrung gemacht, dass oftmals an dieser
11:26
Stelle solche Anforderungen vergessen werden, weil das
11:29
gehört meiner Meinung nach mit zu den Anforderungen.
11:33
Dieses, nennen wir es mal Feature mit dazu.
11:35
Weißt du, weil das schwierige an der Stelle ist, finde ich, wenn
11:40
du jetzt genau diesen Punkt hast und sagst, Na ja, gut, pass auf,
11:43
wir sollen ja wirklich den Branch, den lokalen Branch zur
11:48
Änderung des lokalen Branches auf Remote pushen, das ist die
11:52
Anforderung. Und wenn es jetzt vielleicht so
11:55
ist, dass man irgendwie merge Konflikte hätte.
11:58
Die Anforderung ist ja offensichtlich, dass im
12:00
Endeffekt das einfach. Ja, hochgeschoben werden soll.
12:04
Also mach ich n. Push Force und Bügel alles über
12:11
und am Ende sagt der Stakeholder Moment, hier sind Änderungen
12:16
verloren gegangen und das ist halt das Problem, weil dann
12:20
denkst du dir so. Na ich denke wir sollten das so
12:21
machen. Ja.
12:25
Und da kommt es halt zu. Problemen.
12:28
Ja OK, also verstehe ich das Beispiel.
12:31
Ich hoffe Liebe zur Geburt, du hast das mit dem Git auch
12:34
verstanden, das Beispiel. Genau also was du meinst ist im
12:38
Prinzip, dass der. Der Stakeholder quasi eine
12:44
Vision im Kopf hat. Also so ein Wunschverhalten der
12:47
Software diesen sogenannten Happypass, wie du das formuliert
12:50
hast und. Dann im Prinzip nicht
12:56
berücksichtigt, was alles auf diesem Weg passieren kann
12:59
beziehungsweise denkt. Er hat alles berücksichtigt und
13:02
dann kommt trotzdem Cases. Die quasi, wo er denn selbst
13:09
noch nicht weiß, wie er das eigentlich haben möchte.
13:11
Das ist ja auch so n so n Fall, der öfter mal auftritt wie du
13:14
schon meintest, so na ja gut, er möchte ja scheinbar immer das
13:18
was lokal liegt, ich greif das Beispiel noch mal kurz auf auf
13:23
dem Server Remote zur Verfügung stellen und das ist immer der
13:26
Stand der zählt, also bügeln wir quasi immer alles über das heißt
13:30
wir überschreiben die Änderung und er denkt sich so Moment mal,
13:35
jetzt ist ja ein Fall eingetreten, dass da Sachen
13:37
waren. Die unterschiedlich waren.
13:40
Und die werden jetzt quasi überschrieben, dass da den Fall
13:43
habe ich gar nicht berücksichtigt, dass das
13:44
zustande kommen kann. Ich dachte, es kommen immer nur
13:46
neue Sachen drauf und nicht, dass Sachen quasi durcheinander
13:50
kommen und dann überschrieben oder verworfen werden.
13:55
Das ja, das ist ein ganz klassischer Fall.
14:00
Quasi. Ja.
14:01
Mir ist gerade ein Beispiel eingefallen, weil du meintest,
14:03
hoffentlich konnte jetzt jeder folgen im Sinne von diesem
14:06
Gipfel. Spiel, aber stell dir mal vor,
14:08
ich sag jetzt zu dir Tino, kannst du mal n bisschen Milch
14:11
holen fahren so ne weil wir keine Ahnung wir wollen heute
14:14
Abend irgendwas kochen und wir brauchen Milch du kannst mein
14:17
Fahrrad nehmen, fahr damit einfach zum Supermarkt du darfst
14:20
sagst ja alles klar ich soll Milch holen.
14:22
Fährst mit dem Fahrrad zum Supermarkt.
14:23
Du hast n Platten, ne denkst dir OK, dann lass ich das Fahrrad
14:27
halt hier stehen und lauf halt mit der Milch nach Hause, kommst
14:30
an und sagst hier ist deine Milch und dann sag ich OK wo ist
14:33
aber dein Fahrrad und dann sagst mein Fahrrad und dann sagst du
14:36
ja das hatte n platt ich hab es einfach stehen lassen so ich hab
14:38
nicht die Anforderungen gestellt zu sagen wenn das Fahrrad einen
14:42
Platten hat dann bringt es bitte trotzdem wieder mit zurück also
14:45
weißte oder es hätte ja auch sein können, dass du dir sagst
14:49
ich bring das Fahrrad mit nach Hause weil der will ja bestimmt
14:51
sein Fahrrad wieder haben und ich sag aber.
14:56
Du solltest die Milch mitbringen, aber wenn du Platten
14:57
hast, dann lass das Fahrrad doch da liegen.
14:59
Das ist doch kaputt, will ich nicht mehr haben.
15:01
Also die Frage ist halt, du kannst dir nur denken ja gut
15:04
wahrscheinlich möchte. Er, dass ich das Fahrrad
15:08
mitbringe und wahrscheinlich wird es auch die richtige
15:10
Intuition sein, die du hast. An der Stelle, aber unter
15:13
Umständen, wenn man jetzt auf das in der Softwareentwicklung
15:16
ist, kann es halt sein, dass es nicht immer das ist, was man
15:19
sich denkt, was es ist, wie es sich verhalten soll.
15:22
So. OK.
15:25
Jetzt wusste ich kurz mal selbst mitkommen.
15:28
Ja, genau, also man man, man setzt halt quasi oder setzt
15:32
Sachen voraus, die nicht beschrieben sind, weil man die
15:35
quasi so von von sich ausgeht. Meinst du das damit, dass du
15:40
gewisses Verhalten voraussetzt? Aber dann lass uns doch noch mal
15:47
auf das Hausbeispiel gehen. Wie würdest du das denn besser
15:52
finden? Also mal angenommen, das war
15:54
jetzt, wir schreiben jetzt eine Anforderung an einen Entwickler
15:58
oder bzw dann. An die Handwerkerbauarbeiter.
16:02
Wie auch immer. Ich möchte ein großes Haus
16:07
haben. So, das ist natürlich super
16:08
unpräzise und kann einfach alles rauskommen.
16:10
Das heißt, es muss ja mehr spezifiziert werden, dann könnte
16:13
man ja jetzt beispielsweise im nächsten Schritt sagen.
16:18
Das Ganze soll eine Wohnfläche von so und so viel Quadratmeter
16:24
haben. Auf Xetagen und mit x meine ich
16:27
jetzt, das kann jetzt jeder für sich einstellen, da sollte
16:29
natürlich eine Zahl drin stehen. Sagen wir mal keine Ahnung. 200
16:33
Quadratmeter auf 2 Wohnetagen ja.
16:36
So. Mhm, wäre das denn jetzt präzise
16:39
genug? Es.
16:42
Also ich würd sagen, das ist noch nicht präzise genug, weil
16:45
du natürlich vielleicht auch noch definieren müsstest an
16:48
diesem Beispiel. Wie sollen die beispielsweise
16:52
die Zimmer, wieviel Zimmer sollen pro Etage hinkommen, wie
16:54
sollen die Zimmer gelegen sein? In welche Richtung sollen
16:58
vielleicht sogar die Türen öffnen?
17:00
Wo sollen die Türen sein von den Zimmern und wo kommt
17:03
beispielsweise ein Badezimmer hin, wo kommt zum Beispiel die
17:06
Küche hin? Solche Sachen ne.
17:08
Also es ist natürlich schon wichtig.
17:11
Möglichst präzise diese Anforderung auszuformulieren,
17:14
ne. An der Stelle kann man ja
17:18
zumindest vielleicht auch noch sagen, dass das Beispiel mit
17:20
einem Haus als einzelne Anforderung natürlich recht groß
17:23
gewählt ist, ne? Wenn wir jetzt in der
17:26
Softwareentwicklung unterwegs sind, ist es natürlich schöner,
17:29
wenn man vielleicht kleinere Pakete schnürt.
17:32
Ne ist auf jeden Fall sehr empfehlenswert.
17:36
Sodass halt die Anforderungen möglichst Kleinigkeiten
17:40
umfassen. Ne, also sagen wir mal, man
17:42
würde zum Beispiel diesen dieses dieses Zaun hauen bauen von dem
17:46
Haus würde man jetzt zum Beispiel unterteilen in mehrere
17:50
Aufgaben. Ne, dass man zum Beispiel sagt,
17:52
OK, was ist denn die Anforderung an die Grundfläche?
17:56
Ne, was ist denn die Anforderung an zum Beispiel?
18:00
Die Etagenzahl ne, was ist die Anforderung an die?
18:05
Zimmer, wie sie gelegen sind, also dass man das so sukzessiv
18:08
aufbaut, weil du könntest ja anfangen und sagen, OK, ich leg
18:11
erstmal den Grund. Grundriss, wie man das nennt, ne
18:14
also den das Fundament bau dann sozusagen die am Fundament die.
18:20
Das Haus drumherum, die wie nennt sich das?
18:23
Das Grundgerüst auf. Und so weiter.
18:28
Man merkt, wir sind ja auf jeden Fall die absoluten Handwerker.
18:32
Die kommen nur auf Fachbegriffe hier um die Ecke.
18:39
Das ist aber, um dann die Softwareentwicklung zu kommen,
18:42
um vom Handwerk weg, weil das auf jeden Fall nicht unser
18:44
Steckenpferd. Das ist nämlich ein wichtiger
18:48
Punkt, was du gerade gesagt hast, wo halt auch schon sehr
18:51
oft dran kränkelt, sage ich mal, dass diese Features oder diese
18:57
Anforderungen einfach viel zu viel umfassen, weil das genau
19:01
die Wahrscheinlichkeit enorm steigert, dass Sachen vergessen
19:04
werden. Also wenn die Anforderung ist,
19:06
bau mir bitte ein Haus, dann ist da so viel Spielraum drin, dass
19:11
alles Mögliche passieren kann, was quasi an der eigentlichen
19:15
Vorstellung dran vorbeigeht und selbst wenn man jetzt anfängt,
19:19
deswegen habe ich das mal so ein bisschen eingeladen.
19:22
Zu spezifizieren, wie dieses Haus aussieht, die
19:25
Wahrscheinlichkeit immer noch sehr groß, dass Sachen vergessen
19:28
werden, weil du die vielleicht im Kopf wieder voraussetzt, dass
19:32
ja Unstimmigkeiten auftreten, also quasi wieder Abweichungen
19:35
zwischen deiner Vorstellung und der realen Umsetzung am Ende.
19:39
Ja, und da hast du ja schon einen guten Punkt gebracht, dass
19:42
es immer von Vorteil ist. Diese Aufgabenpakete nenne ich
19:46
es jetzt mal, also diese Anforderungen oder Feature
19:49
wünsche. Klein hält, weil man sie einfach
19:54
besser überblicken kann und besser analysieren und
19:56
spezifizieren kann und dann quasi sukzessiv darauf basierend
20:01
dann nach und nach zu dem Gesamtziel kommt und.
20:07
Halt wirklich ein sehr entscheidender Punkt, den ich so
20:11
erfahrungsgemäß festgestellt habe.
20:15
Beispielsweise hatte ich mal. Ein Ticket beziehungsweise das
20:20
hatten wir beide sogar, das war in der Zeit, seitdem wir wieder
20:23
zusammenarbeiten. Das war relativ umfangreich, hat
20:29
aber auf den ersten Blick nicht so gewirkt.
20:32
Und. Da war nämlich genau der Fall,
20:35
dass beide Seiten der Meinung waren, OK, hier ist alles
20:39
spezifiziert, so wie es sein müsste und wir haben quasi
20:42
angefangen es zu implementieren. Und dabei hat sich dann doch
20:47
immer mehr herausgestellt, dass es wesentlich größer ist als
20:52
anfänglich gedacht. Und das wär halt auch der Punkt,
20:57
wo man sagen müsste, OK das das wird so wahrscheinlich nicht
21:00
funktionieren. Man müsste das entweder noch mal
21:03
runterbrechen oder ja halt splitten.
21:06
Ne, diese ganze Anforderung. Und das ist jetzt wieder
21:10
Realität und Theorie. Es ist aber anders gelaufen als
21:15
gedacht, sondern es lief im Endeffekt so, dass man immer
21:17
nachspezifiziert hat, weil man dachte, na ja, gut, das ist
21:20
jetzt vielleicht noch so ein ein Ding, was fehlt, das schreibe
21:23
ich jetzt mal bei uns, in dem Fall noch ins Ticket rein, ja
21:26
gut, alles klar, dann wissen wir jetzt für den Fall, was zu tun
21:28
ist. So, und das ist x mal passiert
21:32
und das beinhaltet natürlich auch, und das ist eine große
21:36
Gefahr, um mal so auf negative Aspekte einzugehen.
21:39
Wir haben auch viele Sachen doppelt gecoded, weil wir
21:43
dachten, okay, es müsste jetzt nach Schema A laufen haben das
21:48
implementiert. Dann wurde festgestellt, Herr,
21:51
nee, nee, nee, das ist eigentlich gar nicht, nee, das
21:55
wird so nicht funktionieren, jetzt, wo ich noch mal drüber
21:56
nachdenke und das Ausprobieren, das wird so nicht funktionieren,
21:59
wir brauchen Schema B, alles klar, dann reverse du das bzw
22:05
implementierst Schema b und sagst dann wiederum so jetzt
22:10
aber jetzt haben wir es doch oder?
22:12
Ja, aber jetzt ist irgendwie. Jetzt fehlt mir n bisschen was
22:15
aus Schema a. Also wir müssen jetzt irgendwie
22:17
gucken, dass wir das irgendwie noch zusammenfügen.
22:19
Und wenn du in diesem Hamsterrad drin bist.
22:21
Ja. Dann Gnade dir Gott.
22:24
Also dann ist halt wirklich n Teufelskreis eröffnet, weil
22:29
keiner mehr am Ende wirklich weiß, was will ich hier
22:31
wirklich, was brauch ich, was muss ich tun und dann wird es
22:35
halt richtig. Richtig tricky und vor allem
22:38
frisst es Zeit. Also es ist dann kein effektives
22:41
Arbeit mehr in meinen Augen. Na du bist ja dann, und das ist.
22:43
Halt keine Seltenheit, dass sowas passiert.
22:45
Und du bist ja dann irgendwann in so einem.
22:47
Wünsch dir was. Zirkel gefangen, wo dann
22:51
irgendwie am besten kommt noch noch jemand anders mit rein und
22:55
sagt ja das wär aber auch noch gut.
22:56
Eigentlich muss es so sein und dann?
23:00
Dreht sich alles nur noch kreuz und quer durch die Gegend?
23:04
Aber ja, du. Verlierst halt das Ganze aus den
23:06
Augen so. Ne genau, und das fühlt genau
23:09
das ist halt wirklich schwierig, weil im Endeffekt bringt es halt
23:13
nichts, weil du verlierst. Halt Zeit und du verschwendest
23:18
halt Geld. So und schwierig wird es dann
23:21
und das ist halt meine Erfahrung, die ich öfter mal
23:24
gemacht habe. Ich sag nicht, dass das immer so
23:26
ist, aber ich habe durchaus die Erfahrung auch gemacht.
23:31
Dass im Endeffekt du vielleicht Zeitdruck hast und wenn du
23:35
Zeitdruck hast, habe ich die Erfahrung gemacht, dass.
23:38
Die Anforderungen zusätzlich sogar schwammig formuliert
23:41
werden, weil Leute es schnell haben wollen.
23:43
Leute wollen schnell Feature X haben, machen sich aber aus
23:48
Gründen der vielleicht zeitprobleme noch weniger
23:50
Gedanken darüber, wie sich Feature X irgendwie verhalten
23:54
soll. Genau das zum Beispiel hier mit
23:57
diesem Milchhohe Fahrradbeispiel.
24:01
Da wird dann nicht über Eventualitäten nachgedacht, über
24:05
Sachen, die eventuell passieren könnten und wie man damit
24:08
umgehen soll. Und dann kommt es genau zu dem
24:12
Punkt, dass du schnell was implementierst, das dann halt
24:15
eben nicht ganz vollständig ist. Du wieder eine Runde drehst,
24:21
dann noch mal in die Gespräche kommen musst, überlegen muss,
24:23
was passiert denn hier, es wird wieder schnell, schnell, schnell
24:25
gemacht, du implementierst es wieder, schnell, schnell,
24:27
schnell und am Ende drehst du halt, anstatt eine ordentliche
24:30
Runde 3. Runden, die einfach nur Waste
24:34
waren und hast am Ende aber doppelt so lang gebraucht und
24:37
das sieht man aber am Anfang vielleicht nicht so ne.
24:39
Also es wird am Anfang gerne mal übersehen.
24:41
Meiner also meine Erfahrung nach ich sag nicht, dass es immer so
24:44
ist und dass es bei jedem. Auf dieser Welt, so ist aber es
24:48
ist halt die Erfahrung, die ich dabei gemacht hab und das ist
24:51
halt schwierig. Ja.
24:56
Bearbeiten möchte also mal als kleines Beispiel ne, wenn sagen
25:00
wir mal du hast n irgendein System ne Anwendung wo du dich
25:06
als User registrieren kannst. Ne dann ist es erstmal ja
25:10
überhaupt gar kein Problem zu sagen du hast vielleicht
25:13
Anforderungen an die Systemen die sich sukzessiv aufbauen, es
25:17
ist ja kein Problem zu sagen, ey du kannst dir ein user Profil
25:20
anlegen, das ist die erste Anforderung die wird gemacht in
25:23
einer Iteration sage ich jetzt mal ne wenn wir jetzt.
25:26
Einem agilen Umfeld sind aber du hast einen gewissen Zeitumfang,
25:29
vielleicht wo du sagst oder eine gewisse Planung und sagst in
25:33
diesem Planungszyklus sage ich mir jetzt, ich möchte gerne,
25:36
dass man sind jetzt sehr kleine arbeitspakete oder sehr grobe,
25:41
grob gefasste arbeitspakete User anlegen kann.
25:43
So, dann möchtest du zum Beispiel okay du möchtest, dass
25:46
du noch ein Bild anlegen kannst, also ein User Profilbild anlegen
25:50
kannst. Dann als nächstes sagst du noch,
25:52
ich möchte auch noch, dass der User sein Profilbild ändern
25:55
kann, das sind ja. Klare Anforderungen, die nach
25:58
im. Im Nachhinein sag ich jetzt mal
26:00
sukzessiv formuliert werden und die kannst du auch super
26:03
abarbeiten und deine Software im hoffentlich im Normalfall gut
26:07
erweitern, ne? Alles kein Problem.
26:11
Schwierig wird es eher, wenn man sagt, OK, wie soll die
26:15
Anforderung für das Profilbild denn sein, ne, und du sagst zum
26:18
Beispiel ja, das Profilbild darf nur die und die Größe haben und
26:22
es wird auf jeden Fall nur ein Bild sein.
26:26
Und das ist wirklich eine feste Anforderung an diese Software.
26:30
Und dann kommt aber vielleicht sowas wie übrigens eine Sache
26:34
wäre dann doch noch ganz wichtig, vielleicht auch ein
26:36
bisschen später. Das Profilbild müsste jetzt doch
26:41
ein Video sein können. So, und da könntest du halt
26:46
unter Umständen Teufels Küche sein oder kommen, weil klar kann
26:50
man jetzt sich hinstellen und sagen, naja gut okay, du hast
26:53
aber jetzt es ist auch eine sukzessive Änderung, es kann
26:57
aber durchaus auch sein, dass also das ist finde ich dieser
27:00
kleine Unterschied zwischen es ist eine sukzessive Änderung
27:03
oder du legst von vorne herein wirklich Grundpfeiler fest und
27:08
das ist jetzt vielleicht nicht ein starkes Grundpfeiler, sowas
27:11
kann man ändern dieses Beispiel. Aber je stärker sich quasi oder
27:15
je stärker diese Grundpfeiler im Boden verankert sind, desto
27:18
schwieriger wird es halt eben diese Änderungen zu machen.
27:22
Und das ist halt schwierig. Ja.
27:25
Und in unserem Halt mit mehr Aufwand wieder verbunden.
27:28
Genau, genau und prinzipiell klingt das jetzt erstmal an sich
27:33
jetzt nicht, nicht nicht schwer. Ne du sagst OK ne Speicher
27:37
anstatt n Bild halt einfach n. N Video kann man natürlich auch
27:41
machen. Es kommt vielleicht n bisschen
27:42
drauf an, wie wie man sozusagen die Speicherung von dem
27:46
Profilbild oder Video dann am Ende gewählt hat.
27:49
Ne kommt dann n bisschen drauf an, aber im Endeffekt ist es ja
27:52
jetzt auch ne Änderung, die durchaus möglich ist.
27:54
Aber ich sag nur mal rein theoretisch könnte es ja
27:57
vielleicht auch. Unter anderen Umständen dazu
28:01
kommen, dass bestimmte Änderungen reinkommen, die
28:03
vielleicht wirklich einschneidend sind, so dass du
28:05
dann nicht mehr so einfach in der Lage bist, diese
28:08
Anforderungen zu ändern, weil sie halt eben in dem
28:11
Grundgedanken dieser Anforderungen vielleicht auch
28:14
verankert sind. Ja, und das also was was du
28:19
meinst. Damit ist quasi wenn im Vorfeld
28:21
das schon weiter oder konkreter überlegt worden wäre, dass dann
28:26
halt so Breaking Changes vermieden werden könnten, genau
28:30
oder worauf möchtest du da mal hinaus?
28:32
Ja also du kannst natürlich, du kannst dich natürlich hinstellen
28:35
und sagen, gut ich also du ich find das ist ja.
28:39
Da spielen ja 2 Sachen ineinander, finde ich, weil auf
28:43
der einen Seite hast du die Anforderungen, die vielleicht
28:46
nicht gut gestellt wurden, ne oder beziehungsweise vielleicht
28:49
auch im Vorfeld nicht gut überlegt worden, weil ne man
28:51
könnte sich auch hinstellen und sagen naja pass auf.
28:55
Lass uns mal ein Bild und ein Video machen, weil wenn du
28:58
gerade vielleicht dabei bist und das fertig.
28:59
Gerade in dem Moment fertig hast und dich dafür entschieden hast
29:02
und eine Rückfrage gestellt hast, soll es wirklich nur ein
29:04
Bild sein? Ja, es soll nur ein Bild sein
29:05
und du gehst davon aus, dann musst du ja vielleicht nicht
29:09
deine Software dafür auslegen, dass du auch ein Video speichern
29:12
kannst. Ist ja nicht notwendig und wenn
29:15
du wirklich mit Sicherheit weißt vom Stakeholder, das muss nur
29:18
ein Bild sein, alles gut, dann kannst du dich genau darauf auch
29:20
einigermaßen anpassen, vielleicht auch
29:22
speicheroptimierung, was auch immer, aber wenn du jetzt und
29:26
wenn wenn du dann sagst, ist es wirklich so.
29:28
Ja es ist wirklich nur ein Bild, dann machst du das.
29:32
Das Feature ist fertig und dann kommt weißt du was eigentlich
29:35
doch ein Video, das ist halt blöd, weil dann drehst du wieder
29:38
diese Runde musste es noch mal umändern und.
29:40
Längst halt Zeit, weil wenn du das im Vorfeld gewusst hättest,
29:44
so, ich mein jetzt ist es n Unterschied, wenn jetzt nach n
29:46
Jahr später jemand kommt und sagt Ey der Markt gibt es her,
29:50
wir müssen das ändern, es ist unglaublich wichtig jetzt n
29:52
Video als profilbild auch zu haben ist das find ich auch ne
29:55
andere Geschichte ne? So ja ist n wichtiger Punkt.
30:01
Ich würd mal noch mal an unserem Haus weiterbauen, damit man sich
30:04
das besser vorstellen kann. Das ist ja genau so, als wenn du
30:09
sagst, OK, ja gut, ich spezifizier jetzt weiter meine
30:11
Anforderungen und übrigens ich würde gerne ich möchte gerne
30:16
heizen in den Räumen. Und du sagst du ja okay kann die
30:21
Heizkörper an die Wand machen können Fußbodenheizung machen
30:25
was du möchtest. Ja du ich glaube so Heizkörper
30:29
ist cool. Ich brauche keine
30:32
Fußbodenheizung. Gut, dann wird das Haus gebaut,
30:36
so bodenestrich wird alles gegossen, fertig, Bodenbelag
30:40
drauf, was auch immer, ist nicht spezifiziert.
30:44
Und dann sagt der Kunde auf einmal.
30:48
Aber weißt du, so eine Fußbodenheizung ist doch
30:51
ziemlich geil. Komm, das machen wir noch.
30:54
Und dann fängst du an zu schwitzen und denkst dir so ja
30:58
okay. Aber wir haben doch jetzt schon,
31:00
der Boden ist fertig, ich muss das jetzt alles wieder
31:03
rausreißen, um da diese Matten oder was auch immer zu verlegen.
31:08
Why fällt dir das jetzt erst ein?
31:10
Das ist n riesen Umbau, ich glaub der Mitarbeiter kommt da
31:13
reinzuschwitzen. Der wirft sein Leis Werkzeug in
31:16
die Ecke und das nie wieder gesehen.
31:19
Ich bin raus, baust doch selbst. Nee, aber um das mal quasi so in
31:23
den in alltägliches Beispiel zu kippen.
31:28
Das für Schweiß und Arbeit bedeuten könnte.
31:30
Dann und vor allem auch finanziell, das ist ja auch
31:33
immer in so Projekten ein riesen Punkt, weil Zeit ist Geld und
31:37
wenn du da lange brauchst, um das geben wir jetzt mal nicht
31:39
von den Materialien aus, jetzt wie beim Handwerk, aber in der
31:43
Softwareentwicklung was das an Geld kostet das denn alles
31:46
wieder umzubauen, nur weil am Anfang sich die Anforderungen
31:49
nicht genau überlegt wohnen und du siehst ich mag dein
31:53
Hausbeispiel, da kann man gut dran erklären, das ist ja aber
31:56
auch genauso. Auch noch mal das Hausbeispiel,
31:59
das ist nämlich gar nicht so so so unrealistisch.
32:02
Ich habe sehr oft überlegt, dass ein Projekt gestartet wurde, es
32:06
gab ein Big Picture, das heißt, es gab eine Vision, was das Tool
32:11
oder die Softwarelösung am Ende können soll.
32:15
Das wurde sozusagen gepitcht. Ja.
32:18
Und los. Und du denkst dir so.
32:22
Und los. Dann werde ich jetzt anfangen,
32:25
das zu implementieren. Ja, ja, fang an los, ja habt ihr
32:29
irgendwie gibt es irgendwelche Anforderungen daran, was ich
32:32
berücksichtigen soll? Na ja, das was es können soll.
32:35
Aber so richtige Anforderungen haben wir noch nicht.
32:38
Und dann kommt das, was immer sehr gefährlich ist.
32:41
Die werden aber noch kommen, ja, wir haben sie jetzt noch nicht
32:44
aus Zeitgründen, aber wir werden die Anforderungen nachreichen
32:46
und mach erstmal ohne Anforderung implementier doch
32:49
erstmal ohne Antwort, du weißt ja wo es hingeht soll und ich
32:52
schwöre dir in vielen Projekten in denen ich gearbeitet habe,
32:56
war das der Fall und auf Twitch hatten wir da auch mal eine
32:59
Diskussion und ich fand es so krass, dass es anderen
33:01
Entwicklern genauso geht, dass sie sagen, welche Anforderungen
33:05
kann es froh sein, wenn du überhaupt Anforderungen hast.
33:07
Ich meine, dann braucht man sich doch auch nicht wundern.
33:11
Dass es so oft an den potenziellen späteren
33:14
Anforderungen daran vorbei geht, ja, das ist doch, das ist ja
33:17
eigentlich, das ist doch so logisch, und da haben wir wieder
33:20
Theorie und Praxis, es ist so logisch in der Theorie, dass das
33:23
nicht gut gehen kann. In der Praxis wird es doch oft
33:26
so gelebt, ja genau, also dass das Ding ist, man will sich ja
33:31
nicht hinstellen und sagen, also mein Klemmer an der ganzen
33:34
Geschichte. Ist das oftmals von
33:36
Anforderungen. Seite jetzt aus meiner
33:38
Entwicklersicht eine Anforderung kommt und gesagt wird, mach das
33:43
mal so, dann hast du vielleicht zu wenig Informationen.
33:47
Du fragst vielleicht noch nach, es dauert, es ist alles nicht
33:51
klar, du entwickelst vielleicht, dann war es das doch nicht so,
33:53
wie wie es gedacht worden ist, weil die Anforderungen falsch
33:57
gestellt worden sind. Mal als Beispiel kann ja auch
33:59
passieren, jemand sagt Anforderungen so und so und
34:02
merkt dann. Mal.
34:05
So wollte ich das ja gar nicht. Ist ja irgendwie blöd gelaufen
34:07
so, aber wenn du dann an diesem Punkt kommst, wo du dann sagst
34:10
okay, jetzt habe ich es aber irgendwann fertig, dann kommt
34:12
von sag ich mal vom von Stakeholder sich kommt dann um,
34:16
dort ist alles so lange so und dann denke ich mir so es ist
34:18
halt ich lehne mich jetzt mal aus dem Fenster, das ist eine
34:22
Frechheit weil man schiebt die Schuld von sich weg und sagt
34:26
Pass mal auf Leute ja was dauert bei euch so lange aber ich
34:30
möchte gerne ein großes Haus aber was dauert das so lange so
34:34
und das ist halt das das sowas nervt mich persönlich halt
34:38
einfach. Weil es ist ja wichtig, dass man
34:40
halt einfach also ne, wenn die eine Seite das Beste geben soll,
34:44
dann sollte die andere Seite genauso das Beste geben und dann
34:46
kann da was draus werden. Es ist ja auch nicht so als
34:48
würde man ne. Es kann natürlich auch durchaus
34:50
sein, dass die Anforderungen perfekt gestellt werden.
34:53
Das softwareentwickelnde Team aber sich denkt, wir bauen jetzt
34:57
unsere Software so blöd, dass sie überhaupt nicht gut
34:59
erweiterbar ist, nicht gut wartbar ist.
35:01
Man kann mit dieser Software eigentlich überhaupt nichts mehr
35:03
machen. So, wenn also changes
35:05
reinkommen, ne. Und das ist natürlich auch blöd,
35:08
ne, weil es ist, es ist ja, es ist ja wichtig, dass man sagt,
35:12
OK, es ist n Unterschied zwischen fehlende Anforderungen
35:15
oder Du hast Anforderungen die sich im Verlaufe des Projektes
35:19
ändern. Ne das ist das ist das ist n.
35:22
Feiner, aber feiner Unterschied, der unglaublich wichtig ist,
35:24
weil wenn wir in einem agilen Softwareentwicklungsumfeld
35:27
unterwegs sind, können sich die Anforderungen ändern.
35:30
Das ist gar kein Problem, sag ich jetzt mal.
35:32
Ne, also es kann durchaus sein, dass dass sich, dass sich Sachen
35:35
verändern, aber nicht während einer Feature Entwicklung, also
35:40
oder nicht um 180 Grad, das ist halt ein kleiner Unterschied und
35:44
das ist halt ein absoluter Struggle, weil du kannst dich
35:46
natürlich auf der anderen Seite hinstellen und sagen Wir sind
35:49
hier im agilen Softwareumfeld alles cool, ich kann machen was
35:51
ich will, ich kann meine Anforderungen ändern.
35:53
Wir reagieren doch ganz agil und schnell darauf.
35:59
Ja, das ist. Weißt du was?
36:00
Ich weiß halt auch schwierig, also ich, ich weiß absolut was
36:03
meins ist. Das Thema dabei ist, wir sehen
36:07
das natürlich viel aus Entwicklersicht, weil wir ja
36:09
auch Entwickler sind. Ich möchte da nur anmerken, es
36:14
ist aber auch nicht einfach. Ich denke, das hat man auch
36:17
jetzt hier in der Folge schon herausgehört, vernünftige
36:20
Anforderungen zu definieren oder ein Feature Wunsch so klar zu
36:24
definieren, wie man es gerne hätte, weil man halt vieles
36:27
berücksichtigt. Man muss auf fairerweise sagen,
36:31
und das ist auch dann nicht mehr die Aufgabe des Stakeholder, sag
36:35
ich mal. Dass man ja auch nicht weiß, was
36:38
das für die Software alles bedeutet.
36:40
Also ich, ich definiere ja auf oberster Ebene quasi ein eine
36:45
Funktionalität beispielsweise, die ich gerne noch on top hätte
36:48
in der Software. Ja.
36:49
So bin aber ja nicht derjenige, der unter der Haube weiß, wie
36:54
das alles entwickelt wurde und was daraus resultieren könnte.
36:59
Also es ist ja schwierig, quasi den Einblick zu haben, geht das
37:03
überhaupt so richtig, so einfach wie ich das hätte, wie ich das
37:06
mir wünsche oder oder was bedeutet das, das ist ja auch
37:09
nicht mal die Anforderung, weil du entwickelst das ja auch
37:12
nicht, das Tool. Spezifisch zu sagen, welches
37:16
Verhalten soll denn wann wie eintreten oder wie soll sich das
37:20
Feature verhalten, das liegt ja schon in deiner Verantwortung
37:24
und da muss ich sagen, wenn ich zum Beispiel so eine Anforderung
37:27
definiere, fällt mir das auch schwer, das immer sehr präzise
37:30
zu machen, weil du halt vielleicht Sachen voraussetzt,
37:33
die gar nicht gegeben sind, oder oder.
37:36
Einfach, dass man einfach Cases vergisst, wie du ja meintest.
37:39
Zu einer bekannten Edge Cases, die einfach sehr selten
37:41
auftreten, aber auftreten können und dann nicht klar ist oder
37:45
undefiniert ist, wie das Verhalten sein soll.
37:47
Und da muss ich sagen, es ist halt für beide Seiten schwer.
37:51
Und das spricht wiederum dafür, dass es eine sehr gute
37:54
Kommunikationsschnittstelle da geben muss in meinen Augen.
37:57
Definitiv. Also stimm ich dir total zu.
38:01
Ich kann auch noch mal. Mir fällt gerade ein kleines
38:03
Beispiel ein, also ich hab auch mal an einem Projekt gearbeitet.
38:08
Wo? Es gab eine Phase, wo
38:10
Anforderungen, also sagen wir mal User Stories gestellt worden
38:13
von den Stakeholdern an unser Entwicklerteam.
38:17
Und wir haben dann diese Stories besprochen, also überlegt ok,
38:22
bevor man sie richtig bearbeiten kann, werden diese Stories
38:24
einmal besprochen. Team und das wurde dann quasi
38:29
von unserem PM gepitcht. Er hat uns dann das vorgestellt,
38:32
weil er in meinem Austausch mit den Stakeholdern war und hat uns
38:36
dann gesagt Okay Pass auf das und das wird gewünscht so und
38:38
dann haben wir im Team diese Aufgaben besprochen und dann
38:41
hatten wir eine Phase, wo es sehr oft dazu kam, dass wir uns
38:44
dann überlegt haben, ja, aber was ist denn im Fall XY, das ist
38:48
ja hier überhaupt nicht definiert, ist aber unglaublich
38:50
essenziell für die Software. Weil wir sonst unter Umständen
38:54
für irgendwelche Einheiten, die wir sozusagen gehalten haben in
38:58
unserer Software undefinierte Zustände hätten.
39:01
Und das durfte halt einfach nicht passieren.
39:04
Demzufolge waren das sozusagen waren die Anforderungen nicht
39:08
klargestellt, was an dieser Stelle überhaupt nicht schlimm
39:10
ist. Wie du auch meintest, weil wir
39:11
haben das geklärt in diesem Termin, sozusagen im Team, haben
39:15
die Fragen noch mal definiert, und dann ist es noch mal
39:17
sozusagen zurückgegangen so, und in dem Fall hast du ja nicht das
39:21
Problem, dass du schon anfängst zu implementieren und dann aber
39:25
irgendwann merkst, oh mein Gott, hier ist gerade eine totale
39:27
Sackgasse, das geht gar nicht, das heißt, wenn die
39:29
Kommunikation stimmt, ist alles in Ordnung.
39:31
Nur wenn wir an den Punkt kommen, dass wir dann wirklich
39:33
schon anfangen, eventuell merken, warte mal, hier stimmt
39:36
irgendwas nicht und das hatte ich auch schon in dem gleichen
39:38
Projekt. Du fängst an, du implementierst
39:41
etwas, kommst selber erst an diesem Punkt, dass du dir
39:44
denkst, Moment, was passiert in diesem Fall durchaus möglich und
39:49
dann ging das noch mal zurück und dann wurde.
39:53
Aber ganz andere. Also dann haben sich die
39:54
Anforderungen wirklich sehr, sehr gedreht, weil die sich
39:56
selber dann gedacht haben, oh hey Mist, was ist das denn, das
40:00
können wir so wirklich nicht machen und dann hast du halt.
40:03
Wirklich. Und dann kommt halt die Unruhe
40:04
rein. Ne, dann bist du wieder in den
40:06
Teufelskreis. Und dann hast du aber wirklich
40:07
ne Menge Zeit auch versenkt. In dem Fall war es dann wirklich
40:10
so, dass die Anforderungen noch mal durchgegangen sind, nochmal
40:13
wirklich überlegt wurden und dann nochmal in unser Team kam.
40:17
Wir haben das dann im Endeffekt bearbeitet, aber der Punkt an
40:20
dieser Stelle ist, dass diese Entwicklungszeit, die wir vorher
40:23
genutzt haben, halt wirklich waste war.
40:26
Und wir hatten in dem Moment nicht großartigen Zeitdruck.
40:29
Es war soweit okay, aber wenn du jetzt dir noch vorstellst, dass
40:32
Zeitdruck hinzukommt und ich vermute mal, dass einige, die
40:35
auch zuhören, Liebe zuhören, lieber zuhören.
40:39
Sicherlich auch mal in Projekten arbeiten oder gearbeitet haben,
40:42
wo Zeitdruck da ist, weil dann wird es nämlich, dann wird es
40:45
nämlich wild. So einer Stelle.
40:51
Ja, das n ganz guter Punkt auch, weswegen in der agilen Welt ja
40:58
es Termine dafür gibt, sogenannte Refinements, um
41:02
einfach denn noch mal sich diese Requests oder Feature wünsche
41:06
sich anzuschauen, drüber zu sprechen um wirklich ein
41:10
gemeinsames Verständnis davon zu schaffen und sich dann darauf
41:14
festlegen zu können wie es sein soll und wie ihr dann in dem
41:18
Termin gemerkt habt oder beziehungsweise beide Seiten
41:21
dann gemerkt haben, sowohl der Stakeholder mit seinem Wunsch.
41:25
Der gemerkt hat, oh Moment, ich habe es mir nicht final überlegt
41:28
und ihr euch schon mal Gedanken machen konntet und gemerkt habe
41:32
ja, aber Moment für unsere Software, ich meine das kannst
41:35
du nicht wissen von außen, aber es ist für uns wirklich wichtig
41:37
zu wissen was in dem und dem Fall passieren soll und dafür
41:41
ist so ein Termin ja super, dass das Ganze dann noch mal
41:43
durchgesprochen werden kann um halt nicht diese Zeit zu
41:47
verbrennen am Ende. Ja.
41:50
Das ist halt ein sehr essentieller Punkt und wichtig
41:53
und deswegen auch bei so agilen Frameworks berücksichtigt.
41:56
Genau. Also.
42:02
Hast du noch was, was dir gerade spontan einfällt?
42:04
Ansonsten würde ich dich einfach mal fragen.
42:07
Nein, also ich denke ich denke das Ding ist es.
42:11
Ist ein Thema, da kannst du sehr lange drüber reden und wir haben
42:13
ja auch wie gesagt so in Twitch Sessions schon mit unseren.
42:18
Mit unserer Community drüber gesprochen und da uns
42:21
ausgetauscht, weil es, was ich erstaunlich finde, aber auch
42:25
nicht verwunderlich ist, dass es bei vielen zu Problemen dabei
42:28
kommt. Es nie so quasi so eine heile
42:33
Welt gibt von. Also ich kriege mal
42:35
Anforderungen, die sind so super, ich kann das einfach
42:37
direkt runter coden, alle sind glücklich, alle sind zufrieden,
42:41
so läuft es halt in den wenigsten Fällen, weil es halt
42:43
einfach auch ein schwieriges Thema ist, viel mit
42:45
Kommunikation zu tun hat und ja man sich, ich glaube was da
42:50
hilft ist sich immer ein bisschen in die Lage des anderen
42:52
zu versetzen, das heißt beim Entwickeln sich nicht denken, Oh
42:56
jetzt ist das schon wieder so Scheiße spezifiziert, ich weiß
42:58
schon nicht was ich tun soll hier, sondern sich auch mal
43:01
überlegen, ja gut, hätte ich denn daran gedacht?
43:03
Von der anderen Seite ja, und genauso als Anforderer, also als
43:08
Stakeholder zu sagen, ja warte mal, könnte ich jetzt ganz
43:12
objektiv, wenn ich dieses Ticket zum Beispiel lese oder diese
43:15
Anforderung, könnte ich das entwickeln, was ich da
43:18
aufgeschrieben hab, und wenn da die Antwort nein ist, weiß man
43:21
ja schon, ja gut, da muss ich da wohl auch noch mal ran.
43:25
Genauso ist es und dabei würde ich es.
43:27
Genau, warte ganz kurz. Genauso ist es auch wichtig,
43:30
dass die Anforderungen, die gestellt werden, auch nicht in
43:33
ewig langen Texten runtergeschrieben werden, zum
43:36
Beispiel. Also das ist jetzt noch mal eine
43:38
persönliche Erfahrung, die ich gehabt habe, die ich gemacht
43:41
habe, das ist auch wichtig, du meintest ja, es muss
43:44
verständlich sein und es muss irgendwie klar sein, was gewollt
43:47
ist für jeden, auch objektiv im optimalen Fall, es ist aber auch
43:51
wichtig, dass es auch nachvollziehbar ist.
43:54
Und wenn es ein riesen Text ist, wo man erst mal Ewigkeiten
43:57
durchlesen muss, was gemeint ist und es nicht sozusagen in
44:00
ordentlichen Punkten aufgelistet ist, sage ich jetzt mal, blöd
44:03
gesagt einfach, dass man sich vorstellen kann.
44:06
Dann ist es halt eben schwierig. Und was ich auch sagen könnte
44:09
ist, dass man zum Beispiel die entsprechenden Anforderungen,
44:12
wenn sie denn auch klar aufgeschrieben worden, in
44:14
welcher Art und Weise, dass sie auch, dass man aus externer
44:18
Sicht die Möglichkeit hat, das zu prüfen.
44:21
Mir diese Anforderungen, so wie sie gestellt ist, wirklich in
44:24
meiner Software am Ende, das ist auch wichtig und den Punkt, den
44:28
wir am ersten. Mal das ganze evaluieren.
44:30
Kann genau also wenn ich jetzt zum Beispiel Softwareentwickler
44:32
bin und ich kriege eine Anforderung, dass ich dann ich
44:34
implementiere das und sage zum Beispiel keine Ahnung, wenn ich.
44:39
Weiß ich nicht. Angenommen ich, ich leg mir n
44:41
user Profil an, dann möcht ich danach, dass ich sozusagen ne
44:44
grüne Bestätigung habe, mein Userprofil wirklich da ist.
44:47
Ne, das heißt rein theoretisch könntest du jetzt als
44:49
Softwareentwickler sagen, OK, wenn ich das jetzt mache in der
44:51
Oberfläche die ich geschrieben hab.
44:53
Dann sehe ich hinterher eine grüne success Nachricht und kann
44:57
vielleicht auch in meiner also Datenbank, die lokal einfach für
45:01
mich in der Entwicklung läuft, nachgucken ob wirklich der User
45:03
entstanden ist oder nicht nur mal als als Beispiel ne das sind
45:07
wichtige Sachen die wo man einfach selbst für sich
45:09
überprüfen kann funktioniert das auch und was auf jeden Fall, das
45:14
möchte ich noch mal sagen, weil das ist mir sehr wichtig.
45:18
Anforderungen in kleinen Paketen stellen hilft ungemein.
45:25
Ja, also da gibt es ja wie gesagt was du meintest so kurz
45:29
fassend, so, da gibt es ja auch verschiedene Formate, wie man
45:33
Anforderungen stellen kann oder aufschreiben kann, weil du ja
45:36
vorhin schon das Wort userstory fallen lassen hast.
45:40
Es gibt Akzeptanzkriterien werden oft verwendet, um zum
45:43
Beispiel das auch Testbar zu machen, zu sagen, OK, was muss
45:46
denn erfüllt sein, damit die Anforderungen im im Ganzen
45:50
erfüllt ist. Da gibt es ja verschiedene
45:52
Möglichkeiten und Tools, die dabei helfen, das ganze Halt zu
45:55
optimieren und trotzdem gibt es immer noch Probleme dabei.
45:59
Deswegen, liebe Zuhörer, lieber Zuhörer, falls sich das Thema
46:02
interessiert, wie kann man denn Anforderungen gut aufschreiben?
46:05
Was sind akzeptanzkriterien, was gibt es da noch so, dann melde
46:10
dich gerne bei uns, dann können wir auch gerne da noch weitere
46:13
Infos bereitstellen oder vielleicht noch eine weitere
46:15
Podcast Folge zu dem Thema machen, ansonsten würde uns
46:18
brennend interessieren, wie deine Erfahrungen, falls du da
46:21
welche gesammelt hast sind. Was hattest du so für
46:24
Erlebnisse, vielleicht auch witzige Fälle in Kombination mit
46:28
Anforderungen und. Dass beispielsweise komplett
46:31
dran vorbei implementiert wurde, wie wir das erwähnt hatten,
46:35
schreibt uns gerne, zum Beispiel auf der Podcast Mail oder auf
46:38
den anderen Plattformen. Die Links sind wie immer in den
46:40
Shownotes. Dort findest du alle und
46:43
ansonsten würde es uns natürlich auch freuen, wenn du unseren
46:46
Podcast weiterempfehst. Falls er dir gefallen hat, so an
46:48
mindestens 23 Freunde, das wäre super, um die Anforderungen mal
46:51
konkret zu machen, wo jetzt war das Wort mindestens drin.
46:56
Und ansonsten würde ich sagen, haben wir uns alle beim nächsten
46:59
Mal wieder. N schönen Tag noch und bis dahin
47:04
deine Coding Buddies gemeinsam. Besser.