Feature Driven Development

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

Hi all,

I'm wondering if I understand the purpose of Feature Team Areas correctly.

Suppose we use TogetherJ, and have created a TogetherJ project containing the overall domain model (ProjectName.tpr).
When starting a DBF process for feature A, do you guys create the design (sequence diagrams, modifications to the overall domain model) in this same TogetherJ project?

Or do you create a separate work area (read: a separate TogetherJ project) for each feature?

Thanks!
Rudy

The Agile Project Management E-Mail Advisor, is a weekly electronic briefing from Cutter Consortium's Agile Project Management Advisory Service. It is written by Jim Highsmith, Director, Agile Project Management Practice.

"... Two things struck me about De Luca's keynote address and half-day workshop at the conference. First, his focus on the people aspects of project management, and second, the simplicity and power of the "Parking Lot" for planning and monitoring large projects. The Parking Lot will be the focus of this Advisor..."

I'm not sure if it has been written down anywhere, but the original FDD project strongly believed in defensive coding techniques such as validating all parameters on entry to a method and the throwing of an exception for invalid parameters.

Recently, the trend towards test-driven development has pushed developers towards an "I don't need defensive code, it just slows the runtime performance. I can catch all my errors with my JUnit"

I'd like to solicit opinion on this from the community. I haven't made up my own mind on it and I'm open to suggestions.

Is test-driven development a replacement for defensive coding standards enforced at code reviews? Comments please...

This post stems out of a thread that Paul Szego started, in which rudy posed some questions about components and application layers, and which is probably dead, so I thought I'd start a new thread and share some of my experiences.

Firstly, business domain specific objects/components can not be reused across applications for the very simple reason they contain business specific data and if you 're-use' the object you must replicate the data, and data replication doesn't scale and is generally a bad idea in OLTP systems. Thinking back, I'm astonished we even tried.

So if I a create a customer component, I can not reuse it, but I need reuse. Every major application in a typical enterprise needs customer details. Every major application in a bank needs to debit/credit account. Every major application in a health care domain needs to charge insurer. I have never come across a business (domain) where the need to reuse things wasn't widespread.