禪道命名標識約定－敏捷在禪道（五）

四月初開始 通過小迭代實現敏捷開發。經過超人、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，三週為宜。