CRE: Technik, Kultur, Gesellschaft

Hintergründe und Erfahrungen zur Software-Entwicklungsmethode "XP"

Episode image forCRE028 Extreme Programming

Extreme Programming (XP) ist eine seit einigen Jahren immer populärer werdende Methode zur Entwicklung von Software in kleineren Teams. Die teilweise radikalen Änderungen im Vergleich zur "traditionellen" Vorgehensweisen erfordern umfangreiches Umdenken in technischen und sozialen Prozessen, bieten aber die Möglichkeit der Beherrschung zuvor schwer zu bändigender Dynamiken.

Ängste, mangelnde Offenheit und Kommunikation sowohl auf Seiten des Auftraggebers als auch der Entwickler sind häufig bereits der Anfang vom Ende jeder erfolgreichen Softwareentwicklung. Extreme Programming begegnet diesemn Problemen durch kooperative Entwicklungsmodelle (Pair Programming), iterative Verfeinerungen der Aufgabenstellung undJ Konzentration auf schnelle Releasesyklen und Testbarkeit von Systemen.

Pavel berichtet aus seinen jahrelangen und mehrheitlich positiven Erfahrungen in der konkreten Anwendung von Extreme Programming im Unternehmen und erläutert, welche Schritte nötig waren, um diese Umstellung zu einem Erfolg zu führen, welche langfristigen Effekte das hatte.

HINWEIS: Die Sendung von 2006 wurde 2023 neu geschnitten und die Hintergrundmusik der Originalaufnahme wurde zur besseren Hörbarkeit entfernt und ein Transkript hinzugefügt.

Tim Pritlove

Pavel Mayer

Für diese Episode von CRE: Technik, Kultur, Gesellschaft liegt auch ein vollständiges Transkript mit Zeitmarken und Sprecheridentifikation vor.

Bitte beachten: das Transkript wurde automatisiert erzeugt und wurde nicht nachträglich gegengelesen oder korrigiert. Dieser Prozess ist nicht sonderlich genau und das Ergebnis enthält daher mit Sicherheit eine Reihe von Fehlern. Im Zweifel gilt immer das in der Sendung aufgezeichnete gesprochene Wort. Formate: HTML, WEBVTT.

Transkript

Tim Pritlove 0:00:50

Hallo, hier ist Chaos Radio Express, Ausgabe Nummer 28 in schneller Folge inden letzten Tagen, ausgelöst durch meine Präsenz am Linux-Tag.Da haben sich viele interessante Themen ergeben, aber die Liste ist noch langund heute wartet schon das nächste Thema auf uns und es lautet Extreme Programming,eine Methode Software zu schreiben und dazu habe ich den Pavel wieder bei mir,der uns ein bisschen Einblick in diese Technologie geben wird.Und mein Name ist, wie gehabt, Tim Brickler.Ja, hier sind wir wieder.Ich begrüße Pawel. Pawel.

Pavel Mayer 0:02:23

Hallo Tim.

Tim Pritlove 0:02:25

Hallo Pawel. Ja, Extreme Programming soll das Thema sein heute, dieser Sendung.Ein Begriff, der schon eine Weile.

Pavel Mayer 0:02:34

Seit 99 eigentlich hat das so begonnen, breite Wellen zu schlagen.Da hat Kent Beck seine drei Bücher veröffentlicht, Extreme Programming und ExtremeProgramming Explained. A.

Tim Pritlove 0:02:52

Das waren also die Standardwerke zu dem Thema?

Pavel Mayer 0:02:55

B. Ja, aber vielleicht fangen wir mal vorne an.Also Extreme Programming klingt, wenn man das Wort hört, erstmal so,als würden irgendwelche Nerds 48 Stunden lang vorm Rechner sitzen und so langeprogrammieren, bis sie umfallen.Das Interessante ist aber, das ist eine sehr geschickte Wahl dieses Begriffs,weil tatsächlich ist Extreme Programming genau das Gegenteil davon.So Extreme Programming ist so der Einzug von Wahrheit und Vernunft in die Softwareentwicklung.

Tim Pritlove 0:03:36

Du meinst vorher war das alles unvernünftig und alle haben sich einen in dieTasche gelogen. Ja, definitiv.

Pavel Mayer 0:03:43

Ich meine, das ist überhaupt eines der größten Probleme bei der Softwareentwicklung,so die fehlende Ehrlichkeit, so die Ehrlichkeit zu sich selbst,die Ehrlichkeit gegenüber dem Kunden und die Ehrlichkeit gegenüber dem eigenen Management.Und da versucht Xtreme Programming einfach ein paar Pfeiler einzuschlagen, die dafür sorgen,dass es eben mit Vernunft zugeht und dass es nachhaltig zugeht.Extrem ist an extrem programming ist,dass man die guten Dinge oder die Dinge, die man als gut und richtig erkannthat, mit aller Konsequenz versucht durchzusetzen.

Tim Pritlove 0:04:35

Also eine Diszipliniertheit im Prinzip. Also man muss dazu sagen,Extreme Programming bezeichnet also eine Vorgehensweise, eine Art und Weise,wie man an Softwareentwicklung als solche herangeht.Es ist jetzt nicht eine spezielle Technik, es hat nichts mit Programmiersprachenim eigentlichen Sinne zu tun,sondern es lässt sich im Prinzip auf jeden Entwicklungsprozess anwenden.Egal, ob man jetzt in Perl oder C oder was auch immer entwickelt, eine Methodik.

Pavel Mayer 0:05:01

Ja es ist gut du hast jetzt das m-wort gesagt was halt das ist zumindest verpönt,in der extreme programming,äh äh szene von methodik oder methodologie äh zu sprechen aber tatsächlich ist es äh so etwas wobei,da es halt viel äh auch disziplin und energie erfordert braucht man auch etwas ja Rückhalt.Als ich das kennengelernt habe, so 2000 habe ich damit begonnen, das Ganze.

Tim Pritlove 0:05:37

A1. Warum? Also ich meine, wie bist du da überhaupt drauf gestoßen? Was war die Motivation?

Pavel Mayer 0:05:42

B2. Unzufriedenheit. Einfach Unzufriedenheit mit der Art und Weise,wie Softwareentwicklung, wie ich sie bis dahin betrieben habe und wie meineTeams sie betrieben haben.Bis zu Extreme Programming war mir gar nicht klar, was eigentlich alles verkehrt daran war.Ich dachte, das müsste einfach so sein, dass man oft nicht rechtzeitig fertigwird, dass die Leute alle bis an den Rand der Erschöpfung arbeiten,dass man versucht, irgendwie den Kunden permanent zu beschwichtigen,weil die Dinge nicht so laufen,wie sie sollen.Ja, ich meine, es gibt einen Haufen von Problemen einfach in der Softwareentwicklung,die jeder kennt. Es fängt damit an.Also Software wird nicht termingerecht fertig oder die Entwicklung wird sogarbeendet, bevor die Software einsetzbar ist oder wenn man soweit kommt,stellt man irgendwann fest, der Wartungs- und Änderungsaufwand,wird sehr schnell zu hoch, um die Software den ständig wechselnden Anforderungen anzupassen.Oder ja, die Software wird wegen Unzuverlässigkeit und Problemen irgendwannkaum genutzt von den Leuten, die sie ursprünglich bestellt haben.Oder sie löst das Problem nicht so, wie es mal versprochen oder angedacht war.Oder in der Zwischenzeit, bevor die Software fertig geworden ist,hat sich das Problem eigentlich verändert mittlerweile.Oder ja, man hat die falschen Features eingebaut, viele nette Features,aber der Nutzen der Features, die man eingebaut hat, ist nicht so,wie man sich das vorgestellt hat.Und irgendwann fangen die Leute einfach, auch vor allem die guten Leute an,das Projekt und die Software zu hassen und versuchen, sich halt anderswohin abzusetzen.Das ist so das Ding.

Tim Pritlove 0:07:44

Bis hin zu flüchtenden Programmierern.

Pavel Mayer 0:07:46

Jaja, also man will dann irgendwann nur noch nur noch weg.Dann ist natürlich das das Problem. Kunde steht auch im Baum,das heißt typischerweise der Kunde weiß am Anfang nicht, was er will.Das ist eigentlich auch relativ normal.Und er weiß eigentlich erst, was er will und was nicht, wenn er es hat.So das ist auch ein typisches Ding. Man zeigt es sie und dann sagt er ja supergenau so wollte ich das oder nee also das wollte ich eigentlich nicht.Ich habe zwar gesagt, dass ich das wollte, aber so habe ich mir das nicht vorgestellt.Dann ist es so, dass der Kunde natürlich er steckt nicht so tief drin im Entwicklungsprozessund weiß nicht, welche Features jetzt einfach und billig sind und welche schwierig und teuer sind.So das zu vermitteln, ist auch schwierig. So außerdem will der Kunde natürlichdummerweise vorher wissen, was es kostet und was er dafür bekommt,während der Programmierer natürlich sich möglichst nicht festlegen möchte.Dann gibt es das Problem, dass der Kunde häufig einen festen Termin hat,an dem alles fertig sein soll. Das beißt sich dann natürlich auch.Außerdem ändert der Kunde gerne seine Meinung. So, das ist aber auch ganz normal, ähm, so.Früher habe ich die Kunden das übel genommen, so mittlerweile weiß ich,dass es einfach dazugehört.Ich meine, jeder von uns ändert mal seine Meinung, warum sollte dann nicht auchder Kunde seine Meinung ändern.

Tim Pritlove 0:09:14

Weil man sich ja im Prinzip auch während des Prozesses, in dem man das so begleitet,ausgelöst eben durch diese Aktivität, die sich dann entspannt,auch überhaupt erstmal Gedanken macht.Also überhaupt erst so sehr auch in dem Prozess drin ist, das kenne ich auch,wann auch immer ich in der Situation war,auch Features festzulegen oder in gewisser Hinsicht auch Aussagen zu machenüber grundlegende Funktionsmodelle, stellt man dann nach zwei,drei Monaten fest, wenn man erstmal den Gedankenprozess angeworfen hat,dass man dann eben so es auf einmal ganz anders sieht.

Pavel Mayer 0:09:42

Ja, und dann ist das das große Problem in der Entwickler-Kunden-Beziehung ist die Angst.So die Angst, weil Softwareentwicklung ist riskant.So alle Beteiligten fürchten sich vor den vielen Dingen, die schiefgehen können.Und tatsächlich ist es so, dass nicht eingestandene Ängste die Ursache der meistenFehlschläge in der Softwareentwicklung sind.Also zum Beispiel, der Kunde hat Angst, dass er nicht bekommt,was er will, dass er nicht das Richtige verlangt, dass er zu viel zahlt für zu wenig.Dass er seine Karriere irgendwelchen Techies anvertrauen muss,die das gar nicht kümmern, also die Karriere, dass er niemals einen klaren Plan erhalten wird.Oder der Kunde hat Angst zu Recht auf, dass die Pläne, die er zu sehen bekommt,reinste Märchen sind und dass er nie wissen wird, was wirklich los ist,weil er keinen richtigen Einblick hat.Oder er hat Angst, dass man ihn auf die ersten Aussagen festnageln wird under später nicht mehr auf veränderte Anforderungen reagieren kann.Oder dass ihnen also niemand sagt ihnen die Wahrheit.So das sind so typische Ängste des Kunden und die sind eben tatsächlich nicht unberechtigt.Auf der anderen Seite steht der Entwickler, der natürlich auch von Ängsten geplagt ist.Also ganz vorne, dass mehr von ihm verlangt wird, als er schaffen kann.Dann, dass von ihm verlangt wird, sinnlose Dinge zu tun.Das ist eine große Angst so im Projekt.Oder, dass er einfach zu dumm ist, das Problem zu lösen.Auch diese Selbstzweifel sind häufig da.Oder er fürchtet sich irgendwie, dass das Wissen veraltet und er zurückfällt.Auch da ist er getrieben.Und dann natürlich ein großes Problem, was auch da ist, dass man,dass der Entwickler Verantwortung.Übertragen bekommt, aber nichtdie notwendige Autorität, um der Verantwortung auch gerecht zu werden.

Tim Pritlove 0:11:58

