"Scrum is simple，but it's not easy。"這是參加CSM認證培訓課上Vernon大師介紹Scrum框架前說的一句話，當時因為剛接觸敏捷不久，對Scrum也只限于皮毛的理論知識，對大師的這句話并沒有太多感受。后續隨著公司一年多的Scrum+XP的落地實踐，在公司內部負責敏捷推廣，給各個團隊培訓敏捷基礎知識，同時在幾個團隊中擔任ScrumMaster，對這句話的感越來越深。

因為在公司每個月都會新員工做敏捷培訓，對于框架中的內容已經很熟悉，但每每遇到落地實踐的問題，都會重翻這本經典之作對應的章節，而對于Scrum框架這個章節都會必看，帶著問題重讀，對框架中各塊內容有更深的理解。

這也是為什么我會選擇"Scrum框架"這一章節的原因。

Scrum框架總覽：

首先，Scrum不是一個類似ISO9000或者CMMI L3之類的標準過程，也不能保證團隊有條不紊的按照步驟一步步執行后，就能在指定時間和預算內產出讓客戶滿意的高質量產品。相反，在一定時期內Scrum有可能會讓高層感覺團隊依舊很"慢"。因為，Scrum是一個用于組織和管理工作的框架。

*Scrum價值觀：

價值觀是整個框架的基石，就好比建造高樓大廈的地基，雖然不屬于建筑的組成部分，但它對保證建筑物的堅固耐久具有非常重要的作用。不理解或者不認可價值觀，后續的各項活動也就不會深入理解其中的目的或者價值，會做的越來越形式化。

在Scrum聯盟的各項認證培訓，以及在大部分資料中，對于Scrum價值觀是五大項“承諾、專注、公開、尊重、勇氣”。但本書提到了八大價值觀，稍有差別。對此也曾有過困惑，百度了很多資料，后來在一篇《Scrum價值觀問題溯源》的簡書中看到Bob對此問題詢問原書作者后的答復“書中的幾項是作者自己添加的，他認為非常重要的價值觀”。追本溯源，兩者“專注、開放、尊重、勇氣”是完全一樣的，差別在于“承諾”和“誠實、信任、授權、合作”這些詞條。在實際的落地實踐中，真實感受到“承諾”完全可以貫穿這四項詞條：“承諾”是PO和開發團隊相互給予對方的，在過程中通過緊密“合作”來促進承諾的達成。團隊基于團隊的平均速率“誠實”地向PO承諾下一個Sprint目標，PO在過程中充分“信任”團隊可以交付高質量產品增量，并且承諾不會干擾團隊。對于SM來說，不再是以往的管理者的角色，而是一個教練，在過程中充分發揮教導作用，幫助團隊制定合適的、有團隊特色的Scrum方式，給予團隊充分“授權”，而不是像傳統項目經理那樣去分配任務或者發號施令。

Scrum價值觀推崇以人為中心，與眾多企業文化也是相符的，但真正讓公司從上至下做到理解和落地還是需要下很大功夫的。否則，將會變成墻上文化，隨之Scrum各種實踐也會有形無神。

*Scrum角色：

PO、SM、開發團隊，三個角色在工作中相互影響、相互依靠，在過程中相互磨合，“相愛相殺”的感覺，逐漸形成有機整體。

-PO：明確WHAT？（要開發什么？以什么順序開發？）-引導團隊做正確的事情

關于PO這個角色多說一句：我們公司有產品經理、產品助理等崗位，但是在團隊內往往會把崗位與角色混淆，很多開發同學會說團隊內有2個、3個、甚至于5個PO，個人認為這是比較嚴重的概念錯誤，一是SM要自省團隊為什么會有這樣的概念錯誤？二是承擔PO角色的同學要自省真的承擔起相關職責了嗎？PO在團隊內是唯一有權決定要構建哪些特性并以何種順序來構建的人。如果有N個PO存在，那對于開發團隊來說也是一種痛苦，不知道該聽誰的。。。

-SM：指導團隊在通用Scrum框架上建立并遵循自己的過程。

通過自己的個人影響力來領導團隊，在團隊中承擔培訓、引導、輔導、啟發、協調等作用，屬于“服務式領導”。避免通過權力來命令或者控制，否則違反了Scrum基本價值觀。

-開發團隊：確定HOW？（如何交付PO要求的產品）

跨職能、自組織團隊，7±2的規模（兩個披薩原則），如果團隊人數過多，溝通渠道會很多，那么各種溝通和會議的效率會大大降低。

我們的做法：在公司剛開始推行敏捷的時候，要求每個團隊都創建一份“團隊工作協議”，全員簽名后貼在各自的白板上。雖然建立是帶著半強迫的性質，但每個團隊所公示出來的內容實際是團隊問責的明確聲明，對于團隊自組織管理起到了一定的推動作用。例如，站會遲到是最常見的一些問題，在工作協議中對此會有團隊共同商定的“處罰”辦法。起初，工作協議中的內容不會很多，隨著沖刺的進行，發現問題、解決問題、回顧總結，工作協議會越來越充實，這也充分體現了團隊的持續提升。當團隊中有新的同學加入，工作協議也是讓新人快速了解團隊文化的方式之一，更快融入團隊之中。

