Wenn Du auf XP und Scrum schaust, sind die Bücher von Mike Cohn besser. Er hat gerade ein Werk zu Scrum veröffentlicht, das seine gesamte Erfahrung als Scrum Berater der letzten Jahre in einer Art Scrum Standardwerk zusammenfaßt (er ist einer der Gründerväter, deshalb ist mit "letzten Jahre" dessen Aktualität bzgl. der laufenden Diskussionen bei XP und Scrum gemeint):
Mike Cohn, Succeeding with Agile
Grundsätzlich würde ich mich von dem Gedanken lösen, daß es ein Java Projekt ist. Es geht in erster Linie um die Grundsätze moderner Software-Entwicklung, bei der Java in vielen, vielen Facetten eine Rolle spielen kann, aber nicht muß. Es ist besser die Software-Entwicklungsprozesse (XP, Scrum) so wie den Einsatz von Patterns bei der Implementierung zu betrachten, also das derzeitig allgemeingültige vom derzeitig konkreten zu trennen. Deshalb wirst Du auch kein Buch finden, wie Du es Dir vorstellst. In beiden Bereichen finden ständig Veränderungen statt. Vor ein paar Jahren hat noch jeder auf RUP gestanden. Dieses Jahr hat Scrum seine Akzeptanz gefunden und wird nächstes Jahre sicher exponentiell zulegen. Bei Java z.B. zeichnet sich ab, daß die Frontends, bisher noch in JSP/Struts oder JSF entwickelt, in Richtung Flex gehen.
Scrum in Kombination mit XP ist das derzeit beste, was wir als Werkzeug zum Managen von (Software)Projekten haben. Das ist die eine Seite der Medaille, die dafür sorgt, das der Kunde im Kontext von Zeit, Geld und Funktionsumfang ein effizientes Ergebnis erhält. Wie das Ergebnis technisch aussieht, da helfen weiterhin Architektur, Patterns und Best Practices (wie XP: Paarweises Programmieren, Test Drven Development / Continuous Integration, etc.). Ganz am Schluß kommt dann Java oder Flex oder Ruby on Rails, etc. Die übrigens alle miteinander kombiniert werden können. Reine Java-Projekte wird es in naher Zukunft nicht mehr geben, da Java nicht in allen Architekturschichten wirklich hip oder billig genug in der Produktion ist.
Es könnte sogar sein, daß wir in 10 Jahren zwar noch die JVM nutzen, aber den größten Teil der Entwicklung gar nicht mehr in Java machen. Grundsätzlich zeigt die Erfahrung: die Sprachen kommen und gehen, was bleibt sind die Konzepte dahinter (soweit nicht das Paradigma, derzeit ja Objektorientierung, nicht auch noch wechselt). In diesem Sinne würde ich auch die Einarbeitung ansetzen.
Soweit Scrum und XP verstanden sind, kann man dann im Netz nach Werkzeugen und Frameworks Ausschau halten, die die Prinzipien abbilden. Derzeit zeichnen sich im Kontext des Automatischen Testens z.B. verschiedene Strömungen ab. Da muß man für das eigene Projekt u.U. noch mal Grundsatzentscheidungen auf technischer Seite treffen.
. "State of the Art Software Development" ist halt nicht bei jedem das Selbe.
