Red Hat如何管理開發工作

本文要點

  • 要有勇氣選擇和發展適合你團隊的流程。
  • 看板可以用於高度分佈式的團隊,處理高度複雜的項目。
  • 看板可實現異步性並能很好地擴展。與Scrum相比,實現前者需要的資源更少。
  • 在看板的幫助下,你能專注於理解和改善你們的實際工作方式。
  • 啓用看板必須有工具鏈。我們很高興分享我們使用的:Overbård

由於爲Red Hat JBoss EAP規劃開發工作的難度越來越大,Red Hat決定引入看板,以使其開發流程更易管理,同時保持一個非常高的質量水平。在2019年敏捷希臘峯會上,Dimitris Andreadis介紹了他們如何在自己分佈式的團隊中引入看板,並解釋了爲什麼他們要開發自己的Jira插件來可視化工作狀態,以及如何向看板卡添加並行任務來簡化工作流程。

EAP團隊引入看板後,首先將他們流程的所有細節都映射到一個個看板狀態上。Andreadis說,在看板上可視化這些狀態後,所有人就有了一致的視角。他們使用連續流程優化了添加、合併或刪除狀態的過程。

由於標準Jira插件具有許多狀態和複雜的流程,所以很難用來可視化工作狀態。於是他們決定開發自己的插件,名爲Overbård,使他們能夠將所有內容都放在一塊板上,並使用過濾器來顯示出令人感興趣的信息。Andreadis說,這個插件還可以當場創建新視圖。

Andreadis提到,藉助看板,你可以完全尊重你們現有的流程、角色和團隊動態,捕獲和可視化進行中的工作狀態,然後對其進行迭代和持續改進。它使你處於一種持續自我完善的心態上。

InfoQ在2019年敏捷希臘峯會上的這次演講之後,採訪了Red Hat工程總監Dimitris Andreadis,討論了他們所面臨的問題、爲什麼決定選擇看板而非Scrum、如何引入看板、Jira插件Overbård如何幫助他們查看進行中的工作、在看板中使用並行任務的經驗,以及看板爲他們帶來的好處。

InfoQ:你們遇到了什麼樣的問題?

Dimitris Andreadis:Red Hat JBoss EAP(企業應用程序平臺)已經成爲了非常複雜的產品。結果,爲EAP新版規劃開發工作的任務也變得愈加複雜。在一次極端情況下,團隊在開發先前的次要版本功能時,還要開發下一個主要版本;那個主要版本的開發計劃持續討論了14個月,而需求還在不斷變化。但是,花更多精力來做規劃並不能改善最終結果;它並沒有讓我們變得更聰明或更準確。我們寧願花更多的時間去做事情而不是誇誇其談。當時我們面臨的主要問題就是這個。

此外,在某些情況下需求可能會被誤解或溝通不暢,等我們發現時已經是週期中較晚的時候了。我們必須找到一種方法來集體迭代需求,並確保每個人都知道要做什麼。某些情況下,在確定我們完全理解問題和建議的解決方案之前,我們甚至可以進行概念驗證。

最後,在如此龐大而分散的項目中跟蹤新版進度是非常困難的。不同的子團隊在處理多個組件時的並行操作太多了。沒有一種簡單的方法可以對當前狀態產生一致的視角,也沒有一個指派某人跟蹤進度的地方。自然,遵守商定的發佈日期也就更加困難了。

InfoQ:是什麼讓你們決定採用看板而非Scrum呢?

Andreadis:我們有一個大型的分佈式團隊,在特定領域設有小型子團隊,因此使用嚴格的Scrum設置來協調所有這些工作看起來很困難,而且成本很高。爲了使流程順利進行,我們需要創建六個或更多的Scrum團隊,上面還要有一個Scrums的Scrum,這意味着我們必須找到或創建同等數量的Scrum大師,並找到一種方法來將我們的一位產品經理複製成許多產品負責人。

這些子團隊由高度專業化的、通常資格較深的開發人員組成,他們對接自己的上游社區,並擁有經過多年發展而來的流程。我們不想改變他們久經考驗的流程。而且,我們還得讓同一個Scrum團隊中的成員們處理不同的領域。例如,處理安全和集羣工作的人們就沒什麼共同點;沒什麼理由將他們放在同一個Scrum團隊中。

最後,許多複雜的功能通常需要數週甚至數月的開發時間,而試圖在短衝刺內對它們進行細微管理是沒有意義的。沒有什麼顯而易見的方法可以將這些功能分解爲許多有意義的部分,也沒有一個“客戶”可以測試這些中間的交付成果。涉及到實現規範(例如Java EE 8)時,你的功能必須跟隨規範來走,完成一項是一項。

