Extreme Pro­gramming: Soft­ware­ent­wick­lung extrem gedacht

Es gibt mitt­ler­wei­le die ver­schie­dens­ten Auswüchse von agiler Soft­ware­ent­wick­lung. Neben Scrum und Kanban wird auch immer wieder Extreme Pro­gramming be­spro­chen und an­ge­wen­det. Was ist an dieser Ent­wick­lungs­art so extrem?

Extreme Pro­gramming (XP) gilt – und das ist das na­mens­ge­ben­de Extrem – als die ra­di­kals­te Umsetzung der agilen Soft­ware­ent­wick­lung. Soll heißen: Agiler als XP ist ver­mut­lich keine andere Methode, schon gar nicht tra­di­tio­nel­le Pro­gram­mier­wei­sen. Extreme Pro­gramming grenzt sich daher bei­spiels­wei­se auch konkret vom Was­ser­fall­mo­dell ab, das laut den Erfindern von XP zahl­rei­che Probleme mit sich bringt. Mitte der 1990er-Jahre haben sich die Ent­wick­ler Kent Beck, Ward Cun­ning­ham und Ron Jeffries ent­schie­den, die klas­si­sche Ar­beits­wei­se um­zu­krem­peln und einen neuen Weg zu gehen.

Grund­sätz­lich ist Extreme Pro­gramming auf die An­for­de­run­gen des Kunden aus­ge­rich­tet. Das klingt zunächst selbst­ver­ständ­lich, doch klas­si­sche Soft­ware­ent­wick­lung kann nur in einem be­grenz­ten Maße auf Kun­den­wün­sche eingehen – schwierig wird es besonders dann, wenn sich diese Wünsche re­gel­mä­ßig ändern. XP versucht zudem die Krea­ti­vi­tät von Ent­wick­lern zu fördern und ak­zep­tiert Fehler als einen selbst­ver­ständ­li­chen Faktor bei der Arbeit.

Gleich­zei­tig geht XP – wie andere agile Methoden auch – von ite­ra­ti­ven Prozessen aus. Ein großes Projekt von Anfang bis Ende durch­zu­zie­hen und mehrere Monate zu in­ves­tie­ren, nur um am Ende fest­zu­stel­len, dass das Ergebnis nicht passt – damit bricht XP. Statt­des­sen wird in kurzen Zyklen ständig geprüft, be­spro­chen und ver­öf­fent­licht. So können Fehler schnell fest­ge­stellt und beseitigt werden.

Um den An­for­de­run­gen zu begegnen, hat man ein recht deut­li­ches Framework ent­wi­ckelt. Es geht von ver­schie­de­nen Werten, Prin­zi­pi­en und Techniken aus. Darüber hinaus werden konkrete Rollen vergeben, damit Aufgaben klar zugeteilt werden können.

Mit fünf Werten versucht XP die grund­sätz­li­che Ein­stel­lung bei der Pro­gram­mier­ar­beit zu verändern. Das Team soll als Ganzes eine bestimmte Men­ta­li­tät verfolgen, um so best­mög­lich mit­ein­an­der arbeiten zu können und ein erst­klas­si­ges Produkt zu erstellen.

Kom­mu­ni­ka­ti­on ist bei XP sowohl zwischen den Team­mit­glie­dern als auch zwischen Ent­wick­lern und Kunden wichtig. Ein per­ma­nen­ter Austausch soll dafür sorgen, dass Probleme direkt adres­siert werden können. Nur wenn alle Be­tei­lig­ten jederzeit mit­ein­an­der im Gespräch sind, können Miss­stän­de kurz­fris­tig auf­ge­deckt werden. Kom­mu­ni­ka­ti­on sorgt außerdem dafür, dass alle mit dem gleichen Wis­sens­stand arbeiten und sich dem Projekt ver­pflich­tet fühlen. Ein richtiges Gespräch vor Ort wird dabei dem Austausch von schrift­li­chen Nach­rich­ten vor­ge­zo­gen.

