Extreme Programming at Sabre eXtreme programming (XP) was first introduced by Ke
ID: 446874 • Letter: E
Question
Extreme Programming at Sabre eXtreme programming (XP) was first introduced by Kent Beck when he was the project leader on a large, long-term project to rewrite Chrysler Corporation"s payroll system. He later outlined this development methodology in a book titled Extreme Programming Explained: Embrace Change. Some of the main concepts of XP include using small teams, using simple code, reviewing it frequently, testing it early and often, and working no more than a 40 hour work week. XP is often referred to as a lightweight methodology because it does not emphasize lengthy requirements definition and extensive documentation. Instead, XP focuses on having the end user or customer develop user stories that describe what the new system must do. Beck suggests that project teams have no more than 12 developers working in pairs that work side by side on a single assignment. He believes that this approach leads to better quality code that takes less time to test and debug. Close communication between the developers and users/customers is key, as the user stories provide a basis for prioritizing the applications’ most important functionality and estimating code releases that are tested and shared among the development team. Sabre Airline Solutions for many years relied on a large modeling and forecasting software package called AirFlite Profit Manager to make flight schedules more profitable. In 2000, Release 8 of the software system contained approximately 500,000 lines of code and was four months late, with 300 known bugs or defects identified in final system testing. Moreover, a Sabre customer found 26 bugs in the first three days of acceptance testing, with an additional 200 bugs uncovered after the system was joint tested by Sabre and the customer. Since then, the company has adopted XP and claims that XP has dramatically improved the quality and productivity of its 300 developers. More specifically, only 100 bugs were found 16 months after Release 10 of AirFlite Profit Manager was shipped to its airline customers. Even more impressive was that Release 10 required just 3 developers to support 13 customers, while Release 8 required 13 people to support 12 customers. On another project, Sabre converted the user interface of its AirServ airline cabin provisioning optimization system from C++ to a Web-based Java application over a two-year period that required rewriting about 100 GUI programs. After the development team changed over to XP halfway through the project, Sabre reported that programmer productivity—as measured by the number of labor hours required for each screen—still increased by 42 percent. Other success stories include a Host Access Tool project that provides a common application programming interface for accessing legacy host systems. This system had over 15,000 lines of code and was developed from the outset using the XP methodology. Twenty months after its ship date, the software has remained defect free. In addition, only four bugs have shown up after 15 months in another software system called Peripheral Manager, a system that manages interactions between host systems and peripheral devices, and contains about 28,000 lines of code. With XP as its new approach to development, Sabre Airline Solutions customers defined features in terms of user stories that are expressed in user terms and simple enough to be coded, tested, and integrated in two weeks or less. Developers define criteria for automated test units, while customers define a broader set of criteria for acceptance testing. Both unit and acceptance testing are written before a feature or user story is coded. An inability to write a test usually means that the feature is not well defined or understood. The coding is accomplished in an open lab in pairs by teams of developers to promote collective ownership of the code. The developers can sign up for the tasks they want to work on and/or the person they want to work with. Each team also has an “XP coach” and an “XP customer” who is a subject matter expert and prioritizes product features, writes user stories, and signs off on the test results. Developers are encouraged to refactor code—i.e., rewrite code not just to fix bugs or add features, but to make it more efficient and easier to maintain. Customers see new releases in one to three months. According to Brad Jensen, senior vice president for airline product development at Sabre, the quality improvements come directly from XP"s continuous testing and integration. He says: “Every two weeks what you"ve completed has got to be production-ready. You code as you test. You actually write an automated unit test before you code the unit, so if bugs do creep in, you find out about it right then.” Moreover, Damon Hougland, director of airline products and services, believes that paired programming can be a difficult sell at first because many think it will double programming costs. However, he believes that XP actually reduces costs because the extra time to write a line of code is more than offset by effort to test, fix, and maintain the code. He also explains, “Everyone on the team works on every part of the system. You have the weaker people paired with the stronger people, and the business knowledge and coding knowledge are transferred very quickly.” However, XP does not include all the processes and practices a software development organization must follow. As Hougland contends, “XP really focuses on what [programmers] do. It doesn"t cover the traditional project management you have to do with customers, such as customer communications, and a lot of the testing we do is not covered in XP. A lot of people try XP and fail because they assume that XP will do everything for a development methodology.” Suppose you have been hired as a consultant by a company that is interested in exploring XP as a development methodology. In the past, the company has developed systems using more traditional project management and development approaches, so the current IT staff has little or no knowledge of XP. The CIO has asked you to provide some insight into the following questions: How should the company introduce XP? More specifically, should the company just jump right into it and attempt to use XP on a large, upcoming project that is mission critical to the company? Or should it experiment with a smaller, less critical project? Can traditional project management tools such as a work breakdown structure (WBS) be used in XP? What methods for estimation would be most appropriate when following an XP approach? If the company"s developers have always followed a more traditional approach to IT projects, what impacts might introducing XP have on them?
Explanation / Answer
XP cannot be used directly to the new comer and the highly critical and intense projects. High value projects must not be used as a trial run. The entire business image will come down if the high voltage project is tested with the XP roll out. There are various factors that needs to be considered while migration is happening. Mass roll out cannot be done on a high value project where the stakes are very high. There must be a systematic rollout.
First the employees must be well versed with the usage of XP in the development of projects. Migration itself is a process. Specific training and workshop needs to be conducted for the employees who are going to handle different aspects of XP. Their first hand knowledge levels needs to be tested and their scoring patterns in the evaluation needs to be monitored.
Simulated project with the new system, which is set in for work must be run in a trial basis. The feedback from the trial run must be evaluated strictly and any modifications if required must be done to it.
The next thing is that the database that is used in the old operating platform, should be migrated properly to the new XP system, which is going to be used henceforth.
Probable defects that could occur when the process of migration is happening must be identified earlier, and the respective corrective measures must be taken
The transition phase is very critical and all the employees must be informed earlier regarding the process that is set for migration. During the process of migration, a pilot run must be done with the implementation of the XP operating system.
Then the full fledged live run must be done with the small volume project, and the emerging defects that are coming up could be ironed out immediately.
By following the step by step implementation of the XP system, the company's brand image also rises to the higher levels.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.