1 摘要

ANSTO(Australian Nuclear Science and Technology Organisation，澳大利亚核科学与技术协会)的中子波仪器项目最多控制八台和特定辅助设备相关联的仪器。该项目预计在2006年中期完成。

这个系统的控制软件的需求由一个国际委员会提出，软件架构将取决于来自于至少三个洲的专家的建议。项目的成功在很大程度上依赖于开发队伍的沟通能力，以及他们对于突发需求和资源变更做出适当反应的能力。

同传统的有严格的文档、确定的计划和过程的软件开发方法不同，敏捷软件开发方法更强调对于项目目标的持续逼近、开发者的个人能力，以及小组成员之间的沟通。

本文探讨了在科技组织中应用敏捷开发方法的一些主要原则，并说明了到目前为止这些原则在中子波仪器项目中的效果。

2 科技组织中的软件开发过程

“每隔一段时间，开发组反思一下如何能够提高效率，

然后相应的调整以后的开发过程。” [1]

目前的软件工程通过一些要素来界定软件的规模，这些要素至少包括时间、范围、包括预算在内的各种资源。在项目开展的过程中，这些要素经常会有一些突发的变化，某一个要素的变化往往会对其他因素造成很大的影响。对这些变化的不成功的处理往往会导致整个项目的失败。

科研项目往往会有更多的变更，允许项目根据以后研发的情况做出调整，甚至为了迎合项目成果的变化重新定义项目的范围和资源。在项目规划的时候，往往对项目的情况作出最坏的打算，允许项目花费比收益高很多的成本，或者仅仅取得远远比它可能获得的效果少得多的效果。

目前，科研软件开发的成功往往在很大程度上依赖开发者的个人能力，以及一个在这个领域积累了多年经验的开发小组。这种情况在已经发布的科研软件中占有越来越大的比例。

下一代的项目需要的是将开发者的技术经验和他们应用工具的能力尽量的结合起来。

3 敏捷软件开发宣言

过去十年中提出的很多软件开发方法都是建立在开发者的实力的基础上的。他们认识到了个人的贡献，密切的和频繁的交流，以及和软件本身多次的交互的重要作用。其实，软件本身才是项目的唯一目标。

这些方法论的提出者和实践者在2001年组织了专门的会议，提出了他们对于这些方法的宣言：

我们试图通过实践或者帮助别人来探讨开发软件的更好方法。

通过探讨我们达成一致：

个人能力和人际关系 胜过于 过程和工具

可正常工作的软件 胜过于可理解的文档

和客户合作 胜过于 合同谈判

对变更做出反应 胜过于按照计划开发

一般，别人关注右面的项目，而我们更关注左面的。

此外，开发组根据宣言制定了一些原则，并把它们形成文档。这些原则和一般的开发方法的主要区别如下：

- 敏捷方法更强调在预测的基础上的变化。设计和构建的计划中包括了对于需求、设计概念等的变更的管理，并通过有效的沟通把风险降低。

- 敏捷方法更强调人而不是过程。开发者被认为是具有专业技能和主动性的技术专家。小组中最适合做出计划的人来充当管理的角色。客户被认为是评判系统应该如何更有效运行的裁判。

被称为敏捷的方法很多，例如XP，功能驱动程序设计，Scrum, Crystal,以及渐进软件开发。这些方法在各自一定的领域内发挥重要作用，因此很难成为对所有项目都适用的方法。

Fowler认为，渐进的过程适合于以下类型的项目：

- 需求不明确，或者不稳定。

- 有责任心和主动性的开发者。

- 客户了解项目的情况，也愿意参与项目。

此外，科研组织内很多项目是有小团队完成，组织内有比较好的合作氛围，开发内容会警察尕省变化，这些都很适合使用敏捷方法。

4 案例学习：中子波仪器项目

"朴素—把工作效率尽量提高的艺术—是最基本的。" [1]

NBIP（The Neutron Beam Instruments Project，中子波仪器项目）的主要任务是为一个正在准备实施的仪器提供一个先进、稳定、可扩展的控制系统，并能够积累操作员的经验。这个项目的特殊之处在于，开发组是在没有硬件设备，甚至有时连元器件都没于的条件下开始工作的。

