Latest / Coding Buddies | Tech & Dev-Mindset / Durchstarten mit Extreme Programming

Transcript

Durchstarten mit Extreme Programming · Coding Buddies | Tech & Dev-Mindset

0:00
Im Endeffekt, jeder wollte irgendwie nach Scrum arbeiten,
0:02
egal in welchen Bereichen. Und das ist halt auch wirklich
0:05
ne klare Abgrenzung zum XP. Niemand möchte von XP Coding
0:10
Buddies Dein Podcast rund um Softwareentwicklung und
0:13
aktueller Tech News. Herzlich Willkommen.
0:28
Halli Hallo und herzlich Willkommen zur neuen Folge des
0:30
Coding Bodys Podcast. Schön, dass du wieder
0:32
eingeschaltet hast, deine Gastgeber.
0:34
Und wie soll es auch anders sein, sind meine Wenigkeit Tino
0:37
und auch der fantastische Fabi, den ich hier begrüßen möchte.
0:40
Fabi, Was geht ab? Was geht ab?
0:43
Es ist Weihnachtszeit, jedenfalls geht es langsam los
0:46
mit der Weihnachtszeit und. Echt weiter geht es einem gut,
0:49
oder? Ja, da hast du mir jetzt direkt
0:51
den Aufhänger geklaut, weil ich wollt mal fragen, ob du schon so
0:54
in Weihnachtsstimmung bist. Also wir haben nämlich jetzt
0:56
Dezember den letzten Monat des Jahres.
0:59
Es geht sag ich mal in die Zielgerade und wie wie ist deine
1:05
Laune, wie geht es dir damit? Mir geht es gut, also ich weiß
1:09
nicht, ich komm eigentlich immer so n bisschen schwerer, so in
1:14
Weihnachtsstimmung muss ich sagen.
1:16
Von Jahr zu Jahr oder allgemein? So allgemein also gut, ich mein,
1:20
wenn du so 6 Jahre alt bist oder so, dann weiß ich nicht, da ist
1:23
man gefühlt seit September in Weihnachtsstimmung und weiß gar
1:26
nicht mehr wie lange es noch wieviel Jahre es noch gefühlt
1:28
dauern muss, bis wieder Weihnachten ist.
1:31
Aber ja, weiß ich nicht, irgendwann war das bei mir so n
1:35
bisschen weg, dass ich mir dachte, so geil jetzt irgendwie
1:37
so also ich, ich freu mich auf Weihnachten und ich mag die Zeit
1:40
total. Ja, aber irgendwie ist es so ein
1:43
bisschen, dass so weiß nicht diese vorweihnachtliche Zeit.
1:48
Also weißt du, dieses Weihnachten ist irgendwie so so,
1:51
ich denke mir immer so am 24 dann hoppala, ist ja schon
1:54
wieder Bescherung. Ja, die Zeit rennt.
1:57
Ne, hast du denn noch irgendwelche Jahresvorsätze, die
1:59
du jetzt noch ganz schnell umsetzen musst, bevor das Jahr
2:01
vorbei ist und die nächsten quasi kommt?
2:03
Warte, ich guck kurz nach. Guck mal auf deine Checkliste.
2:06
Ich hab ne ich muss, ich muss nur noch, ich muss nur noch 8
2:09
Bücher lesen dieses Jahr. Das geht ja, das geht ja.
2:13
Dann machen wir schnell, dann kannst du mich gleich
2:14
weiterlesen. Ach ja, aber so eine andere
2:20
Sache bist du eigentlich so ein Weihnachtsmarkttyp?
2:23
Man, warum stellst du so schwierige Fragen?
2:26
Weil man sich nicht auf die Folge einstellt, das wird ne
2:28
sehr komplizierte Folge ich denk ich denk mir immer so boah geil,
2:31
bald ist wieder weihnachtsmarkt, bald geht es wieder los ich hab
2:34
richtig Bock nen schönen Glühwein und dann gehst du auf
2:37
den Weihnachtsmarkt, das ist übelst voll, du kannst nicht
2:39
treten, du musst überall anstehen und ich denk mir nach
2:42
dem Glühwein oh Mann ich hab keinen Bock mehr echt so.
2:47
Man stellt sich so diese ideale Vorstellung.
2:49
Weißt du, es schneit, du bist warm angezogen, es ist total
2:52
cool, du stehst da mit deinen Freunden, trinkst einen
2:54
Glühwein, ne super Stimmung herrscht, aber am Ende wirst du
2:56
immer so dicht gequetscht und versuchst ja.
2:58
Möcht noch jemand Glühwein, weil ich würd mich schon mal
3:00
anstellen, weil es dauert so ungefähr ne halbe Stunde.
3:03
Ja genau dann wartest du bis irgendjemand wieder kommt, dann
3:05
ist es aber gefühlt schon halb wieder irgendwie, du hast nix
3:08
mehr seit ner halben Stunde und es regnet leicht und es regnet
3:12
leicht es sind. 12 Grad und es regnet in Deutschland.
3:16
Aber meistens gibt's einen, weil.
3:17
Weihnachtsmarkt besucht, der richtig gut ist im Jahr, warum
3:19
auch immer. Mindestens einer ist dabei.
3:21
Na gut, dann drücke ich dir die Daumen, dass der auch wieder
3:23
stattfindet, falls er noch nicht da war.
3:26
Also die sind ja schon geöffnet, na gut, dann würde ich sagen
3:31
werde ich mal das heutige Thema Anteasern, es ist
3:34
Weihnachtsmarkt, nein ich möchte mit dir heute über extreme
3:43
Programming. Lass es kurz wirken, reden und
3:49
es ist ja immer. Es war auch mal ne Zeit lang so
3:51
n richtiger Hype und viele also man hat es auch oft gelesen und
3:55
auch gerade so in den Anfängen als Softwareentwickler begegnet
3:59
der Begriff einem, aber man kann sich dann vielleicht nicht so
4:01
viel darunter vorstellen was dahinter steckt, deswegen würde
4:04
ich das gerne einfach mal so mit dir beleuchten und vor allem und
4:09
damit nehme ich es schon n bisschen vorweg, ich würde es
4:11
auch sehr gerne. Mal gegenüber Scrum abgrenzen,
4:15
weil da oft Parallelen gezogen werden.
4:17
Und es gibt natürlich auch Gemeinsamkeiten, aber auch viele
4:20
Unterschiede und das würde ich gerne einfach mit dir heute mal
4:23
der Sache auf den Grund gehen, ja.
4:25
Auf jeden Fall. Also das Ding ist klar, gibt es
4:27
Parallelen? Ich meine, es sind beides agile
4:29
Frameworks, die man verwendet, ich weiß nicht wie es dir ging,
4:33
so ich, ich weiß noch, dass ich irgendwann im Studium mal von
4:36
Extreme Programming gehört habe und ich.
4:40
Ich dachte mir damals also, ich konnte mir gar nichts drunter
4:42
vorstellen, ich hatte keine Ahnung, was das ist.
4:44
Das ist irgendwo in irgendeiner Vorlesung mal gedroppt und ich
4:46
dachte mir so, also ich saß da ne klein Fabi mit 6 Jahren nein.
4:52
Ja, der sich auf Weihnachten. Freut.
4:56
Also ich saß. Ich saß in der Vorlesung und
4:57
dachte mir, so, OK, was ist jetzt extreme programming, ich
5:00
hab das so richtig, also meine Vorstellungen haben sich ja
5:03
überschlagen, was extreme Programming ist, ne.
5:06
Also ich dachte so okay wenn du irgendwann mal irgendwann kommst
5:10
du aus der Uni raus, du gehst ins Arbeitsleben und irgendwann
5:13
machst du Extreme Programming. Da dachte ich, wenn man dahin
5:16
kommt, ne, dann bist du topnodch das ist ganz oben, da bist du
5:19
quasi der Rockstar der Softwareentwicklung.
5:23
Ja weißt du was ich meine? Aber ja klar und ist halt so
5:26
extrem dabei dann und das krasse war, dass ich irgendwann
5:30
tatsächlich an diesen Punkt gekommen bin, wo ich extreme
5:33
Programming gemacht habe, ne? Und dann kommst du halt auf die
5:37
harte Realität zurück und merkst erstmal, OK, du bist wirklich n
5:40
Rost. Ne, es ist jetzt kannst du nur
5:44
noch bergab gehen, jetzt hast du die Spitze erreicht nein, aber
5:47
es ist ja also ich kenn das Gefühl, weil ich dacht mir auch
5:51
was soll das sein also extreme, also bin ich dann so hart am
5:54
coden, dass ich stundenlang durchcode im Team und man so ne
5:58
super pace hat in der Entwicklung, dass du einfach
6:00
super schnell die Software rausknallst.
6:03
Aber es ist am Ende, das hast du ja jetzt schon gesagt, auch nur
6:06
in Anführungszeichen. Ein agiles Framework, was
6:08
gewisse Methoden und vor allen Dingen, wie soll ich sagen, ein
6:14
gewisses Mindset mit sich bringt, worauf es am Ende
6:16
ankommt und. Genau das würde ich jetzt sehr
6:19
gerne mit dir, wenn du bereit bist, beleuchten, dann hole ich
6:23
mir noch ein Kaffee, aber also weil du ja meintest, es gibt.
6:29
Verschiedene Methoden, nach denen du arbeitest, ne.
6:31
Und es sind natürlich auch Methoden oder Praktiken, die
6:35
auch wirklich interessant sind. Muss man ja auch sagen.
6:37
Also es ist ja auch schon ne ne spezielle Art.
6:42
Also wenn du jetzt zum Beispiel sagst, OK ne, du hast Sport und
6:45
du hast Extremsport, dann ist es schon was anderes ne klar ist es
6:49
jetzt nicht irgendwie so damit zu vergleichen, dass du
6:52
irgendwie. Weil sie nicht bis an dein
6:55
absolutes Limit gehst. Aber ich kann ja schon mal
6:57
vorwegnehmen, dass es schon bestimmte Praktiken gibt.
7:00
Oder wenn man nach diesem Framework arbeitet, dass man da
7:03
auf jeden Fall schon eine gewisse Disziplin braucht.
7:06
Also es ist nicht trivial, sozusagen da wirklich danach zu
7:09
arbeiten. So, und demzufolge macht es das
7:12
auf irgendeine Art und Weise schon vielleicht extrem.
7:17
Ja, hast du recht, hast du recht, aber dann lass uns doch
7:21
mal reinstarten. Extreme Programming was steckt
7:26
dahinter und was sind so die Prinzipien?
7:27
Weil wir haben ja jetzt gesagt, es ist ein agiles Framework,
7:31
kurz für alle Faktenfreunde, also es ist so in den Neunzigern
7:35
entstanden, durch Candback entwickelt, auch ein sehr
7:39
bekannter Name in der Welt der Softwareentwicklung, und das
7:45
Ziel war, den Fokus mehr auf die Teamarbeit zu richten, dass man
7:49
auch ein schnelleres Feedback bekommt in der Entwicklung.
7:53
Und vor allem das ist ja auch oft so, ein so ein Ansatz, den
7:57
man verfolgt, dass man kontinuierlich besser wird, das
8:00
heißt, gerade durch dieses schnelle Feedback, es schafft
8:04
seine Prozesse, seine Arbeitsweisen immer weiter zu
8:07
optimieren, um so kontinuierlich sich zu verbessern im Laufe der
8:11
Entwicklung, dass man so da war, so der Fokus drauf und.
8:15
Und ich glaube auch, was man nicht vernachlässigen sollte,
8:18
war auf jeden Fall auch eine hohe Codequalität, die dann
8:21
sozusagen versucht wird, dadurch halt auch zu gewährleisten, was
8:24
natürlich immer schwierig ist zu sagen, finde ich, weil ich denke
8:27
mir so okay gibt es irgendwas, wo man sagt, ja, codequalität
8:31
ist uns eigentlich unwichtig, von daher ist es gefühlt
8:35
eigentlich immer irgendwo natürlich sehr erstrebenswert,
8:39
aber wie gesagt, durch bestimmte Praktiken, die wir auch später
8:42
noch ein bisschen erläutern wollen.
8:45
Ist natürlich die Codequalität. Damit soll es natürlich sehr,
8:48
sehr quasi gefördert werden oder gestärkt werden.
8:51
Die Codequalität und das Extreme, weil wir haben ja jetzt
8:57
also schon ein bisschen drüber gewitzelt, warum es extreme
8:59
heißt, aber es geht halt wirklich darum, diese Werte,
9:01
auch diese agilen Werte, halt wirklich auf die Spitze zu
9:03
treiben, das heißt, man versucht jetzt eine Umgebung zu schaffen,
9:07
dass man genau diese Punkte bis ins Extreme.
9:12
Angehen kann und optimieren kann.
9:13
Das ist halt so am Ende der Punkt dahinter, warum warum es
9:18
so heißt wie es heißt, genau also man kann halt sagen, dass
9:22
so Werte wie Kommunikation im Vordergrund stehen, Einfachheit,
9:27
Feedback, Mut ist ein riesen Punkt der den finde ich halt
9:32
auch sehr cool daran, dass man sagt okay wir sind mutig und
9:35
gehen die Schritte um zum Beispiel diesen Fokus überhaupt
9:39
zu erreichen. Dass du sagst, wir haben jetzt
9:41
die und die Zielsetzung und wir sind mutig und probieren neue
9:45
Sachen aus. Wir sind mutig und ändern
9:47
Sachen, das sind ja extrem wichtige Punkte und dabei spielt
9:51
dann auch Respekt immer mit rein zu sagen, wir respektieren auch
9:56
Entscheidungen, wir respektieren Sachen, dass die geändert werden
9:59
müssen, das finde ich halt cool, genau Meinungen.
10:04
Auch wieder. Stichwort Teamarbeit, dass da
10:06
auch viel Respekt herrscht, und das klingt ja so erstmal alles
10:12
ganz cool, auf jeden Fall. Also wenn ich das jetzt so hören
10:15
würde, als Einsteiger oder einsteigerin, würde ich mir
10:17
denken, ja, klingt nach einem sehr coolen Framework, es ist
10:20
auch n cooles Framework und es hat auch coole Kernprinzipien,
10:23
auf die ich noch mit ihr eingehen möchte, damit man
10:24
einfach noch besser abstecken kann, was sich jetzt dahinter
10:27
verbirgt, aber das ist im Prinzip so, das agile Mindset
10:31
dahinter, was? Denke ich mal im Sinne von Kent
10:35
Back, dann entwickelt wurde ich. Finde irgendwie bei dem bei dem
10:38
Mut ich weiß nicht, muss da mal ein bisschen schmunzeln.
10:41
So wenn ich das lese so und sei auch mutig, aber ich ich finde
10:46
nachher kommt auch noch mal, wenn wir im Verlauf der Folge
10:49
noch mal darauf eingehen, also. Kann ich das vielleicht oder
10:54
Kümmels vielleicht auch noch mal n bisschen genauer irgendwie auf
10:56
den Punkt bringen, wo Mut zum Beispiel ne ne wichtige Rolle
11:00
spielt und dann ist es vielleicht nicht mehr ganz so,
11:01
weil wie gesagt, ich find ich find das klingt irgendwie
11:03
einfach so, immer wenn ich es lese denk ich mir so Mut.
11:07
Ja, also ich find halt gerade wenn man schon verschiedene
11:10
Projekte erlebt hat, wird man glaub ich diesen Punkt recht
11:13
schnell verstehen, wie wichtig der sein kann.
11:16
Je nachdem auch in welchen Strukturen man gearbeitet hat.
11:19
Aber es ist halt wirklich n sehr entscheidender Punkt am Ende.
11:22
Definitiv. Das auf jeden Fall.
11:25
Und also ich sag mal so, wenn wenn man jetzt von Extreme
11:31
Programming redet oder auch danach arbeitet, dann hat
11:34
Extreme Programming ja so bestimmte Prinzipien, nachdem es
11:38
sich orientiert. Das meinst du ja auch schon ein
11:40
bisschen so nach, dass man sagt okay man arbeitet halt, also man
11:44
versucht dieses agile auf die Spitze zu treiben und da können
11:48
wir ja noch mal jetzt ein bisschen gucken, was genau jetzt
11:50
eigentlich dahinter steht, also welche Punkte und.
11:54
Weil ich finde zum Beispiel ein hoher Punkt, den ich ja auch
11:56
schon mal angesprochen hatte, der auch im Fokus steht, ist ja
11:59
zum Beispiel eine hohe Codequalität, und da meinten wir
12:03
ja, OK, wie kann man das denn überhaupt gewährleisten?
12:05
Also du, wie gesagt, es ist Quatsch zu sagen, es gibt
12:09
irgendwie Bereiche, wo man sagt, Ey, Komm, codequalität ist uns
12:13
völlig egal. Ich glaube, ich habe das noch
12:14
nie gehört, wo sollte sowas auch irgendwie sein, ne das.
12:18
Aber man kann natürlich schon mit bestimmten Prinzipien dafür
12:21
sorgen, dass du vielleicht das ganze Forcierst und sagst okay,
12:24
wenn du danach arbeitest, dann ist die Wahrscheinlichkeit, dass
12:28
dein Code also höher qualitativ ist.
12:31
Am Ende ist einfach die Wahrscheinlichkeit ist höher,
12:33
als wenn man jetzt nach anderen Methoden arbeitet,
12:37
beispielsweise per Programming. Per Programming ist ja im
12:41
Endeffekt. Klingt vielleicht lustig.
12:43
Ich weiß nicht, ob es jemandem ein Begriff ist.
12:45
Man arbeitet im Endeffekt zu zweit, also 2 Entwickler oder
12:49
Entwicklerinnen arbeiten zusammen am gleichen Code und
12:54
ich fand das so lustig, weil als ich das das erste Mal gemacht
12:56
habe, habe ich das auch jemand mal klärt und es wird irgendwie
13:00
nicht so richtig verstanden, aber der Kernpunkt ist
13:03
eigentlich, ob du es remote machst oder vor Ort.
13:06
Ist es eigentlich so, dass du. Jeder hat einen Bildschirm,
13:08
jeder hat eine Tastatur und jeder hat eine Maus.
13:10
Aber das was du bedienst. Der Inhalt des Bildschirms ist
13:13
exakt der gleiche und damit arbeitest du halt eigentlich auf
13:18
dem gleichen Code, also alles was du zum Beispiel siehst, Tino
13:20
auf dem Bildschirm sehe ich auch so, also es ist einfach nur ein
13:23
gespiegelter Bildschirm mehr oder weniger und jeder kann
13:25
interaktiv darauf rumarbeiten und das witzige ist, dass man
13:30
natürlich dann auch relativ schnell, also ich glaube das
13:31
erste was dann irgendwann kam, so, ja dann kannst du ja dem
13:34
anderen die Maus wegnehmen. Ja, kannst du.
13:37
Du kannst dir mal die Maus wegnehmen.
13:38
Machst du zweimal, ist witzig und dann hörst du damit wieder
13:41
auf. Und irgendwann fängst du noch
13:43
mal damit an. Also Liebe zuhören, Liebe
13:47
zuhören, falls sich das Thema Pair Programming interessiert.
13:49
Wir haben dazu auch mal ne Podcast Folge gemacht, dann hört
13:52
das gerne mal rein, da wir auch selbst nach Pair Programming
13:56
arbeiten, haben wir das Ganze auch mal in der eigenen Folge
13:59
beleuchtet. Genau, aber der Grundpunkt ist
14:02
ja zumindest, dass du halt mit 4 Augen auf den Code guckst, nicht
14:05
mit 2, was zum Beispiel einfach von der Grundprämisse her sagt,
14:09
OK, die Codequalität wird zum Beispiel erhöht, ne, aber ich
14:12
weiß nicht, was gibt es denn noch so für was fällt dir ein,
14:15
was es noch so für Praktiken gibt bei XP, die für eine hohe
14:19
Codequalität zum Beispiel sagen. Na also, was damit auch
14:23
eingeführt werden sollte, wenn man sagt, man arbeitet nach XP
14:27
ist auch oft Test riven Development, weil gerade so Unit
14:31
Tests im Fokus stehen, dass man sagt OK jede Codeänderung und
14:34
jeder Code teil sollte Abgetestet sein um diese hohe
14:37
Code Qualität gewährleisten zu können.
14:39
Das ist nämlich auch der Punkt weil du meintest jeder möchte
14:42
Code Qualität ne hohe Code Qualität aber die Frage ist lebe
14:46
ich das auch und versuch alles um das zu gewährleisten oder ist
14:50
es eigentlich nur so ne Motivation zu sagen?
14:52
Ja, nee, ich möchte schon, dass mein Code von hoher Qualität
14:55
ist, aber eigentlich ja. Testest du alles ab.
14:58
Nö, testet mir nicht so wichtig weißt du also klar hat jeder
15:01
diese Motivation, aber es gibt dann halt auch mit Ton um das n
15:04
bisschen zu forcieren sozusagen und dann auch wirklich ne
15:06
bestmögliche Qualität zu erreichen und da zählt dann halt
15:10
Test Driven Development auch ein, gibt es ja auch immer so
15:14
Leute die da pro stehen oder Contra zu stehen wir sind Fans
15:17
davon und auch danach arbeiten wir.
15:20
Haben auch ne eigene Podcast Folge dazu gemacht.
15:22
Also Liebe zu lieber zu was, falls du da auch mal reinhören
15:25
möchtest, mach das sehr gerne, ist auch ne sehr coole Folge
15:27
damals geworden, aber zum Beispiel.
15:29
Ist sie auch bis heute noch. Aber ich find es halt
15:31
interessant. Es ist einfach.
15:32
Also mittlerweile hab ich das Gefühl, dass mehr Leute auch
15:35
sagen, ja, wir testen auch unseren Code ne, also wie
15:37
gesagt, du kannst natürlich auch den Code vorher schreiben oder
15:40
nachher vor der Implementierung nach der Implementierung geht ja
15:43
beides irgendwo, aber. Trotzdem habe ich das Gefühl,
15:48
dass noch viele, dass es trotzdem noch viele Punkte gibt,
15:51
wo halt nicht getestet wird. Und das ist halt irgendwie
15:54
schade und das ist natürlich finde ich per Definition
15:57
irgendwie sage ich mal Qualitätseinbußen, den du da mit
16:01
dir, also den du da mit dir mit einkaufst und deswegen hier halt
16:05
wirklich auch groß geschrieben. Test Driven Development als Tool
16:10
sozusagen oder als Praktik, um sozusagen die hohe Qualität zu
16:14
gewährleisten und. Der nächste Punkt, der mir da
16:18
auch noch zu einfällt, ist, dass man halt auch wirklich wert
16:21
drauf legt, regelmäßig sein Code zu refectern nicht nur den Code,
16:24
auch die Tests, wenn es sein muss.
16:26
Und ich finde, da gehört Mut dazu.
16:28
Das ist zum Beispiel ein Punkt, wo Mut, wo man es jetzt nicht
16:33
mehr sozusagen belächeln muss, weil klar kannst du dich
16:36
hinstellen und sagen okay, wir sollten mal den Code refectern
16:39
und ich vermute mal, dass es immer irgendjemanden gibt,
16:42
wahrscheinlich nicht aus dem Entwicklerteam selber, sondern
16:45
von außen. Und die Person wird dann sagen,
16:48
ja, mach das mal vielleicht besser nicht, das dauert zu
16:50
lange, das bringt jetzt gar nichts, wir müssen irgendwas
16:54
liefern oder was auch immer irgendwelche Stimmen wird es,
16:57
glaube ich immer geben, und da gehört einfach unglaublich viel
17:00
Mut auch dazu zu sagen, Nein, es tut mir leid, ich bin hier der
17:04
Entwickler oder die Entwicklerin und ich habe meine Aufgabe oder
17:09
meine meine Verantwortung ist, die Codequalität zu
17:12
gewährleisten, also wird es jetzt refectered und.
17:16
Und du bist ja meistens nicht alleine im Team.
17:18
Also es geht ja weiter, aber dass man wenigstens, sage ich
17:23
mal ein 2 Entwickler oder Entwicklerinnen dann sozusagen
17:26
auch entbehren kann, wenn sie es für nötig halten, den Code zu
17:29
refactern, dann finde ich, sollte man es tun und da gehört
17:33
wie gesagt Mut dazu, einfach auch dazu zu stehen und dafür zu
17:36
argumentieren und dafür einzustehen zu sagen, jetzt wird
17:38
refecterd sorry. Ja, das ist ja auch ein großer
17:41
Punkt bei XP zu sagen, nein, wir haben jetzt festgestellt, wir
17:45
müssen Refactern es gibt jetzt stellen in unserer Software, die
17:49
überarbeitet werden müssen, und das ist ja auch so eine
17:52
Eigenschaft von XP, die dann cool ist, dass du sagst, OK, wir
17:55
haben jetzt diesen Need festgestellt und wir reagieren
17:57
da drauf, es gibt jetzt keinen Plan, der sagt, Nein, frühestens
18:01
in 4 Wochen könnt ihr jetzt darauf reagieren.
18:03
Sondern. Es gibt jetzt diesen Need und
18:06
wir müssen das jetzt machen und es wird jetzt auch gemacht.
18:09
Ja, und das ist ja auch wieder so ein Punkt, der für Mut
18:11
spricht, dann am Ende definitiv genau, gehen wir mal ein
18:18
bisschen vom technischen Weg und noch mal ein bisschen in
18:22
Richtung Allgemeines all Mindset, wie man arbeiten möchte
18:29
und zwar hatten wir ja gesagt, Feedback steht auch ganz.
18:33
Forenkurs und da würde ich mal drüber reden wollen, wie sieht
18:38
das eigentlich aus, wenn ich jetzt in einem Team, was nach XP
18:42
arbeitet, bin wie wie, wie sieht da die Kommunikation aus.
18:47
Also mal angenommen ich habe jetzt ich entwickle ein Produkt,
18:52
eine App beispielsweise und ich habe jetzt verschiedene Kunden.
18:57
Normalerweise kriegst du ja so Anforderungen reingekippt, dann
19:00
liest du dir die durch und guckst ja okay.
19:02
So und so soll die App aussehen. Ich entwickle das, ich entwickle
19:05
das also jetzt so in der alten Schule sage ich mal ne und ja
19:09
Guthaben wir alles erledigt, alle Anforderungen drin, ja okay
19:12
dann machen wir jetzt einen Release davon und geben das dem
19:15
Kunden und der ist hoffentlich zufrieden.
19:18
Bei XP sieht das ja anders aus da da versucht man ja sehr sehr
19:21
kundenorientiert zu arbeiten, kannst du das kurz mal erklären?
19:26
Ja, im Endeffekt. Also ich kenne das zum Beispiel
19:29
auch so aus meiner eigenen Erfahrung, dass man zum Beispiel
19:30
auch oft New X Designer oder New X Designerin mit drin hat,
19:34
beispielsweise also, wenn es jetzt um etwas geht, wo eine UI
19:37
dabei ist, sag ich jetzt mal ne, aber ich sag mal, das kann man
19:41
auf einer Metaebene auch auf andere Anwendungen übertragen.
19:47
Aber wichtig ist, dass regelmäßig irgendwie ein
19:50
bestimmter Stand an den Kunden, oder sag ich mal Stakeholder
19:54
oder wie auch immer an an die Person, die das sozusagen
19:57
gewünscht hat. Das Feature, was auch immer
20:00
irgendwie zur Verfügung gestellt wird.
20:02
Da bietet sich natürlich CICD an, das sind ja zum Beispiel
20:05
auch Praktiken aus dem DEF Ops Bereich, da haben wir auch 2
20:08
folgen zu gemacht. Liebe Zürin lieber Züra, wenn
20:10
dich das interessiert, hör da gerne mal rein und.
20:14
Und die, das bietet sich natürlich an, um halt eben
20:16
sozusagen stände, die du baust, also die, die du also auch
20:20
Implementierung, Features, die du reinbringst schnell an,
20:23
sozusagen diejenige Person, die es gewünscht hat, auszuliefern.
20:27
Und demzufolge kannst du natürlich, je schneller das
20:30
funktioniert und je besser dein System ist, sozusagen gezielt
20:34
auch auszuliefern. Endkunde, Stakeholder, wie auch
20:36
immer kannst du natürlich auch. Je schneller, je besser.
20:41
Das geht, je schneller das geht, desto schneller kriegst du
20:43
Feedback wieder und das ist natürlich ein wichtiger Punkt,
20:47
weil du halt dann, sobald du das Feedback bekommst, weißt du, bin
20:51
ich auf dem richtigen Weg, können wir so weiter arbeiten
20:54
oder gibt es vielleicht Änderungen oder Punkte, die
20:57
vielleicht in dem Moment noch gar nicht klar waren, zum
21:00
Beispiel so was wie, Ach, das wollten wir ja gar nicht so, das
21:03
haben wir gar nicht in. In dem Moment überhaupt
21:05
realisiert, dass das ein Punkt ist beispielsweise, und deswegen
21:08
müssen wir da noch mal umbauen, umarbeiten.
21:12
Ja, der Vorteil ist halt, dass du diese kleine kleine
21:15
definierten Einheiten hast zu sagen okay, wir gehen jetzt
21:19
einen kleinen Steps, das entwickeln wir und dann holen
21:21
wir das Feedback vom Kunden ein und das funktioniert halt bei
21:25
XP, wenn man es richtig lebt halt sehr gut, weil die.
21:29
Der Kunde halt auch wirklich direkt zur Verfügung steht.
21:33
Also man hat n direkten Draht dazu und kann sagen Ey, wie
21:35
findest du denn das sag ich mal die nächste Iteration ja, aber
21:39
nicht nicht so im Scrum Sinne sondern wirklich jetzt hier.
21:41
Wir haben jetzt diese kleine Änderung eingebaut, gib mal dein
21:44
Feedback, so hast du dir das so vorgestellt, also man spricht da
21:48
auch oft von so einem on Side Customer, dass du also er ist
21:51
quasi schon Teil des Teams irgendwo.
21:54
Nicht, dass er da mitentwickelt, aber er steht halt zur
21:56
Verfügung, um dieses Feedback zu bekommen.
21:59
Das ist halt n sehr wichtiger Aspekt dabei, der auch wirklich
22:01
super cool ist. Weil wenn du deinen Kunden erst
22:04
alle 3 Monate sprechen kannst oder in den nächsten 3 Monaten
22:08
widersprechen kannst, weil bis dahin hast du n riesen
22:10
Aufgabenpaket bekommen, dann kann halt so viel nach hinten
22:13
losgehen, dass. Du gefühlt nach 2 Tagen
22:16
eigentlich schon n Gespräch mit ihm bräuchtest.
22:18
Weil du einfach. Komplett in die falsche Richtung
22:20
entwickelt hast, weil die Anforderung.
22:22
Es liegt ja nicht unbedingt am Entwickler, die Anforderungen
22:24
können halt einfach super unpräzise sein, was nicht selten
22:26
vorkommt, dass halt einfach zu viel Spielraum da drin ist.
22:33
Und dann ist es ja nicht verwunderlich, wenn es mal in
22:34
die falsche Richtung geht oder nicht nach der Vorstellung des
22:37
Kunden. Und das, finde ich, ist bei
22:38
extreme Programming halt auch ein sehr cooler Ansatz zu sagen,
22:41
Nein, der Kunde steht zur Verfügung und du kriegst dieses
22:44
schnelle Feedback genau. Also man, das kann man ja auch
22:46
noch mal ein bisschen von Scrum abgrenzen, weil rein theoretisch
22:49
geht das bei Scrum ja auch, dass du irgendwo, sage ich mal,
22:52
jemanden hast jetzt für Feedback zur Verfügung steht, aber im
22:55
Normalfall ist das eher von dem Scrum Framework so ausgelegt,
22:59
dass du halt deinen Sprint, der eine feste Einheit hat, das.
23:03
Sagen wir mal irgendwas zwischen 2 und 4 Wochen und dann am Ende
23:06
dieses Sprints kriegst du eigentlich dann so dieses
23:09
Feedback und kannst dann sozusagen für deine nächste
23:13
Iteration oder für den nächsten Sprint kannst du dann wiederum
23:16
dieses Feedback einplanen und das ist halt genau dieser kleine
23:20
aber feine Unterschied bei XP, dass du erstmal hast du generell
23:24
viel viel kleinere Iterationen, die meistens so sagen wir mal
23:28
eine Woche sind und. Und sie sind mehr auch on demand
23:30
geschnitten. Ne, also es ist nicht so, dass
23:32
du sagst, ey, wir haben jetzt eine Woche und danach ist
23:35
erstmal ne, dann macht bis dahin erstmal und dann geht es weiter,
23:38
sondern es geht halt immer. Du kannst halt auch
23:41
zwischendurch mal ein Feedback vom Kunden bekommen oder auch
23:44
einfordern und auch dann sozusagen das Ganze anpassen und
23:47
das finde ich halt. Es ist halt unglaublich
23:49
flexibel, aber wie du auch schon meintest es.
23:53
Es erfordert auch eine Menge Disziplin am Ende, um danach
23:56
auch richtig zu arbeiten, weil ich glaube, dass es manche Leute
23:59
gibt, die sich dann denken, so okay, das ist ja, weiß ich
24:02
nicht, eine ganz schöne, wie denn, was jetzt eine ganz
24:06
schöne. Hippie Art und Weise zu
24:08
arbeiten, völlig unstrukturiert. Weißt du ja, also es wirkt halt
24:11
unstrukturiert, aber am Ende geht es darum, dass du halt
24:14
flexibel sein musst. Das heißt, wenn wenn es dich
24:16
stört, dass du morgen vielleicht schon wieder in eine andere
24:18
Richtung läufst. Dann ist es nicht das richtige
24:21
Framework für dich, weil du musst halt reagieren, einfach
24:24
auf Ereignisse sozusagen. Aber was ich noch spannend finde
24:27
ist, weil du gerade Scrum als Vergleich erwähnt hast.
24:30
Also ja, du hast halt Größe, Iteration und bei Scrum ist
24:35
einfach das höchste Ziel was du erreichen willst ist auch die
24:39
Zielsetzung der Iteration zu erreichen, das heißt du
24:42
definierst oder committest dich auf Ziele, die du in den
24:46
nächsten Wochen erreichen willst.
24:47
Und das ist auch das. Das Wichtigste, diese zu
24:50
erreichen, da gibt es keinen Spielraum mehr.
24:52
Mit Änderungen wie du so schön gesagt hast.
24:54
Aber was ich auch noch spannend finde ist, was man auch nicht
24:56
vergessen darf ist, wir haben ja eben gesagt, du hast so ne Art
24:59
on Side Customer der erreichbar ist für schnelles Feedback, auch
25:03
wirklich spontan und bei Scrum läuft es ja eigentlich eher so,
25:08
dass n Team ein PO hat. Der quasi die Schnittstelle vom
25:12
Entwickler zum Kunden oder Stakeholder am Ende ist und der
25:16
ja im Interesse der Kunden das Produkt definiert.
25:21
Das heißt, du hast da wieder so eine Schnittstelle dazwischen,
25:23
die auch hakelig sein kann und Feedback verzögern kann
25:27
beispielsweise, oder es ist einfach noch eine Instanz mehr,
25:32
wo Spielraum reinkommen kann, wenn du weißt wie ich meine und
25:36
das ist halt auch noch ein Unterschied zu XP das.
25:39
Das stimmt also rein theoretisch hast du natürlich bei Scrum,
25:41
wenn es jetzt um die Rollenverteilung geht, strikte
25:44
feste Rollen, die eingehalten werden müssen.
25:47
Bei XP ist es eigentlich nicht angedacht, dass du feste Rollen
25:52
hast. Also es gibt rein theoretisch
25:54
bei XP nicht unbedingt so was wie einen Po beispielsweise oder
25:59
eine Po, aber das bedeutet aber auch gleichzeitig wiederum
26:03
nicht, dass man sagt okay man. Und so darf sowas nicht
26:06
einsetzen. So, das ist halt auch noch mal
26:08
soein.es ist nicht verboten, aber es ist nicht unbedingt
26:11
zwangsläufig gesetzt, aber nichtsdestotrotz kann natürlich
26:15
auch genauso der Developer ist es auch gewünscht und sage ich
26:21
mal angeraten, dass man halt auch als developer oder
26:24
developerin halt eben in Kontakt mit dem Kunden zum Beispiel
26:27
steht. Absolut.
26:32
Aber. Aber was würdest du denn jetzt
26:33
sagen? Also wir haben jetzt XP
26:36
beleuchtet und auch schon mal so eine erste Abgrenzung zu Scrum
26:39
gemacht, das würde ich aber gerne noch ein bisschen
26:41
detaillierter machen später, weil das ist es verschmilzt an
26:45
Gewissen Stellen, hat aber auch an gewissen Stellen
26:47
unterschieden, das ist halt, weil beispielsweise in Scrum
26:50
heißt es ja nicht, dass du jetzt nicht per Programming einsetzen
26:53
kannst, weil das jetzt XP zugeordnet ist.
26:55
Darum geht es ja gar nicht, aber es gibt halt doch gewisse
26:57
Unterschiede, aber vorher würde ich gerne noch mal
26:59
zusammenfassen, wer. Welche Vorteile siehst du denn
27:04
jetzt in XP, also in Extreme Programming?
27:07
Wenn jetzt ein Team sagt, wir überlegen, ob wir es mal
27:09
ausprobieren, welche Vorteile können sich daraus ergeben?
27:13
Also was ich auf jeden Fall sehr, sehr vorteilhaft finde,
27:18
ist halt und ich habe es ja selber auch, habe selber auch
27:22
eine Zeit lang wirklich nach XP gearbeitet, also 5 Jahre
27:25
ungefähr. Und mittlerweile, also jetzt
27:29
nutzen wir beide ja zum Beispiel auch Teile sozusagen davon,
27:33
zumindest ich nenn es mal Tools wie zum Beispiel per Programming
27:36
und TDD beispielsweise. Aber in einem Scrum context.
27:39
Deswegen hab ich gesagt, also es ist nicht ausgeschlossen.
27:42
Genauso wie man ja auch zum Beispiel NPO für XP verwenden
27:45
darf, sozusagen ne. Es ist ja ne, aber also ist
27:48
gewagt, aber. Aber ich finde was, was was, was
27:53
mir immer unglaublich gut gefallen hat, ist, und das hab
27:56
ich auch echt gemerkt, dass die Codequalität wirklich
28:00
unglaublich hoch ist. Das ist nicht nur einfach so ne
28:04
Floskel. Und natürlich kannst du es auch
28:07
schaffen, dass sie nicht so ist, auch wenn du danach arbeitest.
28:10
Na klar, es geht immer irgendwie alles.
28:13
Es kann sich jeder hinstellen und sagen, ja, ich habe das auch
28:15
mal probiert, funktioniert aber nicht.
28:17
Natürlich kommt es auch auf die Qualität deiner Tests zum
28:20
Beispiel an, wenn du Tests schreibst oder was auch immer
28:23
und es kommt natürlich auch auf den auf die Qualität des Codes
28:25
drauf an. Also wenn du jetzt zum Beispiel
28:27
sagst, EY setzt jetzt mal ganz viele frisch geborenes Developer
28:32
und Developerinnen irgendwie dahin und lass die mal arbeiten,
28:35
die Qualität muss unglaublich. Nicht hoch sein, wenn sie nach
28:36
Extreme Programming arbeiten natürlich nicht.
28:39
Also du brauchst natürlich auch irgendwie erfahrene Leute da
28:42
drin, aber im Normalfall hast du eine sehr, sehr hohe
28:44
Codequalität, einfach aufgrund der Praktiken und das per
28:47
Programming. Zum Beispiel fördert halt auch
28:50
unglaublich krass diesen Wissensaustausch, genau zum
28:53
Beispiel wenn du erfahrene und weniger erfahrene Leute da drin
28:57
hast. Dass dieser Wissensaustausch so
28:59
krass ist, dass du in kürzester Zeit voneinander lernen kannst
29:03
und also diese, dieser, dieser, wie nennt sich das, diese,
29:08
diese, diese Lernkurve ist halt extrem steil so, und das finde
29:13
ich halt auch unglaublich cool, also das hat man, man hat im
29:19
Normalfall relativ schnell dann auch dadurch aus diesem Effekt
29:22
heraus den Punkt, dass sich alle Leute, die im Team da
29:27
Mitarbeitenden, XP Halt auch unglaublich verantwortlich für
29:30
das Produkt fühlen. Was auch ein sehr, sehr großer
29:34
Punkt auf der haben Seite ist, weil dann kniest du dich da auch
29:36
richtig rein und du bist halt unglaublich flexibel, was
29:41
natürlich auch wieder auf der anderen Seite diese Disziplin
29:44
erfordert, was vielleicht ein Nachteil sein kann, aber das
29:47
finde ich sind für mich unglaublich großartige Vorteile
29:49
von XP, die ich auch sehr kurz erlebt habe du ja auch
29:53
teilweise. Das, was du gerade angesprochen
29:56
hast, diese Transparenz finde ich halt auch extrem.
29:59
Cool dabei, weil du hast halt diese enge Zusammenarbeit.
30:01
Du hast n schnellen Austausch, auch gerade wie du meintest
30:04
durch Pearl Programming und das schweißt so n Team auch zusammen
30:08
und vor allem schafft Vertrauen, also in dem Moment wenn ich auch
30:10
mit auch also was wir jetzt vielleicht noch nicht erwähnt
30:13
haben, noch mal ganz kurz beim Pearl Programming.
30:16
Zirkuliert man ja auch oft. Das heißt, du hast nicht immer
30:18
die gleichen Pairs, sondern um diesen Wissensaustausch zu
30:21
fördern, setzt du die Teams ja auch neu zusammen und das
30:25
oftmals auch täglich, dass du sagst, heute arbeite ich mit dem
30:28
Morgen, mit dem Ey, an welchem Thema bist du?
30:30
Ja, mach ich mit, lass uns n Pair bilden sozusagen, und das
30:33
Ganze fördert halt auch unfassbar viel vertrauen, weil
30:35
du halt mit deinen Kollegen eng zusammenarbeitest mit einem Mal.
30:39
Und das finde ich, ist halt n riesen Punkt auch dabei der so n
30:42
Team halt richtig boosten kann, also dass die Halt wirklich
30:44
Perform am Ende ja. Und was mir dabei auch sehr gut
30:48
gefällt, und das ist n Punkt gerade bei so erstprojekten also
30:53
angenommen ich hab n Produkt und ich möchte es jetzt erstmalig
30:57
entwickeln und es ist noch so n bisschen in der
30:59
Definitionsphase. Also wir wissen noch nicht genau
31:03
wie es wird, nehmen wir wieder n Beispiel als als Beispiel ne App
31:07
und wir haben so n so n so ne Funktionalität die richtig cool
31:10
ist. Da sind wir überzeugt von aber
31:12
wie die App genau aussehen soll, ja und wie sie sich anfühlen
31:15
soll in der Bedienung. Das ist noch nicht so klar und
31:17
brauchen wir vielleicht noch so andere Features da drin und das
31:20
ist definiert sich alles während der Entwicklung, dann ist halt
31:23
XP super geeignet dafür, weil du diese hohe, also diesen hohen
31:27
Grad an Flexibilität hast. Weil du nicht sagst, also so
31:31
richtig alt wasserfallmäßig NÖ, ich will jetzt alle
31:33
Anforderungen haben, die wenn ich die hab, dann geh ich erst
31:35
in die nächste Iteration und so weiter das schon mal gar nicht
31:38
und selbst scrum wäre da nicht träge, aber nicht optimal.
31:43
Sagen wir mal so. Also es ist ja nicht träge im
31:45
Sinne von, das kannst du auf keinen Fall nach Scrum machen,
31:47
aber XP ist da für mich einfach noch geeigneter, weil ich
31:50
einfach Tag für Tag mal übertrieben gesagt oder was
31:53
heißt übertrieben? Nein du kannst Tag für Tag
31:55
entscheiden. Hier.
31:57
Wie sieht es aus? Ich hab gestern mal das gemacht,
31:59
dieses kleine Feature, wie fühlt sich das für dich an?
32:02
Ja nee gut OK weiter refact dann und so weiter und da finde ich
32:07
ist das halt einfach n super geeignetes Framework in diesen
32:11
Fällen. Natürlich kannst du jetzt sagen,
32:12
ey es ist einfach nur ne neue Version, es ist version 1025.
32:21
Da kommen n paar Änderungen rein, die sind seit 2 Jahren
32:23
aufgeplant was was willst du da jetzt extrem rangehen an die
32:26
Nummer also hier die 5 Punkte müssen da eingebaut werden und
32:30
fertig da da macht es natürlich keinen Sinn, deswegen meine ich
32:33
also es ist halt auch projektabhängig.
32:35
Ne, aber gerade für so Schnelllebige und neue Projekte
32:39
ist es halt super. Also das was du jetzt so
32:40
beschrieben hast klingt ja so auch schon nach so MVPS ne nach
32:44
diesen Minimum viable products. Das ist ja auch n Punkt bei
32:48
Extreme Programming, der da komplett mit Reinspielt, weil du
32:51
versuchst ja einfach auch schnelle Änderungen, also
32:55
schnell im Sinne von kleine Änderungen nicht zu viel auf
32:57
einmal wirklich. Erstmal nur das, worauf es
32:59
ankommt. Und das ist ja auch dieser MVP
33:01
Gedanke, der da gefördert wird. Ja genau, aber wie gesagt was
33:05
halt wichtig ist und das ist natürlich ne Abhängigkeit die du
33:08
eigentlich brauchst. Bei XP ist natürlich, dass du
33:11
halt eben auch das Engagement vom Kunden hast.
33:14
Es ist nämlich unglaublich anstrengend, wenn du die ganze
33:16
Zeit dann hinterher bist. Den Kunden, die User wie auch
33:19
immer zu heranzuziehen und zu sagen, Gib doch mal bitte dein
33:24
Feedback. Ne, das ist halt schon irgendwo
33:27
ne Abhängigkeit die du hast und die schon gegeben sein sollte,
33:30
damit es richtig gut funktioniert.
33:33
Und wie gesagt, hohes Maß an Disziplin.
33:36
Das damit muss man irgendwie arbeiten und es funktioniert
33:38
hauptsächlich halt auch für kleinere Teams und jetzt zum
33:42
Beispiel nicht für irgendwie n Team aus 20 Leuten ne.
33:45
Na ja, da wird es schwierig, ne und wie gesagt der Punkt Kunde,
33:48
weil wir gesagt haben so n on Side Customer den der muss
33:52
erreichbar sein. Du brauchst natürlich auch n
33:53
Kunden der da Bock drauf hat. Also wenn der sich jetzt denkt,
33:56
ey, ich möchte aber nur alle 4 Wochen mit euch sprechen, ich
33:58
habe gar nicht so viel Zeit für Termine oder irgendwas, da wird
34:01
es halt gar nicht funktionieren, dann kannst du es eigentlich von
34:03
Anfang an sein lassen. Also es ist halt einfach
34:05
Prämisse zu sagen, ich kann diesen Kunden wirklich immer
34:09
erreichen. Also.
34:11
Es ist auch so eine Einstellungssache auf Seiten des
34:13
Kunden. Ganz wichtiger Punkt definitiv.
34:16
Aber lass uns doch mal noch mal das Ganze zu Scrum abgrenzen.
34:23
Weil wie gesagt, es haben beides vor und Nachteile.
34:25
Es sind beides agile Frameworks, man hat jetzt wahrscheinlich
34:29
auch im Laufe der Folge gemerkt, es gibt Parallelen, es gibt auch
34:32
Unterschiede, aber ich würde das gerne noch mal zusammenfassen,
34:35
lass uns doch noch mal anfangen bei den Abläufen und rollen mal
34:38
so ganz strukturell, weil du gesagt hast, OK, rollen sind
34:43
nicht unbedingt vorgesehen in XP in Scrum Ya Show, Wir haben
34:46
jetzt zum Beispiel den PO schon genannt, du hast auch einen
34:49
Scrum Master, du hast die Entwicklerrolle dann.
34:52
Wie siehst du? Da den Unterschied zu in der in
34:56
der Struktur sage ich mal der agilen Frameworks in den
35:00
Abläufen. Also genau, also du hast ja bei,
35:04
also nennen wir das ganze vielleicht mal so, wie sagt man
35:10
dazu, das sind ja so Art Zeremonien, die man.
35:13
So abhält ja, ich glaube, nach dem Manifest nennt man das ja
35:17
und? Im Endeffekt hast du ja so
35:20
bestimmte Punkte wie zum Beispiel ein Planning.
35:22
Ein Daily nennt sich das Ganze ja, ein Review, ein Rene Retro,
35:28
also diese ganzen Zeremonien, diese ganzen Termine.
35:31
Ich finde Termine klingt immer blöd, aber die hast du ja, die
35:34
sind ja auch irgendwo festgesetzt in Scrum und im
35:40
Endeffekt gibt es ähnliche Punkte.
35:44
Punkt oder ähnliche Teil. Sie heißen teilweise ein
35:46
bisschen anders, ich zum Beispiel, das heißt dann nicht
35:48
Daily, sondern Stand Up zum Beispiel zielt aber mehr oder
35:52
weniger auf das Gleiche hin, also ab, aber es ist halt, wenn
35:56
du wirklich strikt nach Scrum arbeitest, dann hast du ja
35:59
wirklich diese entsprechenden Termine, die festgesetzt sind,
36:02
die sind an einem festen Zeitpunkt zu einem festen Tag.
36:05
Mehr oder weniger, aber schon relativ fest gebrannt.
36:08
Du einigst dich irgendwann auf eine Sprintgröße, meistens
36:12
irgendwas zwischen 2 und 4 Wochen und innerhalb dieser Zeit
36:17
planst du dann halt deine Aufgaben, arbeitest sie ab,
36:20
guckst okay wie ist es denn jetzt gelaufen und was haben wir
36:23
so alles geschafft? Und dann retrospektierst du das
36:26
Ganze noch mal. Wie lief denn so dieser Sprint?
36:29
So und ähnlich funktioniert es tatsächlich auch eigentlich bei
36:32
XP. Bloß mit dem Unterschied, wie
36:35
ich schon meinte, dass die Iteration der Sprint viel viel
36:39
kleiner ist. Also ich kenne das, dass es dann
36:42
wirklich auf eine Woche zum Beispiel begrenzt ist.
36:45
Und klar kann man sich dann hinstellen und sagen, OK, weiß
36:47
ich nicht, soll ich jetzt jede Woche n Retro machen?
36:49
Ja, aber. Im Endeffekt ist es alles
36:53
irgendwie mehr oder weniger on demand, weil du kannst zum
36:56
Beispiel auch sagen, Leute, ich habe gerade echt ein großes
36:59
Ding, lasst uns mal bitte kurz eine Retro machen und die muss
37:02
dann aber auch nicht, keine Ahnung eine Stunde sein, weil
37:05
ich habe auch manchmal das Gefühl, dass so auch im Scrum
37:07
Kontext heißt es, wir haben jetzt einen Termin, der geht
37:10
jetzt eine Stunde und manchmal geht dann sozusagen der die
37:15
Tendenz dahin, dass man sagt okay, wir haben eine Stunde,
37:17
also füllen wir diese Stunde auch aus.
37:19
Und das ist halt nicht unbedingt sinnvoll.
37:22
Und genauso ist es zum Beispiel auch beim beim Wo.
37:24
Wieder die Disziplin Reinsteht, wo wieder?
37:26
Definitiv. Aber was zum Beispiel auch finde
37:29
ich ein sehr, sehr ausschlaggebender Punkt ist, den
37:31
ich auch aus an eigener Hand erfahren habe, ist, wenn du zum
37:35
Beispiel nach Scrum arbeitest und sagst okay, wir machen jetzt
37:36
irgendwie was für die nächsten 2 Wochen, dann setzt du dich hin
37:41
und sagst okay das sind meine Aufgaben, die ich für die
37:43
nächsten 2 Wochen definiere oder für die nächsten 34, je nachdem
37:46
für den nächsten Sprint so. So, und wenn du jetzt sagst
37:48
okay, ich hab das aber abgearbeitet, 2 Tage bevor der
37:51
Sprint vorbei ist, dann würde nach Scrum es heißen okay du
37:56
hast jetzt erstmal 2 Tage nichts zu tun, warte bitte bis zum
37:58
nächsten Planning so ja gut, wenn wenn du es so ganz genau
38:03
genau nimmst. Ja genau aber mal also ich hatte
38:06
zum Beispiel auch öfter mal, dass den Punkt bei XP, dass wir
38:11
einfach wirklich fast waren, so war halt einfach so.
38:15
Weil es halt einfach gut geflutscht hat.
38:17
Wir haben halt auch gute Aufgabenpakete, also kleine
38:21
Aufgabenpakete abgesteckt, das war wirklich fantastisch, muss
38:24
man sagen, aber Fakt ist war, wir waren nach der Hälfte der
38:27
Iteration waren wir auf einmal fertig, so was machst du dann
38:29
also das ganze Team hatte nichts mehr zu tun, so und dann haben
38:32
wir halt gesagt okay, du haben wir irgendwie geguckt, wollen
38:35
wir mal wieder ein, Ich nenne es jetzt mal planning machen, dass
38:38
wir halt einfach neue Aufgaben definieren und sagen okay was
38:43
wenn? Welche Aufgaben, die stehen dann
38:44
gerade aus? Dann werden die quasi besprochen
38:46
und dann können die wieder angegangen werden und das war
38:49
wirklich mehr oder weniger einfach on demand, dass man
38:51
einfach sagt, wir brauchen gerade wieder was.
38:52
Wollen wir diesen Termin gerade machen, weil wir brauchen ihn,
38:56
das heißt, du hast zwar eine gewisse Regelmäßigkeit, aber
39:00
diese gewisse Regelmäßigkeit kann man halt auch unterbrechen
39:03
und sagen okay lass uns doch einfach das jetzt machen, weil
39:05
jetzt ist es gerade notwendig, weil es ist ja einfach zu sagen,
39:11
wir haben feste Strukturen und und davon gehen wir nicht weg
39:14
oder man sagt, EY, das und das brauchen wir gerade, also lass
39:18
uns das doch einfach machen, wenn wir es brauchen, so ne und
39:21
ich fand den Ansatz halt auch wirklich sehr praktikabel, es
39:25
hat gut funktioniert. Ja, also da unterscheidet sich
39:29
dann halt so n bisschen auch die Zielsetzung.
39:30
Ne, also wenn du jetzt sagst bei XP.
39:34
Änderungen der Anforderungen oder auch neue Anforderungen
39:36
können jederzeit angenommen und umgesetzt werden.
39:39
Du versuchst halt einfach immer nur diese hohe technische
39:42
Qualität und dieses kontinuierliche Feedback
39:44
einzuholen, das hast du auf der XP Seite und bei Scrum ist es
39:49
halt so. Du versuchst halt so ne klare
39:51
Organisation zu schaffen mit transparenten Prozessen, also es
39:55
gibt so n ganz festen Ablauf, der ist zwar agil innerhalb
39:59
dieser. Sag ich mal.
40:00
Oder zwischen den Inkrementen sag ich mal.
40:03
Aber dazwischen hast du halt n festen Rahmen.
40:06
So und da ist halt auch kein Platz mehr in innerhalb der
40:09
Sprints Veränderung. Klar macht man das, es sind ja
40:12
immer nur Frameworks, das heißt du musst dich ja nicht zu 100%
40:15
daran halten oder sonst sagt ja keiner so, das ist kein Scrum
40:19
mehr ciao aber grundsätzlich vom Grundgedanken ist es halt nicht
40:24
so wie bei Extreme Programming angedacht ja.
40:27
Aber was ich halt schade finde bei Scrum auch in puncto
40:31
Aufgabenplanung hab ich dann die Erfahrung gemacht, damit man
40:34
überhaupt nicht auf den in diesen Zustand kommt, nichts zu
40:37
tun zu haben, wird man am liebsten erstmal gleich komplett
40:40
überplant, so weil dann hast du ja eigentlich immer diesen,
40:43
diesen diesen das Gefühl OK ich kann hab immer was zu tun, aber
40:49
gesund ist es auch nicht, weil es fühlt sich auch einfach nicht
40:51
gut an so permanent zu sagen OK ich hab es nicht geschafft, ich
40:55
hab es nicht. Geschafft, nicht geschafft,
40:56
nicht geschafft. Großer Unterschied ist auch,
41:01
wenn man so überlegt, was die Frameworks beinhalten, muss man
41:04
ja sagen, dass XP sich die technische Seite anguckt, gerade
41:07
schon mal so ein bisschen angeteasert, wo Scrum gar nicht
41:11
drauf eingeht. Also Scrum versucht ja wirklich
41:16
Prozesse zu schaffen. Aber die technischen Umsetzungen
41:19
spielen sind da nicht definiert oder spielen da keine Rolle.
41:22
Wo hingegen bei XP haben wir gesagt hohe Codequalität per
41:26
Programming Test Driven Development sind alles so
41:29
Praktiken die da genannt werden und das finde ich halt auch.
41:33
Ist ein großer Unterschied, dass das bei Scrum keine Rolle
41:35
spielt, also so gesehen Scrum musst du ja auch nicht als
41:41
Entwicklerteam nutzen, Scrum kannst du für alles nutzen, es
41:44
ist halt eine Strukturierung, es sind Prozesse.
41:47
Management XP Menge Management genau ja sehr viel und XP
41:52
richtet sich halt schon wirklich an die Entwicklung.
41:54
Ja und das finde ich halt auch immer spannend so, weil wenn du
41:58
so ein sag ich mal in diesem Gegensatz stehst und sagst ja
42:01
gut, was wollen wir denn hier eigentlich machen?
42:03
Ja wir wollen Software entwickeln, ja dann fokussiere
42:06
dich doch darauf, dass Software gut entwickelt werden kann und
42:08
nicht, dass man irgendwie irgendwelche Management Prozesse
42:11
bedient. So das ist dann auch immer.
42:16
Ich verstehe, dass es Leute gibt, die das gerne wollen, aber
42:19
die Frage ist, was willst du am Ende für ein Ziel erreichen?
42:22
Ganz genau, und das ist, das ist auf jeden Fall ein großer Punkt
42:26
zu sagen okay Scrum ist halt so universell einsetzbar in allen
42:30
Bereichen, es gab ja auch diesen Riesen agilen Hype, ich weiß
42:34
nicht, ob der immer noch lebt oder ob der so ein bisschen am
42:36
sterben ist. Gerade aber im Endeffekt, jeder
42:39
wollte irgendwie nach Scrum arbeiten, egal in welchen
42:41
Bereichen, und das ist halt auch wirklich eine klare Abgrenzung
42:45
zum XP, niemand möchte. Nein, aber es richtet sich halt
42:50
wirklich an die Entwicklung. Ja, definitiv, ich meine also im
42:54
Endeffekt ist es, ich sag mal so ne, weil klar, man kann sich
42:57
jetzt hinstellen und sagen, ich meine wir beide finden XP glaub
43:00
ich cool, ich glaub das ist rausgekommen und es heißt aber
43:04
nicht, dass XP wie du ja gerade eigentlich schon angeschnitten
43:06
hast, jetzt die allheil Lösung ist so, sondern es gibt
43:10
natürlich für verschiedene. Sag ich mal Rahmenbedingungen
43:15
gibst, ist auch das Gute das richtige Framework, was du dann
43:18
sozusagen verwenden kannst. Es gibt sicherlich auch
43:21
Projekte, wo auch Scrum oder XP keinen Sinn machen würde ne,
43:26
aber man muss immer gucken okay wann funktioniert was und ich
43:29
glaube das Wichtigste am Ende ist ja eigentlich, dass man
43:32
sagt, Ob du jetzt Scrum nimmst, XP oder irgendwas anderes ist es
43:36
einfach wichtig, dass man irgendwie am Ende des Tages
43:39
irgendwie. Hinbekommt, dass das Team gut
43:43
funktioniert, dass es sich fürs Projekt irgendwie eignet, dass
43:46
es sich gut einbettet und dass alle damit irgendwo zufrieden
43:49
sind, so alle gut kriegt man meistens nicht hin, aber es ist
43:56
ich, ich finde es halt manchmal auch schwierig, dass es oft so
44:01
ist, dass wenn du was Neues vorschlägst, ob es jetzt scrum
44:04
ist, also selbst wenn Leute in Scrum drin sind und du sagst,
44:08
Ey, lass uns doch mal nach XP arbeiten, habe ich der.
44:11
Erfahrung nach oft so, dass also die Erfahrung gemacht, dass die
44:15
Leute dann sagen, lieber erstmal nicht neue Sachen will ich nicht
44:18
so. Also fehlt schon mal der Mut für
44:21
XP. So na gut, ich würde sagen, wir
44:26
haben es ausführlich besprochen, fabi ja auf fortgeschrittene
44:29
Zeit hat mir wieder sehr viel Spaß gemacht.
44:32
Vielen Dank mir auch. Vielen Lieben Dank.
44:34
Tino war ein toller. Talk über XP Wir mögen es,
44:40
probiert es gerne mal aus. Liebe zürer lieber Zürer, das
44:43
ist sehr empfehlenswert, zumindest mal die Erfahrung
44:46
damit zu sammeln, aber lasst uns doch auch gerne mal auf der
44:49
Podcast Mail zukommen, ob ihr schon mal nach XP gearbeitet
44:52
habt oder ob ihr da mal Lust drauf habt, wenn ihr noch
44:54
weitere Infos wollt, schreibt uns einfach gerne eine Podcast
44:56
Mail, da können wir auch gerne in den Austausch gehen oder
44:59
kommt auf unseren Discord Server wie auch immer links zu all
45:02
unseren Plattformen findet ihr in den Shownotes.
45:04
Und wenn euch die Folge gefallen hat, dann lasst doch gerne eine
45:08
gute Bewertung da. Und wenn ihr generell sagt,
45:10
Coding Buddies, der Podcast das Projekt ist echt eine coole
45:13
Sache. Ich mag die beiden, dann könnt
45:16
ihr uns auch gerne unterstützen mit einer kleinen Spende, aber
45:18
den Link dazu findet ihr auch in den Shownotes und in diesem
45:21
Sinne würde ich sagen, sind wir raus für heute und wir hören uns
45:24
beim nächsten Mal wieder. Hab eine schöne Zeit du auch
45:27
Tino und in dem Sinne danke bis zum nächsten Mal deine Coding
45:31
Buddies gemeinsam. Besser.