XP

Extreme Programming:

Description	Site
XP Sites	http://www.extremeprogramming.com http://www.c2.com
Reference Material	Extreme Programming Installed Explains the core principles of Extreme Programming and details each step of the development cycle. Teaches readers how to work with an on-site customer, define requirements with user stories, estimate the time and cost of each story, and perform constant integration and frequent iterations. Softcover. DLC: Computer software--Development Extreme Programming Explained The book intends to describe what XP is, its guiding principles, and how it works. Simply written, the book avoids case studies and concrete details in demonstrating the efficacy of XP. Instead, it demonstrates how 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. As the author notes, these principles are not new, but when they're combined their synergy fosters a new and arguably better way to build and maintain software. Throughout the book, the author presents and explains these principles, such as "rapid feedback" and "play to win," which form the basis of XP. Planning Extreme Programming The Extreme Programming (XP) paradigm has developers doing things like programming in pairs, writing tests to verify all code, and continuously refactoring designs for improved performance. Written by two of its inventors, Planning Extreme Programming shows you how to implement XP by using a simple, effective process. This remarkably short (yet remarkably useful) title will give any XP manager or programmer a perspective on delivering software that meets the needs of customers better. Extreme Programming in Practice (not out yet) Extreme Programming Examined (not out yet)

XP Planning (Martin Fowler)

Summary:
Idea is to plan, not once, but continue the planning throughout the project. Develop an initial track and be sure you stay on that track or any (agreed upon) adjustmens made to that track. The customer has a big role here and is involved in making business decisions. Ideally the customer "knows the domain and knows they're needs. Reality shows this is not always the case, requiring the developer to engage in high level business consulting by taking part in identifying the customer's needs. Success is achieved when the true customer is identified and has the support of the decision maker in the organization! The key elements in the planning phase are expressing features as "user stories" and using those feature to define a release plan. The concept of Stand-Up meetings are used to stay focused and efficient. Utilize the MVC (Model-View-Controller) principle during planning. Where developing the model is the first phase consisting of modeling the customer's needs (e.g. the actual content and functionality). View and Control would come into play later (e.g. developing the UI and implementation details). The 4 variables involved in the planning process are Cost, Quality, Time, and Scope!.

It draws from certain Business Management philosophies that helped make manufacturing companies successful. XP integrates these "best business practices" into software development. Concepts like customer focused, market oriented...etc., where the focus is always on the customer. You let the customer decide on feature/functionality. Further, you also let the customer control the priority of these features and give them responsibility/authority to change requirements. Our job is to provide them with some basic guidelines (story cards and estimates). The reasons TQM was successful in manufacturing,
are also applicapable here. People have a guideline, some guideline that is very flexible and adaptable. Its not very rigid and does not require much overhead.

Keys to success:
-Customer speaks with one voice, defines / prioritizes user stories, and decides the business value
-Developers speak with one voice, provide estimates (ideal time), provide measureable feedback
-Clear role definition (customers and developers)
-Goals are clearly identified and agreed upon by the customer/decision maker
-Balancing Power (Business decisions vs Technical decisions)
   1. Business decisions made by the customer (Scope, Dates, Priority)
   2. Technical decisions made by developers (Estimates on feature or "user stories")
-Keep dates!
-Pair programming must be done with at least one experienced developerl. Done at the task level.
-Track progress with a simple spreadsheet
-Visual Graphs: used for status "...you can't improve what you don't measure"
  Examples include bug density, acceptance tests defined and passed
-On time delivery!

Terminology:
-User Stories: Unit of functionality in XP. 1~2 sentances explaining an agreed upon feature by customer
  and developer. Stories are written throughout the project. Idea is to use individual index cards for each
  story so that they can be visually arranged and rearranged.
   1. Usually 6 stories per iteration
   2. Estimates include unit testing
   3. Stories are (mostly) independent and testable (test areed upon by both customer / developer)
   4. Components: Name, Story, Estimate
   5. Stories are ordered based on business value (defined by customer)
   6. Stories are later broken down into tasks and each task has a unit test
-Ideal Time: Time is measured in "ideal effort" usually "ideal weeks or days." Ideal effort is the unit of
  effort and doesn't account for pair programming.
-Iterations Planning:
   1. Iterations contain a small group of stories along with completed unit tests (according to customer).        This serves to close the loop incrementally.
   2. Performance data is applied to user stories, tracking is done at the task level in ideal time
   3. Each iteration contains (stories and acceptance tests, the plan, and report with confirmation)
-Release Planning:
   1. Contains a group of iterations (this is customer controlled)
   2. Velocity = people*(weeks / iteration) / f, f = no. of calender days per ideal day