A Project Management Overview of XP Software Development Methodology
This paper will discuss at a high-level how software development projects are run when implementing the extreme programming (XP) methodology, and explain during which step, XP covers the Project Management Institute’s (PMI) process groups, and management knowledge areas (MKA) . After the XP process is discussed, XP’s unique way of developing code, its documentation management, and user-centric approach are explained. Since XP is written as being easy to implement, a short discussion of where the real work occurs is included, then guidance on what types projects it is best to implement XP. A brief overview of agile methodologies (AM), of which XP is but one, is included first.
The characteristics of AM are that they the value “(a) individuals and interaction over processes and tools, (b) working software over comprehensive documentation, (c) customer collaboration over contract negotiation, and (d) responding to change over following a plan”. AM concentrate on developing functionality over managing the development of functionality. The management of traditional software projects favors a well-planned approach – typically called the “waterfall approach” – documenting all project details before development starts. AM advocates creating a high level design of the whole system, then working on functionality in ascending order from highest to lowest in customer perceived business value. All AM assume requirements will change constantly so shorter development cycles are instituted to accommodate for the new or changed requirements. AM also assume close contact with the business (for the purposes of this paper, business, client, & user are used interchangeably) to answer any questions, and help resolve issues related to design, cost, and scheduling.
XP Step One – The Planning Game
The first step of an XP project encapsulates the PMI Initiating and Planning processes and is called the planning game. The planning game is a meeting in which desired functionality is discussed and analyzed via the creation of user stories . Participants are users, project and development managers, architects, and developers. Other stakeholders, from the business or development side who can add value to the design of the functionality of the proposed system, are included when needed . After business prioritizes the user stories, development estimates how many top priority user stories can be achieved within the first iteration/coding cycle (iteration velocity ). This process continues until all user stories are planned for in subsequent iterations, thus creating the project plan. At the beginning of each iteration, another planning game is instituted to get the detailed functionality for each user story to be implemented . This set of user stories/requirements does not change during the iteration. PMI MKAs touched on during the planning games are scope, time, cost, quality, communication, and risk. Time, scope, and cost are documented as an outcome of deciding what user stories are to be solved and when, and how much it will cost for each story. Quality is documented as an outcome through the creation of acceptance tests with measure(s) of quality built in to each test. True XP projects have at least one business representative sitting with the development team which aids in addressing most communication issues. Risk management is thought through in the game and if needed, a spike solution is explored to determine how risky a certain technical aspect of the user story is . A spike solution is a coding effort that is worked on just enough until a high-level design of the potential risk can be foreseen.
XP Step Two – Code Iteration
Each coding iteration is at most three weeks long. This is when the PMI Execution process occurs via iteration tracking and daily meetings. The daily meetings are called ‘stand-up...
Please join StudyMode to read the full document