SIEGFRIED Du meinst, dass ihm jetzt Vorgaben gemacht werden,wie er etwas zu lösen hat, aus irgendwelchen Situationen heraus.

Pavel Mayer 0:12:04

BARTHOLZ Genau, er sagt, du bist jetzt verantwortlich, dass das rechtzeitig fertig wird, aber...

Tim Pritlove 0:12:09

SIEGFRIED Und dann sagt er, da will ich aber Programmiersprache X nehmen,weil meiner Meinung nach ist das genau das, was ich dafür brauche.Und dann kommt so die Firmenvorgabe, nein, wir nehmen aber jetzt Java, genau, wir nehmen Y.

Pavel Mayer 0:12:20

Und du musst auch mit diesen drei Leuten irgendwie klarkommen dort.Und dann ein ganz wichtiger Punkt, den jeder hasst, wovor jeder Entwickler Angsthat, Qualität opfern zu müssen, um Termine zu halten.Also quasi durch die äußeren Umstände dazu gezwungen zu werden,seinen eigenen Qualitätsansprüchen nicht gerecht zu werden.Und ich meine, niemand schafft gerne Dinge von schlechter Qualität und niemandbenutzt gerne Dinge von schlechter Qualität.Und davor hat man eben auch Angst.Dann auch noch ein Punkt, schwierige Probleme alleine lösen zu müssen.Ich meine, manchmal sind die Probleme wirklich sehr, sehr schwierig,vor denen man löst, sodass da auch einfach eine Angst da ist,alleine mit einem Problem zu kämpfen und nicht zu wissen, ob man das Problemjetzt niederringt oder von dem Problem niedergerungen wird.Und dann eben immer wieder der Zeitdruck, nicht genug Zeit zu haben,um in dem Projekt erfolgreich zu sein.Quasi nicht die Bedingungen zu haben, Erfolg haben zu können.Das heißt von vornherein zu wissen, dass es eigentlich nur schief gehen kannoder im besten Falle man gerade mit einem blauen Auge da vorn kommt.Das sind so die ganzen Ängste.

Tim Pritlove 0:13:41

Okay, das heißt, spätestens jetzt haben wir glaube ich mehrere Leute davon abgebrachteine Programmierer-Kurier in ihrem Leben einzuschreiben.Bevor wir jetzt zu Lösungsansätzen kommen, würde ich nochmal fragen,seit wann programmierst,du jetzt konkret? Nur mal so ein bisschen auch deine Aussage im Hintergrundder Erfahrung reflektieren zu können.

Pavel Mayer 0:14:03

Ja, also ich glaube, mein mein erstes Programm habe ich so 1979 geschrieben,noch auf einem Blatt Papier und ja, Geld verdiene ich damit glaube ich so seit81, 82 etwa, das heißt ich habe schon, kann man sagen,ja, als Profi weit über 20 Jahre lang Software. Ciao.Entwickelt.

Tim Pritlove 0:14:34

Ja du hast ja eigentlich auch sehr viele Programmiersprachen gesehen und dieseganzen Probleme, die du gerade angesprochen hast, sind auch wirklich vollkommenunabhängig von Betriebssystemen, Plattformen, Größenordnungen,das interessiert eigentlich immer alle.Ja das ist. Ich kenne auch einige der engsten, die du aufgezählt hast,haben mich sicherlich auch schon mal durchgestanden.Wobei man manchmal auch so ein bisschen noch die die Freude der Blauäugigkeit hat und sagt,holy droh, Programmieren macht so einen Spaß, da rauscht man einfach durch undlässt sich eben auch von Ängsten an nicht so sehr viel bremsen,aber das ändert noch nichts daran, dass man eben immer noch dazu neigt,Sachen zu entwickeln, die am Ende keiner haben will oder die im Zweifelsfallauch nicht funktionieren.

Pavel Mayer 0:15:12

Ja, also irgendwann wird oder die meisten Projekte, so habe ich sie kennengelernt,wurden entweder irgendwann langweilig oder ja, es wurde dann fast hysterisch.Je näher dann die Deadlines rückten, umso näher rückten sie auch dem Nervenzusammenbruch.Es gab dann einige gute Leute, auf denen die ganze oder auf den besten Leutenruhte dann auch die Last des ganzen Projekts,die waren dann irgendwann auch gar nicht mehr ansprechbar und so jetzt als Managerkonnte man dann nur da stehen und beten und und hoffen,dass sie jetzt das wirklich auch hinbekommen.Aber man steuerte dann irgendwann, hatte man das Gefühl, komplett nur noch imBlindflug unterwegs zu sein und nur darauf zu hoffen,dass die einzelnen Leute irgendwie das Ganze noch gerade rechtzeitig rettenund dass man so noch die Kurve kriegt.

Tim Pritlove 0:16:12

Wobei oh wunder oh wunder ich habe das auch sehr häufig dann gesehen also dieseKraft der der letzten Tage oder im Zweifelsfall auch der letzten Stunde,das Programmieren mal wieder zu den Höchstleistungen.

Pavel Mayer 0:16:23

Ja die sogenannte Crunch Time also ich habe das lange Zeit auch für Normalität gehalten, für halt.Den normalen programmierer alltag weil ich es nirgendwo anders gesehen oderoder kennengelernt habe und.Ich muss sagen tatsächlich ist es aber nicht so es muss nicht so sein sondernmit xp habe ich, Das schien mir,als ich darauf gestoßen bin, erst mal alles sehr plausibel zu sein.

Tim Pritlove 0:16:55

Also XP, muss man dazu sagen, ist die anerkannte Abkürzung für Extreme Programming,hat in diesem Fall nichts mit Windows zu tun, aber so nennt man es halt, okay.

Pavel Mayer 0:17:04

Und es war aber auch nicht ganz einfach, damals wirklich damit zu beginnen.Also in der einen Firma, in der ich dann war, hatte ich versucht,nun mein Team und meine Kollegen in der Geschäftsleitung damals davon zu überzeugen,dass wir das doch probieren.Aber ja, jede Art von Methodik wurde dann eher von der Hand gewiesen und nee,wir haben das schon immer so gemacht und jetzt irgendeinen Schnickschnack.Aber als ich dann einen neuen Job angeboten gekriegt habe, bot sich dann dieGelegenheit, dass ich dort als Bedingung gestellt habe, dass ich freie Handhabe in der Organisation,der Entwicklungsabteilung und dass ich insbesondere freie Hand habe,dort Extreme Programming einzuführen.Und alle Leute, die dann eingestellt wurden, die ich eingestellt habe,habe ich von vornherein ja auf Extreme Programming eingeschworen.Und um es mal vorwegzunehmen, wir betreiben das jetzt seit fünf Jahren und auchalle Leute in dem Team sind davon dermaßen überzeugt,dass das eine vernünftige Sache ist,sodass das zu einem Selbstläufer geworden ist.Ich glaube nie würde, gerne zu einer anderen Art von Softwareentwicklung wieder zurückzukehren.Das wäre irgendwie wie ein Rückschritt in die Steinzeit oder in die, ja, so.

Tim Pritlove 0:18:44

Okay gut dann spielen wir das doch mal durch so ich bin jetzt euer neuer Programmiererich werde jetzt irgendwie eingestellt nachdem ich meine über vollkommen übertriebenenGehaltszahlungen durchgesetzt habe.

Pavel Mayer 0:18:57

Ja das würde dir sicherlich nicht gelingen.

Tim Pritlove 0:19:01

Aber das glaube ich auch nicht.Aber nehmen wir es einfach mal an, um die Stimmung hochzuhalten.Wie auch immer. Auf jeden Fall, was müsste ich jetzt lernen?Was kommt auf mich zu, wenn ich mit XP, also Extreme Programming,in die Softwareentwicklung einsteige?

Pavel Mayer 0:19:18

Okay, als erstes, äußeres oder auffälligstes Merkmal würdest du sehr viel Zeitmit anderen Mitprogrammierern vor einem Rechner sitzen, vor einem Bildschirm, vor einer Tastatur,mit einem normalerweise, wobei durchaus auch Situationen dann entstehen,wo dann mal drei oder vier Leute vor einem Bildschirm sitzen,aber das ist dann schon eher etwas übertrieben.Aber in der in der Regel sitzen halt eben immer zwei Leute vor dem Bildschirm.Der eine ist der sogenannte Driver, der programmiert und der andere sitzt daneben,schaut sich an, was er macht, behält das große Bild im Kopf,weist ihn eventuell auf Fehler hin.Und ja, und wenn er zu ungeduldig wird und meint, jetzt irgendwie selber malHand an, dann wechselt man eben die Rollen, dann kriegt er die Tastatur in dieHand und okay, dann dann dann mach du, wenn du meinst.

Tim Pritlove 0:20:21

Also der eine ist der Driver und der andere hatte auch einen Namen?

Pavel Mayer 0:20:25

Ja der partner er wird genau alsoder driver und der partners ist die die offizielle xp bezeichnen aber.XP ist halt viel viel mehr als jetzt nur per programming und das ist ein einsicherlich eines der wichtigsten merkmale so nennt man das per programming.

Tim Pritlove 0:20:50

Pair Programming. A. Der Fabriker ist noch nicht fallen gelassen.M. Ja. A. Im Paar programmieren.

Pavel Mayer 0:20:55

M. Ja.

Tim Pritlove 0:20:55

A. Okay. Aber das ist, glaube ich, auch das, wofür es am bekanntesten ist.Also wenn ich so von einem Erfahrungsraum, wenn man jetzt Leute auf ExtremeProgramming anspricht, dann sagen sie, ah ja, das ist da, wo man irgendwie gemeinsamvor dem Computer sitzt. Pair Programming.

Pavel Mayer 0:21:07

M. Ja. Also in der Praxis, möchte ich auch mal, um es davor wegzunehmen,es eignet sich nicht jede Tätigkeit dazu.Man kann in etwa sagen, je komplizierter die Aufgabe ist, umso besser ist es,zu zweit daran zu arbeiten.Einfache Dokumentationstätigkeiten zum Beispiel funktionieren zu zweit nichtso gut, weil der eine sich dann einfach nur langweilt und nicht wirklich was zu tun hat.Aber praktisch alle anspruchsvolleren oder schwierigeren Aufgaben,da braucht man gar keine äußeren Regeln, da holen sich die Leute sofort gerneund freiwillig jemanden dazu.

Tim Pritlove 0:21:48

Das Modell des Pair-Programmings bricht ja im Prinzip so mit so einem grundlegenden Diven-Status,den ja Programmierer eigentlich über lange Zeit immer genossen haben und wannauch mich erinnern kann, in jeder Firma gab es eigentlich immer mit dem einen oder anderen Gott,der halt so vor seiner Maschine saß und niemand traute sich auch nur in dreiMeter Umkreis oder irgendwie ihn zu berühren, weil man Angst hat,gleich zu Staub zu zerfallen,weil eben so übermächtig die Maschine im Griff hat. Das habt ihr sozusagen gar nicht mehr.

Pavel Mayer 0:22:15

Und ja, man muss...Sehen das bei bei extrem programming vieledinge ineinander greifen und das ein wichtigesziel oder ein ein wichtiges ding ist auch jano home monopoly zu vermeiden das heißt dass man versucht das gesamte wissenüber die ganzen entwickler möglichst breit zu zu streuen und zu verteilen undAlso wenn du jetzt kämst, das ist auch ein großer Vorteil.Jetzt würdest du halt sofort mit einem erfahrenen Mann die ersten Wochen vordem Rechner sitzen und natürlich sehr schnell alle spezifischen Dinge,alle Tricks, wo befindet sich was, sehr schnell aufnehmen.Das heißt, es eignet sich wunderbar, also es gibt keine Methode,wo man als Einsteiger wirklich schneller reinkommt, als einfach die ganze Zeitmit jemandem zusammen da zu sitzen. Also typischerweise.

Tim Pritlove 0:23:17

In zwei Fällen auch erstmal als Partner.

Pavel Mayer 0:23:18

