eXtreme Programming (XP) lasst sich systematisch so anpassen, dass es fur komplexe und lang laufende Projekte anwendbar wird. Dadurch konnen die positiven Eigenschaften des XP auch fur grose Projekte eingesetzt werden, ohne die Kontrolle uber die Projekte zu verlieren.

Professionelle Software-Entwicklungs-Projekte setzen verstärkt Open-Source-Software ein. Durch ihre spezifischen Eigenschaften bietet Open-Source-Software verschiedene Vorteile für die Software-Entwicklung. Dieser Beitrag stellt diese Eigenschaften vor und leitet daraus Vorteile aber auch Risiken des Open-Source-Einsatzes ab. Auf Basis umfangreicher Projekterfahrungen zeigen die Autoren Strategien und Architektur-Richtlinien auf und illustrieren diese anhand von Projektbeispielen.

Using methodological extensions to adapt extreme programming (XP) for major projects offers a high security and reliability without limiting software development's advantages. The authors describe their use of XP extensions that focus on development's planning and controlling aspects, demonstrating that a suitably adapted agile development process is applicable to long-term, large-system projects.

Agile und leichtgewichtige Methoden wie eXtreme Programming (XP, siehe [Beck2000], [LRW2002]), SCRUM (siehe [SB2001]), Crystal Clear (siehe [Cockburn2002]) oder auch Feature Driven Development (FDD, siehe [Palmer2002]) sind heute in aller Munde. Sie versprechen reduzierte Entwicklungskosten bei hoher Qualitat. Dieser Beitrag stellt einige Thesen zum Verhaltnis agiler Methoden zum Requirements Engineering (RE) vor und will damit zur Diskussion einladen. Die Thesen basieren auf den Projekterfahrungen des Autors.

From the Publisher: Real-life experience of eXtreme Programming from XP programmers. eXtreme Programming (XP) is a hot new development methodology for building software systems quickly without sacrificing quality. Authors Lippert, Wolf and Rook have three years' experience of working on professional XP projects. The projects range from application via prototype to framework development and cover project sizes from one person month to more than 400 person months. Until now XP has been described in outline by those promoting its advantages, this book provides objective examples of how it can be used in practice. An objective assessment of XP, grounded in real world experience, and not written by those championing this methodInvaluable combination of theory and practiceCovers advanced topics such as project organization, team roles and integrating legacy systems

