回顾那些失败的项目，无一不是需求分析不全面、不完整导致项目不断变更、延期，最终以质量的牺牲来结束项目，因此项目管理中我更注重需求的管理。本次由Iverson主讲的这部分受到我的关注，在此感谢Iverson的无私分享和充分的准备。

凡是受到实践检验而总结出来的成果，无疑是值得借鉴和学习的，而下面的内容完全是Iverson不断实践得出的经验：

在需求收集的过程中，对于这些项目，很多业务的专业性都很强，虽然之前也会对这方面的业务做一些了解，但是和专业人士相比，还差得远，所以在每次需求讨论的开始，我会请求用户对这个需求的背景做一个详细的说明，以及这个需求实现的目的。

 在用户介绍完了背景和目的之后，对需求的业务也就比较了解了，此时用户再谈论需求，对需求本质的把握就会比较容易些。

 说到这里，顺便说一下什么叫本质用例。根据Scott.W.Ambler的定义，有两种风格的用例模型：反映用户行为需求的本质用例模型以及反映分析的系统用例模型。

本质用例模型通常称为业务用例模型或抽象用例模型，用于对行为需求建立独立于技术的模型，注意，这里的重点是独立于技术。

系统用例模型也叫做具体用例模型或详细用例模型，用于为行为分析建模.

 回过头继续需求收集的过程，需求收集最重要的是要准确理解用户的需求，所以我认为这其实是一个反馈、审核、确认不断迭代的过程。

 1 如果可能，最好让最终的开发人员一起参加需求收集过程，这能避免各个中间环节造成的越来越大偏差的累积。

 2 会谈时，当用户描述完一个主题时，需求收集人员需要把这个主题通过自己的理解，向用户复述一遍，让用户确认收集人员理解的需求和用户的需求是一致的。

 3 使用白板或者记事本画出流程图或者本质界面图，需求人员和用户通过对图形的分析，达成一致，图形，往往能更直观地说明问题，对于涉及到界面的需求，这个时候形成本质界面。

 4 会谈结束后，尽快把需求收集内容整理成正式的文档，提交给用户，用户一般会对用户做一次审核，若有错漏的地方，用户会指出。

 5 经常，上述过程完成后，会进行一次需求审核会议，约定相关用户，对正式的需求文档进行审核，确认正式文档的需求是跟用户的要求一致。

 这是我在实际项目中的需求收集的一个过程，实践证明还是很有效的。

 对于需求收集会议的一些注意事项，大师们有个总结：

 会谈对象：潜在的用户、问题领域或技术领域专家。

1 事前发送一份议程，给出预期内容，让参加会谈的人对会谈有所准备

2 事前几小时确认会谈将如期举行，否则改期。

3 会谈开始时，对会谈者能抽出时间表示感谢。

4 告知谈话人项目的相关内容和他在过程中的作用。

5 简要说明要讨论的话题，并确认会谈要持续的时间，这有助于帮会谈者确定预定目标，而且，会谈者在会谈过程中帮你控制时间。

 6 尽快提出关键性问题

7 向对方询问你是否遗漏了什么，或有什么要补充的。

8 会谈结束时，总结要点，确保没有遗漏什么内容，并确保理解所有内容。

9 会议结束时，再次感谢谈话人。

10 告诉谈话人什么时候可以整理完成会谈记录（最好是刚刚结束立马整理，内容还保留得比较深刻），并告诉对方会把会谈记录反馈给他们，让他们确认内容没有被误解。

11 学会倾听，并适时地做一些重复，有助于理解谈话内容。

12 区分哪些是需要完成的，哪些是希望完成的，这两者区别很大，不要镀金。

 上面这个过程是需求收集的一个过程，接下来，说一点需求分析方面的

 需求分析，在我经历的项目过程中，一般已经和系统设计关联在一起，往往系统框架，系统分层策略，组件部署策略已经形成方案。对开发小组来说，有个业务建模的过程；而对于大多数用户来说，界面就是整个系统。我们需求的分析结果，通过系统用例和系统UI界面与用户进行沟通、确认。

 曾经有个系统，用户在一个省，而开发人员在另一个省，当时是这样做的：

 前期在用户所在地，面对面的做了需求收集，并形成了本质用例和本质界面。然后开发人员回到自己所在地做系统开发，因为这种情况下用户不大可能时常与开发人员在一起，为了保证开发结果的准确性，我们用visio画出系统UI，并对操作流程在UI图上做了详细的文字说明，然后用邮件发送给用户评审，用户评审完后把意见发给我们，反复几次之后，一般就能得到比较准确的结果了。当时开发的结果，用户还是比较满意。

 这个应该算是系统原型法，我用过2种：一种是抛弃型的，比如上面的系统UI图和一些演示性的、通过各种方式完成的能说明系统运行情况的制品；另一种是可以复用的程序原型，系统的结构和以后开发的真实系统差别不大，通过接口分离和模拟数据，营造出系统实际运行的假象。一般来说，后者的效果更好，但是有个问题，会对用户造成错觉，认为系统已经到这个地步了，应该很快就能上线了吧。。。结果比较尴尬。

 需求分析的过程，往往是整个团队共同分析的过程，如果可能，把所有的开发人员召集在一起一起进行，最好不要一个人分析完了，就扔给开发人员去实现。这样会挫伤开发人员的积极性，会降低开人员的责任感和归属感。让项目组成员对项目的总体情况有所了解，众人拾柴火焰高，对项目的发展很有帮助，项目经理的压力也会减轻不少。

 二 开发中的持续集成

 持续集成（Continuous Integration）这个术语源自 XP（极限编程）的一个最佳实践，随着XP 社区在近几年的壮大，XP 的很多实践得到了广泛的推广，持续集成就是其中之一，但是持续集成并非 XP 的专利，持续集成完全可以应用在采取非XP 方法（例如 RUP）的项目里面。持续集成也不是一个新的概念，在这个术语出现之前，日创建（daily build）提供同样的含义，他们的主要区别就在于实施的频率上，随着 XP 社区的大师级人物 Martin Fowler的一篇《Continuous Integration》正式为其正名，持续集成这个术语就越来越多地出现在原来日创建出现的位置。

 持续集成的主要目的尽量在早期发现系统的bug，避免越到后期解决bug代价越大的问题。

 持续集成包括以下几大要点：

