Jira & Confluence 在敏捷轉型中的重要性

640?wx_fmt=png

Atlassian 產品的設計理念

640?wx_fmt=jpeg

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

640?wx_fmt=png

爲了讓大家更好的理解,我們假設一個場景:

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

 

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

 

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

 

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

 

640?wx_fmt=png

我們來看一下這裏的幾個問題:

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

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

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

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

 

  • 去中心化和共享:雖然小趙是需求文檔的原作者,但是由於Confluence是基於Wiki精神設計的,小趙發表初版後,任何干系人都可以直接對內容進行修改和貢獻。而Confluence會自動記錄每一版的修改,隨時可以回退到任何一個版本。

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

我們一起來看一段利用Confluence進行團隊協作的視頻:

而 Jira 也有類似的設計。

 

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

640?wx_fmt=png

善用敏捷思維運用工具

640?wx_fmt=jpeg

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

 

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

 

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

 

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

 

那怎樣使用 Jira 和 Confluence 纔是正確的呢?我在這裏總結了一些使用原則:

- Jira 的使用原則

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

 

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

 

  • Epic - 史詩故事:包含某個特性或子項目的相關用戶故事,便於用戶故事歸組。

  • Story - 用戶故事:其中一種Issue的類型。這裏強烈建議用戶故事是具有一定業務價值、可單獨交付、最小的需求。

  • Sub-task - 子任務:用戶故事下需要分配給不同人處理、可單獨交付的的子任務,比如前端開發與後端開發,上、下游組件開發等。

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

640?wx_fmt=png

 

如果一個 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 強大的靈活性和對延後決策的完美支持

640?wx_fmt=jpeg

 

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

 

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

640?wx_fmt=png

640?wx_fmt=png

640?wx_fmt=png

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

640?wx_fmt=png

 

- Confluence 的使用原則

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

 

640?wx_fmt=png

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

640?wx_fmt=jpeg

640?wx_fmt=png

由於 Confluence 具有強大的靈活性,文檔所處的位置可以通過 Move 功能隨意移動,不建議花太多時間設計文檔間的關係

 

在去中心化的原則下,每個人都可以貢獻內容,所以 Confluence 的文檔體系建立一定是自底向上的,這不可避免地會帶來文檔的碎片化和內容的重複建設。但不必對此過於擔心,其實互聯網也是這樣的,我們不還是活得好好的,能通過互聯網獲取到我們所需要的信息嗎?強大的搜索功能可以幫助我們找到需要的內容。

 

善用標籤,也就是在編寫某類文檔有加上相應的關鍵字做標籤,然後通過標籤把相應的文檔聚合在某個地方,方便查閱,是更高效的方法。

 

- Jira 與 Confluence 的實時互動

全球 76% 的客戶表示,將這兩種產品相結合可以幫助他們更快交付項目!我們一起來看一段視頻:

只要把某個 Jira Issue 的鏈接地址貼到 Confluence 頁面裏,該 Issue 的標題和實時狀態會自動顯示在 Confluence 頁面中。

640?wx_fmt=png

 

我們建議把項目中相對靜態的信息,如項目的整體框架或者從項目拆分到特性等內容放在 Confluence 中。

 

然後把對應的比較動態的具體工件通過 Jira 來追蹤,然後把 Jira Issue 的鏈接放在 Confluence 頁面中,建立兩者的對應關係,整個項目的脈絡,一目瞭然。

 

而且在 Jira 中的狀態更新在 Confluence 頁面中也能實時反映。或者通過 Confluence 的表格功能建立用戶故事地圖,然後把生成的用戶故事通過 Jira 記錄,並把鏈接放在 Confluence 裏的地圖細節中。

簡單來說,就是靜態的內容放 Confluence,動態的內容放 Jira,並把兩者鏈接起來。

我們不時需要給客戶提交項目報告。過去,我們需要手動整理這些信息,費時費力。通過這兩大利器,我們可以輕鬆構建實時的報告和儀表盤,只消一次搭建的功夫。

 

我們可以在 Confluence 中把整個 Jira 列表引入,列表的內容可以通過 JQL 靈活設定。也可以把列表轉換爲圖表,建立可視化很強的儀表盤。

 

640?wx_fmt=png

640?wx_fmt=png

敏捷轉型是思維轉型

640?wx_fmt=jpeg

最後我想強調的是,敏捷轉型是思維轉型。我們需要:

 

  • 深入理解敏捷價值觀——在前文提到“去中心化、集體討論、信息共享、靈活、透明、可視化”等原則纔是敏捷轉型的思想武器;

  • 運用具體實踐和工具落實敏捷價值觀——JIRA和Confluence可以幫助我們踐行敏捷原則和價值觀;

  • 持續回顧與改善——沒有放之四海而皆準的方法,通過針對具體交付問題的持續回顧、總結,才能幫我們找到最合適自己的方法和工具。

關於作者

640?wx_fmt=jpeg

劉 華 (Kenneth)


  • 就職於世界500強銀行,負責基金服務業務軟件開發與交付,DevOps團隊負責人

  • 敏捷、精益、DevOps專家

  • 精通極限編程、Scrum、看板方法、測試驅動開發、持續集成、行爲驅動開發、DevOps工具棧

  • 曾在GDevOps、DevOpsDays Meetup、中國軟件技術大會、ArchSummit等論壇發表主題演講

  • 著有《獵豹行動:硝煙中的敏捷轉型之旅》一書

640?wx_fmt=png

小說體敏捷/DevOps轉型教科書

和實戰經驗分享

購書指南

紙質書、電子書在京東噹噹亞馬遜、微信讀書等渠道已全面上架,搜索關鍵字“獵豹 敏捷”即可找到。

有聲書已登錄喜馬拉雅、微信讀書,適合路上聽書的你。

關注公衆號看其他原創作品

640?wx_fmt=jpeg

覺得好看,點個“在看”或轉發給朋友們,歡迎你留言

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章