目前，准备各个仪器所需要的组件正在快速的进行，在当前的条件下开发一个一般性系统的时机已经成熟。最关键的问题是，随着仪器设备的到位和安装，必须同步开发相关的验证软件。控制系统必须能够同八台完全不同的仪器和辅助设备集成使用。

为了实现这些目标，必须开发以下适用于所有的仪器的系统：

- 控制系统：一个公共的核心控制系统，可以是应所有的仪器。

- 用户界面：在公共框架的基础上可以用户订制的界面。

- 配置管理系统：一个记录所有仪器配置情况的数据库。

- 开发方法、实践和工具：确保这些系统的开发是可控制的，能够在一定的时间内实现。

最终我们选择了一套已有的软件模块，一些开源工具，传统的软件开发方法和敏捷开发技术。

5 NBI项目管理和软件开发方法

“只有自律性强的组织才可能产生出最好的软件架构、需求、设计。”[1]

NBI项目作了严格的计划，详细的预算、风险控制，进程跟踪以及文档管理，这些使得该项目成为一个非常成功的案例。在实现这些需求的同时，项目组希望该项目的开发过程是最好的。

大多数软件开发都包括一些共同的部分，例如：

- 目标

- 具有不同背景、完成不同任务的角色

- 具有足够的经验和技术，可以完成这些任务的团队

- 为开发系统建立的一组正式或非正式的规范

- 一套技术，例如开发语言、工具、组件以及用于开发目标系统的其他产品

- 一个新的或者是基于以前的系统的框架结构，并在此基础上作出目标系统的设计和计划

在这个案例中，目标是明确的，叫色和成员都已经选定。他们会选择一些可以实现我们的项目目标的方法和工具，以及开发项目所必须的一些原则。由于这个项目组一贯主张敏捷方法，因此选择了极限编程(XP)和功能驱动计划的方式。

5.1 极限方法

极限编程(XP)是为了实现敏捷开发而选择的一套方法和原则。XP的发明者，Kent Beck和Ward Cunningham，都是敏捷宣言的发起人。

正如敏捷方法关注的是人，XP方法以开发者、开发团队以及开发组和客户之间的共同方式为核心。

5.2 开发过程

NBIP项目组的每个人都要收集需求、修正软件结构和设计方案、做初步的测试和集成。由于开发环境引入和很多的工具，开发组成员还需要将安装、配置和数据恢复程序文档化。

传统的软件开发过程在这里被认为都是同等的程序，它们平行的进行，并频繁的同步，以便能够有迹可循。

为了能够对软件的设计和架构有一致的理解，每当一个主要的组件成熟的时候，这个部分的完成人将为项目组的其他成员组织一个讨论会或者培训，以便项目组的其他成员了解该模块的信息。这样的合作也提供了一个在模块的开发者和用户之间的协调机会。

5.3 小组实践

XP方法的最大特点是不断的鼓励开发组形成需求和理解。为了能及时了解需求的变化情况，敏捷方法要求经常和客户沟通，XP方法可以保证开发组随时都可以取得客户的支持。

在紧密的合作过程过程中，需求的反馈和变化都可以很快的被吸收。为了及时响应，开发组可以通过短时间的交互关注变化的情况。

NBIP通过每天的会议来同步他们的行为。为了保证例会在短的时间内结束，并能取得效果，项目组采取了“立会”的形式。虽有的参与者站着参加会议，在一个简短的会议后马上回到工作中。项目成员汇总前一天工作的成功经验和遇到的问题，并考虑在下一步工作中如何调整。项目组的每一个成员可以指导小组现在在做什么以及以后需要做什么，小组成员也可以自由的请求帮助，以便解决遇到的问题。既是一个开发者没有参加某一次会议，他也可以很快知道项目的信息。

这些工作是由开发者完成的，当产生了一些新的问题需要和客户沟通的时候，客户也可以很自由的参加这项工作。

为了能够更好的沟通，XP提供了很多共享资源。例如，项目组的成员都可以使用已有的仪器设备，并可以共享仪器操作界面的图片。

