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.