Einleitung

"50% Einsparung der Projektkosten durch Anwendung Agiler Verhaltensweisen", das klingt schon sehr phantastisch, finden Sie nicht auch? Aber auch interessant, oder? Aber ich werde Ihnen nicht sagen können, wie Sie "ganz sicher" dieses Ziel gleich bei Ihrem nächsten Projekt erreichen werden. Da wäre ich ja so etwas wie ein Wunder-Heiler (und das bin ich definitiv nicht!).

HALT!!!
Bitte nicht gleich wieder weg-klicken -- natürlich werde ich Ihnen zeigen, welche Agilen Praktiken und Methoden (oder besser Verhaltensweisen) sich reduzierend auf Ihre Projektkosten auswirken.

Auf der anderen Seite kenne ich aber Ihre momentane Projekt-Arbeitsweise nicht; d.h. ich kenne Ihre "Entfernung" von Agilem Verhalten nicht. Diese "Entfernung" bestimmt aber letztendlich Ihr persönliches Reduzierungs-Potential.

Also, es ist wie meistens im Leben: man bekommt nichts geschenkt! Will sagen: es liegt an Ihnen persönlich, daß Sie selbst einschätzen, inwieweit die aufgeführten Punkte in Ihrem speziellen Fall fehlen und damit ein konkretes Reduzierungs-Potential vorliegt.

Seitenanfang

Abschätzung des Reduzierungs-Potentials

Ich möchte Ihnen einen möglichen Weg vorschlagen, mit dem Sie selbst relativ einfach Ihr persönliches Reduzierungs-Potential abschätzen können. Damit haben Sie den Vorteil, daß Sie meinen Aussagen nicht "blind" vertrauen müssen und erhalten gleichzeitig eine wesentlich spezifischere Aussage als ich sie je treffen könnte.

Wenn man einmal von den reinen Investitionskosten im Projekt absieht (Hardware, Software, Infrastruktur), dann werden die Projektkosten bestimmt durch Personen, die eine bestimmte Zeit lang für das Projekt arbeiten (z.B. Analysten, Designer, Architekten, Programmierer, ... vielleicht Sie selbst). Und bei Software-Entwicklungs-Projekten liegt hier der Hauptanteil der Projektkosten. Damit konzentrieren wir uns ausschließlich auf diesen Kosten-Block.

Eine faire Annahme sollte sein, daß Sie wissen, wie sich Ihre Personal-Zeiten im Projekt auf die einzelnen Abschnitte verteilen: wieviele Personen-Tage/-Wochen/-Monate gehen in die Anforderungs-Analyse, wieviel in Design, wieviel in Projekt-Management und -Administration, etc..

Mit den folgenden Beschreibungen Agiler Praktiken und Methoden sollten Sie somit in der Lage sein zu schätzen, welche Kosten eines Ihrer tatsächlichen Projekte Sie sich gespart hätten, falls Sie in diesem Projekt die angesprochenen Praktiken und Methoden angewendet hätten.

BEVOR SIE WEITER LESEN, wählen Sie bitte aus Ihren letzten Projekten eines als Beispiel aus, an dem Sie die folgenden Praktiken bzgl. Reduktions-Potential messen können.

Seitenanfang

"Timeboxed" ... und dann ist Schluß

"Timeboxed" bedeutet: es gibt einen fixen Endtermin, der garantiert nicht verschoben wird, egal, wie viel oder wie wenig bis dahin erreicht ist.

Jeder "vernünftige" Mensch wird sofort Alarm schlagen: das kann doch nicht angehen, daß ich ein Projekt-Team bezahle, das am Ende daher kommt und sagt: "Oh, sorry! Aber leider haben wir nur die Login-Maske geschafft.".

Wer vom eher klassischen Ein-Schritt-Wasserfall-Vorgehen kommt, der mag damit im ersten Ansatz richtig liegen.

Aber es geht hier nicht darum, das ganze Projekt als eine(1) große Timebox zu sehen, sondern als eine Folge von kürzeren Timeboxes (siehe nächster Abschnitt).

Grundsätzlich gilt: wenn mein Personal nur 8 Monate an dem Projekt arbeitet und keinen Tag länger, habe ich die Projektkosten auf jeden Fall schon einmal "gedeckelt"! Fast ...

... denn die Kosten werden ja doch nach oben "davonlaufen", weil wir schwierige Phasen ja durch Überstunden kompensieren (müssen), oder?

