背景

因?yàn)楣ぷ餍枰?，最近學(xué)習(xí)了Gitlab Flow的流程，感覺更適合真正做軟件研發(fā)的項(xiàng)目團(tuán)隊(duì)，主要面向交付物為代碼的這種場景，基本上都是圍繞著功能的需求分析、設(shè)計(jì)、開發(fā)、版本發(fā)布的敏捷式開發(fā)流程。
敏捷式開發(fā)模式強(qiáng)調(diào)程序員團(tuán)隊(duì)與業(yè)務(wù)專家之間的緊密協(xié)作、面對面的溝通（認(rèn)為比書面的文檔更有效）、頻繁交付新的軟件版本、要求有緊湊而自我組織型的團(tuán)隊(duì)、能夠很好地適應(yīng)需求變化的代碼編寫和團(tuán)隊(duì)組織方法，也更注重軟件開發(fā)中人的作用。
而我們這邊的項(xiàng)目一般是面向企業(yè)的駐場實(shí)施開發(fā)，一般甲方的項(xiàng)目管理需求都是基于瀑布式開發(fā)模式的要求，實(shí)施周期的各個階段需要有相應(yīng)的交付成果，且交付物不限于代碼，（需求文檔、設(shè)計(jì)文檔、程序代碼、測試文檔、上線方案等等）。敏捷式開發(fā)明顯不適用，最多就是基于整體瀑布式開發(fā)模式，局部以迭代式開發(fā)方式來推動項(xiàng)目主體部分的推進(jìn)。
同時(shí)，客戶類項(xiàng)目實(shí)施過程中，除了項(xiàng)目本身的工作，還有類似與客戶溝通、與第三方廠商溝通，甚至日常的加班、請假、住宿管理等等其他雜項(xiàng)任務(wù)，gitlab就更不能滿足實(shí)這類管理的需要了。
基于以上的思考，又研究了專門的項(xiàng)目管理軟件--zentoo（禪道）。

zentoo使用簡介（非常簡）

zentoo的安裝詳細(xì)可見另一篇文章：禪道本地部署安裝

zentoo是國產(chǎn)的開源項(xiàng)目管理軟件，是一款非常完備的項(xiàng)目管理軟件，覆蓋了項(xiàng)目管理的核心流程，能夠支持各類開發(fā)模式的管理流程。其開原版本身的功能已經(jīng)很豐富，且初始化就定義了一些角色的工作流程的建議，可以給我們很好的參考，如其“我的地盤”推薦的內(nèi)容：

我的地盤

zentoo的官網(wǎng)上提供了詳細(xì)的使用說明文檔，在里面有最簡單的使用方式介紹，也有進(jìn)階的比較復(fù)雜的使用流程講解。根據(jù)實(shí)際項(xiàng)目的特性，最簡的使用方式肯定是不適用的，但是也不必所有的禪道上的功能都用起來，畢竟這個工具是為了方便我們的項(xiàng)目管理，如果太復(fù)雜，項(xiàng)目成員和項(xiàng)目經(jīng)理花太多的精力來維護(hù)禪道上的內(nèi)容反而就得不償失了。
因此，我們基于禪道最簡單的用于項(xiàng)目任務(wù)管理的流程，結(jié)合實(shí)際情況做一下具體的項(xiàng)目管理過程設(shè)計(jì)，更多的功能隨著使用的深入再不斷的探索。

項(xiàng)目管理的目標(biāo)

項(xiàng)目管理目標(biāo)最重要的一點(diǎn)當(dāng)然是按期保質(zhì)的完成項(xiàng)目的上線和交付，但實(shí)際上除了這個目標(biāo)外還有一點(diǎn)附帶的就是讓項(xiàng)目團(tuán)隊(duì)成員在一個項(xiàng)目中獲得相應(yīng)的能力提升。
通常情況下，保證重點(diǎn)目標(biāo)都已經(jīng)非常困難了，所以另外的目標(biāo)往往就被忽略了，然后整個項(xiàng)目周期內(nèi)大家都是忙忙碌碌的一頓加班，項(xiàng)目上線后做個形式主義的總結(jié)后什么都沒留下，或者留下一些應(yīng)付公事的項(xiàng)目過程文檔，翻都懶得翻。
在不斷的項(xiàng)目實(shí)踐中提升自身產(chǎn)品和技術(shù)方案的價(jià)值，提升項(xiàng)目實(shí)施工藝水平，提升團(tuán)隊(duì)整體的技術(shù)水平和管理水平，對我們實(shí)施團(tuán)隊(duì)來說才是最重要的，而保證項(xiàng)目按期保質(zhì)交付是附帶的執(zhí)行目標(biāo)，如果能團(tuán)隊(duì)項(xiàng)目管理做的足夠好，項(xiàng)目質(zhì)量不敢說決對，至少有很大的保證。

