DSDM defined 21 products to be produced across 5 phases. This was pre-Atern, God knows how many products it has now we have renamed all the phases and added pre- and post- project phases.
I don’t think any truly Agile method should divide its steps into five artificial Waterfall-style phases, so it shouldn’t divide its products up into such minute pieces
To use DSDM nomenclature, if a part of the Functional Model & Design & build) happens in each Step, then there is no difference between Functional Model Review Records & Design Prototype Review Records. Also I fell that only Producing Test Records in certain phases de-emphasizes testing and leads people to assume testing only occurs at certain points, just like in a Waterfall project.
Now it’s perfectly sensible to retain the deliverables of DSDM, but group them into related blocks, so:
Reviews and Records: </strong> Functional Model Review Records, Development Risk Analysis Report, Design Prototype Review Records, Test Records & Project Review Document. I would imagine we’d all agree that a single format for test records and a single template for reviews is a good idea – and DSDM refers to “Review Records”. Producing a record and/or a review for every Step is no only sensible, but is a prerequisite for Quality Assurance.</li>
<li> <strong>Code: </strong> DSDM has an optional Feasibility Prototype, Functional Prototypes, Design Prototypes, a Tested System and a Delivered System. Hang on though. These are either just phase dependent names of stages in the development of the coded system or
<li> <strong>Requirements: </strong> Prioritised Requirements List, Non-functional Requirements List, Business Area Definition, System Architecture Definition & Functional Model. Now I can probably hear howls of protest at this grouping, but it is both logical and illustrates some of the problems about too fine grained a division of the product of a project. I don’t think anyone can argue with putting the two requirements lists here (though I do <a href=”quality-requirements.htm”>argue with non-functional</a> as a name), but both Business Area and System Architecture definitions being here too? Well isn’t the Business Area Definition a document which describes the business environment the system must work in? Isn’t the System Architecture Definition a document which describes the technical environment the system is embedded in? Therefore they are both environmental requirements. Why specify the hardware that the system runs on as if it is a fundamental part of the system, rather than a requirement for the current implementation? No, BAD and SAD they may be, but they belong as part of the requirements. And functional model? Well OK, that might be in the wrong place, but I’m assuming it means just the definitions of the functionas required, say a set of formulae. It cannot be sensible if it is some kind of code specification document to keep it separate from the Code descriptions. So the Functional Model has entries such as “this is the formula you must implement in code” and System Architecture Definition has “for the current installation we need it on server X under Operating System Y in Language Z”. It all looks like requirements to me.</li>
<li> <strong>Plans: </strong>Outline Plan, Outline Prototyping Plan & Implementation Strategy. Strangely there is no mention of a testing plan (that’s part of the Prototyping Plan) and a Quality plan seems to be an alien concept. Of course, individual timeboxes have their own plans too. So why no just say we have a plan, in outline first of all and as we progress we fill in the the details? One Project, One Plan.</li>
now this leaves out two products listed by DSDM: User Documentation and the Trained User Population. I’ve not forgotten them, but as you can guess by now, I have issues. For one thing “Trained User Population” as a product? Am I to breed them myself? Surely the product is a deliver training course? As for documentation, it’s the medium that I protest about. it implies a hefty manual which no one will ever read, but when did you last see a manual for any general office software product? We are meant to “get by” with Internet searches and on-line help. I’m by no means happy having to rely on searches just to be able to perform my ordinary work. However, I <em>do</em> want sophisticated and comprehensive on-line help with every system. Every development must include time for adequate help or it simply isn’t complete and there is no point having a system if the client cannot use it, although I’d like to think my designs can be used instinctively, without formal training…
Perhaps DSDM has a point in listing these two to remind the team to do the documentation and train the clients, but I’d rather think that they were professional enough to remember that that’s part of their job