This is going to be the noobist of all noob questions, but what exactly is scope creep, what does it entail?
相关问题
- Name for a method that has only side effects
- Best way to keep the user-interface up-to-date?
- Multi-pass C preprocessor [closed]
- should I write more descriptive function names or
- Open a new tab in firefox and keep ff in the backg
相关文章
- Should client-server code be written in one “proje
- Algorithm for maximizing coverage of rectangular a
- Is there an existing solution for these particular
- What is Scope Creep? [closed]
- How can I modify .xfdl files? (Update #1)
- What is the best algorithm to shuffle cards? [clos
- Hashtable and list side by side?
- Regular expression which matches at least two word
You start with a mouse and end up with an elephant.
In other words requirements change on a daily basis and what you are supposed to deliver doesn't look anything like what was supposed to be delivered at the start of the project
There are two definitions for scope creep.
Negative. Scope changed in uncontrolled ways adding cost and risk.
Positive. Scope changed in uncontrolled ways because our fantasy project plan was wrong, and we starting learning things we didn't expect to learn.
Most folks seem to like the first one.
The second one, however is more accurate. The few managers who recognize that scope creep -== learning are able to manage it wisely and get stuff done.
The rest of the managers see uncontrolled learning as a threat. The project won't create the hoped-for deliverables in the fantasy schedule or budget. This means that either scope needs to be reduced or budget needs to be expanded.
Note that most Agile methods don't seem to care much about scope or scope creep. With a narrow focus on the next release, the big picture becomes less threatening and scary.
Learning -- in an Agile context -- also leads to scope creep, but it's a good thing. Stuff that won't ever be useful is deferred. Stuff that didn't seem important when we started gets accelerated.
In the case of feature creep in my view there needs to be an element of contributing to the downfall of a product. For example growth of a city is good - urban sprawl is bad.
Or in the case of UI design.. all related features get stuck on one control screen - new features are continually added to the point where their mear existance confuses more people than would ever find the features useful.
To qualify as feature creep they should pass the test of contributing to unecessary complexity or throwing unecessary wrenches in the lifecycle of the system. Origionally unplanned features that do not meet this critera should not be concidered feature creep.
Scope Creep is concidered in the same light as feature creep only at the level of a products scope... For example:
Your team is building an "Air Sucker"(tm) which sucks air from one location and transports it to a factory two blocks away. The scope of the air sucker is that it moves air.
Then management realizes the sucking device also needs to suck and transport water and sand. The Air Sucker was never designed to transport liquid or granular materials and thus increasing the scope of the air sucker to the point where it must be significantly reengineered to meet the new transport requirements.
If you have appropriate change controls, possibly a cash cow.
There's a famous picture of a big power boat with a little runabout in tow. The runabout is called "The Original Contract", and the power boat is called "The Change Requests"
It's when a project incessantly gets larger and more complex than what was originally planned for, and therefore is perpetually behind schedule and over budget.
Scope creep is when requirements keep being modified or added to current product release. For example, you show a demo to the customer/user and they request new reports/buttons/fields. It can also occur when a developer wants to add new "cool" features, etc without needing them. It is best prevented by managing the project release cycles. People suggesting features is a good thing, but everybody involved needs to understand the impact on the project and budget. Consider adding new feature requests to a list and meeting regularly to decide which new features get added to the "next release".