多人員參與問題
產(chǎn)品某一個業(yè)務功能的實現(xiàn)會涉及到前端溯警、后端蛛倦、android、ios等多人員具壮，gitlab 企業(yè)版提供了issue有多個assignees的功能，但很可惜社區(qū)版是沒有這項功能的哈蝇。
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.
社區(qū)版如何解決此問題棺妓？
解決此問題之前，先介紹一下Group炮赦。
Group是一個容器怜跑，里面可以包含子Group和Project
-
產(chǎn)品研發(fā)參與的人員和角色可以在group中定義、也可以在project中定義吠勘，會有繼承關系性芬。
例如：groupA下有projectA， groupA的參與人員有memberA剧防，角色為guest植锉，依據(jù)繼承，projectA中的參與者也就會有memeberA
在Project中創(chuàng)建issue诵姜，可以在分組目錄通覽
有了上面的知識后汽煮，開始解決某一業(yè)務功能多人參與的問題，步驟如下：
- 一個產(chǎn)品對應一個根Group棚唆，分別建立前端暇赤、后端、android宵凌、ios對應的子分組
- 產(chǎn)品所有的研發(fā)人員加入到根Group中鞋囊，角色為Guest，前端瞎惫、后端溜腐、android、ios人員分別加入到對應的子分組中瓜喇，角色為Developer
- 在前端挺益、后端、android乘寒、ios等子分組中建立對應的Project（private或internal的）
- 在每個子分組的Project中為這個業(yè)務功能分別創(chuàng)建issue望众，因為這些issue是為了解決同一個業(yè)務功能，issue描述的業(yè)務功能內容會相同，但是這些issue在每個分組中又會有所區(qū)別烂翰，例如前端會關注界面的樣式夯缺、內容，后端會關注接口的邏輯和數(shù)據(jù)接口甘耿，在issue中描述要體現(xiàn)出來踊兜。
有了這幾步操作，貌似并沒有解決掉各個分組的研發(fā)人員需要交流溝通的問題佳恬。這里采用如下方式解決：
在根Group建立一個general project（public的）捏境，里面存放所有的設計文檔、接口文檔毁葱、原型和UI圖典蝌。這個project是產(chǎn)品組每個成員都可看到的，這樣通過這些文檔就達到了溝通的目的头谜。當然，這樣做的一個約束（算不上缺點）就是需要設計鸠澈、文檔柱告、UI圖先行。這樣也就能更好的規(guī)范了開發(fā)流程笑陈，解偶了各個開發(fā)人員之間的依賴關系际度，整體結構如下圖：
總結：同一業(yè)務功能，不同類型的開發(fā)人員都有自己對應的group涵妥、project乖菱、issue，這些開發(fā)人員通過根project中的文檔蓬网、UI進行交流溝通窒所。對于同一issue，同一組中多個人員參與的話帆锋，只需在issue comment中@相應的人員即可
約束總結
根分組project維護的目錄結構如下：
-
phone目錄：存放移動端相關文檔和設計圖
origin: psd原圖
prototype: 原型文件
sketch:效果圖
document存放文檔
web目錄：存放web端相關文檔和設計圖
分組中維護的issue類型：
-
子分組Project中只維護如下類型的issue
- 業(yè)務功能：例如查車吵取、綁車
- 軟件功能：例如友盟、版本設計
- bug
-
根分組Project中主要維護的issue類型包含：
- 產(chǎn)品新想法
- 新需求
通過根分組中的issue定義產(chǎn)品里程碑锯厢，開展產(chǎn)品的迭代皮官。根據(jù)子分組中的issue定義包的里程碑，開展軟件的迭代
Issue標簽規(guī)范
-
領域相關
- area/android android相關
- area/ios ios相關
- area/backend 后端相關
- area/frontend 前端相關
-
優(yōu)先級相關
- priority/P0 十分緊急（必須放下手中的工作立刻修復）
- priority/P1 較為緊急（完成手中目前的階段性工作实辑，開始此項）
- priority/P2 普通（完成手中所有p1的階段性工作捺氢，開始此項）
- priority/P3 不緊急（沒事干的時候，開始此項）
-
研發(fā)issue類型
- kind/dev bug bug類型
- kind/dev enhancement 改進項
- kind/dev feature 新功能
-
研發(fā)進度issue類型
- open（issue board自帶）
- progress/dev doing 開發(fā)中
- progress/dev done 開發(fā)完成
- progress/dev schedue 下一步開發(fā)
- closed（issue board自帶）
通過里程碑標識出已open的所有issue剪撬，團隊站會時溝通將下一步要開發(fā)的issue標識為dev schedue 摄乒，將正在進行還沒有開發(fā)完成標識為dev doing，開發(fā)完成的標識為dev done，里程碑關閉后將相關的issue close掉缺狠。
-
產(chǎn)品issue類型
kind/product idea（產(chǎn)品新想法：例如问慎，增加藍牙無鑰匙進入）
kind/product enhancement(產(chǎn)品已有功能改進：例如，交互功能挤茄、指令功能)
-
kind/product feature(產(chǎn)品新功能)
注：盡量杜絕研發(fā)完成后如叼，交互、樣式穷劈、名稱等細節(jié)的修改笼恰，這些在設計階段確定完成（一步走穩(wěn)之后再走下一步）
-
產(chǎn)品進度issue類型
- progress/product confirmed 已確認（經(jīng)過討論）
- progress/product desiging 設計中
- progress/product developing 研發(fā)中
- progress/product done 產(chǎn)品迭代完成
后面這三種類型，需要同時指定迭代里程碑
注：產(chǎn)品類型的issue需要由owner進行review（原因：產(chǎn)品issue的提出可能是各種類型的人提供）歇终，入口比較雜社证，所以需要審閱。研發(fā)類型的issue不需要審閱评凝，因為肯定是項目經(jīng)理錄入追葡，入口可控。
-
產(chǎn)品迭代和軟件迭代
涉及到產(chǎn)品迭代奕短，則創(chuàng)建根組里程碑宜肉；涉及到某一端的軟件迭代（例如android端3個apk），則創(chuàng)建子組里程碑翎碑；涉及到某一個軟件的迭代谬返，則創(chuàng)建project里程碑
軟件某一里程碑出現(xiàn)bug，在該里程碑中修復日杈。小版本號升級
產(chǎn)品里程碑v1.0
軟件版本則可為v1.0.0遣铝，當該里程碑的軟件發(fā)現(xiàn)bug并修復后，軟件版本可為v1.0.1
issue錄入模版
- bug issue 錄入模版
- 新需求錄入模版
- 業(yè)務功能issue模版
- 軟件功能issue模版
- 產(chǎn)品亮點錄入模版
模擬演練
-
錄入 產(chǎn)品新需求issue
在根Group下的project中錄入
-
根據(jù)產(chǎn)品新需求issue莉擒，出用例酿炸、出思維導圖，然后出原型啰劲，出效果圖
在根Group下的project中錄入
-
原型梁沧、設計文檔都已在根Group下的project創(chuàng)建好，android里程碑已定義好蝇裤，增加該里程碑中的研發(fā)issue信息
New issue -> 標題廷支、內容 -> 標簽打上：area/android, priority/P1, kind/dev feature, 里程碑指定為該里程碑， assignee指派給具體的人員
