【心得】軟件團隊Git工作流及Jira的基本知識和常見問題解釋

軟件團隊使用Jira的基本知識和常見問題解釋

前置知識

職位

軟件團隊中常見的職位

• PM (Project Manager)項目經理
• TL (Technical Lead or Team Lead)技術經理
• PG ( Programmer )程序員
• SE (Software Engineer)軟件工程師
• DBA (Database Administrator）數據庫管理員
• QA (QUALITY ASSURANCE）測試

在公司交流時一般都以職位簡稱表達，之后文檔我將以職位簡稱表達身份

以上是我們在軟件開發工作中經常打交道的角色,每個公司具體情況不同,稱呼可能有出入；其中SE和PG很多公司並不細分，因為軟件工程師也是程序員，多數情況下在工作上沒什么區別，非要理解的話，那么可以用SE不僅僅上寫代碼的人而是有追求的有工匠精神，關心的不僅僅是代碼還有軟件工程中的種種問題。其中QA很多公司也稱呼TE
另外注意項目經理和技術經理的區別,項目經理更多上在工作上的人事管理,負責團隊的工作安排,考核,甚至工作環境這類的管理.而技術經理是項目在技術上的直接負責人,起技術能力要求非常高,要求在軟件從設計、研究、開發、測試、部署整個的流程的所有技術細節皆要求掌握。比如選用什么框架，項目結構要求；在軟件公司中這兩個職位可能只存在一個而負責原本是兩個職位該做的事情，比如說PM同樣負責了項目的技術方向

流程

一個軟件項目的流程一般如下

1. 提出設想
2. 調研分析
3. 設計
4. 開發
5. 測試
6. 部署
7. 上線運營

普通程序員一般只參與開發、測試流程，越高級的技術或管理涉及的流程越多

新功能流程

在項目設計完成后，就進入開發流程了，每個項目又可以拆分成不同的模塊、功能，在團隊開發中在把這些模塊、功能細分下去交給各個PG開發，這一步由TL或QM負責。每一個功能又按下面的流程進行

Bug修復流程

這里很多人會誤解，QA測試如果有bug不是會打回開發重新開發嗎？注意！在正經的軟件開發流程中，程序員在編寫代碼時產生的錯誤不能稱之為Bug，這里的bug指的是對於當前項目來說的bug；也就是說，在你開發一個功能時，只要你的代碼沒有提交到團隊的代碼倉庫，你產生的錯誤僅僅是你的錯誤,而不是項目工程的bug，QA難免會出錯，在審查你的代碼時不能做到面面俱到，當項目倉庫的代碼或生產環境的代碼運行出了錯誤，那才是我們這里要說的bug。這里討論的bug一般是QA、TL或者其他PG在拉取了倉庫的代碼運行時或生存環境發現的錯誤，將在額外的工作流程中提出並制定PG去解決，一般是負責這個bug代碼的PG去修復

bug的修復流程和上面的新功能開發流程類似，就不再列出了

Git

介紹

git相信大家已經了解了，但是在商業項目團隊開發中，為了便於管理，同樣對Git的使用做了要求

請知悉以下Git常見操作

1. 拉取：從倉庫拉取權限允許的分支代碼
2. 提交：將本地的修改結果提交到本地倉庫
3. 推送：將本地倉庫某條分支的內容推送到遠程倉庫的同名分支上
4. 拉取請求：請求將某條分支（源分支）的代碼合並到另一條分支（目標分支）上，將由目標分支的審核者審核是否同意合並

目前主流的Git管理方案是工作流方案，什么是工作流？以上面的功能和bug修復的流程來說，就是一個工作流。一般的軟件項目在開發過程中，PG拿到一個任務，一般是功能、bug修復、改進這三項，針對這三項在工作中又有不同的流程細節，涉及到不同的職能分工。所以在Git倉庫中，對代碼的管理就有了新的要求

git一定要搞清楚，倉庫分為本地和雲端倉庫，雲端倉庫為團隊的公共倉庫，有權限的每個人都可以拉取一份代碼到自己的本地倉庫，在拉取下來之后，可以認為本地倉庫內容和雲端倉庫內容是一直的，你在本地修改的內容和雲端沒有關系，只要你不推送代碼到雲端，你就影響不了團隊的其他人~

以工作流而設計的分支模型

專業的Git工作流以分支作為管理，在倉庫中會存在以下分支

master
develop
release/
feature/*
bugfix/*
hotfix/*

• master

主分支，為保護分支，常駐只有一條，存放從release分支合並過來測試通過的穩定版本代碼,作為服務器部署運行的版本，除了TL或其他負責人一般為只讀，甚至有些團隊把該分支直接設置為不可見

• develop

開發分支，為保護分支，常駐只有一條，一般為倉庫的默認分支，除了技術管理層其他人只讀，存放最新的各個PG開發完畢初步測試通過合並過來的代碼，QA會根據自己的工作安排拉取該分支進行測試找出bug，其他的PG也可以拉取獲得最新的版本

• release/*

發布分支，為保護分支，暫駐存在多條，從develop分支創建，比如release/v1.0.3代表項目發布的1.0.3版本。除了技術管理層其他人只讀，存放項目准備部署到服務器上線的代碼，交給qa進行最高要求的模擬測試，這個分支允許我們做做后的細小更改。通過之后將合並到master分支正式發布，並在master分支上打tag標簽（比如：v1.0.3）便於記住這個版本，同樣也必須合並回develop分支。最終刪除該分支記住：在創建新的release分支准備發布時，該分支可能因為調試會存在一段時間，在此期間，bug的修復可能會合並到該分支而不是develop分支，該分支嚴格禁止增加新的feature！！

• feature/*

功能分支，暫駐可以存在多條，從develop分支創建，pm划分功能模塊交給不同的pg完成，每一個功能都會創建一條feature分支進行開發，比如feature/xxxx，xxxx為該功能在團隊內部的編號，pg可以自行創建該分支，擁有讀寫權限，在pg完成功能自測后，將推送該分支代碼到遠程倉庫，並發起pull request（和並請求）將該分支合並到develop分支，通過后刪除該分支

• bugfix/*

bug修復分支，暫駐可以存在多條，從develop分支創建，處理者可以自行創建擁有讀寫權限，后面帶的為bug的編號，交給pg修復，擁有讀寫權限，修復完畢后和feature分支一樣的處理方式。注意在release分支存在時（發布期間），bug的修復應該合並到release分支而不是develop，因為develop存在的bugrelease也有而release是准備發布了！

• hotfix/*

熱修復分支（緊急bug修復分支），暫駐可以存在多條，一般從master分支創建，處理者可以自行創建擁有讀寫權限。代表着線上版本出了問題，一般是非常緊急的，因為master正在運行，是處理優先級最高的分支，修復完畢將合並回master和develop分支，命名規范hotfix/xxxx,xxxx為內部bug編號

分支的寫權限表示可以推送到遠程倉庫

只讀意味着項目成員都可以拉取到自己本地倉庫，可以查看運行甚至修改,但是無法將自己的修改推送修改到雲端，

pull request：拉取請求，其實翻譯名不好理解，確切的來說應該叫做合並請求。表示將一個分支的代碼請求合並到另一條分支，將有目標分支管理員審核，記住，你可能沒有向目標分支發起合並請求的權限！

Jira

jira是一個以項目為核心以問題為驅動的工作流管理平台

我們知道了不同的功能或bug都以一個一個任務交給不同的人去處理，在團隊開發中，新功能由研發、客戶、領導等目標提出，bug一般由qa提出，那么，在一個團隊當中，我們不可能要求每一個提出需求的人當面或用其他方式告訴你：我要你做這個任務，溝通的成本是巨大的，甚至在大團隊中還考慮異地、時差、認不認識等問題，而且，在考核工作時，我們又怎么知道：當初是誰提出需求又是交給誰處理了？又是誰審批的？花了都長時間？當時的細節？如果我們要解決上面的問題，難以避免的需要划分大量的人工去記錄，還不能保證正確性。那么，jira就是為了記錄工作流而存在的

以問題為驅動的工作流程

什么是問題？功能，是一個待解決的問題，bug，也是一個待解決的問題。所有中出現需要人去處理的事情，都是問題，只是名稱而已，

一個問題在工作中應該經歷這樣的最基本流程

考慮到現實的復雜情況，流程可能更復雜

建議好好結合現實情況，上面的流程是不奇怪的，看不懂的同學建議回家放牛 ，你不適合進入職場

我們再思考一下，在上面的每個流程中，由需要不同的人參與進來，不同的人還得在正確時機參與進來，這就是jira需要解決的問題

jira中的基本名詞概念

項目角色

現實軟件職場中存在不同的職位分工，那么，在jira系統中，同樣應該參照現實簡歷相應的模型，便於不同的用戶以不同的角色參與到項目的問題解決流程中

所謂的項目角色一定要記住，角色意味着權限，而這里叫做“項目角色”那么也就意味着這些角色要存在於項目的人員組成中，不是說把張三丟進pm中他就是項目經理了，而是屬於把張三先放進某個項目組，再賦予張三為這個項目的PM角色

問題類型

同樣現實工作中要解決的問題分為不同的類型，jira已存在以下問題類型

其中軟件項目中主要需要關注的問題類型有

• 新功能
• 故障
• 改進

這三種類型的問題幾乎全覆蓋了我們的工作內容

其中需要注意的類型

• 任務
• 子任務

這兩者字面意思很好理解，但是，我們軟件工程中的需求（功能，bug）不能稱之為任務嗎？是可以的的，但是，既然jira設計了既然單獨設計了，那么我們就應該換個角度理解，任務應該是開發過程中產生的不可歸為新功能 故障 改進 的問題,比如,pm叫pg張三去調試下服務器的環境,這也是屬於項目的正常工作內容,但不能歸為該三者只能歸為任務 。

下面的是什么鬼？

• epic
• 故事

emmmmmm，這只能說又是個文化差異的鍋了，epic中文譯名“史詩”，表示一個非常大量的工作，包含許多故事（story） ；故事又為最小單位的任務；那這不是和上面的任務類型沖突了嗎？，其實，我們應該這樣去理解。

epic在軟件項目中一般理解為客戶提出的一個大的需求，故事是從這個需求拆封出來更細小的需求，比如：張三找到你們團隊說：“我要做一個類似淘寶的平台”，那么，張三的“購物平台”就是一個需求（epic），經過細致研討，拆分出：瀏覽商品，搜索，購物，付款驗證，物流管理....這些小的需求（story）。注意，epic和story更多象征着在紙面上的理想需求，一個團隊不僅僅是存在開發人員，還有市場調研，設計，研發等等崗位，這些人不太參與項目代碼的具體實現，而他們的工作和討論更多是圍繞在epic和story上面，那么他們一樣是在jira系統中存在的，一個軟件項目，不僅僅是代碼就可以支撐的。回到剛才張三的故事，在團隊內部研討分析后我們決定截馬雲胡或者捅張三刀子開干，那么就着手建立項目開始寫代碼，那么這時候，一個個需求就真真變成需要實現的功能，過程中又回產生一個個bug，see？

反正我們程序員更關心前面三種就可以了，當然，不代表需求分析的時候你就不參與，不然的話，被掏屁股的就不僅僅是張三還有你了，不過，普通的碼農也未必能參與到設計層的

當然，完全可以在jira創建項目后自定義該項目的問題類型方案，添加自定義問題類型也可以，以上只是jira默認的軟件項目問題類型方案

工作流

什么是工作流？你可以回去看看之前提到的幾張流程示意圖，圖中一個問題從開始到完成的過程，就是工作流

jira可以自定義每個不同問題類型的工作流。怎么理解這句話？比如我們的新功能開發，從提出->分配->處理->審核代碼->測試->完成;這就是一個工作流,其中有些步驟可能回打回處理,審核又要求有管理權限的人參與,那么,定義這個過程,讓jira自動處理這個過程,在不同的階段可以讓正確的人參與進來.這就是我們定義工作流的意義

比如我為不同的4個類型定義了不同的工作流

那么拿新功能類型問題的工作流來說,每一個點代表了當前問題所處的狀態

我們在來看從"審查中"到"已解決"這步驟來看

可以發現,我要求必須是項目管理員或PM,TL才可以將問題的狀態從“處理中”轉換為“已解決”，說人話就是這三個角色才有審核的權限

還可以定制該行為產生的后果

有意思的是我還加了一個觸發器，當該問題（新功能）的相關分支被Git同意合並之后，自動執行這一轉換

新功能會創建feature分支進行開發，最終pg會請求合並該分支，從某種意義上來說，管理者同意了該分支的合並，也代表着通過了該問題的處理結果了

報告人

問題的提出者

一般是由PM，QA提出，只有一個人，可以被修改，在新建問題是，報告人就是新建問題的人（自己），但是也可以指定為其他人（一般不會，除非這個問題是被人提出而你只是記錄者）

經辦人

經辦人可以理解為問題分配給誰處理

表示問題的工作流中需要參與進來的人，問題的處理者絕對是經辦人，審核的領導也是經辦人，在提出問題時，可以不指定經辦人，因為，問題的提出者可能並不知道問題的會怎么處理，誰來處理，也就是說，在問題的不同狀態、階段，可以指定不同的經辦人

jira中的權限

在工作環境中，大家的所作所為都應該在自己的職責范圍之內，既不能發生瀆職行為也不是出現越權行為，那么，團隊所有的成員在jira系統中自然要和現實權限匹配，那么同樣需要在jira中搭建相應的權限模型

請記住，jira中以項目為最大標點，也就是說，所有的事情 圍繞着項目思考，角色、權限都是如此，好比一個人可能是一個項目的PG，也可能是另一個項目的QA；所有人都以自身的項目為最大目標，圍繞項目產生問題，在以每個人在這個項目中的不同角色參與問題的不同階段

首先項目的參與人員會在項目成員中添加進來並賦予不同的角色，表示他在項目中起到的作用

值得注意的是，一個人可以賦予多個角色，也可以一個用戶組為單位進來一起被賦予相同的角色

再給不同的角色在項目中賦予不同的權限

可以這么說，因為jira是以問題為核心驅動，所以，一般權限和問題修改，注意，權限可以賦予給一個或多個角色，也可以直接賦予某些用戶（指名道姓）或用戶組，一般不這么做，不好管理，畢竟人員是流動的，而身份一直存在於團隊

開始使用

創建問題

在開發團隊工作中，任何一個任務、問題都需要被記錄。這至關重要，在工作環境下團隊內的每個人的工作安排都關乎利益，不管是對老板還是員工都希望得到清晰明了公正的記錄，jira的問題系統在軟件團隊中尤其適用

注意，在jira中不是誰都可以創建問題，需要看權限，一般來說，管理發布任務，設計研發發布epic，技術管理發布功能，測試發布bug

以下是jira創建問題的表單

在創建一個問題的時候，一定要先想清楚以下幾點

• 問題是針對哪個項目的

• 簡短的問題概要

• 問題的類型

• 誰提出的（一般是自己）

• 清晰明了又不拖沓的描述

以上是一個問題必須的最基本信息，在jira中必須填寫

在創建問題時，如果需要，以下的點也是需要考慮的

• 問題是向誰提出的
• 問題的優選級(嚴重性)
• 屬於哪個模塊
• 屬於哪個版本？
• 預計解決這個問題需要多長時間
• 預計解決這個問題還剩余多少時間
• 這個問題什么時候到期
• 還關聯哪個問題？
• 和關聯的問題是什么關系？
• 關聯哪個epic
• 需要附件嗎
• 為這個問題打一個自定義的標簽

一些字段的解釋

經辦人

一般情況下，可以理解為處理這個問題的人，可以默認為空，默認值一般為項目負責人。記住，問題的解決是一個流程，在這個流程中問題會經歷好幾個狀態；

比如：開始、處理、審批、完成（關閉），這是一個最常見的基本流程狀態，假設張三提出了一個問題，在這個問題提出時他可能並不知道這個問題可能誰來處理。此時問題處於開始狀態，經辦人為空，李四接手了這個問題，問題進入處理狀態，此時經辦人為李四，李四完成后提交審批，問題進入審批狀態，審批這個處理結果的人是李四的領導王五，那么這個狀態下經辦人又變成了王五！

當然，有些團隊可能沒有嚴格按照要求來，經辦人一直是問題的處理者，這不是推薦的做法，另外jira的工作流是可以自定義問題切換狀態時切換經辦人的，只要定義好各個類型的問題的不同狀態的規則即可

模塊和版本

這個比較好理解，該問題屬於項目的哪個模塊？一個bug屬於哪個版本？

不過要注意，模塊需要jira的項目管理員設置，項目的版本也是

關於問題的時間問題

• 初始預估：解決這個問題從開始到結束的預估時間，可以修改
• 剩余的估算：這個要注意，假設問題預計2天完成，可能jira系統上記錄這個問題的時候，問題已經處理過一部分了花了1天時間，那么這個值就是2-1=“1d”；請注意，一般來說，在問題一開始設想的時候將應該在jira系統上創建而不是已經開始處理了在創建，所以，這個值一般和初始預估一致
• 到期日：也很好理解，表示這個問題在哪個日期之前一定要處理完成，雖然假設問題只需要1天完成，但是因為工作安排，可能這個問題會被擱置；那么這個值可能設置在未來的任何一個時間，但一般不會是明天，畢竟你懂得

關聯的epic和問題

首先結合上文之前說明

• 史詩鏈接：epic一般記錄的是需求，那么這個問題是屬於哪個需求的

以下連個字段要一起理解

• 鏈接的問題：這個問題可能和其他問題有關系，關系是什么？

• 問題：有關系的問題

關於問題之間個關系

1. blocks：當前問題影響了某個問題或者說當前問題導致了某個問題的產生
2. is blocked by：和上面相反，是某個問題引起了當前問題，或者導致當前問題不能修改
3. clones：某個問題和當前問題性質一樣
4. is clones by：：和上面相反 ，當前問題和某個問題性質一樣；emmmm，和上面的用哪個都一樣的意思
5. duplicates：某個問題和當前問題重復
6. is duplicates by:當前問題和某個問題重復
7. relates to：注意，這個很重要。表示當前問題和某個問題關聯，解決了當前問題另一個問題就不存在

問題的標簽

沒什么意義，一般打標簽是便於問題的整理

處理分配給我的問題

根據項目的權限設置和工作流以及問題當前的狀態，你能處理的選項各不相同

存在一個未分配的問題？

問題創建出來可以沒有經辦人字段，表示問題未分配，這種情況下，說明提出問題的人應該不知道這個問題交給誰處理，那么項目的管理者將應該負責分配一下該問題

工作日志

工作日志的記錄很重要，不是你在jira點擊開始處理就表示你在工作了，團隊可能會要求按周期、步驟記錄工作日志當做考核標准，這至關重要！

注意！！記錄工作日志應該按照周期，比如下班時，或按照完成步驟記錄，是在一個階段內容完成之后記錄！！！務必按照團隊的日志格式要求記錄！！

注釋

問題的評論，發布 評論點擊備注

改動記錄

一般記錄了問題的修改記錄

活動日志

包含改動記錄，還記錄了問題的流程記錄

問題的狀態

當前問題處於工作流的狀態

問題的解決結果

問題的解決結果，一般由工作流腳本自動改變