减少等待时间：软件开发生命周期的一个“等待减少”程序

像许多人一样，很多软件开发团队会得益于生活方式（或者我应该说成“生命周期”）变更来帮助令他们更瘦、更健康，并且更灵活。利用来自个人健康和减肥领域的比喻，本文探究了达到那些目标的具体、有效的方法。

探究减肥和我们的软件开发项目中的“等待减少”之间的相似之处的灵感起源于我自己的个人健康程序。像许多软件，我个人的项目会维持非常长的时间。但是我很高兴的说，最初的版本是成功的 —— 我觉得即健康又令人吃惊。

同时，我最近无意中发现，IEEE Computer Society 出版物 IEEE Software 中的一篇文章，题目为“你健康吗？”， ¹ Rick Mugridge 和 Ward Cunningham 撰写的书籍 适合软件开发：集成测试框架 的评论，在其中将奥林匹克运动员的健康同软件开发的世界进行了比较。我已经提到了，各种各样的软件质量会议发布“项目健康报告”，作为追踪我们的软件项目“良好状况”的方式。事实上，似乎最近已经出现了许多文章、项目管理仪表板，和将健康和良好形象应用于软件开发活动的类似的东西。

因此这些身体上的健康和软件开发之间的相联是有效且有用的吗？让我们自己去看...

基本假定

像人一样，每个项目是不同的：不同的团队成员、不同的技能，和不同的目标。正如一些人可以吃他们想吃的任何东西，并且从来不增加一盎司，而其他吃同样食物的人就会得到非常不同的结果。总之，对一个项目有效的不一定对下一个项目有效。但是不论您正在讨论的是什么类型的项目，都适用必然的原则。这也适用于我们的身体。

特别是，不论您拥有什么样的体型，减肥的关键是加速您的新陈代谢。新陈代谢对我们来说指的是您的身体燃烧您所吃的食物的速度。拥有快速的新陈代谢的某个人不会遇到保持苗条的麻烦。拥有缓慢的新陈代谢率的人可能吃得非常少，而仍旧增加重量。软件组织以十分相同的方式工作着。软件开发项目的新陈代谢率是组织完成所承诺的特性和任务的速度。等待的增加（与重量的增加相反）表现为缺陷、延迟的特性交付、错过的最终期限，和延迟的或去掉的需求（也就是，对于添加价值的资产的所增加的等待时间）的增长的积累的形式。我们组织的新陈代谢率越快，我们可以交付的特性越多，在不形成缺陷、延迟，和瓶颈储备的情况下，我们对增长的活动层次的响应的能力越大。

创建一个瘦的且健康的组织

要创建一个瘦且健康的软件组织，许多公司求助于“裁员”的方法。这非常类似于我们的时尚“饥饿节食”—— 并且有着类似的结果。这些方法可能在短期有效，但是它们会有不良的结果。

当我们进行饥饿节食来减少我们的卡路里的摄入时，我们不仅破坏肌肉组织，实际上还减小了我们的新陈代谢率。因为我们现在燃烧食物更慢了，所以在我们开始再吃正常进食时会更容易增加重量，这是与我们最初的目的相反的。

同样的，当我们的公司减少其劳动力时，我们减小了我们组织的新陈代谢率（也就是，我们工作的能力）。这迫使我们的劳动力以大量的缺陷、未交付的特性、错过的最终期限，和瓶颈的形式得以等待。饥饿节食的组织的等价物是一条破坏团队的肌肉和执行能力的向下的螺旋。虽然减少劳动力的目标是减少成本并增加利润，但是团队现在也许不能交付实际上增加收益的产品。如果那样的话，我们不能完成我们最终的目标，“赚钱”。

那么在交付高质量的软件产品的时候，组织能够如何重编其新陈代谢，使它可以交付更多并且同时快速减少等待收益呢？

重新调整组织的新陈代谢

如果您想要减轻重量，讽刺地说，您必须要吃。关键是更经常的吃更少的食物，这样可以加速新陈代谢。（当然，您吃的东西也是重要的。）漏掉一顿饭，或者在任意一顿饭时吃太多的食物，将会越来越减慢您的新陈代谢。当提到在软件组织中应用迭代开发生命周期方法时，这一基本方法也有效。

在营养学家 Michael Thurmond 的书籍6-Week Body Makeover 中， ² 他将新陈代谢描述成“篝火”，并且将您吃的食物作为放到火中的原木。如果篝火燃烧的大而热，那么消耗掉您加入的额外木头是没有问题的。相反地，如果火开始灭了并且您将一大块原木放在熏烧的余烬上，那么原木就正好将火熄灭了。最好首先用引火柴和小枝子来给余烬加料，直到火再次燃烧起来。