Meine Antwort heißt: "NEIN!!!"
Kein Projekt wurde bisher durch (regelmäßige) Überstunden wirklich schneller gemacht; klar, man sieht sofort wesentlich mehr Bewegung, aber sieht man auch Fortschritt? I.d.R. werden dadurch die wirklichen Probleme im Projekt nur getarnt und verdeckt, bis sie später ganz unpassend doch wieder auftauchen.

Reduktions-Frage: wieviel Zeit (=Geld) hätten Sie bei Ihrem Beispiel-Projekt durch erreichen des ursprünglichen Endtermins gespart?

Seitenanfang

Kurze Zyklen: Iteration und Release

Wie bereits im vorherigen Abschnitt erwähnt, muß das Prinzip "Timebox" mehrmals in einem Projekt angewendet werden; je öfter, desto besser.

Das bringt uns auf die beiden Zyklen Release und Iteration.

Mit diesem Entwicklungs-Rhythmus haben Sie ein ideales Instrument, um den Charakter Ihres Projekts festzustellen: nach jeder Iteration bzw. nach jedem Release können Sie sehr einfach den tatsächlichen Fortschritt des Projekts messen. Diese Messung besteht im Zählen der erreichten zusätzlichen Funktionalität pro Iteration bzw. Release. D.h diese Messung ist "billig".

Die Meßwerte kumuliert über die Zeit in einem Diagramm ergeben in der Regel nahezu eine Gerade mit einer gewissen Steigung. Diese Steigung ist das sichtbare Merkmal des Charakters Ihres Projekts! (bitte glauben Sie mir: Sie werden nahezu eine konstante Steigung, d.h. eine Gerade sehen; die Frage bleibt nur: wie groß/klein ist die Steigung?)

Die Gerade, die Sie auf diese Weise finden, können Sie sehr einfach in die Zukunft verlängern. Tragen Sie jetzt noch in das Diagramm ein, welches Funktions-Niveau Ihr Projekt erreichen muß. Damit haben Sie auf "billige" Art und Weise eine sehr genaue Aussage darüber, ob Ihr Projekt das notwendige Ziel erreichen wird.

Diese Aussage wird bereits nach den Iterationen 1, 2 spätestens 3 genau genug sein, um ggf. Aktionen einzuleiten (falls die Steigung etwas zu gering ist) bzw. um das Projekt sogar zu stoppen (weil die Steigung definitiv viel zu gering ist), damit weiterer Schaden (=Kosten) vermieden wird.

Reduktions-Frage A: wieviel Zeit (=Geld) hätten Sie bei Ihrem Beispiel-Projekt durch das beschriebene einfachere Monitoring und Berichtswesen gespart?

Reduktions-Frage B: wieviel Zeit (=Geld) hätten Sie bei Ihrem Beispiel-Projekt gespart, weil die eigentlichen Probleme bereits zu Beginn unverdeckt sichtbar geworden wären?

Seitenanfang

Enger Kontakt: Kunde/Anwender und Entwickler

Klassischerweise kommt eine lange Reihe von Personen mit spezialisierten Aufgaben zum Einsatz, bevor die Software-Entwickler ans Werk gehen dürfen: Analysten, Designer, Architekten und Test-Planer bereiten alles bis ins Detail genau vor, um den Entwicklern genaue Arbeitspläne zu übergeben.

Die Kommunikation in dieser langen Reihe wird üblicherweise mit entsprechenden Dokumenten unterstützt (siehe z.B. [2]).

Und auch die Übergabe bzw. die Lieferung an den Kunden / die Anwender ist bereits geplant.

Schnitt ... Kamera-Schwenk ... andere Szene!

Man könnte sich aber auch vorstellen, daß Software-Entwickler und Anwender/Kunde bereits von Beginn an direkt zusammenarbeiten:

• zu Projekt-Beginn diskutieren sie gemeinsam aus der Vogel-Perspektive (10.000m Höhe) die Ziele und Anforderungen: die Anforderungen werden als sog. "User Stories" vom Kunden notiert und priorisiert, vom Entwickler aufwandsmäßig eingeordnet;
• zu Beginn einer Release-Timebox legen Entwickler und Anwender/Kunde das zu erreichende Funktions-Paket fest;
  die Kunden kennen die verfügbare Kapazität, die Entwickler kennen die Prioritäten;
