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

[Aaron Kulkis]

Dan DeSloover wrote:
> 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.
> 

In fact..that's one of the original complaints that put IBM
in federal court -- tortuous interference with competitors sales;
when customers made a purchase because the competitor offered
feature X...and the IBM reps were TRAINED to tell the customer
that they too had feature X under development...and then after
the sales call, were supposed to IMMEDIATELY call in, and tell
engineering to start developing feature X for IBM computers, too.


> 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.
> 
> _______________________________________________
> mdlug mailing list
> mdlug at mdlug.org
> http://mdlug.org/mailman/listinfo/mdlug