基本假定
创建一个瘦的且健康的组织
软件项目的脂肪燃烧练习
那些偶然滑落的原因
结束语
探究减肥和我们的软件开发项目中的“等待减少”之间的相似之处的灵感起源于我自己的个人健康程序。像许多软件，我个人的项目会维持非常长的时间。但是我很高兴的说，最初的版本是成功的 —— 我觉得即健康又令人吃惊。
同时，我最近无意中发现，IEEE Computer Society 出版物 IEEE Software 中的一篇文章，题目为“你健康吗 1 Rick Mugridge 和 Ward Cunningham 撰写的书籍 适合软件开发：集成测试框架 的评论，在其中将奥林匹克运动员的健康同软件开发的世界进行了比较。我已经提到了，各种各样的软件质量会议发布“项目健康 告”，作为追踪我们的软件项目“良好状况”的方式。事实上，似乎最近已经出现了许多文章、项目管理仪表板，和将健康和良好形象应用于软件开发活动的类似的东西。
因此这些身体上的健康和软件开发之间的相联是有效且有用的吗们自己去看…
基本假定
像人一样，每个项目是不同的：不同的团队成员、不同的技能，和不同的目标。正如一些人可以吃他们想吃的任何东西，并且从来不增加一盎司，而其他吃同样食物的人就会得到非常不同的结果。总之，对一个项目有效的不一定对下一个项目有效。但是不论您正在讨论的是什么类型的项目，都适用必然的原则。这也适用于我们的身体。
特别是，不论您拥有什么样的体型，减肥的关键是加速您的新陈代谢。新陈代谢对我们来说指的是您的身体燃烧您所吃的食物的速度。拥有快速的新陈代谢的某个人不会遇到保持苗条的麻烦。拥有缓慢的新陈代谢率的人可能吃得非常少，而仍旧增加重量。软件组织以十分相同的方式工作着。软件开发项目的新陈代谢率是组织完成所承诺的特性和任务的速度。等待的增加（与重量的增加相反）表现为缺陷、延迟的特性交付、错过的最终期限，和延迟的或去掉的需求（也就是，对于添加价值的资产的所增加的等待时间）的增长的积累的形式。我们组织的新陈代谢率越快，我们可以交付的特性越多，在不形成缺陷、延迟，和瓶颈储备的情况下，我们对增长的活动层次的响应的能力越大。
创建一个瘦的且健康的组织
要创建一个瘦且健康的软件组织，许多公司求助于“裁员”的方法。这非常类似于我们的时尚“饥饿节食”—— 并且有着类似的结果。这些方法可能在短期有效，但是它们会有不良的结果。
当我们进行饥饿节食来减少我们的卡路里的摄入时，我们不仅破坏肌肉组织，实际上还减小了我们的新陈代谢率。因为我们现在燃烧食物更慢了，所以在我们开始再吃正常进食时会更容易增加重量，这是与我们最初的目的相反的。
同样的，当我们的公司减少其劳动力时，我们减小了我们组织的新陈代谢率（也就是，我们工作的能力）。这迫使我们的劳动力以大量的缺陷、未交付的特性、错过的最终期限，和瓶颈的形式得以等待。饥饿节食的组织的等价物是一条破坏团队的肌肉和执行能力的向下的螺旋。虽然减少劳动力的目标是减少成本并增加利润，但是团队现在也许不能交付实际上增加收益的产品。如果那样的话，我们不能完成我们最终的目标，“赚钱”。
那么在交付高质量的软件产品的时候，组织能够如何重编其新陈代谢，使它可以交付更多并且同时快速减少等待收益呢p>
重新调整组织的新陈代谢
如果您想要减轻重量，讽刺地说，您必须要吃。关键是更经常的吃更少的食物，这样可以加速新陈代谢。（当然，您吃的东西也是重要的。）漏掉一顿饭，或者在任意一顿饭时吃太多的食物，将会越来越减慢您的新陈代谢。当提到在软件组织中应用迭代开发生命周期方法时，这一基本方法也有效。
在营养学家 Michael Thurmond 的书籍6-Week Body Makeover 中， 2 他将新陈代谢描述成“篝火”，并且将您吃的食物作为放到火中的原木。如果篝火燃烧的大而热，那么消耗掉您加入的额外木头是没有问题的。相反地，如果火开始灭了并且您将一大块原木放在熏烧的余烬上，那么原木就正好将火熄灭了。最好首先用引火柴和小枝子来给余烬加料，直到火再次燃烧起来。
软件项目是同样的方式。如果您的交付率已经非常缓慢了，那么您不可以期望团队交付大的特性。工作只是搁置在那里并且最终作为等待（积压）存储起来。但如果您以小的增量继续特性交付的周期，那么您将以正在进行的方式连续地交付特性 —— 这是迭代开发方法的基础。
软件项目恰当的节食
要成功地减肥，了解您的食物的基本化学性质是有用的。对减肥的目的最有益的食物类型是新鲜、完整，未加工的食物。加工食品不是用来吃或满足的有效方式，因为它们所包含的人造的化学物、盐，和防腐剂改变了我们的身体工作的方式。吃不干净的，加工食品来维持您的身体将不会得到良好的效果。
软件项目几乎以同样的方式工作。对项目来说最好消耗新鲜、自然、干净，简单“无缺陷”的代码。 3 但在当今的面向服务的体系架构、开源和外包的领域中，我们常常依赖于预包装的代码、应用程序或资源。因此，我们不可能总是准备我们自己的软件伙食来避免化学添加剂和防腐剂的等价物，也就是，缺陷。但预包装组件，像快餐，不会节省我们的时间吗经常吃速食堡和炸薯条的繁忙生活方式，使用预包装的代码的结果可能会是短期的，因为我们没有立即意识到这些选择的下游效应。一些相关的考虑如下：
通过使用预包装的组件，我们已经影响了我们自己的解决方案的可测试性。
预包装的代码损害了我们维护并升级自己的产品的能力。
预包装的代码天生地将产品的质量标准限制为最小公分母，也就是，最薄弱的环节可能存在于我们控制之外的代码中。
因此，在使用预包装的代码时，我们如何能够创建一个瘦的、聚焦于质量的软件开发环境面所提到的，不同的组织对这些类型的投入值的响应是不同的。不需要与第三方组件整合得很紧密的组织可能没有吸引或容忍它们的问题。对于需要与预包装的模块密切合作得团队来说，这里有一些增加成功概率的技术：
了解成分。就像阅读食物标签上糖、脂肪，和钠的含量，就您将要消耗的代码来培训自己。如果包装的产品没有与验收准则标签伴随出现，那么根据统计分析结果、代码检查、缺陷 告，和其他遵从已知的质量标准的其他标准来定义您的验收准则。
寻求“低盐的”版本，剥夺您的项目不需要的特性。就像油炸食物或在油和调味料中烹饪的食物减慢您身体的新陈代谢一样，包含您不需要的特定功能或特性的复杂组件可能减慢您的生产率，并且甚至可能使您倒退。不要假设您不得不接受整个包。正如许多餐厅愿意供应特殊的订单，请您制定用您聪明的选择准备的版本。
在放手之前，使用商定的验收测试来增加您的信心。如果可能的话，将特别地检查您预先考虑的潜在问题的验收测试自动化。例如，虽然创建测试来确保您的产品“如预期”工作是普通的，但是还包含获取您知道的外部组件中的行为的测试将导致其他模块的问题。不断地运行那些测试来标记将影响团队生产率或产品的可维护性的任何未预期的变更。
承认采用对外部组件的变更 —— 特别地如果经常做出变更 —— 并且因此修改您项目的进度安排可能会花费额外的时间。
创建桩或临时的（替代品）每日工作来处理依赖的代码区域。这类似于包装一个健康的快餐，放在车中作为储备，以确保您有一些合适的东西来消耗。如果外部组件交付迟了，或者没有按照预期工作，那么您拥有一个可接受的储备来支持测试。通过减少您的依赖性，您令解决第三方问题的这件事变得更加容易。
将您自己的代码加入开源库。这就像将您自己的菜带到家常的宴会上，为了确保您有能享用的一些合适的东西。
创建清楚、简洁并且明确的“契约”来提高与内部和外包团队的交流 —— 并且根据他们来工作。这创建了一个透明且可预期的允许持续反馈的环境。
软件项目的脂肪燃烧练习
要加快物理脂肪消耗的速度，我们可以结合练习程序和健康饮食。那么对于软件开发生命周期来说适当的练习程序是什么p>
虽然每个组织都是不同的，但是存在一些产生大多数浪费的典型问题域。就软件开发项目而言的浪费一般属于三类：（1）等待时间，（2）重复工作，和（3）缺陷生成。
在下面的部分中，我们将自定义一个软件项目的比喻性的“练习程序”，通过处理这些典型问题域的原因来帮助调节和加强。
减少来自决策延迟的等待
软件项目中最大的时间浪费者和获得等待领域之一是决策延迟。决策延迟的原因常常是害怕做出错误决策。但讽刺的是，选择不做出决策本身是一个延迟行动的决策，这没有将您带到接近正确答案的地方。即使是错误的决策令也能使您与可使用的解决方案更接近，因为您可以立即处理“所制定”决策的结果。您做决定的越快，您可以越快的前进并且在积极或消极的结果上采取行动。
我没建议冒失或突然的决策制定。我推荐快速进行可逆的选择，并且对非可逆的、高风险的项更慢些。如果错误选择的预计结果是较小的，那么我们应该根据我们现在知道的内容制定最佳决策并继续前进。在我们的迭代的且不断变更的技术环境中，我们不可能 100％ 确定知道任何决策都是正确的，因为决策是在未来实现的。因此，指定预定目标，并且不要为它担忧。一旦制定出决策，那么就停止对它的讨论。执行，学习所有随后的错误，然后只是继续前进。
对于今天您不能决定的那些条目，那么您需要定义一些具体行动条目，这些行动条目应该缩短您所在位置和您要做出决策所需要的位置之间的差距。确定您的每个动作都有明显的所有者和最终期限。在我的产品小组中，我们经常参加会议来努力地讨论一个问题。在大量的争论之后，我们散会，常常是因为我们需要参加另一个涉及另一个问题的会议。因此，我们不仅不延迟决策，而且我们没有将其加入到一系列事件链中，以使我们更加密切的沟通。
减少对于决策等待时间的有效练习是拥有一个恢复协议（Recovery Protocol）（参见图 1）。
比失败的每日构建的积累数字更好的过程成熟度指示器是能够多快速地从失败中恢复回来、创建一个可测试的构建，并继续下一个开发阶段。在上面，花费了三天（星期二、星期三、星期四），来“通过”该构建。对此项目的测试延迟了三天。就减少等待时间而言，对如何减少确定时间率的因果分析不会比计算构建失败的频率的数字更有益于团队的整个效率吗p>
使每日的构建对减少等待时间更有用的另一个方法是对首先确定什么失败划分优先级。重要的不是构建是否“通过”或“失败”—— 而是我们可以从构建统计数字中获得什么有用的信息来将活动划分优先级。然而，许多软件开发过程利用构建状态盲目且人工地把守进展的下游。人工地把守进展导致了延迟和等待。即使当我们将我们的测试用例流线处理为那些只“应该通过”的内容时，我们也可能落入该圈套。
让我们重放刚描述的用来例举等待减少方法的场景。我们知道星期二的构建只包含预计在此通过的测试用例。星期二的构建因为与 TestCaseA、TestCaseB 和 TestCaseC 相关的缺陷而失败了。TestCaseA 和 TestcaseC 对产品的正常启动和安装是至关重要的。除非那些测试用例通过了，不然团队将停止于此处，不能进行所有重要的测试。TestCaseB 也是重要的测试用例，但它位于测试循环的下游。因此，我们不会在开始的几天执行 TestCaseB。其间，John 将其工作着重于 TestCaseA 和 TestCaseC。John 能够在星期三确定 TestCaseA 和 TestCaseC。我们将 TestCaseB 从“预计通过的测试用例”列表中去除，并重新执行构建。星期三的构建通过了。测试团队解除了此处的等到，并继续前进。John 在星期四确定了 TestCaseB，更新“预计通过的测试用例”列表，而且构建通过了。测试团队收到了带有更新了的构建，并且为该领域测试及时地确定了 TestCaseB，没有减慢测试进度的进展。
图 2：在软件生命周期的不同地方修复缺陷的成本
缓和团队之间的紧张局势
“专业的产品关系就像契约。” 6 为了建立和维护这样的契约，我们需要了解对方的角色。例如，如果您需要一些来自于我的东西来做您的工作，那么您会希望我对您期望的东西有清楚的了解。
在许多软件开发项目中，开发人员和测试人员（以及其他团队）之间的关系，由于误解、失望和挫折形式的紧张而被玷污了。测试人员和开发人员解决问题的方式的差别是该关系的阴和阳。表 3 列举了一些开发人员和测试人员可能持有的非典型的态度。
作为测试人员，我们可以进行两个重要的加固练习，来帮助缓和与开发人员和其他团队成员的紧张局势。首先，我们可以在测试团队和组织的其他团队之间创建一个清楚、精确，并且明确的“契约”。第二，我们可以达成该契约的测试终点。
加强项目的成功标准，并且清楚地描述各种角色、期望，以及每个成员打算如何完成目标，这对创建一个可使用的专业关系契约 —— 以及减少由不必要的紧张局势引起的等待 —— 是必要的。
通过身体塑型来构建强壮的团队
那么让我们说您已经实现了上面的策略中的一部分，并且您的项目开始减少等待。您组织的新陈代谢显著地加快了，并且您的团队恢复了活力。但是您如何能够将此进展维持在连续的基础之上呢p>
是时候塑造您的组织，用以创建您想要的确切的“身体”。精确地身体塑造指的是造型及定义身体每个区域的能力，以便它看起来与您想要看起来的样子正好一致。肌肉燃烧脂肪，您组织中的人员是它的肌肉。因此，以适当的比例调和并构建恰当的团队成员将让您的组织运行的瘦并且平滑。那么我们如何以此方式对我们的软件开发组织塑形呢p>
对任何身体塑形的第一个步骤是设计一个身体蓝图（Body Blueprint）或者个人的开发计划。下面是通用的方法，以及软件开发组织的具体实例。
身体蓝图中的一般步骤：
对您（或您的雇员或您的组织）现今所处的地方做一个自我评估。
确定您想要到哪里。
强调问题域和“这里”及“那里”之间的差距。
首先开始对确定目标的鲜明区域的精确塑型例程。
概括短期的目标以确保您达到了对您所期望的时间表的目的地。
创建奖励机制来推进短期的目标。
一旦发生了重大的变更、重新评估并重新设计改进的下一个层次的身体蓝图。
重复…
这些步骤可能听起来简单。但是在应用它们的时候，您不但定制了对应您个人的需求的程序（不论是与您的体型、产品，还是组织相关联），而且还持有过程、执行和结果的所有权。采用这些步骤集中您的精力和意图，并且将促进重要的变更。
在软件开发组织中，您可以使用许多东西来评估并定义您的产品。一个众所周知的方法是在您的开发生命周期中的每个迭代或里程碑的入口和出口标准。当然，许多软件项目执行上面的步骤 1 和 2。它们确定出它们的目标，并且根据那些目标跟踪它们的进展。我们甚至每周强调两者间的差距及执行概要。
我们执行不好的是步骤 4 及超过的内容。开发组织声名狼藉地乐观。如果我们感觉到我们正在失去动力或者落到后面，那么我们很有信心可以赶上。没有做额外的培训或技能评估来评估我们有效地完成任务的实际能力或才能。所需要的唯一的方针变更是“更努力地工作”。不幸的是，这种习惯性的思维假设我们在开始滑落时没有付出我们自己 100％的努力。它还假设首先我们能够实现目标。
另一个普遍的错误是，我们没能开发出今天我们应该所处的地方的清楚的画面。我们知道我们应该在 X 天 完成，并且可能我们认为我们知道今天所在的位置。但如果我们没有在路上标出的短期的目标和里程碑，我们不会真正地确定我们是否落后或先于进度。
可虑这一假设的交流：
Joe：“在我们的交付中团队落后了。您对回到进度上的计划是什么/p>
Mark：“我们发现我们没有对此领域充分了解的员工。我们目前正在寻找一些承包人来短期帮忙。”
Joe：“要多长时间，并且成本多少/p>
Mark：“最终交付计划在三个月后，因此契约将持续三个月。我们将需要三个额外的人员在该时间内完成任务。”
Joe：“要额外的成本吗需求/p>
Mark：“嗯…我们计划为每个承包人分配一个开发人员，作为伙伴或顾问以减少对我们的产品和编码标准的学习曲线。我们需要为每个承包人找到办公空间和设备。我们还考虑远程的方式。”
Joe：“那么，总的来说，你们花费时间来寻找并雇佣三个人员，需要分配空间和设备，将要打断或减慢至少一个开发人员来指导或培训新的人员，并且你的团队不得不承担与更大的团队相关的增加的管理和协作功能。如果承包人远程工作，那么需要有额外的指导、管理和管理复杂度。这样我们在同样的时间框架（在其中我们不能完成原来的任务数量）内增加了半打任务。这样怎么工作/p>
Mark：“我们会更努力的工作。我们会完成的。”
夸大之词吗是，但它例举出，当我们没有向下看到我们交付的技能和能力时，我们最终将会落后。
那些偶然滑落的原因
虽然生成零缺陷及零停产事件的应用程序是我们应该不断渴求的极致目标，但是更现实的是承认我们将时常地遇到滑落和牵绊。就像在我们个人的减肥过程中，我们的软件开发项目会由于像下面讨论的那些原因一样而滑落。
知道了这些滑落会时常发生，并且对它们做好准备，使我们有控制地响应，而取代不假思索的反应。让我们看看一些响应一些普遍的错误的适当的方式。
关注点放错了地方
从软件开发的观点看，我们的错误反应为生成的缺陷的数目。在物理的领域内，“此时此刻您是否是一个确定的指示 —— 是您四肢上的挫伤和擦伤的数量。当您不注意的时候，您碰到桌子、椅子、门口，凡是您想得到的。” 9
整个开发团队的集体目标是生产出客户会重视的东西。真正地从事于对每个迭代和阶段的质量输出的创建是关键的。这意味着在需求审阅活动过程中，举例来说，开发人员的主要任务是“需求审阅。”在设计活动中，开发人员的主要任务是创建并审阅设计文档。在编码活动中，开发人员的主要任务是生成没有错误且与客户相关的代码。在文档审阅活动过程中，开发人员的主要任务是确保用户辅助材料和错误消息足以平坦客户的学习曲线。在安装和部署的过程中，开发人员的主要任务是确保客户可以很容易地安装并配置您的产品，以便他们可以尽可能有效地完成他们“实际的”工作。
如果在需求审阅会议或电话会议走查过程中撰写电子邮件或编码，您的注意力就放错了地方。如果您开始人工测试，然后离开去和某人谈话，或者完成另一项任务，那么您不会注意到测试揭示的任何出乎意料的结果或定时问题。即使您全神贯注于在特定的日期提交您的代码的最终期限，您也被进度分散注意了，并且不是完全投入于现在进行的一对程序设计和测试中。
那么，什么可以帮助我们抵抗注意力的分散并且以任务为中心呢可以通过设定更小的、短期目标并且当我们达到目标时奖励一些自己的方式来待一会。注意其他人是另一种保持连续的方式。我们可以通过在其他人帮助我们达到短期目标时奖励并感激其他人的方式来做到这点。着重于通过迭代的里程碑，反对孤立于您的对长期的交付的骚乱的团队目标也有帮助。
留意该（关注的）时刻要求不只是在现场。这是我们必须积极地并且不断追求的东西。它需要可以由事件来变换。考察我们是否实际地关注了好测试的方法是，如果我们觉得在离开事件时与进入时一样，那么我们真正完全地致力于该活动。
友好的及自我怠工
如我上面谈到的，许多测试团队完全有理由抱怨它们由于构建失败而不能继续工作。作为测试人员，我们感觉到，我们通过强调问题来完成工作 —— 现在改正问题是“其他人”的工作。在我们“置于等待”时，我们非常繁忙，也许是致力于不同的领域，像不是为此次迭代安排的可有可无的特性。不幸的是，我们的“可有可无”的特性中没有一个可以减少当前的等待时间。每个人都正努力工作。但是项目越来越落后。因此，我们滥用了时间。
如果我们马上完全参与并且分担解决问题，那么我们可能会以我们的才能和技能找到复制的方法。最好将时间花在辅助构建团队来调查错误上，或流线化构建验证的测试用例上，或将前进所需的最小确定划分优先级，或者帮助测试一些此次迭代的限定发布的组件。虽然我们很忙，但是实际上致力于手边的事件。我们没有辅助减少等待。
这是所谓的友好怠工。像刚描述的这样的情况使我们感觉到我们在不成为延迟的原因的情况下还有更多的时间。只要“他们”阻塞了，“我们”可以致力于我们想要致力于的事情上。
自我怠工看起来非常类似，除了“我们”是构建团队之外。我们不让或允许任何其他的团队来辅助。我们不试验或调查在过去我们如何完成任务的备选方案。
两个实例中的圈套是“我的工作或你的工作”的心态。每个人都有不同的技能和才能，足够真实。每个人都有他们的主要责任和任务，非常真实。但是，如果产品从来不装载就没有这样的问题。注意真正的目标 —— 在计划的迭代中交付商定的、增加价值的版本 —— 帮助我们避免这些牵绊。
会义务
在个人减肥的场景中， 会义务是 会功能、宴会、假期，以及那些娱乐的中心是食品的地方。在软件开发情景中， 会义务在您没有完全控制开发环境时出现。以下是当您觉得自己什么都没有时增加您的控制的很好的练习。
将您的精力集中于您控制的领域。
概述出您的整体目标、远景和成功标准。
利用支持那些目标、远景和成功标准的标准和验收准则或预期内容。
对那些预期的内容、角色和时间表取得一致（类似于专业契约）。
执行您自己的任务，并且辅助其他人来执行他们的任务。
该方法增加您在工作环境中的影响。正如浴室磅秤，这些控制帮助您着重于您的目标并追踪您的成功。
另一方面，一旦您将那些控制就位，不要盲目地成为它们的奴隶。记住控制是用来支持更大的视界（您的原则和价值）的。像磅秤一样，控制只是测量工具。计划是减少等待，并且构建健康且灵活的开发组织。在增加客户满意度的同时，我们应该更感兴趣于我们投放市场的时间。因此，不要让控制导致等待收益。
例如，您全部的目标中的一个是交付零已知缺陷的产品。如果您满足了客户的期望，那么为了那些缺陷的工作是可接受的，并且您的自动调整允许客户完成他们的工作，然后，您拥有少量的缺陷的事实不需要延迟产品发布（尽管您的发布标准按别的方式陈述的）。
当我们在 会情况中遇到压力或压抑时，我们知道我们经常求助于方便的食品（巧克力、糖，等等）。甚至是在软件项目中，在压力和恐慌的时期，我们倾向于求助于我们的舒适地带。不幸的是，有时候这意味着我们回到了坏习惯。通过利用恢复协议，在艰难时期，我们可以与我们整个的视界、价值和目标保持同步。
如同健康程序一样，庆祝短期的成功将镇静恐慌并加固您的新习惯。审查团队目标将避免那些艰难时期中的所有消极的怠工。设置带有验收和成功标准的契约将提高您对外部组件的影响。通过将这些想法应用到您特定的情况下，并且与其他人分享，您不仅可以提高您自己的效率，而且提高团队或整个组织的效率。
结束语
正如多年逐渐积累的体重一样，软件开发周期中的等待收益经常在不引人注意地情况下变大。错过的最终期限、延迟的特性，或者增加的缺陷积累成为我们开发生命周期的公认的副产品 —— 照常营业。但是相信“那是事情完成的方式”只是我们可以变更的习惯。
在整篇文章中，就缺陷的积累、未交付的特性、交付确定所需的时间，达到您的质量标准所进行的迭代数量，等等而言，我讨论了开发生命周期中的等待收益。我还讨论了减少等待时间，以及如何集中于整个目标和远景的技术。也许最重要的是，我建议我们重新定义主要标准，我们通过此标准来判断组织的健康，而不是通过我们所进行的滑落的实际数量，而是通过我们从中恢复得有多快和多不费力气。
在您的项目策略中包含“等待减少”计划将增加软件组织得适应性、灵活性，和生产力。有了对“等待收益和等待减少”问题的新意识，我希望您可以在您自己的项目中确定出一些等待减少的机会。
