这个问题实际上包含两个问题，需要分别解决：
为什么有些团队有严格的开发流程？
简单的答案是，如果不这样做，就会发生错误。代价高昂的错误。对于开发而言，这是正确的，对于IT领域的其余部分（系统管理员，DBA等）也是如此。
对于许多开发人员和IT工作者而言，这是很难理解的，因为我们大多数人只曾在“极端”中工作过-大型的财富式公司，至少有十几个开发人员，并且遵循严格的流程，或者小型的微型ISV甚至是自由职业者，人们不会很糟地搞砸，或者搞砸的成本很低。
但是，如果您曾经见过处于这两个阶段之间的公司-即使是一家拥有出色，才华横溢的IT员工的公司-您也会了解没有流程或流程不善的危险。您会发现，员工之间的沟通遭受了组合爆炸问题的困扰；一旦您达到一个团队中大约6-10名开发人员的水平，主要或严重缺陷的主要原因就不是缺乏人才或专有技术，而是缺乏沟通。
爱丽丝在周一早上四处询问，并决定可以在躯干中进行重建手术，因为没有其他人在做那部分。鲍勃（Bob）一个小时后才回来，那是他休假回来，精力充沛，决定要在那个完全相同的区域实施一项新的主要功能，为什么还要打扰分支机构，因为无论如何都没有人触摸过该代码？因此，爱丽丝还清了这笔“技术债务”，鲍勃实施了他的杀手级功能，该功能已经停滞了6个月，当他们最终都签入自己的代码时（当然是在周五关闭时间之前！），整个团队必须留在后面，并努力度过噩梦般的冲突地狱，在接下来的几周中，这种冲突会继续作为错误和回归而继续存在。
爱丽丝（Alice）和鲍勃（Bob）都在编码任务上做得很好，但是他们俩都以一个错误的决定开始（“可能发生的最坏情况是什么？”）。团队负责人或项目经理将他们带入验尸，并敲出清单以防止这种情况再次发生：
- 必须每天检查一次，以最大程度地减少冲突的影响；
- 必须在分支机构上进行大约1天以上的更改；
- 所有重要的任务（包括非功能性工作，例如重构）都必须在错误跟踪器中正确跟踪和分配。
我敢打赌，对我们很多人来说，这个“过程”似乎是常识。这是旧帽子。但是您知道很多较小的团队不这样做吗？一个只有两个人的团队甚至根本不会理会源代码控制。谁在乎？老实说这没有必要。问题只有在团队成长时才开始发生，但过程没有。
当然，过程优化就像性能优化一样。它遵循反指数曲线。上面的清单可以消除80％的缺陷，但是在实施该清单后，您发现其他一些原因可以弥补其余 80％的缺陷。在我们的虚构但熟悉的示例中，由于具有不同的构建环境，可能是构建错误，这又是由于没有标准硬件，并且开发人员使用的开源库每2周更新一次。
因此，您有以下三种选择：（a）标准化硬件并严格限制第三方库的使用，这既昂贵又可能严重损害生产力，或者（b）设置构建服务器，需要sysadmin组和a专职开发人员来维护它，或者（c）让开发人员自己通过分发标准虚拟机并告诉开发人员在此基础上进行开发来自己做到这一点。显然，（b）是最佳的长期解决方案，但（c）在可靠性和权宜性方面具有更好的短期平衡。
循环不断。您看到的每个“策略”通常都是为了解决实际问题而制定的。正如乔尔·斯波斯基（Joel Spolsky）早在2000年写的那样（与您完全不同的话题是，但仍然有意义）：
当您走进一家餐馆时，看到一个标有“禁止狗入内”的标牌，您可能会认为该标牌纯粹是说明性的：饭店先生不喜欢狗在附近，因此当他建餐厅时，他就竖起了这个标牌。
如果这就是发生的一切，那么也将有一个“禁止蛇”的标志。毕竟，没有人喜欢蛇。还有一个“禁止大象”的标志，因为当他们坐下时，他们会摔碎椅子。
标志存在的真正原因是历史性的：这是一个历史标记，表明人们曾经试图将狗带入餐厅。
在大多数（我不会说全部）软件团队中都是相同的：诸如“您需要为每个错误修复添加一个测试用例”之类的策略几乎总是表明该团队在历史上存在回归问题。 回归是这些问题中的另一个问题，最常见的原因是通信中断而不是功能不足。只要您了解该策略，您就可以使用合法的快捷方式（例如，我必须修复6个小错误，但是它们都具有相同的功能，因此我实际上可以为所有9个小写一个测试用例）。
这就解释了为什么存在这些流程，但这不是全部。另一半是：
为什么这个过程很难遵循？
这实际上是一个更简单的答案：这是因为团队（或其管理人员）专注于可重复的结果并最大程度地减少缺陷（如上所述），但并未充分关注该过程的优化和自动化。
例如，在原始问题中，我看到了几个问题：
修订控制系统（CVS）是当今标准的传统。对于新项目，它几乎已完全被Subversion（SVN）取代，而Subversion本身很快就被诸如Mercurial（Hg）之类的分布式系统所取代。切换到Hg将使分支和合并变得更加简单，即使在上面的假设示例中，每日提交的要求也将变得不那么痛苦。该代码甚至不必编译，因为存储库是本地的。-实际上，懒惰的开发人员甚至可以根据需要自动化此步骤，设置注销脚本以自动将更改提交到本地存储库。
没有花时间使虚拟机过程自动化。获取，配置源/库并将其下载到虚拟机的整个过程可以100％自动化。在本地计算机上进行错误修复时，您可能会在某个地方的中央服务器上运行一个无人值守的过程（并且仅使用VM来确保构建干净）。
另一方面，在一定程度上，每个开发人员的VM解决方案开始变得愚蠢，您应该只拥有一个Continuous Integration服务器。这才是真正的生产力收益的地方，因为它（主要）使单个开发人员不必担心所有构建。无需担心设置干净的虚拟机，因为构建服务器始终是干净的。
问题的措辞（“所有步骤的测试用例”）表示正在进行一些手动测试。同样，这可能适用于工作量相对较低的小型团队，但在更大范围内根本没有意义。回归测试可以并且应该是自动化的；没有“步骤”，只有添加到单元/集成测试套件中的类或方法。
不用说，从Bugzilla升级到更新（更好）的Bug跟踪系统将使那部分体验的痛苦减轻得多。
公司不一定只是因为尚未解决这些问题就变得便宜或愚蠢。他们所知道的只是当前流程有效，并且在某些情况下，他们规避风险，不愿对其进行任何更改。但是，实际上，他们只需要让他们相信这些好处。
如果开发人员花了一周的时间来跟踪所有非编码任务的时间，那么您可以轻松地将其累加起来，向管理层表明（例如）零资本，100个工时的投资来升级到Mercurial消除解决合并冲突的每周最多10个工时的工作，那么这就是10周的回报，他们几乎肯定会同意。构建服务器（CI）的想法相同，或更完善的错误跟踪。
回顾一下：团队还没有做这些事情，因为没有人说服管理层今天要做的足够重要。因此，要采取主动，将其转化为成本效益方程式；找出在可以最小化风险的情况下可以简化/自动化的任务上花费了多少时间，并计算了收支平衡点和新工具或技术的最终收益。如果他们仍然不听，那么您已经知道剩下的选择了。
如果开发人员花了一周的时间来跟踪所有非编码任务的时间，那么您可以轻松地将其累加起来，向管理人员展示……并将其转化为成本效益方程式等。
上面的部分看起来值得进一步扩展。
我可以确认它有效。程序员在我从事的一个项目中几次使用它，每次导致所需的更改。
我的总体印象是，如果做得正确，此技巧会否决大量管理层的无知和惰性。
我想指出，尽管我们（开发人员）不得不采用这种DIY方法的公司在IT方面非常不成熟。在经验丰富的软件供应商中，我看到的东西大部分是由经理自己完成的。通常，他们比我们的程序员更有生产力。生产力更高。