CPSC225/Notes/ExtremeProgramming

Once there were no rules for creating software. This worked well for individuals, but teams ran into problems. Understanding each others code, fixing bugs, and testing required that some rules be adopted. Before long, the rules designed to help a project move along smoothly were actually hindering progress. All of the documentation took too long and wasn't always needed. Some programmers begin to cut corners, the documents are not completed, and they lose value.

= XP =

XP is a software development methodology that has a few, easy to follow rules. This ensures that rules will be followed, keeping programmers focused. Without the complicated and time consuming documents, programmers can work on the software in an exciting, dynamic environment. XP emphasizes communication and simplicity.

Planning
User stories are written. (simple requirements) Release planning creates the schedule. (technically determined iterations, created by team) Make frequent small releases. (iterations) The Project Velocity is measured. (# user stories per iteration) Iteration planning starts each iteration. (use project velocity to restructure release plan) Move people around. (knowledge is shared between more people) A stand-up meeting starts each day. (scrum) Fix XP when it breaks.

Designing
Simplicity. (fast, easy, never move ahead too quickly) Choose a system metaphor. (everyone uses common naming conventions) Use CRC cards for design sessions. (Class, Responsibilities, and Collaboration) Create spike solutions to reduce risk. (simple program dedicated to one problem) No functionality is added early. Refactor whenever and wherever possible.

Coding
The customer is always available. (a hard rule, required to fill gaps in user stories) Code must be written to agreed standards. (easier to understand) Code the unit test first. (increase understanding of problem, define solution) All production code is pair programmed. Only one pair integrates code at a time. Integrate often. (avoiding integration problems) Use collective code ownership. (everyone can work on anyone elses work, to dislodge bottlenecks) Leave optimization till last. No overtime.

Testing
All code must have unit tests. All code must pass all unit tests before it can be released. When a bug is found tests are created. (find, test, fix) Acceptance tests are run often and the score is published. (user stories->acceptance tests->scores)

= References = Kent Beck and Don Wells, www.extremeprogramming.org

= Other Links = Ward Cunningham's WikiWikiWeb page on Extreme Programming The New XP - a Ron Jeffries web-mag XProgramming.com XPORG - ExtremeProgramming.org XP articles directory Agile Alliance XP Library