管理依赖

管理依赖并没有什么秘诀可言。你唯一能做的便是将风险最小化，而最小化这些 由依赖引发的风险有一些关键技巧，我称它们为“五个如果”。

1. 如果去除它也可以运转，那就去除它。

少做少错是不言而喻的。减少特性总是能减少你的风险。在产品的早期版本中，

将某些特性改由人工实现可以消除风险。例如将开发客户支持申请表单换成直接提供 一个客户支持邮箱（形式为mailto:[email protected]），诚然这会增加一些工作量，因为 工作人员需要理清楚客户想要咨询的问题，但你并不知道到底会增加多少的量，所以 你应该推迟对该特性资源投入以减免风险。

2. 如果内部能构建，那就内部构建。

在谷歌一些最高效的团队，尤其是Android 和 Chrome，都强调要遵循“所有东西 都构建在内部”的方法。事实上他们也是这样做的，虽然这会让其他人不爽，还会在 某些方面拖慢开发速度，但它创造了一个允许高频率交付的环境。谁能抗拒交付的诱 惑呢！

3. 如果必须添加一个依赖，那就趁早添加。

把风险最高的问题放在最前面去解决，这样才能更早发现风险，更早采取适当的 矫正措施，从而增强按期发布项目的信心。

4. 如果必须添加一些依赖，那就依靠它上一个已构建的版本。

总有人会这样鼓动：“版本2 的 Foo 会更加好用，它的开发团队也进展良好！计划 用版本2 吧，版本 1 实在是太丑陋了。”其实这样做基本上是不经济的。风险是交付 的敌人。

5. 如果交付得早，被依赖伤害的可能性就小。

这条原则看起来有悖常理，实际上却很靠谱。你计划依赖的系统和产品总是在你 眼皮底下悄悄地发生改变。例如一个你依赖的有利的业务关系会因为合作方雇佣了一 个新的CEO 而失效，而你根本无法预测这样的事件。因此，早点交付总能帮助你降 低风险。

第 5 章

赢在测试 5

SHIPPING

GREATNESS

如果你交付的软件无法正常工作，卖不出去是一方面，更糟糕的是你会因此蒙 羞。这就是为什么我会对任何打算交付的产品进行“高中蒙羞测试”。这个测试很有 效。在高中年代谁没有因为荷尔蒙引发的冲动而留下过深深的心理伤痕，好莱坞等电 影行业还从中挖掘从而产生了巨大的社会影响力。你也可以利用这些心理伤痕，只需 扪心自问：“我能确信当一个高中老同学看到我的产品时我不会感到羞愧吗？”这就是

“高中蒙羞测试”的全部。

这个测试能帮助你确保你的团队是快乐的。汤姆·德马可和蒂姆·李斯特在他们 合著的《人件：富有成效的项目和团队》中指出：“伤害团队的一个最佳方法是要求团 队成员去做一些他们并不引以为豪的事情。”记住，你的工程团队成员都有一帮高中 老同学，别让他们因为你的产品而蒙羞。

那么，如何确保你交付的软件不会让你蒙羞呢？你可以遵循下面8 个主要步骤，

这些步骤对产品质量有着重大影响。

1. 坚持测试驱动开发。

2. 围绕优秀的测试主管组建测试团队。

3. 亲自评审测试计划和测试用例。

4. 自动化测试。

5. 虔诚地推行内部试用（Dogfood）。

6. 开展找虫总动员。

7. 勤勉且有条理地处理 Bug。

8. 任命可信测试者以构建最后一道防线。

做好以上8 步能帮助你在交付卓越软件的道路稳步前行。接下来让我们深入讨论 细节。