Here's a brief and interesting article from Optimize magazine called The Silent Conductor. Managing technical people, especially your "A" people, will always be challenging (otherwise, they wouldn't be A-class people!) and this article gives an interesting glimpse into this but from a very different field than I.T. Having said that, I have often seen a correlation between music and A-class I.T. people...
Jeff
This is a web based application to help track progress when using the Feature Driven Development Software Engineering model. It was used successfully by a team of 16 student Software Engineers and contains all the basic functionality with regard to Feature Areas, Feature Sets and Features. It can be downloaded at http://fddtrack.sf.net and the forums or the mailing lists can be used for feedback and questions. The bug database can be used for possible bugs. For developers interested in extending the system, the File Release contains Documents which cover the
- Initial Requirements
- Detailed Design
eXtreme Programming folks complain about BDUF (Big Design Up Front)processes and occasionally accuse FDD of being a BDUF process because it builds an initial overall model.
My response is that FDD is not BDUF but JEDI - Just Enough Design Initially.
The rebuff is usually - how do you know what is 'Just Enough' to which I usually reply with tounge in cheek, 'it takes ability and experience to be a Jedi Master'.
However, my basic rule of thumb for knowing when enough modeling has been done up front is, when after one pass through the envisioned scope of the software in question, modeling in small groups does not produce any new classes or associations of real significance.
I've been wondering (again) whether or not we should seek a new name for the term "Feature" in FDD.
As we know a Feature is a post-modeling (post-analysis) artifact which describes a piece of client-valued functionality using Peter Coad's template - "action" "result" "object" and often with "parameters" added to the end of the term.
The trouble with the name "Feature" is that Marketing, probably correctly, thinks that they own it. Marketing Requirements Documents (MRDs) often contain the product features required for a piece of software. Product Features are not FDD Features!
Recently, I was forced to introduce, for a brief time, the term DWU (Development Work Unit). Our new VP of Marketing had declared "Marketing owns the feature list and Engineering has nothing to do with it". We were being asked to give up FDD and we couldn't do that, so we renamed Feature to DWU - even though everyone hated that term.
"If I have seen farther than others, it is because I was standing on the shoulders of giants."
I think it's important, in the interest of educating the public, as well as improving the state of the art, to share hard-won knowledge. With that in mind, I thought I might share a couple of tidbits from my own experiences, both with the FDD process itself, and with trying to track it.
I feel that the importance of choosing class owners carefully is a bit understated in the existing literature. In classes with Steve one day, he had us form a mock implementation team, and try to assign class ownership, and then schedule chief programmer worksheets and team assignments. The group I was a member of was, I felt, spending far too long trying to decide who should own what classes. The two CPs were trying to wrangle for important classes, because they felt the need to have some architectural control over the whole system. In the interests of getting the phase over with, so we could move on, I put on my Dictator Hat and randomly assigned classes to the teams, including giving the two CPs the classes they'd been eyeballing.
This summer, my company invested about 3 man-months on a web application for tracking FDD projects. We identified approximately 160 features that such a tool would need over the full lifecycle of a product.
Before myself and my cohorts were pulled off onto other things, we managed to implement approximately a third of that functionality. The outcome was, if a bit light on features, quite robust, and adequate for use with teams that are relatively new to FDD.
I am currently contemplating how to broach the subject of open-sourcing the tool, as it has no relevance to my company's business markets.
 | Lean Thinking : Banish Waste and Create Wealth in Your Corporation, Revised and Updated author: James P. Womack,Daniel T. Jones,James Womack,Daniel Jones asin: 0743249275 |
I wanted to draw your attention to a section in Lean Thinking by Womack & Jones, which describes a Toyota technique which they call "visual control" - I see this as the car industry equivalent of the FDD Wall Chart. There is a fascinating anecdote about the Toyota US distribution warehouses and how they use such a technique. The key point is that a wall chart similar to the FDD Feature List is already considered a best practice in other industries.
I have been reading a lot of material on efficient methods from other industriues and I am finding that a lot of techniques in FDD can be mapped against techniques in lean production and distribution systems.
Dear Sirs,
I want to call your attention to an interesting resource that may help developers that use workpackages.
When the CP does the design of new features he marks every method that related to the feature with a tag identifying the workpackage, like:
/**
*
* @workpackage SM001-013...
*/
public void getThisAndThat() {
throw new NotImprementedException();
}The developers may open all classes they own from the class owner list of the workpackage and search for the tag, browsing through them using F3 or any other location method. It allows for very fast browsing and location of all parts of the code that relate to the workpackage. In addition to that, if a programmer needs to touch any additional field or method to support a feature, he adds the tag to the modified piece of code. This process works the same both for designing and coding phases.
Research by the Cutter Consortium shows Feature Driven Development as the number 2 most popular agile methodology. The research also looks at the bigger issue of Agile vs Heavy methodologies and what percentage of projects are Agile. Read the research article here.
A study on the use and impact of Open Source and Free Software in the UK Government.
A very interesting whitepaper.
