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

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

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

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

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

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

圖示：Jira典型視圖

圖示：Ones典型視圖

圖示：PingCode典型視圖

圖示：禪道典型視圖

圖示：TAPD典型視圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖示：機(jī)器人Triage 自動(dòng)處理Issue/MR

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

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

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

汽車行業(yè)

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

圖示：MappingSpace對(duì)V模型的支持示意

更多請(qǐng)閱讀MappingSpace官方文檔。

圖示：MappingSpace對(duì)V模型的支持實(shí)際效果

總結(jié)

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

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

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

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

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

圖示：項(xiàng)目管理工具的互補(bǔ)共生

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

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