第二章 过程改进，没有灵丹妙药

    我们正面临着重量级版本发布前的最终决斗，我早已厌烦了人们满腹牢骚：依赖模块不稳定还延期交付。你是从哪个星球过来的？他们不稳定又延期那是当然的。

    没错，没错，软件包所依赖的另外一些软件包应该比自己的更稳健（稳定性依赖原则）。我已经不厌其烦地强调这个原则。但是当你为一个雄心勃勃的科技公司工作时，如微软，没人愿意干等着一项其所依赖的技术稳定后再行编码——至少我没遇到过这样的执行官。

    这就意味着你的依赖模块不稳定还可能会延期交付。这不是你所依赖的团队的错，而且下一次也不会有所改善。认栽吧——停止抱怨，该怎么办就怎么办。不知道怎么办？我知道会这样。

    作者注：停笔3年后，我在过去5个月中发表了4篇有关过程改进的专栏，这是第一篇。为什么停了这么久又突然思如潮涌？因为在这篇专栏发表前7个月，我重新回到了Xboxcom网站的项目组。我曾对开发专员、项目负责人及项目经理进行过培训，而现在我又回到了这个位置。

    在回来承担开发经理期间，我的专栏不是谈论迅速适应新角色就是讲一些我备忘录里的话题及一些新想法。当我从事新工作6个月后，效率低下使我不胜其烦。因此，我又重新去关注工程改进。

    锦囊妙计

    有5种方法可用来应对不稳定的依赖模块：

    1将强依赖转化为弱依赖或知识依赖。

    2通过交流及项目管理一举搞定。

    3尽可能地接近他们。事必躬亲、身体力行、亦步亦趋、互通有无。

    4吸取他们的成果为你所用。

    5建立多版本开发计划，构建稳定的接口及实际可行的时间表，要作一个引领者而不是追随者。

    等等，最后一种方法有点白日做梦——就只有4种方法可以应对不稳定的依赖关系。我们逐个讨论。

    作者注：通过建立多版本计划、稳定的接口、更实际的时间表以及成为一个引领者而不是追随者来避免不可靠还误工的依赖方所造成的麻烦，微软里的（不管哪里的）团队称之为：明天更美好，从而按预期时间表提供完善可靠的用户体验。

    这些明智的团队对新兴技术做了些牺牲，但是，记住苹果是一个很注重创新的公司，但是苹果的创新不是利用新兴的技术，相反，他们通过成熟的技术开创全新的用户体验。

    我想你脑子没那么死

    一个强依赖模块，就是如果没有它，你就铁定不能顺利发布产品了。如果它失败了，你也就失败了。一个弱依赖模块，具有一种回退机制。如果它失败了，你的软件仍然可以通过削减某些功能成功发布。

    不稳定的强依赖模块往往使你死无葬身之地。你会希望将它们改造成一个弱依赖模块从而有个备选方案。通常，方案包括使用依赖模块的前期版本，也可以削减功能，或买断依赖模块的版权，或是进行整合。

    备选方案往往更具心理作用。它们消除了对失败的恐惧及不确定性。谁都知道接下来将发生什么。产品中不会有新鲜的玩意——表现平平的预览版及乏善可陈的最终版。但此时人们仍然有积极性提供尽可能好的功能，没有了后顾之忧，人们就能更好地合作并解决问题了。

    取一段合作方的代码作为参考，试着从强依赖或弱依赖转换成知识依赖。你确实不需要对其他团队有所依赖，除了他们的知识与经验。

    知识依赖被轻视了——它们并没有得到应有的重视。因为你的团队或许不想使用一些强依赖模块或弱依赖模块，但并不意味着你不能从一些做过类似事情的人的才智与经验里获益。在第10章的“怀疑论及其他革新毒药”中我对此有讨论。

    沟通失败

    如果你正面临着交杂繁重的时间表，就如你以往参与的项目一样，你必须尽量与你的合作方沟通并作好项目管理。无论他们有多么可靠，也无论你的协调能力有多强。即使合作意向可以达成，关键的细节却没有定论。你需要经常重复地跟每个人沟通，并时刻盯紧每个预成品。

    你可能认为这些额外的沟通会很烦琐，但只要你处理得当就不会烦琐——通过经常性的面对面交谈、项目跟踪（如Product Studio或TFS）及通过Email交流计划变更。

    经常面对面交谈（一个星期左右）对于协调小范围的变更、修正发生的问题及对关键事宜作周全的检查非常有用。一次周全的检查只用5分钟就能对合作意向作出确认。（我们仍然能在两星期内提供关键样品，不是吗？我们仍然没被解雇，不是吗？）

    在工作项目数据库中进行项目跟踪，如使用Product Studio、TFS等商业软件包，对于跨团队跟踪Bug修复情况及工作项目的进展情况相当有效。与你的合作伙伴共享数据库查询，那么每个人都可以得到相同的状态信息。

    当你或你合作伙伴的计划变更时，每个人都应当及时知晓。先与各种人（Scrum负责人、项目经理及直接相关人员）通过Email联系。如果有些工作项目取消了，改变了或增加了，要马上更新工作项目数据库。在接下来面对面的会晤中，再对什么改变了以及为什么改变作全面阐述。这样做似乎毋庸置疑，但一人的细微改动对于别人就是伤筋动骨，这就是为什么你还得作个周全的检查。

    作者注：很显然，这种附加的交流及项目管理是一项额外工作。对于这篇专栏中提到的所有其他方面也是一样。额外的工作通常与项目管理者及测试者高度相关，但对开发者也影响重大。额外工作的分量与依赖类型（强的、弱的或知识性的）及复杂程度有关。要预备相应的计划方案。