1、簡介
Codes 重新定義 SaaS 模式 = 雲端認證 + 程式及資料本地安裝 + 不限功能 + 30 人免費
Codes 是一個 高效、簡潔、輕量的一站式研發專案管理平臺。包含需求管理，任務管理，測試管理，缺陷管理，自動化測試，cicd 等功能； Codes 幫助企業加速融合研發、測試、運維一體化程序。商業版不限功能，本地安裝只限使用者數，30 個使用者免費 ; 社群版當前只開放了測試跟蹤管理 (主要功能用例管理，缺陷管理)，後續接著分離其他功能程式碼出來。
官網 https://icodes.work/
gitee 程式碼倉庫 https://gitee.com/xiaoming1q/icodes
2、背景
市面上老一點的專案管理工具迭代下只含任務，其他一些新的專案管理工具迭代下包含了需求、任務和缺陷。迭代下只包含任務顯然很不合理；只有需求、任務和缺陷，也是有問題的。
一個研發週期的閉環：從需求-->到研發任務-->到測試-->到上線。一個迭代就是一個研發週期，迭代下的需求除了可分解為開發任務外，也應可分解為測試用例才方便測試左移；很多專案管理工具，迭代下雖然有需求和任務，但是他們是隔離的，不能從需求中拆分出任務，這也不符合一般的敏捷開發過程。
3 多事項閉環迭代功能說明
3.1 敏捷場景拆解為迭代的業務過程
Codes 產品團隊基於以上眾所周知的認知，不走尋常路，從實際出發採用多事項閉環迭代的實現方式。敏捷開發的場景如下圖所示：
Codes 中把上述敏捷場景拆解為迭代，迭代作為一個完整的研發週期閉環，包含了從需求、到任務、到用例、到測試、到缺陷、到自動化測試到上線，並自動生成迭代總結並存檔。
敏捷場景拆解為迭代的業務過程：1從需求池中分配需求到迭代下 2在迭代下把研發把需求拆分為任務 3在開發拆解任務的同時，測試同學可進行需求測試並針對需求編寫測試用例 4待開發同學完成研發任務提交測試後，測試同學執行測試用例，且執行不透過就提交缺陷 5在工作的過程中提交工時日報，自動計算迭代進度 6 迭代總結及覆盤 7上線釋出。
3.2 Codes多事項閉環迭代功能說明
如下圖所示，迭代下有需求、任務、缺陷，測試用列，功能業務場景，介面場景，交付物和釋出，場景內用例，人員分工。需求可分拆解為任務和分解為測試用例；功能業務場景為場景用例，是一組有執行順序的用例集合；交付物為迭代中產出的各種文件；釋出指上線時執行的一系列有先後順序的事項，也可當一個釋出的check list 來看，省得因粗心引發問題；人員分工，顯示迭代下各人員事項分工及進度；工時趨勢顯示預估工時、實際工時和已用工時趨勢。
Codes 的迭代也為不完全按標準流程的場景提供了靈活性。比如，如果需求很簡單可以不拆解為任務，直接把需求當任務來處理；另外如果沒有需求，直接建任務也是可以的，這時在迭代下任務的TAB頁中可以把不關聯需求的任務分配到迭代下。迭代下任務TAB中的任務有兩個來源，拆解需求的任務，以及手動分配到迭代下不關聯需求的任務。
3.3 為方便從不同維度來檢視相關工作項，需求、任務，缺陷和用例都支援分組顯示。
需求分組，可按負責人、建立人、來源、優先順序、流程、需求分類、狀態來分組以及以看板檢視來顯示。預設為標準檢視，也就是不分組的列表顯示。
任務分組，可按負責人、任務型別、緊急程度、需求、狀態來分組以及以看板檢視來顯示。
缺陷分組，可按待處理人、提交人，狀態、等級、需求來分組以及以看板檢視來顯示。
迭代下的缺陷可以是當前迭代中新提交的缺陷，也可能是需要當前迭代解決的存量缺陷。
用例分組，可按執行人、狀態、類別、優先順序和需求來分組顯示。標準檢視是預設檢視，就是不分組的列表。
3.4 以迭代方式組織測試的特點
傳統是以測試計劃來執行測試，一個計劃下分配要執行的用例，難以體現出測試執行人員的分工以及不同執行人員之間的執行進度。一個執行人一個計劃，多人就要建多個計劃，非常不方便，同一個計劃下如不同的人執行不同的用例只能口頭來安排。
Codes 中，把用例分配到迭代下後，再分配執行人，也就是在同一迭代下，各自有各自要執行的用例，然後可以檢視到總進度也能看各自的進度。
分配用例到迭代
在當前迭代需求下，編寫的用例自動分配到當前迭代下，當然也可以分配其他的用例到當前迭代下。
分配執行人
可勾選要分配的用例，也可以左邊的樹上勾選相關需求，也可把當前查詢到的用例全部分配（不用一一勾選）
執行用例
可快速執行，比如迴歸測試時，不需要檢視用例明細後再執行。
也可點用例狀態，在用例明細中執行
檢視執行情況，有總進度也有各人各自的進度
3.5 交付物
迭代中的一切產出物可以在這裡維護，且會自動放到專案文件下，在專案文件和迭代交付物中都可方便的檢視迭代中所產出的文件。
3.6 人員分工
這裡可以看迭代下各人員的事項安排及進度
3.7 迭代工時趨勢
可以檢視迭預代估、實際及已用工時的趨勢，Codes 中還可檢視階段以及專案的工時的趨勢。
3.8 迭代報告及釋出
迭代報告可匯出來，且迭代設定為完成時自動在專案文件中存一份迭代總結。除總覽的TAB外，其他TAB都是明細資料。
釋出
主要作為上線前check list事項 ,確保上線不會因遺漏出問題。
3.9 採用多事項且閉環的迭代的好處
以迭代為中心來組織研發工作，圍繞需求拉通上下游所有研發活動。方便覆盤，過程管理更通透和全面。那會不會帶來混亂呢？肯定不會，雖然所有事項都在一個迭代下，但不同職位的人員進入迭代的執行時間是不同的。
因迭代中包含了的所有事項，那麼迭代的進度和工時更完整的。用例我們用執行成本而不是用例個數來計算工時，另外在Codes 工時日報中除把迭代下，需求，任務，缺陷，用例工時都記錄下來外，其他事項，如開會等也計算到工時中，沒有預估工作量的待辦事項也透過日報中剩餘工時記錄下來，也就是說Codes 計算進度的資料是全面的，所以計算的進度更準確。
上圖迭代進度還可下鑽到人
原本就渾然一體的工作形成閉環，打破使用者的割裂感：不需要文件在叧一個功能模組中集中維護，做到研發和測試不分家，實現統一管理。也解決了測試在DevOps快速迭代中的木桶效應，促進了研發、測試、運維一體化融合程序。
更具靈活性，可閉環選代，也可非閉環迭代即和傳統做法一樣只有部分事項參與迭代。
最後打個總結：Codes多事項閉環迭代一點技術門檻都沒有，我們這樣實現就是為了方便完整管理一個研發週期，可以按版本來規劃迭代，也可按交付的時間週期來規劃迭代。創新不是為了玩新奇，是為了解決問題，下一次我們來聊聊另一個創新點，也是很酷的功能，欲知後事如何，且看下回分解。匠心打磨，持續創新是Codes的產品基因。