項(xiàng)目管理的原則

我自己總結(jié)了幾個項(xiàng)目管理的原則，也包括對項(xiàng)目管理軟件的使用原則：

1. 項(xiàng)目管理以交付物為導(dǎo)向，以任務(wù)為管理單元，所有任務(wù)的最終目標(biāo)都是要有相應(yīng)的高質(zhì)量交付物并需經(jīng)過審核通過。
2. 項(xiàng)目之中人人平等，不管是日常作息安排、請假制度、加班制度、工作流程，制定過程征求意見，制定之后后每個人都要嚴(yán)格遵守。
3. 項(xiàng)目成員每天有必要的日常任務(wù)執(zhí)行情況的總結(jié)登記，但流程設(shè)計(jì)不能過于復(fù)雜，每天用于實(shí)現(xiàn)合理項(xiàng)目管理的工作平均耗時(shí)不超過30分鐘（可以更低，但不應(yīng)該低于10分鐘）。
4. 不以單個任務(wù)的完成情況評判工作能力，但階段性任務(wù)執(zhí)行情況應(yīng)能夠作為考評的依據(jù)，并能指導(dǎo)改進(jìn)。

項(xiàng)目角色分配

按照項(xiàng)目不同階段對人員的需求分配，實(shí)施類項(xiàng)目應(yīng)該包括以下幾類人員：
項(xiàng)目經(jīng)理、需求分析人員、系統(tǒng)設(shè)計(jì)人員、系統(tǒng)開發(fā)人員、系統(tǒng)測試人員等。
每一類人員可能根據(jù)所負(fù)責(zé)的模塊或者子系統(tǒng)不同再分組,并且每一類角色還有對應(yīng)的組長角色來分管,理論上的角色實(shí)在相當(dāng)多。
實(shí)際的情況是這種分類方法不太實(shí)用，不管你認(rèn)為合不合理，實(shí)際情況是除了模塊分組，每個項(xiàng)目成員在不同階段承擔(dān)不同的角色是非常正常的情況，因此從任務(wù)分配和執(zhí)行的角色分配上，我覺得只需要將人員分為以下幾類就可以了：

• 項(xiàng)目經(jīng)理（產(chǎn)品經(jīng)理）

1. 項(xiàng)目經(jīng)理負(fù)責(zé)推動項(xiàng)目各階段各項(xiàng)任務(wù)的分配和推進(jìn)執(zhí)行，對各階段的交付物進(jìn)行檢查和組織評審，還包括對項(xiàng)目實(shí)施期間日常管理工作的內(nèi)容，額外的還要面對各類甲方、乙方、第三方的工作扯皮工作，事情繁多瑣碎是重要特點(diǎn)。所以使用禪道這種項(xiàng)目管理軟件目的更多的是為了幫助項(xiàng)目經(jīng)理將項(xiàng)目的一些日常管理、任務(wù)追蹤、質(zhì)量檢查這些工作規(guī)范化、清晰化，更系統(tǒng)直觀便捷的了解到項(xiàng)目的進(jìn)展情況、項(xiàng)目成員的產(chǎn)出情況等，減少瑣事上的精力投入。

2. 實(shí)施類項(xiàng)目不太注重產(chǎn)品經(jīng)理的角色，基本上沒有專門的產(chǎn)品經(jīng)理人員設(shè)計(jì)產(chǎn)品的功能這種形式。大多數(shù)情況是由項(xiàng)目經(jīng)理來承擔(dān)產(chǎn)品經(jīng)理這個角色的職責(zé)，所以有時(shí)候像數(shù)據(jù)倉庫這種本身就偏重實(shí)施類的項(xiàng)目，在項(xiàng)目完成后也很難提煉出比較完備的產(chǎn)品，而一般項(xiàng)目做的好的話也只是作為參考的解決方案案例存在，這是題外話。

