CODING 敏捷實戰系列課第二講：Scrum 敏捷項目管理核心要素之 3355
Scrum 是敏捷開發流派中最著名和最落地的一支，全球 70% 以上公司的敏捷轉型都是以 Scrum 起步。CODING 特邀敏捷顧問、CST & CTC 認證敏捷教練申健老師將在本課程《Scrum 敏捷項目管理核心要素之 3355》中介紹 Scrum 框架的核心要素，幫助大家更好地學習實踐 Scrum。
大家好，本次我將為大家詳細講解敏捷的一個流派，叫做 Scrum 敏捷項目管理核心，它起源於 2001 年，當時有 17 位大牛共同討論了他們的想法和各種軟體開發方法，經過交流，他們最後達成了價值觀和原則上的共識，共同發布了敏捷軟體開發宣言。
而迭代的概念則可以追溯到 1970 年左右，Scrum 也是用迭代式去進行發展，與之相應對的就是瀑布式，所有工作像流水線一樣有計劃且按部就班的去進行。例如：在軟體開發中，先是需求分析、設計，然後進入開發編碼、測試，到最後上線，整個過程有前後順序，不過現實中總會在某個地方出現問題從而造成返工。
有兩個日本學者在 1986 年研究了豐田、本田、Canon 等高科技公司怎樣在一個不確定的情況下去研發一個新產品，他們發現這些公司不再去區分職能部門，而是具有跨職能團隊的特點。就像打英式橄欖球，每個人都有各自的專長，但是目標是統一的：要進球贏球。
所以他們在管理智力型研發項目時，沒有再用瀑布流式來管理，而是用一種不斷迭代的方式。項目的迭代時間不超過四周，在這四周里必須包含所有的必備工作，包括分析、設計、編碼、測試，確保快速交出一份相對簡單可用的產品，及時獲得用戶回饋。否則如果等到產品上線再來收取用戶回饋，改動成本、項目風險將是非常高的。Scrum 通過事務減少工作任務和工作時間，給予跨部門小團隊充分的授權，讓他們自己決定如何工作，同時又保持目標一致。
1995 年創立 Scrum 時，也吸收了豐田汽車的精益思想，例如減少浪費、限制流動。Scrum 是一個解決複雜自適應問題的框架，讓我們以迭代和增量的方式，在最短時間內交付最大價值的產品。要知道你的人力、物力、財力，包括你的時間，永遠是有限的，有一句老話叫「錢要花在刀刃上」，集中優勢兵力干一件大事，先做價值最高的那個，分清主要矛盾和次要矛盾。越想全都解決，越解決不了，而 Scrum 就是希望你能做出取捨。例如你的項目上線後，真正被用戶使用的部分佔比多少，創造了多少價值？通常我們叫二八原則，是指 80% 的價值一定是在 20% 的工作任務里，剩下的都是錦上添花，也有可能是無用功，如果能夠減去沒有價值的任務，就能讓我們獲得更充分的時間把品質做的更好。Scrum 並不是必須把所有東西做完，有一句名言叫做「遇到事要嘗試反過來想一想，世界每天都在變化，所有事情沒有一個盡頭」，要學會適應變化、破解和應對複雜性、擁抱變化。
其實在敏捷 Scrum 里，我們更喜歡用這種產品的思維，而非項目，因為按照定義項目是一次性的，也就是說必須先做一個計劃，然後按部就班去遵循這個計劃的固化思維。你需要分清你的產品到底是什麼類型，在業務目標之下，大家可能會有很多的想法，所以有時會缺乏一個真正的決策者，或者決策者的位置特別高，資訊流動不暢，導致大家想法不一樣，那真正幹活的人實際上是無所適從。在 Scrum 里首先要定義一個很重要的角色，叫產品負責人，他要綜合各方的想法，進行艱難選擇，將所有想法根據投入產出比進行排序，形成一份產品待辦列表清單。它可以無限地增長，但並不意味著要把列表裡所有東西都做完，而是從業務、運營角度來說時間挺重要，那在這個時間點我們就要集中優勢兵力做最重要最有價值的。
「倒排期」是指一開始規劃很多任務，把所有任務全都扔進固定時間內，從進度上來說可能磕磕絆絆做完，但是品質就慘不忍睹了。而 Scrum 可以從時間往後倒推，根據可持續的方式來進行動態取捨和排期，先形成一個初始的產品待辦列表，團隊和 PO、業務干係人可以約定迭代周期，顧名思義它是一個短的時間周期，通常不超過四周。
首先需要開一個 Sprint 計劃會，從長長的產品待辦列表裡面去拉取一批工作，進行分解，形成工作計劃。每一個短的時間周期里都有一個小的目標，在小目標之上一定有個大目標，小目標是從大目標里進行分解，之後進行開發、編碼、測試等等。而每日還有一個站會活動（Daily Scrum），讓團隊成員聚在一起分享今天的進展與遇到的問題，這是一個強制溝通的機會。在項目快結束時，我們將工作集成起來，如果是軟體則進行集成測試，其他的產品類型則進行相應的產出。然後將完成的產品增量拿到 Sprint 評審會上，邀請產品相關人士並做演示，這時可能會有人提出產品跟預想的不一樣，那麼趕緊修改，回饋來得越早越好，越早去發現問題，修復的成本越低，根據回饋可以調整出我們到底要做哪些內容。最後來到回顧會，這時不止需要對產品進行調整，還要進行檢測調整。
接下來講講三大角色，分別為：產品負責人（ PO ）、開發團隊、Scrum Master 敏捷教練。做產品只能有一個 PO ，負責最大化的投資回報率，並且不斷地重新調整優先順序和梳理列表。開發團隊顧名思義就是幹活的，這個團隊就像球隊一樣，它是「跨職能」，並且是「自管理」，被給予很高程度的自治和責任。Scrum Master 敏捷教練，顧名思義就是教練，幫助你具備獨立解決問題的能力，所以他並不是一個管理者和管控者，更多的是服務型的領導者，有什麼不會的可以教你，但是最終幹活的一定是開發團隊，例如龍舟隊，龍舟隊上划船的就是開發團隊，掌舵人就是 PO，前面敲鑼打鼓把握節奏、鼓舞士氣就是 Scrum Master，這三個角色就組成了一個龍舟隊。
三個工件分別是指產品待辦清單、Sprint 迭代待辦清單和符合完成定義的產品增量。例如首先產品有個大的目標方向，經過我們的收集資訊分解，變成 1-8 號需求，我們需要選取需求到待辦清單，團隊再分成子任務，之後迭代開始，將產品進行集成，變成可以測試驗收上線的產品增量，最後經過回饋，PO 可以再去調整剩餘的需求。
在 3355 中，第一個 5 是指五個事件，是 Sprint 本身短時間盒和其他四個會，分別為 Sprint 計劃會、每日 Scrum 站會、Sprint 評審會、Sprint 回顧會。在做同一產品多團隊時首先要拆團隊，維持不超過 9 個人的團隊結構，類似 LeSS 結構，強調工作在同一個產品的多個團隊，只有 1 個 PO 和 1 份 PB，所有團隊的迭代時間盒對齊。在 Sprint 末尾要交出已集成、完成的產品增量。如果是超過 8 個團隊，可以考慮 LeSS Huge 結構，增加領域產品負責人（Area Product Owner）角色。第二個 5 是五個價值觀：開放、尊重、勇氣、專註、承諾。承諾這個詞在 Scrum 中表達的是全身心投入去完成 Scrum 團隊的目標，而不是說必須按計劃完成，兩者之間還是有些不同。
Scrum 是一面照妖鏡，它的設計「故意不完整」，也故意讓項目團隊「更難受」，你認為做的產品是完美的，而 Scrum 就是指出產品的不完美，也就是挑錯。原來一個月交不出產品，那麼就把時間縮短成一周或兩周迭代，逼迫團隊做出改變。敏捷不是從 0-1 的非黑即白，它是一個持續優化的過程，通過持續交付、持續優化、持續改進、持續提升、持續塑造，最終實現小步快跑，快速迭代。那麼今天就分享到這裡，謝謝！
