证券软件系统开发采用敏捷开发模式，一定要把敏捷设计、敏捷开发、敏捷测试连在一起，这样才能最大限度地发挥敏捷的效用。

　　需求Backlog清单都列出来了之后，开发人员需要根据排定的需求优先级，从需求池当中选出需求排到当前的迭代中，直到所有需求的估算工作量加起来达到迭代周期的工作量为止，一般会留一小部分时间来做为缓冲。证券软件开发人员集体估算每个需求的工作量并维护到上述的Backlog列表中，这些都是在敏捷的迭代计划会上完成的。

　　接下来是确定Backlog是否还需要拆分，即判定是否可以在一个迭代内完成，或者是否可以在一天内完成，证券软件开发敏捷开发模式可以建立详细的考核机制，每天都跟踪之前一天的任务是否已经完成。开发人员拆分Backlog出来的结果就是一条条的Task，然后开发人员根据各自的任务来编写《产品系统设计说明书》，最后汇总。一般拆分的依据如下：

　　1、每个拆分出来的Task都是可单独验证并上线的。

　　2、每个拆分出来的Task都是可以在单个迭代内完成的。

　　每日可以跟踪需求实现的进度，检查每天的工作进展是否按照迭代计划在进行，永远确保资源投入在高优先级的Backlog上；该完成而未完成的任务有哪些以及是什么原因，及时识别出对迭代中后续问题的影响，并根据风险和应急方案努力规避；遇到的问题应该由谁来负责解决以及何时必须解决，否则会影响后续计划中哪些条目，尤其是那些有前后依赖关系的条目；开发过程中会出现对原有需求的进一步细化，可能会和迭代计划时讨论的结论有一些差异，那么变更的内容是否会对既定的业务需求产生调整等等。

　　证券软件开发敏捷测试是顺应敏捷开发方法，力求达到质量和效率平衡的一系列测试实践，敏捷测试是测试的一种，强调从用户的角度，即从使用系统的用户的角度来测试系统。重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

　　因此，证券软件定制在敏捷开发模式下，开发人员不是等整个迭代的任务都开发完了才送测，而是做完一个送测一个。前面也讲到Backlog拆解成Task时要求每个Task都是可以单独验证的，也就是说每个Task都是可以单独测试的，这样测试人员可以对每个已开发完成的Task进行测试，及时发现问题，及时改进。这种模式下，效率高的话可以精确控制到每天的开发结果验证，这样可以确保产品需求都是按照计划来进行的，并且不会偏离需求本身。

　　测试人员也是从迭代计划会议开始参与到每个迭代当中，对本次迭代中安排的所有需求清单编写测试用例，最后形成一份汇总后的《测试用例及测试报告》。在每天的会议上，测试人员可以及时告知每天的测试进展和测试的问题，及时帮助开发人员修正。这样测试人员就可以持续测试、持续反馈，整个测试的阶段性会比较模糊，主要强调测试的速度和适应性。

　　证券软件开发敏捷测试要求测试人员去扮演“用户”的角色，确保产品满足既定的需求；强调直接的沟通、协作以及团队责任，不太关注对缺陷的记录与跟踪；需要建立起有效的自动化测试方法，对老模块的功能用自动化测试，新模块用手工测试结合的方法。