InfoQ:你們是如何爲EAP引入看板的?

Andreadis:逐漸地!第一步是識別你的實際流程,並嘗試將其映射到一個個看板狀態上。當我們談論狀態時,我們指的是“所有”狀態。不只是簡化的ToDo、Doing和Done。你要捕獲工作流的全部細節,這樣就能做到我所說的“深度看板”。說起來容易做起來難。經過多年開發的複雜產品的開發流程往往會嵌入到人們的思維中。其中很大一部分可能是部落知識。所以你一開始發現的事情可能不怎麼討人喜歡,但這不是看板的問題,這是現實。

之後,你可以在看板上可視化你的狀態,以便每個人都能看到相同的視圖。根據選擇的工具不同,這一步可能很有挑戰性,但重要的是你使用的工具應該與你的票務跟蹤器、JIRA、github或其他組件緊密集成。你要擁有一個唯一事實來源。想想看,看板就是你工作的可視化結果。

最後,在準確映射了初始狀態後,你就可以開始考慮優化方法了。例如,我們引入了一個新的分析階段,以確保產品管理/工程/質量檢查人員都認同對某個需求的解釋。另一個例子是,我們使狀態之間的過渡更加自由,以增強工作流中的並行性。

這基本上是一個連續的過程,因此重點在於一步一個腳印,不能急於求成,因爲你不想嚇到你的團隊,或給他們的生活帶來不必要的複雜性。重要的是,試着在每個點上解釋你要解決的問題,並與團隊達成一致的解決方案,因爲他們會使用這套流程,所以取得所有人的認同是很關鍵的。

InfoQ:你們開發了一個名爲Overbård的Jira插件。能否詳細說明它的作用,人們又該怎樣獲取它呢?

Andreadis:將工作流映射到看板狀態後不久,我們就遇到了麻煩,因爲狀態太多了(大約23個),並且我們找不到使用標準JIRA敏捷插件可視化它們的便捷方法。你甚至無法在屏幕上看到這些狀態。我們也看過其他工具,但我們不想在多個系統之間同步狀態,我們希望有唯一的事實來源,也就是我們的JIRA跟蹤器。

我們還希望將所有內容都放在一塊板上,並使用過濾器來顯示讓我們感興趣的信息,而不是要維護許多鏈接在一起的看板。過濾器和泳道在JIRA中非常靜態;它們必須手動設置,而在我們的情況下,我們想要更動態的東西,因爲我們有太多動態的事物了,我們希望能夠在現場創建新視圖。

沒能找到適合我們需求的工具後,WildFly/EAP Core開發人員Kabir Khan提出了一個想法,就是開發自定義的JIRA插件來解決這些問題;他也(非常成功地)扮演了版本協調者的角色。於是他順着這個想法走了下去,創建了Jibran,後來改名爲Overbård開源(注意:這是挪威語)。本質上,Overbård是其他常規JIRA項目之上的一個查看器。它使用一些有限的配置來知道應該從哪裏獲取信息以及如何可視化信息來創建看板。除此之外,其他所有狀態都從JIRA問題抽身出來了,因此這裏沒什麼奇妙的東西。

Overbård支持水平滾動和可摺疊狀態或狀態組,這樣就能處理許多狀態。它是完全動態的,並支持零配置的任意過濾方式。你創建的任何視圖都可以添加書籤,因此可以非常輕鬆地返回到它們上。而且它非常快,因爲它可以在服務器上緩存數據。它實際上是將項目問題加載到緩存中,這樣過濾就是即時完成的了。Overbård的確拯救了我們,併爲我們的敏捷轉型之旅提供了便利。

你可以從這裏免費獲取Overbård。

你還可以在此處運行一個Overbård演示板的只讀版本。

InfoQ:你們是如何向看板流程中添加並行任務的?

Andreadis:我們還是很快就意識到了看板狀態是非常連續的,而現實則更加平行化。通常來說,會有很多人在某項功能上協作,例如開發人員、測試人員和文檔編寫人員等,而且每個人都可能在整個工作流程中處於各自的階段。在看板狀態上映射所有這些情況可能頗具挑戰性,並且可能導致狀態數量爆炸或引入僞狀態,這些僞狀態無法捕獲現實情況,同時毫無必要地讓工作流變得很複雜。

解決這個問題的一種方法是引入某種相互鏈接的任務,但這會產生大量相互關聯的票證,從而毫無必要地使事情變得複雜且難以管理。

因此,我們想到了一種方法,就是在JIRA票證上引入新的自定義字段,來捕獲感興趣的各種並行任務,例如,一個測試開發(TD)任務正在與主要功能的開發任務並行進行,所以可以有自己的狀態,可能與其所屬的主看板卡不一樣。將任務並行化後,我們其實是在二維看板上引入了第三個維度。

