Issue Tracking in Redmine


Redmine 是以 Issue Tracking 為概念核心。一開始的目的是為了追蹤軟體的 Bug,後來衍伸出追蹤 事情議題 的概念,最後集結的就是專案管理的功能。

什麼叫做 議題

Issue: 翻譯成『議題』,泛指需要被管理、處理、關注、討論、追蹤 ,後來我也延伸到 的管理。在組織裡面,每天有一堆事情要處理,大的事情、小的事情、專案的、非專案、很多人在意的、沒人關心的 …. 每件事情,都是 議題 Issue

議題關注的重點有兩個:流程角色

  • 角色 (Roles):誰負責?誰處理?重點在於
    • 角色代表可以有不同權限,或者走不同流程。
    • 軟體開發最基本的角色:Developer, Reporter, Manager
    • 在組織裡角色也代表著權力與資源的多寡
  • 流程 (Workflow):流程代表 SOP,可以 SOP 代表問題少。
    • 流程由一堆 狀態 (Status) 組成
    • 最簡單的流程: New -> In Progress -> Done
    • 流程所有狀態又分成 open, close 兩種。

每個議題可大可小,但是基本的需要知道以下資訊:

  • 時間的起迄 (Start Date, Due Date):開始時間、結束時間
  • 估時 (Estimate):需要粗略的工時估計,雖然叫工程師估時很不切實際,但是管理上還是要做。。。
  • 發起人 (Author):誰發起 (issue) 這個議題?
    • 這個發起人必須說清楚要做啥,跟 Assignee 溝通
  • 負責人 (Assignee):主要由誰負責這個議題,只能是一個人
    • 如果需要兩個以上的人處理,就需要 breakdown 成兩個以上的 issue,而由一個人負責管理所有的子議題。
    • 不適合的用法:循序 (Sequence) 的協作項目,也就是一件事情需要很多人做,把這張 Ticket 一個人傳給另一個人,這樣的用法不適合 Redmine,因為沒有主要的負責人。如果流程不常,建議 Breakdown 成不同的 Task。
  • 狀態 (Status):現在是在什麼樣的狀態?
    • 狀態代表著決策者接下來動作的參考點,也是整體進度的狀況
    • 狀態的集合代表著 Tracker 的流程
    • 狀態跟角色權限有關係,狀態可以透過流程規劃,限制角色的權限,達到全縣管控目的,例如只有 Tester 可以關閉 Bug

其他 Optional 的欄位,用在任務進行中管理使用:

  • 優先權 (Priority): 優先次序
  • Milestone / Version: 階段性任務的時間點,重點在時間。
    • 以軟體來講就是 Version
    • Redmine 會彙整相關的 Task 的進度,PM 要關注的是這個
    • Redmine 原始的關鍵字叫做 Target Version,後來我跟同事討論,覺得 Milestone 更適合
    • 使用 Agile 可以把這個當作 Sprint 使用,概念上是一樣的。
    • 相關文章:Version Control
  • Category: 以 為主的任務分類。
    • 工作分類很多種,不知道找人,就找分類,每個分類會有一個預設的處理角色。
  • 進度 (% Done):完成到哪裡了?
    • 這個欄位的資訊會被彙整到 Milestone / Version

所以什麼是 一個議題 ?簡單說,只要需要花時間的,就是議題,例如:

  • 讓公司今年達到 10 億獲利 –> 大議題
  • 讓公司今年員工都加薪 –> 大議題
  • 今年導入 DevOps 精神 –> 大議題
  • ooxx 功能效能不好,要修正 –> 議題
  • 應該要有 ooxx 功能,可以改善 aaazzz –> 大議題
  • 某某功能上有一個 bug –> 小議題
  • 利用自動化改善系統管理 –> 大議題
  • 用大數據,找到公司的金礦 –> 大議題

這些大大小小需要被管理 事情 都是 議題,議題都會有主要的目的性、達到的效果,怎麼有效、有組織的管理這些東西,就是管理者要思考的。這件事情可以讓公司有淺力、有想法的員工參與,訓練獨立思考與判斷的能力。

Issue 的種類:Tracker Type - 以軟體開發為例

Issue 的種類在 Redmine 裡稱為 Tracker Type,針對不同類型的問題與需求,有不同的 流程狀態

