Agile development, part of the extreme programming methodology,
aims to improve the quality and delivery time of projects.
European banking and financial group BNP Paribas is approaching new
software development projects with a methodology aimed at improving
quality and project delivery.
Traditionally, software development projects use the "waterfall"
system for producing code, where testing and end-user acceptance
are conducted only once the analysis, design and development phases
of a project have been completed.
The agile approach, part of a wider programming methodology known
as extreme programming, is iterative, so testing and user
acceptance occurs continually throughout development of the
project.
The idea is for a project to be split into small chunks which are
presented to users on a regular basis as completed pieces of
functionality.
The concept of requiring close user involvement might appear to
preclude the use of extreme programming in commercial IT
organisations, but the answer is for a user representative to take
the user's part, according to analyst firm Butler Group.
Fred Tingey, UK head of risk IT at BNP Paribas, runs a team of 60
developers and has been training teams of developers and business
analysts in the agile approach on a project basis. He said, "Agile
programming requires a change in mindset. It is important to have
mentoring."
The bank employed Irish IT consultancy Exoftware to train and
mentor project teams of six or so programmers in the agile
methodology. Business analysts were also given classroom training
as the methodology required business involvement throughout the
development process.
Tingey said changing developers' mindsets could take up to six
months. "The better the developers are, the quicker they adapt," he
said. In his experience, the people who find agile programming
difficult are generally the less capable developers. "They do not
really understand what they are doing," he said.
He added, "Agile programming brings discipline, measurement and
reduces the risk [of programming projects]." The approach is based
on delivering what is known as a "minimal marketable feature set"
of an application to business users every two weeks.
"Instead of having a lot of business involvement upfront, the
business is involved more regularly [throughout the project],"
Tingey said.
The benefit of the approach, according to Tingey, is that the
business is able to provide continual feedback. It also means that
the business can decide how much functionality it requires without
having to wait for the full application to be developed. This can
reduce the development effort if certain functions are no longer
needed by the business.
The approach involves test-driven software development, where
programmers collaborate and share code, rather than work
individually on constituent parts of a project. A metric within
agile programming called velocity measurement has become an
essential project management at BNP Paribas. This estimates the
relative amount of work required to program key areas of
application functionality prioritised by the business. "It helps to
show the business the cost benefit," said Tingey.
The bank has recently rolled out CPA, a tool for administering
credit limits on the trading desk using agile programming as the
development methodology. Tingey now has a team working on a related
application which handles excess management to cope with the bank's
exposure when a limit is exceeded.
Meta Group analyst Earl Perkins said this type of development
exposes users to unnecessary risks as it is difficult to build
security into the software development lifecycle.
He said, "We have found that some of the newer software development
lifecycles, extreme programming and related iterations of those
lifecycles have actually been a step backward for applying security
and risk related steps or processes."
XPDay, a conference on extreme programming and agile software
development, will take place on 25-26 November in London
www.xpday.orgTwelve principles of extreme
programming
Planning
The commissioning organisation creates "user stories" that define
the desired features and the development team estimates the amount
of resource for each story.
Start small
Rather than wait for the full feature set to be implemented,
related features should be grouped with the smallest initial
implementation.
Naming convention
Each project has a metaphor applied to it to act as an
aide-memoire.
Simplicity
Aim for the simplest design available to fit the user stories.
Testing
No feature is added until a test has been written and run for that
feature.
Refactor
Refactor out any duplicate code.
Pair programming
No developer works in isolation.
Collective ownership
Modules are considered as part of the whole and not as individual
pieces. Developers are working on the project, not on a module.
Integration
Changes have to be integrated into the code base on
a regular basis, which should not exceed 24 hours. Tests should be
run before and after integration.
No overtime
Developers have a working week and that working week is strictly
adhered to. No midnight sessions to get the project done on time.
Commissioning access
The development team has to have continuous access to the end-user.
Coding standards
Everybody codes to the same internal standards. Source: Butler
Group