The first edition of Extreme Programming Explained had too much emphasis on practices and none on principles. Values were mentioned, but it was like talking about the CEO and the assembly line workers in a company with no mention of middle management. Thankfully Kent Beck has rectified that situation in Extreme Programming Explained: Embrace Change 2nd ed.
First up are the values. Values are the root determinants of your behavior. There is always a root value underlying your actions when developing software. For example, say a developer decides that a UI bug is not important even though the customers clearly think it is and say so. His action may represent an underlying value that he doesn't respect non-technical people.
XP's values are communication, simplicity, feedback, courage, and respect. Astute readers will notice that this is one more than in the previous edition. These values are behind the commonly-known XP practices (pair programming, test-driven development, etc.). But values don't map directory to practices; there is an intermediary step called principles. Extensive software requirement documents are intended to communicate, but so are face-to-face meetings. They both represent the value of communication, but your domain-specific principles will determine which one you prefer.
The "new" XP has fourteen principles:
- Humanity - software is written by people, XP takes it into account
- Economics - "business" pays for software, so let's make sure to deliver business value
- Mutual benefit - don't choose solutions that may work for you but really transfer the burden to someone else
- Self-similarity - I don't know where Kent Beck was going with this one, but it sounds a lot like patterns (not just design patterns, all types of patterns)
- Improvement - start now and constantly improve rather than trying to design the perfect solution "all at once"
- Diversity - encouraging healthy conflict improves software development
- Reflection - analyze why things work and don't work, do retrospectives frequently
- Flow - like the Theory of Constraints shows us, small batch sizes (iterations) are good
- Opportunity - continuous personal growth, or a high rate of L
- Redundancy - make sure several practices address a problem, like a defense-in-depth technique against software development problems
- Failure - if at first you can't succeed, fail a couple times first, then you'll figure it out
- Quality - basically projects don't go slower by keeping quality high, they end up going faster
- Baby steps - incremental change is more likely to work than big-bang changes
- Accepted responsibility - business people may own the schedule, but programmers own their estimates
Somewhere at the intersection of the values and principles you'll find each of the XP practices, which is where we'll pick up next time.
Read: Extreme Programming Explained: 2nd ed - Part 1
Previous Topic
