Words: 1929
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) [9]. 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. Agile Methodologies 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”[1].
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 [1]. 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 [3]. 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 [5]). 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 [5].
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 [4]. 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 meetings’ and everyone stands in a circle.
They include people working directly on code and the project manager only. The set agenda for each meeting covers what was completed since the last meeting, what is scheduled for the day, and what problems are anticipated so others can offer guidance. Iteration tracking consists of teams reporting on which tasks leading up to a certain piece of functionality have been completed. The team decides to report task completion on a daily, twice a week, or weekly basis [7]. XP Steps Three and Four ??? Testing & Closing
Business and development will create acceptance tests for each user story which the programmers (or the test team) will test on a daily basis with each code drop [6]. This is when the PMI Monitoring and Controlling process occurs, and is carried out by passing unit and acceptance tests before a piece of functionality is considered complete. Unit tests are created and run by each developer making sure no errors will be found during the acceptance tests. Acceptance tests show the user that each story’s functionality was developed correctly and meets agreed upon measures of quality.
During closing and for proper hand off to the maintenance team, user stories are put in proper order. Then the final high-level architecture and any special design, or code related considerations are documented. Remember, at the end of each iteration, all new features work. It is up to the user when to deploy them. The creation of and carrying out of the unit and acceptance tests is how XP addresses the PMI Quality MKA. The PMI Communication MKA is touched on during the first planning game, stand-up meetings and as a natural outcome of pair programming. Coding in XP ??? Pair Programming
Pair programming is intended to improve communication throughout the development team, develop collective code ownership, and improve maintainability [3]. The main challenge to pair programming is convincing programmers who typically work alone, to work with others on a rotating basis [3]. Some like the social interaction and skill improvement, while others find it difficult to work with other peoples’ styles and see it as a threat to their positions [3]. Documentation in XP ??? Output of Each Step XP views documentation during the normal plan-driven method as duplicating effort.
With the short development cycle in XP, documentation slows the process down. In XP, all decisions are documented as the output of each step in the process and in coordination with the user. For instance, design documentation is in the user stories, which are created with the user, and with all subsequent design decisions written as notes attached to the story [8]. If a user requires documentation produced as an output of the process, that request goes through the same process as a feature request, in a planning game with development estimating effort/cost, and the user deciding if it is truly worth the time and effort.
The main point with AM in general and XP in particular, is that “face-to-face communication, interaction, and the sharing of ideas eliminates the need for documentation that is required for the traditional models” [1, 8]. XP Is User-Centric The user is in control of the process and cost when XP is used, as she decides what goes into each iteration, and how often she wants to see a working version [2]. At the end of an iteration, acceptance tests are run and the user decides if the functionality is acceptable or not.
If not, then additional work is documented in the user story and it is scheduled for another iteration. It is added in the next iteration if the user decides it is absolutely mandatory. At the beginning of each iteration, the user is queried again to make sure the functionality about to be developed is what is indeed expected. Since the user is in control of what work is scheduled for each iteration, she is in control of the cost as well. XP ??? Is It Really That Easy? So, where is the ‘real’ work in XP? The following paragraph is this author’s opinion, based on experience.
The planning games can be recipes for disaster. Requiring many people with such diverse backgrounds and experience to agree on many points in a short period of time could be daunting. Keeping people on track and not completely designing each piece of functionality is a hard thing to do as well. One of the key points in the games to remember is that developers need to know what are the requirements, i. e. what will make the user ‘happy’, for each piece of functionality, not jump ahead to what the final technical design will be.
Since the user is integral to the creation of user stories and acceptance tests, it takes time, most likely the project manager’s or business analyst’s, to coach the user to proficiency in these matters. Convincing the user to accept shorter development cycles with less functionality can seem counter-intuitive to a person or business used to receiving the whole product delivered at once. For instance, the amount of time needed to develop all functionality on one web page, might require more than one iteration. The user is then tasked with deciding which functionality is enough for that web page to be useful.
This is potentially disastrous as the user is actually being asked to OK less functionality ??? for the short-term ??? than desired. Daily stand-up meetings are held to figure out which problems need to be resolved quickly before they slow the process down. Running the daily stand-up meeting on a daily/weekly basis requires strong leadership, quality decision-making skills, and resolve. It also must be stated that a three week cycle is for coding only. Meaning planning games, user-run acceptance tests, and code migration to production server need to be incorporated in to the schedule.
Documentation is handled in a completely different way than traditional methods with direct communication favored over change requests, addendums to design documentation, etc. It is easy for a programmer to forget to document a verbal decision with the user in code comments, or by updating a user story. XP ??? When to Use It? The final point to be made in this discussion is when to use the XP method. As with all AM, XP is best suited for projects with a tight schedule, uncertain requirements, a high degree of change, and significant risk [1].
Traditional plan driven projects are best suited for projects where “(a) Requirements are well understood, [and] (b) Frequent maintenance is expected in the future” [1]. Since XP is user-centric, it requires a technologically advanced customer and one comfortable with the software development lifecycle and processes. The customer should also be able to work effectively with the development team during planning games, as well as comfortable working with developers to resolve any questions or problems during each iteration. References: [1] V. Guntamukkala, J. H. Wen, M. J. Tarn (2006).
An empirical study of selecting software development life cycle models. Human Systems Management 25, 265-278 [2] Cusumano, M. A. (2007). Technology Strategy and Management – Extreme Programming Compared with Microsoft-Style Iterative Development. Communications of the ACM. 50 (10), 15. [3] Gittins R. , Bass J. , and Hope S. (2004). A Comparison of Software Development Process Experiences. LNCS 3092, pp. 231???236. [4] Wells D. (1999) Extreme Programming: Create A Spike Solution. http://www. extremeprogramming. org/rules/spike. html. Retrieved on Nov. 6, 2007. [5] Wake W. C. (2006).
Agile Project Management, XP Style. http://xp123. com/xplor/xp0111a/index. shtml. Retrieved on Nov. 6, 2007. [6] Wake W. C. (1999). Intro. to Extreme Programming (XP). http://xp123. com/xplor/xp9912/index. shtml. Retrieved on Nov. 6, 2007. [7] VersionOne, Inc. (??2007) Iteration Tracking. http://www. versionone. com/Resources/IterationTracking. asp. Retrieved on Nov. 6, 2007 [8] Jefferies, R. (2001) Essential XP: Documentation http://www. xprogramming. com/xpmag/expDocumentationInXp. htm. Retrieved on Nov. 7, 2007 [9] Schwalbe, K. (2007). Information Technology Project Management. Boston:Thomson Course Technology.