5.4 功能驱动计划

Coad在书中用了独立的一章概要的描述了FDD方法。这提供了一种一个相对大的、在技术和经验上有相当的差异的租来开发复杂的软件应用的方法。

FDD方法包括五个过程：

NBIP没有采用FDD方法，但是借鉴了FDD功能的概念，以及通过一系列功能制定计划和构建系统的优点。

功能是在需求获取过程受手工形成的。

功能是对于系统的某一个部分为了获得特定的结果而执行的一个操作的简单描述。

User stories是软件系统的用户执行的操作的自然语言描述。

开发组记录在同客户进行的例会上收集的User stories。通过这些User stories可以获得一系列的功能，这样可以一直保持克辉对于各种功能的理解。客户代表还可以帮助确定这些功能的优先级。

通过这种方法，开发足可以记录独立于实现细节和软件架构的用户需求。

为了和里程碑的概念区分，实现一个功能所需要的范围被称为粒度。FDD每个功能用不超过两周的时间实现，这样，对于实现功能列表的工作所需要的任务分配、工作量平衡、进度度量等都会比较容易实现。进度可以以单元为单位，这样既便于用户理解下一个版本所作的修改，也可以很方便的测试。

在FDD的方法中，基于功能的开发和构建会反复地进行，直到所有的功能都已经实现。功能计划仅仅提交目前的修改，说明哪些功能列表被实现，这些修改针对的是那个用户群。

按照他们的优先级和依赖关系，功能集排成一个实现序列。在每一个交互过程结束时，计划的变化都会反过来影响到那些已经实现的功能。这样的反复过程有助于更好的管理需求的变更。

6 外部协作

“在一个开发组中传输信息最有效的方法是面对面的交谈。”[1]

6.1 控制系统

NBIP选择了SICS（SINQ Instrument Control System，SINQ指令控制系统）作为奇迹与服务器的控制软件的基础。SICS是一个在PSI应用的操作简便、稳定、经过严格测试的平台。在Hauser的著作帮助我们确定了这个系统的标准和决定。

2004年上半年，NBIP项目组邀请了SICS的主要作者之一，Mark Koennecke参加了ANSTO关于开发的一系列研讨会和培训。除了介绍有价值的开发理念和SICS的使用，还介绍了一些有关SICS的进展。

这项协作的最直接的影响是，可以通过修改SICS的结构改站点的结构，通过一组驱动程序和脚背把对于站点的维护同核心系统分开。同时，PSI所使用的模块提供了很多可以被ANSTO使用的模块和例子。

只有SICS的服务器和设备驱动库可以同ANSTO的系统完全结合起来。每台仪器在虚拟的局域网上运行一个SICS服务程序，他可以通过TCP/IP和设备控制器以及数据服务器在局域网上交换数据。

这样的连接图可以使SICS服务器不必同设备分享内部总线，而是通过网卡连接。这样，服务器可以运行在仪器附近一个可靠的、独立的PC上，可以通过任意数量的客户机访问服务器，不管是在仪器附近还是在远程，只要有一定的授权，就可以访问。服务器是基于面向对象结构的，内嵌的Tcl解释器可以实现以下功能：

- 解析客户端发来的命令行指令

- 在服务器启动的时候执行初始化角本，定义仪器的配置参数

- 翻译和执行服务器发来的提供扩展功能的角本

- 翻译和执行用Tcl编写的客户角本

设备驱动程序是为各种特殊设备编写的，它们在启动时候通过一个角本为特定的仪器定义数据、组合方式和配置数据等。

通过提高系统的可靠性，开发过程中减少了测试工作，这样使对仪器的访问得到了限制，维持在了一个典型的水平。为了保证维护计划的弹性，需要增加新的设备以扩展系统的容量。

SICS的模块通过PSI和注册表同步。

6.2 客户端

基于Hauser提出的原因，NBIP很快选择了C/S的结构。

ESRF的软件工程师，Andy Gotz为我们的SICS控制的仪器提供了选择平台无关的框架的图形化用户界面客户端的指导。为了达到这些要求，通过一定的调研，我们很快决定选择基于Java的平台。

