Key XP Roles

<< The Four Values of XP

XP Role: Customer

The on-site customer (or customer team) is there to make day-to-day business decisions about what functionality goes into the project and what stays out.

The programmers and the XP Coach lead the customer by the hand. The trouble is, being immersed in the technical goings-on of the project, every day for the entire project duration, is bound to have an effect on the customer. He or she will end up thinking like a 'techie'.

Surprisingly, the customer is also encouraged to get involved in the programming side, writing automated acceptance test scripts. Initially these are handled by the programmers, but the drive is always towards getting the customer to handle these as soon as they are able.

From Extreme Programming Installed (Ron Jeffries et al):

"...Better yet, make a little scripting language that the programmers can use. Then grow it and make it easier until the customers can use it."

A classic fallacy is that programming can be "replaced" with visual tools, enabling non-programmers ("business users") to define flows of logic. No matter how visual or user-friendly these tools, this is still programming. The user is still defining something like: step 1, step 2... if <condition> then do step 3 else back to step 1...

However you look at this, it is still programming (or scripting). Joining lines and boxes together is just a visual metaphor for program code. Usually, these visual tools involve double-clicking a "decision box" to enter the actual decision-making code, e.g. in VBScript or JavaScript. Sure, it might be simple enough for the customer to do with a little help and training from the programmers, but they are still training the customer to program. The customer is being groomed to think, and make decisions, like a 'techie'.

XP Role: Programmer

If the programmers are good programmers, they will possess genuine enthusiasm for their job. Programming is a way of life for them. This means they will be excited at the release of the latest bleeding-edge API, and will be champing at the bit to use BandwagonX 0.9 in the customer's million-dollar mission-critical enterprise, and to constantly push the envelope of new technology. This is why most projects have (or really should have) level-headed analysts who actually understand the business issues, and who understand that risk mitigation is the most important activity in any project.

These analysts provide a much-needed buffer zone between programmer and customer.

XP requires programmers to have a broader skill set than simply programming. Suddenly they are not only coders but customer-facing analysts, Object-Oriented designers, OO programmers, testers, process experts, not to mention junior-grade project managers. Sounds great if you can get the staff, but remember these are people who supposedly can't be trusted to write code on their own.

XP Role: Tester

XP does not specify a Quality Assurance (QA) team or role. Instead, the programmers perform unit testing, and either the programmers or the customer perform acceptance testing.

From Extreme Programming Explained (Kent Beck):

"An XP tester is not a separate person, dedicated to breaking the system and humiliating the programmers."

That's an emotive way of putting it. However, the QA team is there with good reason. They want to break the system as early as possible, so that the product doesn't go out the door to be broken by the customer instead. The QA team is dedicated to preventing the programmers from experiencing this burning humiliation.

A programmer can only anticipate and intercept the bugs that they are expecting. A programmer might be convinced that their code module is rock solid. However, a fresh mind testing the same module is bound to spot potential problems that the programmer, being up close to their own code, just wouldn't have noticed.

The primary role of a QA team is to test the product against the requirements. In other words, they test at the application level, not at the code level. They will almost certainly use automated scripts, making regression testing a relatively painless process - in other words, in the non-XP world it is common to run automated scripts to ensure that the latest changes have not broken existing code. This provides great support for change in scope or design mid-project.

In a well-run and well organised project, there will be no concept of a "brick wall" between the programmers and the QA testers. The testers should roam freely amongst the programmers, offering support for running their functional tests. QA should never be content to wait patiently for the latest build to test. Testing should be common-place, taking place as soon as a programmer is ready to test their completed module. The "official" QA test scripts are still run on the regular integration builds, of course. Management can then use the resultant reports to build an accurate picture of the project's current level of progress and stability.

Of course, this does sound remarkably similar to XP's goal of frequent release builds, and to run acceptance tests as often as possible. If there are similarities here, then that's a good thing. However, the unfortunate difference is that "pure" XP cuts out the QA tester as a separate role. Instead, the programmer's build is tested directly by the customer, then goes straight out the door into this week's production release.

It is unusual for QA to delve in at the code level. A well-managed QA department will, however, insist on reviewing the programming team's process, to ensure that the source code does get reviewed by a fresh pair of eyes, either by another programmer or the team leader.

This is not the same as pair programming. Code reviewing needs to take place after the code has been written, i.e. viewing a product that is being presented to the reviewer as finished. Why? Two reasons:

1. Because the programmer, given the correct environment and proper mentoring, will discover a large proportion of their own bugs before the code has even been compiled. (In the book Software System Testing and Quality Assurance, Boriz Beizer discusses private bugs, i.e. those that are discovered and fixed by the programmer during their own code and test cycle).

2. Because you really don't want to interrupt a programmer while they're programming. They hate that. To a programmer, uninterrupted concentration is paramount.

 

>> And Finally: The Conclusion

Software Reality XP Forum

<< Back to XP Central

<< Back to Lifecycle