【專案管理】關於Issue/Milestone的使用指導

前言

本指導內容主要基於：

• 和鄒欣老師的語音交流結論
• 鄒欣老師《構建之法》的相關章節內容
• 現有開源專案在類似情況下的做法
• 筆者本人的專案相關經驗
• 筆者本人基於課程現狀的一點私貨

僅為一家之言，如有偏頗或不全者，歡迎討論或補充，感激不盡。

關於Milestone

• Milestone顧名思義，翻譯成中國話叫做“里程碑”
  • 基於上述含義我們一定程度上可以將Milestone理解為一個階段
• 對於Milestone的建立
  • 請務必按照相對獨立的區域性任務目標進行劃分，而不是簡單的以時間節點等非專案因素來劃分
  • 要設定合理的週期
    • 一般週期是1-4周為限度為好
    • 對於明顯過短的階段，該考慮是否與其他階段合併；對於明顯過長的階段，該考慮是否進行階段的進一步細分；不過仍然務必需要滿足上述基於目標進行劃分的基本要求
    • 如果實在難以兩全，則在基本合理的前提下，不必強求任務週期長度（簡而言之：里程碑的目標性優先於時間週期性）

【太長不看版】具體且簡單來說

• Milestone需要按照相對獨立的區域性任務目標進行劃分，不要簡單地基於時間來設定Milestone
• 對於軟工課程
  • Alpha階段可以劃分為一個Milestone
  • 因為其是一個完整獨立的階段，且時間週期和比較合理
• 在一些常見的開源專案中，也明顯體現著階段這一特性
  • 比如這個在Gitlab官方站上的開源專案：https://gitlab.com/arl2/palaestrai/-/milestones，靠上端的幾個Milestone雖然略長於四周，但是很明確的體現著階段的意義與目標

關於Issue

• Issue顧名思義，翻譯成中國話叫做“問題”
• 對於Issue的建立
  • 請務必按照相對獨立的區域性任務目標進行劃分，而不是簡單的以時間節點等非專案因素來劃分；且需要以簽入程式碼完成某實際模組為目標導向，標準為在Gitlab系統平臺上有Commit/Merge Request等形式的體現
  • 要設定合理的週期
    • 一般在實際環境下，週期以小時為單位為佳。例如，在現實企業開發中一天的8小時工作，可以設定幾個Issue來跟蹤進度，每個Issue大約2-3小時。
    • 其他週期相關與Milestone類似，也是同樣的目標性優先於時間週期性
    • 粒度劃分要儘可能做到易於跟蹤瞭解情況，但又不應細到嚴重影響工作手感或失去具體意義
  • 要根據分工，設定合理的Assign to，即將Issue具體分配到人；此外對於Issue其他相關的人員，也可以在Issue內容中進行@，以確保通知到相關人員。
  • 要根據任務所屬階段，關聯至對應的Milestone，以確保當前Issue進度可以納入Milestone進行計算
  • 要根據任務性質和當前狀態，打上合理的標籤，以方便可以在看板上快速瞭解當前整個專案的進展狀況
• 對於Issue的後續操作
  • 在Issue下可以就問題本身展開進一步的討論，並注意合理使用Comment和Discussion
    • Commit指評論，意為針對此問題本身的評論，不支援進一步回覆等功能
    • Discussion指討論，意為針對此問題的討論，支援進一步回覆等功能，並且對於discussion而言
      • 需要在討論完畢後，在討論宣告終結的那個回覆上點選右上角Resolved，表示問題已經被解決
      • discussion的解決程度也是衡量issue進度的重要指標，可以直觀地理解為——“問題下的Discussion未被全部解決意味著對此問題尚有需要進一步商議的問題，並需要儘快討論敲定”
    • 因此，建議但凡是因為存在疑問或不明確之處，而需要展開討論和商議的內容，都請使用Discussion
  • 注意與倉庫內其他內容的關聯
    • 例如Commit、Merge Request等，這些關鍵資訊需要與Issue進行充分的繫結，即在Issue中可以觀測到在系統層面上所建立的關聯
    • 具體來說可以參考官方文件：https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically，裡面對於Commit和Merge Request如何自動操作Issue有較為詳細的介紹，請各小組務必認真讀一讀，瞭解一下Gitlab Issue的正確開啟姿勢
  • 當任務的狀態或者性質發生變化時
    • 請及時更新Issue的標籤
  • 對於已經解決或者完成的Issue
    • 首先確保相關聯的Commit、Merge Request等是否都已經穩定（具體來說，需要確保是期望的版本，並且如果設定了CI的話需要CI也一併通過）
    • 其次確保當前Issue下的discussion是否已經被全部解決，Issue問題底部右側區域是否顯示綠色塊（如果discussion數量不少於1的話）
    • 在滿足上述基本要求並且確保Issue已被解決或完成的情況下，請務必記得關閉此Issue，以在系統層面上表示該Issue的終結

【太長不看版】具體且簡單來說

• 一個Issue可以視為一個問題或者任務，粒度要小一些以便精準反應各部分進展狀況
• Issue應該保持其問題或者任務的性質，不要基於時間來設定Issue
• Issue需要以簽入程式碼完成某實際模組為目標導向，諸如“學習XXX技術”、“對接XXX需求”等沒有程式碼體現的內容不應作為Issue
• Issue的維護是一個完整連貫的過程，請善用Gitlab平臺本身的一系列機制以達成更好的效果
• Issue講究實事求是，情況有變則寫清楚原因後增刪即可
• 考慮到可能對長遠一些的內容做不到精確規劃，建議先以Issue的形式做粗略規劃，後續根據實際情況再做擴充