本文作者：極狐GitLab 資深解決方案架構(gòu)師 尹學(xué)峰

許多企業(yè)依舊在用老舊的方式，如Excel離線表格進行項目管理。表格無法簡介的呈現(xiàn)出項目的任務(wù)分解、完成進度、任務(wù)類別等多種項目管理過程中必備的要求，更無法實現(xiàn)與企業(yè)員工的日常即時通信系統(tǒng)的打通。往往導(dǎo)致項目管理與項目實際情況相去甚遠。

為此，誕生了許多專業(yè)的項目管理軟件。不同行業(yè)類型、不同的技術(shù)水平適用于不同的項目管理軟件。

不同行業(yè)的傾向性

通用型傳統(tǒng)行業(yè)

建議使用Jira、Ones、PingCode、禪道、Redmine、TAPD、Polarion等工具。其中Jira是目前較為主流的項目管理工具，用戶基礎(chǔ)眾多，遺憾的是，Jira目前在國內(nèi)沒有技術(shù)支持團隊，選用Jira需要承擔(dān)較大的運維風(fēng)險。而后者皆為國產(chǎn)的商業(yè)化項目管理軟件，可以很好的替代Jira。這幾款工具的典型視圖如下：

圖示：Jira典型視圖

圖示：Ones典型視圖

圖示：PingCode典型視圖

圖示：禪道典型視圖

圖示：TAPD典型視圖

通用型高新技術(shù)行業(yè)

如果企業(yè)內(nèi)項目管理人員大部分具有開發(fā)背景，且項目分解后的工作內(nèi)容主要為由程序員進行代碼編寫工作完成的話，那么建議使用極狐GitLab進行項目管理。項目管理與代碼開發(fā)在同一個平臺完成，進而可以直觀、零延遲地反映項目真實進度。下面對如何使用極狐GitLab進行項目管理加以闡述：

極狐GitLab支持敏捷開發(fā)管理體系，它用群組、子群組和項目來分別對應(yīng)項目、子項目和代碼倉，通過epic、子 epic 和 issue 來對應(yīng)原始需求的任務(wù)、子任務(wù)和具體開發(fā)工作，這是項目管理的第一步。

圖示：極狐GitLab的敏捷開發(fā)管理體系

產(chǎn)品經(jīng)理創(chuàng)建原始需求后，和研發(fā)人員一起細化需求，并基于 invest 原則拆分需求。首先明確所有需求，撰寫具體的 user story。(注：參考epic實例 Browser-based scanner for DAST )

圖示：史詩Epic 原始需求拆分與規(guī)劃

撰寫完成后，如果大家有其他意見，可以以評論的方式寫在該 issue 下，然后進行討論，直到需求明確。極狐GitLab 以 issue 驅(qū)動，即無論是開發(fā)的任務(wù)、開發(fā)的需求還是 bug 缺陷，一律都用 issue 進行管理。

圖示：議題Issue 用戶故事與人員指派

撰寫完成后，如果大家有其他意見，可以以評論的方式寫在該 issue 下，然后進行討論，直到需求明確。極狐GitLab 以 issue 驅(qū)動，即無論是開發(fā)的任務(wù)、開發(fā)的需求還是 bug 缺陷，一律都用 issue 進行管理。

圖示：議題Issue 用戶故事與人員指派

隨著組織發(fā)展，issue 會越來越多，極狐GitLab 以一種靈活的自定義方式去打上不同的 Label，來區(qū)分不同 issue。Lable 是多級式的，第一級是一個 type，它決定了該 issue 是一個 bug、功能還是 QA 等。當打上第一級 Label 后，還需要打上第二級甚至第三級，比如說這個 bug 是性能問題、安全問題，還是來自一個手機端等等，可以自由精準地定義 issue。

圖示：標記Label 區(qū)分議題類型

有了 Label 區(qū)分還不夠，對研發(fā)人員來說，需要一個視角去看這些 issue。研發(fā)團隊可以通過看板的方式進行 issue 管理，看板其實就是不同視角的視圖。企業(yè)內(nèi)，研發(fā)團隊、測試團隊還有產(chǎn)品團隊都應(yīng)該有屬于自己的看板。產(chǎn)品團隊關(guān)心的是任務(wù)的分配，所以有一張以研發(fā)工程師為視角的看板，比如張三在做需求A，李四在做需求B，這些都有一張看板；此外還有一張工作流看板，展示需求進行到什么階段。對于測試人員來說，只需要看到相關(guān) bug，不需要管在做什么，當然也可能會看一下看板，可以根據(jù)不同團隊的職責(zé)進行劃分。

