按功能实现，而不是按架构——保持项目节奏实践之三

逐个功能进行实现和测试

哈威、维贾、道、兰迪、肯和梅布尔，负责提醒功能的团队

我是哈威，团队的头儿。我们的开发人员包括维贾、道、兰迪和肯，梅布尔是测试人员。我们在GUI、平台、硬件集成以及几个方面都有专家，而梅布尔无所不知。（背景中传来笑声。）

刚开始的时候，我们试图先把架构开发出来，再制订规范，告诉大家我们在做什么。我们每个人各自负责一块，最后再放到一起。可是一切都没有按计划进行。因为即使我们有规范，在开发各自的组件时，我们总会改变些什么。

梅布尔曾经听过有关按功能实现的说法，并告诉了我。我问大家是否愿意组建一个基于功能的团队。嗯，其实是基于功能集合的团队。我们开发所有的提醒功能，一次完成一个，从前端到后台。梅布尔会负责测试。

开始时有点儿困难，不过习惯之后，我们添加功能的速度让人惊喜不已。我们不再是每个人开发很多代码然后再集成到一起，而是只添加每个提醒功能需要的代码，再进行测试。梅布尔保证我们不要出现系统级别上的问题，我们保证每个提醒功能不要出问题。

我们的开发速度如此之快，不久就有新的功能需要开发了。现在，有些其他组也在尝试我们的做法。整个项目的进度都加快了，而且客户也能知道我们在开发哪些功能，反馈也由此而来。

很多项目团队都是按照架构进行组织的，比如基于Web的产品会分平台组、中间件组和GUI组。可是如果按架构进行实现，项目经理就很难知道开发完的功能是否可以正常运行，除非等到整个产品集成完毕。如果按架构实现，就很难进行持续集成了，因为无法构建和运行测试。在开发的开始阶段，没有哪个功能是完全实现的，都要等到快结束的时候才能做完。而且，项目经理也无法将任何功能视为完成。

所有已经完成的开发工作都是在创建“浪费”［MP06］，没有产生任何有价值的东西。一旦完成某些功能，就可以开始计算价值了。可是在此之前，这些价值无法衡量。

按架构实现会打乱项目的节奏，因为得到的都是部分完成的功能。不到开发完成，项目经理看不到完整的功能，而这时得到的反馈对开发人员来说就太晚了。如果按功能实现，开发团队只要针对某个功能的要求利用架构进行实现就好了。假如要开发Web应用，项目经理可以组织一个小型的基于功能的跨职能团队，其中包括一些了解平台的人员、一些了解中间件的人员和了解GUI的人员，他们各自负责自己擅长的工作，并且只针对团队负责的一个特定功能。要是团队人员拥有不同的兴趣和技术技能，比如擅长GUI和固件方面的技术，这些人就可以按照功能逐个应用他们的技能。（项目经理应该帮助他们组织好各自在项目中的工作时间。）

有些团队认为，应该在项目前期预先细化需求（Big Requirements Up Front，BRUF），并进行大量设计（Big Design Up Front，BDUF）。这样的团队要想切换到按功能实现的方式，就没那么顺利了。这时，可以跟他们说明一个功能应该是什么样子（它应该有多小），并让他们知道自己不应该做什么（参见5.3节），帮他们了解实现的功能要具备足够的架构完整性，从而在实现后续功能时也不会有问题。要提醒这些团队，他们在调试和测试的时候，都是按功能进行的，因此不会陌生。

有些人可能仍持反对态度，说他们在考虑一个功能之前，仍需要知道整体架构没有问题。这种情况下，架构草稿会有所帮助（参见3.5节）。不过不要坚守其中的架构，除非团队已经实现过不少功能了。

9.3.1. 首先实现具有最高价值的功能

在按功能实现时，要先实现最有价值的功能。把风险最高的功能先往后放一放。如果运气足够好，也许根本不用开发这些高风险的功能。这样一来，测试人员和开发人员就能对整个系统有足够的了解，他们就可以保持自己的节奏了。

有些团队不愿意按功能实现，因为他们不知道先开发哪个功能。团队中有些人会希望先开发风险最高的功能，有些人希望先开发最有价值的功能。如果没人愿意排定需求的优先级顺序，那就很难知道哪个功能最有价值了。

如果没有客户或是客户代理的参与，你作为项目经理，就要在团队的辅助下，担起制订和发布产品待办事项列表的责任（参见16.6.1节）。项目经理要判断出各个功能的实现顺序。

如果有人愿意判定各个功能的价值，那就按价值高低进行实现，即便会给架构带来风险也要这么做。

如果功能的价值和完成度越高，项目经理就能在当前项目中为自己和团队带来更多灵活性。你也许可以尽早发布（如果高风险的功能无法使用当前架构），这对很多客户都是很有价值的。推迟开发高风险、低价值的功能，可以保持项目的节奏，并降低当前版本的风险。

9.3.2. 按功能调试

有些团队坚持按架构实现。到了测试的时候，测试人员却是逐个功能进行的。这么一来，团队在调试的时候也得按功能进行了，即使他们构建产品的方式与此不同。

为了按功能调试，项目经理要构建跨架构团队（要么就得能够接触到所有团队成员）。如果从来没有组建过跨越架构的团队，项目的节奏会因此而扰乱。不过，要是没有跨越架构的团队，问题是无法解决的。

要是到了项目尾声，发现团队在按功能调试，那还是考虑在一开始就按功能实现吧。这会减少项目的干扰，同时项目节奏也更平稳。

9.3.3. 按功能测试

测试人员会按照功能测试系统，有时是因为需求的编写方式，有时是因为这就是测试人员访问系统的工作方式。当测试人员报告问题时，他们很少会单独报告各个小架构组件上的问题。实际上，他们会在测试用例中提出问题，比如，“当我试图打开一个银行账号时，我可以看到数据穿过中间件进入到数据库中，但是我看不到返回的确认。”测试人员在这里报告了一个中间件的问题，但是没有明确指出是在哪里。

开发人员已经习惯于看到这样的报告了（不管是与调试还是测试相关），也惯于回溯问题，以判断功能是如何与架构交互的，从而理解问题。按功能实现，开发人员就可以在设计和编写代码时看到潜在的问题，不至于到开发尾声才发现。