Extreme Programming
Wilfrid Hutagalung
IS6840 Class
Dr. Vicki Sauter
Fall Semester 2006
Waterfall and the Old Methodologies
The Advent of Agile Methodologies
Extreme Programming in Practices
System developments as a part of systems analysis and design have been developing with improved methodologies and approaches. As we already knew, in systems development a methodology refers to a framework that is used to structure, plan and control the process of developing an information system [1]. The still most used methodologies in systems development are Waterfall methodologies, which were proposed by W.W. Royce in 1970 [2].
Waterfall and
the Old Methodology
Traditional software development methodology to which Waterfall model belongs, use rigid procedures and requires deep and precise up-front planning. Before any work can be started all requirements must be ready and validated. There is a clear path and clear goals on the the projects. Below is a diagram of traditional waterfall method.
Figure 1. Waterfall Method [3]
By emphasizing on clear definition from the beginning of project waterfall approach has the strengths of ability to analyze potential changes easily, large and distributed teams are well-coordinated, predictable budgets, and only needs small involvement from subject matter experts [4]. This approach, however, also surfaces negative issues which become the weaknesses of the waterfall methodologies: lack of flexibility, difficulty in predicting actual needs for the software, the loss of intangible knowledge between phases, discouragement of team cohesion, and the tendency to not discover design flaws until the testing phase.
The Advent of
Agile Methodologies
Over the years there have been criticisms on the waterfall method or model due to some of its characteristics which are not suitable to more current environments. Some considerations which reveal the weaknesses of waterfall method are [5]:
· In reality it is very difficult for projects to follow the sequential flow of the model
· It is difficult to identify all requirements and goals at the beginning of projects as requirements tend to change all the way
· A working version can only be obtained late in the process
The background for waterfall method’s characteristics is that it was developed using engineering approach [6]. Critics argue that engineering processes like in building bridges are simply not suitable to be applied to software development because conditions are different.
As a reaction (or correction) to the shortcomings of traditional methodology several new and improved methodologies were introduced. Agile methodologies, introduced in 2001, replace the rigid and predictive nature of traditional methodology with adaptive and agile methods. Below is a picture of how agile methodologies differ from traditional waterfall model.
Figure 2. Waterfall vs eXtreme Programing [7]
The main concern of agile methodologies is the ability to embrace changes which are very likely to happen in environments which lack predictability [6]. To achieve the objective, agile methodologies use three key principles [8]: (1) a focus on adaptive methodologies, (2) a focus on people, and (3) a focus on self-adaptive processes. These principles can be expanded furthermore as [24]:
·
Testing is early, often and
frequently automated
·
Incremental design
·
Daily deployment
·
High level of customer
involvement
·
Continuous integration
·
Short development cycles
·
Incremental planning
·
Single code base
·
Embracing change
Agile methodologies do not refer to one specific approach but are a group of individual methodology that implement agile principles. Several agile methods that have been developed are:[8]
Scrum
Dynamic Systems Development Method (DSDM)
Feature Driven Development
Lean Development
Extreme Programming (XP)
Adaptive Software
Development
Extreme Programming (XP) happens to be the most well-known of agile methodologies and will be explored further.
The origin of extreme programming (XP) started in 1990s when Kent Black tried to find a better way of doing software development when he was handling a project at DaimlerChrysler [9]. His new approach which will later be called Extreme Programming Methodology and proved to be a successful method.
As a method which was created as a reaction to the old methodology XP uses different approaches that distinguishes itself from waterfall model. One significant difference in its approach is that it focuses on adaptability rather than on predictability. [2]. The reason behind this approach is that software development is a very fluid process where requirements cannot be fully predicted from the beginning but will always change as projects move on. Hence software development needs a methodology that is capable to adapt to changing requirements at any point during the project life.
In
his experiment at the DaimlerChrysler project
1. You need to improve communication.
2. You need to seek simplicity.
3. You need to get feedback on how well you are doing.
4. You need to always proceed with courage.
Combining all these principles, Extreme Programming works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation [10]. Although practices used in XP are actually common practices which are shared by other methodologies, XP goes further by doing those practices to an extreme level (hence the “Extreme” Programing). Below is a table on how XP is extreme.
|
good practices are |
pushed to the extreme. |
|
Code reviews |
review code all the time (pair programming) |
|
Testing |
everybody will test all the time (unit testing) even the customers (functional testing) |
|
Design |
make it part of everybody's daily business (refactoring) |
|
Simplicity |
always leave the system with the simplest design that supports current functionality (simplest thing that could possibly work) |
|
Architecture |
everybody will work defining and refining the architecture all the time (metaphor) |
|
Integration testing |
integrate and test several times a day (continuous integration) |
|
Short iterations |
make iterations really short-seconds, minutes, hours not weeks, months, years (the planning game) |
Table 1. Why it’s called eXtreme [11]
Extreme Programming
in Practices
There are four basic activities that XP proposes for software development process [12]:
1. Coding.
In XP coding is considered the only important product of the system development process. XP programmers start to generate codes at the very beginning so “At the end of the day, there has to be a program.”
2. Testing.
XP emphasizes to always check if a function works is by testing it. XP uses Unit Tests which are automated tests, and the programmer will write tests as many as possible to try to break the break the code he or she is writing.
3. Listening
Obviously, coding and testing need to be done no matter how a system is developed, but listening is very important in XP [13]. For XP developers the ability and expertise in technical aspects should be accompanied by the ability to be good listeners. This ability will enable them to understand what customers want and develop solutions which match customers’ needs and desires as close as possible.
4. Designing
XP’s simplicity principle doesn’t mean that it can exclude designing process. Without proper design in the long run system becomes too complex and projects could come to a halt. It is then important to create a design structure that organizes the logic in the system so too many dependencies in the system can be avoided.
In XP these four basic activities are implemented by using practices which are traditional software engineering practices but elevated to embody and encourage XP values. Although completely there are 28 rules and practices of Extreme Programing [9] they can be compacted into twelve simple rules [14] [15]:
1. User stories (planning): User stories can be
viewed as a smaller version of use case. In this way, the customer define as
briefly as possible the specification of the new application (features, value,
priority). These stories will be the base for the project team to do cost
estimation and management of the project.
2. Small releases (building blocks): XP emphasizes on small,
simple but frequent versions updates of the application. Each newly added
requirement will instantly incorporated and the system is re-released.
3. Metaphor (standardized naming schemes): Developers and
programmers must adhere to standards on names, class names and methods.
4. Collective ownership: In XP methodology, all code is
considered to be owned by the whole team and not an individual property. Hence,
all code is reviewed and updated by everyone.
5. Coding standard: Styles and formats of coding
must be the same in order to enable compatibility between team members. This
approach results in more rapid collaboration.
6. Simple design: Always look for system
implementation that is as easy as possible implementation of the system yet
meets all required functionality.
7. Refactoring: The application should be continually adjusted and
improved by all team members. This requires extremely good communication
between members to avoid work duplication.
8. Testing: Every small release (called building block) must pass
tests before being released. XP’s uniqueness in this aspect is that tests are
created first and then application code is developed to meet and pass the cahllenges of those pre-written tests.
9. Pair programming: XP programmers work in pairs.
All code is developed by two programmers who work together at a single machine.
The expectation is that pair programming produces higher quality code at the
same or less cost.
10. Continuous integration: Software builds are
completed several times a day. In this way all developers can avoid work
fragmentations because they continuously releasing and integrating code
together.
11. 40-hour workweek: Keep mental and physical
conditions to be up and running by not working more than what the bodies can
handle.
12. On-site customer: The customer must be viewed as
an integral part of the project. The customer must be arranged to be available
at all times in order to ensure that the project is in the right track.
XP process can be represented by the diagram below:
Figure 3. XP process [16]
Although XP methodology can result in an improved process which is more efficient more predictable more flexible and more fun [17], [18] it also has weaknesses such as:
■ Difficulty coordinating larger teams
■ Can result in a never-ending project if not managed properly
■ Tendency to not document thoroughly
■ Predicting the precise features to be accomplished in a fixed time/budget
which are actually common
weaknesses in methodologies using iterative approach [19]. Some XP opponents
argue that the very highly valued XP practices also make it a high risk
proposition [20]. Failure or disturbance
in just one rule will severely affect the next rules like in domino
effect. However, it is worthwile to point out that according
to Standish Group’s research that developing projects with smaller time frames,
with delivery of software components early and often, which are best practices
used in XP methodology, will increase the success rate [21].
To put things in perspective, XP works best if applied on
projects which have certain characteristics [12] [22]:
·
The project uses new or prototype technology which is
still developing and hence will incorporate many changes along the way and many
implementation problems are still unforeseen.
·
Frequent, small releases are possible.
·
The projects are for research purposes.
·
Projects are small and more easily managed through
informal methods.
Below
is a matrix on which methodologies apply best in certain condition:
Table 2. Choosing the Appropriate Method [23]
There is no such thing as the best methodology. Project Managers must weigh project aspects against available methodologies to make an appropriate selection. If a certain development process has been working well then it will be wise to stick with it. Other methodologies like XP, Scrum, CMM, or RUP can be reviewed to borrow some good and applicable ideas into the current methodology in use.
1. www.cms.hhs.gov/SystemLifecycleFramework/Downloads/SelectingDevelopmentApproach.pdf
3. www.cs.earlham.edu/~pickeju/sensem/figure1.html
4. www.ncycles.com/
e_whi_Methodologies.htm#_Toc28065936
5.
Center for Technology in Government, University at
6.
Hoffer, Jeffery A., George,
Joey F., Valacich, Joseph S. Modern Systems Analysis
and Design.
7. Dr Dmitry Tishkovsky, Software Development Tools, www.csc.liv.ac.uk/~dmitry/courses/COMP350/notes/COMP350-02-methodology.pdf
8. Steve Hayes, Martin Andrews, An Introduction to Agile Methods, www.wrytradesman.com/articles/IntroToAgileMethods.pdf
10. www.xprogramming.com/xpmag/whatisxp.htm
11. http://moonbase.wwc.edu/~aabyan/XP/problem.html
12. www.selectbs.com/glossary/what-is-extreme-programming.htm
13. Kenneth E. Kendall, Extreme Programming in Practice: A Human-Valued Approach to the DSI Conference Management System, Decision Line Vol. 35,October 2004
14. Scott Withrow, Extreme Programming: Do these 12 practices make perfect?, http://articles.techrepublic.com.com/5100-22_11-1046488.html
15. B. Rumpe, P. Scholz, Scaling the Management of Extreme Programming Projects, Projects & Profits Special Issue on Management of Extreme Programming Projects, Vol. III (8), pp. 11-18. ICFAI Press, Hyderabat, August 2003.
16. www.codeproject.com/gen/design/XP.asp?msg=1758050
17. http://positivesharing.com/2006/01/extreme-projects
18. John Noll, Darren C. Atkinson, Comparing Extreme Programming to Traditional Development for Student Projects: A Case Study, Department of Computer Engineering Santa Clara University, year unknown
19. Dan
Marks, Development Methodologies Compared, N·CYCLES
Software Solutions, December 2002.
20. www.softwarereality.com/lifecycle/xp/safety_net.jsp
21. Clement
James Goebel III, Extreme Programming Practices Used to Facilitate Effective
Project Management, Menlo Institute LLC, 2003.
22. www.onlamp.com/pub/a/onlamp/2003/07/31/extremeprogramming.html
23. www.ddj.com/dept/architect/184411706
24. www.msonewyork.com/agilemethod.html