Ja, ja, als Partner, wobei auch die Leute sehr, sehr schnell dann selber auchdurchaus als Driver unterwegs sind.Und je nachdem, also wir haben dann Einarbeitungszeiten zwischen,ich würde sagen, zwei Wochen und zwei Monaten typischerweise,je nachdem wie viel Vorqualifikation die Leute haben, bis sie voll einsetzbar sind.Und spätestens nach sechs Monaten sind sie wirklich vollwertiges Teammitgliedund können wiederum ja als erfahrene Leute bereits dann wieder neue Leute anlernen.Umgekehrt ist es, wenn man mal einen Experten in einem bestimmten Gebiet vondraußen reinholt für eine begrenzte Zeit und den auch immer ins Pair gleichpackt, dann ist das natürlich die beste Art und Weise, um Know-how abzusaugen.Das heißt, auch was der Experte macht, das gesamte Wissen, So kann man am meistendavon profitieren, wenn immer jemand mit dabei sitzt.Und wer mit dabei sitzt, das entscheidet man.Oder die Paarungen, die sind jetzt nicht fest, sondern die werden im Prinzipjeden Morgen beim sogenannten Stand-up-Meeting aufs,Neue,ausgeknobelt.Das heißt...

Tim Pritlove 0:24:42

A, das heißt es gibt so einen Tagesrhythmus.

Pavel Mayer 0:24:44

Genau.

Tim Pritlove 0:24:44

Der Tag fängt an, erstmal trifft man sich.

Pavel Mayer 0:24:46

Der Tag fängt an, typischerweise bei uns um 10 Uhr, ist so eine ganz gute Zeit.Für alle und um 10 Uhr beginnt das Stand-up-Meeting, das heißt alle stehen,niemand darf sitzen, das verhindert, dass das Meeting endlos ausufert.

Tim Pritlove 0:25:04

Acht, deswegen Stand-up-Meeting.

Pavel Mayer 0:25:06

Ja, weil man das im Stehen macht und das macht man typischerweise vor einem...

Tim Pritlove 0:25:11

Ist das eure Methodik oder ist das tatsächlich Bestandteil von XP?

Pavel Mayer 0:25:14

Ja, das ist auch eine XP-Methode,und verhindert eben ja, dass das Ausufern.

Tim Pritlove 0:25:20

Sondern wahrscheinlich auch, dass die Leute ihre Laptops so klappen.

Pavel Mayer 0:25:23

Ja, ja.

Tim Pritlove 0:25:26

Der Tod jedes Meetings.

Pavel Mayer 0:25:28

Und so das Stand-up-Meeting morgens läuft so,dass jeder erzählt, was er am Vortag gemacht hat, welche,also auf welche Probleme er gestoßen ist und erzählt dann, was er für den heutigenTag vorhat und sucht sich dann jeweils ein Pair für die Aufgabe.Und da gibt es den Grundsatz, also wie man ein Pair findet, man fragt halt, kannst du mir helfen?Und die vorgeschriebene Antwort darauf ist ja.

Tim Pritlove 0:26:01

Okay, Beteiligungszweig.

Pavel Mayer 0:26:03

Und man kann dann aber, also es ist auch so, jeder hat seine Aufgaben,die er sogenannte Engineering Tasks, die er, für die er selber verantwortlich ist.Und wenn er sich jetzt jemanden dazu holt, der andere hat natürlich auch Engineering Tasks.So, aber dann sagt man halt, okay, ich helfe dir jetzt meinetwegen heute Vormittagund Und heute Nachmittag hilfst du mir dann wiederum bei meinem Engineering-Task,oder ich helfe dir heute und morgen hilfst du mir bei einem Task.

Tim Pritlove 0:26:36

Wie ist das eigentlich, wenn man jetzt eine ungerade Zahl Programmierer hat?Was macht man dann? Kommt dann noch eine andere Gruppe dazu?

Pavel Mayer 0:26:42

Ja, das ist schlecht. Ihr könnt ja nicht immer im Zweierpasch neue Entwickler…Ne, wie gesagt, es gibt Tätigkeiten auch, die besser alleine funktionieren,wenn man ein neues Betriebssystem….A. so hin und ja, es gibt halt dann auch andere Meetings, wo man sich koordinieren muss.Also es ist nicht, es ist nicht, nicht wirklich schlimm jetzt,wenn man mal eine ungerade Zahl, ja, also das, das, das findet sich dann, dann schon.Also jedenfalls verhindert man dadurch Know-how-Monopole,was,sehr gut ist, wenn die Leute mal in den Urlaub gehen wollen,dann ist immer jemand da, der trotzdem Bescheid weiß.Früher war das eben immer ein Problem, dass bestimmte Leute in kritischen Projektphasen,einfach nicht krank werden durften,ja keinen Urlaub nehmen konnten.Und wenn dann so jemand, wenn dann jemand auch noch die Firma vielleicht verlässt,dann waren das immer gewaltige Katastrophen, die halt tatsächlich ganze Projekte gefährden konnten.Das ist eigentlich ein sehr unprofessioneller Zustand und das ist für alle einfach sehr entspannt,dass sie, dass sie wissen, dass die gesamte nicht nur alleine auf ihren Schulternruht jetzt, sondern dass sie sich jederzeit jemanden zur Hilfe holen könnenund dass auch viele Leute da sind.Das ist einfach ein unheimlich gutes Gruppengefühl.

Tim Pritlove 0:28:13

Was ich auch noch sehe ist, dass man natürlich dabei auch eine ganze Menge Kleinigkeiten lernt.Also es sind ja immer so diese kleinen Tricks, so wie löse ich irgendwie dieseskleine Problem, so ganz alltägliche Sachen, wie kapsel ich das jetzt,wenn ich mit solchen Datentypen zu mache, Sortieralgorithmen, also so everyday.

Pavel Mayer 0:28:29

Ja, allein Editor-Tricks, also wie man seinen Editor bedient oder wie man sichseinen Arbeitsprozess, seine Oberfläche.

Tim Pritlove 0:28:38

Und so hat man die Weiterbildung quasi parallel automatisch mit eingebaut.

Pavel Mayer 0:28:42

Und wenn jemand mal eine gute Idee hat oder einen netten Trick,dann verbreitet sich der einfach ganz schnell in der ganzen Firma,auch durch die wechselnden Paarungen.So, was aber jetzt dazu kommt als Prinzip auch noch,ist, das ist die sogenannte collective code ownership, beziehungsweise,also jeder darf jederzeit am gesamten Code ändern, was er will.Früher war das immer so, das ist mein Code und wehe, da fasst jemand dran an,dann übernehme ich keine Verantwortung oder Garantie, dass das Ganze noch funktioniert.Einer unserer Entwickler früher brachte der Spruch, ja, wenn der Programmiererim Urlaub ist, dann ist sein Code auch im Urlaub.So, das heißt, der darf dann eben nicht verändert oder nicht angefasst werden.Und bei Extreme Programming ist es explizit so, sowas gibt es nicht.Jeder darf überall alles ändern. So das Problem ist jetzt natürlich,wenn jeder überall alles ändern darf und eventuell aber nicht die Zusammenhängeversteht, wie verhindert man,dass jeder die Dinge kaputt macht?Und da kommt dann wieder ein anderes wichtiges Prinzip, nämlich,die sogenannten Unit-Tests. Das heißt, jede Funktion, die man einbaut,hat einen dazugehörigen Test, der auch automatisch abläuft.Und sobald man eine Veränderung irgendwo macht, also wir haben jetzt.

Tim Pritlove 0:30:14

Was heißt, er läuft automatisch ab? Ja, muss ja im Prinzip das ganze Software-Setup,schon mal so sein, dass es eine Stelle gibt, wo immer Tests laufen.

Pavel Mayer 0:30:23

Ja, genau.

Tim Pritlove 0:30:23

Es gibt, man hat natürlich ein zentrales Software-Repository,wo also typischerweise CVS oder Subversion, wo die ganze Software eingechecktist, zentral und man sich einzelne Teile rausholen kann.

Pavel Mayer 0:30:36

Genau. Und in dem Moment, wo man jetzt Veränderungen wieder in das zentraleRepository zurückspielt, gibt es dann wiederum Rechner, die das merken,aha, da hat es eine Änderung gegeben,sich die Software holen, sie übersetzen, in dem Fall also compilen und dannautomatische Tests ablaufen lassen, die halt ja dann die Ergebnisse mit Sollwerten vergleichen.

Tim Pritlove 0:31:02

Das heißt, bevor man eine neue Funktion einbaut, muss man sich quasi auch gleichzeitigGedanken darüber machen, wie man das testen kann.

Pavel Mayer 0:31:08

Genau, typischerweise.

Tim Pritlove 0:31:09

Gibt es Fälle, wo das nicht greift?

Pavel Mayer 0:31:12

Eigentlich sollte man sogar den Test vorher schreiben. Also bevor man die Funktionschreibt, schreibt man erst den Test, was auch gleichzeitig hilft,sich Gedanken über die Schnittstelle zu machen.

Tim Pritlove 0:31:23

Ja, genau. Wie wird das benutzt?

Pavel Mayer 0:31:24

Wie wird das benutzt? Das heißt, das entsteht dann meistens parallel,also der Test und die Funktion,wobei es gibt eben bei den Tests unterschiedliche Tests, aber wichtig da sindvor allem die Modultests auf verschiedenen Ebenen und wir haben,Unittest heißt das, weil man sich sozusagen auf eine Teilfunktion bezieht.

Tim Pritlove 0:31:46

Auf eine einzelne Unit eben.

Pavel Mayer 0:31:48

Genau, ein bestimmter Modul, eine bestimmte Funktion.Es gibt auch entsprechende Frameworks, die einem das erleichtern.

Tim Pritlove 0:31:57

Also ich glaube zum Beispiel bei, das fällt mir jetzt gerade so ein,also es gibt sicherlich noch andere gute Beispiele, aber bei Ruby on Rails,was ja derzeit eine sehr populäre Entwicklungsplattform ist,Da ist im Prinzip Tests auch von vornherein vorgesehen.Es gibt so eine definierte Direktoriestruktur und es gibt auf jeden Fall schonmal einen Ort, wo man seine Tests rein tut, genau aus solchen Erwägungen heraus.Aber es gibt sicherlich auch noch andere Beispiele.

Pavel Mayer 0:32:20

Und da ist wichtig, dass es auch einfach ist, die Tests zu schreiben,dass es halt bequem ist zu testen. Das ist wichtig.Und da haben wir halt auch ein ganz brauchbares eigenes Framework,das es wirklich zum Kinderspiel macht. Und ja, ich glaube, also wir haben...Jetzt in den letzten zwei Jahren ein Framework entwickelt, was so,ich glaube, knapp 500.000 Zeilen Quellcode hat.Und ich glaube, ich habe jetzt nicht die genaue Zahl vor Augen,aber bei einem Durchlauf werden einige 10.000 Tests durchgeführt,so nach jeder einzelnen Veränderung.

Tim Pritlove 0:33:09

Und… eine Funktion? Wird sie jetzt zigtausendmal getestet oder es gibt zigtausend Tests?

Pavel Mayer 0:33:14

– Nein, typischerweise für eine Funktion hat man dann etwa, ich würde sagen,je nachdem wie kompliziert diese Funktion ist,zwischen ein bis zehn Tests, wo man dann versucht, sie mit unterschiedlichenParametern, das ist, wenn ein String reingegeben wird, dass man es mal mit einemleeren String probiert etwa,oder was ist, wenn der Parameter Null ist, dass man halt auch,normale Fälle und Grenzfälle und auch die Fehlerbehandlung testet,typischerweise, um zu sehen, ob auch der richtige Fehlercode zurückgegeben wird,wenn die falschen Parameter reingehen. A.

Tim Pritlove 0:33:52

Das finde ich ganz interessant, weil was ich sehr häufig festgestellt habe beiProgrammierern ist, dass sie so eine Mentalität entwickeln, so ja,das muss ich jetzt nicht überprüfen, weil das hat man ja nicht zu machen.Man hat das ja nicht so zu benutzen und der Benutzer ist ja doof.Und wenn es auch wiederum nur ein Programmierer ist, der in dem Fall der Benutzer ist.Weil sehr viel häufiger glaube ich, als dass jetzt wirklich es sich um Codehandelt, der von jemandem benutzt wird.Es ist ja so, dass andere Programmierer den Code benutzen, weil man eben Modulebereitstellt und so weiter.Und viele dieser Fehler, die heutzutageauftreten und die auch für viele Security-Fehler verantwortlich sind,Entstehen meistens einfach nur deshalb, weil der Programmierer sich gar nichtvorstellen kann, dass irgendjemand das in einer Art und Weise benutzt,die anders ist als die, die er sich ursprünglich gedacht hat,die sozusagen den normalen Zustand darstellt.Das schärft sicherlich die Sinne ein bisschen, oder? Wenn man solche Tests schreibt.

