March 25, 2002R McFadyen a lightweight approach to software development. about 5 years old has been used at: Bayerische Landesbank, Credit Swiss Life, DaimlerChrysler, First Union National Bank, Ford Motor Company UBS XP was based on observations of what made computer programming faster and what made it slower. e X treme P rogramming (XP)

March 25, 2002R McFadyen create tests first, before the code keep their design simple and clean get feedback by testing their software starting on day one. deliver the system to the customers as early as possible and implement changes as suggested remove redundancy, eliminate unused functionality refactor throughout the entire project life cycle to keep the design simple avoid needless clutter and complexity. keep your code clean and concise so it is easier to understand, modify, and extend. make sure everything is expressed once and only once Extreme Programmers

March 25, 2002R McFadyen All code is created by two people working together at a single computer. It is counter intuitive, but … increased quality generates big savings later in the project Sit side by side in front of the monitor. slide the key board and mouse back and forth. one person types and thinks tactically about the method being created, while other thinks strategically about how that method fits into the class. Pair programming

March 25, 2002R McFadyen written by the customers as things that the system needs to do for them. similar to usage scenarios they are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax. User Stories

March 25, 2002R McFadyen Developers estimate how long the stories might take to implement. Each story will get a 1, 2 or 3 week estimate in "ideal development time". This ideal development time is how long it would take to implement the story in code if there were no distractions, no other assignments, and you knew exactly what to do. > 3 weeks means you need to break the story down further. < 1 week and you are at too detailed a level, combine some stories. User Stories

March 25, 2002R McFadyen The customer then decides what story is the most important or has the highest priority to be completed User stories are printed or written on cards. Developers and customers move the cards around on a large table to create a set of stories to be implemented as the first (or next) release. A useable, testable system that makes good business sense delivered early is desired. User Stories

March 25, 2002R McFadyen Overtime Once or twice a year, you can work overtime for a week but the need for a second week of overtime in a row is a clear signal that something else is wrong with the project. stand up meetings every morning everyone stands up in a circle to avoid long discussions Communication / Meetings

March 25, 2002R McFadyen Strictly sequential (or single threaded) integration by the developers themselves Single threaded integration allows a latest version to be consistently identified. Single threaded integration developers should be integrating and releasing code into the code repository every few hours, when ever possible. never hold onto changes for more than a day. Integrate often

March 25, 2002R McFadyen XP is controversial  Don't force team members to specialize and become analysts, architects, programmers, testers, and integrators--every XP programmer participates in all of these critical activities every day.  Don't conduct complete up-front analysis and design-- an XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development.  Develop infrastructure and frameworks as you develop your application, not up-front--delivering business value is the heartbeat that drives XP projects. Designing one day-at-a-time

March 25, 2002R McFadyen Chrysler Comprehensive Compensation System an often quoted example of XP 1997 Payroll for 10,000 employees 2,000 classes 30,000 methods C3

March 25, 2002R McFadyen full-time experienced programmers working 45 minutes on a challenging problem important to their organization 5 alone and 10 in five pairs statistically significant results all teams outperformed the individuals pairs spent 60% more time completed task in 40% of the time produced better algorithms and code 1998 experiment

March 25, 2002R McFadyen students same classes same instruction 13 individual programmers 28 pair-programmers one partner is the “driver”, the other watching for defects, thinking of alternatives, considering implications pairs first assignment took 60% more time then decreased to 15% 1999 experiment University of Utah

March 25, 2002R McFadyen After the initial adjustment period in the first program (the "jelling" assignment), together the pairs only spent about 15% more time on the program than the individuals

March 25, 2002R McFadyen the resulting code has about 15% fewer defects

March 25, 2002R McFadyen

March 25, 2002R McFadyen In statistically significant results, pair programming teams who had earlier programmed alone reported that they enjoyed pair programming more and that they were more confident in their programs than when they programmed alone Most of the programmers enjoyed programming collaboratively 1999 experiment University of Utah

March 25, 2002R McFadyen University of Utah another experiment planned Brook’s Law “Adding manpower to a late project makes it later.” Why? Now they want to see if XP can break that law 200? experiment