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

    深入探讨

    当然，你也可能只会死板地运用Scrum和极限编程：你先在“基础框架”上花费工夫，而让客户苦苦等候着他们想要的功能。为了定期获得客户的反馈，快捷的周期循环要有个基本前提：开发应该“深度优先”，而不是“广度优先”。

    确切地说，广度优先是指对每一个功能进行定义，然后对每个功能进行设计，接着对每个功能进行编码，最后对所有功能一起进行测试。而深度优先意味着对单个功能完整地进行定义、设计、编码和测试，而只有当这个功能完成了之后，你才能去做下一个功能。当然，两个极端都是不好的，但深度优先要好得多。对于大部分团队来说，应该做一个高层的广度设计，然后马上转到深度优先的底层设计和实现上面去。

    这正是微软的Office功能小组的工作方式。首先，团队对他们需要哪些功能以及如何使这些功能协调工作做出计划。然后大家被分成各司其职的多个小型团队，每个团队自始至终一次只负责一个功能。最终结果是，一个运行良好且稳定的产品快速地交付给用户进行试用。

    作者注：当然，功能小组（Feature Crew）的想法并不新鲜。然而，在一个像Office这样庞大而活跃的生产环境中，能够找到一种方法去实现精益软件开发已经是一个重大的成就了。你要知道的是，Office系统现在已经拥有多种桌面应用、服务器应用和大型的在线服务。

    深度优先通过把注意力放在将被使用到的工作上，而不是可能永远不会被客户关注或者面面俱到而永远得不到定论的“基础框架”上，这样就能减少过量生产。另一个出色的深度优先开发方法是“测试驱动开发”（TestDriven Development，TDD），但我想在后面“过度开发”那一节中再展开讨论它。

    运输

    第二个极度浪费是期望万事俱备。在制造业中，这通常是指零部件的运输问题。对于软件来说，这个“运输”指的是团队之间可交付成果的传递。这里有3个令人厌恶的运输问题之源：创建、分支和Email。

    ·创建：创建花费的时间越长，浪费的时间就越多，这是我想让你引以为戒的。极限编程和敏捷方法都坚持每天创建，而这条规则他们很可能是从微软学去的。但对于大型团队来说，每天创建越来越不现实。幸运的是，我们已经安排了优秀的人才来解决这个问题，但这确实是个大问题。这点不用多说。

    ·分支：我喜欢Source Depot。它对整个公司的价值是巨大的。但它也像一只宠物象一样让人失去兴趣：当它还小的时候非常可爱，但经过几年的喂养后，灵活性就逐渐丧失。建立代码分支是个很好的主意，因此很多大的团队都这么做了。现在假设你在A2B3C1分支上工作，而你的伙伴在A3B1C2上实现了一个关键功能或者修复了一个重大Bug，那他们首先需要把C2横向集成到B1里，再将B1横向集成到A3，而你必须将A3纵向集成到A2，再将A2纵向集成到B3，将B3纵向集成到C1。天哪！！！等所有这些集成都做完了，黄花菜都凉了。这种做法还仅仅是你当前周期内产品生产线的一个分支。

    作者注：Source Depot是微软用于管理上亿行源代码和工具的大规模资源控制系统，包括版本控制和分支管理。

    Email：最后一个运输噩梦是Email通知单。项目经理告诉开发和测试人员规范书准备好了；开发人员告诉测试人员说编码完成了；测试人员告诉开发人员说他们的代码有Bug；开发人员告诉项目经理说他们的设计变更有问题；还有我的个人问题：与客户、依赖方或者零售商之间的沟通，特别是越洋沟通。极限编程和敏捷方法通过废除这种形形色色的岗位角色和每日召开会议来解决这个Email通知单问题。但对于外地零售商和依赖方，这行不通。我们只有在可行的情况下才使用自动通知功能，在必要时才用Live Meeting，以及通过Email给对方一个明确答复来减少Email的恣意蔓延。

    行为

    第三个极度浪费是仅仅为了找出问题而花时间。在制造业中，这是对机械和人工行为的一种浪费。在软件行业中，就是把时间花在研究做什么、怎么做及怎么调整原先方案上。糟糕的搜索技术是行为浪费的一个典型例子。不可测试、无法维护、无法管理的代码同样是一种浪费。

    设立中断及调试参数有助于快速找出Bug及减少浪费。设计复审、代码复审、代码分析和单元测试都能达到减少浪费的目的。极限编程居然建议“结对编程”（Pair Programming），但我个人认为，这样做是对资源的一种浪费（除非开发人员是在一起学习一个新的代码库）。团队软件过程可用于检测你所有工作及弊病，你可以清楚地了解到你的时间是怎样花掉的，因而你也能大大地减少你的行为浪费。

    作者注：在一些陌生领域，为了开发一些新鲜的玩意儿，我的团队已经采用了“结对编程”法。它相当有效。

    一个特别讨厌但能避免的行为浪费是复制Bug修复信息，因为代码注释需要同时变更，Source Depot需要重新集成，Product Studio需要重新整合以及收到邮件后要相应地进行工程改进。每个人都浪费劳力去管理Bug和项目进度数据的多个副本。有一些工具可以让这类事情变得简单，信息只需输入一次，便能自动被传播到其他所有的地方。这类工具可以有助于减少无谓的行为。