and more study...

[kazumicchi]

Extreme programming is a set of practices that match the 'soft' in software.  software can be thought of as a structured fluid. you can change any bit as long as it still hangs together. therefore the set of practices in XP should be just as fluid.

XP is important to project management and quality assurance. XP is a set of 12 practices designed by programmers for programmers. there is no PM role in XP.  It is team based with the responsibility for the project based on the team. There are no layers of abstraction with XP (no analysts). The customers talk directly to the programmers.  QA is built into XP.

There are four variables of software - cost, time, quality and scope.

Cost is usually fixed, but adding money can help.  If it is too little, there is a major problem, and you have to know the upfront cost - committed.

Time
-more time may increase quality and/or scope
-too little time may result in failure or poor quality
-need to be committed up front

quality
-if you sacrifice quality in any aspect, you pay for it
-high quality always

scope - less scope improves quality and time.

Varying scope controls cost, quality and time. Varying cost, quality or time is a disaster.

basic activities of XP are coding, testing, listening and designing.
has four values - communication, simplicity, feedback, courage

Communication - xp requires, encourages and fosters communication.  It is not done via paperwork (as it can be misinterpreted or unread). Customers work with programmers on site (unit testing, pair programming, task estimation)
Simplicity is not easy. The simpler the design the easier it is to communicate or change.
Feedback is necessary. Concrete feedback about a system is priceless. Optimism is an occupational hazard for programmers. Feedback works on different time scales - pair programming, estimating, planning game, releases etc. The more feedback provided, the easier it is to communicate.
Courage includes making estimates, throwing code away, refactoring (shared code) and pair programming. Courage w/o communication, simplicity and feedback is hacking.

Basic principles of XP are rapid feedback, assume simplicity, incremental change, and embracing change.

implementing XP should be fun - it should be enjoyable because XP is successful.
implementing XP is a quality process because it has measurement and testing implicit within the project - thus quality cannot be removed
four variables - scope, time, quality, cost
quality is the easiest to hide and the hardest to measure

XP calls for short release cycles, ~1-3 weeks
Task 1/2 days to 3 days (max 4 hours)
highest priority feature first

problem:system goes sour
-XP creates and maintains system of tests
-ensures a quality baseline
-system in top condition

problem:defect rate
-programmer function tests, customer writing tests, feature by features

problem:business misunderstood
-XP customer integral part of team
-learning by customer
-change is relatively easy

problem:business changes
-XP shortens release cycle
-changes incorporated at each release
-change is embraced

problem:false feature rich
-XP insists only highest priority tasks are addressed

problem:staff turnover
-XP programmers accept responsibility
-XP programmers make own estimates
-XP concentrates on communication
-XP brings on board new staff via pair programming
-XP has shared ownership of code

benefits of xp
-customer made all product related decisions
-always had a choice about how to deal with challenges
-in control of scope/timeline tradeoffs
-no surprises when software was delivered
-process was predictable (all subsequent releases were on time)
-customer could change their mind
-at many stages, the releases could be cut and shipped
-the relationship b/w customer and developer changed from adversarial to cooperative
-everyone on team knows what's going on