Feature Driven Development

Phil Armour made this post against an old thread and seeing as it talks about cognitive factors in software - topic that interests me - I thought I'd start a new thread in reply to it.

I have a suspicion this (i.e. studies showing that inspections are more effecive than testing) may be both highly situational and a somewhat invalid conclusion, even based on the original data.

I'm a psychologist by background and I know that clear and pronounced results in any kind of behavioural study are quite unusual. There have been enough studies with clear results to show that inspections are both a very effective way of removing defects from software and much more effective than testing. Also I have never seen a study that shows testing to be more effective than inspections. Also I know from personal experience that inspections are very effective. So unless you can present new evidence your opinion is not significant.

I want to start with FDD right away. But an FDD implementation like Nebulon's Project Tracking System (PTS) still is not public available. Or is it free available and I don't know about it?

Giving my manager a clear view to FDD's benefit through such a tracking and report system, would make it much easier for me to convince him of the FDD approach.

Any hint from you except for writing my own PTS are very welcome.

This is in response to a request for a list of features. Would it be worthwhile for the community to apply FDD to the PetStore project which is rather well known in the java and .Net Community. This could then serve as a instructive application of FDD beginning to end ( the source code is already on the Net as well as a complete running example).

Others have done this using variants of the Unified Process.

Jeff states
"
Your request for an FBS from a real project is understandable but problematic - for several reasons. Features are very granular and therefore are very project and domain specific. This means that a small number features from a real project FBS are unlikely to make sense to someone outside that domain

This one has bugged me for some time and I heard a reference to it again the other day which has prompted to me ask about it here.

At last years Agile Development Conference in Salt Lake City, I was on a park bench panel with several others on Adopting Agile. The panel had been running for maybe half an hour and I happened to have one of the four "speaker chairs" at the time and I'd just finished speaking quite a bit myself. Alistair Cockburn came in and took one of the speaker chairs. He said that he'd just come from a presentation by Roy Singham, CEO of Thoughtworks, and Roy had said that to do Agile required 50% of the people to be experienced in Agile. Someone in our session asked Alistair if that meant 50% of the people had to be trained (e.g. had to have done an XP course - for example) and Alistair answered no. Not just do 50% had to have done an XP course, they had to also have done an XP project.

I came across a newsgroup post announcing a survey being carried out by the University of Cagliari on the adoption and use of Agile processes in industry. (Full details below.)

Comment moderation has been switched on. You can "mod" a comment up or down from a list of votes with scores. You cannot mod your own comments. When viewing a discussion thread, you can mod (vote) multiple comments and then at the end of the page click the Moderate button to register all your votes.

I've been browsing the forum recently and have found a lot of interesting discussions. However, it is a bit of a chore going through the topics on-line.

Would it be possible to have an archive of all of the forum discussions made available for download as a single document?

Sorry if this is already available and I've just missed it.

Thanks

Hanging out with XPers at the agilemodeling news group makes me realize how large the disconnect is between the XP people and me, and if I were to boil it down to one thing it would be they utterly fail to understand the need for large scale software development.

Their arguments invariably come back to, and I paraphrase, 'but its easier to do small scale development'. Of course its easier to do small scale development! But organizations don't large scale development for fun. Its hard! The risk of failure is high! And it costs A LOT more $$$. So why do large scale development?

We need to explain why large scale development is sometimes (and I would argue frequently) the only solution. Given our current state of understanding of software development.

There's an article at cio magazine titled Lies, Damned Lies and Requirements [cio.com] that has the following comment posted (by Paul, IT Manager, Boston) in response to it.

Having been involved with many large IT projects over the past 20+ years and I've witnessed both great successes and horrible failures. As for the failures sometimes the blame was on the business side for insisting on pie-in-the-sky requirements, but typically more often the blame belongs on the engineering side for under estimating work and overblowing promises. I've learned over the years that the single biggest factor in the success (or failure) of an IT project is the presence (or absence) of a mature, articulate, highly visibile manager over the project lifespan - who has credibility and solid support from management in both camps, and brings an ownership perspective to the daily squabbles that inevitably occur when business expectations are challenged and engineering realities hit home. Its futile to expect self-interested users OR engineering brainiacs to take the long view, when the best chance for success lies in a strong, proactive management approach - the prerequisite FIRST REQUIREMENT.

As Phil Bradley said to me in an e-mail, "...an interesting human factor, that I don't think I have heard articulated before."

It's a very interesting factor indeed. In these times of growing interest in, and adoption of Agility, there are some that are saying that a project manager merely

(or, as discussed in a another topic, into whatever you want to call the groupings)

To help me convinve my partners that FDD is the way to go, could someone please provide examples of feature lists, showing the Major Feature Sets, Feature Sets, Features, from real projects?

I read in a Coad/Yourdon book that Einstein said that example is the best teacher, and I must say I agree.

Thanks in advance