這是一個看板卡的示例,最底部的一行標記了並行任務的首字母縮寫,並帶有相應的顏色代碼以顯示其當前狀態。例如,TD代表卡上描述的功能是“測試開發”,並且可以使用狀態ToDo / Red、InProgress/Yellow、Review/LightGreen和Done/BrightGreen。每個並行任務都可以有自己獨立的狀態集,例如產品文檔(PD)帶有七個不同的狀態。並行任務狀態可以直接在卡上更改,並且卡上的幾乎所有內容都帶有工具提示和額外說明。

並行任務是一個非常強大的概念,它具有多個優點:

  • 它創建了更緊湊的看板視圖,互連的票證更少。
  • 它簡化了整體工作流,因爲你在主看板卡上需要的狀態更少了
  • 它更好地捕獲了開發工作的現實情況。同一時間會有許多事情在發生,每件事在任意給定時刻都可以處於不同的階段。
  • 它使你只需單擊幾下即可創建任意查詢,比如說展示文檔尚未驗證的,開發和測試完成的功能。
  • 你可以使用並行任務來跟蹤多種合併的前置條件,例如,當所有並行任務變爲綠色時(可以對狀態進行顏色編碼),則我們準備合併到主線或部署到生產環境中。

現在,由於我們控制了工具鏈(Overbård),我們就可以對其進行增強以正確理解和可視化這些並行任務,這樣它們就不再是JIRA票證上簡單枯燥的字段,而是我們流程的有效推動力量。

InfoQ:採用看板可以給你們帶來哪些好處?

Andreadis:採用看板有很多好處。

首先,當你開始使用看板後,就可以完全尊重你的現有流程、現有角色和團隊動態。看板會迫要求你準確地建模工作流程,以及實際完成工作的方法。你需要非常詳細地瞭解狀態、輸入、輸出、切換點和完成的定義。只有做到這些,才能捕獲和可視化進行中的工作,然後對其進行迭代和不斷改進。看板將你帶入這種不斷自我完善的心態,這一點非常重要。

看板非常適合我們的異步工作方式,並幫助我們使交付保持很高的質量水平。通過精心整理的積壓和定時發佈,我們極大地簡化了計劃流程。我們就新版的主題取得一致認識,然後由開發人員負責推進工作,從而減少上下文切換並縮短規劃時間。

總體而言,我們設法將18個月的平均發佈週期縮短爲3個月的迭代週期。對於這種複雜的項目來說,減少到六分之一是巨大的成果。而且,我們已經做到了基本上由一個人來主持工作,同時開發支持工作流所需的工具。在等效的Scrum設置中,我們需要6-8人(或更多)才能爲流程本身提供資源。人們很難相信我們用很少的資源就取得了如此大的成就。

我認爲看板與Scrum有點正交。對我來說,Scrum看起來更像是一個盒子或一個工作框架,描述了盒子外圍發生的事情。它定義了流程、角色、職責、儀式和發佈節奏。但它幾乎沒有說明盒子中的內容,關注正在進行的實際工作。它假設的是如果讓所有人每天參加站會,他們就能以某種方式來解決問題。Scrum是非常同步化的。

相比之下,看板更像是一種可以在現有流程之上應用的方法。看板非常關心盒子裏發生的事情;它關注正在進行的實際工作,如何捕獲和可視化它,然後逐步迭代以優化它並增加流量並從而增加輸出。看板可以放入不同大小的盒子中。你可以在Scrum(ScrumBan)內完美地執行看板,此外它可以很好地異步運行,從而提供更好的可擴展性。

不管怎樣,無論選擇哪種方法,重要的是要讓工具適應流程,而不是讓流程適應工具的侷限性,而這正是我們開發自己的JIRA插件Overbård的原因所在。既然這個工具對我們很有用,那麼它可能對其他人也很有用,所以請隨時試用Overbård,看看它是否適合你的開發流程。

作者介紹

Dimitris Andreadis在IT領域擁有20年的經驗,他目前是Red Hat的工程總監,負責Quarkus團隊。在此之前,他曾多年負責WildFly/JBoss企業應用服務器團隊。他還曾擔任JBoss AS項目負責人,並且從企業初創期開始就一直是JBoss的粉絲和貢獻者。他之前曾在Intracom和摩托羅拉的NMS/OSS領域工作,設計可重複使用的框架和分佈式系統。ANdreadis在雅典技術教育學院學習計算機科學,並獲得愛爾蘭都柏林大學的碩士學位。

原文鏈接

Using Kanban with Overbård to Manage Development of Red Hat JBoss EAP

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