软件项目是同样的方式。如果您的交付率已经非常缓慢了，那么您不可以期望团队交付大的特性。工作只是搁置在那里并且最终作为等待（积压）存储起来。但如果您以小的增量继续特性交付的周期，那么您将以正在进行的方式连续地交付特性 —— 这是迭代开发方法的基础。

软件项目恰当的节食

要成功地减肥，了解您的食物的基本化学性质是有用的。对减肥的目的最有益的食物类型是新鲜、完整，未加工的食物。加工食品不是用来吃或满足的有效方式，因为它们所包含的人造的化学物、盐，和防腐剂改变了我们的身体工作的方式。吃不干净的，加工食品来维持您的身体将不会得到良好的效果。

软件项目几乎以同样的方式工作。对项目来说最好消耗新鲜、自然、干净，简单“无缺陷”的代码。 ³ 但在当今的面向服务的体系架构、开源和外包的领域中，我们常常依赖于预包装的代码、应用程序或资源。因此，我们不可能总是准备我们自己的软件伙食来避免化学添加剂和防腐剂的等价物，也就是，缺陷。但预包装组件，像快餐，不会节省我们的时间吗？如同经常吃速食堡和炸薯条的繁忙生活方式，使用预包装的代码的结果可能会是短期的，因为我们没有立即意识到这些选择的下游效应。一些相关的考虑如下：

• 通过使用预包装的组件，我们已经影响了我们自己的解决方案的可测试性。
• 预包装的代码损害了我们维护并升级自己的产品的能力。
• 预包装的代码天生地将产品的质量标准限制为最小公分母，也就是，最薄弱的环节可能存在于我们控制之外的代码中。

因此，在使用预包装的代码时，我们如何能够创建一个瘦的、聚焦于质量的软件开发环境？如上面所提到的，不同的组织对这些类型的投入值的响应是不同的。不需要与第三方组件整合得很紧密的组织可能没有吸引或容忍它们的问题。对于需要与预包装的模块密切合作得团队来说，这里有一些增加成功概率的技术：

• 了解成分。就像阅读食物标签上糖、脂肪，和钠的含量，就您将要消耗的代码来培训自己。如果包装的产品没有与验收准则标签伴随出现，那么根据统计分析结果、代码检查、缺陷报告，和其他遵从已知的质量标准的其他标准来定义您的验收准则。
• 寻求“低盐的”版本，剥夺您的项目不需要的特性。就像油炸食物或在油和调味料中烹饪的食物减慢您身体的新陈代谢一样，包含您不需要的特定功能或特性的复杂组件可能减慢您的生产率，并且甚至可能使您倒退。不要假设您不得不接受整个包。正如许多餐厅愿意供应特殊的订单，请您制定用您聪明的选择准备的版本。
• 在放手之前，使用商定的验收测试来增加您的信心。如果可能的话，将特别地检查您预先考虑的潜在问题的验收测试自动化。例如，虽然创建测试来确保您的产品“如预期”工作是普通的，但是还包含获取您知道的外部组件中的行为的测试将导致其他模块的问题。不断地运行那些测试来标记将影响团队生产率或产品的可维护性的任何未预期的变更。
• 承认采用对外部组件的变更 —— 特别地如果经常做出变更 —— 并且因此修改您项目的进度安排可能会花费额外的时间。
• 创建桩或临时的（替代品）每日工作来处理依赖的代码区域。这类似于包装一个健康的快餐，放在车中作为储备，以确保您有一些合适的东西来消耗。如果外部组件交付迟了，或者没有按照预期工作，那么您拥有一个可接受的储备来支持测试。通过减少您的依赖性，您令解决第三方问题的这件事变得更加容易。
• 将您自己的代码加入开源库。这就像将您自己的菜带到家常的宴会上，为了确保您有能享用的一些合适的东西。
• 创建清楚、简洁并且明确的“契约”来提高与内部和外包团队的交流 —— 并且根据他们来工作。这创建了一个透明且可预期的允许持续反馈的环境。

软件项目的脂肪燃烧练习

要加快物理脂肪消耗的速度，我们可以结合练习程序和健康饮食。那么对于软件开发生命周期来说适当的练习程序是什么？

虽然每个组织都是不同的，但是存在一些产生大多数浪费的典型问题域。就软件开发项目而言的浪费一般属于三类：（1）等待时间，（2）重复工作，和（3）缺陷生成。

在下面的部分中，我们将自定义一个软件项目的比喻性的“练习程序”，通过处理这些典型问题域的原因来帮助调节和加强。

减少来自决策延迟的等待