RCP（Eclipse Rich Client Platform，Eclipse胖客户端平台）天然集成了Eclipse开发工具，它为我们提供一套成熟的、可以客户化的、标准的、独立于操作系统的开发工具。我们把客户端软件称做Gumtree。Gumtree本身足够灵活，足以满足ANSTO的规范(GumNIX)，完全有可能很成功地在以后的控制系统，例如EPICS或TANGO上应用。

6.3 其他合作的可能

敏捷开发提高了稳定开发的可能。发起人、开发组、用户都可以取得比较稳步的进步。[1]

只要有可能，开发组总是想办法提高系统的效率。

SICS可能为以后的站点提供同步的扩展。SICS服务器程序的核心部分是PSI（Paul Scherrer Institut，Paul Scherrer研究所）的Mark Koennecke开发的。

核心代码已经扩展到可以支持站点描述的设备和方法。伴随着系统的扩展，核心系统恩深已经被一个新的小组在一定程度上得到了修改。

开源思想在仪表控制客户端的开发中起到了重要的作用，开发组从开源工具获益，并因此提高了效率。我们的客户端软件，Gumtree在SourceForge注册为一个开源项目，对其他同我们的开发组同等地位的合作者开放，来自ESRF和PSI的开发者已经表示出了对我们的平台的兴趣。

由于采用了开放的态度，事实上，很多其他用户和程序员扩展的程序和工具被我们所采用并加入到我们的系统，例如Eclipse，他的插件，NeXus以及TANGO。

7 敏捷开发工具集

随着一个新的开发组的建立，必须选择一个开发方法论和核心工具集。这一定要是简单易学的工具，并有比较高的效率可以在一定范围的设备上建立稳定的方案，还要有充分的扩展性，以便能够满足仪器科学发展的需要。

开源集成开发环境

Eclipse是一个集成开发环境和应用程序平台。除了为项目提供Java和C/C++的编辑工具，Eclipse的插件还给了我们同我们的源代码管理工具（cvs或者vss）集成的图形化的和基于菜单的工具。

- 源代码管理工具（cvs或者vss）

- 调试工具(gdb)

- 源代码文档化工具(javadoc和doxygen)

- bug/发行数据库(bugzilla, MySQL)

- 外部编辑器(针对Tcl, perl, Python等)

插件也提供了本地功能的支持。

- 针对java和C/C++的优化工具

- java单元工具

- 用SQL输出建模的数据库环境

- UML支持(自行开发)

- 可执行程序的分析工具(Hyades)

此外，Eclipse还有很多其他免费的或者商务的插件，这些插件为软件提供了扩展的功能或界面。

整个开发组都使用相同的集成开发环境，不论是C/C++或者Java的开发，调试，测试，还是形成相关的文档。这样提高小组成员交换工作的可能性。

其他基于社区的工具

- Apache / Bugzilla / Perl / MySQL用于跟踪bug、发布的版本以及改善功能的请求

- MySQL同时作为配置管理系统的后台数据库

- NeXus和HDF是SICS所需要的。这些产品也提供了对于开发工作很重要的API和数据浏览器

- Tango包omniORB目标分解器

- DejaGNU测试环境

配置管理和参数保留

开发过程中的一个主要目标是从中心知识库自动生成配置指令的文件和对于这些配置文档的可视化控制。

在仪器操作过程中，保留模块的调用参数可以使模块从不正常的状态恢复。

把这些参数保存在一个分布式的系统有利于远程指令状态监测和调试。

为了保证系统所有的功能都没有重复的完成，我们需要一个集中、可靠、快速、基于网络的模块，通过它可以知道任何一个配置的关系，以及他们当前的状态。

目前的数据库被定义为在SICS初始化的时候完全覆盖。这样，SICS可以在适当的时候根据物理配置角本重建。我们倾向于使用JDBC完成对于一个相应到角本的转换。

数据库本身使用Eclipse的插件。培植数据库的角本可以翻译成各种形式的SQL。数据库的设计是文档化的，并且有严格的版本控制。

8 HIFAR MRPD：调整计划和提交代码

“可执行的软件是衡量进度的唯一要素。” [1]

