《獵豹行動硝煙中的敏捷轉型之旅》的作者：劉華老師在10月19日的 Atlassian 社區日 | 廣州站的活動上跟我們分享了《Jira & Confluence 在敏捷轉型中的重要性》這個主題，並且他也把此次的分享寫成文章，希望和更多的小夥伴們一起共享和學習。

Atlassian 產品的設計理念

工欲善其事，必先利其器！今天，我們就來聊聊全球敏捷開發團隊普遍使用的兩大利器：來自澳大利亞的軟件企業 Atlassian 的 Jira 和 Confluence。其設計理念徹底地貫徹了敏捷開發所倡導的去中心化、協作、集體討論、信息共享、靈活、透明、可視化等原則。

為了讓大家更好的理解，我們假設一個場景：

假設小趙是負責需求分析的BA，她需要和項目干係人一起進行需求分析和確認。

按照過去的做法，小趙會用Word來組織一份需求文檔，然後通過郵件把文檔發給所有干係人收集意見。干係人也會通過郵件回覆意見。然後她又要把根據意見修改的版本發給所有干係人。由此會產生大量的郵件。

由於只有小趙掌握關於需求的全部和最新的信息，每次當某個干係人想要翻閱需求文檔時，由於不確定TA手頭上的版本是否是最新的，TA一定會找小趙再要一次。小趙需要不厭其煩地招呼這些主。

而且萬一小趙病了或者需要突然請假，需求分析和確認這件事情就會停滯下來，其他人也會抓狂。

我們來看一下這裡的幾個問題：

中心化管理：最全面和最新的信息只掌握在小趙一個人手上，她也成為需求分析這個事情的中心節點，一旦她這個節點出了問題，就會成為整個環節的障礙和瓶頸，其他人的工作也會受到影響；

信息沒有共享：信息全部通過郵件傳遞，不好翻閱和查找，除了小趙外，其他人都是兩眼一抹黑，無法確定自己手頭上的信息是否是最完整和最新的。

討論的收集：
意見都是通過郵件收集，小趙需要手動收集和整理，費時費力，其他人如果不看每一封郵件，也無法掌握所有人的意見。

但如果小趙是用 Confluence 工作的話，會怎樣呢？

去中心化和共享：雖然小趙是需求文檔的原作者，但是由於Confluence是基於Wiki精神設計的，小趙發表初版後，任何干系人都可以直接對內容進行修改和貢獻。而Confluence會自動記錄每一版的修改，隨時可以回退到任何一個版本。由於任何人都可以在Confluence上看到最新的內容，他們隨時可以看到最全面和及時的信息。小趙被徹底地解放了出來，即使她臨時無法上班，其他人都可以繼續討論、完善需求。

集體討論：所有干係人都可以通過Confluence的Comment功能對文檔內容進行討論、對話。所有人都可以很直接地查閱到全部討論內容。

而 Jira 也有類似的設計。

通過去中心化、共享和集體討論，可以減少瓶頸，賦能每個人都有足夠信息進行相應的工作，也使得過程變得透明，增加用戶/業務對交付過程的理解與信任，促進融合，共同實現項目目標。

善用敏捷思維運用工具

既然 Jira 和 Confluence 是基於敏捷原則和價值觀設計的，只有以敏捷思維來做事，才能善用這些工具。千萬不要把舊思維運用在這些新工具上

我們公司過去是用 Word/Excel+SharePoint，很多同事在使用 Confluence時，只是把它當成了 SharePoint 的替代品，把一大堆 Word/Excel 文檔以附件形式放在 Confluence 的頁面上。

雖然 Confluence 可以管理附件文檔，但這完全不是它的特長。

我們從RTC過渡到 Jira 時，也存在類似的情況。

那怎樣使用 Jira 和 Confluence 才是正確的呢？我在這裡總結了一些使用原則：

- Jira 的使用原則

：

在 Jira 裡面，所有的事項都統一叫做 Issue，而 Issue 可以定義 Issue 的類型，以映射我們真實工作工程的管理單元，比如它可以是 Story 代表用戶故事，它可以是 Test 代表測試用例，它可以是 Incident 代表生產環境故障等。不同的 Issue 類型也可以對應不同的工作流，以反映真實的工作過程。

Jira 是原生支持敏捷開發的。在敏捷開發中，有下面幾個層級：

Epic - 史詩故事：包含某個特性或子項目的相關用戶故事，便於用戶故事歸組。
Story - 用戶故事：其中一種Issue的類型。這裡強烈建議用戶故事是具有一定業務價值、可單獨交付、最小的需求。
Sub-task - 用戶故事下需要分配給不同人處理的子任務，不可單獨交付，比如前端開發與後端開發，上、下游組件開發等。

由於一個 Epic 包含若干個用戶故事（Story），在新建或編輯Story時，可以通過 Epic Link 的屬性把該 Story 指向一個已有的 Epic，從而建立兩者的隸屬關係。

如果一個 Story 需要拆分成任幹個任務交給不同人或團隊完成，可以在 Story 中新建 Sub-task 並分配給相應的人或團隊。Defect 也是一種 Sub-task。獨立測試團隊對某個 Story 進行測試時發現 Defect，應該在該 Story 下創建 Defect (Sub-task)，把兩者關聯起來。

在一個 Story 級別的 Issue 中，可以按“More”按鈕，然後按“Create Sub-Task”按鈕來新建 Sub-task。Sub-task 和 Story 級別的 Issue 是可以相互轉換的。所以即使一開始關係建錯了，也沒有關係。另外，Issue 類型可以通過 Move 功能隨時進行轉換。這也體現了 Jira 強大的靈活性和對延後決策的完美支持。

小結三者關係是 Epic 包含若干個 Story，Story 包含若干個 Sub-task。

我們可以在JIRA中做發佈計劃。在管理界面中，管理員可以根據發佈計劃定義 Version，包含發佈日期與發佈提要。在每一個 Issue 中，我們可以在 Fix Version/s 屬性中指定它將在哪個 Version 發佈。可以通過Releases頁面輕鬆發佈Release Note。

通過代碼版本控制軟件如 SVN、Git等的插件，只要在提交代碼時，提交備註（Comment）中包含JIRA Issue Key，相應的代碼提交信息也會顯示在Issue中，從而建立 Issue 與相應的代碼的可視關係。實現敏捷與 DevOps 裡倡導的可追蹤性。

- Confluence 的使用原則

Confluence 是基於 Wiki 精神設計的，任何人都可以對內容進行修改和貢獻。所以在建立 Confluence 文檔時，不必拘泥於一次寫對，持續地更新、修正恰恰符合“先完成、再完美”的敏捷原則。

我強烈建議大家在編寫 Confluence 文檔時，善用 Header 來對文檔進行結構化處理。Confluence 支持5級 Header，便於建立不同的章節和層次結構，配合目錄（Table of Content）功能，Confluence 會自動根據文檔的 Header 生成相應的目錄和書籤，便於定位某個章節。