[mdlug] Seeking best practice documentation for "dual-track" development

[Dan DeSloover]

You're chasing your own tail on this one.

No matter how much information sales have on the current status of a
project, they will always promise something that doesn't exist or isn't
ready.

My two rules of business are simple:

1. Never trust a salesman.
2. All problems in business inevitably start with the sales department.

Robert Meier wrote:
> Lugs,
>
> Summary:
> I'm looking for some internet or book documentation for
> a best current practice in software development.
> The usage of the documentation is primarily for citation in
> management presentations.
>
> The particular aspect sought is what used to be called 'dual-track
> development (by AT&T, RCA, ...) and I suspect might now be called
> 'continuous development'.
>
> What is the current buzzword?
>   dual-track development? continuous development? ???
> Where can I find a best practices description?
>
>
> Detail:
> The salient feature is TWO development trunks to separate
> development scheduling from testing and sales scheduling.
>
> The benefits include
>   o sales always has a testing-approved copy to sell
>   o sales always knows what features are deliverable today
>        (those tested in the approval process)
>   o sales always knows what features are soon to be deliverable
>        (those in testing but not yet approved)
>   o testing can be thorough, rather than compromised for sales date.
>   o testing is more predictable so can be more easily automated
>   o development can design projects to minimize overall cost and
>     maximize efficiency rather than fit a sales date, or compromise
>     quality when sales dates change.
>
>
>                  --featu 2--+
>                 /          / \
> developers  --feat1--+    / --feat3--+
>            /  /     / \  / /   \    / \
>         ===============+========+======+== all bugs get fixed
>             \         \       \
> testing      \         \   bugs\
>               \         \ / /   \
>                ======+   ====|   =======+ only "safe" bugs get fixed
>                approve\   reject  approve\
>                        \                  \
>                         ================== ===============
> sales   [advertise]     [burn and ship]    [burn and ship]
>
> Though not required, references that use cvs would be
> especially useful.
>
> What is the best way for testing to snapshot what is being tested?
>   separate repository? special tag?
> What is the best way for testing to mark what is approved?
>   archived package? separate repository? special tag?
> What is the best way for development to mark
>   what is needed for integration but not yet ready for testing?
>     special tag? absence of special tag?
>   what is a "safe" fix suitable for the next testing cycle?
>     special tag? absence of special tag?
>
> TIA,
> --
> Bob
>
>   "The surest sign that intelligent life exists elsewhere in the
>    universe is that none of it has tried to contact *us*."
>      -- Calvin and Hobbs
>
> _______________________________________________
> mdlug mailing list
> mdlug at mdlug.org
> http://mdlug.org/mailman/listinfo/mdlug
>


----
Dan DeSloover
O Lord, grant that we may always be right, for Thou knowest we will
never change our minds.