Extreme programming modified: embrace requirements engineering practices

TLDR

Extreme Programming is a popular agile methodology, yet its reliance on code and tests, single customer representative assumption, and limited documentation create maintenance issues and a narrow system view. The study evaluates Extreme Programming against the Capability Maturity Model and the Sommerville‑Sawyer model. The authors suggest adding documented requirements, adapting the planning game to accommodate multiple customer representatives, and establishing a broader system perspective early in the project lifecycle.

Abstract

Extreme programming (XP) is an agile (lightweight) software development methodology and it becomes more and more popular. XP proposes many interesting practices, but it also has some weaknesses. From the software engineering point of view the most important issues are: maintenance problems resulting from very limited documentation (XP relies on code and test cases only), and lack of wider perspective of a system to be built. Moreover, XP assumes that there is only one customer representative. In many cases there are several representatives (each one with his own view of the system and different priorities) and then some XP practices should be modified. In the paper we assess XP from two points of view: the capability maturity model and the Sommerville-Sawyer model (1997). We also propose how to introduce documented requirements to XP, how to modify the planning game to allow many customer representatives and how to get a wider perspective of a system to be built at the beginning of the project lifecycle.