Kent Beck`s Extreme Programing

© Hannes Fischer Softwareentwicklung
Kent Beck's Extreme Programing
(Hannes Fischer, Fischer Software in Stuttgart)
Jede neue Technologie hat von Anfang an Anhänger und Feinde. Vor allem, wenn sie in der Praxis
weitgehend unbekannt ist. Genauso geschieht es bei dem Entwicklungsprozeß »extreme
Progaming«, auch kurz xP genannt. Nur wird hier die Diskussion erbitterter und härter geführt als
bei anderen Themen. Warum dies so ist, soll der folgende kurze Text aufzeigen.
XP stößt alle bisher geltenden Regeln um. Angefangen bei der Projektplanung bis hin zur
Unternehmenskultur, alles wird hinterfragt, geändert und optimiert. »Kent Beck«, der Begründer
dieser neuen Technologie geht von dem, bisher nicht bewiesenen, Ansatz aus, daß späte
Korrekturen eines EDV-Systems nicht wie angenommen exponentiell teurer sind als frühe, sondern
nur in geringem Maße Mehraufwände nach sich ziehen. Daher ist es in seinen Augen sinnvoll, nur
die momentan nötigen Entwicklungen durchführen zulassen und Annahmen an die Zukunft zu
vermeiden. Kent Beck führt dabei die 80-20 Regel ein, laut der 80% der Funktionalität mit 20% der
gesamten Projektzeit realisierbar sind. Man muß nur die richtigen 80% treffen.
Kalkuliert man diese momentan eingesparten Kosten nun kaufmännisch nach, so gehen Zinsen,
Nachteile durch frühe Bindung des Kapitals und viele andere Faktoren in die Berechnung ein, die
unter dem Strich eine spätere Änderung sogar günstiger erscheinen lassen. Hierbei wurde noch
nicht die schlechte Trefferquote bei Zukunftsvoraussagen für IT Systeme einberechnet.
Werden diese Fakten berücksichtigt, und wird ein Entwicklungsprozeß so gestaltet, daß mit einer
Teilmenge der gesamten Kundenwünsche, den Stories, bereits effektiv gearbeitet werden kann.
Dazu muß der Kunde oder Auftraggeber noch nicht den gesamten Entwicklungshorizont kennen.
Die Software wird im Laufe der weiteren Versionen immer den neuen Kundenwünschen angepaßt
und so komplettiert. Es wird dabei ein Zyklus von 3 bis 4 Monaten für die erste Markteinführung
und weitere dreiwöchige Zyklen für die Folgeversionen angestrebt. Als Folge davon ist eine sehr
enge und zeitaufwendige Kommunikation zwischen den Projektpartnern nötig, wobei der Kunde
dadurch immer wieder die Chance erhält Richtungskorrekturen an der Entwicklung der Software
vorzunehmen. Ist kein Markterfolg sichtbar, kann das Projekt sehr schnell auf Eis gelegt oder
kontrolliert ganz eingestellt werden.
Auch bei der Durchführung der Entwicklungsarbeiten greifen neue Methoden. Wenn sich ein
erfahrener Entwickler die einzelnen Bestandteile des Prozeß ansieht, erkennt er vieles aus der
gängigen Praxis wieder. Am besten sind sie ihm aus bereits scheiternden Projekten bekannt. Ein
Projekt in einer angespannten Situation wird oft eher pragmatisch als konservativ durchgeführt, der
gesunde Menschenverstand gewinnt die Oberhand über jahrzehnte lang gewachsene Vorgehensweisen. Das hat Kent Beck erkannt und das Konglomerat aus verschiedenen Projekterfahrungen zu
einem kompletten Entwicklungsprozeß zusammengesetzt
Bereits bei der Verteilung der Aufgaben fangen die Änderungen an, die Teammitglieder erklären
sich selbst für Teilaufgaben, die Stories, zuständig und sind im weiteren Projektverlauf
verantwortlich für die Realisierung. Im Gegensatz zu herkömmlicher Projektarbeit wird die Arbeit
nicht delegiert, sondern übernommen. Die täglichen Arbeitseinheiten werden morgens besprochen
und sollen am frühen nachmittag in das Gesamtprojekt integriert werden. Die täglichen Aufgaben
sind so zu bemessen, daß eine Wochenarbeitszeit von 40 Stunden nicht überschritten wird. Ist das
Pensum nur mit Überstunden zu schaffen, liegen so viele Probleme vor, daß eine
Reorganisationsphase mit dem Kunden eingeschoben werden muß
Kent Beck's Extreme Programing
1
© Hannes Fischer Softwareentwicklung
Nach »Kent Beck« muß jede Zeile Code von zwei Personen gesehen werde, die logische Folge
davon ist das »Pair Programing«, bei dem zwei Entwickler die bei der morgendlichen Besprechung
festgelegte Arbeit gemeinsam durchführen. Durch die gemeinsame Kontrolle auf Fehler und die
dabei erreichte Optimierung ist die Produktivität höher als bei einzeln arbeitenden Entwicklern.
Dabei wechseln sich die aktiven Phasen (Keyboardbesitz) mit den beratenden Phasen ab. Durch die
etwas unterschiedlichen Rhythmen der Entwickler laufen Hoch- und Tiefphasen nicht gleichzeitig
ab, der Code wird immer von der Person mit der besseren momentanen Verfassung geschrieben.
Das Wissen um Codebereiche ist daher nicht auf eine Person konzentriert, sondern wird immer von
mindestens zweien getragen. Da die Zusammensetzung der Zweierteams laufend wechselt, ist durch
die bessere Kommunikation eine weite Verbreitung des Projektwissens gewährleistet. Als
Nebeneffekt, werden die Spezialkenntnisse der einzelnen Teammitglieder weitergegeben und
sorgen für eine andauernde Weiterbildung.
Kommunikation zwischen den Teammitgliedern ist ein Muß. Jederzeit kann von anderen
Teammitgliedern Hilfe angefordert werden, die zeitnah geleistet werden sollte. Durch die zentrale
Anordnung der Entwicklerarbeitsplätze wird diese enge Zusammenarbeit gefördert.
Die Relation zwischen idealer und realer Entwicklungszeit ist bei xP etwa 2,5 bis 4, das heißt eine
ideale Entwicklerstunde wird in 2,5 bis 4 Stunden geleistet. Basierend auf diesem persönlichen
Parameter werden Zeitschätzungen in idealer Entwicklerzeit auf den realen Entwicklungszeitraum
abgebildet. Dieser hohe »Load« Faktor wird den Kunden vielleicht erschrecken, aber in keinem IT
Prozeß wird effektiver gearbeitet. Der menschliche Geist ist nicht fähig lange Zeit konzentriert zu
arbeiten, und das ist bei der Entwicklung notwendig.
Für die Lösung jeder Story wird zuerst das Testszenario geschaffen. Innerhalb dieses Konstrukts
wird dann die Problemlösung entwickelt und am Ende des Tages zusammen mit dem Test in das
Gesamtprodukt integriert. Die tägliche Arbeit ist erst dann vollendet, wenn alle Tests, die bisher
entwickelt wurden ohne Fehler durchlaufen werden. Lassen sich die Fehler nicht beheben, wird auf
die vorherige Version zurückgegriffen und das Problem an einem folgenden Tag erneut
angegangen. Mit dieser Methode kann direkt bei der Integration sichergestellt werden, das die
bisher realisierten Stories fehlerfrei bleiben. Kleine Fehler in anderen Bereichen werden während
der Integration direkt beseitigt. Treten bei intensiveren Tests trotzdem noch Fehler auf, so werden
neue Testszenarien hinzugefügt, die diese Fehlersituation prüfen und der Code entsprechend
erweitert, um auch diesen Vorgaben gerecht zu werden.
Jedes Teammitglied darf alle Codestellen verändern. Der Code hat keinen Eigentümer. Werden
nach der erfolgreichen Vereinfachung oder Optimierung alle Testroutinen durchlaufen, ist die
Änderung korrekt und kann integriert werden. Wenn sich bei der Implementierung einer Story
Fehler zeigen oder abhängiger Code vereinfacht werden kann, so darf jeder im Team diese
Problemstellen beseitigen. Im schlimmsten Fall wird der neue Code, und damit ein Tag Arbeit,
weggeworfen. Dadurch werden zu komplexe oder fehlerträchtige Stellen sehr schnell erkannt,
überarbeitet und beseitigt. Ein gemeinsam entwickelter Programmierstil verbessert die Lesbarkeit
des Codes und läßt nach einer Weile den ursprünglichen Autor nicht mehr erkennen. Sollten bei der
Verfeinerung schwerwiegende Probleme auftreten oder der Code in einen Zustand der allgemeinen
Unordnung geraten, sind Phasen zur Reorganisation geplant. Dabei wird der Code regelmäßig
komplett neu strukturiert und vereinfacht. »Kent Beck« bezeichnet dies als das entropische
Verhalten von Code. Nach diesen Maßnahmen kann der normale Entwicklungsbetrieb wieder
aufgenommen werden.
Für den Auftraggeber ergeben sich Mehrbelastungen, da in regelmäßigen Abständen Steuerungsphasen geplant sind, in denen die Kundenstories nach Wichtigkeit und Kritikalität priorisiert
werden und eventuell geänderte Stories in das Projekt einfließen können. Dabei ist die Anwesenheit
von Entscheidern zwingend notwendig. Die hohe Flexibilität dieses Entwicklungsprozesses fordert
Kent Beck's Extreme Programing
2
© Hannes Fischer Softwareentwicklung
ein intensives Mitarbeiten des Kunden an der Entwicklung, am besten ist ein Mitarbeiter des
Auftraggebers kontinuierlich dem Projekt zugeordnet und übernimmt dort die Rolle des DomainExperten. Dabei beantwortet er Fragen von Entwicklern und bringt seine Kenntnisse über die
eigenen Firma in das Team mit ein.
Ein xP Team braucht Kontrolle über seine Umwelt. Die Möbel und Rechner werden den neuen
Gegebenheiten angepaßt. Laut Kent Beck sind in der ersten Projektphase der Schraubenschlüssel
und der Schraubenzieher das wichtigste Werkzeug, um die Möbel entsprechend den xP Bedürfnissen umzugestalten. In der Regel wird ein Großraumbüro verwendet, an dessen Außenseite die
privaten Schreibtische der Mitarbeiter, eventuell in Cubicles untergebracht sind. Der zentrale Raum
wird von den Entwicklerarbeitsplätzen und den Integrationsarbeitsplätzen beansprucht. Um
zwischen den einzelnen Arbeitsplätzen beweglich zu bleiben werden die rollbaren Bürostühle
wirklich genutzt, auf einen entsprechend harten Bodenbelag ist zu achten. Der beste Platz in den
Räumen soll aber für die »meeting area« reserviert bleiben, in der sich die Teammitglieder zu Besprechungen treffen. Der gesamte Bereich ist auf einfache und unkomplizierte Kommunikation
zwischen den Teammitgliedern optimiert. Alle Teammitglieder werden durch ein leichtes heben der
Stimme erreicht. Der Ruf nach Hilfe verhallt nicht so leicht.
Die Teammitglieder sollten freien Zugang zu ihren Rechnern haben. Um eine möglichst kurze »
Turn-around« Zeit zu haben, müssen die Rechner sehr schnell und effektiv untereinander vernetzt
sein. Wenn die Zeit für die Systemintegration zu groß wird, ist es nicht mehr möglich täglich zu
integrieren, die korrekte Durchführung des xP Prozeß ist nicht mehr gewährleistet. Für dieses lokale
Netz ist eine Insellösung, soweit wie möglich vom vitalen Firmennetz abgetrennt, zu favorisieren.
Lokale Optimierungen können die Weiterentwicklungen in der EDV Technik teilweise
vorwegnehmen. Auch sollte dem Spiel- und Experimentiertrieb der Entwickler nachgegeben
werden. In der zur Kommunikation bestimmten Zeit werden oft Ideen entwickelt und direkt
ausprobiert. Es muß eine Spielwiese geschaffen werden.
Ein weiterer Punkt der beachtet werden muß, ist die Änderung in der Teamkultur, die mit dem
Einsatz von extreme Programing einher geht. XP fördert das selbstständige,verantwortungsvollen
Handeln der Teammitglieder. Es provoziert zu mutigen Taten, zur Optimierung von bereits
bestehenden Code und zum Testen von neuen Ideen. Der Teamleiter wird in seiner Verantwortung
geschwächt, da sie auf das gesamte Team übergeht. Er ist hauptsächlich zur Koordination und
Abstimmung mit den Auftraggebern zuständig. Dem Team wird ein Coach zu Seite gestellt, der den
korrekten Ablauf des Prozeß überwacht und wenn nötig als Moderator eingreift. Zusätzlich nimmt
er die Schulungsaufgaben war.
Nicht alle Aufgaben sind für xP geeignet. Idealerweise sollten sich weitgehend unabhängige
Teilprojekte bilden lassen, die mit eine Personalaufwand von 6 bis 12 Entwicklern, einem
Teamleiter, einem Coach, einem Domainexperten und den Personen zur Unterstützung wie
Sekretariat, Administration usw. bearbeitet werden können. Damit scheiden Großprojekte von
vornherein aus, auch Projekte die bereits mit herkömmlichen Mitteln sehr weit geplant wurden,
sind nicht geeignet. Ein besonders interessanter Einsatz ist bei bereits gescheiterten Projekten, in
denen durch Reorganisation des Codes und Konservierung des Projektwissens ein Neuanfang unter
xP als letzter Rettungsversuch gesehen wird. In diesen Fällen hat sich innerhalb des Entwicklerteams oft eine sehr pragmatische Arbeitsweise entwickelt, die dem Arbeiten unter xP sehr nahe
kommt. Hier können überraschende Erfolge erzielt werden. Aber eine Aussage von Kent Beck
sollte nicht vergessen werden: wird der Prozess zu 80% angewandt, sind nur 20% des Vorteils
gegen andere Vorgehensweisen zu erwarten, erst 100% xP erlauben es die gesamten Vorteile
auszuschöpfen.
Wird diese neue Technologie in einem Testprojekt verwendet, sollte dieses Team von den
konservativ arbeitenden Abteilungen räumlich und personell getrennt werden. Die Arbeitsweisen
Kent Beck's Extreme Programing
3
© Hannes Fischer Softwareentwicklung
unterscheiden sich so stark voneinander, daß Reibungen nicht ausbleiben. Eine scheinbare
Bevorzugung des xP Teams entsteht durch den Wegfall von Überstunden und die intensivere
Diskussion innerhalb der Entwicklergruppe. Die persönlichen Beziehungen innerhalb des Teams
werden enger und unnötige Konflikte lassen sich leichter vermeiden, ein harmonischeres Arbeiten
wird möglich. Auch wird die Effektivität der Teammitglieder eine neue Bewertung der Einzelleistungen nach sich ziehen. Andernfalls besteht die Gefahr, das ausgebildete xP Entwickler die
Firma verlassen und in andere Projekte abwandern. Ist die Arbeit in dem Testteam erfolgreich,
können weitere Bereiche in der Entwicklung mit den bereits erprobten Mitarbeitern als Coach auf
xP umgestellt werden.
Durch all die genannten Punkte, unterscheidet sich ein xP Projekt sehr stark von der monolithisch
geprägten IT Struktur in Deutschland. Die Auftraggeber müssen erst lernen, sich wieder auf das
wesentliche zu konzentrieren. In der Softwareentwicklung heißt das, nur das notwendige codieren
und alles überflüssige zu vermeiden. Dies ist ein sehr pragmatischer Weg, der manchmal in die Irre
führt, aber bei den durch xP gesunkenen Entwicklungskosten ist dies akzeptabel, da der Gesamtaufwand geringer als bei anderen Prozessen ist. Der weggeworfenen Code enthielt ja keine unnützen Zukunftsinvestitionen, die teuer erarbeitet worden sind und nun einer anderen Vision zum
Opfer fielen. XP ist nicht die gesuchte »Silver Bullet«, aber mit xP kann das Fehlen dieses
Allheilmittels leichter verschmerzt werden. Mit xP kann Informationstechnologie schneller und
kostengünstiger genutzt werden.
Kent Beck's Extreme Programing
4

Download Report