Bei XP strebt man immer nach der ein­fachs­ten Lösung. Das bringt gleich mehrere Vorteile mit sich: Wenn man sich nur auf die not­wen­di­gen Faktoren kon­zen­triert, hält man sich nicht mit Un­wich­ti­gem auf. Dazu gehört auch, nur die im Moment be­nö­tig­ten Features zu ent­wi­ckeln und nicht bereits für even­tu­el­le, zu­künf­ti­ge An­for­de­run­gen vor­zu­ar­bei­ten. So be­schleu­nigt das Team die Ent­wick­lung. Ein schlankes Produkt ist zudem sehr viel einfacher zu handhaben – sowohl bei der Wei­ter­ent­wick­lung als auch bei der War­tungs­ar­beit. Zu­sätz­lich er­leich­tert ein möglichst simpler Pro­gramm­code das Ver­ständ­nis, was auch im Sinne des Werts Kom­mu­ni­ka­ti­on ist: Wenn das komplette Team den Quelltext verstehen kann, fällt es leichter, sich darüber aus­zu­tau­schen.

Auch dieser Wert ist eng verbunden mit der hohen Wert­schät­zung direkter Kom­mu­ni­ka­ti­on. Der Kunde soll möglichst oft seine Kritik äußern können. Beim Extreme Pro­gramming werden al­ler­dings auch Meldungen des Systems (Logs) als Feedback behandelt. Damit man eine Feed­back­kul­tur im Sinne von XP rea­li­sie­ren kann, ist es wichtig, klein­schrit­tig zu denken: Das Team arbeitet in kurzen Zyklen, testet den Code immer wieder und stellt die Wei­ter­ent­wick­lung auch dem Kunden in kurzen Ab­schnit­ten vor. So lassen sich Än­de­run­gen und Feh­ler­be­he­bun­gen kurz­fris­tig vornehmen.

Extreme Pro­gramming versteht unter Mut die Be­reit­schaft, die Wahrheit zu sagen – selbst wenn diese eher un­an­ge­nehm ist. Gibt es Fehler im Produkt, müssen sie benannt werden, auch wenn man selbst dafür ver­ant­wort­lich ist. In einem Team, das nach XP-Werten arbeitet, spielen auch Ent­schul­di­gun­gen keine Rolle. Kein Team­mit­glied sollte versuchen, seine Be­tei­li­gung an einem Fehler klein­zu­re­den, da dies nicht ziel­för­dernd ist. Überdies versteht man unter dem Wert in diesem Kontext auch, den Mut zu haben, Or­ga­ni­sa­ti­ons­struk­tu­ren zu ändern, eigene Ar­beits­wei­sen zu hin­ter­fra­gen, Kritik an­zu­neh­men und Code u. U. auch komplett neu zu schreiben.

Damit das Team un­ter­ein­an­der har­mo­niert und aus­ge­zeich­ne­te Leis­tun­gen voll­brin­gen kann, ist ge­gen­sei­ti­ger Respekt notwendig. Dies schlägt sich auch darin nieder, dass ein Ent­wick­ler nicht durch Än­de­run­gen die Arbeit eines anderen sabotiert. Auch über das Team hinaus bis zum Kunden ist die Wert­schät­zung wichtig. Nur wenn man die Belange des anderen ernst nimmt, kann man auch an­ge­mes­sen darauf reagieren. Schließ­lich soll auch die Ge­schäfts­lei­tung dem Ent­wick­lungs­team Respekt ent­ge­gen­brin­gen und die Mit­ar­bei­ter mit den be­nö­tig­ten Kom­pe­ten­zen und Res­sour­cen aus­stat­ten.

Beim Extreme Pro­gramming stehen die Prin­zi­pi­en zwischen den Werten und Praktiken, sie verbinden damit das Abstrakte mit dem Konkreten. Die Prin­zi­pi­en leiten sich mehr oder weniger aus den zuvor de­fi­nier­ten Werten ab.

Feedback soll so früh­zei­tig wie möglich eingeholt und dann gleich­falls möglichst schnell umgesetzt werden. Dabei sollen Rück­mel­dun­gen durch das System selbst (beim Testen des Codes) binnen von Sekunden oder Minuten umgesetzt werden – statt das Feedback bei­spiels­wei­se zunächst zu sammeln. Feedback der Kunden soll man hingegen innerhalb von Tagen oder Wochen einholen und be­rück­sich­ti­gen.

