导读：Ecom的EMS1.0.0项目尝试了敏捷开发模式，极大地提升了项目的效率与质量。下面，让我们一起看看项目组的做法吧！

【实践1】迭代开发、迭代测试、迭代设计：
EMS1.0.0采用迭代开发方式，共划分4个迭代版本。QA与RD的配合模式如下图。

每个版本的单元测试都在提测前完成，以确保交给QA黑盒功能测试的代码都经过单测检验。单测未完成，则不允许迭代周期结束。为此，多次出现调整迭代计划情况。

RD开发下一版本时，QA专注于上一版本黑盒测试。时间允许情况下，QA会提前配合RD做下一版本单测。QA测试中发现问题，及时与RD沟通，确认bug后RD会及时修正，并交由QA即刻验证。

此外，详设撰写也采用分阶段迭代方式，使得 RD、QA 都能先从整体把握项目全貌，避免一开始就纠结于各种细节。测试设计与产品设计并行，提升效率同时保证了文档质量。

【实践2】FeatureList：
在SQA建议下，EMS的两模块分别做了Feature List，开发过程也据此划分。每个开发版本完成的功能都是Feature List的一部分，且每个版本都是可交付，可run的，功能相近的feature划分在同一版本中。正是因为有了基于Feature List制定的开发计划，QA的工作才更加清晰明了，每一阶段的测试点才更加明确。对应RD的Feature List，QA制定了自己的测试计划，也是按表格的形式展现（如下图所示）：

【实践3】单元测试：
EMS两个模块在单测上采取了不同的投入力度，表现出截然不同的效果。

Broker模块的单测成本较高，考虑到单测需要启动桩，且桩数据构造成本较大，所以单测投入相对较少，代码分支覆盖率低（仅为15%），但黑盒测试阶段发现bug多（38个），耗时长（200人时）。

Storage模块则与之相反，单测投入相对较多，代码分支覆盖率高（60%），发现bug数量较多（QA的单测就发现了10个）。在黑盒测试阶段发现bug少（10个），耗时很短（80人时）。

通过实践对比，可以看出单元测试与黑盒测试之间的密切关系。

另外，在设计、开发过程中应考虑代码的可测性 ，可测性低的代码将带来较高的单测成本（有的甚至没法单测），并最终造成QA在黑盒测试投入较多的时间。

【实践4】QA和RD坐在一起：
EMS项目中，QA与RD坐在同一片区域，QA背后是RD，RD脑后是QA。有问题，大家都是扭过头来就讨论，EMS项目中遇到问题都是当面沟通，马上解决，效率极高。当然，为防打扰别人的思路，一般会先在hi上说一声。

【实践5】跨职能团队：
EMS迭代开发中的协作非常紧密与高效。敏捷团队中的角色并非一刀切，关键是合理协调人力，有序分工，充分配合。当某一版本周期紧时，QA主动协助RD单 测；项目后期，RD开始直接使用QA开发的自动化测试工具与测试数据进行测试。另外，模块级的性能测试都由RD同学完成，灾难恢复类的测试则由OP完成， 而QA只是提供测试环境和机器。

在这样一个氛围融洽的项目团队里，EMS1.0.0成功上线，并获得了两项商务搜索部的创新奖，那让我们来看下这个高效的敏捷团队吧！