Pavel Mayer 0:34:44

Auf jeden Fall. Aber es gibt vor allen Dingen auch Leuten, die relativ neu dasind, so das Vertrauen, wenn sie an einem riesigen System etwas ändern und trotzdemalle Tests noch durchlaufen, dass sie nichts kaputt gemacht haben.Das heißt, eine Methode greift eben in die andere und das eine geht nicht ohne das andere.Das heißt, ein bisschen XP ist zwar,vielleicht besser als ich sag mal keine dieser methoden zu benutzen aber sorichtig die die volle schönheit entfaltet sich tatsächlich erst wenn diese ganzendinge ineinander greifen und.Mal also diese methoden jetzt mit dem also wie beispielsweise per programmingund test sind natürlich dinge die vor allem die entwickler betreffen aber eine ganz wichtige.Front ist eben jetzt, also es fängt halt viel früher an, nämlich bei der, an der Kundenfront.Das heißt, wie man das ganze Projekt von vornherein aufzieht.

Tim Pritlove 0:35:46

B2. Der Kunde, das unbekannte Wesen. A3.

Pavel Mayer 0:35:48

Ja, der, der Kunde. Wir hatten ja schon… B2.

Tim Pritlove 0:35:52

Programmierer hassen Kunden.

Pavel Mayer 0:35:54

A3. Ja, eben, oder beziehungsweise sie haben Angst vor Kunden, weil sie…,Das hatten wir ja eingangs schon erwähnt, dass es da eben so das heißt,erst mal fängt es damit an, was oft Wunder wirkt, ist, dass man diese Ängsteoffen benennt, auch gegenüber dem Kunden.Das ist oft, das ist gar nicht einfach, das erfordert Mut, weil so über Ängstezu reden mit einem Kunden,aber wenn man sich tatsächlich dann mal überwunden hat, tatsächlich also diesen Mut zur Wahrheit,so entsteht dann erstmal ein ganz anderes, neues Vertrauensverhältnis und dieÄngste tatsächlich schwinden oder werden kontrollierbar, weil man einfach darüber redet.Hey, ich habe Angst davor, dass du mir Unmögliches abverlangst so und du hast Angst davor.Ja, dass ich das verkacke, so. Lass uns sehen, wie wir irgendwie gemeinsam.

Tim Pritlove 0:36:57

Und was macht man da mit dem Kunden?

Pavel Mayer 0:36:59

Ja, und dann ein ganz wichtiges Ding ist, rauszufinden, was dem Kunden wichtig ist und was nicht.Das heißt, was wir typischerweise machen, also wir schreiben alle Anforderungen, alle Ideen,alles, was der Kunde gerne hätte, Egal wie absurd es klingen mag oder wie nebensächlichoder wie vielleicht sogar unmöglich ist, es wird erst mal alles aufgenommen.Und dann, was auch wichtig ist, dass man die Dinge, die man aufnimmt,also in XP macht man das in Form von sogenannten User Stories.Das heißt, man versucht, in nicht technischer Form zu beschreiben oder zu besprechen,was das System eigentlich tun soll.In Form von so einer Art Storyboards. Das heißt, wie geht der User mit dem System um?Plus eben zusätzliche Anforderungen, wenn er schon etwas genauer weiß,wie, keine Ahnung, das muss unter Windows laufen oder es müssen irgendwie 1000Leute damit gleichzeitig arbeiten.

Tim Pritlove 0:38:06

Das ist alles Storyboards, also quasi wie ein Drehbuch, dass man also wirklich versucht, die...Funktionalität, also nicht die Funktionalität, sondern die Art und Weise,wie die Software eingesetzt wird, zu beschreiben wie einen Film.

Pavel Mayer 0:38:17

Ja, so in etwa wie kleine Episoden aus einem Film und dann halt ja weitere Anforderungen,die der Kunde oft hat, eben in eine Liste zu bringen.Und dann ist es ganz wichtig, das priorisieren, weil nicht alle Anforderungensind natürlich gleich wichtig.Und es ist ganz wichtig rauszufinden, was ist dem Kunden wichtig und was istdem Kunden weniger wichtig und was ist nur nice to have.Also typischerweise haben wir dann eine Liste von Merkmalen.Also muss Dinge, die unbedingt sein müssen, Dinge, die ihm wichtig sind undDinge, die er zwar ganz gerne hätte, aber auf die er dann im Notfall auch verzichten kann.Und das Interessante ist, viele dieser kleinen Dinge, die ihm nicht so wichtigsind, sind oft wenig aufwendig, sodass man die auch einfach mit erledigen kann.Das heißt, selbst wenn die Zeit knapp ist, muss man nicht alle Nice-to-haves.Unter den Tisch fallen lassen, sondern die kann man dann nebenbei erledigen.Aber ganz wichtig ist, dass wenn man die Dinge, die dem Kunden am wichtigsten sind,zuerst versucht zu realisieren und einem dann irgendwann die Zeit ausgeht,dann sind hoffentlich nur noch die weniger wichtigen Dinge übrig,aber die wichtigen Dinge sind bereits da.Das ist ein ganz, ganz elementares Prinzip.Und die Prioritäten können halt während des Projekts jederzeit auch wieder neu festgelegt werden.

Tim Pritlove 0:39:51

Aber jetzt sind ja die Features, die der Kunde haben will, nicht unbedingt immerdie Features, die dem Programmierer auch Spaß machen.Ja also an der Stelle wird es auch immer spät, häufig ist es ja auch wichtig,dass man den Programmierer bei Laune hält, wie greift ihr das?

Pavel Mayer 0:40:02

Ja aber da muss der Programmierer dann einfach über seinen Schatten springenund sich darüber im klaren werden,wer ihm in dem Fall seine Brötchen bezahlt und ja da ist der Kunde dann schontatsächlich einfach König.

Tim Pritlove 0:40:18

A. Ok, aber wenn wir an der Stelle mal vielleicht einen Schritt zur Seite machenund ein bisschen über Open Source Entwicklungen nachdenken.Viele Leute, die Chaos Radio hören, sind ja auch in dem Feld selber tätig.Findest du, dass eben auch für Open Source Projekte Extreme Programming hilfreich sein kann?Oder ist das jetzt wirklich nur die Erleichterung, um im Kontext einer Firma,also in so einem künstlichen Gebilde, was es ja eigentlich ist, zu überleben?

Pavel Mayer 0:40:46

Das ist natürlich die Frage, wo ist der Kunde bei Open Source?

Tim Pritlove 0:40:52

Das ist eine gute Frage.

Pavel Mayer 0:40:55

Und was auch wichtig oder eigentlich bei XP im Idealfall ist,ein Vertreter des Kunden,ist halt Teil des Teams, ist ständig oder ist zumindest ständig verfügbar,um Fragen zu beantworten. Das ist auch eines.

Tim Pritlove 0:41:11

Ist das eine Bedingung an den Kunden? Geht ihr da so ran und sagt,okay, wenn ihr von uns was wollt, dann müsst ihr ja auch eine Person abstellen,die immer ansprechbar ist?

Pavel Mayer 0:41:18

B2. Ja, das ist das Ideal, ist aber, also ist auch eines der Ideale in XP,die am tatsächlich am schwierigsten in der Praxis umsetzbar ist,weil entsprechend qualifiziertes und autorisiertes Personal beim Kunden sehrhäufig nicht zur Verfügung steht.Und da arbeitet man dann mit einem Stellvertreter, also beispielsweise,dass man einen Projektleiter hat, der nicht Mitglied des Entwicklungsteams istoder bei der Projektentwicklung ein Produktmanager,der dann die Kundenrolle wahrnimmt und dann eben dort die Prioritäten setztund einfach Entscheidungen trifft.Und der Programmierer wiederum, der Entwickler, ist dann in der schönen Situation,jeweils wenn jetzt ein neues Feature beispielsweise verlangt wird,dass dann dafür natürlich, wenn man priorisiert, entsprechend ein anderes Featurenatürlich geringere Priorität bekommt, zwangsläufig.Das heißt, der Kunde kann auch nicht immer, ich sag mal, mehr und mehr reinpacken,ohne weiteres, sondern er muss dann gleichzeitig für jedes Ding,was jetzt vorgezogen oder einen höheren Stellenwert kriegt, bekommen natürlichandere Dinge zwangsläufig einen geringeren Stellenwert.Und das ist aber auch ganz in Ordnung so.

Tim Pritlove 0:42:45

Um das nochmal auf Open Source zu übertragen, ist das natürlich eine schwierigeForderung sozusagen den Kunden.Auf der einen Seite hat man bei Open Source natürlich auch eine extreme Beteiligungin der Regel von Kunden, von Nutzern, ob die jetzt von dem Programmierern sowahrgenommen werden und auch so wertgeschätzt werden, sei mal ganz dahingestellt.Also die Masse ist auf jeden Fall da und üblicherweise hat man ja auch relativnahe Wege, Mailinglisten etc.

Pavel Mayer 0:43:08

Ja, wobei ja also bei Open-Source-Projekten, also bei rein Open-Source-Projekten,die,irgendwie,sovon,ein,zwei Leuten mal begonnen werden, weil sie ein brennendes Problem lösen wollen,da funktioniert das natürlich so nicht.Aber wenn ein oder zwei Leute irgendetwas machen, da braucht man dann auch XP nicht.Also XP funktioniert am besten, also skaliert am besten so für Teams mit fünfbis sechs Leute jeweils.Also man kann es bis zehn etwa, also zehn Leute in einer Gruppe noch hoch skalieren,aber wir haben die Erfahrung gemacht, dass wir halt sobald jetzt eine Gruppeso sechs, sieben Leute überschreitet,dass wir dann die Gruppen teilen und lieber zwei Gruppen machen,wobei die Gruppen dann wiederum regelmäßig Teammitglieder austauschen in regelmäßigenAbständen, um die Kommunikation zwischen den Teams aufrecht zu erhalten unddas auch gepairt wird zwischen den Teams,damit halt die sich nicht komplett verselbstständigen.

Tim Pritlove 0:44:14

OK, also eure komplette Mannschaft teilt sich in verschiedene Teams auf oderGruppen, die sich unterschiedlichen Gesamtproblemen zuwenden,auch wenn es am Ende alles zusammengehört.Und dann wird auch da untereinander getauscht. Das heißt, man ist eigentlichauch sehr viel weniger die ganze Zeit an einer Sache. Weil üblicherweise, ich kenne das auch,hat man ja dann immer so den Experten für dieses und diesen Experten für diesesund die tendieren dann auch dazu immer in ihrem Code dran zu kleben und danneben auch nicht mehr so änderungsfreundlich zu sein, das wollt ihr damit quasi verändern.

Pavel Mayer 0:44:42

