Introducing XP into the Company


Two types of projects existed when we started: major testing and debugging of existing projects, and new development.

In past projects, we had organized ourselves so that the teams would test each other's software, thus relying on the view of many test experts that independent testing is the most effective approach. This didn't work, because the teams' main priority was to their own project, and with deadlines fast approaching, each team concentrated on its own development work at the expense of testing another team's system. Coupled with the problem of teams trying too hard to satisfy late changes in their client's requirements, this was a clear recipe for disaster. Thus, when the academic year ended, we were unable to deliver software of the appropriate quality. (After the end of the year, the students graduate and leave, so we do not have the flexibility of extending deadlines or the benefits of continuity in the teams, because next year's company comes from the next cohort of students.)

We discussed these problems with the next cohort when they arrived in September 2000, and then looked at the ideas behind XP, primarily using [Beck2000] and the main XP Web sites. It was immediately clear to them that this new technique could be a big improvement on what had been done before. They therefore decided to adopt this way of doing things as far as possible.

The idea of pair programming was well received and has proved extremely effective in debugging code. The construction of functional test sets from the requirements also had a big impact on the process. It highlighted the need for suitable testing software, so both test generation and test application tools had to be built for the specific applications. Because these tools were based on generic concepts, they can be adapted to other projects. We describe some work on developing extremely powerful test case generators in [Holcombe+2001]. However, we still have problems estimating the amount of time and effort needed to complete projects, and this area needs further research.

The other important influence was in the management of client expectations, and this is now realized to be a vital factor. Delivering a high-quality basic system, rather than one with lots of extra, mainly unnecessary features, was instructive. The students are enthusiastic about satisfying their client's requirements, but sometimes they try too hard, and the project is then at risk because they cannot deliver it all in time and with high quality.

For brand-new projects, we introduced the students to a new approach for organizing stories and creating provably powerful test sets. This approach was tried on a Web-based project and immediately produced excellent results. It was both simple to use and powerful in its ability to capture the essence of the system. However, the projects are still ongoing, so it is perhaps too early to make any firm conclusions.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net