ambiguities in the development process

[Andre Garzia]

I am a single man team, I write my specs and when I meet them, I give myself
chocolate...

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:

> Kay-
>
> 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://lists.runrev.com/mailman/listinfo/use-revolution
>



-- 
http://www.andregarzia.com All We Do Is Code.