Tim Pritlove: Hallo, hier ist Chaos Radio Express, Ausgabe Nummer 28 in schneller Folge in
Tim Pritlove: den letzten Tagen, ausgelöst durch meine Präsenz am Linux-Tag.
Tim Pritlove: Da haben sich viele interessante Themen ergeben, aber die Liste ist noch lang
Tim Pritlove: und heute wartet schon das nächste Thema auf uns und es lautet Extreme Programming,
Tim Pritlove: eine Methode Software zu schreiben und dazu habe ich den Pavel wieder bei mir,
Tim Pritlove: der uns ein bisschen Einblick in diese Technologie geben wird.
Tim Pritlove: Und mein Name ist, wie gehabt, Tim Brickler.
Tim Pritlove: Ja, hier sind wir wieder.
Tim Pritlove: Ich begrüße Pawel. Pawel.
Pavel Mayer: Hallo Tim.
Tim Pritlove: Hallo Pawel. Ja, Extreme Programming soll das Thema sein heute, dieser Sendung.
Tim Pritlove: Ein Begriff, der schon eine Weile.
Pavel Mayer: Seit 99 eigentlich hat das so begonnen, breite Wellen zu schlagen.
Pavel Mayer: Da hat Kent Beck seine drei Bücher veröffentlicht, Extreme Programming und Extreme
Pavel Mayer: Programming Explained. A.
Tim Pritlove: Das waren also die Standardwerke zu dem Thema?
Pavel Mayer: B. Ja, aber vielleicht fangen wir mal vorne an.
Pavel Mayer: Also Extreme Programming klingt, wenn man das Wort hört, erstmal so,
Pavel Mayer: als würden irgendwelche Nerds 48 Stunden lang vorm Rechner sitzen und so lange
Pavel Mayer: programmieren, bis sie umfallen.
Pavel Mayer: Das Interessante ist aber, das ist eine sehr geschickte Wahl dieses Begriffs,
Pavel Mayer: weil tatsächlich ist Extreme Programming genau das Gegenteil davon.
Pavel Mayer: So Extreme Programming ist so der Einzug von Wahrheit und Vernunft in die Softwareentwicklung.
Tim Pritlove: Du meinst vorher war das alles unvernünftig und alle haben sich einen in die
Tim Pritlove: Tasche gelogen. Ja, definitiv.
Pavel Mayer: Ich meine, das ist überhaupt eines der größten Probleme bei der Softwareentwicklung,
Pavel Mayer: so die fehlende Ehrlichkeit, so die Ehrlichkeit zu sich selbst,
Pavel Mayer: die Ehrlichkeit gegenüber dem Kunden und die Ehrlichkeit gegenüber dem eigenen Management.
Pavel Mayer: Und da versucht Xtreme Programming einfach ein paar Pfeiler einzuschlagen, die dafür sorgen,
Pavel Mayer: dass es eben mit Vernunft zugeht und dass es nachhaltig zugeht.
Pavel Mayer: Extrem ist an extrem programming ist,
Pavel Mayer: dass man die guten Dinge oder die Dinge, die man als gut und richtig erkannt
Pavel Mayer: hat, mit aller Konsequenz versucht durchzusetzen.
Tim Pritlove: Also eine Diszipliniertheit im Prinzip. Also man muss dazu sagen,
Tim Pritlove: Extreme Programming bezeichnet also eine Vorgehensweise, eine Art und Weise,
Tim Pritlove: wie man an Softwareentwicklung als solche herangeht.
Tim Pritlove: Es ist jetzt nicht eine spezielle Technik, es hat nichts mit Programmiersprachen
Tim Pritlove: im eigentlichen Sinne zu tun,
Tim Pritlove: sondern es lässt sich im Prinzip auf jeden Entwicklungsprozess anwenden.
Tim Pritlove: Egal, ob man jetzt in Perl oder C oder was auch immer entwickelt, eine Methodik.
Pavel Mayer: Ja es ist gut du hast jetzt das m-wort gesagt was halt das ist zumindest verpönt,
Pavel Mayer: in der extreme programming,
Pavel Mayer: äh äh szene von methodik oder methodologie äh zu sprechen aber tatsächlich ist es äh so etwas wobei,
Pavel Mayer: da es halt viel äh auch disziplin und energie erfordert braucht man auch etwas ja Rückhalt.
Pavel Mayer: Als ich das kennengelernt habe, so 2000 habe ich damit begonnen, das Ganze.
Tim Pritlove: A1. Warum? Also ich meine, wie bist du da überhaupt drauf gestoßen? Was war die Motivation?
Pavel Mayer: B2. Unzufriedenheit. Einfach Unzufriedenheit mit der Art und Weise,
Pavel Mayer: wie Softwareentwicklung, wie ich sie bis dahin betrieben habe und wie meine
Pavel Mayer: Teams sie betrieben haben.
Pavel Mayer: Bis zu Extreme Programming war mir gar nicht klar, was eigentlich alles verkehrt daran war.
Pavel Mayer: Ich dachte, das müsste einfach so sein, dass man oft nicht rechtzeitig fertig
Pavel Mayer: wird, dass die Leute alle bis an den Rand der Erschöpfung arbeiten,
Pavel Mayer: dass man versucht, irgendwie den Kunden permanent zu beschwichtigen,
Pavel Mayer: weil die Dinge nicht so laufen,
Pavel Mayer: wie sie sollen.
Pavel Mayer: Ja, ich meine, es gibt einen Haufen von Problemen einfach in der Softwareentwicklung,
Pavel Mayer: die jeder kennt. Es fängt damit an.
Pavel Mayer: Also Software wird nicht termingerecht fertig oder die Entwicklung wird sogar
Pavel Mayer: beendet, bevor die Software einsetzbar ist oder wenn man soweit kommt,
Pavel Mayer: stellt man irgendwann fest, der Wartungs- und Änderungsaufwand,
Pavel Mayer: wird sehr schnell zu hoch, um die Software den ständig wechselnden Anforderungen anzupassen.
Pavel Mayer: Oder ja, die Software wird wegen Unzuverlässigkeit und Problemen irgendwann
Pavel Mayer: kaum genutzt von den Leuten, die sie ursprünglich bestellt haben.
Pavel Mayer: Oder sie löst das Problem nicht so, wie es mal versprochen oder angedacht war.
Pavel Mayer: Oder in der Zwischenzeit, bevor die Software fertig geworden ist,
Pavel Mayer: hat sich das Problem eigentlich verändert mittlerweile.
Pavel Mayer: Oder ja, man hat die falschen Features eingebaut, viele nette Features,
Pavel Mayer: aber der Nutzen der Features, die man eingebaut hat, ist nicht so,
Pavel Mayer: wie man sich das vorgestellt hat.
Pavel Mayer: Und irgendwann fangen die Leute einfach, auch vor allem die guten Leute an,
Pavel Mayer: das Projekt und die Software zu hassen und versuchen, sich halt anderswohin abzusetzen.
Pavel Mayer: Das ist so das Ding.
Tim Pritlove: Bis hin zu flüchtenden Programmierern.
Pavel Mayer: Jaja, also man will dann irgendwann nur noch nur noch weg.
Pavel Mayer: Dann ist natürlich das das Problem. Kunde steht auch im Baum,
Pavel Mayer: das heißt typischerweise der Kunde weiß am Anfang nicht, was er will.
Pavel Mayer: Das ist eigentlich auch relativ normal.
Pavel Mayer: Und er weiß eigentlich erst, was er will und was nicht, wenn er es hat.
Pavel Mayer: So das ist auch ein typisches Ding. Man zeigt es sie und dann sagt er ja super
Pavel Mayer: genau so wollte ich das oder nee also das wollte ich eigentlich nicht.
Pavel Mayer: Ich habe zwar gesagt, dass ich das wollte, aber so habe ich mir das nicht vorgestellt.
Pavel Mayer: Dann ist es so, dass der Kunde natürlich er steckt nicht so tief drin im Entwicklungsprozess
Pavel Mayer: und weiß nicht, welche Features jetzt einfach und billig sind und welche schwierig und teuer sind.
Pavel Mayer: So das zu vermitteln, ist auch schwierig. So außerdem will der Kunde natürlich
Pavel Mayer: dummerweise vorher wissen, was es kostet und was er dafür bekommt,
Pavel Mayer: während der Programmierer natürlich sich möglichst nicht festlegen möchte.
Pavel Mayer: Dann gibt es das Problem, dass der Kunde häufig einen festen Termin hat,
Pavel Mayer: an dem alles fertig sein soll. Das beißt sich dann natürlich auch.
Pavel Mayer: Außerdem ändert der Kunde gerne seine Meinung. So, das ist aber auch ganz normal, ähm, so.
Pavel Mayer: Früher habe ich die Kunden das übel genommen, so mittlerweile weiß ich,
Pavel Mayer: dass es einfach dazugehört.
Pavel Mayer: Ich meine, jeder von uns ändert mal seine Meinung, warum sollte dann nicht auch
Pavel Mayer: der Kunde seine Meinung ändern.
Tim Pritlove: Weil man sich ja im Prinzip auch während des Prozesses, in dem man das so begleitet,
Tim Pritlove: ausgelöst eben durch diese Aktivität, die sich dann entspannt,
Tim Pritlove: auch überhaupt erstmal Gedanken macht.
Tim Pritlove: Also überhaupt erst so sehr auch in dem Prozess drin ist, das kenne ich auch,
Tim Pritlove: wann auch immer ich in der Situation war,
Tim Pritlove: auch Features festzulegen oder in gewisser Hinsicht auch Aussagen zu machen
Tim Pritlove: über grundlegende Funktionsmodelle, stellt man dann nach zwei,
Tim Pritlove: drei Monaten fest, wenn man erstmal den Gedankenprozess angeworfen hat,
Tim Pritlove: dass man dann eben so es auf einmal ganz anders sieht.
Pavel Mayer: Ja, und dann ist das das große Problem in der Entwickler-Kunden-Beziehung ist die Angst.
Pavel Mayer: So die Angst, weil Softwareentwicklung ist riskant.
Pavel Mayer: So alle Beteiligten fürchten sich vor den vielen Dingen, die schiefgehen können.
Pavel Mayer: Und tatsächlich ist es so, dass nicht eingestandene Ängste die Ursache der meisten
Pavel Mayer: Fehlschläge in der Softwareentwicklung sind.
Pavel Mayer: Also zum Beispiel, der Kunde hat Angst, dass er nicht bekommt,
Pavel Mayer: was er will, dass er nicht das Richtige verlangt, dass er zu viel zahlt für zu wenig.
Pavel Mayer: Dass er seine Karriere irgendwelchen Techies anvertrauen muss,
Pavel Mayer: die das gar nicht kümmern, also die Karriere, dass er niemals einen klaren Plan erhalten wird.
Pavel Mayer: Oder der Kunde hat Angst zu Recht auf, dass die Pläne, die er zu sehen bekommt,
Pavel Mayer: reinste Märchen sind und dass er nie wissen wird, was wirklich los ist,
Pavel Mayer: weil er keinen richtigen Einblick hat.
Pavel Mayer: Oder er hat Angst, dass man ihn auf die ersten Aussagen festnageln wird und
Pavel Mayer: er später nicht mehr auf veränderte Anforderungen reagieren kann.
Pavel Mayer: Oder dass ihnen also niemand sagt ihnen die Wahrheit.
Pavel Mayer: So das sind so typische Ängste des Kunden und die sind eben tatsächlich nicht unberechtigt.
Pavel Mayer: Auf der anderen Seite steht der Entwickler, der natürlich auch von Ängsten geplagt ist.
Pavel Mayer: Also ganz vorne, dass mehr von ihm verlangt wird, als er schaffen kann.
Pavel Mayer: Dann, dass von ihm verlangt wird, sinnlose Dinge zu tun.
Pavel Mayer: Das ist eine große Angst so im Projekt.
Pavel Mayer: Oder, dass er einfach zu dumm ist, das Problem zu lösen.
Pavel Mayer: Auch diese Selbstzweifel sind häufig da.
Pavel Mayer: Oder er fürchtet sich irgendwie, dass das Wissen veraltet und er zurückfällt.
Pavel Mayer: Auch da ist er getrieben.
Pavel Mayer: Und dann natürlich ein großes Problem, was auch da ist, dass man,
Pavel Mayer: dass der Entwickler Verantwortung.
Pavel Mayer: Übertragen bekommt, aber nicht
Pavel Mayer: die notwendige Autorität, um der Verantwortung auch gerecht zu werden.
Tim Pritlove: SIEGFRIED Du meinst, dass ihm jetzt Vorgaben gemacht werden,
Tim Pritlove: wie er etwas zu lösen hat, aus irgendwelchen Situationen heraus.
Pavel Mayer: BARTHOLZ Genau, er sagt, du bist jetzt verantwortlich, dass das rechtzeitig fertig wird, aber...
Tim Pritlove: SIEGFRIED Und dann sagt er, da will ich aber Programmiersprache X nehmen,
Tim Pritlove: weil meiner Meinung nach ist das genau das, was ich dafür brauche.
Tim Pritlove: Und dann kommt so die Firmenvorgabe, nein, wir nehmen aber jetzt Java, genau, wir nehmen Y.
Pavel Mayer: Und du musst auch mit diesen drei Leuten irgendwie klarkommen dort.
Pavel Mayer: Und dann ein ganz wichtiger Punkt, den jeder hasst, wovor jeder Entwickler Angst
Pavel Mayer: hat, Qualität opfern zu müssen, um Termine zu halten.
Pavel Mayer: Also quasi durch die äußeren Umstände dazu gezwungen zu werden,
Pavel Mayer: seinen eigenen Qualitätsansprüchen nicht gerecht zu werden.
Pavel Mayer: Und ich meine, niemand schafft gerne Dinge von schlechter Qualität und niemand
Pavel Mayer: benutzt gerne Dinge von schlechter Qualität.
Pavel Mayer: Und davor hat man eben auch Angst.
Pavel Mayer: Dann auch noch ein Punkt, schwierige Probleme alleine lösen zu müssen.
Pavel Mayer: Ich meine, manchmal sind die Probleme wirklich sehr, sehr schwierig,
Pavel Mayer: vor denen man löst, sodass da auch einfach eine Angst da ist,
Pavel Mayer: alleine mit einem Problem zu kämpfen und nicht zu wissen, ob man das Problem
Pavel Mayer: jetzt niederringt oder von dem Problem niedergerungen wird.
Pavel Mayer: Und dann eben immer wieder der Zeitdruck, nicht genug Zeit zu haben,
Pavel Mayer: um in dem Projekt erfolgreich zu sein.
Pavel Mayer: Quasi nicht die Bedingungen zu haben, Erfolg haben zu können.
Pavel Mayer: Das heißt von vornherein zu wissen, dass es eigentlich nur schief gehen kann
Pavel Mayer: oder im besten Falle man gerade mit einem blauen Auge da vorn kommt.
Pavel Mayer: Das sind so die ganzen Ängste.
Tim Pritlove: Okay, das heißt, spätestens jetzt haben wir glaube ich mehrere Leute davon abgebracht
Tim Pritlove: eine Programmierer-Kurier in ihrem Leben einzuschreiben.
Tim Pritlove: Bevor wir jetzt zu Lösungsansätzen kommen, würde ich nochmal fragen,
Tim Pritlove: seit wann programmierst,
Tim Pritlove: du jetzt konkret? Nur mal so ein bisschen auch deine Aussage im Hintergrund
Tim Pritlove: der Erfahrung reflektieren zu können.
Pavel Mayer: Ja, also ich glaube, mein mein erstes Programm habe ich so 1979 geschrieben,
Pavel Mayer: noch auf einem Blatt Papier und ja, Geld verdiene ich damit glaube ich so seit
Pavel Mayer: 81, 82 etwa, das heißt ich habe schon, kann man sagen,
Pavel Mayer: ja, als Profi weit über 20 Jahre lang Software. Ciao.
Pavel Mayer: Entwickelt.
Tim Pritlove: Ja du hast ja eigentlich auch sehr viele Programmiersprachen gesehen und diese
Tim Pritlove: ganzen Probleme, die du gerade angesprochen hast, sind auch wirklich vollkommen
Tim Pritlove: unabhängig von Betriebssystemen, Plattformen, Größenordnungen,
Tim Pritlove: das interessiert eigentlich immer alle.
Tim Pritlove: Ja das ist. Ich kenne auch einige der engsten, die du aufgezählt hast,
Tim Pritlove: haben mich sicherlich auch schon mal durchgestanden.
Tim Pritlove: Wobei man manchmal auch so ein bisschen noch die die Freude der Blauäugigkeit hat und sagt,
Tim Pritlove: holy droh, Programmieren macht so einen Spaß, da rauscht man einfach durch und
Tim Pritlove: lässt sich eben auch von Ängsten an nicht so sehr viel bremsen,
Tim Pritlove: aber das ändert noch nichts daran, dass man eben immer noch dazu neigt,
Tim Pritlove: Sachen zu entwickeln, die am Ende keiner haben will oder die im Zweifelsfall
Tim Pritlove: auch nicht funktionieren.
Pavel Mayer: Ja, also irgendwann wird oder die meisten Projekte, so habe ich sie kennengelernt,
Pavel Mayer: wurden entweder irgendwann langweilig oder ja, es wurde dann fast hysterisch.
Pavel Mayer: Je näher dann die Deadlines rückten, umso näher rückten sie auch dem Nervenzusammenbruch.
Pavel Mayer: Es gab dann einige gute Leute, auf denen die ganze oder auf den besten Leuten
Pavel Mayer: ruhte dann auch die Last des ganzen Projekts,
Pavel Mayer: die waren dann irgendwann auch gar nicht mehr ansprechbar und so jetzt als Manager
Pavel Mayer: konnte man dann nur da stehen und beten und und hoffen,
Pavel Mayer: dass sie jetzt das wirklich auch hinbekommen.
Pavel Mayer: Aber man steuerte dann irgendwann, hatte man das Gefühl, komplett nur noch im
Pavel Mayer: Blindflug unterwegs zu sein und nur darauf zu hoffen,
Pavel Mayer: dass die einzelnen Leute irgendwie das Ganze noch gerade rechtzeitig retten
Pavel Mayer: und dass man so noch die Kurve kriegt.
Tim Pritlove: Wobei oh wunder oh wunder ich habe das auch sehr häufig dann gesehen also diese
Tim Pritlove: Kraft der der letzten Tage oder im Zweifelsfall auch der letzten Stunde,
Tim Pritlove: das Programmieren mal wieder zu den Höchstleistungen.
Pavel Mayer: Ja die sogenannte Crunch Time also ich habe das lange Zeit auch für Normalität gehalten, für halt.
Pavel Mayer: Den normalen programmierer alltag weil ich es nirgendwo anders gesehen oder
Pavel Mayer: oder kennengelernt habe und.
Pavel Mayer: Ich muss sagen tatsächlich ist es aber nicht so es muss nicht so sein sondern
Pavel Mayer: mit xp habe ich, Das schien mir,
Pavel Mayer: als ich darauf gestoßen bin, erst mal alles sehr plausibel zu sein.
Tim Pritlove: Also XP, muss man dazu sagen, ist die anerkannte Abkürzung für Extreme Programming,
Tim Pritlove: hat in diesem Fall nichts mit Windows zu tun, aber so nennt man es halt, okay.
Pavel Mayer: Und es war aber auch nicht ganz einfach, damals wirklich damit zu beginnen.
Pavel Mayer: Also in der einen Firma, in der ich dann war, hatte ich versucht,
Pavel Mayer: nun mein Team und meine Kollegen in der Geschäftsleitung damals davon zu überzeugen,
Pavel Mayer: dass wir das doch probieren.
Pavel Mayer: Aber ja, jede Art von Methodik wurde dann eher von der Hand gewiesen und nee,
Pavel Mayer: wir haben das schon immer so gemacht und jetzt irgendeinen Schnickschnack.
Pavel Mayer: Aber als ich dann einen neuen Job angeboten gekriegt habe, bot sich dann die
Pavel Mayer: Gelegenheit, dass ich dort als Bedingung gestellt habe, dass ich freie Hand
Pavel Mayer: habe in der Organisation,
Pavel Mayer: der Entwicklungsabteilung und dass ich insbesondere freie Hand habe,
Pavel Mayer: dort Extreme Programming einzuführen.
Pavel Mayer: Und alle Leute, die dann eingestellt wurden, die ich eingestellt habe,
Pavel Mayer: habe ich von vornherein ja auf Extreme Programming eingeschworen.
Pavel Mayer: Und um es mal vorwegzunehmen, wir betreiben das jetzt seit fünf Jahren und auch
Pavel Mayer: alle Leute in dem Team sind davon dermaßen überzeugt,
Pavel Mayer: dass das eine vernünftige Sache ist,
Pavel Mayer: sodass das zu einem Selbstläufer geworden ist.
Pavel Mayer: Ich glaube nie würde, gerne zu einer anderen Art von Softwareentwicklung wieder zurückzukehren.
Pavel Mayer: Das wäre irgendwie wie ein Rückschritt in die Steinzeit oder in die, ja, so.
Tim Pritlove: Okay gut dann spielen wir das doch mal durch so ich bin jetzt euer neuer Programmierer
Tim Pritlove: ich werde jetzt irgendwie eingestellt nachdem ich meine über vollkommen übertriebenen
Tim Pritlove: Gehaltszahlungen durchgesetzt habe.
Pavel Mayer: Ja das würde dir sicherlich nicht gelingen.
Tim Pritlove: Aber das glaube ich auch nicht.
Tim Pritlove: Aber nehmen wir es einfach mal an, um die Stimmung hochzuhalten.
Tim Pritlove: Wie auch immer. Auf jeden Fall, was müsste ich jetzt lernen?
Tim Pritlove: Was kommt auf mich zu, wenn ich mit XP, also Extreme Programming,
Tim Pritlove: in die Softwareentwicklung einsteige?
Pavel Mayer: Okay, als erstes, äußeres oder auffälligstes Merkmal würdest du sehr viel Zeit
Pavel Mayer: mit anderen Mitprogrammierern vor einem Rechner sitzen, vor einem Bildschirm, vor einer Tastatur,
Pavel Mayer: mit einem normalerweise, wobei durchaus auch Situationen dann entstehen,
Pavel Mayer: wo dann mal drei oder vier Leute vor einem Bildschirm sitzen,
Pavel Mayer: aber das ist dann schon eher etwas übertrieben.
Pavel Mayer: Aber in der in der Regel sitzen halt eben immer zwei Leute vor dem Bildschirm.
Pavel Mayer: Der eine ist der sogenannte Driver, der programmiert und der andere sitzt daneben,
Pavel Mayer: schaut sich an, was er macht, behält das große Bild im Kopf,
Pavel Mayer: weist ihn eventuell auf Fehler hin.
Pavel Mayer: Und ja, und wenn er zu ungeduldig wird und meint, jetzt irgendwie selber mal
Pavel Mayer: Hand an, dann wechselt man eben die Rollen, dann kriegt er die Tastatur in die
Pavel Mayer: Hand und okay, dann dann dann mach du, wenn du meinst.
Tim Pritlove: Also der eine ist der Driver und der andere hatte auch einen Namen?
Pavel Mayer: Ja der partner er wird genau also
Pavel Mayer: der driver und der partners ist die die offizielle xp bezeichnen aber.
Pavel Mayer: XP ist halt viel viel mehr als jetzt nur per programming und das ist ein ein
Pavel Mayer: sicherlich eines der wichtigsten merkmale so nennt man das per programming.
Tim Pritlove: Pair Programming. A. Der Fabriker ist noch nicht fallen gelassen.
Tim Pritlove: M. Ja. A. Im Paar programmieren.
Pavel Mayer: M. Ja.
Tim Pritlove: A. Okay. Aber das ist, glaube ich, auch das, wofür es am bekanntesten ist.
Tim Pritlove: Also wenn ich so von einem Erfahrungsraum, wenn man jetzt Leute auf Extreme
Tim Pritlove: Programming anspricht, dann sagen sie, ah ja, das ist da, wo man irgendwie gemeinsam
Tim Pritlove: vor dem Computer sitzt. Pair Programming.
Pavel Mayer: M. Ja. Also in der Praxis, möchte ich auch mal, um es davor wegzunehmen,
Pavel Mayer: es eignet sich nicht jede Tätigkeit dazu.
Pavel Mayer: Man kann in etwa sagen, je komplizierter die Aufgabe ist, umso besser ist es,
Pavel Mayer: zu zweit daran zu arbeiten.
Pavel Mayer: Einfache Dokumentationstätigkeiten zum Beispiel funktionieren zu zweit nicht
Pavel Mayer: so gut, weil der eine sich dann einfach nur langweilt und nicht wirklich was zu tun hat.
Pavel Mayer: Aber praktisch alle anspruchsvolleren oder schwierigeren Aufgaben,
Pavel Mayer: da braucht man gar keine äußeren Regeln, da holen sich die Leute sofort gerne
Pavel Mayer: und freiwillig jemanden dazu.
Tim Pritlove: Das Modell des Pair-Programmings bricht ja im Prinzip so mit so einem grundlegenden Diven-Status,
Tim Pritlove: den ja Programmierer eigentlich über lange Zeit immer genossen haben und wann
Tim Pritlove: auch mich erinnern kann, in jeder Firma gab es eigentlich immer mit dem einen oder anderen Gott,
Tim Pritlove: der halt so vor seiner Maschine saß und niemand traute sich auch nur in drei
Tim Pritlove: Meter Umkreis oder irgendwie ihn zu berühren, weil man Angst hat,
Tim Pritlove: gleich zu Staub zu zerfallen,
Tim Pritlove: weil eben so übermächtig die Maschine im Griff hat. Das habt ihr sozusagen gar nicht mehr.
Pavel Mayer: Und ja, man muss...
Pavel Mayer: Sehen das bei bei extrem programming viele
Pavel Mayer: dinge ineinander greifen und das ein wichtiges
Pavel Mayer: ziel oder ein ein wichtiges ding ist auch ja
Pavel Mayer: no home monopoly zu vermeiden das heißt dass man versucht das gesamte wissen
Pavel Mayer: über die ganzen entwickler möglichst breit zu zu streuen und zu verteilen und
Pavel Mayer: Also wenn du jetzt kämst, das ist auch ein großer Vorteil.
Pavel Mayer: Jetzt würdest du halt sofort mit einem erfahrenen Mann die ersten Wochen vor
Pavel Mayer: dem Rechner sitzen und natürlich sehr schnell alle spezifischen Dinge,
Pavel Mayer: alle Tricks, wo befindet sich was, sehr schnell aufnehmen.
Pavel Mayer: Das heißt, es eignet sich wunderbar, also es gibt keine Methode,
Pavel Mayer: wo man als Einsteiger wirklich schneller reinkommt, als einfach die ganze Zeit
Pavel Mayer: mit jemandem zusammen da zu sitzen. Also typischerweise.
Tim Pritlove: In zwei Fällen auch erstmal als Partner.
Pavel Mayer: Ja, ja, als Partner, wobei auch die Leute sehr, sehr schnell dann selber auch
Pavel Mayer: durchaus als Driver unterwegs sind.
Pavel Mayer: Und je nachdem, also wir haben dann Einarbeitungszeiten zwischen,
Pavel Mayer: ich würde sagen, zwei Wochen und zwei Monaten typischerweise,
Pavel Mayer: je nachdem wie viel Vorqualifikation die Leute haben, bis sie voll einsetzbar sind.
Pavel Mayer: Und spätestens nach sechs Monaten sind sie wirklich vollwertiges Teammitglied
Pavel Mayer: und können wiederum ja als erfahrene Leute bereits dann wieder neue Leute anlernen.
Pavel Mayer: Umgekehrt ist es, wenn man mal einen Experten in einem bestimmten Gebiet von
Pavel Mayer: draußen reinholt für eine begrenzte Zeit und den auch immer ins Pair gleich
Pavel Mayer: packt, dann ist das natürlich die beste Art und Weise, um Know-how abzusaugen.
Pavel Mayer: Das heißt, auch was der Experte macht, das gesamte Wissen, So kann man am meisten
Pavel Mayer: davon profitieren, wenn immer jemand mit dabei sitzt.
Pavel Mayer: Und wer mit dabei sitzt, das entscheidet man.
Pavel Mayer: Oder die Paarungen, die sind jetzt nicht fest, sondern die werden im Prinzip
Pavel Mayer: jeden Morgen beim sogenannten Stand-up-Meeting aufs,
Pavel Mayer: Neue,
Pavel Mayer: ausgeknobelt.
Pavel Mayer: Das heißt...
Tim Pritlove: A, das heißt es gibt so einen Tagesrhythmus.
Pavel Mayer: Genau.
Tim Pritlove: Der Tag fängt an, erstmal trifft man sich.
Pavel Mayer: Der Tag fängt an, typischerweise bei uns um 10 Uhr, ist so eine ganz gute Zeit.
Pavel Mayer: Für alle und um 10 Uhr beginnt das Stand-up-Meeting, das heißt alle stehen,
Pavel Mayer: niemand darf sitzen, das verhindert, dass das Meeting endlos ausufert.
Tim Pritlove: Acht, deswegen Stand-up-Meeting.
Pavel Mayer: Ja, weil man das im Stehen macht und das macht man typischerweise vor einem...
Tim Pritlove: Ist das eure Methodik oder ist das tatsächlich Bestandteil von XP?
Pavel Mayer: Ja, das ist auch eine XP-Methode,
Pavel Mayer: und verhindert eben ja, dass das Ausufern.
Tim Pritlove: Sondern wahrscheinlich auch, dass die Leute ihre Laptops so klappen.
Pavel Mayer: Ja, ja.
Tim Pritlove: Der Tod jedes Meetings.
Pavel Mayer: Und so das Stand-up-Meeting morgens läuft so,
Pavel Mayer: dass jeder erzählt, was er am Vortag gemacht hat, welche,
Pavel Mayer: also auf welche Probleme er gestoßen ist und erzählt dann, was er für den heutigen
Pavel Mayer: Tag vorhat und sucht sich dann jeweils ein Pair für die Aufgabe.
Pavel Mayer: Und da gibt es den Grundsatz, also wie man ein Pair findet, man fragt halt, kannst du mir helfen?
Pavel Mayer: Und die vorgeschriebene Antwort darauf ist ja.
Tim Pritlove: Okay, Beteiligungszweig.
Pavel Mayer: Und man kann dann aber, also es ist auch so, jeder hat seine Aufgaben,
Pavel Mayer: die er sogenannte Engineering Tasks, die er, für die er selber verantwortlich ist.
Pavel Mayer: Und wenn er sich jetzt jemanden dazu holt, der andere hat natürlich auch Engineering Tasks.
Pavel Mayer: So, aber dann sagt man halt, okay, ich helfe dir jetzt meinetwegen heute Vormittag
Pavel Mayer: und Und heute Nachmittag hilfst du mir dann wiederum bei meinem Engineering-Task,
Pavel Mayer: oder ich helfe dir heute und morgen hilfst du mir bei einem Task.
Tim Pritlove: Wie ist das eigentlich, wenn man jetzt eine ungerade Zahl Programmierer hat?
Tim Pritlove: Was macht man dann? Kommt dann noch eine andere Gruppe dazu?
Pavel Mayer: Ja, das ist schlecht. Ihr könnt ja nicht immer im Zweierpasch neue Entwickler…
Pavel Mayer: Ne, wie gesagt, es gibt Tätigkeiten auch, die besser alleine funktionieren,
Pavel Mayer: wenn man ein neues Betriebssystem….
Pavel Mayer: A. so hin und ja, es gibt halt dann auch andere Meetings, wo man sich koordinieren muss.
Pavel Mayer: Also es ist nicht, es ist nicht, nicht wirklich schlimm jetzt,
Pavel Mayer: wenn man mal eine ungerade Zahl, ja, also das, das, das findet sich dann, dann schon.
Pavel Mayer: Also jedenfalls verhindert man dadurch Know-how-Monopole,
Pavel Mayer: was,
Pavel Mayer: sehr gut ist, wenn die Leute mal in den Urlaub gehen wollen,
Pavel Mayer: dann ist immer jemand da, der trotzdem Bescheid weiß.
Pavel Mayer: Früher war das eben immer ein Problem, dass bestimmte Leute in kritischen Projektphasen,
Pavel Mayer: einfach nicht krank werden durften,
Pavel Mayer: ja keinen Urlaub nehmen konnten.
Pavel Mayer: Und wenn dann so jemand, wenn dann jemand auch noch die Firma vielleicht verlässt,
Pavel Mayer: dann waren das immer gewaltige Katastrophen, die halt tatsächlich ganze Projekte gefährden konnten.
Pavel Mayer: Das ist eigentlich ein sehr unprofessioneller Zustand und das ist für alle einfach sehr entspannt,
Pavel Mayer: dass sie, dass sie wissen, dass die gesamte nicht nur alleine auf ihren Schultern
Pavel Mayer: ruht jetzt, sondern dass sie sich jederzeit jemanden zur Hilfe holen können
Pavel Mayer: und dass auch viele Leute da sind.
Pavel Mayer: Das ist einfach ein unheimlich gutes Gruppengefühl.
Tim Pritlove: Was ich auch noch sehe ist, dass man natürlich dabei auch eine ganze Menge Kleinigkeiten lernt.
Tim Pritlove: Also es sind ja immer so diese kleinen Tricks, so wie löse ich irgendwie dieses
Tim Pritlove: kleine Problem, so ganz alltägliche Sachen, wie kapsel ich das jetzt,
Tim Pritlove: wenn ich mit solchen Datentypen zu mache, Sortieralgorithmen, also so everyday.
Pavel Mayer: Ja, allein Editor-Tricks, also wie man seinen Editor bedient oder wie man sich
Pavel Mayer: seinen Arbeitsprozess, seine Oberfläche.
Tim Pritlove: Und so hat man die Weiterbildung quasi parallel automatisch mit eingebaut.
Pavel Mayer: Und wenn jemand mal eine gute Idee hat oder einen netten Trick,
Pavel Mayer: dann verbreitet sich der einfach ganz schnell in der ganzen Firma,
Pavel Mayer: auch durch die wechselnden Paarungen.
Pavel Mayer: So, was aber jetzt dazu kommt als Prinzip auch noch,
Pavel Mayer: ist, das ist die sogenannte collective code ownership, beziehungsweise,
Pavel Mayer: also jeder darf jederzeit am gesamten Code ändern, was er will.
Pavel Mayer: Früher war das immer so, das ist mein Code und wehe, da fasst jemand dran an,
Pavel Mayer: dann übernehme ich keine Verantwortung oder Garantie, dass das Ganze noch funktioniert.
Pavel Mayer: Einer unserer Entwickler früher brachte der Spruch, ja, wenn der Programmierer
Pavel Mayer: im Urlaub ist, dann ist sein Code auch im Urlaub.
Pavel Mayer: So, das heißt, der darf dann eben nicht verändert oder nicht angefasst werden.
Pavel Mayer: Und bei Extreme Programming ist es explizit so, sowas gibt es nicht.
Pavel Mayer: Jeder darf überall alles ändern. So das Problem ist jetzt natürlich,
Pavel Mayer: wenn jeder überall alles ändern darf und eventuell aber nicht die Zusammenhänge
Pavel Mayer: versteht, wie verhindert man,
Pavel Mayer: dass jeder die Dinge kaputt macht?
Pavel Mayer: Und da kommt dann wieder ein anderes wichtiges Prinzip, nämlich,
Pavel Mayer: die sogenannten Unit-Tests. Das heißt, jede Funktion, die man einbaut,
Pavel Mayer: hat einen dazugehörigen Test, der auch automatisch abläuft.
Pavel Mayer: Und sobald man eine Veränderung irgendwo macht, also wir haben jetzt.
Tim Pritlove: Was heißt, er läuft automatisch ab? Ja, muss ja im Prinzip das ganze Software-Setup,
Tim Pritlove: schon mal so sein, dass es eine Stelle gibt, wo immer Tests laufen.
Pavel Mayer: Ja, genau.
Tim Pritlove: Es gibt, man hat natürlich ein zentrales Software-Repository,
Tim Pritlove: wo also typischerweise CVS oder Subversion, wo die ganze Software eingecheckt
Tim Pritlove: ist, zentral und man sich einzelne Teile rausholen kann.
Pavel Mayer: Genau. Und in dem Moment, wo man jetzt Veränderungen wieder in das zentrale
Pavel Mayer: Repository zurückspielt, gibt es dann wiederum Rechner, die das merken,
Pavel Mayer: aha, da hat es eine Änderung gegeben,
Pavel Mayer: sich die Software holen, sie übersetzen, in dem Fall also compilen und dann
Pavel Mayer: automatische Tests ablaufen lassen, die halt ja dann die Ergebnisse mit Sollwerten vergleichen.
Tim Pritlove: Das heißt, bevor man eine neue Funktion einbaut, muss man sich quasi auch gleichzeitig
Tim Pritlove: Gedanken darüber machen, wie man das testen kann.
Pavel Mayer: Genau, typischerweise.
Tim Pritlove: Gibt es Fälle, wo das nicht greift?
Pavel Mayer: Eigentlich sollte man sogar den Test vorher schreiben. Also bevor man die Funktion
Pavel Mayer: schreibt, schreibt man erst den Test, was auch gleichzeitig hilft,
Pavel Mayer: sich Gedanken über die Schnittstelle zu machen.
Tim Pritlove: Ja, genau. Wie wird das benutzt?
Pavel Mayer: Wie wird das benutzt? Das heißt, das entsteht dann meistens parallel,
Pavel Mayer: also der Test und die Funktion,
Pavel Mayer: wobei es gibt eben bei den Tests unterschiedliche Tests, aber wichtig da sind
Pavel Mayer: vor allem die Modultests auf verschiedenen Ebenen und wir haben,
Pavel Mayer: Unittest heißt das, weil man sich sozusagen auf eine Teilfunktion bezieht.
Tim Pritlove: Auf eine einzelne Unit eben.
Pavel Mayer: Genau, ein bestimmter Modul, eine bestimmte Funktion.
Pavel Mayer: Es gibt auch entsprechende Frameworks, die einem das erleichtern.
Tim Pritlove: Also ich glaube zum Beispiel bei, das fällt mir jetzt gerade so ein,
Tim Pritlove: also es gibt sicherlich noch andere gute Beispiele, aber bei Ruby on Rails,
Tim Pritlove: was ja derzeit eine sehr populäre Entwicklungsplattform ist,
Tim Pritlove: Da ist im Prinzip Tests auch von vornherein vorgesehen.
Tim Pritlove: Es gibt so eine definierte Direktoriestruktur und es gibt auf jeden Fall schon
Tim Pritlove: mal einen Ort, wo man seine Tests rein tut, genau aus solchen Erwägungen heraus.
Tim Pritlove: Aber es gibt sicherlich auch noch andere Beispiele.
Pavel Mayer: Und da ist wichtig, dass es auch einfach ist, die Tests zu schreiben,
Pavel Mayer: dass es halt bequem ist zu testen. Das ist wichtig.
Pavel Mayer: Und da haben wir halt auch ein ganz brauchbares eigenes Framework,
Pavel Mayer: das es wirklich zum Kinderspiel macht. Und ja, ich glaube, also wir haben...
Pavel Mayer: Jetzt in den letzten zwei Jahren ein Framework entwickelt, was so,
Pavel Mayer: ich glaube, knapp 500.000 Zeilen Quellcode hat.
Pavel Mayer: Und ich glaube, ich habe jetzt nicht die genaue Zahl vor Augen,
Pavel Mayer: aber bei einem Durchlauf werden einige 10.000 Tests durchgeführt,
Pavel Mayer: so nach jeder einzelnen Veränderung.
Tim Pritlove: Und… eine Funktion? Wird sie jetzt zigtausendmal getestet oder es gibt zigtausend Tests?
Pavel Mayer: – Nein, typischerweise für eine Funktion hat man dann etwa, ich würde sagen,
Pavel Mayer: je nachdem wie kompliziert diese Funktion ist,
Pavel Mayer: zwischen ein bis zehn Tests, wo man dann versucht, sie mit unterschiedlichen
Pavel Mayer: Parametern, das ist, wenn ein String reingegeben wird, dass man es mal mit einem
Pavel Mayer: leeren String probiert etwa,
Pavel Mayer: oder was ist, wenn der Parameter Null ist, dass man halt auch,
Pavel Mayer: normale Fälle und Grenzfälle und auch die Fehlerbehandlung testet,
Pavel Mayer: typischerweise, um zu sehen, ob auch der richtige Fehlercode zurückgegeben wird,
Pavel Mayer: wenn die falschen Parameter reingehen. A.
Tim Pritlove: Das finde ich ganz interessant, weil was ich sehr häufig festgestellt habe bei
Tim Pritlove: Programmierern ist, dass sie so eine Mentalität entwickeln, so ja,
Tim Pritlove: das muss ich jetzt nicht überprüfen, weil das hat man ja nicht zu machen.
Tim Pritlove: Man hat das ja nicht so zu benutzen und der Benutzer ist ja doof.
Tim Pritlove: Und wenn es auch wiederum nur ein Programmierer ist, der in dem Fall der Benutzer ist.
Tim Pritlove: Weil sehr viel häufiger glaube ich, als dass jetzt wirklich es sich um Code
Tim Pritlove: handelt, der von jemandem benutzt wird.
Tim Pritlove: Es ist ja so, dass andere Programmierer den Code benutzen, weil man eben Module
Tim Pritlove: bereitstellt und so weiter.
Tim Pritlove: Und viele dieser Fehler, die heutzutage
Tim Pritlove: auftreten und die auch für viele Security-Fehler verantwortlich sind,
Tim Pritlove: Entstehen meistens einfach nur deshalb, weil der Programmierer sich gar nicht
Tim Pritlove: vorstellen kann, dass irgendjemand das in einer Art und Weise benutzt,
Tim Pritlove: die anders ist als die, die er sich ursprünglich gedacht hat,
Tim Pritlove: die sozusagen den normalen Zustand darstellt.
Tim Pritlove: Das schärft sicherlich die Sinne ein bisschen, oder? Wenn man solche Tests schreibt.
Pavel Mayer: Auf jeden Fall. Aber es gibt vor allen Dingen auch Leuten, die relativ neu da
Pavel Mayer: sind, so das Vertrauen, wenn sie an einem riesigen System etwas ändern und trotzdem
Pavel Mayer: alle Tests noch durchlaufen, dass sie nichts kaputt gemacht haben.
Pavel Mayer: Das heißt, eine Methode greift eben in die andere und das eine geht nicht ohne das andere.
Pavel Mayer: Das heißt, ein bisschen XP ist zwar,
Pavel Mayer: vielleicht besser als ich sag mal keine dieser methoden zu benutzen aber so
Pavel Mayer: richtig die die volle schönheit entfaltet sich tatsächlich erst wenn diese ganzen
Pavel Mayer: dinge ineinander greifen und.
Pavel Mayer: Mal also diese methoden jetzt mit dem also wie beispielsweise per programming
Pavel Mayer: und test sind natürlich dinge die vor allem die entwickler betreffen aber eine ganz wichtige.
Pavel Mayer: Front ist eben jetzt, also es fängt halt viel früher an, nämlich bei der, an der Kundenfront.
Pavel Mayer: Das heißt, wie man das ganze Projekt von vornherein aufzieht.
Tim Pritlove: B2. Der Kunde, das unbekannte Wesen. A3.
Pavel Mayer: Ja, der, der Kunde. Wir hatten ja schon… B2.
Tim Pritlove: Programmierer hassen Kunden.
Pavel Mayer: A3. Ja, eben, oder beziehungsweise sie haben Angst vor Kunden, weil sie…,
Pavel Mayer: Das hatten wir ja eingangs schon erwähnt, dass es da eben so das heißt,
Pavel Mayer: erst mal fängt es damit an, was oft Wunder wirkt, ist, dass man diese Ängste
Pavel Mayer: offen benennt, auch gegenüber dem Kunden.
Pavel Mayer: Das ist oft, das ist gar nicht einfach, das erfordert Mut, weil so über Ängste
Pavel Mayer: zu reden mit einem Kunden,
Pavel Mayer: aber wenn man sich tatsächlich dann mal überwunden hat, tatsächlich also diesen Mut zur Wahrheit,
Pavel Mayer: so entsteht dann erstmal ein ganz anderes, neues Vertrauensverhältnis und die
Pavel Mayer: Ängste tatsächlich schwinden oder werden kontrollierbar, weil man einfach darüber redet.
Pavel Mayer: Hey, ich habe Angst davor, dass du mir Unmögliches abverlangst so und du hast Angst davor.
Pavel Mayer: Ja, dass ich das verkacke, so. Lass uns sehen, wie wir irgendwie gemeinsam.
Tim Pritlove: Und was macht man da mit dem Kunden?
Pavel Mayer: Ja, und dann ein ganz wichtiges Ding ist, rauszufinden, was dem Kunden wichtig ist und was nicht.
Pavel Mayer: Das heißt, was wir typischerweise machen, also wir schreiben alle Anforderungen, alle Ideen,
Pavel Mayer: alles, was der Kunde gerne hätte, Egal wie absurd es klingen mag oder wie nebensächlich
Pavel Mayer: oder wie vielleicht sogar unmöglich ist, es wird erst mal alles aufgenommen.
Pavel Mayer: Und dann, was auch wichtig ist, dass man die Dinge, die man aufnimmt,
Pavel Mayer: also in XP macht man das in Form von sogenannten User Stories.
Pavel Mayer: Das heißt, man versucht, in nicht technischer Form zu beschreiben oder zu besprechen,
Pavel Mayer: was das System eigentlich tun soll.
Pavel Mayer: In Form von so einer Art Storyboards. Das heißt, wie geht der User mit dem System um?
Pavel Mayer: Plus eben zusätzliche Anforderungen, wenn er schon etwas genauer weiß,
Pavel Mayer: wie, keine Ahnung, das muss unter Windows laufen oder es müssen irgendwie 1000
Pavel Mayer: Leute damit gleichzeitig arbeiten.
Tim Pritlove: Das ist alles Storyboards, also quasi wie ein Drehbuch, dass man also wirklich versucht, die...
Tim Pritlove: Funktionalität, also nicht die Funktionalität, sondern die Art und Weise,
Tim Pritlove: wie die Software eingesetzt wird, zu beschreiben wie einen Film.
Pavel Mayer: Ja, so in etwa wie kleine Episoden aus einem Film und dann halt ja weitere Anforderungen,
Pavel Mayer: die der Kunde oft hat, eben in eine Liste zu bringen.
Pavel Mayer: Und dann ist es ganz wichtig, das priorisieren, weil nicht alle Anforderungen
Pavel Mayer: sind natürlich gleich wichtig.
Pavel Mayer: Und es ist ganz wichtig rauszufinden, was ist dem Kunden wichtig und was ist
Pavel Mayer: dem Kunden weniger wichtig und was ist nur nice to have.
Pavel Mayer: Also typischerweise haben wir dann eine Liste von Merkmalen.
Pavel Mayer: Also muss Dinge, die unbedingt sein müssen, Dinge, die ihm wichtig sind und
Pavel Mayer: Dinge, die er zwar ganz gerne hätte, aber auf die er dann im Notfall auch verzichten kann.
Pavel Mayer: Und das Interessante ist, viele dieser kleinen Dinge, die ihm nicht so wichtig
Pavel Mayer: sind, sind oft wenig aufwendig, sodass man die auch einfach mit erledigen kann.
Pavel Mayer: Das heißt, selbst wenn die Zeit knapp ist, muss man nicht alle Nice-to-haves.
Pavel Mayer: Unter den Tisch fallen lassen, sondern die kann man dann nebenbei erledigen.
Pavel Mayer: Aber ganz wichtig ist, dass wenn man die Dinge, die dem Kunden am wichtigsten sind,
Pavel Mayer: zuerst versucht zu realisieren und einem dann irgendwann die Zeit ausgeht,
Pavel Mayer: dann sind hoffentlich nur noch die weniger wichtigen Dinge übrig,
Pavel Mayer: aber die wichtigen Dinge sind bereits da.
Pavel Mayer: Das ist ein ganz, ganz elementares Prinzip.
Pavel Mayer: Und die Prioritäten können halt während des Projekts jederzeit auch wieder neu festgelegt werden.
Tim Pritlove: Aber jetzt sind ja die Features, die der Kunde haben will, nicht unbedingt immer
Tim Pritlove: die Features, die dem Programmierer auch Spaß machen.
Tim Pritlove: Ja also an der Stelle wird es auch immer spät, häufig ist es ja auch wichtig,
Tim Pritlove: dass man den Programmierer bei Laune hält, wie greift ihr das?
Pavel Mayer: Ja aber da muss der Programmierer dann einfach über seinen Schatten springen
Pavel Mayer: und sich darüber im klaren werden,
Pavel Mayer: wer ihm in dem Fall seine Brötchen bezahlt und ja da ist der Kunde dann schon
Pavel Mayer: tatsächlich einfach König.
Tim Pritlove: A. Ok, aber wenn wir an der Stelle mal vielleicht einen Schritt zur Seite machen
Tim Pritlove: und ein bisschen über Open Source Entwicklungen nachdenken.
Tim Pritlove: Viele Leute, die Chaos Radio hören, sind ja auch in dem Feld selber tätig.
Tim Pritlove: Findest du, dass eben auch für Open Source Projekte Extreme Programming hilfreich sein kann?
Tim Pritlove: Oder ist das jetzt wirklich nur die Erleichterung, um im Kontext einer Firma,
Tim Pritlove: also in so einem künstlichen Gebilde, was es ja eigentlich ist, zu überleben?
Pavel Mayer: Das ist natürlich die Frage, wo ist der Kunde bei Open Source?
Tim Pritlove: Das ist eine gute Frage.
Pavel Mayer: Und was auch wichtig oder eigentlich bei XP im Idealfall ist,
Pavel Mayer: ein Vertreter des Kunden,
Pavel Mayer: ist halt Teil des Teams, ist ständig oder ist zumindest ständig verfügbar,
Pavel Mayer: um Fragen zu beantworten. Das ist auch eines.
Tim Pritlove: Ist das eine Bedingung an den Kunden? Geht ihr da so ran und sagt,
Tim Pritlove: okay, wenn ihr von uns was wollt, dann müsst ihr ja auch eine Person abstellen,
Tim Pritlove: die immer ansprechbar ist?
Pavel Mayer: B2. Ja, das ist das Ideal, ist aber, also ist auch eines der Ideale in XP,
Pavel Mayer: die am tatsächlich am schwierigsten in der Praxis umsetzbar ist,
Pavel Mayer: weil entsprechend qualifiziertes und autorisiertes Personal beim Kunden sehr
Pavel Mayer: häufig nicht zur Verfügung steht.
Pavel Mayer: Und da arbeitet man dann mit einem Stellvertreter, also beispielsweise,
Pavel Mayer: dass man einen Projektleiter hat, der nicht Mitglied des Entwicklungsteams ist
Pavel Mayer: oder bei der Projektentwicklung ein Produktmanager,
Pavel Mayer: der dann die Kundenrolle wahrnimmt und dann eben dort die Prioritäten setzt
Pavel Mayer: und einfach Entscheidungen trifft.
Pavel Mayer: Und der Programmierer wiederum, der Entwickler, ist dann in der schönen Situation,
Pavel Mayer: jeweils wenn jetzt ein neues Feature beispielsweise verlangt wird,
Pavel Mayer: dass dann dafür natürlich, wenn man priorisiert, entsprechend ein anderes Feature
Pavel Mayer: natürlich geringere Priorität bekommt, zwangsläufig.
Pavel Mayer: Das heißt, der Kunde kann auch nicht immer, ich sag mal, mehr und mehr reinpacken,
Pavel Mayer: ohne weiteres, sondern er muss dann gleichzeitig für jedes Ding,
Pavel Mayer: was jetzt vorgezogen oder einen höheren Stellenwert kriegt, bekommen natürlich
Pavel Mayer: andere Dinge zwangsläufig einen geringeren Stellenwert.
Pavel Mayer: Und das ist aber auch ganz in Ordnung so.
Tim Pritlove: Um das nochmal auf Open Source zu übertragen, ist das natürlich eine schwierige
Tim Pritlove: Forderung sozusagen den Kunden.
Tim Pritlove: Auf der einen Seite hat man bei Open Source natürlich auch eine extreme Beteiligung
Tim Pritlove: in der Regel von Kunden, von Nutzern, ob die jetzt von dem Programmierern so
Tim Pritlove: wahrgenommen werden und auch so wertgeschätzt werden, sei mal ganz dahingestellt.
Tim Pritlove: Also die Masse ist auf jeden Fall da und üblicherweise hat man ja auch relativ
Tim Pritlove: nahe Wege, Mailinglisten etc.
Pavel Mayer: Ja, wobei ja also bei Open-Source-Projekten, also bei rein Open-Source-Projekten,
Pavel Mayer: die,
Pavel Mayer: irgendwie,
Pavel Mayer: so
Pavel Mayer: von,
Pavel Mayer: ein,
Pavel Mayer: zwei Leuten mal begonnen werden, weil sie ein brennendes Problem lösen wollen,
Pavel Mayer: da funktioniert das natürlich so nicht.
Pavel Mayer: Aber wenn ein oder zwei Leute irgendetwas machen, da braucht man dann auch XP nicht.
Pavel Mayer: Also XP funktioniert am besten, also skaliert am besten so für Teams mit fünf
Pavel Mayer: bis sechs Leute jeweils.
Pavel Mayer: Also man kann es bis zehn etwa, also zehn Leute in einer Gruppe noch hoch skalieren,
Pavel Mayer: aber wir haben die Erfahrung gemacht, dass wir halt sobald jetzt eine Gruppe
Pavel Mayer: so sechs, sieben Leute überschreitet,
Pavel Mayer: dass wir dann die Gruppen teilen und lieber zwei Gruppen machen,
Pavel Mayer: wobei die Gruppen dann wiederum regelmäßig Teammitglieder austauschen in regelmäßigen
Pavel Mayer: Abständen, um die Kommunikation zwischen den Teams aufrecht zu erhalten und
Pavel Mayer: das auch gepairt wird zwischen den Teams,
Pavel Mayer: damit halt die sich nicht komplett verselbstständigen.
Tim Pritlove: OK, also eure komplette Mannschaft teilt sich in verschiedene Teams auf oder
Tim Pritlove: Gruppen, die sich unterschiedlichen Gesamtproblemen zuwenden,
Tim Pritlove: auch wenn es am Ende alles zusammengehört.
Tim Pritlove: Und dann wird auch da untereinander getauscht. Das heißt, man ist eigentlich
Tim Pritlove: auch sehr viel weniger die ganze Zeit an einer Sache. Weil üblicherweise, ich kenne das auch,
Tim Pritlove: hat man ja dann immer so den Experten für dieses und diesen Experten für dieses
Tim Pritlove: und die tendieren dann auch dazu immer in ihrem Code dran zu kleben und dann
Tim Pritlove: eben auch nicht mehr so änderungsfreundlich zu sein, das wollt ihr damit quasi verändern.
Pavel Mayer: Ja ich meine man arbeitet, um jetzt nochmal weitere Prinzipien oder Methoden,
Pavel Mayer: man arbeitet iterativ und relativ kleinteilig, also Also auch ein Ding ist,
Pavel Mayer: man versucht so schnell wie möglich,
Pavel Mayer: ein funktionierendes System zu haben.
Pavel Mayer: Bei uns haben wir uns auf sogenannte Iterationszyklen von zwei Wochen geeinigt.
Pavel Mayer: Das heißt, man plant immer die Arbeit für zwei Wochen im Voraus.
Pavel Mayer: Also jeden Morgen gibt es dieses Stand-up-Meeting, aber.
Pavel Mayer: Alle zwei Wochen gibt es das sogenannte die Iterationsplanung treffen,
Pavel Mayer: wo man ja die sogenannten Engineering Tasks, das sind die kleinsten Arbeitseinheiten,
Pavel Mayer: die kleinsten Aufgaben, wobei jede Aufgabe dann so idealerweise ein bis drei
Pavel Mayer: Tage an geschätzter Entwicklungszeit nur haben sollte.
Pavel Mayer: Weil wir haben festgestellt, dass es schwierig ist, Aufgaben,
Pavel Mayer: von denen man glaubt, dass man mehr als drei Tage dafür braucht,
Pavel Mayer: zuverlässig schätzen zu können.
Pavel Mayer: So das heißt, wenn man jetzt denkt, ich brauche für die Aufgabe sechs Tage, dann geht das nicht.
Pavel Mayer: Dann muss diese Aufgabe weiter unterteilt werden in zwei oder drei Teilaufgaben,
Pavel Mayer: die man wiederum beschreibt, also Engineering Tasks, die halt eine geringere Schätzzeit haben.
Pavel Mayer: Und das ist eben auch, Also dieses Versuchen, zu schätzen, wie lange man braucht,
Pavel Mayer: ist auch ein wichtiger Prozess.
Pavel Mayer: Und da gibt es eben diese sogenannte ideale Programmierzeit,
Pavel Mayer: die man schätzt und am Ende jeder Iteration oder nein, man hält täglich sogar
Pavel Mayer: fest, schätzt man für jede Engineering Task morgens beim Stand-up-Meeting.
Pavel Mayer: Wie viele Tage brauche ich noch?
Pavel Mayer: Also wenn ich jetzt drei Tage geschätzt habe, habe jetzt einen Tag gearbeitet,
Pavel Mayer: dann kann es sein, dass ich feststelle, okay, das ist jetzt doch schwieriger geworden.
Pavel Mayer: Ich schätze, ich brauche immer noch drei Tage.
Pavel Mayer: Und so hat man auch eine ganz gute Kontrolle, also einmal eine Selbstkontrolle
Pavel Mayer: darüber, wie viel Arbeit noch da ist und wie gut man mittlerweile im Schätzen geworden ist.
Pavel Mayer: Und nach 14 Tagen berechnet man dann die sogenannte Velocity des Teams, das heißt,
Pavel Mayer: wie viele von den Engineering-Tasks sind jetzt tatsächlich fertig geworden und
Pavel Mayer: wie viele, also die Velocity sind dann sozusagen die Tage idealer Programmierzeit,
Pavel Mayer: die man in der Lage war, vorauszuplanen.
Pavel Mayer: Das ist dann auch so ein selbstregulierendes Ding, weil für die nächste Iteration
Pavel Mayer: nimmt man sich dann wieder nur so viel Tage oder darf man sich nur so viel Tage
Pavel Mayer: vornehmen, wie man in der letzten Iteration auch geschafft hat.
Tim Pritlove: Also quasi über die über die die Methode der Selbsteinschätzung,
Tim Pritlove: der sicherlich auch nochmal Angst mindernd wirkt, nicht, wenn man das überhaupt
Tim Pritlove: erstmal so zugibt, so ich habe länger gebraucht, das ist ja auch nicht unbedingt
Tim Pritlove: jetzt jedermanns Sache, da so offen einzustehen.
Tim Pritlove: Fühlt man ja sozusagen dann auch eine eine Selbstkontrolle.
Pavel Mayer: BK'IN WIRKLICHE REDEN. Ja und an der Stelle, also XP generell erfordert schon
Pavel Mayer: Offenheit und Vertrauen,
Pavel Mayer: aber auch einen Vertrauensschutz dann, weil man offenbart sich schon an verschiedenen Stellen.
Pavel Mayer: Also es fängt an beim Pair-Programming, wo man natürlich auch seine Schwächen,
Pavel Mayer: und vielleicht Fehler, die man macht, seinem Partner offenbart.
Pavel Mayer: Das fällt anfangs, merkt man oft vielen Leuten, nicht leicht,
Pavel Mayer: weil sie denken, der hält mich jetzt für einen Idioten, weil ich irgendwie keine
Pavel Mayer: Ahnung dieses oder jenes Keyword vielleicht in der Programmiersprache nicht kenne.
Pavel Mayer: Und diese Angst zu nehmen, so das ist auch ein ganz, ganz wichtiges Ding,
Pavel Mayer: auch, dass man Leute eben nicht in die Pfanne haut,
Pavel Mayer: wenn sie sich jetzt verschätzt haben, sondern dass man das eben als normalen,
Pavel Mayer: als Normalität auch begreift und versteht und versucht, dann einfach gemeinsam
Pavel Mayer: das Ganze besser zu machen.
Pavel Mayer: Da ist auch ein wichtiges Prinzip, dass jeder selber seine Zeit schätzt.
Pavel Mayer: Also was nicht passieren darf bei XP ist, dass ich schätze, wie lange irgendjemand
Pavel Mayer: anders dafür jetzt brauchen darf, weil dann kann ich ihn auch schlecht drauf
Pavel Mayer: festnageln. Das heißt, jeder schätzt die Zeit für seine Engineering-Task selber.
Pavel Mayer: Das ist auch ein ganz wichtiges Prinzip.
Tim Pritlove: Was wenn man anderer Meinung ist, dann kommt das wahrscheinlich schon in diesem
Tim Pritlove: Stand-up-Meeting. Genau, dann ist das auch Bestandteil des Stand-up-Meetings, diese Einschätzung.
Pavel Mayer: Ja, beziehungsweise, nee, das passiert bei der Iterationsplanung.
Pavel Mayer: Da schätzt man auch also alle 14 Tage sozusagen, wenn man diese Engineering-Tasks aufhängt.
Pavel Mayer: Das geht auch mit schönen kleinen Kärtchen.
Tim Pritlove: Da kommen wir zu den Karten. Okay, warte mal, da müssen wir nochmal kurz,
Tim Pritlove: nicht, dass es verwirrt, Ich bin ein bisschen verwirrt.
Tim Pritlove: Also wir haben jetzt an regelmäßigen Treffen, die Stand-up-Meeting, das ist jeden Tag.
Tim Pritlove: Dann sagst du, gibt es ein Iterationsplanungstreffen.
Pavel Mayer: Alle 14 Tage.
Tim Pritlove: Alle 14 Tage. Ist das jetzt auch so in XP vorgeschrieben oder ist das so eure
Tim Pritlove: Erkenntnis, wie das so zusammenhängt?
Pavel Mayer: In XP sagt man so, Iterationen sollten ein bis drei Wochen etwa dauern.
Tim Pritlove: Okay, dann seid ihr in der Mitte alle zwei Wochen. Und das heißt,
Tim Pritlove: dass ihr quasi die Zeitziele aller einzelnen Tasks, aller einzelnen Aufgaben,
Tim Pritlove: die ihr euch gestellt habt, überprüft.
Tim Pritlove: Und dann eben auch danach, wahrscheinlich dann in Abhängigkeit der Abhängigkeiten
Tim Pritlove: dieser Tasks untereinander, auch eine Aussage darüber treffen können,
Tim Pritlove: wie lange brauchen wir den eigentlich noch.
Tim Pritlove: Beziehungsweise, es gibt eine Deadline XY.
Tim Pritlove: Die dürfen wir nicht verpassen, weil die Messe fängt an, was auch immer.
Tim Pritlove: Und dann müssen wahrscheinlich entsprechend Features gekürzt werden oder man
Tim Pritlove: muss sich zumindest darüber unterhalten, wie man das beschleunigen kann.
Tim Pritlove: Gibt es sonst noch irgendwelche regelmäßigen Treffen?
Pavel Mayer: Ja, es gibt bei größeren Projekten gibt es dann wiederum die sogenannten Release-Planungstreffen,
Pavel Mayer: die man dann so etwa im Zwei-Monats-Zyklus macht, wo man dann versucht größer,
Pavel Mayer: voraus zu planen, wo man dann die User-Stories sich eben auch überlegt,
Pavel Mayer: die man für die nächste Release gerne hätte.
Pavel Mayer: Wobei eigentlich haben wir bei unserer Arbeit festgestellt, dass wir selten
Pavel Mayer: überhaupt Release-Planungstreffen brauchen,
Pavel Mayer: weil die meisten Projekte, die wir machen, einfach innerhalb von zwei Monaten
Pavel Mayer: mit dem großen Team, was wir haben erledigt sind.
Pavel Mayer: Es gibt dann halt größere Treffen.
Pavel Mayer: Da gibt es dann noch weitere Strukturen oben drüber bei Projekten,
Pavel Mayer: die jetzt mehrere Jahre dauern.
Pavel Mayer: Ja.
Tim Pritlove: Aber wenn man jetzt ein Betriebssystem entwickelt oder so Sachen,
Tim Pritlove: die naturgemäß über sehr lange Zeiträume laufen, mag das schon sehr sinnvoll sein.
Tim Pritlove: So und diese Karten, die du jetzt erwähnt hast, die habe ich auch schon mal
Tim Pritlove: gesehen. Die hängen dann bei euch an der Wand. Gibt es so Kärtchen?
Tim Pritlove: Was ist die Aufgabe dieser Karten, dieser Story-Karten?
Tim Pritlove: Naja, beziehungsweise diese Engineering-Task-Karten.
Tim Pritlove: Verschiedene Karten.
Pavel Mayer: Ja, wobei wir im Wesentlichen, die Engineering-Task-Karten,
Pavel Mayer: sind,
Pavel Mayer: bei uns jetzt konkret die wichtigsten. Das heißt, da weiß man einfach,
Pavel Mayer: an denen hangelt man sich morgens dann immer entlang.
Tim Pritlove: Was steht da drauf?
Pavel Mayer: Da steht dann zum Beispiel so etwas drauf, was ist so ein typischer Engineering-Task,
Pavel Mayer: bei uns, wie Unicode-Transparenz.
Pavel Mayer: In dem und dem Modul herstellen oder dafür sorgen, dass sich Objekte auf einer
Pavel Mayer: bestimmten Spline-Kurve bewegen oder …,
Pavel Mayer: eines bestimmten Bereiches, der klar auch messbar ist, ganz also wo man auch
Pavel Mayer: vor allem testbar und wo man dann ganz klar ja einzelne,
Pavel Mayer: features eben ja das
Pavel Mayer: werden wahrscheinlich ganze menge karten dann sein das sind
Pavel Mayer: ja also wir sehen zu
Pavel Mayer: dass wir möglichst auch die drei tageskarten vermeiden wenn es geht das heißt
Pavel Mayer: wir haben ein und zwei tageskarten und drei tageskarten also wo die schätzung
Pavel Mayer: bei drei tagen liegt wissen wir die sind schon unter umständen kritisch also
Pavel Mayer: die unterschiedliche farbe also sieht man das gleich.
Pavel Mayer: Das steht drauf, es gibt eine Spalte dafür und da steht die erste Schätzung drin,
Pavel Mayer: also in jeder Zeile wird dann jeden Tag, wo an einer Karte gearbeitet wird,
Pavel Mayer: wird halt eingetragen, okay,
Pavel Mayer: wie viel ist dann gearbeitet worden und wie viel glaube ich,
Pavel Mayer: dass ich jetzt noch brauche für diese einzelne Task. A.
Tim Pritlove: Ok, das heißt diese Karte dient gar nicht mal nur dazu, um aufzuschreiben, was noch zu tun ist.
Tim Pritlove: Das ist jetzt nicht eine reine To-Do-Liste, sondern es reflektiert quasi auch,
Tim Pritlove: den Fortschritt, den man konkret gemacht hat.
Tim Pritlove: D.h. wenn ein Tag daran gearbeitet wurde und man hat das Problem noch nicht
Tim Pritlove: gelöst, dann wird eingetragen, den und den Fortschritt habe ich jetzt erzielt,
Tim Pritlove: oder macht man eine Strichliste oder was?
Pavel Mayer: Ich habe jetzt einen tag dran gearbeitet oder einen halben
Pavel Mayer: tag dran gearbeitet und ich brauche jetzt noch anderthalb
Pavel Mayer: tage beispielsweise und wenn die engineering
Pavel Mayer: task eben wenn ich fertig bin dann wird die schön durchgestrichen und dann wendet
Pavel Mayer: man sich der nächsten karte zu so und für 14 tage hat also jeder entwickler
Pavel Mayer: so ich sag mal zwischen zwei bis vier karten etwa so und dann kann man sich das halt ausrechnen,
Pavel Mayer: so wie viel Engineering Tasks man so als Pro-Entwickler dann bearbeitet.
Pavel Mayer: Also pro Woche, sagen wir mal, zwei Karten. Das heißt, jeder Entwickler macht,
Pavel Mayer: halt etwa 100 Engineering Tasks pro Jahr.
Pavel Mayer: Und bei einem 10-Mann-Team sind es halt 1000 Engineering Tasks,
Pavel Mayer: die man so pro Jahr etwa dann,
Pavel Mayer: abarbeitet.
Tim Pritlove: Das heißt, man braucht eine relativ große Tafel.
Tim Pritlove: Wie viele Karten hängen da so normalerweise gleichzeitig?
Pavel Mayer: Immer nur die für die nächsten 14 Tage.
Tim Pritlove: Und wie viel sind das dann so bei euch, mal nur so von der Dimension?
Pavel Mayer: Naja, wie gesagt, so vier pro Person, je nach Teamgröße hängen dann da vielleicht
Pavel Mayer: 20 Karten an der Wand so und die werden dann in 14 Tagen alle abgearbeitet.
Tim Pritlove: Haben die dann eine spezielle Sortierung? in einer Form also die abholen die
Tim Pritlove: jetzt nach den nach der Wichtigkeit nice to have oder wie?
Pavel Mayer: Sven Ne die werden ja konkret einer Person zugeteilt so
Pavel Mayer: dass das läuft dann so ab dass da wird dann in dem
Pavel Mayer: Treffen eine Task aufgeschrieben und dann wird gefragt so wer hat Interesse
Pavel Mayer: dran diese Task jetzt zu übernehmen und dann kann jemand die Hand heben und
Pavel Mayer: entweder man hebt die Hand frühzeitig oder man kriegt halt dann irgendwann die
Pavel Mayer: Karten die übrig bleiben.
Pavel Mayer: So jetzt kann man sich dann überlegen, das funktioniert eigentlich recht gut.
Tim Pritlove: Die Karten sind einfach Papier. Schon mal drüber nachgedacht,
Tim Pritlove: das Ganze elektronisch zu machen?
Pavel Mayer: Ja, allerdings haben diese Papierkarten,
Pavel Mayer: doch erhebliche Handling Vorteile gegenüber was Elektronischen.
Pavel Mayer: Es geht einfach schneller mit den Karten an der Pinnwand. Die kann man eben
Pavel Mayer: mal abnehmen oder zurückschieben.
Pavel Mayer: Man kann sie sehr schnell ausfüllen. Also da sind die Karten einfach jeder elektronischen
Pavel Mayer: Lösung, glaube ich, überlegen.
Tim Pritlove: SIEGFRIED Lebt man die denn runter, wenn man dann jetzt sozusagen daran arbeitet?
Tim Pritlove: Heißt das so, ich picke mir heute meine Aufgaben?
Pavel Mayer: BARTHOLZ Nö, die hängen da und wie gesagt, vor allen Dingen morgens beim Stand-Up-Meeting,
Pavel Mayer: kann man dann die Karten durchgehen und die dienen dann sehr schön als Orientierung auch,
Pavel Mayer: dass man sich halt nicht verdaddelt und man sieht dann auch,
Pavel Mayer: was man noch zu tun hat an Aufgaben.
Pavel Mayer: Man kann sich das selber überlegen, an welcher Karte von denen,
Pavel Mayer: die man jetzt hat, man als erstes bearbeitet, spielt dann nicht unbedingt die
Pavel Mayer: Rolle, was man dann nimmt.
Tim Pritlove: Haben wir jetzt die ganzen konzepte im kern schon bei weitem nicht bei weitem
Tim Pritlove: nicht das klingt ja relativ komplexen
Tim Pritlove: system wie lange muss man sich damit beschäftigen bis man das so halbwegs.
Pavel Mayer: Wie gesagt das geht das geht relativ schnell weil die sachen alle sie sind halt auch.
Pavel Mayer: Sehr, sehr eingängig und sie sind halt logisch und schlüssig und viele dieser
Pavel Mayer: Dinge sind auch Dinge, die man sowieso schon macht oder mal gemacht hat,
Pavel Mayer: allerdings nicht in dieser Kombination und in dieser Gründlichkeit und Konsequenz.
Pavel Mayer: Also man setzt sich gerne mal mit guten Freunden zusammen vor den Rechner und das hat,
Pavel Mayer: glaube ich, auch jeder Programmierer mal gemacht oder das Testen gut ist,
Pavel Mayer: ist auch klar und priorisieren, aber das eben konkret zu machen,
Pavel Mayer: das ist wichtig, aber vielleicht noch mal auf die Iterationen zurückzukommen
Pavel Mayer: und auf den Kunden so ein bisschen.
Pavel Mayer: Wichtig ist es, hatte ich ja schon erwähnt, dass man sehr schnell was funktionierendes
Pavel Mayer: hat, was man auch dem Kunden zeigen kann, so dass man halt Feedback einholen kann.
Tim Pritlove: Kurze Redezeit hat sozusagen.
Pavel Mayer: Dass man eigentlich immer ein funktionierendes System hat, was man dem Kunden
Pavel Mayer: zeigen kann und wo er dann ganz konkret schon sehr früh sieht, was er bekommt.
Pavel Mayer: Das heißt nicht erst am Ende völlig überrascht ist, was hat er denn da,
Pavel Mayer: sondern eigentlich begleitet er den Prozess die ganze Zeit über und kann dann
Pavel Mayer: auch nicht am Ende sagen, hoch, also das hätte ich jetzt nicht erwartet.
Pavel Mayer: Und unsere Erfahrung ist, dass die Kunden, also in der Regel die das dann wirklich
Pavel Mayer: auch begleiten, dann doch sehr angetan sind und auch sehr überrascht sind, dann am Ende,
Pavel Mayer: wie viel, also wie sehr das System dann ihren Vorstellungen tatsächlich entspricht.
Pavel Mayer: Und so, das tut dann halt sehr.
Tim Pritlove: Also im Prinzip deine Erfahrung mit Extreme Programming ist die,
Tim Pritlove: um das mal auch ein bisschen zusammenzufassen, dass dadurch,
Tim Pritlove: dass man in Teams arbeitet,
Tim Pritlove: dadurch, dass Leute sich nicht nur um eine Sache kümmern, sondern dass man eigentlich
Tim Pritlove: seine Programmierer über die zu erledigenden Aufgaben streut,
Tim Pritlove: immer wieder austauscht,
Tim Pritlove: Dadurch, dass man seine Software, während man sie entwickelt,
Tim Pritlove: am laufenden Meta testet, dass man im Prinzip den Test schon vorher schreibt und auch dadurch,
Tim Pritlove: dass man sich bemüht, und das hängt ja mit diesen Tests auch ein bisschen zusammen,
Tim Pritlove: weil man kann ja nichts testen, was nicht läuft, dass man sich bemüht immer
Tim Pritlove: zu einem laufenden System beizutragen, sodass man eben nicht so drei,
Tim Pritlove: vier Wochen Hänger hat, wo erstmal gar nichts läuft und ich schreibe jetzt sowieso
Tim Pritlove: erstmal alles neu und keiner kann was testen.
Tim Pritlove: Dass man damit eigentlich auch unmittelbar den Anforderungen des Auftraggebers,
Tim Pritlove: Kunden, wie man es auch immer nennen möchte, entgegenkommt.
Pavel Mayer: B2 Ja und man minimiert das Risiko natürlich extrem, weil man auch,
Pavel Mayer: wenn man sieht, das läuft in die falsche Richtung,
Pavel Mayer: dann kann man halt frühzeitig gegensteuern und nicht erst, wenn das ganze Geld
Pavel Mayer: ausgegeben ist, sondern man hat halt dann sehr frühzeitig.
Pavel Mayer: Und man weiß auch darüber, also wir haben gerade jetzt in den fünf Jahren noch das ganze Thema.
Pavel Mayer: Vorhersage noch ganz gut optimiert. Das heißt, wie lange brauchen wir für bestimmte Aufgaben?
Pavel Mayer: Da haben wir noch ein paar eigene Verfeinerungen eingeführt,
Pavel Mayer: nämlich dass wir Engineering Tasks nach Innovationsgrad und nach Komplexität nochmal versuchen,
Pavel Mayer: einzuordnen.
Pavel Mayer: Und wir haben halt Metriken, wo wir wissen, wie sehr wir uns verschätzen bei
Pavel Mayer: einzelnen Aufgaben, abhängig davon eben, wie innovativ und wie komplex die Dinge sind.
Pavel Mayer: Und diese Faktoren berechnen wir vorher bei der Planung schon mit ein und sind
Pavel Mayer: mittlerweile tatsächlich so gut, dass wir in den letzten anderthalb Jahren,
Pavel Mayer: ist mir kein Fall bekannt, wo wir wesentlich über der veranschlagten Zeit gelegen
Pavel Mayer: hätten und wo wir tatsächlich die erwarteten Features in der erwarteten Zeit
Pavel Mayer: dann auch geschafft haben.
Pavel Mayer: Und es gibt natürlich auch gerade bei den Projektleitern ein Vertrauen, was wichtig ist.
Pavel Mayer: Sie brauchen auch nicht irgendwie künstliche Sicherheiten einzurechnen, weil das.
Pavel Mayer: Ja, das passt. Und bei größeren Dingen hat man eben auch mehr Vorwarnzeit.
Pavel Mayer: Also wir haben teilweise bei größeren Projekten so die Vorwarnzeit auf,
Pavel Mayer: ich sag mal, zwei Monate etwa so herausgesetzt.
Pavel Mayer: Das heißt, wir konnten relativ genau, also zwei Monate vorher schon sagen,
Pavel Mayer: dass wir voraussichtlich nicht fertig werden mit dem erwarteten Umfang.
Pavel Mayer: Das erfordert auch wieder Mut zur Wahrheit und die Leute wollen einem das oft
Pavel Mayer: gar nicht glauben, dass man halt schon zwei Monate vorher weiß, dass man genau,
Pavel Mayer: wir können dann genau sagen, okay, wir brauchen sechs Tage länger,
Pavel Mayer: zwei Monate im Voraus, um fertig zu werden.
Tim Pritlove: Ja, weil die gängige Annahme ja die ist, dass man dann einfach am Wochenende
Tim Pritlove: mal ein bisschen durcharbeitet, dann holt man das schon wieder raus.
Tim Pritlove: Aber das macht ihr dann ganz bewusst nicht.
Pavel Mayer: Überstunden sind verboten bei Extreme Programming. Das ist halt auch noch ein wichtiges Merkmal,
Pavel Mayer: weil Überstunden sich letztendlich nicht auszahlen,
Pavel Mayer: weil wenn die Leute mehr arbeiten, also es ist halt nicht nachhaltig, so eine Crunch Time.
Pavel Mayer: Das heißt, wenn die Leute zu viel arbeiten, sinkt faktisch die Produktivität.
Pavel Mayer: Das heißt, man versucht, jeden einzelnen Entwickler so an seinem Sweet Spot,
Pavel Mayer: also die Produktivität am Sweet Spot zu halten, weil wenn man darüber hinausgeht,
Pavel Mayer: mag sein, dass man dann vielleicht tatsächlich die Woche früher fertig wird.
Pavel Mayer: Gelegentlich passiert das auch,
Pavel Mayer: aber da gibt es die Regel, wenn es denn absolut nicht zu vermeiden ist.
Pavel Mayer: Dass man dann zeitnah wiederum für Ausgleich und Erholung sorgt.
Pavel Mayer: Das heißt, wenn jemand tatsächlich mal Überstunden einschieben musste,
Pavel Mayer: dass er dann gezwungen wird,
Pavel Mayer: zwei Tage frei zu nehmen, wenn er das Wochenende übergearbeitet hat,
Pavel Mayer: um einfach die Leute maximal produktiv zu halten.
Pavel Mayer: Und das ist eben auch eine Sache, die einfach ökonomisch ist,
Pavel Mayer: Weil man lügt sich dann auch in die Tasche, wenn man meint.
Pavel Mayer: Leute holen sich ihren Urlaub so oder so, selbst wenn sie vom,
Pavel Mayer: vom Rechner sitzen, dann starren sie halt zwei Stunden in den Bildschirm,
Pavel Mayer: ohne etwas zu tun oder klicken im Web rum oder tun einfach andere Dinge.
Pavel Mayer: Und dann ist es einfach am besten, wenn jeder ja acht Stunden am Tag konzentriert
Pavel Mayer: an einer Sache auch arbeitet, als jetzt zwölf Stunden dort zu sitzen,
Pavel Mayer: aber acht Stunden davon eigentlich nur schlapp in den Seilen zu hängen.
Tim Pritlove: Ist ein ehrlicher Deal, da fällt mir noch was ein, vielleicht macht ihr das
Tim Pritlove: ja auch, aber da würde mich auch mal deine Meinung dazu interessieren.
Pavel Mayer: Es wird ja so kolportiert, dass bei Google ist die Anweisung,
Pavel Mayer: gibt es die Poemierer, ich weiß nicht, ob es nur die Poemierer betrifft,
Pavel Mayer: im Wesentlichen wahrscheinlich, dass die einen Tag in der Woche freikriegen,
Pavel Mayer: um an ihren eigenen Projekten zu arbeiten.
Pavel Mayer: Habt ihr so was ähnliches? Nein.
Tim Pritlove: Also ich bin mir jetzt ehrlich gesagt bei dem Tag in der Woche nicht ganz so
Tim Pritlove: sicher, aber es gibt ein gewisses Zeitkontingent, was sozusagen freigestellt
Tim Pritlove: wird, die Programmierer explizit ermutigt werden auch eigene Sachen auszuprobieren.
Pavel Mayer: Ja, ich meine das ist sicherlich auch eine gute Sache, wenn man sich's äh...
Pavel Mayer: Leisten kann bei uns. Konkret läuft es so, dass wir auch eine ganze Reihe von
Pavel Mayer: Forschungsprojekten haben, aber das wird dann einfach eingestreut.
Pavel Mayer: Das sind dann auch Engineering-Tasks, die ja, dann äh. A.
Tim Pritlove: Achso, wo man sich quasi dann auch gemeinsam drauf einigt, dass man in den Sachen
Tim Pritlove: schon immer mal rumforschen wollte.
Tim Pritlove: Und das können dann aber auch Einzelne vorbringen, dass sie das sozusagen mal
Tim Pritlove: für ein interessantes Ding halten.
Pavel Mayer: Ja, bestimmte Features oder Projekte, die sich die Gruppe dann einfach selber
Pavel Mayer: geben kann, wo es dann in dem Sinne keinen Kunden gibt, sondern wo die Gruppe
Pavel Mayer: als solche der Kunde ist, weil man gerne ein bestimmtes Feature hätte.
Pavel Mayer: Was wir allerdings machen, ist der sogenannte Infrastructure Friday,
Pavel Mayer: wobei tatsächlich nur das ein halber Tag ist, wo wir uns gemeinsam um unsere
Pavel Mayer: Tools und Werkzeuge kümmern.
Pavel Mayer: Weil wir haben festgestellt, oft wenn die Zeit knapp ist, dann denkt man,
Pavel Mayer: okay, also dieses Problem mit dem Bildsystem oder irgendwie jenes Dokumentationstool,
Pavel Mayer: wenn ich ein bisschen Zeit habe, dann fixe ich das.
Pavel Mayer: Aber tatsächlich kann man nicht vorhersagen, wann wirklich die Zeit da ist.
Pavel Mayer: Das heißt, wir sehen zu, dass wir regelmäßig einen halben Tag pro Woche wirklich
Pavel Mayer: darauf verwenden, unsere eigene Entwicklungsumgebung, Bildserver und so weiter zu verbessern.
Tim Pritlove: Alle dann gleichzeitig quasi?
Pavel Mayer: Ja, wir haben da eigentlich den Freitagnachmittag so bei uns dafür reserviert.
Pavel Mayer: Das heißt, Zum Wochenausklang.
Pavel Mayer: Zum Wochenausklang, genau.
Tim Pritlove: Dann weiß man auch gleich, wenn man Montag wieder reinkommt,
Tim Pritlove: ist alles ein bisschen besser als vorher.
Tim Pritlove: Interessante Motivationsschritt. Zumal der Freitagnachmittag ja sowieso immer
Tim Pritlove: so die Tendenz hat, etwas auszufranzen.
Tim Pritlove: Dann leidet zumindest nicht die eigentliche Softwareentwicklung.
Tim Pritlove: Ah ja, okay. Interessanter Ansatz.
Tim Pritlove: Haben wir denn jetzt die ganzen Kernpunkte von XP, sagen wir jetzt mal so,
Tim Pritlove: wie es im Buch steht, bereits abgearbeitet?
Tim Pritlove: Ich glaube die wichtigsten Dinge haben wir jetzt.
Tim Pritlove: Gibt es denn einen einzelnen Punkt von diesen Guidelines, wie ich das mal nennen
Tim Pritlove: möchte, diesen Richtlinien, die Extreme Programming da aufruft,
Tim Pritlove: die dir besonders imponiert haben?
Tim Pritlove: Oder vielleicht sogar, je nachdem, vielleicht auch etwas, was sehr viel mehr
Tim Pritlove: Effizienz gebracht hat, als du es ursprünglich erwartet hättest.
Tim Pritlove: Wenn das jetzt so jemand hört, denkt er sich so, ah, naja, einsam auf dem Rechner sitzen und so.
Pavel Mayer: Ich denke, wenn ich jetzt gezwungen wäre, drei Kernpunkte rauszugreifen,
Pavel Mayer: die am wichtigsten sind, dann ist das das iterative Vorgehen,
Pavel Mayer: das Pairing auf jeden Fall und das Testen.
Pavel Mayer: So diese, ja die automatischen Tests, das sind, würde ich sagen,
Pavel Mayer: die unverzichtbar sind.
Pavel Mayer: Ja, aber alle anderen Dinge werden auch gebraucht, damit das eben smooth ineinander greift.
Pavel Mayer: Und als Wert eben, ja, die Ehrlichkeit. Also das ist auch immer,
Pavel Mayer: also Ehrlichkeit mit sich selbst und Ehrlichkeit gegenüber dem Kunden.
Tim Pritlove: B2. Und dem Rest des Teams auch. A1.
Pavel Mayer: Und natürlich ja, also Ehrlichkeit und Vertrauen. B2.
Tim Pritlove: Führt auch zu einer besseren Stimmung wahrscheinlich.
Pavel Mayer: A1. Auf jeden Fall. Also gerade die Stimmung und die Krankheitsrate und also. B2.
Tim Pritlove: Naja, auch die Bereitschaft einzuspringen, wenn jetzt jemand Probleme hat wahrscheinlich.
Tim Pritlove: A1. Mhm. Die schönen Utopier in der Vorfeldentwicklung.
Pavel Mayer: Und wenn es denn wirklich mal brennt, dann kann man auch, dann weiß man,
Pavel Mayer: also wenn wirklich die Dinge mal schief gegangen sind, wenn wirklich die Realität
Pavel Mayer: mal komplett mit der Planung auseinandergelaufen ist,
Pavel Mayer: was halt manchmal einfach passiert durch, also am häufigsten durch äußere Einflüsse,
Pavel Mayer: dass sich eben die Bedingungen,
Pavel Mayer: die äußeren Bedingungen ändern oder man manchmal von vornherein weiß,
Pavel Mayer: eigentlich geht es nicht.
Pavel Mayer: Aber dann weiß man, dass man ein absolut fittes Team hat,
Pavel Mayer: was dann auch in der Lage ist,
Pavel Mayer: richtig zuzupacken und auch den Karren aus dem Dreck zu ziehen und nicht eine
Pavel Mayer: halb geschlagene Armee,
Pavel Mayer: die irgendwie schon halb Halb verhungert schlaflos mit Rändern sowieso und nur
Pavel Mayer: noch resigniert irgendwie,
Pavel Mayer: ankämpft ja.
Tim Pritlove: Was mich noch interessieren würde gibt es technische Werkzeuge die ihr jetzt
Tim Pritlove: zum Einsatz bringt die jetzt über die normalen Entwicklungswerkzeuge hinaus geben?
Pavel Mayer: Die jetzt zu irgendeinem dieser punkte im extrem bei programming
Pavel Mayer: beitragen also kommunikation zum austausch zu der meditation also definitiv
Pavel Mayer: also unser bild system also der automatisierungsgrad in unserem bild und dokumentationssystem
Pavel Mayer: glaube ich ist ziemlich fortgeschritten und zwar hatte ich ja schon erwähnt,
Pavel Mayer: was man sowieso hat, zentrales Repository,
Pavel Mayer: der Bild und die automatischen Tests.
Pavel Mayer: Was sich bei uns aber noch anschließt an die Module-Tests, sind halt generelle Regressions-Tests,
Pavel Mayer: wo halt, also wir haben halt eine 3D-Multimedia-Software,
Pavel Mayer: Bilder, die halt dann bestimmte Szenen rendern soll und dort haben wir beispielsweise etwa 100 Ergebnisse,
Pavel Mayer: also Testbilder, die dann rausgeschrieben werden und die dann verglichen werden
Pavel Mayer: am Ende des Prozesses und...
Tim Pritlove: Also kannst du nochmal kurz erläutern, was ein Regressionstest ist?
Pavel Mayer: Das ist mehr ein Test, wo man das Ergebnis, was bei dem Test rauskommt,
Pavel Mayer: mit einem vorgegebenen, mit einem Soll-Ergebnis dann einfach vergleicht.
Tim Pritlove: Inwiefern ist das jetzt ein, also ich meine, macht das nicht jeder Test,
Tim Pritlove: ich meine, testet ob das und das stattfindet?
Pavel Mayer: Ja, allerdings sind, also diese sind dann nicht mehr auf Modulebene,
Pavel Mayer: also keine Modultests mehr, sondern tatsächlich auf Anwendungsebene,
Pavel Mayer: wo… Geht's beim Registrierungs-Test nicht auch ein bisschen um die Wiederholung,
Pavel Mayer: dass man das irgendwie in verschiedenen Varianten testet?
Pavel Mayer: Ja gut, natürlich versucht man mit den Tests möglichst viel,
Pavel Mayer: ich sag mal, Codepfad abzudecken.
Pavel Mayer: Also die Test-Coverage, dass halt jede Codezeile, die durchlaufen werden kann,
Pavel Mayer: auch irgendwo dann am Ende ein Ergebnis hat.
Pavel Mayer: Aber vielleicht lasse ich noch mal beim Bildsystem sozusagen die Specials,
Pavel Mayer: die vermutlich kaum jemand oder von wo ich zumindest nicht gehört habe davon,
Pavel Mayer: dass außer uns jemand so weit gegangen ist.
Pavel Mayer: Das eine ist, wir machen auch Performance-Tests, das heißt, es wird nicht nur.
Pavel Mayer: Es wird nicht nur das Ergebnis getestet, sondern wir machen während des Testens
Pavel Mayer: auch Laufzeit-Statistiken, die in den Bild mit eingehen.
Pavel Mayer: Das heißt, wenn jemand etwas einbaut, was das System an sich verlangsamt,
Pavel Mayer: dann wird das sofort sichtbar.
Pavel Mayer: Oder man sieht auch Optimierungserfolge, wenn man etwas schneller macht,
Pavel Mayer: dann wird man auch dadurch belohnt, dass man plötzlich sieht, hey,
Pavel Mayer: wow, ich habe jetzt diese oder
Pavel Mayer: jene Funktion um zehn prozent beschleunigt und
Pavel Mayer: gerade heutzutage leidet ja oft auch software
Pavel Mayer: darunter dass sie einfach
Pavel Mayer: immens ressourcen verbraucht dann wird
Pavel Mayer: hört ja dann so dinger wie leakage tests wo wir halt automatisch überprüfen
Pavel Mayer: ob memory leaks da sind aber was auch richtig also ob sich die programme quasi
Pavel Mayer: ein bisschen zu sehr am Speicherpool bedienen und nicht wieder freigeben und
Pavel Mayer: dadurch immer wachsen und wachsen und mehr Ressourcen pressen.
Pavel Mayer: Und Dokumentation ist auch noch so ein wichtiger Punkt. Und zwar eigentlich
Pavel Mayer: vermeidet man es bei XP zu viel Dokumentation zu schreiben, weil bei Dokumentation,
Pavel Mayer: die von Hand geschrieben ist, das Problem, dass sie sehr schnell veraltet,
Pavel Mayer: falsch und nicht akkurat ist.
Pavel Mayer: Das heißt, was wir auch drin haben, sind verschiedene Systeme,
Pavel Mayer: die die Dokumentation automatisch erzeugen,
Pavel Mayer: durch entsprechend sich Informationen aus dem Quellcode holen und zusätzlich
Pavel Mayer: Informationen, die man reinschreibt, extrahieren.
Pavel Mayer: Plus wir haben nun ein Tutorial für unser System und der Tutorialcode selber
Pavel Mayer: wird auch durchgetestet Und das Ergebnis wird als Screenshot gleich in eine
Pavel Mayer: entsprechende Website eingebaut.
Pavel Mayer: Das heißt, man kann sicher sein beim Tutorial, was man hat, dass der Code,
Pavel Mayer: der im Tutorial steht, auch getestet ist und das Ergebnis, was dann auf dem
Pavel Mayer: Schirm zu sehen sein soll,
Pavel Mayer: eben auch in der Dokumentation immer aktuell übereinstimmt mit dem Ergebnis,
Pavel Mayer: was man dort auch sehen soll.
Pavel Mayer: Es wird eine automatische Cross-Referenz angelegt.
Pavel Mayer: Wir haben auch selbst dokumentierende Dateiformate beispielsweise auf XML-Basis, die über XML-Schema.
Pavel Mayer: Funktionieren und man dort jederzeit auch, also,
Pavel Mayer: das endet alles, also die gesamte Dokumentation landet halt in verschiedenen
Pavel Mayer: Websites und man hat damit dann am Ende nach einem erfolgreichen Bild auch eine
Pavel Mayer: aktuelle und stimmige Dokumentation und Tutorials vom Programm,
Pavel Mayer: von den Datenformaten, von allem.
Tim Pritlove: Also kurz gesagt, es lohnt sich und es passt auch zum Extreme Programming, dass man möglichst viel,
Tim Pritlove: automatisiert, was das Testen betrifft, aber auch unter Umständen,
Tim Pritlove: was das Dokumentieren betrifft.
Tim Pritlove: Teilweise muss man das ja auch nicht alles selber programmieren.
Tim Pritlove: Also es gibt in sehr viel Programmiersprachenumgebungen mittlerweile Möglichkeiten
Tim Pritlove: aus Programmcode direkt Dokumentation zu erstellen. Also entweder direkt aus dem Code selber.
Tim Pritlove: Das hängt natürlich dann sehr von den Fähigkeiten, die ich bei mir sprach,
Tim Pritlove: aber oder doch zumindest, dass man eben bestimmte Schreibweisen für Kommentare,
Tim Pritlove: die man in den Source Code einführt,
Tim Pritlove: dass man eben bestimmte, ja, Arten und Weisen, wie man etwas dokumentiert,
Tim Pritlove: direkt in die Kommentare, Konventionen genau reinschreibt,
Tim Pritlove: um daraus eben auch automatisch Software-Dokumentation zu machen,
Tim Pritlove: die natürlich dann den großen Vorteil hat, dass man sie a, nicht nochmal schreiben,
Tim Pritlove: und prüfen muss und b, dass sie eben auch genau das reflektiert,
Tim Pritlove: wie eben der Ist-Zustand ist, also unter Umständen auch mit allen Fehlern, die man drin hat.
Tim Pritlove: Mann, Mann, Mann. Das war jetzt auf jeden Fall schon mal hier eine der längsten
Tim Pritlove: Ausgaben des Chaos Radio Express,
Tim Pritlove: aber ich bin eigentlich ganz froh, dass wir da hier auch mal in die Tiefe gegangen
Tim Pritlove: sind, weil ich denke Extreme Programming ist etwas, was eine ganze Menge Leute
Tim Pritlove: doch eine Menge Last von den Schultern nehmen kann.
Tim Pritlove: Haben wir denn jetzt noch...
Pavel Mayer: Negativpunkte?
Tim Pritlove: Das wäre ein Punkt. Ja, das können wir eigentlich vielleicht mal voranschieben,
Tim Pritlove: weil danach nochmal drauf eingehen, wie man, wie man sozusagen sich diesem Thema
Tim Pritlove: dann auch nochmal nähert, wenn man Interesse hat, das in irgendeiner Form umzusetzen.
Tim Pritlove: Hast du denn noch negative Erfahrungen gemacht? Gibt es Probleme?
Pavel Mayer: Ja, eins hatte ich schon erwähnt, nämlich, dass es diesen idealen Kunden,
Pavel Mayer: wie man ihn gerne für XP hätte, dass der selten anzutreffen ist,
Pavel Mayer: dass man dort halt Dinge finden muss.
Pavel Mayer: Ansonsten gibt es manchmal auch Anforderungen.
Pavel Mayer: Die an einen herangetragen werden, wo man gezwungen ist,
Pavel Mayer: bestimmte schwergewichtige Softwareentwicklungsprozesse zu fahren oder mit anderen
Pavel Mayer: Abteilungen zusammenzuarbeiten, die andere Prozesse haben, die halt extrem viel, also hunderte von,
Pavel Mayer: also Pflichtenheft ist zum Beispiel so eine Sache, normalerweise vermeidet man
Pavel Mayer: es oder versucht halt nicht zu viel Arbeit vorab in den Pflichtenheft zu stecken,
Pavel Mayer: aber manchmal ist es einfach eine Anforderung.
Pavel Mayer: Und da ist es uns aber ganz gut gelungen, das zu emulieren bzw.
Pavel Mayer: Diese Artefakte oder diese Dokumente, dieses Pflichtenheft genauso zu behandeln
Pavel Mayer: wie eine Programmieraufgabe und aber auch dem Kunden klarzumachen,
Pavel Mayer: dass das Schreiben des Pflichtenheftes in Konkurrenz steht,
Pavel Mayer: jetzt ressourcenmäßig mit dem Entwickeln von Features.
Pavel Mayer: Das heißt, je mehr Pflichtenheft er wünscht, umso weniger Zeit bleibt halt natürlich für die Umsetzung.
Pavel Mayer: Aber wenn er das wünscht, wenn das erforderlich ist, werden halt diese Artefakte
Pavel Mayer: eben abgebildet und das funktioniert auch ganz gut quasi mithilfe von XP andere
Pavel Mayer: Verfahren zu emulieren oder sich an andere Verfahren.
Tim Pritlove: A1 Was meinst du jetzt mit Artefakte? Was ist das für Schwierigkeit? BK'IN DR.
Pavel Mayer: MERKEL. Also Dokumente beispielsweise, also Stücke von Dokumentationen bezeichnet,
Pavel Mayer: man einfach dort als Artefakte, einfach die Ergebnisse,
Pavel Mayer: die halt zurückbleiben im Laufe der Entwicklung.
Pavel Mayer: Also Ergebnisse, so Überbleibsel, kann man sagen, der Entwicklungstätigkeit.
Pavel Mayer: Es ist auch nicht unbedingt jedermanns Sache.
Pavel Mayer: Also es gibt in seltenen Fällen einfach Leute, die nicht damit klarkommen,
Pavel Mayer: also mit dieser Ehrlichkeit und Offenheit, die sich einfach nicht die Schwierigkeiten
Pavel Mayer: damit haben, sich zu offenbaren oder mit anderen Leuten vorm Rechner zu sitzen.
Pavel Mayer: Was nicht gleichbedeutend ist, dass es sich dabei um schlechte oder unfähige
Pavel Mayer: Programmierer handelt.
Pavel Mayer: Aber eigentlich ist es eher selten, dieses Phänomen und mit der richtigen Herangehensweise,
Pavel Mayer: wenn man halt zeigt, dass eben auch Vertrauensschutz besteht,
Pavel Mayer: öffnen sich dann die meisten auch.
Pavel Mayer: Aber es gibt eben einige, wo es nicht klappt. Und dann eignet sich XP nicht
Pavel Mayer: unbedingt für jede Art von Entwicklungsaufgabe und nicht für jede Art von Teamgröße.
Pavel Mayer: Also ein 1000-Mann-Projekt jetzt,
Pavel Mayer: mit XP zu fahren, das wüsste ich nicht. Also irgendwie Toll Collect beispielsweise jetzt,
Pavel Mayer: nach XP-Prinzipien,
Pavel Mayer: zu
Pavel Mayer: fahren.
Pavel Mayer: Also so ein System könnte einfach,
Pavel Mayer: schwierig,
Pavel Mayer: werden,
Pavel Mayer: oder da gibt es zumindest noch nicht die Werkzeuge oder Verfahren.
Tim Pritlove: A. Wobei man so ein großes Projekt ja auch aufbrechen kann oder eigentlich auch zwangsläufig.
Tim Pritlove: Ich habe keine Ahnung, wie die nun ihre Softwareentwicklung da konkret organisiert haben.
Tim Pritlove: Aber im Prinzip haben sie ja genug Teilaufgaben, um das eben auch in einzelne
Tim Pritlove: Gruppen zu unterteilen, in denen sie ja dann immer noch entscheiden könnten,
Tim Pritlove: nach XP-Maßgaben vorzugehen.
Pavel Mayer: Ja allerdings ist dort so wie ich das mitbekommen habe
Pavel Mayer: bei toll kollekt das ganze extrem formalisiert gewesen
Pavel Mayer: das heißt auch einzelne teams waren komplett
Pavel Mayer: abgeschottet und dort wurde beispielsweise jede veränderung in form von change
Pavel Mayer: requests dann erst mal erfasst dann dokumentiert also ein ziemlich großer verwaltungs
Pavel Mayer: Also dafür taugt es auf jeden Fall nicht unmittelbar zu kämpfen.
Pavel Mayer: A. Und dafür, naja, also vielleicht jetzt wenn, also wird man auch Methoden
Pavel Mayer: und Verfahren entwickeln können im Laufe der Zeit, wo man das auch auf größere
Pavel Mayer: Projekte skalieren kann.
Pavel Mayer: Auf der anderen Seite, man weiß seit längerer Zeit, es gibt sowas wie eine magische
Pavel Mayer: Grenze der Planbarkeit in der Softwareentwicklung.
Pavel Mayer: Und da gibt es dieses sogenannte 6x6, also sechs Leute für sechs Monate. Das ist so.
Pavel Mayer: Etwa markiert so die tatsächlich die Grenze des Planungs Horizont was so,
Pavel Mayer: wo man wirklich zuverlässig planen kann.
Pavel Mayer: Alles was halt irgendwie mehr als sechs Leute für mehr als sechs Monate umfasst,
Pavel Mayer: ist tatsächlich nicht wirklich planbar so im Voraus, beziehungsweise da hat man halt,
Pavel Mayer: da wachsen dann letztendlich die Unsicherheiten.
Pavel Mayer: Man kann dann zwar glauben und hoffen, dass es hinkommt, aber ja die Unsicherheiten nehmen zu.
Pavel Mayer: Das weiß man aber schon seit 20, 30 Jahren hat IBM das schon festgestellt,
Pavel Mayer: dass eben dieser ja 6x6 so in
Pavel Mayer: etwa tatsächlich die Grenze der Planbarkeit dasteht. das moderne Sixpack.
Tim Pritlove: Gut, um vielleicht mal so langsam langsam zu einem
Tim Pritlove: Ende zu kommen, ich wage das ja gar nicht abzukürzen, weil das eigentlich alles
Tim Pritlove: viel zu interessant ist, aber wenn ich mich jetzt ganz konkret als Empfehlung
Tim Pritlove: hier an unsere Hörer, wenn man jetzt mal sich konkret dem Thema nähern möchte,
Tim Pritlove: was ist der beste Weg? Als erstes kauft man sich ein schlaues Buch.
Pavel Mayer: Ja, also wie gesagt diese von 99, die drei Bücher von Kent Beck sind so die
Pavel Mayer: Standardwerke, die man auf jeden Fall lesen kann,
Pavel Mayer: dann findet man natürlich im… Also Extreme Programming,
Pavel Mayer: wie heißt das eine, das Manifest?
Pavel Mayer: Ja, dann Extreme Programming Explained heißt das eine, glaube ich.
Tim Pritlove: Gibt es das auch in Deutsch? Ja, ne?
Pavel Mayer: Weiß ich gar nicht.
Tim Pritlove: Ja, gibt es. Also, oder? Moment. Moment. Ja, es gibt deutsche Übersetzungen. A2.
Pavel Mayer: Das kann gut sein. Ja, das ist sicherlich ein Einstieg.
Pavel Mayer: Dann so in Deutschland hat sich halt so Frank Westphal, ist so der deutsche XP-Guru,
Pavel Mayer: der sich dort am meisten XP verschrieben auf www.frankwestphal.de,
Pavel Mayer: findet.
Pavel Mayer: Man halt auch jede Menge, ja auch Links Westphal mit ph.
Pavel Mayer: Einfach zusammen geschrieben oder einfach nach extrem Programming googeln,
Pavel Mayer: wobei das der Klassiker ist, glaube ich, das C2 Wiki,
Pavel Mayer: wo es auch sehr viele Links gibt.
Pavel Mayer: Es gibt außerdem Mailinglisten, wo sehr viel Traffic ist, eigentlich mehr als
Pavel Mayer: man so konsumieren kann,
Pavel Mayer: aber wo sich auch extrem viele erfahrene Leute austauschen und wo man auch viel rausziehen kann.
Pavel Mayer: Aber letztendlich nur sagen anfangen Schwierigkeiten, die dabei auftreten,
Pavel Mayer: sind einmal natürlich, dass das Management davon zu überzeugen,
Pavel Mayer: dass jetzt zwei Leute immer vor dem Rechner sitzen, natürlich erst mal,
Pavel Mayer: wenn da zwei Leute ist es doppelt so teuer genau wo doch jeder irgendwie für
Pavel Mayer: sich arbeiten kann und sie doch dann das doppelte schaffen.
Tim Pritlove: Wenn der eine Holz hackt warum muss der andere noch zugucken.
Pavel Mayer: Ja eben.
Tim Pritlove: Ja aber an der Stelle wird natürlich schön deutlich und meine das das kenne
Tim Pritlove: ich auch aus eigener Erfahrung Softwareentwicklung ist wirklich ein ganz anderer
Tim Pritlove: Beruf der sich so mit herkömmlichen Beschäftigungen kaum vergleichen lässt,
Tim Pritlove: Weil man einfach auf eine bestimmte Art und Weise dort involviert sein muss
Tim Pritlove: und auch so eine Macht in Anführungsstrichen verfügt über das, was man da tut.
Tim Pritlove: Man streicht ja nicht nur eine Wand, ja, nach einer bestimmten Vorgabe und dann ist sie halt grün,
Tim Pritlove: sondern man trifft Entscheidungen, die letzten Endes für eine Vielzahl von Leuten,
Tim Pritlove: das kann sich exponentiell ausdehnen,
Tim Pritlove: in irgendeiner Form auch maßgeblich sind bis hin zur gesamten Softwareentwicklung
Tim Pritlove: in einer Firma in der nächsten Zeit und da lastet natürlich eine Menge drauf.
Tim Pritlove: In gewisser Hinsicht würde ich sagen, das sind zwei Leute eher ja noch wenig.
Pavel Mayer: B2 Ja, das andere Ding ist, dass man auch bereit sein muss,
Pavel Mayer: seine Einstellung zu ändern und seine Werte auch zu ändern, zum Beispiel das
Pavel Mayer: ganze Überstunden-Thema.
Pavel Mayer: Da galt es ja also speziell auch in der New Economy oder es gibt halt jede Menge
Pavel Mayer: War Stories, wo die leute dann 90 stunden pro woche dann heldenhaft ja es geschafft haben.
Tim Pritlove: B2. Real Programmers schlafen unter einem Tisch. A3.
Pavel Mayer: Ja so da muss man halt eher sehen, dass man da auch eine kulturelle Veränderung
Pavel Mayer: hinkriegt und sagt also über stunden also wenn es nötig wird über stunden zu fahren,
Pavel Mayer: dass das einfach ein Ergebnis schlechter und falscher Planung ist.
Pavel Mayer: Und jetzt kein Heldentum in dem Sinne. Das ist kein Wert an...
Tim Pritlove: Aber was macht ihr denn, wenn ein Programmierer Bock drauf hat?
Tim Pritlove: Länger an irgendwas zu arbeiten. Wird der dann aus der Firma gefegt?
Tim Pritlove: Es gibt auch so Momente, da kann man einfach gar nicht aufhören zu programmieren,
Tim Pritlove: weil man weiß, wenn ich das jetzt nicht irgendwie in den nächsten drei Stunden
Tim Pritlove: fertig buddiere, dann kann ich meinen Tag auch vergessen, dann denke ich sowieso nur noch dran.
Pavel Mayer: Das ist auch völlig in Ordnung. Jeder ist unterschiedlich belastbar oder der
Pavel Mayer: Sweet-Spot liegt bei jedem auch irgendwo anders. Das ist eine Sache auch des Alters.
Pavel Mayer: In einem bestimmten Alter hat man auch das Gefühl, mit neun oder zehn Stunden
Pavel Mayer: am Tag sich ganz wohl zu fühlen.
Pavel Mayer: Dann ist das halt das Ding. Aber wichtig ist, dass Überstunden eben nicht erwartet werden.
Pavel Mayer: So und dass sie nicht honoriert werden insbesondere also
Pavel Mayer: wenn jemand freiwillig gerne dort dort
Pavel Mayer: sitzt aber wichtig ist es eben keine incentives dafür zu
Pavel Mayer: schaffen das heißt überstunden normalerweise nicht
Pavel Mayer: zu vergüten sondern wenn also bei uns wenn es wirklich brennt dann werden halt
Pavel Mayer: nur in solchen fällen eben überstunden freigegeben und erfasst und dann eben
Pavel Mayer: vergütet aber im normalfall,
Pavel Mayer: sag ich mal, kann jeder zwar so lange bleiben und so lange arbeiten,
Pavel Mayer: wie er will, das ist dann aber sein Privatvergleich.
Tim Pritlove: A. Ok, aber so eine Abgabephase jetzt in zwei Tagen ist die Präsentation,
Tim Pritlove: lalala, aber wir haben insgesamt auch alle gemeinsam eingesehen,
Tim Pritlove: wir haben da noch ein Problem, dann ist es der Ausdruck.
Pavel Mayer: Dann läuft es eben so, dass ich in dem Fall sage, okay,
Pavel Mayer: es ist jetzt knapp, jeder kann jetzt so viel tun, wie er halt dazu in der Lage
Pavel Mayer: ist und mir das dann entsprechend melden und dann greift halt diese Urlaubsgeschichte.
Pavel Mayer: Aber eben, ja, das ist eine Bewusstseinsveränderung, die auch dort einkehren muss.
Tim Pritlove: Ja.
Tim Pritlove: Bewusstseinsveränderung in Form von Extreme Programming vielleicht ja auch für
Tim Pritlove: euch ein Thema oder vielleicht auch etwas, was ihr in euren Unternehmen mal ansprechen möchtet.
Tim Pritlove: Ich habe schon mit so viel, gerade jetzt dieses Wochenende wieder mit frustrierten
Tim Pritlove: Programmierern gesprochen,
Tim Pritlove: die einfach so unglücklich sind in ihren Firmen, weil irgendwie die Leute verstehen
Tim Pritlove: nichts von Softwareentwicklung, es gibt keine richtige Kommunikation,
Tim Pritlove: man redet auch nicht wirklich über die Probleme, also jetzt auch mal ganz von
Tim Pritlove: dieser eigentlichen Methodik, die einem zum besseren Programmierer werden lassen
Tim Pritlove: kann und die ganzen Sachen finde ich also gerade diese Offenheit und Ehrlichkeit, gerade in so etwas,
Tim Pritlove: wo man so mental engagiert ist, wie beim Programmieren, was ja nicht eine reine
Tim Pritlove: Engineering Tätigkeit ist.
Tim Pritlove: Man lötet nicht. Es ist wirklich, ja und auch sehr philosophisch an vielen Stellen.
Tim Pritlove: Und da ist es einfach wichtig, dass das Klima stimmt.
Tim Pritlove: Und ja, vielleicht ist Extreme Programming für euch ein Weg, das zu machen.
Tim Pritlove: Es gibt ja auch noch viele andere Methodiken, die vielleicht auch nicht so viele Probleme haben.
Pavel Mayer: Andere Archeemethoden.
Tim Pritlove: Das muss man alles auch nochmal ein bisschen hinterfragen. Vielleicht auch bei Chaos Radio Express.
Tim Pritlove: Ich bin ja immer auf der Suche nach interessanten Themen und jetzt hatten wir
Tim Pritlove: mal wieder ein interessantes Thema.
Tim Pritlove: Ich bedanke mich bei dir, Pavel, für die sehr ausführliche Darstellung dieses Themenkomplexes.
Tim Pritlove: Ist ja nicht das erste Mal, dass du hier bei Chaos Radio Express dabei bist.
Tim Pritlove: Ich hoffe auch nicht das letzte Mal.
Tim Pritlove: Und ja, für die mit Abstand längste Chaos Express Sendung entschuldige ich mich
Tim Pritlove: schon mal, aber ich denke der Inhalt war es wert.
Tim Pritlove: Wenn ihr Rückmeldungen habt...
Tim Pritlove: Feedback, Kommentare, Kritiken, alles mögliche, was euch auch einfällt.
Tim Pritlove: Ihr wisst es, Chaosradio.de.
Tim Pritlove: Ich würde jetzt auch ganz gerne nochmal die Telefonnummer fallen lassen,
Tim Pritlove: aber jetzt habe ich sie mir gerade nicht auf den Bildschirm geschrieben,
Tim Pritlove: könnt ihr auf der Webseite nachschlagen.
Tim Pritlove: Ich freue mich auch immer über Audio-Kommentare, muss aber natürlich nicht sein,
Tim Pritlove: wie es euch auch immer am besten passt.
Tim Pritlove: Könnt ihr hier einen interaktiven Podcast mit uns gestalten.
Tim Pritlove: Haben wir noch ein Schlusswort, was weißes zum Tage, zur Nacht muss man ja sagen, schon fast eins.
Pavel Mayer: B2 Für vielleicht noch das Thema Qualität. Es gibt halt in XP nur zwei Arten
Pavel Mayer: von Qualität, die man abliefert.
Pavel Mayer: Perfekt und krankhaft perfekt.
Tim Pritlove: Oha, okay, was ist besser?
Pavel Mayer: Das kommt darauf an, was das System dann am Ende leisten soll.
Pavel Mayer: Also wenn es eins ist, an dem vielleicht irgendwie Leben oder große Vermögenswerte
Pavel Mayer: hängen, dann sollte man vielleicht auf die Krankheit-perfekt-Variante,
Pavel Mayer: gehen.
Pavel Mayer: Aber ja, Qualität ist einfach das, was allen auch ein gutes Gefühl gibt,
Pavel Mayer: so stolz auf seine Arbeit sein zu können, so den Kunden glücklich zu machen,
Pavel Mayer: so, dann macht die Arbeit einfach auch Spaß.
Tim Pritlove: Okay, das war ein schönes Schlusswort. Ich hoffe, dass wir uns mit einem krankhaft-perfekten,
Tim Pritlove: Ergebnis hier an euch herangeschmiedet haben und ihr einen Podcast bekommen,
Tim Pritlove: ob ihr ihn haben wolltet. Ich sag dann mal Tschüss.
Pavel Mayer: Tschüss.
Tim Pritlove: Und wir hören uns bald wieder bei einem neuen Chaos Radio Express auf diesem RSS-Feed. Bis bald.