在仪器还没于安装的情况下，开发组想到了早期的一个项目，于是想把软件系统原型运行在这个已经存在的仪器（HIFAR1）HIFAR上。虽然增加了一定的工作量，但是也产生了一些值得期待的成果：

- 取得了在一个实际的仪表项目调整和扩展SICS性能的信心

- 通过小组的开发实践，取得了开发过程、任务管理等方法论的信心

- 通过和现实的系统的交互，拓展了现行系统和NBIP仪表科学的视野

- 提供了一个测试小的持续改进的平台

- 测试了可配置的服务器和客户端目前已经实现的细节，客户端包括控制选项，仪表状态显示，试验状态显示，数据显示

- 提供了调试和测试过程的验证

- 提供给所有的用户一个客户端已得到关于可用性的反馈

- 取得了存取实际的数据的经验并对于如何管理它展开了讨论

- 测试了我们的前端数据压缩和分析工具

我们选择了仪器HIFAR MRPD，因为它在控制的设备的数量以及设备的系列方面和目标系统比较接近。现在的用户界面所具有的一些功能是可以被新系统的客户端Gumtree所使用的。这些仪器的使用进度刚好可以提供给项目组使用，也可以披露给开源社区。

通过对问题域的分析确定了项目的目标和限制。然后开发分两个方向进行，分别开发客户端和服务器端，通过定期的会议同步进度。

小组和一个这个领域的专家组同时工作，这个专家组包括这方面的科学家和HIFAR的开发者和维护者。专家组提供了有关很多专业知识，包括仪表的使用，目前的和计划中的功能的细节，如果有新的操作代码，他们也会马上反馈。作为回报，他们对于仪表的结构和使用取得了更深的认识，这些对于他们以后的工作和决定有所帮助。

每个设备的驱动程序完成的时候，都会组织针对通讯和功能的测试。在可控的状态下对每个驱动进行在线的测试。

作为先行功能列表的一个部分，MRPD的设备和功能也集成在了开发计划中。

在很短的时间内，一个完整系列的设备驱动已经编码完成。MRPD目前正在等待最后的集成的是，然后仪器科学家和用户可以提供关于应用程序使用的反馈。

9 方法论的展望

作为一个新成立的小组，我们没有在开始的时候很急切的建立所有的开发环境以及提供所有的支持工具。NBIP的开发环境和项目开发的过程同步的进行。这不是最理想的，但是在我们所拥有的资源的情况下却是最现实的。尽管我们拥有一些传统的开发过程的工具，但是我们还是选择了更能够支持我们的敏捷实践的方法和工具。

调整目标功能集可以提供一种在项目组成员之间平衡工作量的机制。

作出功能的计划以后，开发者集中精力关注这些内容，而小组负责人维护一张进度的列表。如果发现一些功能是有问题的，或者开发者不能继续原来的工作，资源将通过一个定义完整的机制重新分配。

我们一直坚持每隔三个月在开源社区公布自己的项目里程碑。

尽管我们在这个间隔调整计划，但是我们希望在项目组内部，我们的频率要更高些。这样做的一个先决条件是高度自动化的软件包装和部署。一旦实现了自动部署，一个新开发的功能可以在几分钟之间内反映在软件包里面。

在极限编程里面，我们希望细化开发任务的粒度。XP需要一个功能可以在一天之内完成，其中包括单元测试。

如果不能做到这点，就说明任务的范围太大，需要再分解。简单的说，可能存在潜在的没有其他的支持就无法实现的可能。我们的测试还是一种不是很正式的模式——开发者本人测试他自己的代码。

程序编译是自动进行的，但愿测试是不完整的，也是非正式的。继承测试仍旧是在开发者在完成一系列的功能以后进行的，尽管我们尝试把测试的频率提高。

程序员自己测试的方法被实践证明是非常有效的。似乎，心理上的障碍比事件的障碍更加难于克服。根据我们的有限经验，程序员在潜意识中都希望在开发结束后马上进行测试。去除了bug的程序可以保证更加稳定，这样的做法可以提高整个开发组的效率。这种方法在很大程度上要依赖其他方法的使用。

