Feature Driven Development

FDD says nothing how requirements are formulated prior to process 1 - Develop an Overall (Domain) Model. In fact FDD downplays the importance of formal requirements and stresses the importance of participation of Domain experts. I know in part this is due to Jeff's, far from unique, prior experiences with Use Cases!

I have commented that - Any idiot can write a Use Case, and most of them do! What I mean by this is that the Use Case format and notation is loose and you can put pretty much anything in a Use Case format. This problem is exacerbated by Business Analysts who, while they understand the business, often have a limited grasp of what software developers need and can use. An additional problem is what I call the paid-by-word syndrome - aka more is better!

The site has just been updated to the latest version of drupal. The "number of reads" against stories and comments (and other node types) is a new feature and these counts have only just been switched on. ***UPDATE*** The forums and Files section are back online.

I spotted this post on the Scrum Development list and thought it worthy of reposting here.

---------------------------------------------------------------------------

CALL FOR PAPERS

1st Workshop on

Knowledge Management for Distributed Agile Processes:
Models, Techniques, and Infrastructure
(KMDAP '03)

for the

Twelfth IEEE International Workshops on Enabling Technologies:
Infrastructure for Collaborative Enterprises (WET ICE '03).

I'd like to comment on something Jason Marshall posted elsewhere on this site, because the subject has been bothering me for some time - Agile processes encourage teamwork but how does the manager reconcile this with flexible working.

"I think in a real world, where people get pulled onto multiple projects, don't keep precisely the same hours, and occasionally find employment elsewhere, there's significant danger in assigning code ownership to a lone individual."

The basic problem is that events which require team working such as daily standup meetings, design sessions, reviews and check-ins, builds and integration testing, cannot be completed if all team members are not present.

In July I decided to explore the fundamentals of FDD by comparing it to XP. It turned into an attempt to formulate XP using the ETVX format, which proved to be very fruitful for the understanding of XP.

The blog entry is titled Understanding XP through FDD, and I'd appreciate any comments or corrections as I am sure there are points where I haven't understood FDD fully.

I've decided to make the 2nd draft of my forthcoming book, "Agile Management" available for a limited time on the web for public review.

The book is about management, control, cost justification and executive reporting for Agile software development methods. It's intended for managers in Fortune 1000 companies - every one from project or development manager level up to the COO, CIO and CFO. It is due for publication by Prentice Hall in June 2003.

A Practical Guide to Feature-Driven Development (The Coad Series) author: Stephen R. Palmer,John M. Felsing asin: 0130676152

As editor, and more often than not author, of the online newsletter, The Coad Letter (www.thecoadletter.com) between June 2000 and February 2002 I wrote a number of issues about FDD. Most of these found their way into my book, A Practical Guide to Feature-Driven Development in some form or another and some were draft versions of some of the chapters in the book.

Coad Letter #86: Integrating Best Practices - (from chapter 3)
"Like all good software development processes, Feature Driven Development is built around a core set of ?best practices?. The chosen practices are not new but this particular blend of the ingredients is new. Each practice compliments and reinforces the others. The result is a whole greater than the sum of its parts; there is no single practice that underpins the whole process. A team could choose to implement just one or two of the practices, but would not get the full benefit that occurs by using the whole FDD process. ..."

New article from Robert Topley on the theory of evolutionary change in a product and learning to cope with it using process. There are some interesting observations on RAD processes and why RAD is not Agile.

Naturally, DSDM comes out as an Agile process despite its origins in RAD.

Evolutionary Development, read more...

This great article was brought to my attention by Mary Poppendieck on the Lean Development list.

Compare and contrast how Toyota designs cars and how FDD builds software and draw your own conclusion. Interesting reading...

Applying Lean Principles to Product Development

The SDC2003 conference is on in New Zealand March 10-12 and Australia March 12-14. This is the conference that last year brought the likes of Jim Highsmith and Martin Fowler to our shores and this year includes Karl Wiegers, Steve Mellor, Scott Ambler and others. I'll be delivering a keynote on FDD at this conference. I hope to see some of you (local folk) there.