四月初开始 通过小迭代实现敏捷开发。经过超人、NoteCode 之辩析和众人南北协同开发之实践，对禅道的使用常有体悟，时有所获。
在禅道上构建产品
不同角色、不同平台都是一个产品，比如供应商PC版就是一个产品。
嗯？看起来这里的产品和你的想象不一样，甚至差别很大，是的，因为最初我也不是这么划分产品的，后来超人建议这么试试，我才这么做的。
经过实践，发现对小团队是一个合适的做法。这相当于进行了拆分，降低了耦合，降低了复杂度。
- 按角色按平台分产品，有利于厘清各自的功能和内容，从而有利于复用；
- 经常维护需求模块；
禅道：产品-》需求-》维护模块，模块分级不超过 3 级；
通过产品模块的良好划分，使得开发任务保持和产品设计的内在一致性； - 需求模块 并不总是和 线框原型 | 页面需求 一致；
- 重要的、独立的、复用的，应当考虑单独设置；
- 需求模块 和版本无关，不标识版本；
迭代的周期
- 一个版本，多次迭代，每次迭代以一周为宜；
禅道命名标识约定
- rdoc 版本命名，如：0.6（在 svn | git 上保持一贯的分支概念）；
- 迭代命名：迭代代码+标识短语，如：s0.6a成都站；
团队名称：s0.6a；
迭代代码：s0.6a，
标识短语：成都站；成都站 是具有明显区别性和实际含义的标识短语；命名还是很重要的，每次迭代都要一起商定 标识短语。
- 产品命名示例：供应商PC版
- 产品需求模块命名示例：首页
- 任务命名：任务标题
- BUG 标题命名：建议以产品模块为前缀；
仅供备注（请直接忽略）
- 不再需要 标识一个产品计划（原来用于将需求关联到产品计划，因为我们不再使用禅道管理需求）；
产品计划命名：p0.6a成都站（p: plan，0.6: rdoc version） - 不再使用禅道管理需求；
需求前缀命名：【r0.6a成都站】标识需求前缀；
需求请关联产品/模块；
每个需求：【r0.6a成都站】${具体需求 Title} - 不再需要 创建版本（build）（原来用于将 BUG 关联到 build，因为我们持续发布，不再在禅道管理 build）；
build 命名：x.y.z.w 格式
注：之前的做法（包括 8ni）是：一个版本，一次迭代，多个 build，三周为宜。
