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.
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.
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
