禪道項目管理系統(tǒng)使用規(guī)范

...wd......wd......wd...禪道工程管理系統(tǒng)使用標準一、標題命名標準禪道工程管理系統(tǒng)提供模塊名顯示功能，通過以下操縱顯示。這樣標題的命名規(guī)則上我們可以規(guī)定：#工程標簽#【{創(chuàng)立時間}】《{產品/子產品}》{方案/需求/任務/Bug}1.方案/需求/任務命名命名格式：【{創(chuàng)立時間}】《{產品/子產品}》{方案/需求/任務/Bug}例子：【20160907】《中國比特幣》v1.8版研發(fā)方案【20160907】《App》v1.8版研發(fā)方案【20160907】《iOS》v1.8版研發(fā)方案【20160907】《Web》v1.8版研發(fā)方案【20160907】《iOS》找回登錄密碼(手機/郵箱)沒有證件號輸入項2.測試用例命名命名格式：功能模塊-子模塊-子模塊例子：財務功能—人民幣相關業(yè)務功能財務功能—數字貨幣相關業(yè)務功能用戶注冊登錄功能3.發(fā)布版本命名命名格式：{工程/子工程}{版本號}〔{狀態(tài)}〕例子：App1.8〔研發(fā)中〕App1.7〔已發(fā)布〕二、工程開發(fā)方案流程標準1.創(chuàng)立產品創(chuàng)立一個主線產品，假設這個產品涉及多個平臺，則根據父子關系創(chuàng)立樹標準事項：1〕產品只能由超級管理員建設。2〕每個主線產品，自身再細分不同平臺的子產品。2.創(chuàng)立工程如果你已經創(chuàng)立了產品樹，則新建一個主線工程后，它將會關聯(lián)整個產品的樹構造，如上圖所示標準事項：1〕工程只能由超級管理員建設。2〕只要創(chuàng)立好產品體系，直接創(chuàng)立一個主線工程會有對應產品的子工程。3.創(chuàng)立工作方案為了更好維護工程，我們采用階段性迭代開發(fā)方式。每個開發(fā)階段都以唯一的版本號命名方案，每個階段都合理匯總需求及要修復的bugs，盡可能地確定及控制每個階段開發(fā)時間及人力本錢。使工程開發(fā)能做到高效率與高穩(wěn)定兼顧。1〕由工程經理創(chuàng)立“方案〞描述方案的版本號，工作概述，開發(fā)時間等。〔時間盡量預松，以備摸索時遇到坑〕2〕為方案創(chuàng)立需求及關聯(lián)需本次迭代修復的bugs創(chuàng)立這個方案要實現的需求，及要在這次開發(fā)方案中修復的bugs標準事項：1〕開發(fā)方案只能由工程經理等人員建設。2〕開發(fā)方案盡力做到小而精準，做好需求分析，做出符合用戶需要的功能。3〕開發(fā)方案中列明開發(fā)人員及職責，盡量不要一個人員同時在進展多個方案，防止其進度無法把握。4〕開發(fā)方案的時間預估應該要合理，必須包含需求分析，原型設計，編程開發(fā)，功能測試等時間，時間安排不合理會造成偷工減料，Bugs頻繁出現。5〕完成每個方案都必須寫下《方案總結》，總結新技術和遇到的問題，提高團隊效率。4.創(chuàng)立需求有了開發(fā)方案，我們就可以創(chuàng)立需求，把需求關聯(lián)到方案中。有時候，可能會出一些特發(fā)奇想的需求，這些可以不納入到方案中，可以作為臨時任務完成。但我們還是盡可能把需求匯總好，歸納到方案中，這樣才能保證工程穩(wěn)定，降低本錢。防止倉促粗糙的測試導致工程上線遇到嚴重問題，付出沉重本錢。標準事項：1〕需求只能由工程經理，產品經理，客服經理等人員建設。2〕需求盡可能綁定到開發(fā)方案中。3〕需求要指明所屬的產品模塊。4〕需求必須經由產品經理審核。4〕盡可能歸納多個需求點到一個記錄中，可使用《XMind》等腦圖工具整理出來，方便理解閱讀。5.創(chuàng)立任務有了需求，我們就可以依照每個需求點制定日常的開發(fā)任務指派給下屬。有時候有些簡單的任務，可以不需要需求做支持。例如，一些文檔整理任務。但我們盡量把任務歸類好，要保證任務是在那個版本，那需求點而做的。保證Bugs出現時可查找到開發(fā)人員和原始的需求內容。標準事項：1〕任務只能由工程經理等人員提出。2〕單個任務時間最好控制在1周內，盡可能細分任務，這樣進度把控跟準。3〕開發(fā)人員每日要求簡述任務進度和遇到的問題。防止低級問題造成任務阻塞。4〕只要任務關聯(lián)上需求，在詳細頁面中可以看到需求內容。5〕任務描述盡可能清晰羅列工作要點和本卷須知。6〕不要一個任務指派給多個人一起做，防止開發(fā)上的沖突。7〕為了區(qū)分任務是屬于需求關聯(lián)的任務，還是日常臨時的任務，可用顏色區(qū)分，“默認顏色〞為方案任務，“綠色〞為臨時任務6.創(chuàng)立版本開發(fā)方案中的需求都完成后，接下來就是安排測試工作，在測試前需要建設版本號。這樣測試人員發(fā)現bugs，可以標記那個版本發(fā)現的。標準事項：1〕版本只能由工程經理等人員建設。2〕最好不要有兩個同時是“研發(fā)中〞的版本，防止分支的代碼混亂。3〕發(fā)布了的版本記得及時標記為“已發(fā)布〞狀態(tài)。4〕解決了bugs或完成了需求，及時在版本號上關聯(lián)上。7.創(chuàng)立測試版本號創(chuàng)立后，接下來就可以測試了。建設好的測試用例，做好測試方案，測試質量直接影響到產品質量。長期維護的產品應該以測試推動開發(fā)，所以我覺得保證測試質量至關重要。標準事項：1〕測試只能由工程經理等人員建設。2〕盡可能描述本次測試方案的要點和本卷須知。3〕測試人員熟悉新功能后，盡力做到建設專業(yè)的測試用例，并關聯(lián)到每次的測試方案。4〕測試用例的質量直接影響到產品質量，長期維護的產品應該以測試推動開發(fā)，所以我覺得保證測試質量至關重要。8.測試/日常Bugs提交當測試人員/客服發(fā)現時Bugs，最有效的解決就是提交到相關產品對應的Bugs中。防止口頭交代問題造成遺忘及處理結果無法交代清楚。標準事項：1〕Bugs任何人員都可建設。2〕Bugs的發(fā)現過程盡可能記錄詳細，需要賬號或數據條件應該列明。3〕Bugs標記