作者：袁翠

2019年1月20日，這是一個週日的晚上，儘管如此，來參加沙龍的人還是不少，與其在家無所事事，不如來一場知識的火花碰撞。

按照慣例，先是進行自我介紹。如果說這次自我介紹與以往有任何不同的地方，那就是，自我介紹人員要站到臺前來跟大家介紹自己。由於此次的主題是大規模敏捷框架的介紹，很多來參加沙龍的人員並不是非常熟悉，都希望對其有更進一步的瞭解。

話題導入

此次的主題是大規模敏捷框架 – Essential SAFe介紹，主講嘉賓是Ella Yao。本次的分享分為兩大部分：

● 敏捷與Scrum介紹

  • 什麼是大規模敏捷
  • 什麼是SAFe

● Essential SAFe overview and assessment

  • Essential SAFe overview
  • 自我評估

Ella首先拋出的討論問題是：大家對敏捷的理解是什麼。有的學員認為敏捷就是以最低的成本得到最大的價值；有些學員則認為敏捷就是「忽悠」，提高效率；有些認為敏捷適用於產品的迭代而不是定製型的項目，如果有一個原型或功能需要疊加，按照輕重緩急來做，則更適合用敏捷，但是不是所有的甲方需求都能接住，如果按照人天來做，可能沒問題，如果需求固定，又不按照人天來算的話，那麼可能就接不住了；也有學員立馬提出了反對意見，項目本身就是要定好時間/範圍/需求，而敏捷也是需要在PO會議上劃範圍/時間/成本，再形成Sprint，不同點就在於敏捷是不斷進行交付，更有利於及早發現產品是否滿足客戶的需求，不能單純說敏捷更適合於產品的迭代等等。

不同的人對敏捷的理解不同，有人認為它是方法論，有人認為這是一個JIRA工具，是最佳實踐的集成；也有人認為它是先進的管理方法/理念，並且概念在不斷擴大。

敏捷與Scrum介紹

首先Ella對敏捷的發展史進行了簡單介紹。Scrum的概念首次提出是在1980年代，中文並無Scrum的對應翻譯，Scrum的願意是橄欖學的術語，表示並列爭球的意思。在1990年代，Kan & Jeff，Scrum之父真正使用到Scrum的方法，當時傳統的瀑布模式不太適用，市場瞬息萬變，用戶需求在不斷變化，或者是有新的產品時，還不一定知道用戶羣。在2001年，敏捷宣言首次提出，並有了更大的發展；在2009+，形成了大規模敏捷的概念，其他理念如LeSS也相繼提出。Scrum本身其實是一個框架，只是解釋了一個團隊怎麼去做敏捷，建議的團隊成員通常是7+/-2，沒有設定具體的流程。

敏捷宣言引用如下：

  • Individuals and Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to Change over following a plan

That is to say, the items on the left are valued more than the items on the right.

要強調的是，左邊標黑的比右邊更重要，但並不是代表右邊的不要做。

Scrum 框架

接著，Ella對整個Scrum框架進行了講解。PO從幹係人那邊得到需求作為輸入，跟開發團隊保持緊密溝通，清楚想做的特徵在技術上能否實現，風險怎樣。得到輸入後，需要將其轉化為需求列表product backlog（需求列表是動態的，PO可以隨時更新；按照優先順序排序；漸進明細，高需求的顆粒度較小。基本只要幾天的工作量，排在下面的就是簡單描述，需求還不是很明確）。Development team是開發團隊。一個大圈（通常1-4周），最開始定義好一個圈是幾周。迭代第一天會有sprint planning，PO跟團隊解釋前面幾條具體要做什麼。結束後，輸出，團隊在固定的sprint裡面能做完幾條需求。Scrum master的角色有點類似於項目經理，但還是有區別；scrum master會進行協調組織，每天會有15分鐘的站會，會後更新燃盡圖，識別問題風險；sprint最後有兩個會，sprint review 迭代評審會，叫PO過來給他演示進行驗收；sprint retrospective 迭代回顧會：流程/工具/合作/溝通/人/，哪些做得不錯，哪些需要改進；有些改進項可能會進入sprint backlog。