软件项目中最大的时间浪费者和获得等待领域之一是决策延迟。决策延迟的原因常常是害怕做出错误决策。但讽刺的是，选择不做出决策本身是一个延迟行动的决策，这没有将您带到接近正确答案的地方。即使是错误的决策令也能使您与可使用的解决方案更接近，因为您可以立即处理“所制定”决策的结果。您做决定的越快，您可以越快的前进并且在积极或消极的结果上采取行动。

我没建议冒失或突然的决策制定。我推荐快速进行可逆的选择，并且对非可逆的、高风险的项更慢些。如果错误选择的预计结果是较小的，那么我们应该根据我们现在知道的内容制定最佳决策并继续前进。在我们的迭代的且不断变更的技术环境中，我们不可能 100％ 确定知道任何决策都是正确的，因为决策是在未来实现的。因此，指定预定目标，并且不要为它担忧。一旦制定出决策，那么就停止对它的讨论。执行，学习所有随后的错误，然后只是继续前进。

对于今天您不能决定的那些条目，那么您需要定义一些具体行动条目，这些行动条目应该缩短您所在位置和您要做出决策所需要的位置之间的差距。确定您的每个动作都有明显的所有者和最终期限。在我的产品小组中，我们经常参加会议来努力地讨论一个问题。在大量的争论之后，我们散会，常常是因为我们需要参加另一个涉及另一个问题的会议。因此，我们不仅不延迟决策，而且我们没有将其加入到一系列事件链中，以使我们更加密切的沟通。

减少对于决策等待时间的有效练习是拥有一个恢复协议（Recovery Protocol）（参见图 1）。

属性	添加（最大的拐点）	优化（较少的拐点）	折衷（较少的拐点）	采纳（最小的拐点）
资源	X
范围		X
进度安排			X
质量标准				X

图 1：样例恢复协议

恢复协议是在项目开始时使用的很好的工具。团队可以使用它来商定并且指定在问题出现时所采取的方法，例如，如果项目开始渐渐的出现问题了，我们将会做什么？图 1 例举了将若干关键的项目属性划分优先级的恢复协议。该实例表明团队同意 —— 起初 —— 资源是价值系统中最灵活的价值。因此，如果项目开始滑落，那么他们将不断地增加资源，直到不能这样做为止。这将包括从其他项目中获得人员（很可能延迟那些项目）并且/或者雇佣额外的承包人，等等。如果他们利用了所有可用的资源，并且仍旧落后于进度，那么他们将求助于减少项目的特性列表，而仍旧优化对客户的价值。项目团队将以这种方式继续下去，直到他们回到进度上来。只有当他们在用尽要消除的特性时，他们才放开他们的进度。产品质量将是在此特定的恢复协议下被折中的最后要素。

在实际出现任何问题之前将恢复协议就位（并且我们很冷静且不受压力），通过这种做法，在问题出现时减少或消除决策延迟，因为我们已经对如何继续下去达成协议。这种燃烧等待的练习给予组织灵活性和耐力来以一致的且价值驱动方式响应变更。

当然，上面的图表紧紧是一个实例。团队可能选定不同的协议属性或一个不同的表示方案。目标是决定您计划如何根据您商定的价值来处理情况。

处理无效的构建过程

每日的构建，像每日的练习制度，典型地作为最佳实践。但是不正确地实践经常减慢我们的进度并且消极地影响我们的生产力。无效的构建过程不仅增加了投放市场的时间，而且还消极地影响整个项目团队的士气。这种额外的等待由每个人来承担。出于同样的原因，需要改进此领域增加整个软件开发团队的灵活性。

公认的是，生成、绑定、测试，并发布到测试团队的构建的频率影响开发过程的成熟度和质量。自动化的测试用例每天都在不断地被增加、大量批处理，并且盲目地执行，因为这意味着我们在更好地工作。

例如，我曾遭遇过许多监控并跟踪依据这些类型的自动化单元及组件测试的每日构建的通过或失败统计数字的“健康报告”。但尽管日益增长的自动化测试用例在每日地运行着，它们找到的失败还是很少被审阅、修正，并同样紧迫地确定出来。由于推动构建的通过/失败率的单元测试确定率的失败不是处于同样的每日循环上，因而每日失败的构建数量不可避免地积累起来。

思考的一个方向是，由于构建验证测试全都自动化了，在每晚 运行所有的自动化测试的伤害是什么，—— 只是机器时间，对吗？事实上是，执行测试不会花费很多人工时间。但失败分析是这样的。通过决定运行所有的测试，您隐含地同意在一个工作日内审阅每个失败的测试，为了下一个每日构建的运行。例如，如果 8000 个自动化测试用例的构建集合生成了 600 个失败，您能实际地处理这种情况吗？如果您不审阅这些失败，那么测试就没有意义了。

