3 ms·
I work in a contract environment, and it's in our mandate to avoid feature creep. Enhancements have to be derived from the requirements and design that the cust
by bmj 18y ago
I work in a contract environment, and it's in our mandate to avoid feature creep. Enhancements have to be derived from the requirements and design that the customer bought off on, or we require more money. Bugs that interfere with our commitments to the customer, on the other hand, are handled with extreme prejudice.
My employer (who works in a highly regulated industry) works the same way. If a core product must be modified, we issue a change control memo. The items in the memo either have to be tied to bugs in our bug-base or, in the case of enhancements, a specification.
Because of the high volume of paperwork that surrounds software releases (specifications, documentation, test matrices, test reports), enhancements are typically put into a stack until there are enough to justify the load of paperwork that must accompany such a release. Bug fixes still require paperwork, but specs don't need to be written, only test reports.
- msg 18y agoMy sympathies. We don't have as much overhead involved, but around integration time, it gets a lot like you're describing. We get away with a lot of common sense at other times. More often, our enhancements get rolled into a new contract. If they are peripheral enough, we might not even do requirements for the new contract. Just using the old change requests is as specific as it gets.
- bmj 18y agoIt's actually not as bad as it sounds. Devs produce only a small amount of documentation (including unit test reports)--it's the product manager and QC department that really have the burden of documentation. It's nice having a well-defined set of requirements, and because of the overhead of updating documentation, scope creep is kept to a minimum.