最近在不断尝试新的做法，以求提升快速响应能力，适应市场试错节奏，实现敏捷开发。本次做法：一个 rdoc 版本，多次迭代，3~6 天为一个完整的冲刺 sprint（一次迭代）。
开发内容和任务划分
- API 接口（及内部数据设计）的开发；
- 站点路径设计（PATH DESIGN），分散在切页面任务里；
- 页面结构 HTML
- 样式 CSS
- 数据 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 接口测试一定要做到尽早、经常和充分测试。
测试的基本步骤
- 对页面，重点关注其数据元素和文案；
- 对API 接口，边开发边测试，逐个测试（尽早测试、充分测试、经常测试）；
- 数据 JS 通过本地模拟环境进行调试和模块测试；（通常和第2点并行开发）；
- 数据 JS 由使用 MockServer 切换到使用 API 进行集成测试；
- 当每个页面功能都是通过上述步骤持续测试、持续集成起来的时候，系统级测试出现的问题是有限的、易定位、易解决的；持续集成的好处是 快速发现和修复问题（Martin Fowler）；
- 参见 测试向开发行进，论自动化测试；
建立迭代
- rdoc 需求（线框原型）依惯例分版本（概念和过去保持一致），比如 0.6；
- 每个版本分多个小迭代来实现，以 0.6a, 0.6b 前缀来标识；
- 每个小迭代以 3~6 天为宜，即一个完整的冲刺 sprint（迭代）。
- 持续测试，持续集成，持续发布；
