筆者從 2020 年疫情爆發之前，一直從事後端開發工作。2020 年因為工作原因，加入了 SAP 一個代號為 Spartacus 的開源專案的開發團隊。這個專案是一個基於 Angular 的電商 Storefront 框架，其程式碼貢獻者來自全世界各個地區。

實際上，這個專案的開發工作由六個敏捷開發團隊組成，筆者是唯一一位來自 APJ 即亞太地區的開發人員。從此，我開啟了為期兩年多，一直持續到現在的遠端辦公生涯。

本文透過下列幾個方面，向大家分享筆者所在的開發團隊，在遠端辦公領域的經驗和團隊日常的遠端辦公，所使用過的一些工具。

目錄如下：

- 程式碼託管和專案管理：Github
- 即時通訊(文字版)：Slack
- 即時通訊(語音版，影片版，會議)：Microsoft Teams
- 知識管理：Atlassian Confluence

# 程式碼託管和專案管理：Github

我們專案的程式碼託管在這個 Github 倉庫上：https://github.com/SAP/spartacus

每當有新功能開發時，我們會建立名為 `epic/XXX` 的程式碼分支，待開發和測試結束後，將其合併到 `develop` 分支上。

![](https://img-blog.csdnimg.cn/img_convert/f72e484dbc338f6f58e01b68eff34fbf.png)

已有功能的缺陷修復，則使用分支 `fix/XXX` 來完成。對於新版本的釋出，使用 `release/XXX` 分支完成。

![](https://img-blog.csdnimg.cn/img_convert/a7ffbd94f7eeaf4285af732443279985.png)

透過定義這些分支的命名規範，身負不同型別開發任務的同事們，能夠在不同的分支上工作，彼此互不影響。

Github Pull Request 的 Code Review Web 介面，將程式碼修改前後的狀態，提出程式碼審查意見的 Reviewer 和提出程式碼審查的申請者所需的下一步修改等動作，完美地進行了封裝和呈現，使得不在同一辦公室的開發人員們，能夠在這些 Web 介面高效地進行程式碼審查工作。

下圖是我的同事在某處程式碼進行審查後提出的修改建議，修改建議包含修改後的原始碼，以及透過文字表達的該建議背後的考慮。
![](https://img-blog.csdnimg.cn/img_convert/e59635edf25eeb9ccbb7ab60ddd9fdbf.png)

Github 的缺陷(Issue)管理也是其一大亮點。

來自全球的 Spartacus 使用者和程式碼貢獻者，可以按照事先準備好的模板，給我們的程式碼倉庫建立 Issue. 這些 Issue 可以是現有功能 bug，也可以是新的功能請求。每個 Issue 可以分配一到多個標籤(Label)，用來標識該 Issue 的特徵，以及需要解決的領域問題。目前我們的程式碼倉庫有 7804 個已經關閉的 Issue，還有 702 個處於 Open 狀態。這八千多個 Issue，透過總共 534 種不同型別的 Label 來描述。

![](https://img-blog.csdnimg.cn/img_convert/684566e82363d889472a46d5c26bb38b.png)

每個 Issue 可以分配給一個專案(Project)，這個專案是 Github 提供的專案進度管理模組中的模型之一。在 Github Project Dashboard 裡，我們能清晰地看到分配到同一個 Project 的所有 Issue 列表，如下圖所示：

![](https://img-blog.csdnimg.cn/img_convert/7d52ec00d50e7097bfd22b521efc143b.png)

這些 Issue 可以分別被放置到名為 `To Do`，`In Progress`，`Code Review & Local`，`QA from Server After Merge` 的列之下。

每一次敏捷開發的 Sprint Planning Meeting 結束之後，開發團隊當前 Sprint 需要做的任務，以 Issue 的方式出現在上圖 Project 最左邊的 To Do 列之下。每天團隊的 Daily 例會上，大家透過 Microsoft Teams 軟體，撥入會議遠端參加，由 Scrum Master 在自己的電腦上使用分享桌面將 Github Project Dashboard 投影出來，其他團隊成員從 To Do 列表裡選擇自己當天要 work on 的 Issue.

一個 Issue 被某人領取之後，會從 To Do 列移至 In Progress 列。當開發人員完成該 Issue 需要的功能開發或者 Bug 修復，並完成本地測試之後，這個 Issue 從 In Progress 進入 Code Review & Local QA 狀態, 等待組內其他開發人員摘取，進行程式碼審查和交叉測試。當程式碼審查和交叉測試都由另一位開發人員完成之後，Issue 進入 QA from Server After Merge 狀態, 此時團隊的質量控制工程師(Quality Enginner) 就可以開始更高階別的整合測試了。

透過 Issue 關聯的 Milestone 皮膚，我們可以輕易監控一個 Project 的完成進度：

![](https://img-blog.csdnimg.cn/img_convert/24ef0d09d5dbc189e8c7c68e097adb85.png)

以上介紹了透過 Github 管理的 Issue 的一個典型生命週期，我們團隊正是透過這種方式實現的專案任務管理。儘管另一款收費軟體 Jira 也提供了更專業的專案與事務跟蹤管理功能，在任務工作量記錄，專案整體進度把控和任務執行明細顯示方面更為出色，但是 Github Project 也有其亮點，那就是對 Github Issue 和 Pull Request 的深度整合，後者更是我們這種開發人員來自全球各地，橫跨多個時區的全球化開發團隊所看重的特色。

# 即時通訊(文字版)：Slack

程式設計師每天除了編寫程式碼，提交程式碼和審查程式碼之外，免不了要和其他開發人員進行各種互動，比如討論技術問題，釋出組內公告，向其他成員求助等等。

如果是比較簡單的透過文字溝通即可解決的問題，我們團隊的成員傾向於在 Slack 這款軟體裡進行文字交流。

個人認為，同大家日常生活中使用的微信相比，Slack 在軟體開發領域的遠端團隊成員溝通中，有下列顯著的優勢：

## 1. 所有聊天記錄(包括文字和檔案)均持久化在伺服器端，便於查詢

很多使用微信群進行工作溝通的朋友都曾經抱怨過，微信群聊天記錄僅僅儲存在本地，很容易丟失。而 Slack 不存在這個問題，因為一條訊息(無論純文字還是包含了檔案)，一經傳送，就會儲存到伺服器端，並且 Slack 支援了強大的查詢功能。

下面是 Slack 的查詢視窗，我們可以看出，Slack 支援如下幾種查詢方式：

- Google Like 查詢，即在下圖放大鏡的圖示後，直接輸入查詢關鍵字
- 在指定的 Slack Channel 裡查詢，例如下圖的 `Find in ec-spartacus`, 意思是隻在名為 `ec-spartacus` 這個 Channel 裡搜尋
- 只搜尋指定型別的互動記錄，例如 Messages(文字互動資訊)，Files(檔案)，Channels(搜尋名稱包含輸入關鍵字的 Channels) 和 People (搜尋名稱包含輸入關鍵字的  Slack 使用者)

![](https://img-blog.csdnimg.cn/img_convert/92e724386abe8a57dfd985e7b5003c40.png)

以筆者為例，我是 2020年8月加入目前這個開發團隊的，使用 Slack 搜尋，筆者可以輕鬆定位到任意發生在 2020年8月之前的互動記錄：只需要在 Range 裡指定搜尋的起始和結束日期：

![](https://img-blog.csdnimg.cn/img_convert/28a1961f7f0277b71204e501810435a3.png)

就可以快速找到我需要查詢的包含某關鍵字的互動記錄：

![](https://img-blog.csdnimg.cn/img_convert/2f4922ceda61f606c12111824e08d195.png)

## 2. Slack 的文字訊息支援類似 Markdown 的語法，便於程式設計師交流

Slack 的文字支援加粗，斜體，刪除線，引用，插入程式碼等多種格式化選項，同純文字相比，這些格式化效果提高了開發人員閱讀文字資訊的效率。

![](https://img-blog.csdnimg.cn/img_convert/da9ee7535bdbf6a80f6da820d436ff65.png)

除此之外，Slack 的文字編輯器，支援種類豐富的 Emoji 表情符號，能給程式設計師每天單調的生活增添一絲亮色：

![](https://img-blog.csdnimg.cn/img_convert/40670326a0a7aa316869371092f3ec5c.png)

## 3. Slack Thread 對於基於文字的討論話題的高效組織

使用微信群討論工作問題的朋友都有這樣的苦惱：微信群裡的資訊流，沒有層次結構的概念，所有的資訊流都位於同一層級，因此很容易出現同一群裡，同一時刻有若干不同主題的討論同時發生的情況，群的使用者很難憑藉閱讀這些文字記錄，獲得每個不同主題的討論的上下文。

Slack 引入了 Thread 的概念，來高效管理一個 Channel 內不同主題的並行討論文字流。

一個 Thread 代表一個主題，可以包含一到多條文字資訊。一個 Thread 除了第一條原始文字資訊之外的其他文字資訊，稱之為 Reply. 當使用者針對 Thread 第一條文字訊息進行回覆時，這些回覆的訊息就稱之為 Reply，自動同 Thread 的第一條訊息關聯起來。

下圖是一個例子，螢幕左邊的區域顯示了兩條 Thread，分別包含 4 條和 7 條 Reply. 單擊每條 Thread，選擇 View Thread 選單項，可以在螢幕右邊的明細頁面區域裡，檢視該條 Thread 所有的 Reply.

![](https://img-blog.csdnimg.cn/img_convert/b42e6332e251f3e863cbb8c2c4464f94.png)

透過引入 Thread 和 Reply 這組具有類似父子包含關係的概念，Slack Channel 可以高效管理不同主題的文字討論。

## 4. Slack 開箱即用的眾多 App 和強大的擴充套件功能

在 Slack App 市場 https://slack.com/apps，能查閱眾多包含可以顯著提高遠端工作效率的開箱即用的 Slack App ：

![](https://img-blog.csdnimg.cn/img_convert/41976e18d7c9f6a528bf42ed82e9dbd6.png)

我們可以為 Slack Channel 新增這些現成的 App：

![](https://img-blog.csdnimg.cn/img_convert/f872d35372cfe7b1ea6b6d99e31fd1f5.png)

也可以自行開發符合團隊實際工作需要的新 App.

比如我們團隊目前在使用的一個自開發的 Slack App，如下圖所示。每當開發人員有新的程式碼提交，導致持續整合伺服器的 Central Build 失敗後，該 App 就會推送一條訊息到 Slack Channel 中，並且包含三個連結，分別指向失敗的構建，導致構建失敗的程式碼提交，和構建的歷史資訊。

有了 Slack App 這種即時的提示資訊，開發人員能夠避免手動去檢查構建狀態，從而能夠更快地對失敗的構建做出響應。

![](https://img-blog.csdnimg.cn/img_convert/d6c8411b7b7caee182eea5e77fbea2aa.png)

# 即時通訊(語音版，影片版，會議)：Microsoft Teams

對於遠端辦公的敏捷開發團隊來說，Daily Scrum，Planning Meeting，Review Meeting 這些會議都需要放到線上進行。另外，當開發人員遇到複雜度較高的問題，靠純粹的文字資訊討論難以解決時，也需要透過語音加上共享螢幕的方式來交流。

儘管 Slack 本身也提供了語音通訊的功能，但是對於線上會議，我們團隊最終選擇的是 Microsoft Teams 這款軟體。除了在不穩定的網路連線環境下，我們測試出 Teams 的表現優於 Slack 之外，我們可以使用 Teams 的Recording 功能，將重要的會議過程記錄下來，並以 MP4 的格式方便地進行匯出。這些會議的 Recording 對於新加入團隊的同事以及因為種種原因錯過了會議的同事非常有用。

![](https://img-blog.csdnimg.cn/img_convert/716c7f6ba1ef484ff4fe1df1fcf79ea6.png)

# 知識管理：Atlassian Confluence

Slack 裡的文字資訊流雖然搜尋起來非常方便，但是比較碎片化，不適合用來維護系統的、篇幅量較大的、圖文並茂的知識類文章。因此我們選擇了 Atlassian Confluence 用來搭建團隊 Wiki, 實現團隊的知識分享。

Atlassian Confluence 可以支援多使用者對文件的編寫，能夠方便高效地建立軟體研發過程中的需求文件、產品架構設計文件、專案管理文件、技術分享等文件。

其豐富的頁面控制元件，多種類別的開箱即用的模板，基於富文字和文件原始碼級別的編輯方式，使得開發人員和非技術人員都能夠編寫出專業的文件。
![](https://img-blog.csdnimg.cn/img_convert/e8e3492d8622055263156d6e557ffe23.png)

其版本管理和差異比較功能，即便在多個使用者分別對同一文件進行編寫的情況下，也能根據需要，輕鬆回溯出每一次修改的明細資訊：

![](https://img-blog.csdnimg.cn/img_convert/20898c9f7c1ce0f9f1cc1f2043ad5ccc.png)

![](https://img-blog.csdnimg.cn/img_convert/b9d405e6b249cc31f3f1f9b39ba5f643.png)

# 總結

本文透過筆者的實際工作經驗，分享了筆者所在的全球化軟體開發團隊，在遠端辦公這個領域，所使用過的一些工具和經驗。雖然由於疫情以及團隊成員所在地理位置的原因，開發團隊的成員們不能在同一間辦公室裡面對面地工作，但是感謝現代日新月異的 IT 技術，透過本文介紹的這些工具，即便遠端辦公，我們的開發效率也沒有受到太大的影響。

希望疫情能夠早日徹底結束，所有開發人員都能夠迴歸到疫情之前正常的開發工作中去。

一個 Angular 程式設計師兩年多的遠端辦公經驗分享

相關文章