敏捷开发方法在铁路信息系统项目中的应用

刘瑞壮 中国铁路上海局集团有限公司上海申铁信息工程有限公司

2013年随着成立国家铁路局、铁路总公司，近年来国家推动铁路加快体制改革步伐。对于这一历史时期铁路信息系统项目而言，用户的需求是多样的、个性化的和不断变化的。静态的软件项目管理方式，显然已经无法适应铁路管理格局的动态发展。

1 铁路信息系统开发现状及存在问题

上海局在全路信息化建设中始终处于前列，近年来在高铁客服设备维保、车站设备智能化管理系统建设等方面取得重大突破，引起了铁路总公司高度关注，成为各局争相借鉴的典范，可以作为研究铁路信息系统开发现状调研对象，能够反映全路信息系统开发中存在的普遍问题。为了深入了解目前铁路信息系统项目开发现状，本文中选取2013年至2017年铁路总公司、上海局集团公司组织建设的，包括“铁水联运信息共享平台”、“LKJ施工数据安全管理系统”、“上海铁路局综合实时监测管理系统”等，20项典型铁路信息系统项目，从软件开发管理体系、流程和现状方面做了深入调研，对技术人员进行访谈，记录管理进程、项目状态、存在问题。

经对20个项目进行统计，只有近60%的项目是基本按计划完成的。经梳理分析，造成项目严重滞后的因素包括：用户需求不稳定，工作量估算不准，团队成员管理不善，与用户沟通不足。需求反复不定或者在项目中后期需求发生较大变化，是项目延期的主要因素，同时，不定的需求始终影响工作量估算，使已经拖延的工期难以推算完成时间，造成看似无尽的拖延。另外一方面，人员管理不善、缺乏沟通，在项目开发的关键阶段，也阻挠了项目顺利推进。

2 Scrum敏捷开发方法研究

Scrum是一个非常有效的敏捷框架，自诞生以来推广很快，用橄榄球运动来比喻开发过程。在橄榄球运动中，每次冲刺（Sprint，是一种进攻方式）前，都需要先安排一个进攻计划过程，一旦冲刺开始后，也就是开始实施进攻计划后，则团队需要在原冲刺计划的基础上，随机应变，比如计划是A要传球给B最后由B得分，至于具体采用什么途径，跑什么线路，就是要根据变化具体应对的了。最终目标还是要B得分，以达到预期的进攻目的（陈勇，2012）。

Scrum定义了4种主要的角色：

（1）产品负责人（Product Owner）：负责产品规划，负责确定需求优先级。在开发团队和用户之间沟通对接。

（2）利益相关者（Stakeholder）：是与产品有直接利益关系的人，可以理解为偏向用户方面的干系人，负责制定产品需求，并且审查项目成果等。一般由用户或最终用户代表组成。

（3）Scrum 专家（Scrum Master）：指导团队贯彻Scrum方法。在开发团队和产品负责人之间沟通对接。

（4）团队成员（Team Member）：实施项目开发工作的开发人员。

Scrum的核心做法：

Scrum收集最佳实践，并且贯彻敏捷思想，为开发团队提供了，一个实用的敏捷开发框架。比如采用测试驱动开发（Test Driven Development）、结对编程（Pair Programming）等都可以被整合到其中。

迭代计划会 (Sprint Planning Meeting)。按照一个迭代2-4周的工作周期填工作，直到塞满一个迭代，就可以进行开发了。

团队估算。产品负责人主持，团队要共同进行估算，集体智慧完成任务，这样也使估算结果更为客观。

开放的办公环境。便于沟通和互动，大多数团队都会在办公环境中设置白板，在语言难以表达的时候可以随时进行演示。

每日例会。“每日立会”（Daily Stand Up Meeting），每天要维护“燃尽图”（Burn Down Chart），像烧蜡烛一样，团队“烧”完一个任务就标记完成，所有的任务都完成，项目的蜡烛也就烧完了。燃尽图的功能是盯控项目进度，预测进度是否有偏差。

评审会 (Review Meeting)、反思会(Retrospective Meeting)。冲刺冲完了，冲的结果怎么样，要产品负责人说了算。迭代的最后一天，产品负责人要对冲刺的成果进行评审，反馈是不是通过。

3 敏捷开发在铁路信息系统开发中应用策略

3.1 迭代规划管理策略

在迭代规划中，确定开发优先级是首要任务。在确定的过程中，采取什么方式能够保证快速、合理、便于操作，是一个值得研究的问题。查阅文献过程中发现，大部分文献的工作核心，在于确定一系列需求的重要程度，以此作为优先级排序的依据。文献（胡文生等，2013）阐述了，核心功能优先开发，可以在之后的迭代过程中发现缺陷并修正，借此明显提高系统可靠性。如表1（数据源于王晓华.敏捷开发环境下软件可靠性分析及相关问题研究）：

表1 各个用例权重的确定

F1代表最先进行开发的功能组，也是整个项目中最核心的功能组，此功能组共进行了6次迭代。Ni表示测试用例数，Si为测试成功数，Ri表示功能组的可靠性点估计。可以计算出 F1，F2，……，F6功能组经过6次迭代后的可靠性变化情况。数据如表2所列（数据源于王晓华.敏捷开发环境下软件可靠性分析及相关问题研究）：

表2 各功能组在每次迭代周期的可靠性

从列表数据可以看出，在经历了6个迭代周期的F1功能组，可靠性有很显著的提升，以此，使整个系统更可靠。因此如何判断功能组为核心功能组尤为重要。

