Agility Guide

This chapter discusses the Quality Gateway in its most formal incarnation. It is worth emphasizing that you canin fact, you shouldapply some or all of the Quality Gateway tests to a requirement at any stage of your requirements gathering. The way that you implement the Quality Gateway (who will do what, when they will do it, and how many times they will do it) depends on the degree of agility to which you aspire.

Rabbit projects rarely make use of written requirements. This lack of documentation makes it slightly harder to determine whether the requirement is the correct one. Nevertheless, before attempting to implement a requirement, the developer must ensure it is within scope, is testable, is not gold plating, and meets several other criteria that we will cover in this chapter. The Quality Gateway is applicable to rabbit projects, but probably not in the formal way we present the subject here. Rabbit team members should read this chapter and apply its principles as a checklist for reviewing their stories.

Horse projects probably use written requirements and an iterative development cycle. This practice results in a short time elapsing between the gathering of requirements and the release of a partial working version of the product. But putting the product in the user's hands quickly should not be viewed as a way of avoiding testing the requirements. Even for the fastest of cycles, it is still far more efficient and effective to spend a small amount of time testing the requirements before attempting any implementation. Horse projects should use an informal Quality Gateway. More on how to do this later.

Elephant projects produce a specification. The sheer size of elephant projects means that even small errors in requirements have the potential to balloon into major problems if not caught early. The size of the final specification precludes effective testing of the entire documentpeople stop seriously reading at about page 15 and start skimming. The idea of testing individual requirements or cohesive groups of requirements as they are generated is attractive in that it has every chance of success. Each requirement is tested. If it passes these tests (you must determine the tests appropriate for your type of project or product), it becomes part of the specification. As a result, the specification contains only tested, correct requirements.