Ja ich meine man arbeitet, um jetzt nochmal weitere Prinzipien oder Methoden,man arbeitet iterativ und relativ kleinteilig, also Also auch ein Ding ist,man versucht so schnell wie möglich,ein funktionierendes System zu haben.Bei uns haben wir uns auf sogenannte Iterationszyklen von zwei Wochen geeinigt.Das heißt, man plant immer die Arbeit für zwei Wochen im Voraus.Also jeden Morgen gibt es dieses Stand-up-Meeting, aber.Alle zwei Wochen gibt es das sogenannte die Iterationsplanung treffen,wo man ja die sogenannten Engineering Tasks, das sind die kleinsten Arbeitseinheiten,die kleinsten Aufgaben, wobei jede Aufgabe dann so idealerweise ein bis dreiTage an geschätzter Entwicklungszeit nur haben sollte.Weil wir haben festgestellt, dass es schwierig ist, Aufgaben,von denen man glaubt, dass man mehr als drei Tage dafür braucht,zuverlässig schätzen zu können.So das heißt, wenn man jetzt denkt, ich brauche für die Aufgabe sechs Tage, dann geht das nicht.Dann muss diese Aufgabe weiter unterteilt werden in zwei oder drei Teilaufgaben,die man wiederum beschreibt, also Engineering Tasks, die halt eine geringere Schätzzeit haben.Und das ist eben auch, Also dieses Versuchen, zu schätzen, wie lange man braucht,ist auch ein wichtiger Prozess.Und da gibt es eben diese sogenannte ideale Programmierzeit,die man schätzt und am Ende jeder Iteration oder nein, man hält täglich sogarfest, schätzt man für jede Engineering Task morgens beim Stand-up-Meeting.Wie viele Tage brauche ich noch?Also wenn ich jetzt drei Tage geschätzt habe, habe jetzt einen Tag gearbeitet,dann kann es sein, dass ich feststelle, okay, das ist jetzt doch schwieriger geworden.Ich schätze, ich brauche immer noch drei Tage.Und so hat man auch eine ganz gute Kontrolle, also einmal eine Selbstkontrolledarüber, wie viel Arbeit noch da ist und wie gut man mittlerweile im Schätzen geworden ist.Und nach 14 Tagen berechnet man dann die sogenannte Velocity des Teams, das heißt,wie viele von den Engineering-Tasks sind jetzt tatsächlich fertig geworden undwie viele, also die Velocity sind dann sozusagen die Tage idealer Programmierzeit,die man in der Lage war, vorauszuplanen.Das ist dann auch so ein selbstregulierendes Ding, weil für die nächste Iterationnimmt man sich dann wieder nur so viel Tage oder darf man sich nur so viel Tagevornehmen, wie man in der letzten Iteration auch geschafft hat.

Tim Pritlove 0:47:28

Also quasi über die über die die Methode der Selbsteinschätzung,der sicherlich auch nochmal Angst mindernd wirkt, nicht, wenn man das überhaupterstmal so zugibt, so ich habe länger gebraucht, das ist ja auch nicht unbedingtjetzt jedermanns Sache, da so offen einzustehen.Fühlt man ja sozusagen dann auch eine eine Selbstkontrolle.

Pavel Mayer 0:47:45

BK'IN WIRKLICHE REDEN. Ja und an der Stelle, also XP generell erfordert schonOffenheit und Vertrauen,aber auch einen Vertrauensschutz dann, weil man offenbart sich schon an verschiedenen Stellen.Also es fängt an beim Pair-Programming, wo man natürlich auch seine Schwächen,und vielleicht Fehler, die man macht, seinem Partner offenbart.Das fällt anfangs, merkt man oft vielen Leuten, nicht leicht,weil sie denken, der hält mich jetzt für einen Idioten, weil ich irgendwie keineAhnung dieses oder jenes Keyword vielleicht in der Programmiersprache nicht kenne.Und diese Angst zu nehmen, so das ist auch ein ganz, ganz wichtiges Ding,auch, dass man Leute eben nicht in die Pfanne haut,wenn sie sich jetzt verschätzt haben, sondern dass man das eben als normalen,als Normalität auch begreift und versteht und versucht, dann einfach gemeinsamdas Ganze besser zu machen.Da ist auch ein wichtiges Prinzip, dass jeder selber seine Zeit schätzt.Also was nicht passieren darf bei XP ist, dass ich schätze, wie lange irgendjemandanders dafür jetzt brauchen darf, weil dann kann ich ihn auch schlecht drauffestnageln. Das heißt, jeder schätzt die Zeit für seine Engineering-Task selber.Das ist auch ein ganz wichtiges Prinzip.

Tim Pritlove 0:49:07

Was wenn man anderer Meinung ist, dann kommt das wahrscheinlich schon in diesemStand-up-Meeting. Genau, dann ist das auch Bestandteil des Stand-up-Meetings, diese Einschätzung.

Pavel Mayer 0:49:14

Ja, beziehungsweise, nee, das passiert bei der Iterationsplanung.Da schätzt man auch also alle 14 Tage sozusagen, wenn man diese Engineering-Tasks aufhängt.Das geht auch mit schönen kleinen Kärtchen.

Tim Pritlove 0:49:25

Da kommen wir zu den Karten. Okay, warte mal, da müssen wir nochmal kurz,nicht, dass es verwirrt, Ich bin ein bisschen verwirrt.Also wir haben jetzt an regelmäßigen Treffen, die Stand-up-Meeting, das ist jeden Tag.Dann sagst du, gibt es ein Iterationsplanungstreffen.

Pavel Mayer 0:49:39

Alle 14 Tage.

Tim Pritlove 0:49:40

Alle 14 Tage. Ist das jetzt auch so in XP vorgeschrieben oder ist das so eureErkenntnis, wie das so zusammenhängt?

Pavel Mayer 0:49:45

In XP sagt man so, Iterationen sollten ein bis drei Wochen etwa dauern.

Tim Pritlove 0:49:50

Okay, dann seid ihr in der Mitte alle zwei Wochen. Und das heißt,dass ihr quasi die Zeitziele aller einzelnen Tasks, aller einzelnen Aufgaben,die ihr euch gestellt habt, überprüft.Und dann eben auch danach, wahrscheinlich dann in Abhängigkeit der Abhängigkeitendieser Tasks untereinander, auch eine Aussage darüber treffen können,wie lange brauchen wir den eigentlich noch.Beziehungsweise, es gibt eine Deadline XY.Die dürfen wir nicht verpassen, weil die Messe fängt an, was auch immer.Und dann müssen wahrscheinlich entsprechend Features gekürzt werden oder manmuss sich zumindest darüber unterhalten, wie man das beschleunigen kann.Gibt es sonst noch irgendwelche regelmäßigen Treffen?

Pavel Mayer 0:50:23

Ja, es gibt bei größeren Projekten gibt es dann wiederum die sogenannten Release-Planungstreffen,die man dann so etwa im Zwei-Monats-Zyklus macht, wo man dann versucht größer,voraus zu planen, wo man dann die User-Stories sich eben auch überlegt,die man für die nächste Release gerne hätte.Wobei eigentlich haben wir bei unserer Arbeit festgestellt, dass wir seltenüberhaupt Release-Planungstreffen brauchen,weil die meisten Projekte, die wir machen, einfach innerhalb von zwei Monatenmit dem großen Team, was wir haben erledigt sind.Es gibt dann halt größere Treffen.Da gibt es dann noch weitere Strukturen oben drüber bei Projekten,die jetzt mehrere Jahre dauern.Ja.

Tim Pritlove 0:51:16

Aber wenn man jetzt ein Betriebssystem entwickelt oder so Sachen,die naturgemäß über sehr lange Zeiträume laufen, mag das schon sehr sinnvoll sein.So und diese Karten, die du jetzt erwähnt hast, die habe ich auch schon malgesehen. Die hängen dann bei euch an der Wand. Gibt es so Kärtchen?Was ist die Aufgabe dieser Karten, dieser Story-Karten?Naja, beziehungsweise diese Engineering-Task-Karten.Verschiedene Karten.

Pavel Mayer 0:51:38

Ja, wobei wir im Wesentlichen, die Engineering-Task-Karten,sind,bei uns jetzt konkret die wichtigsten. Das heißt, da weiß man einfach,an denen hangelt man sich morgens dann immer entlang.

Tim Pritlove 0:51:52

Was steht da drauf?

Pavel Mayer 0:51:52

Da steht dann zum Beispiel so etwas drauf, was ist so ein typischer Engineering-Task,bei uns, wie Unicode-Transparenz.In dem und dem Modul herstellen oder dafür sorgen, dass sich Objekte auf einerbestimmten Spline-Kurve bewegen oder …,eines bestimmten Bereiches, der klar auch messbar ist, ganz also wo man auchvor allem testbar und wo man dann ganz klar ja einzelne,features eben ja daswerden wahrscheinlich ganze menge karten dann sein das sindja also wir sehen zudass wir möglichst auch die drei tageskarten vermeiden wenn es geht das heißtwir haben ein und zwei tageskarten und drei tageskarten also wo die schätzungbei drei tagen liegt wissen wir die sind schon unter umständen kritisch alsodie unterschiedliche farbe also sieht man das gleich.Das steht drauf, es gibt eine Spalte dafür und da steht die erste Schätzung drin,also in jeder Zeile wird dann jeden Tag, wo an einer Karte gearbeitet wird,wird halt eingetragen, okay,wie viel ist dann gearbeitet worden und wie viel glaube ich,dass ich jetzt noch brauche für diese einzelne Task. A.

Tim Pritlove 0:53:25

Ok, das heißt diese Karte dient gar nicht mal nur dazu, um aufzuschreiben, was noch zu tun ist.Das ist jetzt nicht eine reine To-Do-Liste, sondern es reflektiert quasi auch,den Fortschritt, den man konkret gemacht hat.D.h. wenn ein Tag daran gearbeitet wurde und man hat das Problem noch nichtgelöst, dann wird eingetragen, den und den Fortschritt habe ich jetzt erzielt,oder macht man eine Strichliste oder was?

Pavel Mayer 0:53:46

Ich habe jetzt einen tag dran gearbeitet oder einen halbentag dran gearbeitet und ich brauche jetzt noch anderthalbtage beispielsweise und wenn die engineeringtask eben wenn ich fertig bin dann wird die schön durchgestrichen und dann wendetman sich der nächsten karte zu so und für 14 tage hat also jeder entwicklerso ich sag mal zwischen zwei bis vier karten etwa so und dann kann man sich das halt ausrechnen,so wie viel Engineering Tasks man so als Pro-Entwickler dann bearbeitet.Also pro Woche, sagen wir mal, zwei Karten. Das heißt, jeder Entwickler macht,halt etwa 100 Engineering Tasks pro Jahr.Und bei einem 10-Mann-Team sind es halt 1000 Engineering Tasks,die man so pro Jahr etwa dann,abarbeitet.

Tim Pritlove 0:54:40

Das heißt, man braucht eine relativ große Tafel.Wie viele Karten hängen da so normalerweise gleichzeitig?

Pavel Mayer 0:54:46

Immer nur die für die nächsten 14 Tage.

Tim Pritlove 0:54:49

Und wie viel sind das dann so bei euch, mal nur so von der Dimension?

Pavel Mayer 0:54:52

Naja, wie gesagt, so vier pro Person, je nach Teamgröße hängen dann da vielleicht20 Karten an der Wand so und die werden dann in 14 Tagen alle abgearbeitet.

Tim Pritlove 0:55:02

Haben die dann eine spezielle Sortierung? in einer Form also die abholen diejetzt nach den nach der Wichtigkeit nice to have oder wie?

Pavel Mayer 0:55:08

Sven Ne die werden ja konkret einer Person zugeteilt sodass das läuft dann so ab dass da wird dann in demTreffen eine Task aufgeschrieben und dann wird gefragt so wer hat Interessedran diese Task jetzt zu übernehmen und dann kann jemand die Hand heben undentweder man hebt die Hand frühzeitig oder man kriegt halt dann irgendwann dieKarten die übrig bleiben.So jetzt kann man sich dann überlegen, das funktioniert eigentlich recht gut.

Tim Pritlove 0:55:38

Die Karten sind einfach Papier. Schon mal drüber nachgedacht,das Ganze elektronisch zu machen?

Pavel Mayer 0:55:43

Ja, allerdings haben diese Papierkarten,doch erhebliche Handling Vorteile gegenüber was Elektronischen.Es geht einfach schneller mit den Karten an der Pinnwand. Die kann man ebenmal abnehmen oder zurückschieben.Man kann sie sehr schnell ausfüllen. Also da sind die Karten einfach jeder elektronischenLösung, glaube ich, überlegen.

Tim Pritlove 0:56:08

SIEGFRIED Lebt man die denn runter, wenn man dann jetzt sozusagen daran arbeitet?Heißt das so, ich picke mir heute meine Aufgaben?

Pavel Mayer 0:56:13

BARTHOLZ Nö, die hängen da und wie gesagt, vor allen Dingen morgens beim Stand-Up-Meeting,kann man dann die Karten durchgehen und die dienen dann sehr schön als Orientierung auch,dass man sich halt nicht verdaddelt und man sieht dann auch,was man noch zu tun hat an Aufgaben.Man kann sich das selber überlegen, an welcher Karte von denen,die man jetzt hat, man als erstes bearbeitet, spielt dann nicht unbedingt dieRolle, was man dann nimmt.

