通过小迭代实现敏捷开发

最近在不断尝试新的做法，以求提升快速响应能力，适应市场试错节奏，实现敏捷开发。本次做法：一个 rdoc 版本，多次迭代，3~6 天为一个完整的冲刺 sprint（一次迭代）。

开发内容和任务划分

1. API 接口（及内部数据设计）的开发；
2. 站点路径设计（PATH DESIGN），分散在切页面任务里；
3. 页面结构 HTML
4. 样式 CSS
5. 数据 JS

注意：CSS 和 JS 二者基于 HTML 集成，实现最终用户可见功能。

任务关联性

上层依赖于下层提供的服务：数据 JS 做最后集成（[原图][draw.io-1]）

• 本图使用 draw.io 生成，支持 Google Drive 云存储。
• 页面需求基于线框原型，包含了交互演示和业务说明，页面需求是测试验收的依据。

测试开发

基本理念：尽早测试、经常测试、充分测试。

API 接口

首先提供一个桩，作为一个桩要能支撑 数据 JS 迅速进入开发；之后对每个 API 接口 逐一测试，经常测试，充分测试。

• 通过使用 MockServer，前端自己可以轻松构建本地模拟服务环境。
• API 接口 需要 review。
• API 接口 是测试工程师 前期 重点测试内容。
• 测试工程师有两个主要准备工作：分析接口参数（jmeter 或者自动化脚本）、准备桩数据。

站点路径设计（PATH DESIGN）

• 站点路径 是一个重要事情，属于架构设计一类，需要 review。
• 页面要适当分组，以利于快速交付、持续部署，前端结构要逐步优化；

HTML 页面结构、CSS 样式 及其 设备适配

• CSS 样式，视觉设计师会做一个很好的跟踪，他会 review 其实现效果。
• 作为测试工程师，CSS 样式的测试优先级在 前期 低于功能性测试（包括 API 接口 和 数据 JS 的测试），在后期应当逐步加强设备适配性测试。

数据 JS

作为测试工程师，这是集成测试的重点。要想这部分测试做得好，API 接口测试一定要做到尽早、经常和充分测试。

测试的基本步骤

1. 对页面，重点关注其数据元素和文案；
2. 对API 接口，边开发边测试，逐个测试（尽早测试、充分测试、经常测试）；
3. 数据 JS 通过本地模拟环境进行调试和模块测试；（通常和第2点并行开发）；
4. 数据 JS 由使用 MockServer 切换到使用 API 进行集成测试；
5. 当每个页面功能都是通过上述步骤持续测试、持续集成起来的时候，系统级测试出现的问题是有限的、易定位、易解决的；持续集成的好处是 快速发现和修复问题（Martin Fowler）；

• 参见 测试向开发行进，论自动化测试；

建立迭代

• rdoc 需求（线框原型）依惯例分版本（概念和过去保持一致），比如 0.6；
• 每个版本分多个小迭代来实现，以 0.6a, 0.6b 前缀来标识；
• 每个小迭代以 3~6 天为宜，即一个完整的冲刺 sprint（迭代）。
• 持续测试，持续集成，持续发布；

---