Das Prinzip der Ein­fach­heit ent­spricht in der Grundlage dem gleich­na­mi­gen Wert, erhält aber kon­kre­te­re Um­set­zungs­hin­wei­se. Dafür wendet man zwei Methoden an:

• You ain’t gonna need it (YAGNI): Solange eine Funk­tio­na­li­tät nicht konkret verlangt wird, sollte sie auch nicht im­ple­men­tiert werden, um keine unnötige Arbeit durch­zu­füh­ren.
• Don’t repeat yourself (DRY): Man soll doppelte Arbeit vermeiden und auch den Code so gestalten, dass eine Änderung nicht an mehreren Stellen vor­ge­nom­men werden muss, sondern immer nur einmal.

Beim Extreme Pro­gramming werden Än­de­run­gen immer klein­schrit­tig vollzogen. Statt große Updates zur Eli­mi­nie­rung mehrerer Feh­ler­quel­len auf einmal aus­zu­spie­len, wird nur ein Problem nach dem anderen an­ge­gan­gen. Das sorgt dafür, dass das Team schneller reagiert und man die Än­de­run­gen besser nach­voll­zie­hen kann. Das Prinzip bezieht sich al­ler­dings nicht nur auf den Pro­gramm­code. Auch Än­de­run­gen im Design oder gar in der Team­struk­tur selbst sollen in kleinen, in­kre­men­tel­len Schritten von­stat­ten­ge­hen.

Da Extreme Pro­gramming den Kunden ins Zentrum stellt, werden dessen Än­de­rungs­wün­sche auch hoch bewertet. Deshalb muss das komplette Team solchen Än­de­run­gen positiv ent­ge­gen­se­hen, statt sich ihnen in den Weg zu stellen. Man soll den Kunden also sogar eher dazu anregen, Än­de­rungs­wü­sche zu äußern, statt ihm solche aus­zu­re­den.

Klingt banal, ist aber – wei­ter­ge­dacht – sehr wichtig für das Funk­tio­nie­ren von Extreme Pro­gramming: Das Team soll hoch­wer­ti­ge Arbeit leisten. Was hoch­wer­tig ist, ent­schei­det der Kunde. Um Qua­li­täts­ar­beit zu er­mög­li­chen, ist al­ler­dings das Ma­nage­ment gefragt. Wenn die Faktoren stimmen, das Team also zufrieden mit der ge­leis­te­ten Arbeit sein kann, wirkt sich das wiederum positiv auf die Moral aus.

XP-Praktiken sind ganz konkrete Hand­lungs­an­wei­sun­gen und Ar­beits­me­tho­den. Während die vor­ge­stell­ten Werte und Prin­zi­pi­en auch in anderen agilen Ar­beits­me­tho­den Anwendung finden, sind die konkreten Techniken des Extreme Pro­gramming Al­lein­stel­lungs­merk­ma­le. Auch sie haben sich über die Zeit leicht verändert und sind von Quelle zu Quelle ver­schie­den. Generell werden die Techniken in vier ver­schie­de­ne Bereiche ein­ge­teilt.

Ent­wick­ler­teams arbeiten bei Extreme Pro­gramming in äußerst kurzen Zyklen. Dies erlaubt es, den ge­schrie­be­nen Code immer wieder zu testen. Das Test-Driven De­ve­lo­p­ment geht so weit, dass Ent­wick­ler eine Test­um­ge­bung schreiben, bevor der ei­gent­li­che Quellcode erstellt wird. Code, der diesen Test nicht besteht, kann nicht wei­ter­ge­führt werden. An dieser Stelle kommt das Feedback also aus dem System selbst heraus.

Das so­ge­nann­te Planning Game ist ein Meeting, das zu Beginn jeder Ent­wick­lungs­pha­se statt­fin­det. Das Team und der Kunde finden sich zusammen, um die bisherige Arbeit zu be­spre­chen, Feedback zu geben und künftige Funk­tio­nen zu dis­ku­tie­ren. Daraufhin werden Aufgaben vergeben.

