Hi All,
Has anybody worked out where bug/defect fixes fit into the overall process. For instance say you have been through an interation and release features A,B and C. You embark on the next interation for features D, E and F. During this time the testing/QA department find a bug in Feature A.
The question becomes how and where is this inserted back into the process to be fixed
Many Thanks
Dave
The same way
Hi Dave,
work for bugs/defects or changes (new work) is done the same way. That is - you list features that describe the work to be done (defect or otherwise) and use the same FDD processes. Depending on the granularity, you may also do some shape modeling first.
This question is usually asked as "if a feature is 100% complete and subsequently there is a defect in that feature, does it becomes less than 100%?" No, you add another feature that represents the work for the defect.
You can choose how you want to represent and track such features. Some people don't want to affect the baseline.
Jeff
10% rule
It's late for this comment, but I just started reading the forum...
If the rule of thumb is to swallow any increase of features less than 10% of the original project size; and the addition of defects at the end of an iteration increases the project by more than 10%; how can you reconcile that with what was hopefully a realistic estimate after Process One.
FYI, I haven't done FDD yet, but they were talking it up at TechEd 2004. My issues with Agile methods derive from the fact that as a consultant my company always gives fixed price estimates and is loath to re-approach the customer for additional funding in case the project size expands.
Fixed-price is fine
I don't understand your comments.
The 10% number is just a guide. I personally use it as an upper limit, but that does not mean that I blindly eat any new features below 10%. What I will expose or challenge depends on many factors.
Design and Code defects however are entirely my problem and they do not go into the 10% growth number (requirements defects depend on the nature of the contract).
All I do is fixed-price so I am certainly aware of its issues. I don't understand why in a fixed-price environment you are loathed to go back to the client if the project size expands? That's precisely when you should be going back to the client. You are fixed-price. You are carrying the risk. If the client expands the project you want relief for that.
Jeff
Clarity
Sorry my comments weren't too clear.
You're statement about not considering defects as part of the 10% increase is understood. So they are added as a feature; but not figured into an overall project increase?
On another note... I guess I'm trying to nail down a method for measuring the size of the project.
My company considers pretty high-level features when it provides it's estimate to the client.
So a current project is a good example. We agreed to perform some calculations on incoming data. High level specification is easy (data file is sent to us; we read file and store in database; perform calculation on each row; save results)
However, inside of that the datafile wasn't consistent in format; the calculations depend on a more complicated data model than we were originally aware; the overall structure of the database doesn't fit the applications datamodel;etc...
So I would think we could break each high level task into more granular features, provide estimates for each granular feature and discuss with the client.
However, our sales reps consider the additional complexity in scope, and consequently part of what we promised the customer for the fixed price.
Any advice for dealing with this in terms of FDD?
Maintenance vs. FBS
Does the introduction of maintenance works (e.g. enhancements and corrections) for a software product after it was released affecting the original FBS for the software product ? Or shall we create a new FBS instead ? Shall we include the new maintenance works into the relevant feature sets that were defined earlier, or shall we create a new feature set to accomodate the new maintenance works ?
Chiu Yee Weay
A new project and FBS
Hello Chiu Yee Weay,
if the software product has been released then the project is finished. Further work would be another project and thus another FBS.
Jeff
Naming defect features
This is a couple years late but I have only just recently come across FDD....
If you are adding new defect features to your feature list then this would change the % complete of a feature set from 100% down to say 97% as defects are found. Is this correct as this can cause fluctuations in a project / feature sets completion % and how would do you know if a feature set is truely 100% complete?
Also how would you name defect features?
For example if you have a feature called
"Calculate the total for a sale"
and a problem was found during UAT for this calculation what would you call the defect feature (if you were to use the <action><result><object> template)? Say the tax was incorrectly being included for non taxable items purchased on the sale.
Thanks
Jon Cahill
100% stays 100%
Exactly - and that's why this is never done. You don't ever turn down a feature from 100%.
There are two situations where you could be making a change to some feature that is complete (100%). A user change request (a requirements defect) or a design or code defect.
Let's use your example of a feature "calculate the total of a Sale" and that feature is complete (i.e. 100%)
Case A - a user change request. The requirement has now changed to explicitly state that handling discounts is needed. The work to do this is handled just the same as for maintenance work which is just the same as for the original features. That is, you list features that describe the work to be done - in this case it just so happens to be work in response to a change request. You model first, you list features, you plan, you design and build by feature.
The mechanics of how you do this I've explained in How To Record New Features.
Case B - there is a defect raised about tax being incorrectly included for non-taxable items in the sale.
This work is tracked and reported outside the standard FDD reports. This is because it's not a requirements change - something the user (client) said they'd get right. This is design or code and that's what we said we would get right. Design and code defects are not new features and we have to eat them. i.e. do the work to fix them.
I use a defect tracking system for this and apply all the usual defect practices.
I don't write a defect using the feature template. It simply isn't thought of as a feature - it is thought of as a defect. It is an entry in the defect tracking system and is identified and titled accordingly (just as any other defect in bugzilla - for example). E.g. SCR0016 - Sales tax incorrectly added to non-taxable purchases.
Hope that helps.
Jeff