禅道命名标识约定－敏捷在禅道（五）

四月初开始 通过小迭代实现敏捷开发。经过超人、NoteCode 之辩析和众人南北协同开发之实践，对禅道的使用常有体悟，时有所获。

在禅道上构建产品

不同角色、不同平台都是一个产品，比如供应商PC版就是一个产品。

嗯？看起来这里的产品和你的想象不一样，甚至差别很大，是的，因为最初我也不是这么划分产品的，后来超人建议这么试试，我才这么做的。

经过实践，发现对小团队是一个合适的做法。这相当于进行了拆分，降低了耦合，降低了复杂度。

• 按角色按平台分产品，有利于厘清各自的功能和内容，从而有利于复用；
• 经常维护需求模块；
  禅道：产品-》需求-》维护模块，模块分级不超过 3 级；
  通过产品模块的良好划分，使得开发任务保持和产品设计的内在一致性；
• 需求模块 并不总是和 线框原型 | 页面需求 一致；
• 重要的、独立的、复用的，应当考虑单独设置；
• 需求模块 和版本无关，不标识版本；

迭代的周期

• 一个版本，多次迭代，每次迭代以一周为宜；

禅道命名标识约定

1. rdoc 版本命名，如：0.6（在 svn | git 上保持一贯的分支概念）；
2. 迭代命名：迭代代码+标识短语，如：s0.6a成都站；
   团队名称：s0.6a；
   迭代代码：s0.6a，
   标识短语：成都站；成都站 是具有明显区别性和实际含义的标识短语；

   命名还是很重要的，每次迭代都要一起商定 标识短语。

3. 产品命名示例：供应商PC版
4. 产品需求模块命名示例：首页
5. 任务命名：任务标题
6. BUG 标题命名：建议以产品模块为前缀；

仅供备注（请直接忽略）

1. 不再需要 标识一个产品计划（原来用于将需求关联到产品计划，因为我们不再使用禅道管理需求）；
   产品计划命名：p0.6a成都站（p: plan，0.6: rdoc version）
2. 不再使用禅道管理需求；
   需求前缀命名：【r0.6a成都站】标识需求前缀；
   需求请关联产品/模块；
   每个需求：【r0.6a成都站】${具体需求 Title}
3. 不再需要 创建版本（build）（原来用于将 BUG 关联到 build，因为我们持续发布，不再在禅道管理 build）；
   build 命名：x.y.z.w 格式

注：之前的做法（包括 8ni）是：一个版本，一次迭代，多个 build，三周为宜。