• 模塊分組組長（數(shù)據(jù)倉庫、分析應(yīng)用等等）

1. 分組按照項(xiàng)目模塊分組，承擔(dān)分組組長的角色需要負(fù)責(zé)對本模塊的任務(wù)分配、管理和審核工作，相當(dāng)于分組的項(xiàng)目經(jīng)理角色，分組任務(wù)的需求都是從項(xiàng)目經(jīng)理分配的需求中獲取到的，分組組長不能生成自己的需求。這主要是在一定程度上避免超越項(xiàng)目范圍的任務(wù)發(fā)生。
2. 項(xiàng)目經(jīng)理和各分組組長同時(shí)也具備任務(wù)執(zhí)行者的角色，比如在需求分析階段，需求分析的計(jì)劃制定和任務(wù)設(shè)計(jì)肯定是由項(xiàng)目經(jīng)理帶領(lǐng)各分組組長進(jìn)行的任務(wù)。
3. 項(xiàng)目總體需求、設(shè)計(jì)、測試等方案都需要分組組長負(fù)責(zé)各自模塊部分的任務(wù)，并最終由分組組長提交交付物給項(xiàng)目經(jīng)理以合并。

• 任務(wù)執(zhí)行者（需求分析、系統(tǒng)設(shè)計(jì)、模型設(shè)計(jì)、程序開發(fā)、測試等）

1. 具體任務(wù)的執(zhí)行者，沒有任務(wù)指派分配的權(quán)限，當(dāng)任務(wù)需要拆分或者變更負(fù)責(zé)人時(shí)，需要通知分組組長。
2. 任務(wù)的完成標(biāo)準(zhǔn)是有相應(yīng)的交付物并經(jīng)過了審核人員的通過。

禪道任務(wù)管理

項(xiàng)目初始化

一個新的項(xiàng)目啟動后，基于禪道初始化項(xiàng)目的信息，包括成員、產(chǎn)品、計(jì)劃、項(xiàng)目

1.創(chuàng)建權(quán)限、角色和用戶

如果項(xiàng)目成員來自多個成員,用來標(biāo)識項(xiàng)目組成員本身所屬的部門，部門屬于公司架構(gòu)的管理范疇。
部門一般會分多級部門。

部門創(chuàng)建

創(chuàng)建三個權(quán)限：項(xiàng)目經(jīng)理、分組組長和任務(wù)執(zhí)行者，其中任務(wù)執(zhí)行者只有任務(wù)視圖和部分查詢功能的使用權(quán)限；分組組長額外的有任務(wù)管理指派的功能，項(xiàng)目經(jīng)理有產(chǎn)品、需求的管理操作功能。

權(quán)限創(chuàng)建

用戶創(chuàng)建

2.創(chuàng)建產(chǎn)品

以數(shù)據(jù)倉庫類項(xiàng)目為例，可以簡單的將實(shí)施內(nèi)容分為以下幾塊：

• ETL工具
• 數(shù)倉架構(gòu)
• 數(shù)倉模型
• 數(shù)據(jù)服務(wù)

補(bǔ)充一個非實(shí)施內(nèi)容的雜項(xiàng)工作類：

• 項(xiàng)目支持

這部分包括會議、租房、組織活動、突發(fā)事件等其他事情的任務(wù)

補(bǔ)充一個項(xiàng)目文檔需求的類別：

• 過程文檔

這部分指在項(xiàng)目過程中規(guī)定的需要提交的交付物，其中的代碼部分為各個產(chǎn)品的production版本出來后打包的文件。

產(chǎn)品創(chuàng)建

3.創(chuàng)建項(xiàng)目并關(guān)聯(lián)產(chǎn)品

創(chuàng)建項(xiàng)目

創(chuàng)建項(xiàng)目時(shí)，關(guān)聯(lián)相應(yīng)的產(chǎn)品，這樣基于這些產(chǎn)品的需求就可以關(guān)聯(lián)到項(xiàng)目中去。在項(xiàng)目中不細(xì)分功能模塊，只針對需求分解任務(wù)。

4.添加項(xiàng)目團(tuán)隊(duì)成員

添加團(tuán)隊(duì)成員

然后進(jìn)入項(xiàng)目列表，選中該項(xiàng)目編輯開始這個項(xiàng)目。
禪道的項(xiàng)目的初始化基本就完成了。

工作流程