当然，作为软件质量的专业人员，我们不期望或希望每个构建都通过。例如，在采用外部组件的期间，某些测试将继续失败，直到我们完全地集成了所需的包。然而，当我们机械地忽略失败的构建，因为我们期望某些测试失败时，我们可能未察觉到这样的事实，应该通过的测试没有通过。

解决方案是从您的构建练习中去掉过量的测试，以便您只运行应该通过的测试 —— 并且如果它们失败了您可以审阅并解决他们。当构建失败时，按照这种方法，那就是真的失败。此方法也更易管理，因为，它令您立即地为下一个计划的构建及时地分析、确定，并验证那些失败的测试用例成为可能。

即使当我们着重于确定那些应该通过的测试用例时，诊断、确定并验证缺陷可能要花费超过一天的时间。因此，每日的构建将如预料不断地失败，直到适当的测试用例通过。在这种情况下，那些构建真的失败了吗？它们不是确切地如预料执行的吗（也就是，不精确地说明，它们没“通过”吗）？ 由于这些是预期的事故，所以每日的通过/失败图表（尽管很流行）不是实际的产品健康的有用的指示。

这里有一个实例：星期二的构建只包含打算在此构建上通过的测试用例。星期二的构建由于与 TestCaseA、TestCaseB 和 TestCaseC 相关的缺陷而失败了。John 能够在星期三确定与 TestCaseA 和 TestCaseB 相关的缺陷。并且他在星期四确定 TestCaseC。由于星期五是该构建应该实际地通过的第一次，因此星期三和星期四的失败的构建没有报告为构建失败。因此，在典型的每日构建报告中，我们将报告该周 40％ 的通过率。但是如果我们只考虑我们期望通过的构建，那么我们实际拥有 80％ 的通过率（参见表 1）。

表 1：构建预期的及阻塞的计数

构建	测试通过	预期的结果匹配	阻塞的测试天数
星期一	1	1	0
星期二	0	0	1
星期三	0	1	1
星期四	0	1	1
星期五	1	1	0
健康状态	40%	80%	20%

因此，一张更准确的图表将成为跟踪我们预期将通过的构建的图。

比失败的每日构建的积累数字更好的过程成熟度指示器是能够多快速地从失败中恢复回来、创建一个可测试的构建，并继续下一个开发阶段。在上面，花费了三天（星期二、星期三、星期四），来“通过”该构建。对此项目的测试延迟了三天。就减少等待时间而言，对如何减少确定时间率的因果分析不会比计算构建失败的频率的数字更有益于团队的整个效率吗？

使每日的构建对减少等待时间更有用的另一个方法是对首先确定什么失败划分优先级。重要的不是构建是否“通过”或“失败”—— 而是我们可以从构建统计数字中获得什么有用的信息来将活动划分优先级。然而，许多软件开发过程利用构建状态盲目且人工地把守进展的下游。人工地把守进展导致了延迟和等待。即使当我们将我们的测试用例流线处理为那些只“应该通过”的内容时，我们也可能落入该圈套。

让我们重放刚描述的用来例举等待减少方法的场景。我们知道星期二的构建只包含预计在此通过的测试用例。星期二的构建因为与 TestCaseA、TestCaseB 和 TestCaseC 相关的缺陷而失败了。TestCaseA 和 TestcaseC 对产品的正常启动和安装是至关重要的。除非那些测试用例通过了，不然团队将停止于此处，不能进行所有重要的测试。TestCaseB 也是重要的测试用例，但它位于测试循环的下游。因此，我们不会在开始的几天执行 TestCaseB。其间，John 将其工作着重于 TestCaseA 和 TestCaseC。John 能够在星期三确定 TestCaseA 和 TestCaseC。我们将 TestCaseB 从“预计通过的测试用例”列表中去除，并重新执行构建。星期三的构建通过了。测试团队解除了此处的等到，并继续前进。John 在星期四确定了 TestCaseB，更新“预计通过的测试用例”列表，而且构建通过了。测试团队收到了带有更新了的构建，并且为该领域测试及时地确定了 TestCaseB，没有减慢测试进度的进展。

表 2：测试用例的优先级用来减少等待

构建	测试通过	预期的结果匹配	阻塞的测试天数
星期一	1	1	0
星期二	0	0	1
星期三	0	1	1
星期四	0	1	0
星期五	1	1	0
健康状况	40%	80%	20%

这样看来，虽然构建率的“健康报告”在表 1 和表 2 中几乎一样，但是第一个实例将程序延迟了三天。在第二个实例中，团队只经历了一天的等待时间。

