Extreme Programming at Sabre eXtreme programming XP was firs

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:

Q1 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?

Q2 Can traditional project management tools such as a work breakdown structure (WBS) be used in XP?

Q3 What methods for estimation would be most appropriate when following an XP approach?

Q4 If the company\"s developers have always followed a more traditional approach to IT projects, what impacts might introducing XP have on them?

Solution

Extreme programming is much friendlier on a smaller scaled project, and requires less overall extensive and timely processing. It decomposes all software projects into multiple small releases where each release of the software contains only a subset of the required functionality. These Small Releases are incremental production versions of the project\'s expected final deliverable providing limited subsets of functionality to the system\'s users. Each release of additional functionality offers stakeholders an opportunity to use the evolving capabilities of the software and provide high quality feedback, thereby improving the quality of progressive elaboration. The suggested timeframe for processing is a few weeks, to several, but no more than 10 for best results. While it can often be difficult to identify suitable functionality for early releases, the importance of early releases cannot be overstated. Projects that use small incremental releases benefit from user feedback and well understood project status, and they produce a return-on-investment before the project is fully completed. it is best done in small increments to best gage performance, thus being able to head off problems early, rather than have fiasco\'s such as Philadelphia\'s water project did!. Unlike milestones such as Preliminary Design, whose completion will often simply be declared, these early releases require demonstrable software product. Early releases that do not work provide important information, while there is still budget and schedule to react to the detected problems. Another interesting scenario to consider is a project that is cancelled halfway through due to constraints external to the project. In this case, a team that has produced several incremental releases will potentially have delivered something that will return value to the organization despite being cancelled before completion. The greatest aspect is the on-site development that would best suit the overall developing of coding and the testing metrics and a measurement that would be available immediately, thus the solutions and measures to take were just in time, and lessen the ability for lack of coordination and communications with others within the team.

Collective whiteboards and real-time in person meetings for progress reports, are the mainstay of XP

2) Yes.

A traditional WBS reflects traditional beliefs in functional division of work leading to a Waterfall process and the assumption that all planning can and should be done up front. A WBS will typically be a phase for Analysis, and others for Design, Development, Testing, Release, etc.

An XP style Release Plan maps Epics and User Stories out to give a list of features to be built over time. It is a high level WBS and project schedule in one, in the same way that a Gantt chart is a combination WBS and project schedule.

3)

Parkinson\'s estimation - under consideration of available resources. Corresponding projects can be settled, however only after expenditure.

Top Down estimation – with the starting point of the general functionality. The Iteration Effort Points (ITEP) tries to use this approach.

Bottom Up estimation – consider the estimation of the required system components. This procedure is currently used mostly.

Analogy, through comparison with similar projects. For the identification of the effort, this base stands behind all used procedures.

Expertise, in the context of the beginning of XP-Projects. Intuition and experiences from other projects build the basis of the effort estimation.

4)

Both Approaches are almost similar, But at first the developers may feel uncomfortable with XP due to more features and difeerent approach but they will get habituated and more importantly, they will work quickly.