Delivery addresses the notion of integration of work from streams of implementers. As such, delivery is an
important step and a 'quality gate' of reviews and approvals need to be passed before work can be accepted
into a higher level 'staging area'.
A good project policy is to require developers to rebase their development workspaces to the project's
current recommended baseline before accepting their work into the project's integration workspace. The goal
of this policy is to have developers build and test their work in their development areas against the work
included in the most recent stable baselines before they deliver to the integration workspace. This
practice minimizes the amount of merging that developers must do when they perform deliver
operations.
Another good project policy is to ensure that all files are checked-in prior to delivery. This avoids the
situation of having orphaned files that are not included in a build and might be needed for subsequent
updates.
Delivery is an important step that implies that a developer considers his work to be of sufficiently high
quality to be incorporated into the overall product.
It should be part of the Project Policy on who is to review given work products,
and what level of quality they are to have achieved before being acceptable
for usage by the rest of the project team members. Some guidance on reviews
in provided in the Guideline: Reviews. Many of the work products
in the Rational Unified Process have an associated 'checklist' that can
be used to assess the quality of that work product. For instance, if an work
product is found to be deficient on more than a given number of checkpoints
it is submitted for re-work, and thereby not eligible for 'promotion'.
|