Auch die Idee eines On-Site Customers sorgt für re­gel­mä­ßi­ge Feedbacks. Im besten Fall soll we­nigs­tens ein Re­prä­sen­tant des Kunden fester Teil des Teams sein, um schnell auf Fragen antworten oder Ideen und Prio­ri­tä­ten ein­brin­gen zu können.

Das Pair Pro­gramming schließ­lich sorgt für ein Vier-Augen-Prinzip: Zwei Personen arbeiten immer gleich­zei­tig am Code. Während ein Kollege den Code schreibt, überprüft der andere den Quelltext, gibt Ver­bes­se­rungs­vor­schlä­ge und weist auf Fehler hin. Zwar ist diese Methode sehr kos­ten­in­ten­siv, da gleich zwei Mit­ar­bei­ter für eine Aufgabe ein­ge­setzt werden müssen, doch der ent­ste­hen­de Code ist ultimativ besser und sorgt für weniger Nach­ar­beit.

XP-Teams über­ar­bei­ten ihren Code ständig. Dieses Re­fac­to­ring soll dafür sorgen, den Quelltext zu ver­bes­sern sowie Wie­der­ho­lun­gen und unnötige Be­stand­tei­le zu entfernen. Ein solch op­ti­mier­ter Code ist ver­ständ­li­cher, auch für externe Leser, und zudem weniger feh­ler­an­fäl­lig.

Mit Con­ti­nuous In­te­gra­ti­on sorgen Teams beim Extreme Pro­gramming und anderen agilen Ar­beits­wei­sen für ständige In­te­gra­ti­on von neuem Code in das Ge­samt­pro­jekt. Mehrmals täglich schiebt ein Ent­wick­ler seine Arbeit in das Projekt. So werden die einzelnen Beiträge durch­gän­gig überprüft und alle Be­tei­lig­ten arbeiten mit einem aktuellen Stand.

Funk­tio­nie­ren­de Programme und Updates werden im Sinne von XP so früh wie möglich ver­öf­fent­licht. Small Releases erhöhen auch die Frequenz von Feedbacks. Fehler kann man so schneller fest­stel­len und schon mit dem nächsten Update wieder ausmerzen. Der Kunde hat fort­wäh­rend die Ge­le­gen­heit, den neuesten Stand der Ent­wick­lung direkt aus­zu­pro­bie­ren und Kritik und Vor­schlä­ge an­zu­brin­gen.

Mit einer einfachen Ge­stal­tung (Simple Design) ist der Code für alle Be­tei­lig­ten ver­ständ­lich. Alles, was den Quelltext daher unnötig komplex macht, muss entfernt werden. Für Ent­wick­ler, die nach Extreme Pro­gramming arbeiten, gilt es, jegliche Du­pli­ka­tio­nen zu vermeiden. Außerdem sollte aus dem Quelltext heraus klar­wer­den, was das Ziel des je­wei­li­gen Pro­gram­mie­rers ist.

Damit das komplette Team Hand in Hand arbeiten kann, werden grund­sätz­lich Coding-Standards fest­ge­legt. Diese Vorgaben beziehen sich auf die Her­an­ge­hens­wei­se und auf das Format. Kollegen sollen sich auch im Code der anderen zu­recht­fin­den können, und gleich­zei­tig soll immer nach­voll­zieh­bar sein, wer welche Än­de­run­gen vor­ge­nom­men hat.

Die Mög­lich­keit, gemeinsam am Code zu arbeiten, stärkt die Coll­ec­ti­ve Code Ownership: Statt darauf hin­zu­wei­sen, wer welchen Anteil – und damit auch ent­hal­te­ne Fehler – zu ver­ant­wor­ten hat, begreift man den Code als ge­mein­sa­mes Produkt. Das komplette Team trägt damit die Ver­ant­wor­tung, sowohl für Fehler als auch für Erfolge. Diese Technik lädt zudem dazu ein, an Code von anderen wei­ter­zu­ar­bei­ten und Ideen ein­zu­brin­gen.

