2011年2月1日：“周期长度——生产力的老生常谈”
没有什么比浪费时间与精力更使我恼怒了。我这里所谈的不是培训、重组、激励斗志或度假。这些至少对于你的人生来说都是有潜在价值的。我讲的是创建时间、集成时间、多余的规格、不完整的功能、碍手碍脚的错误、满目疮痍的Bug及过分讲究工程质量的代码与过程。你知道——时光一去不复返。
几年前，我在专栏“精益：比五香薰牛肉还好”（本章较前部分）中已对所有这些浪费进行了批驳，但是我的例子及一些解决方案只对个人方面进行了评述，我并没有真正为团队指出一条明路。你需要一种途径找出极具危害的浪费问题，促使你的团队解决这个问题，使你的团队安枕无忧。
在制造行业，成功的秘密武器是降低库存。库存掩盖了你的生产问题，当你降低了库存，问题就显现了。修正问题并继续降低库存，渐渐地，你的浪费被根除，效率骤升。在软件开发领域，成功的秘密武器是缩减开发周期。概念与实现之间的用时越少，你所面临的障碍就会越多，而这些障碍常与工程无关。修正了这些问题，就释放出了生产力。让我来为你支一招，解放你工程的灵魂。
作者注：很多读者没抓住这篇专栏的要点，以为这只对网站与网络服务有用。而网站只是我举的一个例子，缩短开发周期同样对打包产品有效，如Microsoft Office。唯一不同的是，网站与服务是每月或更频繁地发布最新版，周期长度是两次公开发布之间的时间。对于打包产品或在线服务来说，公开发布是逐年或更长，其开发周期是完成一项功能的时间。
很多工程师问为什么缩减开发周期、协同定位、早期Bug修复以及其他精益概念之间会有不同。我对这样的问题感到奇怪，因为同样这些工程师就不会问为什么优化内部循环，避开磁盘I/O访问，捕获他们的代码错误这些会有助于提升软件执行效率。如果你真看不出来这二者之间的联系，你就该出局了。
一应到位
缩短开发周期的第一步要做的是，确定你的开发周期耗时要多长。对于服务来说，是两次公开发布之间的时间。然而，对于打包产品来说，缩短公开发布版之间的时间往往是不被市场所接受的。因此，周期的更好定义是开始拟定具体功能规范到完成功能开发之间的时间。完成功能开发到底是什么意思？这是关键。
你必须对软件功能及服务的发布定义一个“完工”（done）的概念。以下是我的团队所用的定义。我们认为对于每一个功能要有一个四要件，对于每一次发布有另一个四要件。我们每四个星期对Xbox.com网站进行一次发布——我们乐此不疲！
每项功能“完工”：
1对所有更新过的设计及代码进行了检查。
2编写所有的自动化测试并通过。
3不存在有碍产品推出的Bug。
4所有监测及健康检测工具到位（打包产品使用回馈工具）。
每次发布“完工”：
1所有本地化及全球化工作准备就绪。
2全面测试完成。
3解决所有质量问题及合作方工作到位。
4完成所有必需的发布文档。
如果你想缩短从头到尾工作的时间，通过这8项“完工”标准可以找出所有问题。让我来简要地讨论一下常见问题及如何处理。
如果你要创建
“完工”首先要做的是，检查更新过的设计及代码，这只是节省些时间。所以让我们来谈谈自动测试——单元测试、组件测试、压力测试、验收测试、系统测试及错误注入测试，等等。开发人员及测试人员必须共同参与这些测试系统的编写。由谁来写哪些测试依团队而不同。因为他们希望缩减开发周期，大部分团队对他们的测试套件（test harness）及运行测试的时间纠缠不休。
为缩减开发周期，你必须分清快速又频繁的测试与缓慢又寥落的测试之间的区别。很多测试在此进退维谷并重写或重构。
有一种测试套件就够了，你不必二者兼具——一个用来进行快速并有可靠性保证的签入测试及一个用于全面性测试。如果你在一个非常庞大的团队，即使一次快速签入测试都要耗时10～20分钟以上，那么或许应该让这支庞大的团队采用优先及平行测试技术。
同样，如果重新创建一个庞大的代码库需要10～20分钟以上，你最好采用高效的平行创建技术及依赖创建（build dependency）法。记住，创建、测试及签入组成了软件开发的内循环。所有有利于加快软件开发内部循环的做法都将使整体生产率成倍提升。
对于代码分支来说，你可不想主干有一条以上的分支。集成成本是很高的，每一个分支都增加了一次集成，要慎重考虑。假设你在生产个人便携式电脑，要使这些功能独到的组件逐一通过海关，这将使你的销售大计毁于一旦。每一个分支层次就如同在软件修复、功能模块及主干间增设了一个海关。
请神容易，送神难
在公开发布前清理大量的Bug确实会拖延开发周期。Bug的修复耗时越长，你就等待越久。在设计与代码审查中加入自动测试将大有帮助（就如重构面条代码及采用测试驱动开发）。不管怎样，重要的是尽早找出并修复Bug。即时修复Bug对短周期至关重要。
无论你怎么做，你还是会有Bug——我们是人不是神。有些Bug非常难找和修复，这些将使你们的工作慢下来。好消息是有一种架构对错误具有一定弹性，它能缓解修复最棘手（经常反复发作）Bug的迫切性。弹性架构可以让你在这些顽固、偶发的问题上收集数据并进行修复，只要对这些问题有足够的了解。
作者注：在相当多与此矛盾的专栏中，有一篇我对弹性机制做了更多描述，即“碰撞测试：恢复”（见第5章）。
我该怎么做
监测与健康检测常常是事后诸葛亮。这些节外动作徒增了跟踪检查客户方问题的时间，拉长开发周期。这跟打包产品中设计与使用客户回馈工具一样。
监测与健康检测需做事先考虑，一开始就得进行设计。想想你的软件为什么要这些功能，再问问你怎么知道它会按预期执行。这样会让你清楚地明白如何对它的使用进行监测并了解它的健康状态。
所有这些数据及快速的开发周期使快速回馈机制及实时改进得以实现。搞清楚在每个周期内所花的时间都用在了你怎样才可以让你的产品做得更好，以及如何能与你的团队相得益彰。
作者注：事前对监测与健康检测做好准备刚刚被加入到了我团队的“完工”条目里。糟糕的监测过程及缺失的健康检测使我们误入歧途，而只能看着我们的合作伙伴贻笑大方。
看我的
我们已经谈过全面测试的自动化，而本地化过程在微软是极其精到而快速的，所以下一个会产生问题的领域是完工（signoff）阶段。与质量相关的领域（如安全、隐私等）将有所涉及，而所有工程师一起修复Bug成为常态。然而，这些领域的完工如合作方完工一样，确实会延长开发周期。
虽然质量领域的问题是每个工程师的责任，但如果在一个质量领域的工程过程中指定一个工程师作为带头人，完工阶段就会达到最佳效果。这些工程师成为这些领域中的团队专家，这是个他们施展跨团队工作能力的极佳职业机遇。
因为团队专家自始至终在解决质量领域的问题，完工的要件及相关活动对于他们比起其他团队的员工来讲就要更快、更容易。另外，团队专家加强了团队与其领域中有关专家之间的关系，这样同样加快了工作进展并使整个团队快速成长。
作者注：我们在Xboxcom项目中为缩减开发周期所做的另一件事情是使功能团队协同合作（适当的时候包括相关的人员与销售商），这样使我们的生产率提升了20%（按已完成功能模块的规模及数量占整个公开发布版的量计）。
能不能再详细些
利用我所述的几种方法，我的团队已尽量将产品发布周期从一年几次增加到每4周一次。真是太捧了！在讲这些优点之前，让我来谈谈人们经常问的两个问题。如果在功能或架构改变上所用开发时间超过4周时该怎么办？有两个基本的方法：横向及纵向。
横向方法是一次只在一个协议栈的层面对这次大范围的变更进行改动，比如，先改变模式，再推出新的服务，再写新的模型，再是新的控制器，最后是新的视图。每个层面都可以在4个星期内完成。
纵向方法是将一次大改动分成很小的一些功能块。每个纵向功能块就可以在4个星期内完成。如果这些功能块使用户体验变得不连贯，你就可以暂不将这些更新的功能块提供给客户，直到有足够的功能块得以完成。
人们通常交叉使用横向及纵向方法。遗憾的是，横向方法经常引起每个协议层工程量过大并妨碍了互动的客户回馈机制。我更偏向于纵向方法，横向方法只作为最后的一种选择。
你怎么看待持续性工程（Sustained engineering）？从测试到正式发布过程中，每次持续性工程更新的最终验证大概需要一个月。而我们每4个星期发布成果一次，持续性工程只是我们日常工作的一部分。没有哪个正式版是按持续性工程发布的，除非在一些特殊的情况下，更重要的是，没有一个团队谈得上持续性工程的。其中五味杂陈——我们在犯错中痛着，并在前进中快乐着。
生活很美好
在过去的6个月中，我们都是每4周发布一次，我们实实在在地体会到了这样做的好处：
工程师们所抱怨的很多开销已经一去不返。我们本应该将这些开销投入到有益的工作中去。
遗漏是可控的。如果一项功能在一次发布中错过了一两个星期，那么它仍然会在一个月内再出现在发布中。
正式发布版不再是恐怖又疯狂的了。我们一直在发布，在4个星期内你所能发现的问题也就那么多。
事半功倍。通过流水线生产频繁地实现发布需求，我们的开发过程变得更快了。
我们使客户更满意，他们也注意到了。显著地提高问题响应及回馈的次数，备受客户赞赏。
虽然变更带来了些痛苦，缩短的开发周期使开销更少，出成果更快，使欢快无时不在。团队很开心，我也很开心。
今后，我们期望能在一两天内就出成果，就像我们的对手一样（他们可能正在嘲笑，4个星期这么长的时间）。我们并不想总是这么快地发布产品，但如果能这么做就意味着效率大幅提升。如果照此方法走下去，你将拉近与客户的距离，这对谁都再好不过。
作者注：为什么我们在Xbox com团队中采用4星期开发周期？因为很多领导者，包括我，知道这是提升我们团队生产率及客户质量的最佳路径。缩减周期及工作量是一项精准制造的古老技术，这可以追溯到20世纪30年代。
