|
|
| Software
Development Models |
| Agile Software Development |
| Agile means being both effective and maneuverable,
agile development methods are both light and sufficient. In the introduction of
his book Agile Software Development [97] Alistair Cockburn states: “Knowing
that perfect communications are impossible relieves you of trying to reach that
perfection. Instead, you learn to manage the incompleteness of communication.
Rather than try to make the requirements document or the design model
comprehensive to everyone, you stop when the document is sufficient to the
purpose of the intended audience. Managing the incompleteness of communications
is core to mastering agile software development.” Agile software development
methods are focusing on the people rather than on tools and processes, their
goal is working code more than perfect documentation. They try to adapt to
changes in the requirements rather than the execution of a predefined plan. One
increasingly popular Agile Development Method is known as Extreme
Programming (XP). It is a lightweight discipline of software
development invented by Kent Beck based on principles of simplicity,
communication, feedback, and courage [85]. XP is designed for use with small
teams who need to develop software quickly in an environment of rapidly
changing requirements. Extreme Programming was created in response to problem
domains with changing requirements. In many software environments dynamically
changing requirements is the only constant. XP was also set up to address the
problems of project risk. If the system is needed by a certain date the risk is
high. If that system is a new challenge for the software group the risk is even
greater. If that system is a new challenge to the entire software industry the
risk is greater even still. The XP practices are set up to diminish the risk
and increase the likelihood of success. |
| There are 12 key practices in XP: |
-
The Planning Process -
The XP planning process allows the XP "customer" to define the business value
of desired features and uses cost estimates provided by the programmers, to
choose what needs to be done and what needs to be deferred;
-
Small Releases -
XP teams put a simple system into production early and update it frequently on
a short cycle;
-
Metaphor -
XP teams use a common "system of names" and a common system description that
guides development and communication;
-
Simple Design
- A program built with XP should be the simplest program that meets the current
requirements;
-
Testing -
XP teams focus on validation of the software at all times. Programmers develop
software by writing tests first, then software that fulfills the requirements
reflected in the tests. Customers provide acceptance tests that enable them to
be certain that the features they need are provided;
-
Refactoring
- XP teams improve the design of the system throughout the entire development
by keeping the software clean: without duplication, with high communication,
simple, yet complete;
-
Pair Programming
- XP programmers write all production code in pairs, two programmers working
together at one machine. Pair programming has been shown by many experiments to
produce better software at similar or lower cost than programmers working
alone;
-
Collective Ownership
- All the code belongs to all the programmers. This lets the team go at full
speed, because when something needs changing, it can be changed without delay;
-
Continuous Integration
- XP teams integrate and build the software system multiple times per day. This
keeps all the programmers on the same page and enables rapid progress;
-
40-hour Week
- Tired programmers make more mistakes. XP teams do not work excessive
overtime, keeping fresh, healthy, and effective;
-
On-site Customer
- An XP project is steered by a dedicated individual who is empowered to
determine requirements, set priorities, and answer questions as the programmers
ask them. The effect is that communication improves, with less hardcopy
documentation - often one of the most expensive parts of a software project;
-
Coding Standard - For a team to work effectively in
pairs, and to share ownership of all the code, all the programmers need to
write the code in the same way, with rules that make sure the code communicates
clearly.
|
|
|
|