1 访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统）， 让所有人都能从这里获取最新的源代码（以及以前的版本）。

2 支持自动化创建脚本，使创建过程完全自动化，让任何人都可以只输入一条命令或者通过网页执行简单的操作就能完成系统的创建。

3 测试完全自动化，要求开发人员提供自测试的代码，让任何人都可以只输入一条命令就运行一套完整的系统测试。

4 提倡开发人员频繁的提交（check in）修改过的代码。

 但是在实际应用的过程中，我的感受是1、2、4都是很容易实现的，最大的问题是3，测试完全自动化，根据系统的复杂程度，有些系统比较容易实现，有些系统比较难。而在界面层面上，我所知道的，b/s结构的系统又比C/S结构的系统容易实现。

 对于系统结构比较简单的系统，比如不用跨平台，数据库是单一数据库，实现也比较单一，就算业务逻辑比较复杂，也是比较好实现自动测试的。而有些跨多平台，而实现技术又多种多样，就算业务逻辑简单，实现自动测试也比较困难。

 现在很多TDD开发的文章教程，没有考虑数据库方面的因素，比如那个最经典的转账的TDD开发的例子，在实际应用中，用处可以说不是很多，因为现在的系统，不用数据库的，应该是极少的，所以自动测试的难点又落到了数据库上面。

 比较可行的做法是，永远有一个稳定状态的测试数据库，里面有模拟的业务数据，代表一个指定的状态，每次进行单元测试和界面测试的之前，都需要把这个数据库初始化。然后运行单元测试和界面测试，如果测试的结果符合预期的目标，则表示测试通过，否则测试失败，提交失败报告。

 对界面的测试，web系统可以通过一些脚本工具，比如Rational Functional Tester编写测试脚本，对界面进行测试；而c/s结构的系统，我还没听说什么好用的，如果哪位知道，请不吝告知。

 而当时我们的系统，系统结构比较复杂，有数据采集，数据分析，数据入库，数据呈现，又涉及到多平台，unix，windows，多语言实现，有存储过程，perl，c，java，呈现层使用.net,还有消息平台mq，且数据量巨大，界面层面又有各种各样的控件，一些图表控件，gis控件等等，对于这样的一个系统，要想完全实现各个模块的自动测试，觉得有很大的难度，我们做了一些技术研究后，觉得能力有限，无法在这个系统上实现，就放弃了，主要靠开发人员自测和测试人员的偶尔测试。

 到了项目的后期，随着交货日期的逐渐逼近，越来越多的功能实现在系统里，但是bug也越来越多，甚至到了后来，集成的过程都会频繁出现问题，开发人员疲于奔命查找各种bug，测试人员倒是很轻松，坐等集成完成的测试版本，随便点一点，到处是bug。

 这种状况，导致每次需要发布新版本的时候，头天总是会忙碌到深夜。

         后来觉得，解决不了所有问题，至少要解决系统集成的问题吧，于是去研究CruiseControl。

 CruiseControl的使用比较简单，也很有效。

         按照如下步骤：

         1 安装CruiseControl服务器

         2 安装各种相关支撑软件，比如配置工具，代码构建工具，单元测试工具等。。。

         3 修改配置文件，指定配置服务器，源代码管理器版本，编译服务器，自动集成的时间，集成服务器，发布服务器等。

 然后就可以使用了，大致就是这样一个做法，详情请查看相关的文档。

 之后的项目过程中，每天下班前，开发人员会把完成的功能先自测通过，然后提交到源代码管理器，进行集成编译。第二天，测试人员去发布服务器上获得编译集成后的系统，进行测试。

 因为这个持续集成没有自动测试的功能，所以我们对CruiseControl的使用，只是相当于一个应用系统集成的工具。但是这个已经能保证随时随地都能拿到应用系统的最新版本，能随时向用户演示系统的最新进展，而不会在像之前那样每到版本发布就焦头烂额，bug横飞。