• zu Beginn jeder Iterations-Timebox diskutieren Entwickler und Anwender/Kunde direkt die nächste Stufe der Details (1.000m) zu den ausgewählten "User Stories";
  keine "10m"-Details (z.B. Feld-Positionen auf dem Bildschirm), nur soviel wie nötig ist, um die Iterations-Timebox realistisch mit Arbeit zu füllen;
• während des eigentlichen "Programmierens" unterhalten sich Entwickler und Anwender/Kunde über die letzten Details (1-10m);
• die Entwickler demonstrieren direkt den Anwendern/Kunden die neuen Funktionalitäten und erhalten so auf kürzestem Weg die Rückmeldung, wann sie eine Anforderung (User Story) erfüllt haben, bzw. wo die Erwartungen liegen;
  (wie heißt es im Buch "The Pragmatic Programmer": 'Tip 57: Some things are better done than described.'; siehe [4])
• am Ende jeder Timebox stellen die Entwickler die Lieferung zusammen und führen sie (testweise) aus;

Reduktions-Frage: wieviel Zeit (=Geld) hätten Sie bei Ihrem Beispiel-Projekt gespart, falls Sie auf all die Dokumente verzichtet hätten, die vor dem eigentlichen "Programmieren" erstellt, gelesen, überarbeitet, wieder gelesen und auch irgendwann einmal genehmigt wurden?

Seitenanfang

Just-In-Time: Anforderung und Lieferung

Kostentreiber Nummer eins in (klassischen) Softwareprojekten sind wohl diese Anforderungen:

• erst werden zu Beginn des Projekts endlos viele davon "produziert" und die Kunden sind kaum noch zu bremsen;
• und dann verlangen diese Kunden während des Projekts, wenn man endlich in Ruhe programmieren könnte, ständig neue zusätzliche Anforderungen;
• und nicht genug: bestehende Anforderungen sollen einfach geändert werden;

Aber kein Problem: dafür haben wir einen detailierten Change-Control-Prozeß, der durch ausgefeilte Abläufe alle wichtigen Personen im Projekt an der Entscheidung beteiligt, was akzeptiert wird bzw, was zu bleiben hat wie ursprünglich definiert. Und -- der Kunde zahlt ja.

(Mary Poppendieck zitiert in [5] die Standish Group mit der Aussage, daß "only 20% of the Features and Functions in a Typical System are used Often or Always". Wen wundert das, werden doch die Kunden zu einem Zeitpunkt gezwungen "alle" ihre Anforderungen aufzulisten, zu dem sie in der Regel noch gar nicht wissen, was sie genau brauchen werden, bzw. wie sich die Forderungen einmal auswirken werden; und man droht ihnen auch noch, daß spätere Zusatz-Wünsche sehr sehr teuer werden ...)

Schnitt ... Kamera-Schwenk ... andere Szene!

Anwender und Kunden könnten aber auch gemeinsam mit den Software-Entwicklern lernen. D.h. die aktuell wichtigsten Anforderungen (=User Stories) werden in das nächste Release gepackt; bereits nach der ersten Iterations-Timebox sehen die Kunden, was sie bekommen werden ("Aha ... so fühlt sich das an ...") und können steuernd Rückmeldung geben; und nach einer oder auch zwei weiteren Iterations-Timeboxes ist das Release zum produktiven Einsatz fertig.

Während Release 1 real vom Kunden angewendet wird, werden bereits die nächsten wichtigen Erweiterungen (=User Stories) in das nächste Release eingebaut; der Kunde darf jederzeit noch nicht erledigte User Stories ändern, zurückziehen oder neue hinzufügen; d.h. er darf (ohne Zusatzkosten) seine frischen Erfahrungen sofort gewinnbringend in sein Projekt einbringen.

Auf diese Art und Weise wird man den oben erwähnten "20% used often or always" extrem nahe kommen; will sagen: die Software-Entwickler werden sich kaum mit den restlichen 80% beschäftigen müssen. Persönliche Erfahrung: sogar bei diesem Vorgehen werden noch User Stories werden "obsolete", d.h. sie plötzlich überholt bevor sie überhaupt umgesetzt sind; der Kunde hat durch die Anwendung der Releases gelernt, daß er solche Stories nicht (mehr) benötigt -- die Funktion wird also nicht eingebaut -- diese Kosten sind gespart!