Um das Ver­ständ­nis in Bezug auf den Quelltext noch weiter zu steigern, verwendet man bei Extreme Pro­gramming die Technik System Metaphor. Diese Praktik besteht darin, das Projekt möglichst einfach – auch unter der Ver­wen­dung von Metaphern – zu be­schrei­ben. Das bezieht sich auch auf Kon­ven­tio­nen bei der Benennung von Objekten, Klassen oder Funk­tio­nen im Code, die möglichst selbst­er­klä­rend sein müssen. Neue Mit­ar­bei­ter, die zum Projekt hin­zu­sto­ßen, sollen dieses dadurch schnell verstehen können. Auch Nicht-Pro­gram­mie­rer bekommen so einen Einblick in den Quelltext.

Das Wohl­erge­hen des Teams ist wichtig für den Erfolg des Projekts: Nur Mit­ar­bei­ter, die ausgeruht und motiviert sind, können auch hoch­wer­ti­ge Er­geb­nis­se liefern. Um dies zu ga­ran­tier­ten, schreibt Extreme Pro­gramming die 40-Stunden-Woche (40-Hour Week) vor. Über­stun­den sind um jeden Preis zu vermeiden und nur dann erlaubt, wenn in der Woche darauf keine weiteren aufgebaut werden.

Rollen dienen beim Extreme Pro­gramming dazu, Aufgaben und Kom­pe­ten­zen an alle Be­tei­lig­ten – sowohl die Ent­wick­ler als auch die Kunden – zu verteilen.

Extreme Pro­gramming agiert sehr kun­den­ori­en­tiert, was so weit geht, dass der Kunde als Teil des Teams wahr­ge­nom­men wird und zumindest ein Vertreter sich auch immer vor Ort befindet (On-Site Customer). Der Kunde stellt die An­for­de­run­gen an das Produkt, gibt al­ler­dings nur bedingt vor, wie die Ziele zu erreichen sind. Einzig die Prio­ri­sie­rung der Teil­be­rei­che fällt in seinen Kom­pe­tenz­be­reich. Dazu gehört al­ler­dings auch, die eigenen Wünsche ver­ständ­lich zu machen.

Die Rolle des Kunden kann durch eine Person oder durch ein Team ver­schie­de­ner Vertreter des Kunden aus­ge­füllt werden. In der Praxis nehmen oftmals Produkt-Manager oder auch Mit­ar­bei­ter aus dem Marketing-Bereich (immer passend zum Ziel des Projekts) die Aufgaben wahr.

Das Ent­wick­ler­team wird nicht weiter un­ter­teilt. Das heißt: Jeder, der aktiv das Produkt erstellt, fällt unter die Rolle Ent­wick­ler. Daher gehören mitunter nicht nur Pro­gram­mie­rer dazu, sondern auch andere an der Er­stel­lung be­tei­lig­te Personen – ganz nach den An­sprü­chen des Projekts. Neben der ei­gent­li­chen Ent­wick­lungs­ar­beit ist es auch Aufgabe der Ent­wick­ler, auf die Wünsche des Kunden zu reagieren: Aufwand ein­schät­zen, Zeitplan auf­stel­len, Umsetzung planen.

Zu den Rechten der Ent­wick­ler zählt, sich benötigte Hilfe zu suchen, also z. B. weitere Ka­pa­zi­tä­ten bei der Ge­schäfts­lei­tung an­zu­for­dern. Außerdem gilt laut den Techniken von XP für Ent­wick­ler die 40-Stunden-Woche. Es ist im Sinne des Projekts, dass Ent­wick­ler nicht über­ar­bei­tet sind. Dafür legt das Ent­wick­ler­team seinen Zeitplan selbst fest.

Die Rolle des Managers stellt das Bin­de­glied zwischen Ent­wick­lern und Kunden dar. Personen dieser Gruppe bringen die beiden anderen an einen Tisch und mo­de­rie­ren bei­spiels­wei­se auch das Planning Game. Dabei achtet der Manager darauf, dass vorher fest­ge­leg­te Regeln sowie all­ge­mei­ne Kon­ven­tio­nen einer kon­struk­ti­ven Dis­kus­si­on ein­ge­hal­ten werden. Der Manager übernimmt auch die Aufgabe eines Mediators, sollte dies nötig sein.