Tim Pritlove 0:56:42

Haben wir jetzt die ganzen konzepte im kern schon bei weitem nicht bei weitemnicht das klingt ja relativ komplexensystem wie lange muss man sich damit beschäftigen bis man das so halbwegs.

Pavel Mayer 0:56:55

Wie gesagt das geht das geht relativ schnell weil die sachen alle sie sind halt auch.Sehr, sehr eingängig und sie sind halt logisch und schlüssig und viele dieserDinge sind auch Dinge, die man sowieso schon macht oder mal gemacht hat,allerdings nicht in dieser Kombination und in dieser Gründlichkeit und Konsequenz.Also man setzt sich gerne mal mit guten Freunden zusammen vor den Rechner und das hat,glaube ich, auch jeder Programmierer mal gemacht oder das Testen gut ist,ist auch klar und priorisieren, aber das eben konkret zu machen,das ist wichtig, aber vielleicht noch mal auf die Iterationen zurückzukommenund auf den Kunden so ein bisschen.Wichtig ist es, hatte ich ja schon erwähnt, dass man sehr schnell was funktionierendeshat, was man auch dem Kunden zeigen kann, so dass man halt Feedback einholen kann.

Tim Pritlove 0:57:52

Kurze Redezeit hat sozusagen.

Pavel Mayer 0:57:54

Dass man eigentlich immer ein funktionierendes System hat, was man dem Kundenzeigen kann und wo er dann ganz konkret schon sehr früh sieht, was er bekommt.Das heißt nicht erst am Ende völlig überrascht ist, was hat er denn da,sondern eigentlich begleitet er den Prozess die ganze Zeit über und kann dannauch nicht am Ende sagen, hoch, also das hätte ich jetzt nicht erwartet.Und unsere Erfahrung ist, dass die Kunden, also in der Regel die das dann wirklichauch begleiten, dann doch sehr angetan sind und auch sehr überrascht sind, dann am Ende,wie viel, also wie sehr das System dann ihren Vorstellungen tatsächlich entspricht.Und so, das tut dann halt sehr.

Tim Pritlove 0:58:45

Also im Prinzip deine Erfahrung mit Extreme Programming ist die,um das mal auch ein bisschen zusammenzufassen, dass dadurch,dass man in Teams arbeitet,dadurch, dass Leute sich nicht nur um eine Sache kümmern, sondern dass man eigentlichseine Programmierer über die zu erledigenden Aufgaben streut,immer wieder austauscht,Dadurch, dass man seine Software, während man sie entwickelt,am laufenden Meta testet, dass man im Prinzip den Test schon vorher schreibt und auch dadurch,dass man sich bemüht, und das hängt ja mit diesen Tests auch ein bisschen zusammen,weil man kann ja nichts testen, was nicht läuft, dass man sich bemüht immerzu einem laufenden System beizutragen, sodass man eben nicht so drei,vier Wochen Hänger hat, wo erstmal gar nichts läuft und ich schreibe jetzt sowiesoerstmal alles neu und keiner kann was testen.Dass man damit eigentlich auch unmittelbar den Anforderungen des Auftraggebers,Kunden, wie man es auch immer nennen möchte, entgegenkommt.

Pavel Mayer 0:59:40

B2 Ja und man minimiert das Risiko natürlich extrem, weil man auch,wenn man sieht, das läuft in die falsche Richtung,dann kann man halt frühzeitig gegensteuern und nicht erst, wenn das ganze Geldausgegeben ist, sondern man hat halt dann sehr frühzeitig.Und man weiß auch darüber, also wir haben gerade jetzt in den fünf Jahren noch das ganze Thema.Vorhersage noch ganz gut optimiert. Das heißt, wie lange brauchen wir für bestimmte Aufgaben?Da haben wir noch ein paar eigene Verfeinerungen eingeführt,nämlich dass wir Engineering Tasks nach Innovationsgrad und nach Komplexität nochmal versuchen,einzuordnen.Und wir haben halt Metriken, wo wir wissen, wie sehr wir uns verschätzen beieinzelnen Aufgaben, abhängig davon eben, wie innovativ und wie komplex die Dinge sind.Und diese Faktoren berechnen wir vorher bei der Planung schon mit ein und sindmittlerweile tatsächlich so gut, dass wir in den letzten anderthalb Jahren,ist mir kein Fall bekannt, wo wir wesentlich über der veranschlagten Zeit gelegenhätten und wo wir tatsächlich die erwarteten Features in der erwarteten Zeitdann auch geschafft haben.Und es gibt natürlich auch gerade bei den Projektleitern ein Vertrauen, was wichtig ist.Sie brauchen auch nicht irgendwie künstliche Sicherheiten einzurechnen, weil das.Ja, das passt. Und bei größeren Dingen hat man eben auch mehr Vorwarnzeit.Also wir haben teilweise bei größeren Projekten so die Vorwarnzeit auf,ich sag mal, zwei Monate etwa so herausgesetzt.Das heißt, wir konnten relativ genau, also zwei Monate vorher schon sagen,dass wir voraussichtlich nicht fertig werden mit dem erwarteten Umfang.Das erfordert auch wieder Mut zur Wahrheit und die Leute wollen einem das oftgar nicht glauben, dass man halt schon zwei Monate vorher weiß, dass man genau,wir können dann genau sagen, okay, wir brauchen sechs Tage länger,zwei Monate im Voraus, um fertig zu werden.

Tim Pritlove 1:02:17

Ja, weil die gängige Annahme ja die ist, dass man dann einfach am Wochenendemal ein bisschen durcharbeitet, dann holt man das schon wieder raus.Aber das macht ihr dann ganz bewusst nicht.

Pavel Mayer 1:02:25

Überstunden sind verboten bei Extreme Programming. Das ist halt auch noch ein wichtiges Merkmal,weil Überstunden sich letztendlich nicht auszahlen,weil wenn die Leute mehr arbeiten, also es ist halt nicht nachhaltig, so eine Crunch Time.Das heißt, wenn die Leute zu viel arbeiten, sinkt faktisch die Produktivität.Das heißt, man versucht, jeden einzelnen Entwickler so an seinem Sweet Spot,also die Produktivität am Sweet Spot zu halten, weil wenn man darüber hinausgeht,mag sein, dass man dann vielleicht tatsächlich die Woche früher fertig wird.Gelegentlich passiert das auch,aber da gibt es die Regel, wenn es denn absolut nicht zu vermeiden ist.Dass man dann zeitnah wiederum für Ausgleich und Erholung sorgt.Das heißt, wenn jemand tatsächlich mal Überstunden einschieben musste,dass er dann gezwungen wird,zwei Tage frei zu nehmen, wenn er das Wochenende übergearbeitet hat,um einfach die Leute maximal produktiv zu halten.Und das ist eben auch eine Sache, die einfach ökonomisch ist,Weil man lügt sich dann auch in die Tasche, wenn man meint.Leute holen sich ihren Urlaub so oder so, selbst wenn sie vom,vom Rechner sitzen, dann starren sie halt zwei Stunden in den Bildschirm,ohne etwas zu tun oder klicken im Web rum oder tun einfach andere Dinge.Und dann ist es einfach am besten, wenn jeder ja acht Stunden am Tag konzentriertan einer Sache auch arbeitet, als jetzt zwölf Stunden dort zu sitzen,aber acht Stunden davon eigentlich nur schlapp in den Seilen zu hängen.

Tim Pritlove 1:04:26

Ist ein ehrlicher Deal, da fällt mir noch was ein, vielleicht macht ihr dasja auch, aber da würde mich auch mal deine Meinung dazu interessieren.

Pavel Mayer 1:04:33

Es wird ja so kolportiert, dass bei Google ist die Anweisung,gibt es die Poemierer, ich weiß nicht, ob es nur die Poemierer betrifft,im Wesentlichen wahrscheinlich, dass die einen Tag in der Woche freikriegen,um an ihren eigenen Projekten zu arbeiten.Habt ihr so was ähnliches? Nein.

Tim Pritlove 1:04:51

Also ich bin mir jetzt ehrlich gesagt bei dem Tag in der Woche nicht ganz sosicher, aber es gibt ein gewisses Zeitkontingent, was sozusagen freigestelltwird, die Programmierer explizit ermutigt werden auch eigene Sachen auszuprobieren.

Pavel Mayer 1:05:03

Ja, ich meine das ist sicherlich auch eine gute Sache, wenn man sich's äh...Leisten kann bei uns. Konkret läuft es so, dass wir auch eine ganze Reihe vonForschungsprojekten haben, aber das wird dann einfach eingestreut.Das sind dann auch Engineering-Tasks, die ja, dann äh. A.

Tim Pritlove 1:05:23

Achso, wo man sich quasi dann auch gemeinsam drauf einigt, dass man in den Sachenschon immer mal rumforschen wollte.Und das können dann aber auch Einzelne vorbringen, dass sie das sozusagen malfür ein interessantes Ding halten.

Pavel Mayer 1:05:32

Ja, bestimmte Features oder Projekte, die sich die Gruppe dann einfach selbergeben kann, wo es dann in dem Sinne keinen Kunden gibt, sondern wo die Gruppeals solche der Kunde ist, weil man gerne ein bestimmtes Feature hätte.Was wir allerdings machen, ist der sogenannte Infrastructure Friday,wobei tatsächlich nur das ein halber Tag ist, wo wir uns gemeinsam um unsereTools und Werkzeuge kümmern.Weil wir haben festgestellt, oft wenn die Zeit knapp ist, dann denkt man,okay, also dieses Problem mit dem Bildsystem oder irgendwie jenes Dokumentationstool,wenn ich ein bisschen Zeit habe, dann fixe ich das.Aber tatsächlich kann man nicht vorhersagen, wann wirklich die Zeit da ist.Das heißt, wir sehen zu, dass wir regelmäßig einen halben Tag pro Woche wirklichdarauf verwenden, unsere eigene Entwicklungsumgebung, Bildserver und so weiter zu verbessern.

Tim Pritlove 1:06:32

Alle dann gleichzeitig quasi?

Pavel Mayer 1:06:34

Ja, wir haben da eigentlich den Freitagnachmittag so bei uns dafür reserviert.Das heißt, Zum Wochenausklang.Zum Wochenausklang, genau.

Tim Pritlove 1:06:47

Dann weiß man auch gleich, wenn man Montag wieder reinkommt,ist alles ein bisschen besser als vorher.Interessante Motivationsschritt. Zumal der Freitagnachmittag ja sowieso immerso die Tendenz hat, etwas auszufranzen.Dann leidet zumindest nicht die eigentliche Softwareentwicklung.Ah ja, okay. Interessanter Ansatz.Haben wir denn jetzt die ganzen Kernpunkte von XP, sagen wir jetzt mal so,wie es im Buch steht, bereits abgearbeitet?Ich glaube die wichtigsten Dinge haben wir jetzt.Gibt es denn einen einzelnen Punkt von diesen Guidelines, wie ich das mal nennenmöchte, diesen Richtlinien, die Extreme Programming da aufruft,die dir besonders imponiert haben?Oder vielleicht sogar, je nachdem, vielleicht auch etwas, was sehr viel mehrEffizienz gebracht hat, als du es ursprünglich erwartet hättest.Wenn das jetzt so jemand hört, denkt er sich so, ah, naja, einsam auf dem Rechner sitzen und so.

Pavel Mayer 1:07:42

Ich denke, wenn ich jetzt gezwungen wäre, drei Kernpunkte rauszugreifen,die am wichtigsten sind, dann ist das das iterative Vorgehen,das Pairing auf jeden Fall und das Testen.So diese, ja die automatischen Tests, das sind, würde ich sagen,die unverzichtbar sind.Ja, aber alle anderen Dinge werden auch gebraucht, damit das eben smooth ineinander greift.Und als Wert eben, ja, die Ehrlichkeit. Also das ist auch immer,also Ehrlichkeit mit sich selbst und Ehrlichkeit gegenüber dem Kunden.

