Review process goals

In my opinion, a good review process should:
· identify potential problems earlier in the development cycle
· Help team members learn from their more experienced colleagues
· improve quality through adherance to selected standards
production of content that is easier to understand and maintain

These goals exist primarily for two main business reasons:

· to increase productivity in developing new solutions
· maintain a good return on investment for existing solutions


Reviews could be arranegd in order

Lead / Architects review
A formal review to:
· confirm the scope of work

Peer review
An informal review where:
· Document Authors leverage the input / review of their project colleagues and customer counter-parts to product input, feedback and comments.

Paired review

An informal review where the primary developer should enlist the help of a secondary developer to:

· Logic is complex and requires explaining
· To confirm an area of speciality that another developer possesses (thus encouraging the sharing of information
· To highlight a technique or best practices to his/her peers
· A unit of work has been completed (typically a method passes its unit tests)

Group review
A formal review that should be:
· an independently peformed review to provide input, recommendations and experience for a given deliverable, concept or task package


The review process can be much more efficient with the use of regularly applied automated processes.