工作流程根據(jù)角色不同，所需要負(fù)責(zé)的內(nèi)容也不一樣。

項(xiàng)目經(jīng)理

項(xiàng)目經(jīng)理角色日常主要為確定需求、審核交付物成果，以及使用圖表統(tǒng)計(jì)功能檢查人員投入產(chǎn)出比以推動項(xiàng)目管理決策。

1.創(chuàng)建需求

項(xiàng)目經(jīng)理根據(jù)每個模塊（產(chǎn)品）的特定，制定相應(yīng)的需求，有一些需求時(shí)需要規(guī)劃交付計(jì)劃的，創(chuàng)建相應(yīng)的時(shí)間計(jì)劃，而有一些常規(guī)任務(wù)可以不用計(jì)劃來預(yù)估工作安排。

以過程文檔為例，過程文檔中需求分析階段需要有相應(yīng)的交付物-需求說明書，因此在過程文檔產(chǎn)品中創(chuàng)建相應(yīng)的需求：

創(chuàng)建需求

需求創(chuàng)建完畢后，在需求列表中可以對分組長進(jìn)行需求指派。
所有項(xiàng)目中的需求均由項(xiàng)目經(jīng)理來創(chuàng)建。
需求創(chuàng)建完成后，在項(xiàng)目視圖中對需求進(jìn)行關(guān)聯(lián)，需求關(guān)聯(lián)也可以讓分組組長執(zhí)行。

2.任務(wù)監(jiān)督

每日工作人員提交自己的任務(wù)工時(shí)后，項(xiàng)目經(jīng)理可以從任務(wù)的視角查看投入情況，以評估效率和工作飽和度：

任務(wù)檢查

也可以從人的視角查看每個人完成任務(wù)的多少：

成員視角

分組組長

分組組長接受指派的需求，對需求進(jìn)行分析后分解任務(wù)，并指派任務(wù)給本組的成員。

創(chuàng)建任務(wù)

任務(wù)創(chuàng)建完成后分組組長可以對其進(jìn)行修改調(diào)整，包括重新指派。

任務(wù)優(yōu)先級設(shè)計(jì)

禪道中默認(rèn)分了4個優(yōu)先級，我們簡單規(guī)定下：

正常排期任務(wù)都設(shè)定優(yōu)先級為3。

3.任務(wù)執(zhí)行者

分組組長完成任務(wù)指派后（或由任務(wù)執(zhí)行者自行創(chuàng)建任務(wù)），在任務(wù)列表可以查詢指派給自己的任務(wù)。

任務(wù)列表

任務(wù)執(zhí)行者點(diǎn)擊任務(wù)開始圖標(biāo)以開啟這個任務(wù)，任務(wù)開始時(shí)，需要對任務(wù)需要投入的時(shí)間進(jìn)行一個預(yù)估，記錄到剩余消耗時(shí)間中去。

之后每日或者完成時(shí)對任務(wù)的工時(shí)進(jìn)行錄入：

記錄工時(shí)

要求每個任務(wù)執(zhí)行者每日需要提交任務(wù)的投入時(shí)間和完成進(jìn)度，并且對還需要的時(shí)間進(jìn)行登記，最終任務(wù)完成需要填寫完成總耗時(shí)，以便看到預(yù)估和實(shí)際消耗的差別。
任務(wù)完成時(shí)，在完成備注中寫上該任務(wù)對應(yīng)的交付物的gitlab的合并編號和名稱。

gitlab交付物管理

團(tuán)隊(duì)協(xié)作方式參考文章gitlab使用詳解

在禪道中我們將項(xiàng)目按照模塊拆分成多個產(chǎn)品；

• ETL工具
• 數(shù)倉架構(gòu)
• 數(shù)倉模型
• 數(shù)據(jù)服務(wù)
• 項(xiàng)目支持
• 過程文檔

對應(yīng)的在gitlab中項(xiàng)目團(tuán)隊(duì)下也建立多個project

gitlab團(tuán)隊(duì)+項(xiàng)目

每個project會包含文檔和代碼兩部分，目錄結(jié)構(gòu)由項(xiàng)目負(fù)責(zé)人來統(tǒng)籌規(guī)劃，其他成員只需要clone后按照要求提交交付物就可以。

分支設(shè)計(jì)

每個porject分支創(chuàng)建主要依循以下規(guī)則：