Tim Pritlove 1:08:28

B2. Und dem Rest des Teams auch. A1.

Pavel Mayer 1:08:29

Und natürlich ja, also Ehrlichkeit und Vertrauen. B2.

Tim Pritlove 1:08:33

Führt auch zu einer besseren Stimmung wahrscheinlich.

Pavel Mayer 1:08:36

A1. Auf jeden Fall. Also gerade die Stimmung und die Krankheitsrate und also. B2.

Tim Pritlove 1:08:43

Naja, auch die Bereitschaft einzuspringen, wenn jetzt jemand Probleme hat wahrscheinlich.A1. Mhm. Die schönen Utopier in der Vorfeldentwicklung.

Pavel Mayer 1:08:53

Und wenn es denn wirklich mal brennt, dann kann man auch, dann weiß man,also wenn wirklich die Dinge mal schief gegangen sind, wenn wirklich die Realitätmal komplett mit der Planung auseinandergelaufen ist,was halt manchmal einfach passiert durch, also am häufigsten durch äußere Einflüsse,dass sich eben die Bedingungen,die äußeren Bedingungen ändern oder man manchmal von vornherein weiß,eigentlich geht es nicht.Aber dann weiß man, dass man ein absolut fittes Team hat,was dann auch in der Lage ist,richtig zuzupacken und auch den Karren aus dem Dreck zu ziehen und nicht einehalb geschlagene Armee,die irgendwie schon halb Halb verhungert schlaflos mit Rändern sowieso und nurnoch resigniert irgendwie,ankämpft ja.

Tim Pritlove 1:09:53

Was mich noch interessieren würde gibt es technische Werkzeuge die ihr jetztzum Einsatz bringt die jetzt über die normalen Entwicklungswerkzeuge hinaus geben?

Pavel Mayer 1:10:03

Die jetzt zu irgendeinem dieser punkte im extrem bei programmingbeitragen also kommunikation zum austausch zu der meditation also definitivalso unser bild system also der automatisierungsgrad in unserem bild und dokumentationssystemglaube ich ist ziemlich fortgeschritten und zwar hatte ich ja schon erwähnt,was man sowieso hat, zentrales Repository,der Bild und die automatischen Tests.Was sich bei uns aber noch anschließt an die Module-Tests, sind halt generelle Regressions-Tests,wo halt, also wir haben halt eine 3D-Multimedia-Software,Bilder, die halt dann bestimmte Szenen rendern soll und dort haben wir beispielsweise etwa 100 Ergebnisse,also Testbilder, die dann rausgeschrieben werden und die dann verglichen werdenam Ende des Prozesses und...

Tim Pritlove 1:11:07

Also kannst du nochmal kurz erläutern, was ein Regressionstest ist?

Pavel Mayer 1:11:12

Das ist mehr ein Test, wo man das Ergebnis, was bei dem Test rauskommt,mit einem vorgegebenen, mit einem Soll-Ergebnis dann einfach vergleicht.

Tim Pritlove 1:11:24

Inwiefern ist das jetzt ein, also ich meine, macht das nicht jeder Test,ich meine, testet ob das und das stattfindet?

Pavel Mayer 1:11:32

Ja, allerdings sind, also diese sind dann nicht mehr auf Modulebene,also keine Modultests mehr, sondern tatsächlich auf Anwendungsebene,wo… Geht's beim Registrierungs-Test nicht auch ein bisschen um die Wiederholung,dass man das irgendwie in verschiedenen Varianten testet?Ja gut, natürlich versucht man mit den Tests möglichst viel,ich sag mal, Codepfad abzudecken.Also die Test-Coverage, dass halt jede Codezeile, die durchlaufen werden kann,auch irgendwo dann am Ende ein Ergebnis hat.Aber vielleicht lasse ich noch mal beim Bildsystem sozusagen die Specials,die vermutlich kaum jemand oder von wo ich zumindest nicht gehört habe davon,dass außer uns jemand so weit gegangen ist.Das eine ist, wir machen auch Performance-Tests, das heißt, es wird nicht nur.Es wird nicht nur das Ergebnis getestet, sondern wir machen während des Testensauch Laufzeit-Statistiken, die in den Bild mit eingehen.Das heißt, wenn jemand etwas einbaut, was das System an sich verlangsamt,dann wird das sofort sichtbar.Oder man sieht auch Optimierungserfolge, wenn man etwas schneller macht,dann wird man auch dadurch belohnt, dass man plötzlich sieht, hey,wow, ich habe jetzt diese oderjene Funktion um zehn prozent beschleunigt undgerade heutzutage leidet ja oft auch softwaredarunter dass sie einfachimmens ressourcen verbraucht dann wirdhört ja dann so dinger wie leakage tests wo wir halt automatisch überprüfenob memory leaks da sind aber was auch richtig also ob sich die programme quasiein bisschen zu sehr am Speicherpool bedienen und nicht wieder freigeben unddadurch immer wachsen und wachsen und mehr Ressourcen pressen.Und Dokumentation ist auch noch so ein wichtiger Punkt. Und zwar eigentlichvermeidet man es bei XP zu viel Dokumentation zu schreiben, weil bei Dokumentation,die von Hand geschrieben ist, das Problem, dass sie sehr schnell veraltet,falsch und nicht akkurat ist.Das heißt, was wir auch drin haben, sind verschiedene Systeme,die die Dokumentation automatisch erzeugen,durch entsprechend sich Informationen aus dem Quellcode holen und zusätzlichInformationen, die man reinschreibt, extrahieren.Plus wir haben nun ein Tutorial für unser System und der Tutorialcode selberwird auch durchgetestet Und das Ergebnis wird als Screenshot gleich in eineentsprechende Website eingebaut.Das heißt, man kann sicher sein beim Tutorial, was man hat, dass der Code,der im Tutorial steht, auch getestet ist und das Ergebnis, was dann auf demSchirm zu sehen sein soll,eben auch in der Dokumentation immer aktuell übereinstimmt mit dem Ergebnis,was man dort auch sehen soll.Es wird eine automatische Cross-Referenz angelegt.Wir haben auch selbst dokumentierende Dateiformate beispielsweise auf XML-Basis, die über XML-Schema.Funktionieren und man dort jederzeit auch, also,das endet alles, also die gesamte Dokumentation landet halt in verschiedenenWebsites und man hat damit dann am Ende nach einem erfolgreichen Bild auch eineaktuelle und stimmige Dokumentation und Tutorials vom Programm,von den Datenformaten, von allem.

Tim Pritlove 1:15:24

Also kurz gesagt, es lohnt sich und es passt auch zum Extreme Programming, dass man möglichst viel,automatisiert, was das Testen betrifft, aber auch unter Umständen,was das Dokumentieren betrifft.Teilweise muss man das ja auch nicht alles selber programmieren.Also es gibt in sehr viel Programmiersprachenumgebungen mittlerweile Möglichkeitenaus Programmcode direkt Dokumentation zu erstellen. Also entweder direkt aus dem Code selber.Das hängt natürlich dann sehr von den Fähigkeiten, die ich bei mir sprach,aber oder doch zumindest, dass man eben bestimmte Schreibweisen für Kommentare,die man in den Source Code einführt,dass man eben bestimmte, ja, Arten und Weisen, wie man etwas dokumentiert,direkt in die Kommentare, Konventionen genau reinschreibt,um daraus eben auch automatisch Software-Dokumentation zu machen,die natürlich dann den großen Vorteil hat, dass man sie a, nicht nochmal schreiben,und prüfen muss und b, dass sie eben auch genau das reflektiert,wie eben der Ist-Zustand ist, also unter Umständen auch mit allen Fehlern, die man drin hat.Mann, Mann, Mann. Das war jetzt auf jeden Fall schon mal hier eine der längstenAusgaben des Chaos Radio Express,aber ich bin eigentlich ganz froh, dass wir da hier auch mal in die Tiefe gegangensind, weil ich denke Extreme Programming ist etwas, was eine ganze Menge Leutedoch eine Menge Last von den Schultern nehmen kann.Haben wir denn jetzt noch...

Pavel Mayer 1:16:44

Negativpunkte?

Tim Pritlove 1:16:45

Das wäre ein Punkt. Ja, das können wir eigentlich vielleicht mal voranschieben,weil danach nochmal drauf eingehen, wie man, wie man sozusagen sich diesem Themadann auch nochmal nähert, wenn man Interesse hat, das in irgendeiner Form umzusetzen.Hast du denn noch negative Erfahrungen gemacht? Gibt es Probleme?

Pavel Mayer 1:17:00

Ja, eins hatte ich schon erwähnt, nämlich, dass es diesen idealen Kunden,wie man ihn gerne für XP hätte, dass der selten anzutreffen ist,dass man dort halt Dinge finden muss.Ansonsten gibt es manchmal auch Anforderungen.Die an einen herangetragen werden, wo man gezwungen ist,bestimmte schwergewichtige Softwareentwicklungsprozesse zu fahren oder mit anderenAbteilungen zusammenzuarbeiten, die andere Prozesse haben, die halt extrem viel, also hunderte von,also Pflichtenheft ist zum Beispiel so eine Sache, normalerweise vermeidet manes oder versucht halt nicht zu viel Arbeit vorab in den Pflichtenheft zu stecken,aber manchmal ist es einfach eine Anforderung.Und da ist es uns aber ganz gut gelungen, das zu emulieren bzw.Diese Artefakte oder diese Dokumente, dieses Pflichtenheft genauso zu behandelnwie eine Programmieraufgabe und aber auch dem Kunden klarzumachen,dass das Schreiben des Pflichtenheftes in Konkurrenz steht,jetzt ressourcenmäßig mit dem Entwickeln von Features.Das heißt, je mehr Pflichtenheft er wünscht, umso weniger Zeit bleibt halt natürlich für die Umsetzung.Aber wenn er das wünscht, wenn das erforderlich ist, werden halt diese Artefakteeben abgebildet und das funktioniert auch ganz gut quasi mithilfe von XP andereVerfahren zu emulieren oder sich an andere Verfahren.

Tim Pritlove 1:18:39

A1 Was meinst du jetzt mit Artefakte? Was ist das für Schwierigkeit? BK'IN DR.

Pavel Mayer 1:18:42

MERKEL. Also Dokumente beispielsweise, also Stücke von Dokumentationen bezeichnet,man einfach dort als Artefakte, einfach die Ergebnisse,die halt zurückbleiben im Laufe der Entwicklung.Also Ergebnisse, so Überbleibsel, kann man sagen, der Entwicklungstätigkeit.Es ist auch nicht unbedingt jedermanns Sache.Also es gibt in seltenen Fällen einfach Leute, die nicht damit klarkommen,also mit dieser Ehrlichkeit und Offenheit, die sich einfach nicht die Schwierigkeitendamit haben, sich zu offenbaren oder mit anderen Leuten vorm Rechner zu sitzen.Was nicht gleichbedeutend ist, dass es sich dabei um schlechte oder unfähigeProgrammierer handelt.Aber eigentlich ist es eher selten, dieses Phänomen und mit der richtigen Herangehensweise,wenn man halt zeigt, dass eben auch Vertrauensschutz besteht,öffnen sich dann die meisten auch.Aber es gibt eben einige, wo es nicht klappt. Und dann eignet sich XP nichtunbedingt für jede Art von Entwicklungsaufgabe und nicht für jede Art von Teamgröße.Also ein 1000-Mann-Projekt jetzt,mit XP zu fahren, das wüsste ich nicht. Also irgendwie Toll Collect beispielsweise jetzt,nach XP-Prinzipien,zufahren.Also so ein System könnte einfach,schwierig,werden,oder da gibt es zumindest noch nicht die Werkzeuge oder Verfahren.

Tim Pritlove 1:20:17

A. Wobei man so ein großes Projekt ja auch aufbrechen kann oder eigentlich auch zwangsläufig.Ich habe keine Ahnung, wie die nun ihre Softwareentwicklung da konkret organisiert haben.Aber im Prinzip haben sie ja genug Teilaufgaben, um das eben auch in einzelneGruppen zu unterteilen, in denen sie ja dann immer noch entscheiden könnten,nach XP-Maßgaben vorzugehen.

Pavel Mayer 1:20:35