以軟體開發為例,最常見的會有以下:

  • Requirement: 需求,通常就是抽象的 商業目的,像是:
  • Feature: 新功能、新特色,需求經過系統分析、設計,轉換成技術人員可以時做的具體項目
  • Improvement: 跟 Feature 很像,但是差異在於,Feature 是全新的功能,以前沒有的。Improvement 則是把既有的功能,做修改,不管是增強、調整、修 bug 等等。
    • 跟 Feature 很大的差異,被 Improved 的 Feature ,後續驗證階段必須增加回歸測試 (Regression Test)
  • Defect: 測試階段發現的問題都叫做 Defect (缺失)
  • Bug: 上線後發現的問題叫做 Bug
  • Operation: 系統維運的工作項目,像是 Provisioning, Deployment, Obervation, Maintain, SecOps … 等

不再上述的工作項目全部用 Task ,是最一般化的任務,不知道選什麼就是 Task。

上述 Tracker 站內相關文章:

標題 Issue 的種類:Tracker Type - 以軟體開發為例 說明前述的設計是為軟體開發,其實我也曾經為 系統管理人事請假 設計過不同的 Tracker Type,這些都是不同領域的 Know How,也是最珍貴的知識。

更多 Tracker Types

只要有自己的流程的議題,都可以定義成獨立的 Tracker Type,以下是可以獨立定義的:

  • PoC (Proof of Concept)
  • Budget
  • Plan
  • Release Engineering, DevOps, CI/CD, InfraCode
  • Deployment
  • Backlog
  • Sprint
  • 更多參閱 需求管理 的舉例

要注意的是,Redmine 的 Tracker Type 跟 狀態 (Status), 角色 (Role) 是直接關聯的,所以定義很多 Tracker Type 就代表會把流程搞複雜。流程複雜代表的 溝通成本 提升。

不同階段的企業

不同階段的企業,有不同的需求

  • 草創期:通常是第一年
    • 每個人都身兼數職的階段。
    • 基本上這階段 Bug, Issue, 專案管理系統都不重要,有白板就夠了。
    • 還在燒錢與快倒閉階段,先穩定產品再說。
  • 剛起步的新創事業
    • 大概是前兩年
    • 如果方向正確,會接到很多市場的需求,最需要 Time to Market 的時候
    • 使用 Scrum 這種方法是最適合的。
    • 議題管理系統還不是那麼重要,但是可以開始導入了。
  • 發展中的事業
    • 通常是已經燒錢 2-5 年的公司,已經抓到基本的商業模式,同時已經開始獲利。
    • 轉大人 的關鍵時期,轉不過瞬間會在市場消失
    • 員工數量快速增加,搶人才的時候
    • 組織衝突每天都會上演,甚至是政治戲碼
    • 因為權責不清處,所以組織重構是很常見的
    • 開始需要用 制度人事物
    • 系統的歷史包袱漸漸浮現
    • 有不同地區的辦公室,但是都還是同一個國家
  • 成長中的企業
    • 組織框架大致確立,在市場上已經有能見度和基本的品牌形象
    • 商業模式已經確立,但是持續調整組織以及經營模式。
    • 開始跨國、跨境
    • 有不同地區的辦公室,通常是跨國。
    • 沒有議題管理系統不行,而且需要有專門的部門負責流程制定、導入與管理
  • 穩定獲利的企業,發展第二春
    • 商業模式經得起市場的考驗,且穩定獲利
    • 維運會比開發重要
    • 通常可能已經上市上櫃
    • 開始有不同的嘗試,嘗試新的商業模式
    • 集團式組織組織,開始分不同 事業群事業部,像是 不務正業的先驅者 - YAMAHA

我以前的公司是一家穩定獲利的企業,內部有一套產品流程管理,使用的是 Oracle Agile PLM ,這套系統用來管理整個開發中的產品流程,可以設計各式各樣的關卡,做審核機制。

這樣的流程是可以透過軟體設定制訂出來的,非常的有彈性,但也很複雜。這種大型的流程管控是直屬 IT 部門的流程稽核部門負責。後來有了新的事業部 (就是我加入的事業單位),他們就會來要求要走這套系統。

這段故事參閱 協同合作系統建制與導入 - 以 Redmine 為例 的介紹。

這段獨立另一篇: 不同階段的企業

議題管理

Redmine 在議題管理方面不是最好的工具,但卻是帶出 如何組織議題 這個思維的工具。

著名的專案管理 JIRA 也是以此為概念,甚至延伸到人事管理、HelpDesk、Operations、Legal 等項目,其實重點就是在如何分類議題以及定義流程,這些都是屬於 Domain Know How,atlassian 嘗試把他們包成不同的產品線,擴大市場。

我已經有一套屬於軟體工程專案管理的心法,未來再持續整理分享。

延伸閱讀 (站內)

參考資料


Comments