3 ms·
Okay but aren't you implicitly assuming a sane set of specifications? I've seen it claimed that the input legislation was forty thousand pages. Can't confirm th
by rwallace 11y ago
Okay but aren't you implicitly assuming a sane set of specifications? I've seen it claimed that the input legislation was forty thousand pages. Can't confirm that of my own knowledge, but if it's true, far from criticizing the management of the implementation, we should be holding it up as a miracle that it was ever successfully implemented at all for any price.
- smoyer 11y agoI've seen that too ... and it probably cost many millions of dollars to come up with the ambiguous and likely contradictory specification. People always want to blame the waterfall method for this, but there are a couple aspects to BDUF that I think can help even the most agile project. From the DOD world, Interface Control Documents (ICDs) are a great way to make sure components (especially those developed by different teams) inter-operate. There should also be a reasonably cohesive architectural vision. From that starting point, write some user stories and adapt as needed for each sprint. You need to know approximately where you're headed, but you almost certainly CAN'T know everything you'll learn ahead of time (as this sort of specification implies. As an aside, contractors love ambiguities in specifications and it's actually in their best interest (unless operating on a fixed-price contract) to purposely produce something that meets the specification but is obviously not what the customer needs. There's good money in ECRs.