圖示：看板Board 自定義議題視圖

如果用戶不清楚 issue 的提交方式，會導(dǎo)致 issue 管理困難。例如：

• 當用戶提交 issue 后，沒有分配人員來跟進，那它就被擱置了；
• 或者用戶不清楚該打上什么樣的標記，是 bug 還是功能，導(dǎo)致 issue 分類混亂。

使用triage 機器人可以輕松解決這些問題。當用戶提交了一個 issue 后，這個行為被機器人捕獲到，它會立即在這個 issue 下添加一條評論，并且發(fā)郵件告知創(chuàng)建人應(yīng)該打上 type。當用戶打上 type 后，機器人又會隨機從測試人員中選擇一位，把他加到這個 issue 的指派人里，跟進這個 issue。通過這種方式可以很好地把 issue 管理起來。

圖示：機器人Triage 自動處理Issue/MR

在項目之初和完成之后，可以使用里程碑來對項目進行規(guī)劃和回顧。以下圖極狐GitLab 15.1 的燃盡圖為例：

圖示：里程碑Milestone 迭代規(guī)劃與回顧

不過，這個燃盡圖并不是理想的燃盡圖，因為它并不貼合參考線。在整個迭代周期的第一周，研發(fā)人員開始處理需求的時候，會發(fā)現(xiàn)有些需求描述得不是很清楚，導(dǎo)致評估內(nèi)容增加，或者說有一些新的需求會引進來，所以這個曲線在第一周的時候甚至有點上揚。前兩周集中進行開發(fā)，這時并沒有開始大規(guī)模測試，所以曲線比較平緩。兩周后，主要功能都完成測試，開始介入大規(guī)模測試，這時又會發(fā)現(xiàn)一些 bug，所以曲線又有一些向上的波動。兩、三周之后，這個曲線開始急劇下降。

汽車行業(yè)

當然，如果是汽車行業(yè)關(guān)注V模型，可以考慮MappingSpace這樣的行業(yè)化工具，其針對汽車行業(yè)獨創(chuàng)性的開發(fā)了很多行業(yè)化的工具，方便企業(yè)以更優(yōu)雅的方式工作同時，也可以更方便的通過特定的行業(yè)認證。

圖示：MappingSpace對V模型的支持示意

更多請閱讀MappingSpace官方文檔。

圖示：MappingSpace對V模型的支持實際效果

總結(jié)

項目管理工具的使用并無絕對的排他性，在某些場景下搭配使用可以起到更好的效果。比如極狐GitLab的項目管理工具不能夠滿足一些特定的需求時，或者當參與項目管理的人員種非技術(shù)人員和程序員人數(shù)占比旗鼓相當時，此時面臨的選擇會有多種：

• ? 遷就非技術(shù)人員。僅僅使用與代碼管理孤立的項目管理工具(注：下圖中藍色部分)，會導(dǎo)致項目管理和代碼管理的嚴重割裂，即，項目管理視圖下無法直接提現(xiàn)代碼開發(fā)的工作進度。
• ? 遷就程序員。僅僅使用極狐GitLab作為項目管理工具(注：下圖中橙色部分)，非技術(shù)人員使用門檻相對較高，甚至產(chǎn)生排斥心理。
• ? 各取所長，互補共生。把項目管理中的不涉及代碼開發(fā)工作的宏觀需求放在獨立的項目管理工具中，而與代碼開發(fā)強相關(guān)的技術(shù)需求，則由極狐GitLab管理。

圖示：典型的代碼強相關(guān)開發(fā)過程記錄

非技術(shù)人員無需知道技術(shù)實現(xiàn)細節(jié)，一般程序員也無需了解宏觀的非技術(shù)內(nèi)容。二者之間建立溝通的橋梁則由技術(shù)主管負責(zé)：

• 根據(jù)橙色完成狀態(tài)及時更新藍色狀態(tài)。
• 根絕藍色新需求，分解并創(chuàng)建技術(shù)實現(xiàn)。

圖示：項目管理工具的互補共生

當然，第三方項目管理工具如Jira也可以與極狐GitLab集成。集成完成后，只要Commit Message或者MR Description中包含對應(yīng)的Jira Issue ID，下圖所示即為`MKP-2`，則會自動在Jira側(cè)建立超鏈接。從而實現(xiàn)需求與開發(fā)過程的之間的映射。

圖示：極狐GitLab與Jira集成效果