Hello Everyone,
I have visited your site several times now and I have found the discussions very informative & thought provoking. They have helped me put my experiences with feature driven software development (in general but not FDD in particular) into perspective. I want to make this distinction since my experiences did not involve the use of the FDD methodology as it is proposed in this site, but rather, with ones where the product features drove the release schedule as well as the development (i.e. incremental release, themed release, Staged Delivery, etcâ¦). I think that FDD is definitely more evolved than these others, but it too needs some more refinement, which of course is one of the goals of this site. Nevertheless, after having worked with RUP & XP, I truly think that FDD is the way to go.
I am currently writing a book on SQL Server & .NET and I have dedicated a chapter section (55 pages) to feature driven software development. In it, I talk about my experiences in detail, from my observations of how features drove the development, techniques & documents used, pitfalls & successes, as well as proposals & recommendations of how to improve the methodology. My proposals & recommendations are from my experiences, but they certainly can be applied to a lot of the issues that I have seen discussed here on this site. I didnât want to refer to the methodology as FDD, so I called it FDSD (feature driven software development). Hereâs the structure of the section, along with its subsections:
Project, Configuration & Change Management
- UP, XP, FDD & Feature Driven Software Development
- Project & Configuration Management with FDSD
- The Critical Path & the Multi-Dimensional Feature Set
- Feature Discovery, Definition, and Documentation
- The Feature List & Feature Set Model
- Feature Prioritization
- FDSD, Agile Modeling and the Unified Process
- Mix n Match
- Change Management with FDSD
In addition to my proposals, I also provide three table definitions to store feature information, as well as several stored procedures (in SQL) to do the joins to retrieve & present them properly. I also discuss how to present the feature set & the feature dependencies so that they are easily understood & navigated. If any of you would like me to share my experiences, observations & proposals (Iâll have to draw the line on withholding the table defs & stored proc code), just let me know.
Regards,
TS
Why change the name?
Unless you've significantly changed the process a name change would seem only to promote confusion amongst your readers and the community.
If you have changed it significantly, then perhaps you shouldn't be using a name that's so similar it's virtually the same thing.
By all means, let's keep the
By all means, let's keep the name (FDD). My goal wasn't to change it. I just didn't want to take the liberty of referring to my proposals/recommendations as FDD (although they could be seen as just a variant of FDD) . For now, I do want to call attention to the distinction between the two. Ultimately, I just want to present my proposals/recommendations, and whichever makes sense to the community we can incorporate it in. Sound good?
If it's product development then the FBS reflect that
product features driving the schedule doesn't sound different to me. Care to elaborate? I have extensive product development experience (small and large scale) and have applied FDD to product development numerous times. It might be an interesting discussion to see what you do differently.
Jeff
feature driven release/delivery schedule VS actual FDD
Hi Jeff,
First off, I just want to say that you (as well as the other contributors on this site) have done the community a great service by providing/supporting this site. I was able to relate to a lot of the issues and it also has put a lot of things into perspective for me. I definitely think that it is an excellent foundation to build on. Hopefully, I can contribute a little towards the cause. On the subject of my background, most of my experiences come from projects for a corporate banking application, a private banking application, a mortgage banking application, an application integration effort for a stock exchange, and at a startup building an EBPP (electronic bill presentment & payment) system.
In my experience, features have always driven the development of a software product. It didn't matter what methodology was used. The development focused on building what the stakeholders, clients, or customers wanted. Of course, there were discussions/negotiations on whether a feature be included on the current release or be scheduled for the next release. Ultimately, a release schedule outlining which features would be included with each release was agreed upon. Simply put, high priority or core features were put on the current release while mid to low priority features were candidates to be put off till the next release. Sometimes, the product's defined feature set for each release was of utmost importance and the release schedule was made a little more flexible. Other times, a hard deadline was imposed and we had to decide which features we could realistically build within that time frame and put everything else off till the next release. As such, I see this practice as more of a feature driven release/delivery schedule than actual feature driven development, although it did somewhat drive the development of the product's features from a higher level. I then see actual feature driven development occurring at a lower level when dependencies between features that comprise the entire feature set for a release dictate the prioritization and development of each feature along the critical path of that release. As mentioned in one of the threads here, a development project requiring a holistic delivery of a software product can still implement FDD since the feature dependencies drive the development and not necessarily the release schedule.
TS
Features
sorry for the delay but I'm really busy at the moment and this will only be a short reply.
sure, features should always drive it. I think the rest is really wordplay. What I'm saying you can do with the FBS in FDD is connect both. I don't make the distinction you do in terms of one being feature driven development and the other being features determining releases. I'm saying by thinking in terms of features and using FBS instead of WBS to drive and track projects you connect both. As you move up the FBS hierarchy, there is great value and great communicability. Down at the lowest level, yes you have the features driving development. I use the one way of thinking and one mechanism to connect these two normally separate things.
Jeff
No prob. I'm sorry for the d
No prob. I'm sorry for the delay on my side as well. Been pretty hectic lately.
I agree that there's definitely a connection between both. Either one can affect the other. And maybe it is just semantics, but I wanted to point it out since it is a foundational concept that can be misunderstood at times. A change in the defined feature set for particular release can certainly pull the rug under the prioritized feature list that is driving the development. And the discovery of an issue with a lower level feature can either push back or bring forward the release schedule for a higher level feature. Usually at this higher level, a steering committee is involved but at the lower level (component & object level features), there is usually no need for the steering committee to prioritize them. Once a particular feature (either high or low level) is prioritized by the business side, the prioritization of component or object level features that are related to it (or defined or discovered from its decomposition) would be moot to them. This is because all that they only usually care about is for that feature to be implemented on the scheduled release date. They usually wouldn't care about the details of how that feature's development progresses, let alone how its component or object level features are prioritized.
TS
No comments anyone? In that
No comments anyone? In that case, let's move on to the differences...for one, I don't think that the activities of developing an overall model, building a feature list, planning by feature, etc. really happens sequentially. I see them as happening in parallel, with a feedback loop cycling between these activities. This is because during the planning, designing, and building stages, there is a high probability that more features will either get requested or discovered, and some features may even get redefined. I've seen this happen at as late a stage as user testing. In any case, there's a possibility that the overall model will change, as well as the feature list and the class designs. This will necessitate a feedback loop that will have to cycle back & forth between these activities/stages. With this new information (new feature requests or discoveries, feature redefinitions...), the prioritization or sequencing of features may also change. The critical path (or the development sequence as it's called here) may need to get revised. It should then be flexible enough to be revised with this new information and the development adjusted accordingly as well.
Another difference is the need to acknowledge that a product's feature set is multi-dimensional. This is because I see features existing at three levels: the application or system level, the component or module level, and the object or class level. An application level feature can be decomposed into multiple component & object level features that should be recognized, defined, & documented individually. Another element that adds to the feature set's multi-dimensional nature is that each feature?s definition, composition, or decomposition can span across multiple subject areas, components, or objects. Because of this, I see a need for a better way to document & present the feature list. The old (or perhaps current) way of doing it with an Excel spreadsheet just doesn't cut it anymore.
TS
Yes, but FDD works that way anyway
I do see the modeling process as sequential (meaning it should be done first). it sets everything for the project. You are absolutely correct about the features list and planning processes though. I absolutely do them in parallel, iterating from one to the other as you describe. (I'm actually working on workshop materials for this very topic).
Having said all that though, you can certainly come back around from DBF and BBF and execute the first three processes again. That is common (e.g. for enhancements, major maintenance or defect work, or for areas of the domain that weren't ready when you started).
The thing about feautre and the FBS in particular isn't how you arrive at it. But that you apply the thinking of features and communicability and value. People have got hung up on this before - looking for the prescription for how to build the FBS. It's the least important aspect and it shouldn't be prescriptive either. It's the approach of defining an FBS and not a WBS that is the important thing. So, it doesn't really matter how you arrive at the hierarchy or how many business activities there are (for example). I'll often tweak that subject area<->business activity structure simply for communicability (and value) and the CPs then enumerate features within that structure.
I don't follow all of your multi-dimensional points. Explain some more please?
I've never used excel for the FBS.
Jeff
I agree that a good portion o
I agree that a good portion of the design/model needs to be done in order to get a good idea of where development should head to. And it looks like we also both agree that there will be trips back to the drawing board, if not for just some minor mods.
As for the FBS/feature set, I also agree that it is not something that one sets out to build. I see the building of the FBS/feature set as more of a shadow or supporting workflow. That is, it is more of a documenting effort as features get requested or discovered from doing the other workflows (e.g. requirements gathering, modeling, etc...) on specific subject areas or business activities as well as during change requests or fixes for defects. However, at a certain point there will be the task of decomposing or breaking down (or enumerating as you refer to it) higher level features to reveal or discover the more granular lower level feature definitions. There is also the possibility of having to define upper level features to serve as "supporting parents" for lower level features. Here is an excerpt from my book which I'm just going to copy & paste here as it explains my viewpoint a little better:
When I decided to write this book, I picked up a book on how to write books: "The Self Publishing Manual" by Dan Poynter, which is one of, if not the leading book on the subject. In it, Mr. Poynter recommends that one write the content for the back cover of the book first, then the book's table of contents, and then pick particular sections or chapters to write. He also specifically recommends to not write the chapters sequentially, but instead on whatever order flows better.
Although I picked up Mr. Poynter's book before I wrote this book, I didn't read it until after a couple of months into writing this book. Fortunately, I was doing exactly what Mr. Poynter had recommended. What struck me as interesting was that by not being restricted to writing the book's chapters sequentially, I allowed myself to work with data or informational dependencies of the book's content from one chapter to another, to "go with the flow" so to speak. This is because a book's table of contents organizes the book's contents in a way that makes it easier to read or understand, but, from the author's standpoint, writing the content may not be as straightforward of a process. As such, the ability to prioritize the writing of the chapters from the content generation standpoint makes the process of writing the book flow better for the author.
Writing has long been used as a metaphor for software development, but I think that this approach provides a different twist to it, one of thoughtful planning & design, which can, to some extent, be applied to with feature driven software development. Writing the back cover of the book is like declaring or defining the system's high-level features. The definition of these system level features then sets the foundation for the definition and discovery of component level features, just as the bullet points in the book's back cover guide the creation of the book's table of contents. And just as a book's table of contents sequentially presents the book's contents but doesn't dictate the sequential order of the content creation, the definition of component level features guides the definition and discovery of object level features but does not sequentially dictate them. This order is determined by the author's consideration & analysis of chapter or section dependencies to lead him to write along with the flow, and so should the prioritization of features at all three levels of the system. The author's draft or outline of a chapter is similar to designing a class, as he lays out the structure of the chapter's contents & how the it will flow. And lastly, the outline of each chapter's section is similar to the conditional logic of the code in the methods of the class.
However, this drilldown approach to defining & discovering a software product's features is not an absolute rule. In preparation of writing this book, I wrote down notes on specific content that I wanted to write about, some of which served as the basis for some of the bullet points on the back cover, some I was able to group or assign into bullet points or chapters I had already created, and others became the genesis for new chapters & sections.
In FDSD, the significance of this dynamic is that a lower level feature that is defined or discovered must belong to a higher level feature, otherwise, it will necessitate the definition or creation of one. An example of the latter was a feature definition in the corporate banking system that I mentioned above. Here, a request to have triggers that tracked the values of certain portfolio data and flag them if the values go outside predefined boundaries generated a need for an entire component that managed all the triggers. It also initiated the creation of a key service that we called "My Alerts", which periodically sent notification messages on specific triggers that the users subscribed to. In this case, the definition of an object level feature helped define & created the need for system & component level features.
In all fairness, I think that the drilldown approach is more common, and that features at the application or system level usually get defined or discovered first, as they are usually described in non-technical terms in initial project requests originating from a customer, a stakeholder, or a business user. Component or object level features usually get defined or discovered next, through the decomposition of system level features and analysis of business requirements documents and system design or modeling documents. The exceptions to this drilldown path is when a feature is initially defined at a low level and has no existing higher level feature that it can be grouped or assigned to, as in my example above.
One thing to note is that, in a drilldown approach, the decomposition of the higher level feature usually yields multiple lower level features while the bottom up approach will usually yield only one feature at each corresponding higher level.
Here are two examples of how features can be defined, one from a drilldown approach and the other from a bottom up approach:
Drilldown Approach
1. Application level - a request or requirement to be able to electronically send purchase orders & payments
2. Component level - decomposition of application level feature definition as the ability to send payment messages in EDI as well as ebXML. Technically translated, this would mean creation of classes that format a payment record into an XML or EDI formatted transaction message. If the current product only formats in EDI, the addition of a class or routine that formats messages in ebXML should be considered as a new feature.
3. Class or object level - routine that retrieves payment records from database or one that does the actual message formatting. Also could be routines that do the actual socket handling & messaging. Same rule applies here with multiple object level features supporting component level feature.
Bottom Up Approach
1. Class or object level - function or routine to automate & handle events on embedded Excel spreadsheet object, check for values violating trigger rules, then flag them by coloring cell background a predetermined color (with a legend provided), and finally saving triggered value information in the database.
2. Application level - "MyAlerts" service, part of main user interface & supported by periodic automated notification messages from specific triggers
3. Component level - Alert class (clsAlert) running on a timer in a separate thread & periodically checking for ?triggered? triggers by executing a stored procedure that checks for trigger information entered into database by function or routine mentioned above.
As you can see, a feature may be decomposed into multiple features that exist at other levels or subject areas, it may end up defining other features that complement or supplement it, or it may be defined differently at the different levels of an application. This complex and multi-dimensional nature of a feature set requires an accurate & organized way to document it. Only through this can all the features of a system, including the complementary or supplementary features that might get defined or discovered along with the definition of a certain feature, as well as the different definitions that the feature is seen as or decomposes into at different levels or subject areas of a system or application be documented accurately & properly. By doing so, it would make it easier to track, manage, change or re-prioritize features at the team, as well as the project level. After all, as the old saying goes, "One cannot manage what one doesn't know".
I use a naming convention to assign a code to each feature that is documented. This provides richer information about each feature. Here's the naming convention codes that I use:
1. FR - feature request
2. DF - discovered feature
3. CR - change request
4. DR - defect report
By storing each feature with this naming convention (or one similar to it), it will be easier for features to be retrieved and presented as a feature tree through a tree view control embedded on a form or some interface. And like a use-case tree, a feature tree can provide a global view or overall picture of a system that can easily be drilled down upon.
I also take a different tack on how the feature set is documented & presented. I use tables in a relational database to store the features and their position in relation to the other features. I then use a tree view to present the feature set. The good thing about using a tree view control is it allows toggling between showing/presenting the feature set/FBS from a three level point of view, a subject area point of view, or a feature dependencies view.
Here's an example of a drilldown or gradual opening of a feature set implemented with a tree view control: First, with all three nodes closed:
+ System Level Features
+ Component Level Features
+ Object or Class Level Features
Then, with the system level node opened:
- System Level Features
1. FR 1-S: Electronically sends purchase orders
2. FR 2-S: Electronically sends invoice
3. FR 3-S: Electronically sends payments
+ Component Level Features
+ Object or Class Level Features
The feature numbering or naming convention can use any number before the letter designating the feature's level (e.g. FR 234-C). This way, this practice can easily be integrated with the numbering sequence of the project management or defect tracking software that the team is using. The feature number can be used in the body of an email to better track a thread discussing a certain feature. I'll discuss this further in the Change Management section.
Then, with other nodes opened:
- System Level Features
1. FR 1-S: Electronically sends purchase orders
- Component Level Features
1. FR 1-C: Database access component
- Object Level Features
1. FR 1-O: Retrieve specified purchase orders routine
2. DF 1-O: SOAP call to retrieve purchase order data in XML
3. DF 2-O: Database configured for XML retrieval
2. FR 2-C: Message formatting component
- Object Level Features
1. FR 2-O: EDI message formatting routine
2. FR 3-O: ebXML message formatting routine
3. FR 3-C: Messaging component
- Object Level Features
1. FR 4-O: Message sender routine
- Object Level Features
1. FR 1-O: Retrieve Purchase Orders routine
2. FR 2-O: EDI message formatting routine
3. FR 3-O: ebXML message formatting routine
4. DF 3-O: Message sender routine
2. FR 2-S: Electronically sends invoices
- Component Level Features
1. FR 1-C
- Object Level Features
3. FR 3-S: Electronically sends payments
- Component Level Features
- Object Level Features
- Component Level Features
1. FR 1-C: Electronically sends purchase orders
- Object Level Features
2. FR 2-C: Electronically sends invoices
- Object Level Features
3. FR 3-C: Electronically sends payments
- Object Level Features
- Object or Class Level Features
1. FR 1-O: Retrieve Purchase Orders routine
2. DF 1-O: SOAP call to retrieve purchase order data in XML
3. DF 2-O: Database configured for XML retrieval (SQLXML)
4. FR 2-O: EDI message formatting routine
5. FR 3-O: ebXML message formatting routine
6. DF 3-O: Message sender routine
7. DF 4-O: DOM Level 2 processing
8. CR 1-O: Optimized query to retrieve invoices from DB
9. CR 2-O: Multi-threaded design for faster performance
Database objects such as stored procedures or user-defined functions should be viewed as component level features since they would support the execution of a component or module. Object or class level features can be a request for another field to be retrieved by a stored procedure, optimizing a Transact-SQL statement or a modified conditional logic or algorithm for a routine or function.
By being more granular in defining features, it makes it easier to assign specific tasks to individual developers. As such, GUI work can be specifically assigned to front end developers while database work can be assigned to the database developers. For example, if feature "FR 1-C: Database access component" needs to be built, it is better to break it down and assign FR 1-O & DF 1-O to a .NET or Java developer while DF 2-O should be assigned to a SQL Server or Oracle developer.
Another thing to note is that refactoring or redesigns can be considered as features. Take for example a request from Marketing (or even the CEO) that "the product should process invoices faster than the previous version (or our nearest competitor)". This business level feature request can be decomposed into two lower level supporting change request features CR 1-O & CR 2-O.
TS
How do you track progress?
How do you track progress with your approach?
TS: "No comments anyone? In that case, let's move on to the differences...for one, I don't think that the activities of developing an overall model, building a feature list, planning by feature, etc. really happens sequentially."
Where do you define the scope of the project?
In one way or another I do collect features during the first stage of FDD (Overall Domain Modeling) so I partly understand what you are stating. I really start defning the feature list during the first stage. But it is in the second stage the this list is concluded and matured. As for features that are collected later (during DBF/BBF cycle) they are added to the feature list but they are either "new features" or are what Andersen calls "dark matter".
It seams that there are fundamental differences on what you propose and what FDD purposes. What FDD purposes within the scope of "Feature management" is that in stage 1 and 2 almost all features (client valued functionality) are inventoried and you seam to indicate that this thinking is not practical in your experience, but maybe it is not practical for you becouse you seam to use a abroader definition for the word "feature" then FDD. The list of client valued functions (a.k.a features in FDD) or inventory is what makes the project trackable and everything manageable with great degree of accuracy, including scope creep. This is what creates focus amongst feature teams. The lack of this is what makes a Project Gantt chart not more then a political document.
TS: "This is because during the planning, designing, and building stages, there is a high probability that more features will either get requested or discovered"
The organization that I'm currently working with do work (do not use FDD) as you described and people feal like there is a high probablity that more features will be either requested or dicovered as you have stated. Everyone in this organization agree that the process needs to be improved in order to be more accuratly manageable (PM's currently feal unconfortable about their GANTT charts) and organized (CPs and Programmers don't know precisely were they are heading). It is common here that in the end the project sucess or failure is mandated by the effort of not more then a handfull of developers that are highly proactive but frequently reach the burnout stage. Last week I did a presentation on FDD to PM's, CA's and CP's and everyone was thinking - Why don't we use this? It is clearly feaseble.
At the technical level the problems that these people are not so much on partitioning funcionality in Components as as they are driven by technical aspects, but in what kind of information produced during analysis is really usefull. Furthermore which format for recording the information is more usefull for CP and developer in general. As a programmer I believe that the analisis process starts to be finished when one starts building and tailoring the database model and not before. As an analist I believe that analisis starts to be finished when the domain model begins do take shape. I don't care how many use cases one does, how many textual descriptions exist for a business process/activity (ex: "selling a product online"), or even how many components will it be needed to implement the system. Give me the domain model and I can start talking about it, stating rules around it or even extend it. The beauty is that the database model, component model and much more can be derived from the domain model. Furthermore programmers understand class models and know how to map classes to RDBMS tables or for instance an XML Document if that is the kind of persistance required.
Best regards,
Nuno Lopes
Hi Nuno,Hope all is well.
Hi Nuno,
Hope all is well. I'm very glad to hear your comments (on this and on the two other posts below). I am very sorry that I haven't been able to respond in a timely manner. Unfortunately, this week is very very tight for me. I will try to respond by early next week, possibly Sunday if I can. I've skimmed through your posts and already I can think of a hundred things to say. I'll try to find the time to answer all of them soon.
Kind Regards,
TS
*****************************
***********************************************************
Nuno,
I hope you had a wonderful holiday season and I wish you a Happy New Year. I am very sorry it's taken me forever to respond. As time permits, I'll try to answer your questions below as best I can.
Best Regards,
TS
***********************************************************
How do you track progress with your approach?
***********************************************************
In my book, I provide several table definitions & stored procedures to store/record and track the progress. I also recommend how to graphically present the feature list/feature model. Since it was not my intent to provide an actual software product, I left this open for anyone to build a customized front end application using the database objects that I provided. One implementation would be similar to the MS Project screen. One of the columns in the main feature table is for PercentDone, so the totalling functionality that Project does can easliy be done. The main MS Project screen is actually not a bad way to visually represent, track, and manage a project's feature list/set. The downside of Project is that it's a one user app - hence the creation (and ensuing popularity) of MS Project Server. By implementing it as a web based collaboration app, project team members can simultaneously work in it. It may not be specialized for FDD/FDSD, but it'll work fine for tracking & managing the feature list/set. Other project management tools/apps that come close to what I had in mind are Axosoft's OnTime 2004 version and Logic Software's Easy Projects (and I think both are less expensive than Project Server).
***********************************************************
TS: "No comments anyone? In that case, let's move on to the differences...for one, I don't think that the activities of developing an overall model, building a feature list, planning by feature, etc. really happens sequentially."
Where do you define the scope of the project?
***********************************************************
With most projects, it's hard to get around not doing a high level doc such as a BRD. Also, I still recommend using a domain model for the technical notation. In my current engagement, we're on a themed release schedule with each phase focusing on a grouped set of features that addresses a particular business need. In our BRD, we state something like: "In Phase one, we are focusing on providing the abliity for the system to do this & that..." We then provide a complete breakdown list of the features included in that release. The feature set for each release spans multiple platforms, multiple components/modules, and affects countless procedures, subroutines & functions.
***********************************************************
In one way or another I do collect features during the first stage of FDD (Overall Domain Modeling) so I partly understand what you are stating. I really start defning the feature list during the first stage. But it is in the second stage the this list is concluded and matured. As for features that are collected later (during DBF/BBF cycle) they are added to the feature list but they are either "new features" or are what Andersen calls "dark matter".
***********************************************************
During an initial project meeting or business elaboration session, there's a good chance that features will be requested by a project stakeholder or user. Some may be crystal clear and some may need to be drilled down on or broken down into subfeatures. And in my experience, things change & priorities change along the way. Because of this evolving, shifting nature of software projects, one's methodology should be flexible enough to adjust to either feature/scope creep or new discoveries that can shift priorities and change the feature set further down the road. In my current engagement, we changed phase themes on the fly - as things made more sense (from deeper analysis and as we got more requirements in), we changed themes, shifted some features back to later phases and brought some forward. If we didn't, we'd be building features that weren't need for that particular release, pushing back the release date unnecessarily.
***********************************************************
It seams that there are fundamental differences on what you propose and what FDD purposes. What FDD purposes within the scope of "Feature management" is that in stage 1 and 2 almost all features (client valued functionality) are inventoried and you seam to indicate that this thinking is not practical in your experience, but maybe it is not practical for you becouse you seam to use a abroader definition for the word "feature" then FDD. The list of client valued functions (a.k.a features in FDD) or inventory is what makes the project trackable and everything manageable with great degree of accuracy, including scope creep. This is what creates focus amongst feature teams. The lack of this is what makes a Project Gantt chart not more then a political document.
TS: "This is because during the planning, designing, and building stages, there is a high probability that more features will either get requested or discovered"
The organization that I'm currently working with do work (do not use FDD) as you described and people feal like there is a high probablity that more features will be either requested or dicovered as you have stated. Everyone in this organization agree that the process needs to be improved in order to be more accuratly manageable (PM's currently feal unconfortable about their GANTT charts) and organized (CPs and Programmers don't know precisely were they are heading).
***********************************************************
Having a theme for each release really helps set the context, priority and focus of each feature set.
***********************************************************
It is common here that in the end the project sucess or failure is mandated by the effort of not more then a handfull of developers that are highly proactive but frequently reach the burnout stage. Last week I did a presentation on FDD to PM's, CA's and CP's and everyone was thinking - Why don't we use this? It is clearly feaseble.
At the technical level the problems that these people are not so much on partitioning funcionality in Components as as they are driven by technical aspects, but in what kind of information produced during analysis is really usefull. Furthermore which format for recording the information is more usefull for CP and developer in general.
***********************************************************
Having a field in the feature table to record requirements and business logic also helps.
***********************************************************
As a programmer I believe that the analisis process starts to be finished when one starts building and tailoring the database model and not before. As an analist I believe that analisis starts to be finished when the domain model begins do take shape.
***********************************************************
I would have to disagree on both points. I think that to be agile, one has to be ready to analyze any new information as it comes or gets discovered, set it into the context of that release or the entire project, and decide what effect it has, if any.
***********************************************************
I don't care how many use cases one does, how many textual descriptions exist for a business process/activity (ex: "selling a product online"), or even how many components will it be needed to implement the system. Give me the domain model and I can start talking about it, stating rules around it or even extend it. The beauty is that the database model, component model and much more can be derived from the domain model. Furthermore programmers understand class models and know how to map classes to RDBMS tables or for instance an XML Document if that is the kind of persistance required.
Best regards,
Nuno Lopes
my experiences with feature driven software development
Hi:
I am interested in your book on SQL Server & .NET book. Could you please let me know if the book is available now and if so where can i get it.
Thanks.
Bob
Hi Bob,The book is availa
Hi Bob,
The book is available online. The main page is:
http://www.in-the-trenches.com/mssql.net/default.asp
Regards,
TS
Hi!
Your classification is interesting and at first sight complements the FDD approach. Nevertheless the definition of "Feature" seams broader then FDD and I don't know if that is good for understanding your approach. In FDD a feature is a client valued function or funcionality. It seams that you apply this concept only to what you call "System Level Features". In that case the naming is misleading at first sight. In FDD everything as a very specific scope including namings, that is what makes it so clear.
At first sight as for other the categories you have defined ("Component Level Features" and "Object or Class Level Features") do complement the FDD approach for building a Feature List but at a lower level. Basically the features in this groups are only derived later during the DBF stage or on some separate process; Overall System Architecture Design. In other words you may or not may track them for Project Mangement purposes neither to measure progress
Nuno Lopes
Your line of thinking regarding Components!
You assume that at some point features (business features) need to be mapped to components. FDD does not make any considerations regarding this technical aspect as in some projects this is not the case. But even if it is the case then may you would be interested in reading the following:
"http://msdn.microsoft.com/architecture/journal/default.aspx?pull=/library/en-us/dnmaj/html/businesspatterns.asp"
Althought I don't think that the proposed definition of a business pattern is really a good one, but it is one amongs others that should be taken into account.
Nuno Lopes
PS: As a side note. IMHO a Business Pattern should be defined as a set of business activities and their respective domain model rather then a set of Components as the article argues. This is becouse the domain model does not impose any model for partioning logic into components. This is close to how we preceive business logic and information at a non technical level. This makes a Business Pattern far more reusable across multiple technical architectures and undestandable. But this is a another story.
It's quite similar to my reco
It's quite similar to my recommendation of using themes for each release or phase. It helps set the context and the focus of the everyone's efforts.
I agree, from a semantics poi
I agree, from a semantics point of view, it can be (misleading). I do state here and in the book that a client valued function (a feature request or requirement) can be recorded as a component or object level feature. Take for example, a request for a screen to be automatically minimized when a user does something or for a background thread that does printing formatting to execute faster - these are low level feature requests. And these can come early or later in the project. Usually, if the project is to build a newer, better version of a currently used app or system, these low level requests can come early.
Shift work possible for software development?
Hi. I'm working for a software development work and I'm in charge of resource management. I am wondering if it is possible for the a work package (i.e. smallest unit in a work break down structure) to split the work into shifts where there could possible be two person developing the module. Would appreciate your comments.
Dylan Khoolim
Yes, but...
Hi Dylan,
sure you can have different people working on the features in a workpackage at different times. It's now what I do or recommend as I use class ownership to drive the assignemnts for a workpackage (see other threads on class ownership linked at this site's front page for a discussion of this).
If what you're trying to do is keep two shifts busy, then you should instead be creating workpackages that are cogniscent of who is available for a given shift. In fact, this is no different really than the standard planning a CP does when deciding what features to put into a workpackage.
Jeff
Shift Work fo software development
Hi, Jeff:
Thanks for your tip. I think so far I've tried whittling down my work packages in my WBS to a pointe where it is possible for handovers of a particular piece of work. Let me provide a little more background, in the company that I work for, we are under tremendous time pressures, i.e. the schedule is very tight. This in turn sometimes does impinge on the quality of work which is exactly what I don't want. The idea is that when time is short, I pile on the resources to make up for the shortfall in time. This seems to work but it requires double and sometimes quadruple the effort in communication. Is there an easier way of using double the resources to complete the task?
Many thanks.
Gratefully,
Dylan Khoolim
shift work and communications
Dylan,
I'm sorry for the late post. Not sure if you still are in this situation, but if so, I'd like to let you know that I wrote a chapter section in my book on my recommendations for a methodology using shifts to implement a 24/7 development process. The entire content is available online at: http://www.in-the-trenches.com/MSSQL.NET/chaptersections/24-7FDSD.asp
I recognize that communication can be an issue and I recommended implementing an activity I called "Passing The Baton", where the programmer of the previous shift communicates with the programmer relieving him/her. Having the system requirements and/or feature definitions tightly defined makes a big difference here. So does having the business logic, GUI format, and workflow or screen flow. Having a tool to document & track these as well as each developer's progress and comments is essential too. All these will help minimize the miscommunication or variations on translation or implementation. If disagreements arise, then the manager is then called in to moderate or make the call.
BTW, where exactly do you have problems in communication? what do you mean by double or quadruple the effort?
Regards,
TS