CRE028 Extreme Programming

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

Hallo Tim.

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

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

Das waren also die Standardwerke zu dem Thema?

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

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

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

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

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

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

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

Bis hin zu flüchtenden Programmierern.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ja das würde dir sicherlich nicht gelingen.

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

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

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

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

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

M. Ja.

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

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

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

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

In zwei Fällen auch erstmal als Partner.

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

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

Genau.

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

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

Acht, deswegen Stand-up-Meeting.

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

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

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

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

Ja, ja.

Der Tod jedes Meetings.

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

Okay, Beteiligungszweig.

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

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

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

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

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

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

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

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

Ja, genau.

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

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

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

Genau, typischerweise.

Gibt es Fälle, wo das nicht greift?

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

Ja, genau. Wie wird das benutzt?

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

Auf eine einzelne Unit eben.

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

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

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

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

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

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

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

B2. Der Kunde, das unbekannte Wesen. A3.

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

Programmierer hassen Kunden.

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

Und was macht man da mit dem Kunden?

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

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

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

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

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

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

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

Das ist eine gute Frage.

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

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

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

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

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

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

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

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

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

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

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

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

Alle 14 Tage.

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

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

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

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

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

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

Was steht da drauf?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kurze Redezeit hat sozusagen.

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

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

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

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

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

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

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

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

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

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

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

Alle dann gleichzeitig quasi?

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

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

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

B2. Und dem Rest des Teams auch. A1.

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

Führt auch zu einer besseren Stimmung wahrscheinlich.

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

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

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

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

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

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

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

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

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

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

Negativpunkte?

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

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

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

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

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

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

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

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

Gibt es das auch in Deutsch? Ja, ne?

Weiß ich gar nicht.

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

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

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

Ja eben.

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

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

B2. Real Programmers schlafen unter einem Tisch. A3.

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

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

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

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

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

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

Andere Archeemethoden.

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

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

Oha, okay, was ist besser?

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

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

Tschüss.

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