ambiguities in the development process
andre at andregarzia.com
Tue Apr 28 12:19:45 EDT 2009
I am a single man team, I write my specs and when I meet them, I give myself
it's a self-pavlov thing but it works.
On Tue, Apr 28, 2009 at 12:57 PM, Mark Wieder <mwieder at ahsoftware.net>wrote:
> Tuesday, April 28, 2009, 12:37:12 AM, you wrote:
> > I would suggest that a small portion of the alpha/beta/post release
> > patch cycle is destined to discover the ambiguities that the creators
> > of the original extremely accurate tech specs never envisaged.
> ...with a change of topic...
> I worked on a system a dozen or so years ago where we spent roughly
> the first 60% of our development time (some 8 months or so) hammering
> out the requirements spec. The direct opposite of modern agile
> development techniques. But the result was that we got almost all the
> ambiguities out of the spec so that at the end of that process all
> three stakeholders (development, QA, and documentation) could build
> their deliverables from the same spec in parallel. With the tweaking
> of weekly bug meetings to discuss the few ambiguous issues that had
> managed to sneak through, we delivered an award-winning java app
> pretty much on time and pretty much on budget.
> -Mark Wieder
> mwieder at ahsoftware.net
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
http://www.andregarzia.com All We Do Is Code.
More information about the use-livecode