|
 Agile
development methodologies like Extreme Programming are people-oriented
rather than process-oriented. Pradyumn Sharma writes how these methodologies
truly empower software developers
The software development industry is over half
a century old. Yet, when we look at the history of software projects,
we find so many projects stumbling or failing, though not necessarily
to the extent of completely being abandoned.
Customers often complain that the software is
delivered late, has bugs, does not fulfil the requirements. And
when their requirements change, they feel that the developers are
unreasonable in resisting incorporating these changes. Developers
often complain that the customers do not communicate their requirements
clearly, they keep changing the requirements, and have unreasonable
expectations of delivery schedules. They have to work long hours
as a matter of routine.
Added to these issues, poor testing results in
poor quality of the software that is delivered to a customer. As
defects are identified and fixed, new ones surface. Defect rates
go up, and everybody starts blaming everybody else.
As a project drags on with no end in sight, good
developers get frustrated and start leaving their jobs. This leads
to even more problems for a project.
In many cases, the reason behind this chaos is
the lack of right design and appropriate planning, which is typical
for most projects.
Resistance to formal methodologies
Many organisations have evolved methodologies
that are overly formal and detailed, emphasising on too much planning
and documentation. Formal methodologies are often regarded as too
bureaucratic, and developers normally resist them.
Enter the agile methodologies
Agile development methodologies are known for
their flexible and relatively less formal approach.
The agile development methodologies do include
processes, but they are not very rigid about them. They include
just enough processes to act as useful lighthouses, rather than
becoming impediments to the actual software development. These include
Adaptive Sof-tware Development (ASD), Crystal, Dynamic Systems Dev-elopment
Method (DSDM), Extreme Programming, Feature Driven Development (FDD),
Scrum, etc.
Among these, the Extreme Programming (XP) approach
is by far the most prominently talked about.
Some of the common characteristics of agile development
methodologies such as XP are:
- These are people-oriented rather than process-oriented.
Agile development methodologies truly empower the developers.
The developers make all the technical decisions, make estimates
for work to be done and choose how much process needs to be followed
in a project.
- Agile methodologies work well with changing
requirements. Formal methodologies for software estimation and
project planning work well if the requirements are clearly identified
and they don’t change. However, in most projects, the requirements
do change during their lifetime (for whatever reasons), and therefore,
you need methodologies that can adapt well to the changing requirements.
- Agile methodologies emph-asise small iterations,
which are easier to plan and monitor. They also provide early
feedback.
Extreme Programming
The pioneering work in formulating the practices
of Extreme Programming was done by Kent Beck and Ward Cunningham,
based on their experience in a number of projects in which they
worked together. They observed the practices that increased the
chances of success, and that which led to failures.
Based on these observations, Kent Beck identified
12 key practices of XP, and presented them in his landmark book
Extreme Programming Explained.
One of the key characteristic of XP is a strong
emphasis on teamwork. Many XP practices, such as pair programming,
and collective code ownership, require a team of motivated and committed
people who blend well with each other. XP also advocates small iterations
and continuous feedback from the customer to minimise the risks
in a project.
Key practices of XP
The 12 key practices of XP, as presented by Kent
Beck (with minor rewordings from me) are as follows:
1. The planning game
2. Small releases
3. Metaphor
4. Simple design
5. Testing
6. Refactoring
7. Pair programming
8. Collective code ownership
9. Continuous integration
10. No overtime
11. On-site customer
12. Coding standards
In the subsequent articles, we shall discuss
these key practices of XP in detail.
(To be continued)
Pradyumn Sharma is CEO of Pragati Software,
Mumbai. He has two decades of experience in the IT industry, and
is a trainer and consultant in the area of the object technology.
|