因此，我们需要一个将失败列出优先级，并且告诉我们实际的故障时间，而不是每日构建结果潜在的误导列表的报告。健康不真正地取决于所需的调整数量。组织的健康、灵活性和适应性的适当标志是组织恢复得有多快。当恢复是平稳且直接时，需要调整的问题对软件开发项目的一般成果几乎没有影响。这就像一只脚平衡的灵活的运动员：他们不断地调整并重新校准自己，但这些调整在性能的情况下实际上是不明显的。

总而言之，我们可以通过，在健康的术语里，可能被称为精确度塑造策略，来提高构建效率和有效性。代替每天运行您所有的自动化单元测试，而是运行为此特定的交付或迭代而需要通过的测试。要进一步优化您每日构建验证策略的有效性，通过集中于将等待时间最小化来为每个失败划分优先级。

调整不稳的需求

很少项目能达到所有的成本、进度、质量和需求的目标，在这种意义上，大多数软件被认为至少是局部故障的。失败的一个主要原因是不完整的、含糊的或不明确的需求。即使是最好的需求工具也很难帮助我们验证该需求的质量和完整性。

需求检查是有效的调和练习，用来确保在减少投放市场的时间的情况下，您可以得到您真正想要的产品。

在 Ron Patton 的书籍 Software Testing中， ⁵ 他陈述，考虑周到的产品规范有八个重要的属性。通过仔细地利用这些属性用心地审阅您的需求，您将启动您的检查过程。根据 Patton 的说法，我们的需求应该是：

• 完整的。是否错过或忘记什么？是全面的吗？它包含了所有使其独立的必要内容了吗？
• 准确的。提议的解决方案正确吗？它是恰当地定义了目标吗？有错误吗？
• 精确、明确、且清楚的。描述是准确且不含糊的吗？是只有一种解释吗？容易阅读和理解吗？
• 一致的。所撰写的特性的描述与规范中的其他项不冲突吗？
• 有关联的。陈述对特性是必需的吗？是应该省去的额外信息吗？特性可追溯到原始的客户需求吗？
• 可行的。利用可用的人员、工具和资源，在指定的预算和进度范围内能实现特性吗？
• 代码无关的。该规范不离开产品的定义，而不是底层的软件设计、架构和代码吗？
• 可测试的。特性可以测试吗？提供测试人员可以创建测试来验证其操作的足够的信息了吗？

Patton 进一步建议我们应该梳理我们“问题语言”的规格，它们的出现常常招致麻烦。实例包括：

• 总是、每一个、所有的、没有一个、从未。如果您看到类似这些的相对和绝对地表示东西的词语，确保它们是的确是毫无疑问的。当审查规格时考虑一下违反它们的情况。
• 的确、因此、无疑、明显、一般、通常、最多、主要。这些词语倾向于说服您将某些东西作为假使来接受。不要落入这个圈套。
• 某些、有时、经常、一般、通常、最多、主要。这些词语太含糊了。测试一个“有时候”运行的特性是不可能的。
• 及其他、等、等等、例如。以这些词语结尾的列表是不可测试的。关于系列如何生成，以及列表中接下来出现什么不应该存在混淆。
• 好的、快的、便宜的、有效的、小的、稳定的。这些是无法量化的术语。它们是不可测试的。如果它们在规范中出现，那么应该进一步定义它们来准确地说明它们的意思。
• 已操作、已处理、已拒绝、已忽略、已排除。这些术语会隐含大量的功能，并且需要进行指定。
• 如果 ... 那么（但没有“否则”）。寻找含有“如果 ... 那么”的子句，但没有相匹配的“否则”的陈述。问问自己，如果“如果”没有发生将会发生什么。

创建一个稳定的符合 n' 的开发过程的练习有多少价值？自从我们知道了，甚至回到 1996 年，在设计阶段确定一个缺陷花费平均 25 美元，而在产品部署之后是 16000 美元（参见图 2），保持您在需求检查过程中发现的重要缺陷的数量的度量标准可以直接变为成本的节约。使用这些度量标准例举了您的投资回报和收益效果。

图 2：在软件生命周期的不同地方修复缺陷的成本

缓和团队之间的紧张局势

延迟的另一个来源是错误传达。不论您在处理外包团队、地理上分布的团队，或是内部团队，这一问题是普遍的。不论在哪里存在角色、目标和劳动力的划分，都存在错误传达。出于本实例的目的，我们将着重于开发人员和测试人员之间的关系，尽管同样的技术在任何关系中都有效。

“专业的产品关系就像契约。” ⁶ 为了建立和维护这样的契约，我们需要了解对方的角色。例如，如果您需要一些来自于我的东西来做您的工作，那么您会希望我对您期望的东西有清楚的了解。

在许多软件开发项目中，开发人员和测试人员（以及其他团队）之间的关系，由于误解、失望和挫折形式的紧张而被玷污了。测试人员和开发人员解决问题的方式的差别是该关系的阴和阳。表 3 列举了一些开发人员和测试人员可能持有的非典型的态度。 ⁷

