Extreme Programming at Sabre eXtreme programming (XP) was first introduced by Ke
ID: 447472 • 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:
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?
Explanation / Answer
1 . Continuous integration assures developers that a common, tested baseline exists on a frequent basis. XP suggests an integration scheme where developers can integrate frequently and on their own free will.
The CCB clashed with many of the XP principles. XP recommends frequent integrations for a reason. The staler a branch got the more difficult the merge became. For example, the CCB postponed integration of a “below the line” defect. Meanwhile, significant changes were made to the code before the defect was approved. By this time, the file version with the defect fix is very different from the mainline version. In this situation, the merge was non-trivial and had to be done manually.
Divergence In the beginning of our project, we were highly disciplined pair programmers. We began by pairing for all development activities: design, writing unit tests, and code. We skipped the formal technical reviews (FTR), which were mandated by the CMM based process. We added informal reviews of the design to supplement the pair designing activities. As the project progressed, we paired less often for a number of reasons: less need for mentoring, schedule pressure, office ergonomics, responsibilities on other projects, difficulty finding a pair, management displeasure with the idea of pair programming and no formal reviews, and a new corporate FTR initiative. These are nothing but excuses. We are quick to admit that pair programming is an essential component to an XP-like development process. Our pair programming discipline descended a slippery slope. We transitioned into a process where pairing was only mandated when writing code. Test cases were written in pairs, if possible. Soon each developer became busy with other things and pairing on the code was happening less often as well. Eventually we fell into a process where pairing on code and tests occurred, at the minimum, when making risky changes. We instituted formal reviews of test cases and code because of pressure from our formal review centered organization, defects missed in pair programming, and less pair programming. We began reviewing test cases by looking at descriptions of the tests (this tied the unit tests to higher level box testing scenarios) and not the actual code of the test. We realized this was filling holes in the test suite but it was not improving the current tests. Thus, the bodies of the test cases were inspected as well. 4.2 Pros When we formally reviewed test cases we found missing tests and ways to improve the test suite through better assertions, helper test classes, and helper test methods. We have found that the discussions that take place in reviews, involving developers with many different points of view, are very valuable to the development process. Through pair programming, we have spread the knowledge of the Standard Template Library (STL) and OOD patterns. In doing so, we were able to re-use STL implementations and design patterns throughout our code. We certainly saw no decrease in productivity because of pair programming. Fig. 3 shows the increase in productivity from example projects representing a waterfall lifecycle , to an iterative OO lifecycle and finally four XP pilot projects (Project 5-8). The productivity is measured in KAELOC per staff month. Our project came out with the highest productivity numbers out of them all.
2 . The success or failure of a project all depends on how it is being managed and this is call project management. It ensures a smooth running of the different part of the project life cycle. It consists of many phases namely; initiation, planning, execution, monitor and control and closing. The two approaches that are mainly used nowadays, they are the traditional project management (TPM) and the agile project management (APM). They are both efficient types of project management but it depends on the project, its requirements and where it is being used. TPM has been a major approach since long time back and it has proven that it is still as useful as it was previously. This approach uses a method where a goal and a solution that is clearly (Wysocki, 2009) set to be achieve within a time frame. On the other hand, AGM is more recent approach which is the complete opposite of the traditional approach written as agile manifesto (Fowler & Highsmith, August 2001) by team of software developers. It is an iterative method where is has a clear set of goals to be achieved but the output is not clearly defined. These are two different approaches can be applied to a planning stage using various tools. Planning phase is where all schedules of the projects are identified
Traditional project management is the basic approach that can be used in project management. The goals and scope of the project is already set at the start and it is assumed that it will remain constant throughout the whole process until the completion. The team will work toward this solution with a time limit. There are different types of TPM such as waterfall model, spiral model and V-process model. The water fall model is the main methodology that represents the TPM. It provides a linear execution of phases during the project. The earliest delivery is at the implementation stage that is the client can see the product during the end of the project and at this stage is difficult to amend project scope to suite client purpose.
There are some advantages of using TPM, mainly all tasks that need to be achieved during the projects is already identified and broken down into milestones and deliverables. Another important one is about risk management, where most risks are effectively predictable to be managed with a complex and detailed inception and planning process. And finally it provides a rigid procedure to prevent changes to project scope defined in the early stages.
The negative side of this approach is the lack of client involvement during the whole process until the last stage where they see the final product. There are poor requirements as it is not checked again if it is to the client expectation.
Overview of Agile Project Management Approach
Agile project management is based on an iterative and incremental method, where project scope and result evolve throughout the process with close communication between cross functional teams. According to Jim Highsmith, "Agility is the ability to adapt and respond to change… agile organisations view change as an opportunity, not a threat." (Highsmith, 1999). It promotes adaptive planning, an iterative process, and encourages fast response to change management. APM is one which requires regular feedback as a guide toward the direction the project is moving. Some methodologies to this type of management are Scrum, XP (Extreme Programming), Lean, Agile Unified Process and Feature Driven Development. Scrum is a methodology which is based on communication and collaboration among the team. The team can choose which part they want to develop first and requirement cannot change during iteration. There is no hierarchy, in case of failure or success; it is the responsibility of the whole team and not one individual only. XP is similar to scrum in terms of iterative and process but it does contain some difference such as, requirements can change anytime even during iteration. Team should work in a specific order according to the project charter. Lean is one which involves more the stakeholders to the project. It is often due to which requirements changes regularly but on the other hand it ensures that the project up to the client’s level of expectation. This increases success rate
APM advantages are; it seeks regular and early feedback from client since the first stage itself and it needs smaller development team but with high competence. It has been suitable for projects that have unclear or rapidly changing scopes. It encourages more communication (face to face as they are usually in same location) and close interaction with clients (Highsmith, 2004).
Some disadvantages of agile project management are that is recues the amount of documentation in a project and hence if there is someone else who plan to take over, it will be complex to understand without required document. The fact that there is regular contact and feedback from clients, these increases criticism and may affect team attitude. (Highsmith, 2004)
Critical Analysis of Traditional and Agile
Analysing traditional and agile project management is all about the difference between these two main types of management. The critical analysis will be base of the impact of these two approaches in the planning process stage. The planning process is where the scope of the project, milestone and deliverables, risk and risk control, resource plan, quality plan and financial plan are defined (Eve Mitchell, 22 March 2012).
The first step of planning is to define project scope. In TPM, it is assumed that the project is set with a predefined start date and finishing date (Rad & Anantatmula, 2005). The client and the team will define the requirements of the project during this planning phase and finalise it. Once the stage is passed, the will not be changed and the client will only see the first prototype at the implementation stage. Compared to APM, it is a more flexible methodology, where the scope of the project is defined and is constantly reviews by the client on and iterative basis. It encourages the scope to be reviewed constantly to suite the client expectation. APM has a finish date but the solution of the final product is not defined. It evolves with feedback obtain from client. APM can be chosen as the best method for scope planning as it is keeps requirements project updated. It can contribute to the success of the project as the client is always aware of the changes.
3 .
Extreme Programming (XP) is a software engineering methodology, the most prominent of several agile software developmentmethodologies. Like other agile methodologies, Extreme Programming differs from traditional methodologies primarily in placing a higher value on adaptability than on predictability. Proponents of XP regard ongoing changes to requirements as an often natural and often inescapable aspect of software development projects; they believe that being able to adapt to changing requirements at any point during the project life is a more realistic and better approach than attempting to define all requirements at the beginning of a project and then expending effort to control changes to the requirements.
XP prescribes a set of day-to-day practices for managers and developers; the practices are meant to embody and encourage particular values. Proponents believe that the exercise of these practices—which are traditional software engineering practices taken to so-called "extreme" levels—leads to a development process that is more responsive to customer needs ("agile") than traditional methods, while creating software of similar or better quality
Goal of XP
Extreme Programming is described as being:
The main aim of XP is to lower the cost of change. In traditional system development methods (like SSADM) the requirements for the system are determined at the beginning of the development project and often fixed from that point on. This means that the cost of changing the requirements at a later stage will be high.
XP sets out to lower the cost of change by introducing basic values, principles and practices. By applying XP, a system development project should be more flexible with respect to changes.
XP values
Extreme Programming initially recognized four values. A new value was added in the second edition of Extreme Programming Explained. The five values are:
Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme Programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, Extreme Programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.
Extreme Programming encourages starting with the simplest solution and refactoring to better ones. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Related to the "communication" value, simplicity in design and coding should improve the (quality of) communication. A simple design with very simple code could be easily understood by most programmers in the team.
Within Extreme Programming, feedback relates to different dimensions of the system development:
The software development process is almost invariably guided bysome systematic software development method (SDM). Referred to by a numberof terms, including process models,development guidelines,and systems development life cycle models (SDLC), software development methods nevertheless generally include the same development phases:
The systems development life cycle model was developed as a structured approach to information system development that guides all the processesinvolved from an initial feasibility study through to maintenance of thefinished application. SDLC models take a variety of approaches to development.
Systems development life cycle models include:
· The waterfall model: This is the classic SDLC model, with a linear and sequential method that has goals for each developmentphase. The waterfall model simplifies task scheduling, because there areno iterative or overlapping steps. One drawback of the waterfall is thatit does not allow for much revision.
· Rapid application development (RAD): This modelis based on the concept that better products can be developed more quicklyby: using workshops or focus groups to gather system requirements; prototyping and reiterative testing of designs; rigid adherence to schedule; and less formality of team communications such as reviews.
· Joint application development (JAD): This modelinvolves the client or end user in the design and development of an application,through a series of collaborative workshops calledJAD sessions.
· The prototyping model: In this model, a prototype (an early approximation of a final system or product) is built, tested,and then reworked as necessary until an acceptable prototype is finallyachieved from which the complete system or product can now be developed.
· Synchronize-and-stabilize: This model involves teams working in parallel on individual application modules, frequently synchronizing their code with that of other teams and stabilizing code frequently throughout the development process.
· The spiral model: This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects.
- An attempt to reconcile humanity and productivity
- A mechanism for social change
- A path to improvement
- A style of development
- A software development discipline
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.