Publisher UPGRADE is published on behalf of CEPIS (Council of European Professional Informatics Societies, http://www.cepis.org/) by Novática (http://www.ati.es/novatica/) and Informatik/Informatique (http://www.svifsi.ch/revue/) Chief Editors François Louis Nicolet, Zurich Rafael Fernández Calvo, Madrid Editorial Board Prof. Wolffried Stucky, CEPIS President Gloria Nistal Rosique and Rafael Fernández Calvo, ATI Prof. Carl August Zehnder and François Louis Nicolet, SVI/FSI English Editors: Mike Andersson, Richard Butchart, David Cash, Arthur Cook, Tracey Darch, Laura Davies, Nick Dunn, Rodney Fennemore, Hilary Green Roger Harris, Michael Hird, Jim Holder, Alasdair MacLeod, Pat Moody, Adam David Moss, Phil Parkin, Brian Robson Cover page designed by Antonio Crespo Foix, © ATI 2002 Layout: Pascale Schürmann E-mail addresses for editorial correspondence: and E-mail address for advertising correspondence: Copyright © Novática and Informatik/Informatique. All rights reserved. Abstracting is permitted with credit to the source. For copying, reprint, or republication permission, write to the editors. The opinions expressed by the authors are their exclusive responsibility. The European Online Magazine for the IT Professional http://www.upgrade-cepis.org Vol. III, No. 2, April 2002

XP ist eines der heiß diskutierten Themen der letzten zwei Jahre. Das Tutorial zeigt ausgehend von der Projekterfahrung der Referenten, wie XP erfolgreich eingesetzt werden kann. Dabei wird insbesondere auf sinnvolle Adaptionen für komplexe Projektsituationen eingegangen. Komplexe Projektsituationen treten z.B. dann auf, wenn eine Reihe ganz unterschiedlicher Arbeitsplätze durch das neu entwickelte System unterstützt werden sollen, wenn der Anwendungsbereich selbst komplex ist, wenn der Zeitdruck extrem hoch wird etc. 1 Kurzer Überblick über XP Zu Beginn des Tutorials steht ein kurzer Überblick über eXtreme Programming. Kent Beck stellt in seinem für eXtreme Programming grundlegenden Buch [Be99] seine Ideen für eine leichtgewichtige Art der Softwareentwicklung vor. Statt einem schweren und statischen Methodenapparat sollen Software-Entwicklungsteams ihren Entwicklungsprozess selbst steuern und flexibel anpassen, statt „Big Upfront Design“ empfiehlt Beck: „Do the simplest thing that could possibly work“. Zur Orientierung stellt er vier Werte in den Mittelpunkt und beschreibt ausführlich zwölf Techniken, die eXtreme Programming ausmachen: • Die Werte: Kommunikation, Einfachheit, Feedback und Mut • Die Techniken: Planungsspiel, Short Releases, Metapher, Einfaches Design, Testen, Refactoring, Pair Programming, Collective Ownership, 40-Stunden-Woche, Continuous Integration, On-Site Customer, Coding Standards. In der eXtreme-Programming-Community wird immer wieder der Zusammenhang der genannten Werte und Techniken hervorgehoben, dem Gedanken folgend, dass diese Bausteine als Ganzes viel mehr als die Summe der Teile ergeben. Es wird dabei aber als ausdrücklich sinnvoll angesehen, eXtreme Programming evtl. nur teilweise einzuführen. eXtreme Programming ist demnach flexibel einsetzbar und kann auf spezifische Projekanforderungen hin angepasst werden.

We describe the concept of refactoring tags which supports XP for framework development - especially simple design, refactoring and short releases. A set of four refactoring tags (similar to Java meta tags) reify modifications done to the framework in its source code. Migration tools interpret the refactoring tags and support application developers when migrating to a new framework version with a changed API.

We started using the XP techniques for designing and implementing the JWAM framework since the beginning of 1999. With the help of these techniques we succeeded in evolving the JWAM framework from a „student’s project“ into a real-life professional application framework which is used in several commercial applications today. In this paper we report on our experiences with XP in general and with XP for framework development in particular for more than one year. The following sections describe how we use the XP techniques and how we have adapted them to our specific programming domain – the development of application frameworks for large-scale application software. This paper also discusses some of the problems encountered during XP and their potential solutions. History of JWAM JWAM is a Java framework supporting the development of large scale interactive software systems according to the tools & materials approach . T e foundation of the JWAM framework was laid in 1997 by research assistants and students of the Software Engineering Group at the University of Hamburg and it was a pure University project. We used it as a sandbox for gaining some experience with new concepts and with framework development in general. We also used it for teaching purposes. In 1998 we felt that JWAM had the potential for professional software development. We thought it to be a solid technical base for large-scale software development giving support to developers with a proven design. Important steps to commercialize the framework were a redesign of parts of the framework and the explicit definition of a framework development process and its management. Early in 1999 we began to use XP techniques in a team of seven framework developers and redesigned parts of the framework. First, we used refactoring (cf. [Opdyke92], [Fowler99]), pair programming (cf. [Beck99]) and test classes ([Firesmith96], [Junit99]). Then we added the planning game and continuos integration (cf. [Beck99]). The redesign of the framework had one major goal: simplifying the framework. With this goal in mind we refactored the framework and introduced a separation of the framework core from framework components based on this core. Before we began refactoring there was one framework compound with more than 600 classes. After refactoring we had a framework kernel with about 100 classes plus test classes. The rest of the original classes were divided into separate framework components or had become useless during the refactoring process. 1 WAM is the German acronym for tools, automatons, materials. More information about WAM can be found in [RiehleZüllighoven95]. The framework can be downloaded from [JWAM]. Now, in January 2000 three application projects use JWAM. Two of these projects have already shipped operational client/server applications based on JWAM. We use all of the XP techniques and we were quite successful in introducing them to our team. Of course we had to adapt some of the techniques to our situation. Currently, we further develop the JWAM framework in pairs only and nearly every framework class has a test class. If you want to know more about the JWAM framework take a look at [JWAM]. The Setting The JWAM framework is both rooted in the university and has its commercial context. Within the university we use JWAM for teaching and as a sandbox for trying out new concepts. Within the commercial context we have founded the Apcon Workplace Solutions Ltd. The company uses JWAM for professional application development. This combination of an academic and industrial setting gives us the chance to use leading edge concepts in commercial projects very fast. On the other hand the requirements of the industrial projects trigger the research activities at the university. Figure 1 shows the business use case for the development and usage of the JWAM framework. Note that the different actors may map to the same persons.

XP has one weakness when it comes to complex application domains or difficult situations at the customer’s organization: the customer role does not reflect the different interests, skills and forces with which we are confronted in devel opment projects. We propose splitting the customer role into a user and a client role. The user role is concerned with domain knowledge; the client role defines the strategic or business goals of a development project and controls its financial resources. It is the developers’ task to integrate users and clients into a project that builds a system according to the users’ requirements, while at the same time attain the goals set by the client. We present document types from the Tools&Materials approach (cf. [6]) which help developers to integrate users and clients into a software project. All document types have been used successfully in a number of industrial projects together with the well-known XP practices.

One problem with the XP development process is its fragility. If developers use the XP techniques in an unintended way or not at all, the XP process is likely to break down: The misused techniques affect the other XP techniques in a negative way, breaking the whole process. We believe that it is possible to stabilize the XP process using specialized artifacts to reify the XP techniques. We discuss the reification of the XP technique Continuous Integration using the JWAM IntegrationServer as an example. We present our experience with this tool and analyze its effects on the other XP techniques.