By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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
Twelve principles of extreme programming
The commissioning organisation creates "user stories" that define the desired features and the development team estimates the amount of resource for each story.
Rather than wait for the full feature set to be implemented, related features should be grouped with the smallest initial implementation.
Each project has a metaphor applied to it to act as an aide-memoire.
Aim for the simplest design available to fit the user stories.
No feature is added until a test has been written and run for that feature.
Refactor out any duplicate code.
No developer works in isolation.
Modules are considered as part of the whole and not as individual pieces. Developers are working on the project, not on a module.
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.
Developers have a working week and that working week is strictly adhered to. No midnight sessions to get the project done on time.
The development team has to have continuous access to the end-user.
Everybody codes to the same internal standards. Source: Butler Group