I just completed my first project using (a bastardization of) FDD.
The project was small, so I felt like I could leave out some pieces of FDD without too much impact.
Mostly I skipped through Process #1, #2, & #3 quickly and did a lot of reiterative design at each #4. However the real negative impact on the project came because I skipped the validation steps on #4 & #5.
Now, I'm beginning a 2.0 release of the project and am hoping to adher more strictly to FDD. Since I'm just starting to "Develop an Overall Model" I figured I should get some feedback.
The first thing I think I'll wrestle with is when I try to capture the customer's Wish list for 2.0 as a Feature list.
For example:
There are three main Objects in the application (Hold, HoldAvp, and Ware - as background, this is a QA Hold application for manufacturing).
The original intent was to have defect information associated with a Hold instance. The customer has asked to associate multiple defects with each Hold. After talking with the domain expert, it is clear that they actually want a defect per instance of HoldAvp. From a modeling perspective, it is clear what they want. However, this feature(set) will be too large for a single iteration.
Can anyone provide some hints on how to go about breaking this featureset into individual features?
Any help is appreciated. I'm reading as much as I can; but since I'm on my own trying to implement this methodology (if it's successful we might adopt it for all projects) I'm just trying to get as much feedback as possible.
Hi,
Whatever you do, don't skip the "Build a Feature List" step neither do it quickly. Make sure you have all business features listed. In the ned you have almost all but that does not mean that the step has failed.
This leads me to your statement:
"Can anyone provide some hints on how to go about breaking this featureset into individual features?"
If you are in the first phase this should not be an issue yet. But make sure that you have the most important methods in the Overall Domain Model classes. From this methods plus the documentation and interviews one should be able to build have a more or less stable list of features.
Basically what I do is that I start gathering an informal list of features, classifying them within Business Activities (Feature Sets), right during the Overall Domain Modelling process. I don't think about how big a feature set is at this moment. This helps me to understand what is at stake and develop a mind map.
Once I get in to "Build a Feature List" step I have something that I can use but it is still crude. After all features are listed, I start thinking about how work will be devided amongst CPs. So if I see that a given Business Activity (Feature Set) has too many features and concepts put together, I try to break it into smaller activities, and I take note of dependencies. If a domain expert talkes a lot of a particular Business Activity that is not listed usually I put it too, regardless if it is within the scope of another one already listed, but I take note about this dependency (my mind map).
But this is the last thing I do to my Feature List.
Lastly if you make a searh on this site over "Subject Area", "Business Activity", "Feature Set", "Major Feature Set" and FBS you will get more info about this.
Best regards,
Nuno Lopes
Which Phase am I in?
Sorry if this get's posted twice, I'm having some concentration problems this morning;')
Thanks Nuno. I'll continue reading through the site to make sure I get as much advice as possible.
As I go through Phase I, I think I'm confused about how features that we pass to CP are related to the customer's wish list.
So as part of Release II of my application, the customer would like:
1. Quicker Searching
2. Improved Search options
3. Administrative controls over "locked" records
4. Delineating products by assembly station
5. QA Hold can have more than one defect reason
I had been acting like this is my feature list. After I do a domain walkthrough and update the model I might add some granularity so that some of these items are feature-sets instead of features, but they still drive the Build a Feature List step.
Instead, should I be using their requests to update the model to support their new needs. And using the list of "new" methods/attributes to drive the "Build Feature List" phase?
For example,
Request Number 5 has the biggest impact. The resulting model will include some new objects, new methods and attributes like...
1. HoldDefect object
2. PalletDefect object
3. Hold.getDefectList()
4. Pallet.getDefectList()
5. Hold.defectCountThreshold
etc...
Does the implementation of those methods, and the grouping that they'll be passed to CP drive my Feature List and my Plan by Feature more than the original customer requests?
You need to grasp what a feature is in FDD and how it is defined
In FDD the feature list template is the following:
Subject Area
Business Activity
Feature
Where the description of a Feature follows the following pattern:
[Action] [Result] [Object]
The [Object] name is actually taken from you Overall Domain Model.
So within this reason I would say that your features (customer features) look more like FDD Subject Areas then actually FDD Features.
I've found out that when I'm discussing with a client and building the model I start having a picture of the Business Subjects and Business Activities that are implicit in his explanations. Features as FDD defines them in my little experience usually come up once objects are in place in the domain model.
So to answer your question:
"Does the implementation of those methods, and the grouping that they'll be passed to CP drive my Feature List and my Plan by Feature more than the original customer requests?"
The source of your confusion seams to be that you assume that the relationship between the methods you put in the model and the original requests of your customer is disfunctional. If that is the case then something is wrong with your model for the Overall Domain Model phase. In your example it seams that there nothing wrong with it. For instance when you state:
"4. Pallet.getDefectList()
5. Hold.defectCountThreshold()"
The FDD Feature is:
Calculate defect count threshold on a Hold
List all defects on a Hold
If you look at your methods in this way you can ask your client:
Do you need the system to calculate the defect cound threshold on a Hold?
If he/she sais yes, then the method is really a busines request isn't it? Isn't this feature part of the original requests.
But notice, you can have FDD feature that are not mapped to one method but several.
So again:
"Does the implementation of those methods, and the grouping that they'll be passed to CP drive my Feature List and my Plan by Feature more than the original customer requests?"
Oh definitely yes. IMHO in the end of the day what matters the most is the management of what is to be actually built, or being built. Not the customer initial vague requests that usually I consider to be more like Subject Areas to discuss and elaborate until a full FDD Feature List is set. The nice thing is that the Feature List template when used well actually allows one to build a list that is both understandable by the client and developers.
Another point is that in FDD, CPs actually should participate in the feature list build up. IMHO this is not mandatory but by experience it greately helps comunication between developers and analysts.
Hope it helps.
Nuno Lopes
Another example...
Thanks again.
If no one minds, I'm going to keep describing the steps that I'm going through in this thread. Maybe it will help others that are new to FDD. But again, I'm hoping to get some group mentor-ship.
So I have a single request from the customer.
1. Options for "Search" screen including limiting the results, and providing sort options.
After more analysis, we decided on these 5 options
1. Don't show any "QA Holds" when the app first starts, the app will load more quickly.
2. Show Holds only , no non-failed Audit events (right now all QA Holds are shown along with all Audits that didn't show defects)
3. Date Specific (show QA Holds in a date range)
4. Override, so a user can see all QA Holds
5. All "QA Holds" created for a single Pallet (Pallets can be placed on Hold for QA events).
From this list, I modified my existing model and decided I need to add the following methods/objects
Object
class DateRange {
property Date startDate ;
property Date stopDate ;
}
Methods on Hold
public List getHolds(DateRange dateRange)
public List getHolds(Date date)
public List getHolds(AuditRec auditRec)
public List getHolds(Pallet pallet)
So my continuing questions...
Would each of these be a "feature" grouped under the "Search" featureset?
These are all simple.. Maybe an hour to code/unit test each piece. So I'm confident I can get the coding done in a day. Considering the percentages applied to the DBF/BBF phases, would it be appropriate to to infer that the coding will take 45% of the total iteration... So a day to code means 2 days to complete this feature (so if my iterations are 2 days long, this is the only feature I can complete during this particular DBF/BBF cycle?
A side question to all this is that my view of Modeling considers UML artifacts. UI is lacking there. Do you all use screen mockups as part of your modeling. If not how do you handle additional complexity that comes from UIs that don't map directly to object model functionality. Or how do you handle (in Struts, for example) Action classes, ActionForms, Validation frameworks, etc...
And I forgot...
Back to Nuno's comments that features statements have a suggested "form"
Calling getHolds(AuditRec rec) on Hold would be formed as
Action - Result - Object
1. Retrieve all Holds associated with specified AuditRecord from HoldDAO
2. Retrieve All Holds within date range from HoldDAO
I notice that I already exposed some errors in my modeling... Am I on the right path?
Subsequently, I have a service layer that interacts with the UI and hte DAO...
1. Retrieve All Holds for a specific AuditRec from HoldService?
etc...
Are those two Features for each feature?
Interesting questions
Glad to help. Jeff is the right guy to answer your questions, maybe he can correct me if I'm wrong.
"Would each of these be a "feature" grouped under the "Search" featureset?
These are all simple.. Maybe an hour to code/unit test each piece. So I'm confident I can get the coding done in a day. Considering the percentages applied to the DBF/BBF phases, would it be appropriate to to infer that the coding will take 45% of the total iteration... So a day to code means 2 days to complete this feature (so if my iterations are 2 days long, this is the only feature I can complete during this particular DBF/BBF cycle?"
Very interesting questions. When building my overall domain model I leave out issues such as you are putting unless the functionality reveals it self to be complex. In your case I would have only the method getHolds. So one feature would decribe all the scenarios you are giving.
I have stated that a feature can be mapped to more then one method. Not only it can but IMHO is the most common scenario.
IMHO FDD is a turn key method when you are building a software system with a rich Problem Domain. Within this contextthe Overall Domain Modeling phase shines, so does the feature template (action, result, object). In other words it is a an excellent method to tackle Problem Domain aspects of a project (search for Aspect on this site). Onde you are out of the context this aspect you need to be more creative as there are no formal method to tackle for instance the User Interface aspect of a project as far as I know.
In your example there are two distinct but complementar contexts regarding the development. One is the Problem Domain describing the business entities involved and their business rules and collaborations, another is the UI.
What I do to deal with the UI, I basically bend the method to fit my needs. That is, while doing the Overall Domain Model i also do what I call the Overall User Interface Model. To this, one designs the screens (I use Visio, or even UI Prototypes developed quickly with Visual Studio) and give them an Label (Views). I call this screens views. So my template for a feature within this is still the same as FDD, but istead of refering to objects on the Domain model they refer to the User Interface Model. Again in your example in phase one I would leave out the details regarding all the diferent views necessary to display the Hols until the design on DBF phase.
Remember, according to what I've read on this site the ration between the time it takes to develop an Overall Domain Model, and in my case it also includes the Overall UI Model, and the time it takes to develop the software, is of 1 week of modeling to 3 months od development.
Read this article for more info:
http://www.featuredrivendevelopment.com/node/527#comment-171
So you need to practice in deciding what is important to be in your over all Models. If you already spent a week on this phase while the deadline of the project is within three months, you are running out of time :) (just a teaser)
Hope it helps.
Nuno Lopes
One more thing!
I've noticed that I've not commented part of your question.
".... would it be appropriate to to infer that the coding will take 45% of the total iteration... So a day to code means 2 days to complete this feature (so if my iterations are 2 days long, this is the only feature I can complete during this particular DBF/BBF cycle?"
By experience this kind of inference does not work! IN FDD what I estimate is the time it would take to implement a Business Activity not features individually and set a feaseble date for its delivery.
During the planning phase I usually build a matrix stating the dependecies between Business Actities. I also set some complexity value to each of them, usually based on past experiences or when non at all, based on the number of entities (classes) involved in its implementation. Then based on the complexity value, plus number of resources potentially involved for its completion and the dependency matrix I give delivery dates for each business actitivity.
Thanks again
I thought everyone was ignoring my posts;') So I stopped reading for a week.
In the meantime, I think I've been understanding FDD more in the terms that you're describing. Thanks for clarifying.
Since the last couple of posts, I've changed to working through the object model do the level of methods/attributes. Then backing up to include a group of related methods into a single "feature"... And grouping those features in related feature sets.
For example:
Hold.Comments
HoldForm.Comments
HoldForm.AVPDefectsList
LocalHoldDAO.update
LocalHoldDAO.insert
HoldAvp.isOnHold
HoldAvp.Defects
HoldAction.AddAvp
HoldAction.AddOrUpdateDefectsList(Defects)
DefectList(AVP, Def1, Def2, DefComments)
becomes
1. Add Comments to Hold
2. Verify whether an AVP is already on Hold
3. Associate multiple defects to list of AVP
These are less granular (but still fit in my 2 week iteration) and they bridge the "language" barrier for the user between object modeling and user requirements.
It looks that you are on the right path.
By experience no one ignores your posts on this site. But it takes time to understand eachother, time that most of us don't have much, but still an answer will alwasy come by.
"These are less granular (but still fit in my 2 week iteration) and they bridge the "language" barrier for the user between object modeling and user requirements."
I also went throught what you are doing. Once you feal confident about how the method works you start using a top down approach the definition of your feature list more fluently. That is for instance, you will probably leave out DAO and Facade methods such as the DefectList from your Overall Domain model as this turn out to be more within the scope of System Architecture Design then the Problem Domain.
Anyway, IMHO good job.
Best regards,
Nuno Lopres
Use the Business Language the most you can!
I aso would suggest to use the business lanaguage the most you can when defining the features.
For insance, instead of:
"Add Commennts To Hold" use "Make comments to a Hold"
etc.
Althought in you head semantically they are equivalent, for a business person makes all the differnce. The point is that the first is more in terms of how you see objects has data structures (Collections, Trees etc) weather the second really exposes the feature has an action that a person takes every day.
For instance, a consequential feature could be:
Revise a comment over a Hold"
"etc etc.