公司這一年多的敏捷落地實踐，對于技術團隊來說經歷了很大的考驗：從職能轉變的角度，團隊更加扁平化，取消了項目經理的頭銜，一些人員因為轉變不了思維被迫離職。其次，敏捷轉型對于大家的工作方式、溝通方式也是一個很大的轉變，公司采購了JIRA、WIKI作為日常工具，使工作協作更加透明化、可視化。

*Scrum活動：

各項活動的詳細內容不在這里贅述，只是分享一些自己的感受。

每個沖刺期間，這些活動都是必須執行的，并且一環扣著一環。在轉型期初，很多團隊成員抱怨會議太多，占用了太多時間，經過幾次調研，發現大家對于這些活動或者會議的叫法各有不同，例如：“沖刺規劃”在一些團隊成為“迭代計劃”，一些團隊成為“迭代啟動”。其實，會議目的都是相同的，但在大家都一知半解的情況下會認為有多個會議，太浪費時間了。為了讓各團隊在這方面達成一致，我們將各項活動統一了名稱，并且梳理了會議目的、召開時間、參加人員、輸入、輸出等內容，公示在WIKI中，讓各團隊的SM將相關內容在團隊內宣導。經過一段時間，會議太多的這種反饋就不存在了。

隨著各項活動的不斷進行，問題又來了，大家又反饋“這些會議太形式化了，不開這些會難道項目一定做不好嗎？”答案當然是否定的。實際上，在框架概覽中也已提到，Scrum不能保證團隊有條不紊的按照步驟一步步執行后，就能在指定時間和預算內產出讓客戶滿意的高質量產品。經過一些溝通，出現這種問題反饋是由于大家把這些活動僅僅當成了去開了個會，缺少“儀式感”。《小王子》中對于儀式感有句經典的話：“儀式感，就是使某一天與其他日子不同，使某一時刻與其他時刻不同。”（關于儀式感的重要性，推薦大家一篇簡書（http://www.lxweimin.com/p/1f21b68925c5））隨后，在公司內的各種培訓或者分享中，我把這部分內容都稱之為“Scrum儀式”，把儀式感深入人心。

問題在實踐過程中不斷出現，解決了一個又會冒出了新的問題，我們要做的不是逃避問題，而是去觀察問題背后的根因到底是什么，找到根因，抽絲剝繭，總會找到最合適的解決方案。

*Scrum工件：

-產品列表：由產品負責人管理、不斷演進的一個動態列表；具有DEEP的特點；其中每一個條目稱為PBI，包括功能性需求、非功能性需求、技術改進點、待解決的問題等；

-沖刺列表：在沖刺規劃期間，產品負責人和開發團隊對沖刺目標達成一致后，開發團隊一般會繼續將每個需要完成的特性再細分為一組子任務。這組任務與對應的PBI共同組成了沖刺列表。由開發團隊管理和維護，產品負責人沒有權利自行添加PBI或者子任務。

原則上，在一個沖刺期間不允許改變范圍內的目標。但是，有時候業務需求使我們無法完全遵從這個原則。通常，我們在各個團隊中采取的做法是：產品負責人首先闡明變更的必要性，一切基于價值評估來說話，團隊認可價值后再與團隊協商是否采用“需求置換”，或者團隊接受這個沖刺加班完成。無論是什么結果，產品負責人都不能威脅團隊必須要做。

-潛在可交付的產品增量：這里最關鍵的是團隊內有一致同意的DOD（完成的定義），基于其中的內容來判斷是否沖刺內所有東西都做完了。

“潛在可交付”并不意味著構建出的東西必須實際交付，交付是產品負責人的業務決策，基于發布計劃來確定。

同樣，隨著時間推移，團隊DOD內容會不斷修改完善 。

關于燃盡圖：CSM認證培訓課上Vernon大師介紹，早期時燃盡圖是Scrum工件之一，但是當圖形燃到0點時，并不意味著可以交付出有價值的產品，所以“潛在可交付的產品增量”替代其成為Scrum工件。

那么，燃盡圖是不是就不再重要，可以不再關注呢？非也。個人認為，燃盡圖在沖刺過程中是需要團隊成員共同關注的。無論是手繪還是通過工具來展示，都是沖刺過程中可視化進度的表達方式，能幫助團隊判斷沖刺目標是否可達成的風險概率。

總結：

"Scrum is simple，but it's not easy。"

理論的內容總是很簡單，但是真正做起來，會遇到各種各樣的問題，“見招拆招”，總能找到的合適的解決方法。關鍵是堅持。