For various reasons, sometimes it makes sense to first write the code and only afterwards to write the spec.
For example: You may not be sure what is technically possible, you hope for at least some minimal functionality, but discover that it's trivial to implement a fully-blown feature.
Sometimes it doesn't make sense, but it simply happens; a quick fix or tweak turns into a feature. This could be the result of a programmer having a sleepless night and dedicating it to the cause, or a team having an internal competition.
Or it may simply be a case of feature-creep.
If it's already coded, why the spec?
If nothing else, QA needs to be know what to test, and without a spec that cannot know what is broken or purposely missing.
If you keep documentation up-to-date, then you will need a spec so that the technical writers have a starting point.
But the most important reason to RetroSpec is to enable a spec review. Experienced Project Managers are adept at discovering the corner-cases, but can only do so if there is a spec to review.
If need be, the Project Manager should write a spec, simply in order to ensure that the corner cases are covered.
In a future post we will give examples of typical corner cases, and how to find them.
- Danny Schoemann
No comments:
Post a Comment