Reduktions-Frage A: wieviel Zeit (=Geld) hätten Sie bei Ihrem Beispiel-Projekt gespart, falls Sie auf den Change-Control-Prozeß hätten verzichten können? (wieviele "Transaktionskosten" hatten Sie denn pro Change?)

Reduktions-Frage B: wieviel Zeit (=Geld) hätten Sie bei Ihrem Beispiel-Projekt gespart, falls Sie ein paar von den Funktionen, die jetzt eigentlich nicht benutzt werden, nicht hätten programmieren, testen, abnehmen, liefern, warten müssen?

Seitenanfang

Testen, Testen, Testen: was ging geht immer noch

Ab hier beginnt die Beschreibung von kosten-reduzierenden Praktiken, die eher im "Inneren" eines Software-Projekts ausgeführt und gelebt werden; bis jetzt habe ich ja von Praktiken gesprochen, die nach außen sichtbar und spürbar sind.

An erster Stelle (nicht nur bzgl. Kostensparen) steht hier für mich das Testen.

Gemeint sind hier vor allem

• Unit-Tests:
  damit werden von den Entwicklern Code Units (beginnend bei einzelnen Klassen) getestet;
  Ziel ist es festzustellen, ob der Code so reagiert, wie sich die Entwickler das vorstellen;
• Funktions-/Abnahme-Tests:
  mit diesen Tests wird dem Kunden/Anwender demonstriert, das die Software das leistet, was von ihr erwartet wird;

In beiden Fällen ist das Ziel, die Tests so zu schreiben, daß sie automatisiert ablaufen können; die Vorteile sind

• sie sind ohne Aufwand beliebig oft wiederholbar;
• es werden immer alle Tests wiederholt;
• da kein Aufwand damit verbunden ist, werden sie auch tatsächlich wiederholt;

(die Diskussion Für und Wider Automatisches Testen und wie man sich als Coach dabei verhalten kann soll anderer Stelle besprochen werden; ist in Arbeit)

Hier interessiert uns, wie man sich durch diese Art von Tests Zeit und damit Geld spart:

• vermeidet Nacharbeiten wegen Fehlersuche und -behebung; besonders bei test-getriebener Entwicklung (siehe [6]) werden Fehler meist schon vermieden;
• Fehler werden schneller gefunden, denn durch ständiges Wiederholen der automatischen Tests kann das Fehlverhalten nur durch die allerletzten Änderungen ausgelöst sein;
• fördert das zusätzliche Nachdenken über den zu schreibenden Code; d.h. der Entwickler erlangt in der Regel ein tieferes Verständnis über die Aufgabenstellung;
• besonders bei Funktions-Tests: durch sie werden oft versteckte oder bis dahin noch ausgesprochene Anforderungen/Erwartungen sichtbar (was wiederum spätere Nacharbeit spart);
• die geschriebenen Tests wirken zugleich auch als eine Art von Programm-Dokumentation; sie drücken aus, was der Entwickler von seinem Code erwartet, d.h. was dieser kann und was er nicht kann;
• und immer wieder: eine automatische Test-Suite ist ein sicher Netz, das Fehler bereits während der Entwicklung aufdeckt -- und nicht erst draußen beim Kunden!
• zu guter Letzt: gerade bei test-getriebener Entwicklung (siehe [6]) wirken Tests auch als früher Indikator für den Entwickler, wann er fertig ist; d.h. sobald der Test läuft, ist die (Teil-) Aufgabe erfüllt und man kann sich der nächsten zuwenden;

Reduktions-Frage: wieviel Zeit (=Geld) hätten Sie bei Ihrem Beispiel-Projekt gespart, falls Sie gewisse Mehr- und Nacharbeiten durch frühes, kontinuierliches und konsequentes Testen vermieden hätten?

Seitenanfang

Refactoring: ständige Verbesserung des Designs

Die Klassiker unter den Methodikern werden an dieser Stelle natürlich einwerfen: wenn ein Projekt eine vorab definierte Architektur und ein sauber durchgeplantes Design vorweisen kann, dann ist so etwas wie "Refactoring" erst gar nicht notwendig.

Das ist freilich richtig, FALLS man sich sehr(!) viel Zeit nimmt und falls sich vor allem am Projekt und speziell an den Anforderungen absolut nichts mehr ändert!

Also gut ich gebe zu: der Gewinn mittels Refactoring kann nur bei den Projekten erzielt werden, bei denen sich trotz aller Planungen und Absicherungen Änderungen ergeben und der Kurs des "Projekt-Schiffes" angepaßt werden muß.

