多人員參與問題
產品某一個業務功能的實現會涉及到前端、后端、android、ios等多人員，gitlab 企業版提供了issue有多個assignees的功能，但很可惜社區版是沒有這項功能的。
In GitLab Enterprise Edition, you can also select multiple assignees to an issue, making it easier to track, and making clearer who is accountable for it.
Consider a team formed by frontend developers, backend developers, UX designers, QA testers, and a product manager working together to bring an idea to market.
Multiple Assignees for Issues makes collaboration smother, and allows shared responsibilities to be clearly displayed. All assignees are shown across your team’s workflows and receive notifications (as they would as single assignees), simplifying communication and ownership.
Once an assignee had their work completed, they would remove themselves as assignees, making it clear that their role is complete.
社區版如何解決此問題？
解決此問題之前，先介紹一下Group。
Group是一個容器，里面可以包含子Group和Project
-
產品研發參與的人員和角色可以在group中定義、也可以在project中定義，會有繼承關系。
例如：groupA下有projectA， groupA的參與人員有memberA，角色為guest，依據繼承，projectA中的參與者也就會有memeberA
在Project中創建issue，可以在分組目錄通覽
有了上面的知識后，開始解決某一業務功能多人參與的問題，步驟如下：
- 一個產品對應一個根Group，分別建立前端、后端、android、ios對應的子分組
- 產品所有的研發人員加入到根Group中，角色為Guest，前端、后端、android、ios人員分別加入到對應的子分組中，角色為Developer
- 在前端、后端、android、ios等子分組中建立對應的Project（private或internal的）
- 在每個子分組的Project中為這個業務功能分別創建issue，因為這些issue是為了解決同一個業務功能，issue描述的業務功能內容會相同，但是這些issue在每個分組中又會有所區別，例如前端會關注界面的樣式、內容，后端會關注接口的邏輯和數據接口，在issue中描述要體現出來。
有了這幾步操作，貌似并沒有解決掉各個分組的研發人員需要交流溝通的問題。這里采用如下方式解決：
在根Group建立一個general project（public的），里面存放所有的設計文檔、接口文檔、原型和UI圖。這個project是產品組每個成員都可看到的，這樣通過這些文檔就達到了溝通的目的。當然，這樣做的一個約束（算不上缺點）就是需要設計、文檔、UI圖先行。這樣也就能更好的規范了開發流程，解偶了各個開發人員之間的依賴關系，整體結構如下圖：
總結：同一業務功能，不同類型的開發人員都有自己對應的group、project、issue，這些開發人員通過根project中的文檔、UI進行交流溝通。對于同一issue，同一組中多個人員參與的話，只需在issue comment中@相應的人員即可
約束總結
根分組project維護的目錄結構如下：
-
phone目錄：存放移動端相關文檔和設計圖
origin: psd原圖
prototype: 原型文件
sketch:效果圖
document存放文檔
web目錄：存放web端相關文檔和設計圖
分組中維護的issue類型：
-
子分組Project中只維護如下類型的issue
- 業務功能：例如查車、綁車
- 軟件功能：例如友盟、版本設計
- bug
-
根分組Project中主要維護的issue類型包含：
- 產品新想法
- 新需求
通過根分組中的issue定義產品里程碑，開展產品的迭代。根據子分組中的issue定義包的里程碑，開展軟件的迭代
Issue標簽規范
-
領域相關
- area/android android相關
- area/ios ios相關
- area/backend 后端相關
- area/frontend 前端相關
-
優先級相關
- priority/P0 十分緊急（必須放下手中的工作立刻修復）
- priority/P1 較為緊急（完成手中目前的階段性工作，開始此項）
- priority/P2 普通（完成手中所有p1的階段性工作，開始此項）
- priority/P3 不緊急（沒事干的時候，開始此項）
-
研發issue類型
- kind/dev bug bug類型
- kind/dev enhancement 改進項
- kind/dev feature 新功能
-
研發進度issue類型
- open（issue board自帶）
- progress/dev doing 開發中
- progress/dev done 開發完成
- progress/dev schedue 下一步開發
- closed（issue board自帶）
通過里程碑標識出已open的所有issue，團隊站會時溝通將下一步要開發的issue標識為dev schedue ，將正在進行還沒有開發完成標識為dev doing，開發完成的標識為dev done，里程碑關閉后將相關的issue close掉。
-
產品issue類型
kind/product idea（產品新想法：例如，增加藍牙無鑰匙進入）
kind/product enhancement(產品已有功能改進：例如，交互功能、指令功能)
-
kind/product feature(產品新功能)
注：盡量杜絕研發完成后，交互、樣式、名稱等細節的修改，這些在設計階段確定完成（一步走穩之后再走下一步）
-
產品進度issue類型
- progress/product confirmed 已確認（經過討論）
- progress/product desiging 設計中
- progress/product developing 研發中
- progress/product done 產品迭代完成
后面這三種類型，需要同時指定迭代里程碑
注：產品類型的issue需要由owner進行review（原因：產品issue的提出可能是各種類型的人提供），入口比較雜，所以需要審閱。研發類型的issue不需要審閱，因為肯定是項目經理錄入，入口可控。
-
產品迭代和軟件迭代
涉及到產品迭代，則創建根組里程碑；涉及到某一端的軟件迭代（例如android端3個apk），則創建子組里程碑；涉及到某一個軟件的迭代，則創建project里程碑
軟件某一里程碑出現bug，在該里程碑中修復。小版本號升級
產品里程碑v1.0
軟件版本則可為v1.0.0，當該里程碑的軟件發現bug并修復后，軟件版本可為v1.0.1
issue錄入模版
- bug issue 錄入模版
- 新需求錄入模版
- 業務功能issue模版
- 軟件功能issue模版
- 產品亮點錄入模版
模擬演練
-
錄入 產品新需求issue
在根Group下的project中錄入
-
根據產品新需求issue，出用例、出思維導圖，然后出原型，出效果圖
在根Group下的project中錄入
-
原型、設計文檔都已在根Group下的project創建好，android里程碑已定義好，增加該里程碑中的研發issue信息
New issue -> 標題、內容 -> 標簽打上：area/android, priority/P1, kind/dev feature, 里程碑指定為該里程碑， assignee指派給具體的人員
