Feature Driven Development

ITPS is pleased to announce the release of FDDTracker v2.0. New functionality includes:

Work Packages

Timesheets

Estimating

Release Management

Expense Management

Change Management

Defect Management

Document Templates

Workflow Management

Workflow Designer

Approvals and Notifications

Aspect Milestones

Numerous updates

Being a major release this functionality would normally require existing customers to purchase an upgrade to their existing Version 1.x product.

I am implementing the Code Archetypes ''Domain-neutral component'' (moment-interval, PPt, Description and Role) on the Rational Software Architecture in Plug-in format.

I would like to know if you have any further information or ideas which could be useful to the implementation of this archetype.

I thank you in advance for your help,

I wanted to try to get the FDDi discussion started again. The lack of follow-up comment on the part of the FDD Tools team wasn't intended to indicate any lack of interest on our part. Actually were were quite happy with where the FDDi was going. The last release brought us to a point where it was actually pretty consistent with what we were already doing with some good enhancements, such as a standardized date format and extensibility built in. I personally felt we were well on the way to interchange, at least at a basic level. I also think this would support a good subset of reporting, and that the extensibility built into the format that additional enhancements, such as the Resource information (Chief Programmer for example), could be developed to address any additional areas to further enhance interchange and allow a broader range of reporting capabilities.

FDDPMA is a free, open source, web-based FDD project management tools.
It is deployed to www.fddpma.net and may be downloaded from sourceforge.net web site.

What's new?
- Tested with latest Tomcat 5.5.17 (also works with 5.5.7)
- Updated the Installation Guide (make sure you read the section about Tomcat!)
- Configurable milestones for features (prev. version had them hard-coded)
- Any number of development stages per project (prev. version allowed only one)
- Notification if a user leaves web page without saving changed data
- Administrative interface into application (read user guide section 20)

Hello,

Did anyone use non-standard feature milestones?
I call the standard milestones those described everywhere in FDD docs:
Walkthrough (1%)
Design (40%)
Design Inspection (3%)
Coding (45%)
Code Review (10%)
Promote to build (1%)

If you ever used non-standard ones, can you publish it here along with the reasoning?

Thanks,
Serguei

Hey Everyone,

I gave a FDD lecture last week (29/6/2006) at the Agile Israel User group.

If anyone's interested here are links to the presentation:
PDF - attached to this post.

PPT - http://www.JustinAngel.Net/files/FeatureDrivenDevelopment.ppt
Webcast (WMV) - http://ttvv.tv/users/publicftp/justinangel/webcast-fdd.wmv (hebrew only, sorry)

The presentation decribes:
- why do we need Agile methodlogies
- what are the common problems with Agile solutions
- eXtreme Programming's limitations
- How Feature-Driven Development solves the common agile issues

Hi all

I've embarked on a new web project at work, and have been trying to follow FDD for the initial planning stages. While its going really well, I'm starting to add development time estimates to features, and I've noted that I need to add in time for initial project setup (server, database, etc). This is a common item in our projects, but I can't see anywhere it would fit.

Here's an interesting article on a decision by HP to end telecommuting for part of its workforce.

What's been even more interesting is to read some of the discussion threads about this article around the net.

There's no one right answer here for all cases. There are some roles and some people and some companies for which telecommuting makes a lot of sense and works. And there are others where it doesn't.

Aside from the people and process concerns, I find tools (technology) to be a huge problem here (still). Collaboration tools need to improve significantly - shared whiteboards, shared editors, shared diagrammers, chat and voice tools, and so on, all need to get much better and they need to be more aware of the recording and subsequent publishing needs (this includes classification and tagging for example). There's the issue of firewall and NAT traversal as well.

There's a lot of pain here for vendors to provide relief for...

Finally, and all too expected, there's been some kneejerk negative reactions to the HP article from some so-called Agilists. "Of course we can work remotely." Interesting isn't it that Agile says we should ideally be co-located with the users but some are now saying that the programmers themselves don't need to be co-located with each other. Hmmm... :? :D

Hi, My name is George (Jorge in spanish) Baroudi, i usually develop software in very small teams, and we are adopting FDD as our standar, we have done quite well with all the processes for the last project but, we were thinking about how would it fit a LOC estimation in between planning and the other processes.

Have someone made LOC estimation from a feature list based on past projects?

We are thinking about using an XML representation of the Database and XSL for generating the code based on columns of the tables in the database, and this will be applied to all levels of the different archetypes of the model.

It's interesting to watch people re-invent or re-learn things (the AJAX movement is particularly fun that way right now). Anyway, here's a fun story about Brooks' Law.