表 3：造成开发人员或测试人员紧张局势的属性

示例问题 —— 测试	示例问题 —— 开发
开发团队总是匆匆忙忙，并且告诉我们要更快一些。不像他们，我们不可能承受得起犯错误。	他们不和我们一样快速地工作。
他们忘记告诉我们变更的东西。他们犯了错误并且他们让我们随后补偿。	他们不像我们一样工作努力。
获得准确的信息很难。我们问问题并且经常得不到回音。	有太多的问题了，我们不能完成自己的工作了。
他们总是向项目中添加东西，甚至是在最后。他们是如此的紊乱。	他们总是不说出有关要发生的事情的真相。他们倾向于夸大故障现象。
该软件看起来从来没有被开发人员测试过。	为什么我需要测试我的代码？我们有一整个的部门来干这件事！

开发人员或测试人员紧张的局势不仅存在于项目过程中，而且还存在于软件应用程序部署之后。一个根本的问题是大多数项目成员对测试人员在项目中的角色了解得不够清楚。开发人员、产品经理、项目经理，甚至测试人员对可以达到的覆盖水平、可以常规地揭示的问题类型，以及一致地重现并诊断故障现象所花费的时间持有不现实的高期望值。讽刺的是，依靠单独的测试组织来促进或突出质量问题的组织常常达到相反的效果。这种分离主义不再强调开发人员对软件质量的责任。由于软件质量不是开始于测试的，所以让测试人员负担确保质量的全部担子是不现实的。

作为测试人员，我们可以进行两个重要的加固练习，来帮助缓和与开发人员和其他团队成员的紧张局势。首先，我们可以在测试团队和组织的其他团队之间创建一个清楚、精确，并且明确的“契约”。第二，我们可以达成该契约的测试终点。

加强项目的成功标准，并且清楚地描述各种角色、期望，以及每个成员打算如何完成目标，这对创建一个可使用的专业关系契约 —— 以及减少由不必要的紧张局势引起的等待 —— 是必要的。

通过身体塑型来构建强壮的团队

那么让我们说您已经实现了上面的策略中的一部分，并且您的项目开始减少等待。您组织的新陈代谢显著地加快了，并且您的团队恢复了活力。但是您如何能够将此进展维持在连续的基础之上呢？

是时候塑造您的组织，用以创建您想要的确切的“身体”。精确地身体塑造指的是造型及定义身体每个区域的能力，以便它看起来与您想要看起来的样子正好一致。肌肉燃烧脂肪，您组织中的人员是它的肌肉。因此，以适当的比例调和并构建恰当的团队成员将让您的组织运行的瘦并且平滑。那么我们如何以此方式对我们的软件开发组织塑形呢？

对任何身体塑形的第一个步骤是设计一个身体蓝图（Body Blueprint）或者个人的开发计划。下面是通用的方法，以及软件开发组织的具体实例。

身体蓝图中的一般步骤：

1. 对您（或您的雇员或您的组织）现今所处的地方做一个自我评估。
2. 确定您想要到哪里。
3. 强调问题域和“这里”及“那里”之间的差距。
4. 首先开始对确定目标的鲜明区域的精确塑型例程。
5. 概括短期的目标以确保您达到了对您所期望的时间表的目的地。
6. 创建奖励机制来推进短期的目标。
7. 一旦发生了重大的变更、重新评估并重新设计改进的下一个层次的身体蓝图。
8. 重复... ⁸

这些步骤可能听起来简单。但是在应用它们的时候，您不但定制了对应您个人的需求的程序（不论是与您的体型、产品，还是组织相关联），而且还持有过程、执行和结果的所有权。采用这些步骤集中您的精力和意图，并且将促进重要的变更。

在软件开发组织中，您可以使用许多东西来评估并定义您的产品。一个众所周知的方法是在您的开发生命周期中的每个迭代或里程碑的入口和出口标准。当然，许多软件项目执行上面的步骤 1 和 2。它们确定出它们的目标，并且根据那些目标跟踪它们的进展。我们甚至每周强调两者间的差距及执行概要。

我们执行不好的是步骤 4 及超过的内容。开发组织声名狼藉地乐观。如果我们感觉到我们正在失去动力或者落到后面，那么我们很有信心可以赶上。没有做额外的培训或技能评估来评估我们有效地完成任务的实际能力或才能。所需要的唯一的方针变更是“更努力地工作”。不幸的是，这种习惯性的思维假设我们在开始滑落时没有付出我们自己 100％的努力。它还假设首先我们能够实现目标。

