4squareviews

In chapter 2 of John Stenbeck’s book “PMI-ACP Exam Prep PLUS Desk Reference,” he goes through the various agile project management methodologies.    The most prominent one, Scrum, was discussed in the last post.    In this post, I summarize his presentation on the second most prominent framework in terms of adoption rate and marketplace usage, that of Extreme Programming or XP.

This is a list of features of XP that one should be aware of in studying for the PMI-ACP exam.

1. XP History

The ideas of XP were created in response to two changes in software development:  1) procedural programming was beginning to be replaced by object-oriented programming, and 2) speed-to-market became a strategic growth issue and shorter product life-cycles demanded agility to handle rapidly changing customer requirements.

1. 1999–Kent Beck formalized his ideas for XP in his book Extreme Programming Explained.     This focused on technical practices that promoted skillful software development.
2. 2004–XP continued to be developed, and the second edition of Extreme Programming Explained
   expanded the list of best practices to include:   continuous code reviews, pair programming, unit testing, modularity, bottom-up design, incremental design patterns, and refactoring of all code.

2.  Five Basic Activities of XP

1. Coding–most important product of the development process is software code
2. Testing–the more flaws testing can eliminate, the more working code can be delivered
3. Listening–listening to customer needs so they can be understood well enough to discern the technical aspects of a viable solution
4. Designing–limit system complexity by creating modular designs that organize the system logic with the minimum amount of dependencies
5. Communicating–the opposite direction of 3. Listening, this is communicating to the customers the need to have system requirements for the developers to work on

3. Two Goals of XP

1. Rapidly create and distribute organizational knowledge to the development team
2. Create a unified with the customers and users of the system

4. Four XP Team Roles

1. Customer–creates and prioritizes the stories (deliverables) to be developed.   Customer can vary release date by adding or removing stories from the backlog to be delivered (this is unique to XP).
2. Programmer–estimates stories (i.e., how much effort is needed to complete a specific deliverable), writes code, usually working in pairs with another programmer, and writes tests
3. Coach (OPTIONAL)–monitors process, mentors the team on XP processes and techniques, helps team identify risks and optimization opportunities
4. Tracker (OPTIONAL)–monitors team progress and warns when schedule adjustments require redistributing of tasks.    A programmer can double as a tracker for another pair of programmers.

5. 12 Core Practices of XP

1. Planning Game–technique used to elicit new requirements from the customer, with the team then giving an estimate of the effort required to develop and implement it
2. Small releases–begin with the smallest useful feature set.   Release often, adding a few features each time.
3. Product them–each product has an underlying theme or metaphor,
4. Simple design–employ simplest possible design to get the job done
5. Test-driven development (TDD)–write a test before adding a feature
6. Refactoring–constantly improve a product’s internal design by rewriting code to make the product more reliable and adaptable
7. Pair programming–two programmers work together, the first programmer (the driver) typing in code and focusing all attention on tactical choices and completing the current programming task, while the second programmer (the observer or navigator) reviews each line of code as it is written, considering potential problems with strategic choices, as well as suggesting ideas for improvements.    They switch roles frequently.
8. Collective code ownership–everyone shares responsibility for the quality of the code, so that anyone can make necessary changes anywhere.
9. Continuous integration–all product changes to the code base are integrated at least daily.
10. Forty hour work week–if additional overtime is needed on a regular basis, this is considered a serious failure of the agile process.
11. On site customer–development team has continuous access to an on-site customer or a proxy.
12. Coding standards–everyone codes to the same standards and conventions

6.  6 Criticisms of XP

Although it is a very rigorous framework, there are some who have criticized the XP framework.  Among these criticisms are the following:

1. Stability of requirements (customer can add or remove stories from the backlog at will)
2. Lack of design specifications at the architectural of systems level
3. Lack of a document trail defining compromises made to solve user conflicts
4. Demand to have the customer/proxy on site (principle #11) is unrealistic
5. Requirement to have a unified customer viewpoint versus a single programming organization (principle #11) is unrealistic as well
6. Scalability seems to be an issue in XP framework

The next post will cover Lean Software Development, an agile framework which attempts to apply lean manufacturing principles that descend from the work of W. Edward Deming to the application area of software development.

Filed under: Uncategorized |