2010年10月1日：“有我呢。”
我们正面临着重量级版本发布前的最终决斗，我早已厌烦了人们满腹牢骚：依赖模块不稳定还延期交付。你是从哪个星球过来的？他们不稳定又延期那是当然的。
没错，没错，软件包所依赖的另外一些软件包应该比自己的更稳健（稳定性依赖原则）。我已经不厌其烦地强调这个原则。但是当你为一个雄心勃勃的科技公司工作时，如微软，没人愿意干等着一项其所依赖的技术稳定后再行编码——至少我没遇到过这样的执行官。
这就意味着你的依赖模块不稳定还可能会延期交付。这不是你所依赖的团队的错，而且下一次也不会有所改善。认栽吧——停止抱怨，该怎么办就怎么办。不知道怎么办？我知道会这样。
作者注：停笔3年后，我在过去5个月中发表了4篇有关过程改进的专栏，这是第一篇。为什么停了这么久又突然思如潮涌？因为在这篇专栏发表前7个月，我重新回到了Xboxcom网站的项目组。我曾对开发专员、项目负责人及项目经理进行过培训，而现在我又回到了这个位置。
在回来承担开发经理期间，我的专栏不是谈论迅速适应新角色就是讲一些我备忘录里的话题及一些新想法。当我从事新工作6个月后，效率低下使我不胜其烦。因此，我又重新去关注工程改进。
锦囊妙计
有5种方法可用来应对不稳定的依赖模块：
1.将强依赖转化为弱依赖或知识依赖。
2.通过交流及项目管理一举搞定。
3.尽可能地接近他们。事必躬亲、身体力行、亦步亦趋、互通有无。
4.吸取他们的成果为你所用。
5.建立多版本开发计划，构建稳定的接口及实际可行的时间表，要作一个引领者而不是追随者。
等等，最后一种方法有点白日做梦——就只有4种方法可以应对不稳定的依赖关系。我们逐个讨论。
作者注：通过建立多版本计划、稳定的接口、更实际的时间表以及成为一个引领者而不是追随者来避免不可靠还误工的依赖方所造成的麻烦，微软里的（不管哪里的）团队称之为：明天更美好，从而按预期时间表提供完善可靠的用户体验。
这些明智的团队对新兴技术做了些牺牲，但是，记住苹果是一个很注重创新的公司，但是苹果的创新不是利用新兴的技术，相反，他们通过成熟的技术开创全新的用户体验。
我想你脑子没那么死
一个强依赖模块，就是如果没有它，你就铁定不能顺利发布产品了。如果它失败了，你也就失败了。一个弱依赖模块，具有一种回退机制。如果它失败了，你的软件仍然可以通过削减某些功能成功发布。
不稳定的强依赖模块往往使你死无葬身之地。你会希望将它们改造成一个弱依赖模块从而有个备选方案。通常，方案包括使用依赖模块的前期版本，也可以削减功能，或买断依赖模块的版权，或是进行整合。
备选方案往往更具心理作用。它们消除了对失败的恐惧及不确定性。谁都知道接下来将发生什么。产品中不会有新鲜的玩意——表现平平的预览版及乏善可陈的最终版。但此时人们仍然有积极性提供尽可能好的功能，没有了后顾之忧，人们就能更好地合作并解决问题了。
取一段合作方的代码作为参考，试着从强依赖或弱依赖转换成知识依赖。你确实不需要对其他团队有所依赖，除了他们的知识与经验。
知识依赖被轻视了——它们并没有得到应有的重视。因为你的团队或许不想使用一些强依赖模块或弱依赖模块，但并不意味着你不能从一些做过类似事情的人的才智与经验里获益。在第10章的“怀疑论及其他革新毒药”中我对此有讨论。
沟通失败
如果你正面临着交杂繁重的时间表，就如你以往参与的项目一样，你必须尽量与你的合作方沟通并作好项目管理。无论他们有多么可靠，也无论你的协调能力有多强。即使合作意向可以达成，关键的细节却没有定论。你需要经常重复地跟每个人沟通，并时刻盯紧每个预成品。
你可能认为这些额外的沟通会很烦琐，但只要你处理得当就不会烦琐——通过经常性的面对面交谈、项目跟踪（如Product Studio或TFS）及通过Email交流计划变更。
经常面对面交谈（一个星期左右）对于协调小范围的变更、修正发生的问题及对关键事宜作周全的检查非常有用。一次周全的检查只用5分钟就能对合作意向作出确认。（我们仍然能在两星期内提供关键样品，不是吗？我们仍然没被解雇，不是吗？）
在工作项目数据库中进行项目跟踪，如使用Product Studio、TFS等商业软件包，对于跨团队跟踪Bug修复情况及工作项目的进展情况相当有效。与你的合作伙伴共享数据库查询，那么每个人都可以得到相同的状态信息。
当你或你合作伙伴的计划变更时，每个人都应当及时知晓。先与各种人（Scrum负责人、项目经理及直接相关人员）通过Email联系。如果有些工作项目取消了，改变了或增加了，要马上更新工作项目数据库。在接下来面对面的会晤中，再对什么改变了以及为什么改变作全面阐述。这样做似乎毋庸置疑，但一人的细微改动对于别人就是伤筋动骨，这就是为什么你还得作个周全的检查。
作者注：很显然，这种附加的交流及项目管理是一项额外工作。对于这篇专栏中提到的所有其他方面也是一样。额外的工作通常与项目管理者及测试者高度相关，但对开发者也影响重大。额外工作的分量与依赖类型（强的、弱的或知识性的）及复杂程度有关。要预备相应的计划方案。
你中有我，我中有你
近距离沟通并迅速解决问题的最简单办法是参与到团队中：
事必躬亲。亲自出面了解你的合作伙伴。见个面及一起参与交际从而真正地了解对方。亲密的工作关系对于各个方面都很有帮助，你对双方的成功都至关重要。
身体力行。与你的合作伙伴多些实际接触。整个团队可能没必要，但是专门安排一两个人抽些空跟你的合作伙伴相处，你会对双方存在的问题有一些惊奇的发现。
亦步亦趋。随时与你的合作伙伴保持紧密关系。他们部署，你也开始部署，他们发布Beta版，你也发布Beta版，他们发布正式版，你也发布正式版。与他们保持同步可以让你省很多事——听我的没错。
作者注：灵活敏捷在这里确实很管用。采用简短的开发步骤并时刻准备着发布成果，这不仅有助于减轻你的工作负担，减少技术投入，同时也有助于使你与合作伙伴的产品版本保持同步。
互通有无。多了解合作伙伴使用的工具、工作项目数据库及源代码。对他们的工作了解得越多，就越有利于你预见、理解及解决问题。
作者注：即使你的合作伙伴的接口还没定型，最先的接口雏形也有助于你尽早地进行开发及测试。你可以自己写个模仿器，可以使用合作伙伴早期版本的接口，在其最终版本出来之前以此进行开发及测试。
自成一套
熟悉合作伙伴所用工具的关键点在于把握好你们两者间的交接环节。在他们部署新版本之前，他们应该运行你们所写的构建验证测试——只有你知道希望从合作伙伴那里得到什么；当他们部署新版本之后，你们应该运行他们写的摄取工具——只有他们知道哪些模块在运作、模块间的复杂关系及需要做哪些特殊处理。
你们写的构建验证测试应该能快速检测新版接口是否在你们的预期下运行。编写这些测试可能会有些烦琐，因为你们必须了解自己的应用模式，你们还必须在他们的测试系统上编写测试版。当然，当每次交接顺利完成，你会觉得所有这些努力都是值得的。
你们应用新版接口时，他们写的摄取工具应符合你们所有的需求。包括安装、库、说明、配置及许可。编写这些摄取工具并不会浪费精力，因为他们对你们或你们的合作伙伴的帮助是相同的。也就是说，当每次交接后，如果他们不用再为了使你们的系统正常运行花上两天时间，那所有这些努力都是值得的。
作者注：我们的团队随时备有这些工具。非常棒。
别嚎了！
即使在最完善的环境中，在开发的过程中也时常会有意想不到的事情发生。保持灵活性，以精短的开发周期快速应对变化，并与你的合作伙伴、客户及在你们的团队内部进行妥善的沟通，这样在处理意外之事时就会游刃有余。
责怪你的合作伙伴要少犯错误是无济于事的。即使他们确实错了。我们有缘相聚，我们共进退同患难。如果你们处理问题不当或没有及时发现问题，那你们同样也是在犯错。你们可以在下一次工作中改善沟通并妥善处理问题——问题自然就少了。
因为不稳定的依赖关系可能会带来麻烦事，这或许还让人高兴，所以就要更具有包容的团队意识，为客户带去更快速、更广泛、更强大的革新产品。
不要成为可怜的失败者。设立备选方案，加强沟通，凝聚团队，并按序对工作进行高品质的交接，勇于面对，必创辉煌！
