问题
As software developers we create lots of... well... code. Much of the code we produce can go towards a new feature or an enhancement to an existing feature. When this is the case, how do we know when this feature is done?
What does done mean in the context of a feature? For example, to Company A this may mean many different things like,
- Meets customer requirements (which is tricky in itself)
- No known bugs
- Documentation is written
- etc.
- etc.
To better help understand what done means to different developers and teams please list up to five (but no more than 10) items. This list would be something you as a developer, or your team, might go through and once all items are checked off, the feature is considered done.
Update
These are some great answers. I'm trying to figure out how to determine the best one as I guess this question is somewhat subjective. I guess I'm still looking for a more complete picture.
回答1:
When the client/user signs off on the UAT (User Acceptance Test) after testing it. That's our official measuring stick.
Of course that doesn't mean anything because invariably there's a version 2.0 of the feature requested a few weeks later, but that's more on their end than ours.
edit - If you want to be really detailed about it, here's how we do it:
- Requirements are approved by system analyst and client
- Design is approved by lead programmer
- Code review is approved by peer programmer
- Code is marked as tested in unit testing by QA dept.
- UAT is signed by client after personally testing it themselves.
- Code is marked as tested in system testing by QA dept.
- Code is released.
回答2:
if you mean "done" in the sense of "we'll never have to touch that again", then the only answer is: when the system is obsolete ;-)
if you mean 'when it is ready to ship' then presumably when all of the agreed-upon unit tests pass, assuming TDD/XP/Agile methods of course.
回答3:
When the user's happy with it.
回答4:
When it solves the problem it was envisioned for. This carries with it the burden of adequate testing, documentation, usability, etc - not too much, but enough that it does what it needs to.
回答5:
Distasteful, politically incorrect, but pragmatic answer: there is (at least) one critical point during the evolution of a feature.
Release the feature before this point, and you lose because the customer will not accept the feature. It will cost more to fix--in time, materials, reputation--than it would have cost to "finish" it.
Release the feature after this point, and you lose because of opportunity cost. You would profit more by focusing your attention on something else.
The feature is done when it reaches this critical point.
回答6:
When there's a fork in it.
- Code meets the written specification
- Code passes code review
- Code has and passes unit and integration tests
- Code passes QA
- Package with code is signed off by all stakeholders
-Adam
回答7:
For us, a feature is done, meaning we can ship it, when two criteria are met:
- a feature passes all of the unit tests and manual tests we wrote at the beginning of the release. This is determined by the QA or developers in the absence of QA.
- doing the outstanding change requests/bug fixes to a feature provide less value than the resources (time) needed to complete them. This is determined by the product owner.
回答8:
Every project is divided in sprints.Sprint may have one or more features.A sprint or feature is done when these phases are done for that sprint
1.US->User stories -> UI -User Interface -> Dev -> Development -> QA -> Quality Assurance -> UAT -> User acceptance testing is done.
回答9:
There still seems to be a discrepancy about what "done" means. For many (most?), like Mayank Gupta at Scrum Alliance, done means that a product or feature is potentially shippable at the discretion of the Product Owner.
For others, like MattC above (and my own organization) "done" means that the product or feature has been shipped.
回答10:
When it ships.
回答11:
When there is nothing left to take away from it.
回答12:
Your feature is done when all the tests associated with it pass. When requirements change, add more tests and code until THEY pass too.
回答13:
I think it depends on the people looking at it. Developers naturally want to take code to the nth level, whereas a customer will have a vision for it..
So,
- Customers, when they stop asking for changes.
- Developers, never :)
回答14:
Simple answer: When it meets the requirements of the customer (or the people you are implementing the feature for).
Not so simple answer: When it meets all the intrinsic requirements people/the customer expects: hidden quality requirements, extensibility, documentation, stability, ease-of-use, etc.
回答15:
When it is done in accordance with the teams defined definition of Done. The definition of done should be a visible document agreed by the scrum team which is referred back to whenever the question 'is it done?' is asked.
There is a good article that breaks down the definition of done on the scrumalliance.org website
enter link description here
来源：https://stackoverflow.com/questions/136099/when-is-a-feature-considered-done