Talk:Freeze (software engineering)
 | This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
| ||||||||||||||
Totally bogus? edit
1. Deferring UX after feature freeze as documented is totally bogus. User interface and experience work is part of the feature design process, not a "bug" to be fixed later on. Only bugs are fixed later on.
2. A feature freeze is pretty much coupled with a (semi-)official roadmap, as it implies to setup a list of features that will be contained in the upcoming release of a software, and the release date is effectively deferred to whatever-point-in-time the features are completed.
3. Compared to a code freeze (usually date-based), a feature freeze allows to setup clear metrics for what the state of the software must be in before a new release can be considered. As such, a feature freeze is either very specific in the features it lists, or alternatively, it is represented as a list of (rough) "user stories" (see Scrum (development)).
4. In complex software projects, a feature freeze may imply that missing functionality is determined only after the feature freeze during alpha/beta testing. In that case, the new software release is delayed until the missing functionality has been incorporated to make the product work as intended - or - a new feature may be removed prior to the new release, to target for it again in the second to next release.