Die Rolle wird manchmal auch als Tracker be­zeich­net. Grund dafür ist, dass es zu den Aufgaben des Managers gehört, wichtige Kenn­zah­len (z. B. die Zeit, die jeder Mit­ar­bei­ter für das Projekt aufwendet) zu notieren.

Das komplette Team (inklusive Kunde) muss mit Extreme Pro­gramming umgehen können und diese Ar­beits­me­tho­de kon­se­quent umsetzen. Damit alle die gleichen Vor­stel­lun­gen von den Vorgängen haben, kann ein Coach helfen. Dieser hat mit der ei­gent­li­chen Pro­dukt­ent­wick­lung nichts zu tun, sondern steht nur als externer Helfer zur Seite – ganz ähnlich einem Scrum Master. In Vor­ge­sprä­chen können mit dieser Person die Regeln und Praktiken durch­ge­gan­gen werden. Der Coach begleitet das Team im besten Fall über die komplette Ent­wick­lungs­stre­cke, steht für Fragen zur Verfügung und hilft bei Un­klar­hei­ten.

Oftmals setzt man hierfür einen externen Dienst­leis­ter ein. Es ist aber auch möglich, dass der Coach aus dem Un­ter­neh­men kommt, dann al­ler­dings aus einem anderen Bereich. Dop­pel­rol­len (ein Ent­wick­ler übernimmt zu­sätz­lich die Rolle des Coaches) sollten vermieden werden.

Extreme Pro­gramming hat wichtige Impulse für die Art der Soft­ware­ent­wick­lung gesetzt, ist aber nicht in allen Szenarien und für alle Teams geeignet. XP geht davon aus, dass der Kunde zu Beginn des Projekts selbst noch keine genaue Vor­stel­lung vom fertigen Produkt hat. In einem solchen Fall kann die Software agil, also nach und nach geplant und ent­wi­ckelt werden.

Auf diese Weise wird zum einen der Kunde zu­frie­den­ge­stellt: Man sucht gemeinsam mit ihm nach der passenden Lösung und er ist in jeden Schritt in­vol­viert. Zum anderen können die Ent­wick­ler Projekte so umsetzen, wie sie es für an­ge­mes­sen halten, statt ständig Kom­pro­mis­se eingehen zu müssen. Kommt der Kunde al­ler­dings mit einer fertigen Pro­dukt­be­schrei­bung und einer Liste von Funk­tio­nen auf das Ent­wick­ler­team zu, lässt sich XP nur noch sehr schwer einsetzen.

Gerade das Pair Pro­gramming kann kleine Teams vor Probleme stellen, da die dafür be­nö­tig­ten Ka­pa­zi­tä­ten nicht verfügbar sind. Auch die re­gel­mä­ßi­gen Meetings mit den Kunden kosten Zeit, die wiederum nicht in die ei­gent­li­che Pro­gram­mier­ar­beit fließen kann. In einer idealen Situation spielt das keine Rolle: Das Ergebnis wird eindeutig ein besseres sein, wenn sich das Team die benötigte Zeit und die ge­wünsch­ten Res­sour­cen nehmen kann.

Doch in der Praxis werden Ent­wick­ler sowohl durch ein be­grenz­tes Budget als auch durch klare Deadlines unter Druck gesetzt. Zudem können dem Kunden das Interesse oder die Mög­lich­kei­ten fehlen, sich in dem Maße in das Projekt ein­zu­brin­gen, wie XP es verlangt.

Sind die Ge­ge­ben­hei­ten aber so, dass sie ein Vorgehen im Sinne von Extreme Pro­gramming erlauben, kann ein Team mit dieser Methode ein aus­ge­zeich­ne­tes Ergebnis liefern. Durch die ständigen Tests entstehen stabile Systeme, und das iterative Vorgehen sorgt in Kom­bi­na­ti­on mit dem mi­ni­ma­lis­ti­schen Ansatz dafür, dass auch wirklich nur Funk­tio­nen erstellt werden, die für das Projekt wichtig sind.