Betrachten wir doch bitte den Vorgang des Programmierens einmal unter folgenden Gesichtspunkten:

• jede Veränderung am Code (d.h. auch jedes planmäßige Hinzufügen von Funktionalität) kann das bestehende Design der Software "beschädigen";
• solche "Beschädigungen" müssen nicht groß sein und sind es in der Regel anfangs auch nicht;
• aber mit der Zeit führen sie dazu, daß der Code komplexer als notwendig und damit schwerer verständlich wird;
• jede Erweiterung, d.h. jede Funktion, die hinzugefügt werden muß, dauert länger und länger: der Fortschritts-Geschwindigkeit im Projekt sinkt, Fehler schleichen sich ein und müssen behoben werden;
• letztendlich kann das zu Programmen führen, die funktionieren und keiner weiß mehr warum; d.h. niemand wird mehr den Mut haben, solche Programme an neue Anforderungen anzupassen;

Die Idee des Refactoring ist einfach:

• wenn jede Änderung am Code eine potentielle "Beschädigung" des Designs darstellt, dann wird sie auch als solche behandelt;
• d.h. nach jeder (kleinen) Änderung "geht der Programmierer explizit einen Schritt zurück" und untersucht kurz, ob sich nach der Änderung Ansatzpunkte für Design-Verbesserung finden lassen (siehe [7] oder [8]);
• falls ja, dann wird das entsprechende Refactoring-Schema angewendet (die meisten IDE's unterstützen hier den Entwickler);
• und nicht zu vergessen: nach dem Refactoring zeigen ihm die Unit-Tests, daß das erwartete Benehmen der Software nach außen sich nicht verändert hat;

Das hört sich jetzt nach Mehr-Kosten an. Ja und nein: es ist eine Investition! D.h. es kostet mich jetzt etwas mehr (Zeit), damit ich in den späteren Phasen des Projekts den (Zeit-) Gewinn ernten kann.

Und das schöne: mit dieser Technik verlieren die Änderungen (fast) ihren Schrecken. Verbunden mit den Automatischen Tests sorgt Refactoring dafür, wirklich Software zu erstellen, die man bezeichnen kann als

• flexibel;
• änderungsfreundlich;
• wartungsfreundlich;
• langlebig;

Reduktions-Frage: wieviel Zeit (=Geld) hätten Sie bei Ihrem Beispiel-Projekt gespart, falls Sie in der zweiten Hälfte der Laufzeit die gleiche (oder wenigstens eine ähnliche) Fortschritts-Geschwindigkeit gehabt hätten wie zu Beginn?

Seitenanfang

Automatische Builds: Lieferung auf Knopfdruck

Auch beim besten Projekt-Ablauf kommt die Stunde der Wahrheit meist ganz am Schluß: das Software-System muß geliefert und installiert werden; erst damit ist ja das Projekt-Ziel erreicht!

Oft wird man sich erst zu diesem (späten) Zeitpunkt bewußt, was "liefern" und "installieren" wirklich bedeuten; d.h. der Punkt ist zwar im Projekt-Plan enthalten, aber er wird eben erst ganz am Ende bearbeitet.

Wie sagen die "Pragmatic Programmers" so treffend: "Why wait until the night before you ship to make sure it works?" ([9], Seite 233)

Unter Zeitdruck wird eine Lieferung zusammengestellt; die Installation ist mühsam und bindet Ressourcen; man versucht zu "verbessern" und steigert eigentlich nur die Hektik; Fehler schleichen sich plötzlich ein, wo man keine erwartet hat; usw.

Wie sähe das ganze aus, wenn man dem Projekt-Team die Möglichkeit geben würde, diesen Schritt gründlich vorzubereiten und ausgiebig zu testen? (das klingt jetzt aber gar nicht noch Kosten-Reduzierung, oder? warten Sie bitte ab ...)

"Continuous Integration" heißt die XP-Regel, die hier zum Zuge kommt: während der Entwicklung (beginnend mit Tag 1!) wird ständig ein Skript ausgeführt, das ein lauffähiges System erzeugt.

Das hat gleich mehrere Auswirkungen:

• man benötigt ein Skript (in der Regel ein Ant-Skript, [10]);
• diese Skript dokumentiert sozusagen, wie das System "zusammengebaut" wird;
• die Integration läuft auf Knopfdruck: die Ausrede "keine Zeit" gibt es nicht mehr;
• den Entwicklern wird frühzeitig bewußt, was "Integration" bedeutet; das hat in der Regel Auswirkung auf ihre Arbeit: es kommt zu Wechselwirkungen zwischen Software-System und Integrations-Skript, die zu einem reibungslosen Ablauf führen;
• diese Wechselwirkungen sind in der frühen Projektphase keine Belastung, eher schon Entscheidungshilfen auf dem Weg der Software-Entwicklung;

Und von der Integration zur Lieferung ist dann nur noch ein kleiner Schritt:

• die Regel wird dahin erweitert, daß mindestens zweimal pro Woche eine Lieferung testweise zusammengestellt wird;
• auch das zwingt förmlich zu Automatisierung durch Skripts;
• die Entwickler und sonstige Beteiligte können schrittweise üben, trainieren und lernen;
• eine "richtige" Lieferung ist dann "nur noch" eine Wiederholung dessen, was im Projekt viele Male exerziert wurde;
• und auch hier gilt: wenn man sich bereits in der ersten Projekt-Woche eine Lieferung zusammenstellen muß, wird man sich Gedanken machen, wie dies "einfach" realisieren ist; das wird wieder Auswirkungen haben sowohl auf die Skripts als auch auf Software-System selbst;

Als Ergebnis sehen wir einen erprobten Ablauf zur automatischen Lieferung auf Knopfdruck. Das spart Zeit und vor allem "Nerven"; ganz zu schweigen von den Vorteilen in den späteren Phasen des Systems, wenn Erweiterungen oder Fixes zu liefern sind.

Reduktions-Frage: wieviel Zeit (=Geld) hätten Sie bei Ihrem Beispiel-Projekt gespart, falls die Lieferung und Installation auf Anhieb und ohne Zeitverzögerung geklappt hätte?

Seitenanfang

Zusammenfassung

In diesem Artikel habe ich die Auswirkungen der folgenden Praktiken/Verhaltensweisen auf die Zeit=Projektkosten beschrieben:

• Timeboxed
• Kurze Zyklen
• Enger Kontakt
• Just-In-Time
• Testen
• Refactoring
• Automatische Builds

Eigentlich erkennt man immer wieder ein ähnliches Muster:

• in kleinen, iterativen Schritten bewegt man sich im Projekt vorwärts
• immer aufgefordert den "Kopf zu heben", um zu sehen, wie es vorangeht,
• und sehr früh kleine Kurskorrekturen vorzunehmen, um es noch besser zu machen;

Allen Beteiligten (Software-Entwicklern und Kunden/Anwendern) wird ermöglicht zu lernen und einen möglichst optimalen Weg vom Start zum Ziel zu wählen; egal, ob das Gelände "eben" (viel Erfahrung vorhanden), "steil" (wenig Erfahrung) oder "steinig" (ständige Änderungen und viel Unvorhergesehenes) ist. Unterstützt wird die Konzentration auf das Wesentliche im Projekt und klein sind die Gelegenheiten für "Umwege" (d.h. "Verschwendung");

Meine persönliche Erfahrung zeigt mir, daß "50%" sehr wohl realistisch sind. Wie das in Ihrem Umfeld aussieht, das können Sie jetzt hoffentlich abschätzen. Es sollte einen Versuch wert sein, oder?

Seitenanfang

Verweise

Folgende Quellen wurden zum Teil zitiert bzw. werden empfohlen zur Vertiefung und für weiterführende Informationen:

[1]	Mary Poppendieck: Lean Software Development, An Agile Toolkit; (Addison-Wesley)
[2]	Jens Coldewey: Über Sieben Brücken mußt Du gehen;
[3]	Martin Fowler: Offshore und Agiles Vorgehen;
[4]	Andy Hunt, David Thomas: The Pragmatic Programmer; (Addison-Wesley)
[5]	Mary Poppendieck: Keynote "Make More Money", 1.Dez. 2003, XPday in London;
[6]	Frank Westphal: Test-getriebene Entwicklung;
[7]	Martin Fowler: Refactoring, Improving the Design of existing Code; (Addison-Wesley)
[8]	Martin Fowler: http://www.refactoring.com/;
[9]	Andrew Hunt / David Thomas: The Pragmatic Programmer; (Addison-Wesley)
[10]	Ant-Homepage: http://ant.apache.org/;

Seitenanfang