另一个普遍的错误是，我们没能开发出今天我们应该所处的地方的清楚的画面。我们知道我们应该在 X 天 完成，并且可能我们认为我们知道今天所在的位置。但如果我们没有在路上标出的短期的目标和里程碑，我们不会真正地确定我们是否落后或先于进度。

可虑这一假设的交流：

Joe：“在我们的交付中团队落后了。您对回到进度上的计划是什么？”

Mark：“我们发现我们没有对此领域充分了解的员工。我们目前正在寻找一些承包人来短期帮忙。”

Joe：“要多长时间，并且成本多少？”

Mark：“最终交付计划在三个月后，因此契约将持续三个月。我们将需要三个额外的人员在该时间内完成任务。”

Joe：“要额外的成本吗？培训？设备需求？”

Mark：“嗯...我们计划为每个承包人分配一个开发人员，作为伙伴或顾问以减少对我们的产品和编码标准的学习曲线。我们需要为每个承包人找到办公空间和设备。我们还考虑远程的方式。”

Joe：“那么，总的来说，你们花费时间来寻找并雇佣三个人员，需要分配空间和设备，将要打断或减慢至少一个开发人员来指导或培训新的人员，并且你的团队不得不承担与更大的团队相关的增加的管理和协作功能。如果承包人远程工作，那么需要有额外的指导、管理和管理复杂度。这样我们在同样的时间框架（在其中我们不能完成原来的任务数量）内增加了半打任务。这样怎么工作？”

Mark：“我们会更努力的工作。我们会完成的。”

夸大之词吗？也许是，但它例举出，当我们没有向下看到我们交付的技能和能力时，我们最终将会落后。

那些偶然滑落的原因

虽然生成零缺陷及零停产事件的应用程序是我们应该不断渴求的极致目标，但是更现实的是承认我们将时常地遇到滑落和牵绊。就像在我们个人的减肥过程中，我们的软件开发项目会由于像下面讨论的那些原因一样而滑落。

知道了这些滑落会时常发生，并且对它们做好准备，使我们有控制地响应，而取代不假思索的反应。让我们看看一些响应一些普遍的错误的适当的方式。

关注点放错了地方

从软件开发的观点看，我们的错误反应为生成的缺陷的数目。在物理的领域内，“此时此刻您是否是一个确定的指示 —— 是您四肢上的挫伤和擦伤的数量。当您不注意的时候，您碰到桌子、椅子、门口，凡是您想得到的。” ⁹

灵活性、适应性，和平衡都帮助我们避免碰到东西。但如果我们没有注意，没有马上表现出来，没有留心，那么不论我们有多健康，都将会碰到东西。不留意此时此刻意味着我们将注意力放在其他地方。那么这如何转换到软件组织上呢？

整个开发团队的集体目标是生产出客户会重视的东西。真正地从事于对每个迭代和阶段的质量输出的创建是关键的。这意味着在需求审阅活动过程中，举例来说，开发人员的主要任务是“需求审阅。”在设计活动中，开发人员的主要任务是创建并审阅设计文档。在编码活动中，开发人员的主要任务是生成没有错误且与客户相关的代码。在文档审阅活动过程中，开发人员的主要任务是确保用户辅助材料和错误消息足以平坦客户的学习曲线。在安装和部署的过程中，开发人员的主要任务是确保客户可以很容易地安装并配置您的产品，以便他们可以尽可能有效地完成他们“实际的”工作。

如果在需求审阅会议或电话会议走查过程中撰写电子邮件或编码，您的注意力就放错了地方。如果您开始人工测试，然后离开去和某人谈话，或者完成另一项任务，那么您不会注意到测试揭示的任何出乎意料的结果或定时问题。即使您全神贯注于在特定的日期提交您的代码的最终期限，您也被进度分散注意了，并且不是完全投入于现在进行的一对程序设计和测试中。

那么，什么可以帮助我们抵抗注意力的分散并且以任务为中心呢？我们可以通过设定更小的、短期目标并且当我们达到目标时奖励一些自己的方式来待一会。注意其他人是另一种保持连续的方式。我们可以通过在其他人帮助我们达到短期目标时奖励并感激其他人的方式来做到这点。着重于通过迭代的里程碑，反对孤立于您的对长期的交付的骚乱的团队目标也有帮助。

留意该（关注的）时刻要求不只是在现场。这是我们必须积极地并且不断追求的东西。它需要可以由事件来变换。考察我们是否实际地关注了好测试的方法是，如果我们觉得在离开事件时与进入时一样，那么我们真正完全地致力于该活动。

友好的及自我怠工