Ja allerdings ist dort so wie ich das mitbekommen habebei toll kollekt das ganze extrem formalisiert gewesendas heißt auch einzelne teams waren komplettabgeschottet und dort wurde beispielsweise jede veränderung in form von changerequests dann erst mal erfasst dann dokumentiert also ein ziemlich großer verwaltungsAlso dafür taugt es auf jeden Fall nicht unmittelbar zu kämpfen.A. Und dafür, naja, also vielleicht jetzt wenn, also wird man auch Methodenund Verfahren entwickeln können im Laufe der Zeit, wo man das auch auf größereProjekte skalieren kann.Auf der anderen Seite, man weiß seit längerer Zeit, es gibt sowas wie eine magischeGrenze der Planbarkeit in der Softwareentwicklung.Und da gibt es dieses sogenannte 6x6, also sechs Leute für sechs Monate. Das ist so.Etwa markiert so die tatsächlich die Grenze des Planungs Horizont was so,wo man wirklich zuverlässig planen kann.Alles was halt irgendwie mehr als sechs Leute für mehr als sechs Monate umfasst,ist tatsächlich nicht wirklich planbar so im Voraus, beziehungsweise da hat man halt,da wachsen dann letztendlich die Unsicherheiten.Man kann dann zwar glauben und hoffen, dass es hinkommt, aber ja die Unsicherheiten nehmen zu.Das weiß man aber schon seit 20, 30 Jahren hat IBM das schon festgestellt,dass eben dieser ja 6x6 so inetwa tatsächlich die Grenze der Planbarkeit dasteht. das moderne Sixpack.

Tim Pritlove 1:22:30

Gut, um vielleicht mal so langsam langsam zu einemEnde zu kommen, ich wage das ja gar nicht abzukürzen, weil das eigentlich allesviel zu interessant ist, aber wenn ich mich jetzt ganz konkret als Empfehlunghier an unsere Hörer, wenn man jetzt mal sich konkret dem Thema nähern möchte,was ist der beste Weg? Als erstes kauft man sich ein schlaues Buch.

Pavel Mayer 1:22:50

Ja, also wie gesagt diese von 99, die drei Bücher von Kent Beck sind so dieStandardwerke, die man auf jeden Fall lesen kann,dann findet man natürlich im… Also Extreme Programming,wie heißt das eine, das Manifest?Ja, dann Extreme Programming Explained heißt das eine, glaube ich.

Tim Pritlove 1:23:19

Gibt es das auch in Deutsch? Ja, ne?

Pavel Mayer 1:23:20

Weiß ich gar nicht.

Tim Pritlove 1:23:22

Ja, gibt es. Also, oder? Moment. Moment. Ja, es gibt deutsche Übersetzungen. A2.

Pavel Mayer 1:23:29

Das kann gut sein. Ja, das ist sicherlich ein Einstieg.Dann so in Deutschland hat sich halt so Frank Westphal, ist so der deutsche XP-Guru,der sich dort am meisten XP verschrieben auf www.frankwestphal.de,findet.Man halt auch jede Menge, ja auch Links Westphal mit ph.Einfach zusammen geschrieben oder einfach nach extrem Programming googeln,wobei das der Klassiker ist, glaube ich, das C2 Wiki,wo es auch sehr viele Links gibt.Es gibt außerdem Mailinglisten, wo sehr viel Traffic ist, eigentlich mehr alsman so konsumieren kann,aber wo sich auch extrem viele erfahrene Leute austauschen und wo man auch viel rausziehen kann.Aber letztendlich nur sagen anfangen Schwierigkeiten, die dabei auftreten,sind einmal natürlich, dass das Management davon zu überzeugen,dass jetzt zwei Leute immer vor dem Rechner sitzen, natürlich erst mal,wenn da zwei Leute ist es doppelt so teuer genau wo doch jeder irgendwie fürsich arbeiten kann und sie doch dann das doppelte schaffen.

Tim Pritlove 1:25:01

Wenn der eine Holz hackt warum muss der andere noch zugucken.

Pavel Mayer 1:25:04

Ja eben.

Tim Pritlove 1:25:05

Ja aber an der Stelle wird natürlich schön deutlich und meine das das kenneich auch aus eigener Erfahrung Softwareentwicklung ist wirklich ein ganz andererBeruf der sich so mit herkömmlichen Beschäftigungen kaum vergleichen lässt,Weil man einfach auf eine bestimmte Art und Weise dort involviert sein mussund auch so eine Macht in Anführungsstrichen verfügt über das, was man da tut.Man streicht ja nicht nur eine Wand, ja, nach einer bestimmten Vorgabe und dann ist sie halt grün,sondern man trifft Entscheidungen, die letzten Endes für eine Vielzahl von Leuten,das kann sich exponentiell ausdehnen,in irgendeiner Form auch maßgeblich sind bis hin zur gesamten Softwareentwicklungin einer Firma in der nächsten Zeit und da lastet natürlich eine Menge drauf.In gewisser Hinsicht würde ich sagen, das sind zwei Leute eher ja noch wenig.

Pavel Mayer 1:25:57

B2 Ja, das andere Ding ist, dass man auch bereit sein muss,seine Einstellung zu ändern und seine Werte auch zu ändern, zum Beispiel dasganze Überstunden-Thema.Da galt es ja also speziell auch in der New Economy oder es gibt halt jede MengeWar Stories, wo die leute dann 90 stunden pro woche dann heldenhaft ja es geschafft haben.

Tim Pritlove 1:26:31

B2. Real Programmers schlafen unter einem Tisch. A3.

Pavel Mayer 1:26:34

Ja so da muss man halt eher sehen, dass man da auch eine kulturelle Veränderunghinkriegt und sagt also über stunden also wenn es nötig wird über stunden zu fahren,dass das einfach ein Ergebnis schlechter und falscher Planung ist.Und jetzt kein Heldentum in dem Sinne. Das ist kein Wert an...

Tim Pritlove 1:27:02

Aber was macht ihr denn, wenn ein Programmierer Bock drauf hat?Länger an irgendwas zu arbeiten. Wird der dann aus der Firma gefegt?Es gibt auch so Momente, da kann man einfach gar nicht aufhören zu programmieren,weil man weiß, wenn ich das jetzt nicht irgendwie in den nächsten drei Stundenfertig buddiere, dann kann ich meinen Tag auch vergessen, dann denke ich sowieso nur noch dran.

Pavel Mayer 1:27:17

Das ist auch völlig in Ordnung. Jeder ist unterschiedlich belastbar oder derSweet-Spot liegt bei jedem auch irgendwo anders. Das ist eine Sache auch des Alters.In einem bestimmten Alter hat man auch das Gefühl, mit neun oder zehn Stundenam Tag sich ganz wohl zu fühlen.Dann ist das halt das Ding. Aber wichtig ist, dass Überstunden eben nicht erwartet werden.So und dass sie nicht honoriert werden insbesondere alsowenn jemand freiwillig gerne dort dortsitzt aber wichtig ist es eben keine incentives dafür zuschaffen das heißt überstunden normalerweise nichtzu vergüten sondern wenn also bei uns wenn es wirklich brennt dann werden haltnur in solchen fällen eben überstunden freigegeben und erfasst und dann ebenvergütet aber im normalfall,sag ich mal, kann jeder zwar so lange bleiben und so lange arbeiten,wie er will, das ist dann aber sein Privatvergleich.

Tim Pritlove 1:28:23

A. Ok, aber so eine Abgabephase jetzt in zwei Tagen ist die Präsentation,lalala, aber wir haben insgesamt auch alle gemeinsam eingesehen,wir haben da noch ein Problem, dann ist es der Ausdruck.

Pavel Mayer 1:28:33

Dann läuft es eben so, dass ich in dem Fall sage, okay,es ist jetzt knapp, jeder kann jetzt so viel tun, wie er halt dazu in der Lageist und mir das dann entsprechend melden und dann greift halt diese Urlaubsgeschichte.Aber eben, ja, das ist eine Bewusstseinsveränderung, die auch dort einkehren muss.

Tim Pritlove 1:29:02

Ja.Bewusstseinsveränderung in Form von Extreme Programming vielleicht ja auch füreuch ein Thema oder vielleicht auch etwas, was ihr in euren Unternehmen mal ansprechen möchtet.Ich habe schon mit so viel, gerade jetzt dieses Wochenende wieder mit frustriertenProgrammierern gesprochen,die einfach so unglücklich sind in ihren Firmen, weil irgendwie die Leute verstehennichts von Softwareentwicklung, es gibt keine richtige Kommunikation,man redet auch nicht wirklich über die Probleme, also jetzt auch mal ganz vondieser eigentlichen Methodik, die einem zum besseren Programmierer werden lassenkann und die ganzen Sachen finde ich also gerade diese Offenheit und Ehrlichkeit, gerade in so etwas,wo man so mental engagiert ist, wie beim Programmieren, was ja nicht eine reineEngineering Tätigkeit ist.Man lötet nicht. Es ist wirklich, ja und auch sehr philosophisch an vielen Stellen.Und da ist es einfach wichtig, dass das Klima stimmt.Und ja, vielleicht ist Extreme Programming für euch ein Weg, das zu machen.Es gibt ja auch noch viele andere Methodiken, die vielleicht auch nicht so viele Probleme haben.

Pavel Mayer 1:30:06

Andere Archeemethoden.

Tim Pritlove 1:30:07

Das muss man alles auch nochmal ein bisschen hinterfragen. Vielleicht auch bei Chaos Radio Express.Ich bin ja immer auf der Suche nach interessanten Themen und jetzt hatten wirmal wieder ein interessantes Thema.Ich bedanke mich bei dir, Pavel, für die sehr ausführliche Darstellung dieses Themenkomplexes.Ist ja nicht das erste Mal, dass du hier bei Chaos Radio Express dabei bist.Ich hoffe auch nicht das letzte Mal.Und ja, für die mit Abstand längste Chaos Express Sendung entschuldige ich michschon mal, aber ich denke der Inhalt war es wert.Wenn ihr Rückmeldungen habt...Feedback, Kommentare, Kritiken, alles mögliche, was euch auch einfällt.Ihr wisst es, Chaosradio.de.Ich würde jetzt auch ganz gerne nochmal die Telefonnummer fallen lassen,aber jetzt habe ich sie mir gerade nicht auf den Bildschirm geschrieben,könnt ihr auf der Webseite nachschlagen.Ich freue mich auch immer über Audio-Kommentare, muss aber natürlich nicht sein,wie es euch auch immer am besten passt.Könnt ihr hier einen interaktiven Podcast mit uns gestalten.Haben wir noch ein Schlusswort, was weißes zum Tage, zur Nacht muss man ja sagen, schon fast eins.

Pavel Mayer 1:31:13

B2 Für vielleicht noch das Thema Qualität. Es gibt halt in XP nur zwei Artenvon Qualität, die man abliefert.Perfekt und krankhaft perfekt.

Tim Pritlove 1:31:34

Oha, okay, was ist besser?

Pavel Mayer 1:31:37

Das kommt darauf an, was das System dann am Ende leisten soll.Also wenn es eins ist, an dem vielleicht irgendwie Leben oder große Vermögenswertehängen, dann sollte man vielleicht auf die Krankheit-perfekt-Variante,gehen.Aber ja, Qualität ist einfach das, was allen auch ein gutes Gefühl gibt,so stolz auf seine Arbeit sein zu können, so den Kunden glücklich zu machen,so, dann macht die Arbeit einfach auch Spaß.

Tim Pritlove 1:32:08

Okay, das war ein schönes Schlusswort. Ich hoffe, dass wir uns mit einem krankhaft-perfekten,Ergebnis hier an euch herangeschmiedet haben und ihr einen Podcast bekommen,ob ihr ihn haben wolltet. Ich sag dann mal Tschüss.

Pavel Mayer 1:32:22

Tschüss.

Tim Pritlove 1:32:22

Und wir hören uns bald wieder bei einem neuen Chaos Radio Express auf diesem RSS-Feed. Bis bald.

Shownotes

Weiterlesen →

Aktive Podcasts

Pausierte Podcasts

Archivierte Podcasts

Der Interview-Podcast mit Tim Pritlove

CRE028 Extreme Programming