将各类功能组分为高风险且高价值的功能组、低风险且高价值的功能组、低风险且低价值的功能组，高风险且低价值的功能组。确定迭代顺序的原则就是，把有限的资源，投入到高风险且高价值的功能组上，以此优先实现核心功能，同时减弱风险。

要优先开发高风险且高价值的功能组，目的是在历次迭代中不断发现问题，并且进行纠正完善，以提高整个系统的可靠性。然后依次开发低风险高价值、低风险且低价值的功能组。尽量将高风险且低价值的功能组排除在项目外，因为项目资源是有限的，冒着项目失败的风险去开发可有可无的功能，是没有必要的。

3.2 任务分配和估算策略

团队共同对任务进行讨论。团队成员集体行动，讨论从产品负责人那里听来的故事（用户需求），把将每个用户故事进行转换，变成具体的开发任务。估算后由程序员对任务进行认领，其中可以由两个人对此任务更为熟悉，并且更有兴趣的进行结对，完成特定工作。这样一来，程序员会对其所认领的任务更为自信、具备更强的责任感，更尽力的在限期内完成任务。估算采用以下方法：

（1）德尔菲法。德尔菲法的特点，就是可以得到很高的准确率。

（2）类比估算。类比估算的特点，是容易达成共识。是依据团队经验，设定简单任务，并对其他任务进行类比并估算整个工作量的方法。

（3）故事点。团队选取一个最简单的任务，作为一个单位的故事点，记作1故事点或1点。将其他所有任务与1点的任务类比，根据结果分别估算为1点，2点，3点或者5点，对超过5点的故事就应该拆分成更小的任务。

（4）三角测量。在团队估算中，结合功能点和类比分析的思想，采用"故事点"方法进行敏捷估算，为提供准确度，在每次估算后用三角测量的方法评估结果，4个点的任务应介于3个点和2个点之间。故事点应该是由整个团队进行估算，尽量使团队中的所有成员都要参与故事的故事点估算，每个人都把自己的估算结果说出来，最后大家再定一个所有人都认可的故事点。

项目开发过程中，将团队效率看作是速度，总的工作量看作是路程，所用时间可以很简单的用t=s/v公式求得。故事点就是一个团队工作效率（速度）的基本单位。将最简单的一个故事看作1点，其他故事与之比较，比它规模更大的或者更复杂就赋予更高的速度。受人主观认知水平不同的影响，每个人的对理想日的估算方法和结果往往会有很大差异。为了规避这种个人能力差异，我们采用“故事点”估算方法。

3.3 开发和测试策略

编码前考虑编写测试。验收测试的编写主要包括：测试数据、操作步骤、预期结果。当编码完成时，测试也就基本完成，假如已完成并且通过了所有验收测试，就可以进行用户评审。

将测试分为3个阶段进行，开发人员在迭代中的自行查验，用户故事测试，最后是迭代末期的验收测试。

（1）自行查验：由开发人员自行完成，目的是要提交一个或多个，可以进行自动化测试的用户故事。

（2）用户故事测试：由开发人员和"现场客户"完成，目的是对一个或多个用户故事的功能进行测试，保证功能没有问题。

（3）迭代验收测试：由开发人员和“现场客户”完成，对当次迭代的用户故事，主要基于场景的测试。目的是要保证当次迭代的工作任务确定被客户“签收”。

在估算后，由两个对此任务更为熟悉，并且更有兴趣的程序员进行结对编程。结对编程的工作模式可能有多种，本文作者根据实践经验，提供一种结对方式：

由两名程序员用同一台电脑，轮流进行编程，一个人在编程的同时，另一个人一边看一边指出问题，并且着手编写测试，简要设计测试数据、操作步骤和预期结果。

如果其中一名程序员编程效率明显比较高，也可以不做轮换。但考虑到工作强度不宜由一人承担，并且旁观者虽清，但长时间旁观容易分心，对本职工作失去兴趣，还是要求结对的两人轮流进行编码。

3.4 评审策略

Scrum方法采用时间盒策略。事先定好了评审会召开的时间，到了时间是一定要进行评审的。不可以等开发工作完成，测试完成以后才评审，因此迭代一般不会被拖延。

要注意的是：

（1）事先确定用户故事标准。

（2）评审时以用户故事为整体，进行评价是否达到交付标准。

（3）如果部分功能没有通过验收测试或者没有通过评审，也不需要拖延时间纠结于某个问题，可以与用户协商先确认将完成的工作通过评审，没完成的或者需要改进的，可以产品待开发项，作为以后迭代的任务去完成。

（4）在评审会前，单个用户故事完成时，也可以进行评审，以便降低交付时不能通过的风险。

这样很大程度上，可以避免陷入项目超期甚至严重超期的窘境，尽管有可能会增加迭代，但在规定期限内，一定会完成一个可发布上线的产品，遗留问题可以在试用期内进行解决完善。

4 总结与展望

本文调研铁路信息系统项目现状，发现存在问题，通过重点研究Scrum方法在信息系统开发过程中的应用，结合铁路生产系统项目目前遇到的关键问题，研究并提出更贴合实际、更具操作性的迭代规划、估算、开发、评审等策略。今后进一步的工作，需要不断提高估算的精确度。定量的估算方法可能相对结果会比较精确，但过程复杂，受条件变化影响大，准确性差。相反，定性估算精度不如前者好，但快捷、易操作。为了在准确估算的前提下，不断提高估算精度，有必要基于历史数据以及项目经验的积累，对定性估算和定量估算的数学方法进一步分析研究。