1. 主分支master為實(shí)時(shí)最新版本，所有成員的合并請求都提交到master分支
2. release分支為發(fā)布版本分支，發(fā)布版本分支包括評審分支（文檔評審、代碼評審）、sit測試分支、uat測試分支、投產(chǎn)分支。
3. 多輪評審、測試情況下，每次評審和測試前都發(fā)布一個release分支，賦予版本號
4. backup 備份分支，每周備份，保留近三周備份分支

項(xiàng)目開發(fā)人員只需要按照流程要求向master主分支提交合并申請，項(xiàng)目負(fù)責(zé)人負(fù)責(zé)對合并內(nèi)容進(jìn)行審核以及創(chuàng)建各類分支。

交付物開發(fā)

參考文章gitlab使用詳解，項(xiàng)目成員使用fork方式，fork各個項(xiàng)目的master分支，然后clone到本地，使用git命令來提交自己所做的內(nèi)容到fork后自己的分支之中，然后提交merge請求到項(xiàng)目負(fù)責(zé)人，由項(xiàng)目負(fù)責(zé)人來審核通過。

實(shí)踐經(jīng)驗(yàn)補(bǔ)充調(diào)整

在實(shí)際的使用過程中對原有的流程做了一定的調(diào)整，主要是在權(quán)限方面縮小功能范圍，讓整個禪道的使用更專注的圍繞著“任務(wù)管理”這個目標(biāo)來開展：

1. 調(diào)整界面視圖權(quán)限
   對項(xiàng)目經(jīng)理角色，只保留產(chǎn)品、項(xiàng)目、統(tǒng)計(jì)、后臺這幾項(xiàng)一級菜單視圖，其他的都在權(quán)限管理中屏蔽掉。

   
   
   項(xiàng)目經(jīng)理視圖

對分組組長和研發(fā)人員角色，都只保留項(xiàng)目視圖，讓他們只專注于任務(wù)，使用起來更簡單直觀。

分組組長視圖

工作者視圖

2. 對產(chǎn)品制定明確的計(jì)劃和需求
   在之前的流程中直接跳過計(jì)劃環(huán)節(jié)，采用需求管理任務(wù)的方式，實(shí)施過程中發(fā)現(xiàn)對需求的階段定位和管理都比較混亂，因此還是需要制定明確的計(jì)劃

   
   
   產(chǎn)品計(jì)劃視圖

制定完計(jì)劃后，由項(xiàng)目經(jīng)理負(fù)責(zé)所有需求的創(chuàng)建和管理過程。
分組組長只負(fù)責(zé)對需求進(jìn)行確認(rèn)并創(chuàng)建、修改、指派、完成、取消、關(guān)閉任務(wù)。
研發(fā)人員只能創(chuàng)建、完成任務(wù)，不能指派他人或者關(guān)閉任務(wù)。

經(jīng)過這番改造后，對項(xiàng)目組成員的任務(wù)登記流程變得明確清晰，事后的統(tǒng)計(jì)分析也比較好做。

對任務(wù)情況進(jìn)行數(shù)據(jù)分析

禪道自帶的統(tǒng)計(jì)報(bào)表經(jīng)過檢查發(fā)現(xiàn)不能滿足使用要求（有可能是因?yàn)闆]有完全按照它設(shè)定的方式使用導(dǎo)致的），這樣有些統(tǒng)計(jì)數(shù)據(jù)需要自行去解決，比如人員每日的工時(shí)投入，這個在報(bào)表里就看不到。
于是我整理了獲取一些統(tǒng)計(jì)數(shù)據(jù)的方法，內(nèi)容如下，可做參考：

執(zhí)行完成后，可以在服務(wù)器tmp目錄下獲取這些csv表格，通過這些數(shù)據(jù)可以對項(xiàng)目成員任務(wù)投入、完成效率、空閑情況做出一個比較直觀的結(jié)果。當(dāng)然，實(shí)際數(shù)據(jù)效果相當(dāng)依賴于項(xiàng)目經(jīng)理平時(shí)對項(xiàng)目成員任務(wù)登記的嚴(yán)格要求，否則其統(tǒng)計(jì)結(jié)果可能偏向于大部分都是空閑的狀態(tài)，完成任務(wù)稀少，那就很尷尬了。所以即使有工具的幫助，項(xiàng)目經(jīng)理還是要勤快一些，敦促項(xiàng)目成員規(guī)范的完成自己的工作。