如我上面谈到的，许多测试团队完全有理由抱怨它们由于构建失败而不能继续工作。作为测试人员，我们感觉到，我们通过强调问题来完成工作 —— 现在改正问题是“其他人”的工作。在我们“置于等待”时，我们非常繁忙，也许是致力于不同的领域，像不是为此次迭代安排的可有可无的特性。不幸的是，我们的“可有可无”的特性中没有一个可以减少当前的等待时间。每个人都正努力工作。但是项目越来越落后。因此，我们滥用了时间。

如果我们马上完全参与并且分担解决问题，那么我们可能会以我们的才能和技能找到复制的方法。最好将时间花在辅助构建团队来调查错误上，或流线化构建验证的测试用例上，或将前进所需的最小确定划分优先级，或者帮助测试一些此次迭代的限定发布的组件。虽然我们很忙，但是实际上致力于手边的事件。我们没有辅助减少等待。

这是所谓的友好怠工。像刚描述的这样的情况使我们感觉到我们在不成为延迟的原因的情况下还有更多的时间。只要“他们”阻塞了，“我们”可以致力于我们想要致力于的事情上。

自我怠工看起来非常类似，除了“我们”是构建团队之外。我们不让或允许任何其他的团队来辅助。我们不试验或调查在过去我们如何完成任务的备选方案。

两个实例中的圈套是“我的工作或你的工作”的心态。每个人都有不同的技能和才能，足够真实。每个人都有他们的主要责任和任务，非常真实。但是，如果产品从来不装载就没有这样的问题。注意真正的目标 —— 在计划的迭代中交付商定的、增加价值的版本 —— 帮助我们避免这些牵绊。

社会义务

在个人减肥的场景中，社会义务是社会功能、宴会、假期，以及那些娱乐的中心是食品的地方。在软件开发情景中，社会义务在您没有完全控制开发环境时出现。以下是当您觉得自己什么都没有时增加您的控制的很好的练习。

• 将您的精力集中于您控制的领域。
• 概述出您的整体目标、远景和成功标准。
• 利用支持那些目标、远景和成功标准的标准和验收准则或预期内容。
• 对那些预期的内容、角色和时间表取得一致（类似于专业契约）。
• 执行您自己的任务，并且辅助其他人来执行他们的任务。

该方法增加您在工作环境中的影响。正如浴室磅秤，这些控制帮助您着重于您的目标并追踪您的成功。

另一方面，一旦您将那些控制就位，不要盲目地成为它们的奴隶。记住控制是用来支持更大的视界（您的原则和价值）的。像磅秤一样，控制只是测量工具。计划是减少等待，并且构建健康且灵活的开发组织。在增加客户满意度的同时，我们应该更感兴趣于我们投放市场的时间。因此，不要让控制导致等待收益。

例如，您全部的目标中的一个是交付零已知缺陷的产品。如果您满足了客户的期望，那么为了那些缺陷的工作是可接受的，并且您的自动调整允许客户完成他们的工作，然后，您拥有少量的缺陷的事实不需要延迟产品发布（尽管您的发布标准按别的方式陈述的）。

当我们在社会情况中遇到压力或压抑时，我们知道我们经常求助于方便的食品（巧克力、糖，等等）。甚至是在软件项目中，在压力和恐慌的时期，我们倾向于求助于我们的舒适地带。不幸的是，有时候这意味着我们回到了坏习惯。通过利用恢复协议，在艰难时期，我们可以与我们整个的视界、价值和目标保持同步。

如同健康程序一样，庆祝短期的成功将镇静恐慌并加固您的新习惯。审查团队目标将避免那些艰难时期中的所有消极的怠工。设置带有验收和成功标准的契约将提高您对外部组件的影响。通过将这些想法应用到您特定的情况下，并且与其他人分享，您不仅可以提高您自己的效率，而且提高团队或整个组织的效率。

结束语

正如多年逐渐积累的体重一样，软件开发周期中的等待收益经常在不引人注意地情况下变大。错过的最终期限、延迟的特性，或者增加的缺陷积累成为我们开发生命周期的公认的副产品 —— 照常营业。但是相信“那是事情完成的方式”只是我们可以变更的习惯。

在整篇文章中，就缺陷的积累、未交付的特性、交付确定所需的时间，达到您的质量标准所进行的迭代数量，等等而言，我讨论了开发生命周期中的等待收益。我还讨论了减少等待时间，以及如何集中于整个目标和远景的技术。也许最重要的是，我建议我们重新定义主要标准，我们通过此标准来判断组织的健康，而不是通过我们所进行的滑落的实际数量，而是通过我们从中恢复得有多快和多不费力气。

在您的项目策略中包含“等待减少”计划将增加软件组织得适应性、灵活性，和生产力。有了对“等待收益和等待减少”问题的新意识，我希望您可以在您自己的项目中确定出一些等待减少的机会。

查看本文来源