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