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

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