Agile projects are similar to traditional projects. “You still must define and initiate the project, plan for the project, execute the plan, and monitor and control the results” (“ccspace.com,” 2011). How these steps are accomplished is different and therefore, the Agile project manager must adapt his approach. One agile software engineering method is Extreme Programming or XP.
XP is a collection of values, principles and practices designed to rapidly create highquality software that provides the maximum value for the customer as quickly as possible. It is called extreme or XP because it takes commonsense principles and practices to extreme levels, changing the way programmers work. It is a lightweight methodology suitable for small-tomedium-sized teams developing software that are faced with vague or rapidly changing requirements. XP began in the late 90’s. Ward Cunningham, Kent Beck, and Ron Jeffries are considered the originators. It is based on Beck’s years of software development using objectoriented programming (Brewer, 2001). “Beck and Jeffries worked together at Chrysler Corporation on the first large-scale project to use XP” (“Software development methodologies:,” n.d., para. 2). Since the publishing in 1999 of Extreme Programming Explained by Beck, more publicity has been given to XP as is evident by an increase in books, papers, conferences and web sites.
Beck (2000) gives examples of taking well-known software development practices to extremes. By using pair programming, code reviews are continual, through unit testing and functional testing, testing is continual, integration is continuous by integrating and test several times a day, and considering short iterations, XP makes the iterations very short, minutes and hours vs., weeks and months and years (Beck, 2000).
XP has with five values: communication, feedback, simplicity, courage, and respect. These values are expanded into fourteen principles and again into practices. These practices are specific things that teams can do day-to-day, while values are the fundamentals that strengthen the approach. Although many sources of information about XP list 12 key practices, these have been updated and now list 13 primary practices and 10 secondary practices (Goodpasture, 2010) described below:
Primary Practices Sit Together
Explanation The team should be co-located to allow face-to-face communication and collaboration.
The XP team is multidisciplinary, including both functional and technical experts, not just developers.
Use visuals to communicate work in-progress and where you are in the development process. These visuals may be big visible charts, a story wall, white board(s) or sticky notes. The key is to relay information without requiring a lot of time interpreting.
The diverse XP team should work at a sustainable (for a nearly indefinite period) pace, emphasizing that there be no crisis management at the end. With redundant skills on the team, members can come and go for short periods without slowing development.
Two engineers participate in one development effort, programming in teams, sitting together and jointly solving problems. This contrasts with most conventional methods were programmers work individually. Stories (User Stories) Units of customer functionality are planned in stories related in business terms by embedded customers and interpreted into design requirements by the team. Weekly Cycle Quarterly Cycle Work is completed in weekly cycles. The project depends on business cycles for approvals, funding and often the rollout schedule. For this reason, XP projects must remain aware of current business cycles.
Slack To ensure a minimum of must have requirements are delivered to production and also ensure all time boxes are finished on schedule without holding up others, build buffers into the schedule. Ten Minute Build Decompose requirements to allow short frequent builds to maximize value through testing and validation. Continuous Integration Continuously update the baseline as improvements are made to ensure everyone works with the latest design and to avoid configuration mishaps.
Test First Programming Use test-driven development (TDD): “document development requirements with test scripts… run the test, modifying the object design until it passes… refine the detail design of the object” (Goodpasture, 2010, p. 83). Incremental Design Incremental design allows the system developer to define software in stages. It is characterized as a team working in iterations, where software features grow with each iteration, and where each iteration ends in the production of a stable piece of software for use (“Software development is,” 2007). Secondary Practices Real Customer Involvement Users and customers chosen to participate should be more than just available. They must also have with real, practical, business knowledge.
Incremental Deployment Product is deployed on a speed dictated by the customer’s ability to absorb change. This also may require parallel processing of legacy software. Team Continuity Teams remain together while remaining effective; minimal turnover contributes to the stability of team metrics such as velocity. Shrinking Teams Teams are right-sized; generally, small teams are more nimble, creative, and innovative. However, teams should not be so small as to be ineffective or not allow redundancy needed to tolerate small staffing shortfalls. Root Cause Analysis Always get to the bottom of problems; use root cause analysis to point toward a process that is not working well or does not exist. Shared Code “Everyone can work on any of the product code, and often code is a product of multiple collaborations” (Goodpasture, 2010, p. 308).
Code And Tests
Permanent artifacts of the project include code, test scripts, and test conditions.
Single Code Base
Integrity of design is maintained by keeping baseline; test and development copies are temporary.
New design is integrated daily. It is only added to production daily if the customer can absorb change rapidly. “Work orders are contracted in short sequences when parameters can be stabilized” (Goodpasture, 2010, p. 308).
Negotiated Scope Contract
“XP relies on simplicity, unit testing, programming in pairs, communal ownership of code, and customer input on software to motivate code improvement during the development process” (Beck, 2000). XP uses an incremental planning approach, quickly developing an overall plan that is expected to evolve through the life of the project. By using short iterations, XP is quick and flexible. Every few weeks, organizations are able to see tangible progress on goals. Programmers and customers write tests to monitor the progress of development, allowing the system to evolve, and catch defects early. Additionally, organizations are able to change the direction of the project during development without incurring exorbitant costs.
SCRUM, another Agile methodology, is very similar the XP. Both emphasize Customer Participation, Test-Driven Development, and the use of small teams. SCRUM focuses more effort removing impediments, with daily stand-up meetings where programmers list issues impeding progress, and the Scrum Master is tasked with removing impediments. XP uses pair programming and continual testing to resolve issues. Both methods use iterations but with XP, the iterations are much shorter, 2-3 weeks vs. one month is SCRUM. The table below depicts some other similarities and differences (Shore, 2007).
XP Thinking Pair Programming Energized Work Informative Workspace Root-Cause Analysis Retrospectives Collaborating Trust Sit Together The XP Team Real Customer Involvement Ubiquitous Language Stand-Up Meetings Coding Standards Iteration Demo implied Sit Together Whole Team Real Customer Involvement implied implied implied implied Pair Programming Energized Work Informative Workspace Root-Cause Analysis implied
n/a implied implied implied implied
implied Open Working Environment Scrum Team implied n/a Daily Scrum n/a Sprint Review
Reporting Releasing “Done Done” No Bugs Version Control Ten-Minute Build Continuous Integration Collective Code Ownership Documentation Planning Vision Release Planning n/a Quarterly Cycle Incremental Deployment Daily Deployment The Planning Game Risk Management Iteration Planning Slack Stories Estimating Developing Incremental Requirements Customer Tests Test-Driven Development Refactoring Simple Design Incremental Design & Architecture Spike Solutions Performance Optimization implied implied n/a n/a implied implied Test-First Programming implied Incremental Design Incremental Design implied n/a n/a n/a n/a n/a implied n/a Weekly Cycle Slack Stories implied implied Product Backlog implied n/a implied n/a Sprints implied Backlog Items Estimating implied implied implied Ten-Minute Build Continuous Integration Shared Code implied implied n/a n/a n/a n/a n/a implied implied implied
EXTREME PROGRAMMING (XP) Exploratory Testing n/a n/a
Project Managers must consider various aspects of the project to make an appropriate selection of which methodology to use. XP is just one approach. XP’s set of practices conforms to the values and principles of Agile and its disciplined approach to software engineering, which leads to project success. Therefore, when faced with projects involving new or prototype technology, where the requirements change rapidly, or some development is required to discover unforeseen implementation problems XP is a good choice.
Beck, K. (2000). Extreme programming explained, embrace change. Addison-Wesley Professional.
Brewer, J. (2001). Jera design. Retrieved from http://www.jera.com/techinfo/xpfaq.html
ccspace.com. (2011). Retrieved from http://www.ccpace.com/resources/documents/agileprojectmanagement.pdf
Goodpasture, J. C. (2010). Project management the agile way: Making it work in the enterprise. Fort Lauderdale, FL: J. Ross Publishing, Inc.
Shore, J. (2007, DECEMBER 13). Scrum and xp practices: Cross reference. Retrieved from http://www.jamesshore.com/Blog/Scrum-XP-Practices-Cross-Reference.html
Software development is a team sport!. (2007, JULY 25). Retrieved from http://blogs.msdn.com/b/aridle/archive/2007/07/25/definition-iterative-and-incrementaldevelopment.aspx
Software development methodologies: extreme programming (xp). (n.d.). Retrieved from http://cs.smu.ca/~porter/csc/465/notes/sdm_xp.html
Sorry, but copying text is forbidden on this website. If you need this or any other sample, we can send it to you via email.
Please, specify your valid email address
Topic: Extreme Programming (Xp)
We can't stand spam as much as you doNo, thank’s. I prefer suffering on my own.
Remember that this is just a sample essay and since it might not be original, we do not recommend to submit it. However, we might edit this sample to provide you with a plagiarism-free paperEdit this sample
Courtney from Study Moose
Hi there, would you like to get such a paper? How about receiving a customized one? Check it out https://goo.gl/3TYhaX