多人員參與問題

產(chǎn)品某一個業(yè)務(wù)功能的實現(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。

1. Group是一個容器，里面可以包含子Group和Project

2. 產(chǎn)品研發(fā)參與的人員和角色可以在group中定義、也可以在project中定義，會有繼承關(guān)系。

   例如：groupA下有projectA， groupA的參與人員有memberA，角色為guest，依據(jù)繼承，projectA中的參與者也就會有memeberA

3. 在Project中創(chuàng)建issue，可以在分組目錄通覽

有了上面的知識后，開始解決某一業(yè)務(wù)功能多人參與的問題，步驟如下：

1. 一個產(chǎn)品對應(yīng)一個根Group，分別建立前端、后端、android、ios對應(yīng)的子分組
2. 產(chǎn)品所有的研發(fā)人員加入到根Group中，角色為Guest，前端、后端、android、ios人員分別加入到對應(yīng)的子分組中，角色為Developer
3. 在前端、后端、android、ios等子分組中建立對應(yīng)的Project（private或internal的）
4. 在每個子分組的Project中為這個業(yè)務(wù)功能分別創(chuàng)建issue，因為這些issue是為了解決同一個業(yè)務(wù)功能，issue描述的業(yè)務(wù)功能內(nèi)容會相同，但是這些issue在每個分組中又會有所區(qū)別，例如前端會關(guān)注界面的樣式、內(nèi)容，后端會關(guān)注接口的邏輯和數(shù)據(jù)接口，在issue中描述要體現(xiàn)出來。

有了這幾步操作，貌似并沒有解決掉各個分組的研發(fā)人員需要交流溝通的問題。這里采用如下方式解決：

在根Group建立一個general project（public的），里面存放所有的設(shè)計文檔、接口文檔、原型和UI圖。這個project是產(chǎn)品組每個成員都可看到的，這樣通過這些文檔就達(dá)到了溝通的目的。當(dāng)然，這樣做的一個約束（算不上缺點）就是需要設(shè)計、文檔、UI圖先行。這樣也就能更好的規(guī)范了開發(fā)流程，解偶了各個開發(fā)人員之間的依賴關(guān)系，整體結(jié)構(gòu)如下圖：

image.png

總結(jié)：同一業(yè)務(wù)功能，不同類型的開發(fā)人員都有自己對應(yīng)的group、project、issue，這些開發(fā)人員通過根project中的文檔、UI進(jìn)行交流溝通。對于同一issue，同一組中多個人員參與的話，只需在issue comment中@相應(yīng)的人員即可

約束總結(jié)

根分組project維護(hù)的目錄結(jié)構(gòu)如下：

1. phone目錄：存放移動端相關(guān)文檔和設(shè)計圖

   origin: psd原圖

   prototype: 原型文件

   sketch:效果圖

   document存放文檔

2. web目錄：存放web端相關(guān)文檔和設(shè)計圖

分組中維護(hù)的issue類型：

1. 子分組Project中只維護(hù)如下類型的issue

   1. 業(yè)務(wù)功能：例如查車、綁車
   2. 軟件功能：例如友盟、版本設(shè)計
   3. bug

2. 根分組Project中主要維護(hù)的issue類型包含：

   1. 產(chǎn)品新想法
   2. 新需求

通過根分組中的issue定義產(chǎn)品里程碑，開展產(chǎn)品的迭代。根據(jù)子分組中的issue定義包的里程碑，開展軟件的迭代

Issue標(biāo)簽規(guī)范

1. 領(lǐng)域相關(guān)

   • area/android android相關(guān)
   • area/ios ios相關(guān)
   • area/backend 后端相關(guān)
   • area/frontend 前端相關(guān)

2. 優(yōu)先級相關(guān)

   • priority/P0 十分緊急（必須放下手中的工作立刻修復(fù)）
   • priority/P1 較為緊急（完成手中目前的階段性工作，開始此項）
   • priority/P2 普通（完成手中所有p1的階段性工作，開始此項）
   • priority/P3 不緊急（沒事干的時候，開始此項）

3. 研發(fā)issue類型

   • kind/dev bug bug類型
   • kind/dev enhancement 改進(jìn)項
   • kind/dev feature 新功能

4. 研發(fā)進(jìn)度issue類型

   • open（issue board自帶）
   • progress/dev doing 開發(fā)中
   • progress/dev done 開發(fā)完成
   • progress/dev schedue 下一步開發(fā)
   • closed（issue board自帶）

   通過里程碑標(biāo)識出已open的所有issue，團(tuán)隊站會時溝通將下一步要開發(fā)的issue標(biāo)識為dev schedue ，將正在進(jìn)行還沒有開發(fā)完成標(biāo)識為dev doing，開發(fā)完成的標(biāo)識為dev done，里程碑關(guān)閉后將相關(guān)的issue close掉。

5. 產(chǎn)品issue類型

   • kind/product idea（產(chǎn)品新想法：例如，增加藍(lán)牙無鑰匙進(jìn)入）

   • kind/product enhancement(產(chǎn)品已有功能改進(jìn)：例如，交互功能、指令功能)

   • kind/product feature(產(chǎn)品新功能)

     注：盡量杜絕研發(fā)完成后，交互、樣式、名稱等細(xì)節(jié)的修改，這些在設(shè)計階段確定完成（一步走穩(wěn)之后再走下一步）

6. 產(chǎn)品進(jìn)度issue類型

   • progress/product confirmed 已確認(rèn)（經(jīng)過討論）
   • progress/product desiging 設(shè)計中
   • progress/product developing 研發(fā)中
   • progress/product done 產(chǎn)品迭代完成
     后面這三種類型，需要同時指定迭代里程碑

   注：產(chǎn)品類型的issue需要由owner進(jìn)行review（原因：產(chǎn)品issue的提出可能是各種類型的人提供），入口比較雜，所以需要審閱。研發(fā)類型的issue不需要審閱，因為肯定是項目經(jīng)理錄入，入口可控。

7. 產(chǎn)品迭代和軟件迭代

   涉及到產(chǎn)品迭代，則創(chuàng)建根組里程碑；涉及到某一端的軟件迭代（例如android端3個apk），則創(chuàng)建子組里程碑；涉及到某一個軟件的迭代，則創(chuàng)建project里程碑

   軟件某一里程碑出現(xiàn)bug，在該里程碑中修復(fù)。小版本號升級

   產(chǎn)品里程碑v1.0
   軟件版本則可為v1.0.0，當(dāng)該里程碑的軟件發(fā)現(xiàn)bug并修復(fù)后，軟件版本可為v1.0.1

issue錄入模版

1. bug issue 錄入模版
2. 新需求錄入模版
3. 業(yè)務(wù)功能issue模版
4. 軟件功能issue模版
5. 產(chǎn)品亮點錄入模版

模擬演練

1. 錄入 產(chǎn)品新需求issue

   在根Group下的project中錄入

2. 根據(jù)產(chǎn)品新需求issue，出用例、出思維導(dǎo)圖，然后出原型，出效果圖

   在根Group下的project中錄入

3. 原型、設(shè)計文檔都已在根Group下的project創(chuàng)建好，android里程碑已定義好，增加該里程碑中的研發(fā)issue信息

   New issue -> 標(biāo)題、內(nèi)容 -> 標(biāo)簽打上：area/android, priority/P1, kind/dev feature, 里程碑指定為該里程碑， assignee指派給具體的人員