Yes there is, but XP’s “activities” are not formally identified or described. you’ll find it headed “Define requirements with stories, written on cards” and then throughout the chapter is a mixture of process description and guidance about what use stories are and how (and by whom) they should be produced. And so it goes on, as the books describe XP under major headings; “things done” and “things produced” are described with varying degrees of prescription and detail. RUP’s apparent prescription comes from its completeness and greater formality in its systematic treatment of activities, and their inputs and outputs. XP does not lack prescription, but perhaps in the attempt to remain “lightweight”, the formality and detail are simply omitted. The detail that is present in RUP will have to be added when XP is implemented on a project. Lack of specificity is not a strength or a weakness, but you should not confuse the lack of detailed information in XP with simplicity. At some point, the people on the project will need to know what to do and at that time will need the detail.
RUP recently substituted the term “discipline” for “core workflow”. A discipline in RUP is the collection of activities (and associated concepts) producing a particular set of artifacts, which represents some important aspect or concern in software development. This usage aligns quite well with the dictionary definition of discipline as a branch of knowledge or teaching. As noted previously, RUP’s disciplines are Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment. This does not cover every aspect of what an organization or business might do when employing people to develop, deploy, operate, support, sell, market, or otherwise deal with systems that are largely software. RUP currently does not cover Systems Engineering, for example. Nor does it cover all of the requirements of some international software process standards such as ISO 15504 (which draws in aspects related to software acquisition and human resource management, for example). This is by choice: these other aspects, while important, are outside the engineering focus of the RUP. XP explicitly restricts itself even further: it includes four basic activities—coding, testing, listening, and designing (noted previously as more closely aligned with RUP disciplines) — performed using a set of practices, which requires performing other activities, which map to some of the other disciplines in RUP. XP’s practices are:
- The Planning Game—Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.
- Small Releases—Put a simple system into production quickly, then release new versions on a very short cycle.
- Metaphor—Guide all development with a simple shared story of how the whole system works.
- Simple Design—The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.
- Testing—Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.
- Refactoring—Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.
- Pair programming—All production code is written with two programmers at one machine.
- Collective ownership—Anyone can change any code anywhere in the system at any time.
- Continuous integration—Integrate and build the system many times a day, every time a task is completed.
- 40-hour week—Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.
- On-site customer—Include a real, live user on the team, available full-time to answer questions.
- Coding standards—Programmers write all code in accordance with rules emphasizing communication through the code.
Something to note on the topic of Simple Design is that “extra complexity” is a somewhat subjective term and is difficult to define, being largely in the eye of the experienced beholder.
Activities performed as a result of the practice The Planning Game, for example, will mainly map to RUP’s Project Management discipline. However, some topics are outside the scope of XP; for example, Business Modeling. Requirements elicitation is largely outside the scope of XP—the customer (on-site with the team) defines and provides the requirements (in the form of stories). Deployment of the released software is outside the scope of XP. Because of the scale and types of development it addresses, XP can deal very lightly with issues in Environment and Configuration & Change Management disciplines that the RUP covers in detail.