10 结论

科技软件的成功在很大程度上会受到有经验的参与者和专注的小组的影响。为了更快、更好地完成工作，必须花更多的经历在探索当代软件开发原则和实践上。

敏捷软件开发原则关注的是人。敏捷开发包括很多方法，例如XP和FDD，同重量级的文档驱动的开发过程相比较，敏捷方法在灵活性等方面更有吸引力。这个方法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些实践。然而，在科技和软件开发的精神中，这并不排除在实践过程中会有一些变化。

通过尝试一系列给予敏捷的方法，ANSTO的中子仪器项目产生出了高质量的应用。项目组每天的协调会和与客户的频繁沟通对于鼓舞这个新建立的项目组的积极性起到了重要的作用。协作、公共的开发工具以及面向最终用户的应用、信息的流动和反馈都对结果产生了积极的作用。

很多方法很难独立的使用。开始的时候是凭着知觉选择了测试驱动的开发，结对开发，计划调整周期以及持续改进，不过，后来的结果证实，这些方法都取得了成功。

使用这些方法并不能保证一定成功。现在，我们已经发现开发者的经验和技术仍旧是影响开发结果的最主要因素。然后，我们相信，对于合适的人，基于敏捷原则的开发方法可以产程更好的结果，同时形成一个愉快地、有激情的工作环境。

11 参考资料

[Astels] Astels, D., G.Miller and M.Novak "A Practical Guide to eXtreme Programming", Upper Saddle River NJ: Prentice-Hall PTR, 2002. ISBN 0-13-067482-6

[Coad] Coad, P., et al. "Java Modelling in Color with UML", Upper Saddle River NJ: Prentice-Hall PTR, 1999.

[Fowler] Fowler, M. "UML Distilled" 3rd Ed., Addison-Wesley Publishing Co., 2003. ISBN 0-321-19368-7

[Hauser] Hauser, N., et al, "Choosing an Instrument Control System", NOBUGS Conference 2004.

[Palmer] Palmer, S.R., and J.M.Felsing "A Practical Guide to Feature-Driven Development", Upper Saddle River NJ: Prentice-Hall PTR, 2002. ISBN 0-13-067615-2

12 URL 参考资料

[0] "Manifesto for Agile Software Development" <http://www.agilemanifesto.org/>

[1] "Principles behind the Agile Manifesto" <http://www/agilemanifesto.org/principles>

[2] "Eclipse" <http://www.eclipse.org>

[3] "eXtreme Programming" <http://www.extremeprogramming.org/>

[4] "Feature Driven Development" <http://www.featuredrivendevelopment.com/>

[5] "The New Methodology", Martin Fowler <http://martinfowler.com/articles/newMethodology.html>

[6] "The Agile Alliance" <http://www.agilealliance.org/>

13 附录

[A] “敏捷宣言所主张的原则”

附录A:

敏捷宣言所主张的原则

我们遵循以下原则：

我们最高的优先级是通过及时、可靠的提供有价值的软件来满足客户的需求。

欢迎需求的变更，即使会延迟发布。

敏捷方法通过变更达成客户的竞争优势。

频繁发布软件，从几个星期到几个月，优先选择短的时间周期。

在整个项目过程中，业务人员和开发人员必须每天协同工作。

用有激情的人建立项目。

给他们必须的环境和支持，相信他们可以把工作做好。

在一个开发组中传输信息最有效的方法是面对面的交谈。

可执行的软件是衡量进度的唯一要素。

敏捷方法可以提高开发效率。

敏捷开发提高了稳定开发的可能。发起人、开发组、用户都可以取得比较稳步的进步。

对于优秀的技术和好的设计的持续改进可以增强敏捷方法的效率。

朴素—把工作效率尽量提高的艺术—是最基本的。

只有自律性强的组织才可能产生出最好的软件架构、需求、设计。

每隔一段时间，开发组反思一下如何能够提高效率，然后相应的调整以后的开发过程。

【作者介绍】 iampole在悲观和乐观之间爬行的软件虫。 msn: yinglong_w@hotmail.com作者Email地址：iampole@21cn.com