| Managers don't ask for what they really need when doing budgets. They're not even thinking about things this way. It's a fictional and dysfunctional practice and it bears a remarkable similarity to requirements in traditional software projects. Both the budgeting process and the traditional requirements process are not agile and both result in significant wastage of resources and lost opportunity to deliver more value. |
About fixed-price estimation, Jeff said "Explaining this to the client...the scope and the duration to be negotiated..." when he talks to the FDD approach of project development.
OK, it is a good idea to explain this approach to your client but in the real life, I mean usually, the client first needs to make a RFP with its needs, its dates constraints, and so on and then, you, the supplier, you make a proposal with your estimations (duration, work). So, I mean that with a fixed-price contract approach, the supplier engaged himself on a "needs scope" for a fixed-price before he can be the supplier of the client (ok, I know that the scope of the client's needs is never frozen and this is why the iterative approach is encouraged). When the client has signed the contract, it is difficult to change it (the contract) and have this collaborative approach of the software development.
Jim Highsmith is working on a new book on Agile Project Management and he has given access to it from this website.
http://jimhighsmith.com/APMBook.php
ID=agilepm
PW=apm
Thanks Jim for providing the FDD community access to your materials.
Jeff
Would anyone please clarify and compare the following concepts,
all related to building a features list and to feature planning:
FDD says the following about 'Building a Features List':
A team usually comprising just the Lead Developers from the (Process) Develop an Overall Domain Model is formed to functionally decompose the domain into Subject Areas, the Business Activities within them and the Steps within each Business Activity, thus forming the categorised features list.
 | Domain-Driven Design: Tackling Complexity in the Heart of Software author: Eric Evans asin: 0321125215 |
I wanted to bring this new book by Eric Evans to the group's attention. I haven't read it yet but it sounds like something that would be interesting to FDDers doing step 1 - Build a Domain Model. Domain Driven Design: Tackling Complexity in the Heart of Software by Eric Evans with Foreword by Martin Fowler.
| As a project progresses, new knowledge is acquired from various sources and new features are created for the work that must be done as a result of this new knowledge. Feature Driven Development is designed to cope with new knowledge and has mechanisms to adapt. |
Here's an interesting, but short, Bill Joy interview [fortune.com] where Bill speaks on design amongst other topics.
Hi All,
Has anybody worked out where bug/defect fixes fit into the overall process. For instance say you have been through an interation and release features A,B and C. You embark on the next interation for features D, E and F. During this time the testing/QA department find a bug in Feature A.
The question becomes how and where is this inserted back into the process to be fixed
Many Thanks
Dave
Hi All,
I have just taken on a new position at a company and have been tasked with putting a development process methodology in place. After spending some time looking at the various options I belive that FDD is the right direction for us.
I have done as much reading as I can and I am pretty confident on most parts of the process and where I need to make minor tweaks to fit in with our enviroment.
The main question I am a little stumped on is during the Planning by Feature stage it mentions devloping a "Development Sequence" what actually is this ? Also how/who decide what features are built in each iteration and is this done in the Planning by Feature stage or is this done at the beginning of each iteration ?
There's another long thread running that's spawned some interesting side discussions. I'd like to promote one of these out of there, since it's getting rather confusing and since I think there's a lot of valuable discussion going on I'd hate for it to get lost.
So this post follow on from the comment
Need to clarify the semantics of "the model" by Rudy.
