邱明明
（中国人民银行南京分行营业管理部，江苏 南京 210000）
【摘要】敏捷开发可以应对客户快速变化的需求，它强调以人为核心、采用迭代的方式、循序渐进地开发软件。笔者所在的政府机关小型开发团队近年来对敏捷开发方法有选择地进行了应用，在测试驱动开发、小版本发布、任务投票等方面取得了一些经验。
教育期刊网 http://www.jyqkw.com
关键词 敏捷开发；政府机关；应用
作者简介：邱明明（1982—），男，汉族，江苏阜宁人，硕士，中国人民银行南京分行营业管理部副主任科员。
1敏捷开发的出现和特点
1.1敏捷开发的出现
传统的软件开发方法定义的过程往往大而笨重，降低了软件开发团队的开发效率和响应变化能力，形成了过程膨胀即“过程泥潭”。2001年初，由于看到许多公司的软件开发团队陷入了过程泥潭，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则：个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划，这就是“敏捷宣言”。
敏捷开发的方法很多，有极限编程、Scrum、特征驱动开发、自适应软件开发等。敏捷开发可以应对客户快速变化的需求，它强调以人为核心、采用迭代的方式、循序渐进地开发软件。在敏捷开发中，软件项目被切分成多个子项目，各个子项目的成果都经过测试并可以随时投入运行。敏捷开发要求项目团队全体成员之间形成更加有效的合作关系，使其灵活性更高，以适应不断变化的需求。
1.2敏捷开发的特点
与传统的软件开发方法相比，敏捷开发主要有两个特点。
1.2.1敏捷开发是面向人的而不是面向过程的
敏捷开发认为，人是软件开发中最重要的因素，而且人工作的环境很复杂。它强调软件开发应当是一项令人愉悦的活动，因此更加注重调动人的积极性、主动性和创造性，并培养人在工作中的自豪感。敏捷开发的理念就是信任项目团队能够很好地完成任务，所有的管理都是围绕这个理念展开的。敏捷开发的目的是建立起一个项目团队（包括客户、需求分析人员、设计人员、开发人员、测试人员等多种角色）全员参与到软件开发中。只有这样，软件开发流程才能在项目团队中得到最广泛的接受。敏捷开发还要求开发人员在技术上进行自主决策，因为开发人员是最了解什么样的技术是需要或不需要的。
1.2.2敏捷开发是“主动适应的”而不是“预先设定的”
传统的软件开发方法试图对一个软件项目在很长的时间跨度内做出详细的计划，并形成详细的文档，然后依照计划进行开发。这类方法在计划制定完成后往往拒绝变化，后期的需求变化将会花费极大的代价。敏捷开发则乐于迎接变化，其实，它的目的就是成为更适应变化的软件开发流程。
据统计，很多软件产品提供的功能中，客户常用的功能只占20%左右，其他大部分功能是客户很少使用甚至基本不用的。在这种情况下，采用传统的软件开发方法所设计出的功能，其实很多是不必要的，也将浪费很多资源。敏捷开发则要求客户始终参与整个开发过程，这使得项目团队可以不断地获得客户反馈，不断地适应需求的变更，从而使最终的产品充分符合客户的要求，也极大地减少了资源的浪费。
2敏捷开发在政府机关的应用探讨
由于条件所限，笔者所在的政府机关从事软件开发的技术人员较少且大多不是专职，往往身兼系统运维、科技管理等其他工作，因此政府机关的软件开发往往具有团队规模微型化、开发时间碎片化、项目文档简单化等特点,瀑布模型、RUP等传统的软件开发方法已不能适应政府单位软件开发的需要。笔者所在的小型开发团队近年来对敏捷开发方法有选择地进行了应用，在测试驱动开发、小版本发布、任务投票等方面取得了一些经验。
2.1测试驱动开发
作为敏捷开发最重要的组成部分，测试驱动开发要求实现的每一个业务功能都是从测试开始。开发人员首先对需求进行分析，将需求分解为一个个用户故事，然后根据用户故事，从需求的角度来编写测试代码（主要是单元测试、功能测试），最后依据测试代码来编写业务功能代码。
如果没有测试代码，就不能编写业务功能代码。先写测试代码，能够让开发人员明确目标，就是业务功能代码通过测试。当然通过测试并不是结束，测试覆盖率分析工具还可以直观地显示测试未覆盖到的业务功能代码。在测试没有100%覆盖业务功能代码之前，尽快完善测试代码显得十分必要。
测试驱动开发还方便了代码的重构。重构是在不改变系统外部行为的前提下，对程序代码的内部结构进行整理优化，使得代码尽量简单、易读、可扩展。值得注意的是，敏捷开发中的重构对代码的每一次改变要尽可能小，并用单元测试来验证重构是否引起冲突，并且要求不仅对业务功能代码进行重构，如果测试代码中有重复，也要对它进行重构。
刚开始推行测试驱动开发时，我们的开发人员觉得花费了不少时间在编写测试代码上，项目开发进度不是很快，还不如多花些时间在编写业务功能代码上。不过随着项目开发的不断深入，开发人员发现如果一个业务功能的测试代码写的比较完善，业务功能代码往往不容易出现缺陷，开发人员花在缺陷修复上面的时间比较少，在对代码进行重构时也很容易验证。
2.2小版本发布
在敏捷开发中，不会出现拿到客户需求以后就闭门造车，直到项目开发完成了绝大部分甚至最后才将产品交付给客户的情况，而是多次发布小版本产品。这样，客户每隔一段时间就会拿到发布的小版本产品进行试用，项目团队就可以从客户那里得到更多的反馈来改进产品。
在推行小版本发布后，很多时候我们发现客户提出的需求往往不那么全面，一些新的需求往往是在试用发布的小版本产品后才反馈给项目团队。因此，小版本发布在一定程度上有利于发现新的需求。而对于开发人员，正因为多次发布小版本产品，每一个版本新增的功能简单清晰，不需要很复杂的设计，也在很大程度上简化了设计。
2.3任务投票
在敏捷开发中，每次迭代都要求项目团队在一次迭代期间（一般两到四周）内，完成本次迭代计划里的任务。此时，选择哪些任务加入本次迭代计划需要项目团队的全体成员投票决定。
在投票会议上，项目管理人员列出下一步需要完成的任务，要求项目团队的每个成员对每个任务完成所需要的时间进行现场投票。如果出现不同成员投票结果相差很大的情况，项目管理人员要求相关成员说出理由，再由全体成员商量决定该任务完成所需要的时间。在确定每个任务完成所需要的时间后，项目管理人员根据本次迭代的截止时间要求，选择合适的任务加入本次迭代计划，保证迭代计划里的所有任务完成需要的总时间不能超过项目团队全体成员可用于开发的时间。
在推行任务投票时，我们的开发人员对于一个任务完成所需要的时间进行投票，往往会出现投票结果相差很大的情况。这主要是因为每个开发人员的经验和能力存在一定的差异，对一个任务完成所需要的时间会从自己的角度做出估计。敏捷开发要求，不管是哪个开发人员都要尽可能在项目团队全体成员投票决定的时间内完成该任务。在完成任务的过程中，开发人员充分调动了自身的积极性、主动性和创造性，也培养了在工作中的成就感和自豪感。
3需要改进的地方
尽管我们对敏捷开发进行了一些应用和探索，感受到了敏捷开发带来的好处，但由于条件所限，并没有完整地应用敏捷开发所提倡的各种方法。比如，敏捷开发提倡结对编程，要求结对的两位开发人员使用同一台电脑共同完成代码。结对人员中的一位控制键盘并输入代码，另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。两人交流频繁，并可以随时互换角色。在一次迭代期间，结对的关系要改变很多次，以便每位团队成员和其他团队成员都在一起工作过，并参与了本次迭代中所涉及的每一项工作。由于我们的开发人员经常身兼数职，很难保证一定时间内形成稳定的结对关系，也就很难满足结对编程的要求。一些公司时下正在实践的“松结对编程”是我们下一步考虑的方向。
［责任编辑：汤静］