基本SAFe概覽

Ella對上圖做了詳細介紹，簡單摘要如下：

  • SAFe的全稱是Scaled Agile Framework enterprise
  • 上圖黃色柱形中的每一個小圈代表的是一個scrum迭代，共有五個迭代。兩個小圈中間的省略號。。。的意思是有很多團隊在跑迭代。SAFe有兩層，Team層和program層（很多團隊之間的依賴比較大，人數為50 - 125）。Team 層包含有scrum master, PO, 開發測試人員。Program 層也稱作火車層，跟team層一一對應。
  • RTE：release train engineer 發布火車工程師，類似於chief scrum master的角色
  • Product manager: 可以理解為管理所有PO
  • System architecture: 系統工程架構師
  • Business owners: 老闆/客戶業務方的老闆/研發的老闆，會給PR的價值打分數
  • 版本火車：在發布週期很短的情況下，不按照以前的項目方式（如果在截止日期前沒做完，則延期），而火車的發車時間是固定的，如每月發一版。但是每個月發布的內容是不固定的，這麼處理的目的就是為了建立快速發布的能力；真正達到敏捷，敏捷的範圍scope是可以變的，如果這個版本沒趕上，下個版本再發，客戶那邊也比較容易接受
  • 版本火車+feature 開關：如果有代碼沒寫完，有開關
  • PI planning: 通常是會有上百個人開兩天會，有非常詳細的會議議程。首先Business Owner會就將來的戰略/目標進行發言，接著架構師就公司的架構技術進行發言。接下來會進行scrum分解來計劃這五個迭代要做什麼；在開會之前，PO和product manager要商量哪些特徵feature要做的,怎麼拆分成更小的故事story；第一天會議結束後，會就風險/問題/依賴關係進行分心並討論計劃是否要變；第二天在繼續做分解討論，最後進行信心投票；business owner會進行價值value 打分；做完之後大家按照計劃來執行。在執行過程中，在團隊層（Team level）面，會有每日站會；火車層（Program level）也會有相應的會議，要注意兩者之間要進行互通/同步
  • 在全部五個迭代中，前四個迭代有冤圓圈表示，最後一個沒有圓圈，而是寫著IP （也即innovation and planning創新計劃）迭代；五個迭代中通常留出最後一個做創新/回顧，但是不做新的需求；在開始計劃的時候，前四個迭代真正完成所有需求
  • Enabler: 技術方面的故事
  • 紅色折線：架構跑道；技術類的基礎工作，需要技術/架構團隊經常做系統/架構優化，支持實現新的feature或者換屆由新的業務造成的系統壓力
  • DevOps: 開發和運維，怎樣更好地進行合作，打破中間的裂縫
  • 等等……

在講完框架之後，Ella也分別介紹了Essential SAFe的十個元素是什麼，如果沒有，會造成什麼後果。

自我評估

最後，Ella就敏捷，SAFe與LeSS之間的不同談了她自己的見解：

  • 敏捷 - 只是定義了一個框架，看似簡單，實際做的時候容易有比較多的問題；一般都是根據自己的需要來做，運用比較自由
  • SAFe – 內容其實更多是精益和敏捷的東西，最大的貢獻是有這樣一個框架，除此之外還有細化的流程，引用Ella的話， 「不僅有架子，還有肉」 ，現在最受歡迎，因為每一個步驟很詳細，都有模板，角色定義也非常清楚
  • LeSS - 關注系統思考；首先要考慮組織架構的調整，要求比較高，應用相對沒這麼廣泛

其實不管運用哪種，都需要歷經守破離這三個階段。

至此，本次活動圓滿結束。其實，參加沙龍只是給大家提供一個更好的平臺來進行交流，在參加沙龍之前，如果可以多做做功課，帶著更多的問題來進行探討的話，那麼相信收穫也會更大。讓我們一起期待下一期的活動吧！


推薦閱讀：
相關文章