在目前的互聯網公司，敏捷（Agile）的概念已經有相當的普及，人人都在談，似乎不談敏捷就不那么互聯網了。幾乎所有的互聯網公司都不同程度的實施了敏捷。采用敏捷開發的方法也有很多，主要包括極限編程（XP）、Scrum、水晶方法（Crystal Methods）、自適應軟件開發（ASD）、特性驅動開發（FDD）、動態系統開發（DSDM）、輕量級RUP、測試驅動開發（TDD）等等。而在眾多的敏捷開發方法中，尤以實施Scrum比較流行。

對于我本人來說，接觸Scrum有幾年的時間了。在軟件開發項目中做了一些Scrum的實踐，閑暇時間也經常與業界Scrum同仁們溝通交流一些心得。同時，也始終在關注業界對于Scrum的一些新的認識和實踐的書籍材料。在這一過程中，也促使我對Scrum有了更深刻的理解。

結合我的Scrum實踐，本文主要從Scrum的認識，Scrum的實施過程以及實施Scrum帶來的變化幾個方面進行分享，解讀一個可運行的 Scrum是怎樣的。希望能給大家帶來不一樣的認識，并對Scrum實踐有所幫助。

一、Scrum的認識

首先來了解一下Scrum的定義。Scrum 是一個用于開發和維護復雜產品的框架，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的長度是2到4周。

在Scrum中，使用產品Backlog來管理產品的需求。產品backlog按照實現的優先級進行排序，以商業價值作為排序的主要原則。在Sprint中，Scrum團隊從產品Backlog中挑選最高優先級的需求進行開發。挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表，稱它為Sprint backlog。當Scrum團隊完成Sprint backlog列表中的所有任務時，本次Sprint結束，進入下一個Sprint迭代周期。

Scrum有很大的價值，然而在有些公司推行Scrum卻困難重重，有些人說Scrum沒有什么實質性的作用，然并卵。為什么會有這樣的認識呢？深入分析，原因主要有：

• 項目團隊缺乏對敏捷的正確認識，單純的認為敏捷就是快，就是追趕進度,就可以不受任何制度約束。大家可能聽說過這樣的對聯，“這個功能很簡單，怎么實現我不管。”橫批：“明天上線”。也曾聽說有些公司要開發一個新功能，因為實施了scrum，于是要求項目團隊加班加點，將2周甚至3周以上的開發任務在一周內就發布上線。實施Scrum意味著項目團隊“漫無天日”的加班，這導致了項目團隊對敏捷有一種“恐懼”感；
• PO不能勝任工作，無法拆分有效的用戶故事，或者用戶故事拆分的不合理，無法實現迭代增量開發；
• Scrum對于自組織的團隊要求很高，但許多同學認為自己達不到自組織的標準；
• Scrum倡導工作透明化，項目實時完成情況和每個人的任務認領情況通過項目看板和項目燃盡圖一覽無余，許多人對此不太適應；
• 在迭代的過程中無法及時發現問題，或者發現問題，無法有效解決問題，使項目團隊有一種挫敗感。等等。

如果對Scrum的認識僅僅停留在“上午有個點子，下午就要實現，晚上就能上線，是不恰當的。在我看來，Scrum肯定是有價值的，Scrum的主要作用包括：

• Scrum能夠保證優先開發對客戶具有較高價值的需求，更好的滿足用戶的需求；
• 與瀑布流程下的開發方式相比較，通過實施Scrum，能夠提升團隊一倍的開發效率，最大限度的發揮團隊的作用；
• Scrum能夠縮短開發周期，提高項目的交付效率。

但是，實施Scrum并不意味著不受項目約束，任性而為。那么實施Scrum的正確姿勢是什么呢？

二、如何實施Scrum

（一）確定PO

PO即Product owner,是一個角色，PO是管理產品待辦列表的唯一責任人。當然，在有些公司PO也可能作為一個組織而存在，比如我們公司在實施Scrum中就將PO作為了一個組織。

如果將PO作為一個組織運行，在這一個組織中必須選出一個Owner。作為owner，必須具有大局觀；深刻了解行業信息與走向；能夠把握產品的方向，擔負起產品短期以及中長期的規劃與管理；能夠根據公司戰略要求，進行用戶研究和產品功能規劃，深度跟蹤、分析、挖掘不斷變化的需求，不斷進行產品創新。

另外，如果將PO作為一個組織，在軟件開發項目中，PO小組可能包括的成員有產品經理、業務方、視覺設計師、交互設計師以及架構師等，在多數情況下由產品經理或交互設計師擔任Owner。

（二）組建team 

team是產品藍圖的真正實施者，負責在每個Sprint結束時交付潛在可發布并且“完成”的產品增量。team主要包括開發及測試人員。team必須能夠落實PO對產品的設想。team的規模宜小不宜大，一般5~9人較為合適。

在敏捷開發中倡導的是團隊人員的“全棧”能力，但目前在大多數互聯網公司可能難于落實，比如多數互聯網公司前后端開發是分離的，所以在組建team團隊時需要特別關注前后端開發人員投入的比例。

以我帶的2017年開發的“小鋼店”小程序為例，前端和后端人員投入的比例為2:3時，能夠最大限度的提升項目的開發效率。當然，這個比例必須基于項目中前后端所承擔的具體開發任務情況而定，而不是隨性給出。

（三）、選擇Scrum Master

Scrum Master為過程負責，服務于PO和開發團隊。Scrum Master要有儀式感，能夠有效地、高效的組織迭代計劃會、每日站立會、功能演示會、迭代回顧會等；Scrum Master必須具有高度的執行力，并保持公信力，能夠幫助團隊聚焦交付目標和質量目標，確保團隊高效交付高質量的產品；推動團隊建立高效的流程，指導團隊了解敏捷價值觀、原則和敏捷實踐；負責培訓團隊其他成員，確保Scrum得到正確運用；促進團隊有效的交流協作、問題管理、沖突解決，幫助團隊消除一切障礙。

（四）、維護產品需求池

產品需求池是所有用戶故事的集合，由PO依據公司的戰略和產品愿景進行的思考。PO按照產品實現的優先級順序對產品需求池的所有用戶故事進行排序，并形成產品待辦事項列表，產品待辦事項列表相當于產品研發的“路線圖”，要想了解產品的脈絡，產品待辦事項是最好的參考依據。 

我們每一天都面對著新的競爭者和用戶新的訴求，這意味著PO必須不斷地優化自己的產品設計，并對產品待辦事項列表實現的優先順序進行調整。在這一過程中，PO應該與所有利益相關者和團隊進行協商，以確保產品待辦事項能夠反映用戶的真實訴求。

（五）、故事點評估

相對精確的評估工作一般都是在沖刺計劃會上進行，并由負責實際開發及測試工作的團隊對產品待辦事項做出評估。在實踐過程中為了讓沖刺計劃會更高效，在沖刺計劃會之前PO與Scrum Master會作出一個粗略的評估。看看沖刺計劃是否切實可行？要完成這些事項，現有的信息是否足夠？用戶故事拆分是否合理？

在開發團隊進行評估時，建議摒棄傳統的“人天”評估法，采用故事點的方式，用斐波那契數列的數字（1，2，3，5，8，13，21……）的形式去評估。評估時team需要首先確定一個用戶故事為作為評估的參照。另外，特別注意的是當評估的單個故事點大于21的時候，用戶故事需要進行再次拆分，單個用戶故事點數不超過8是最理性的狀態。 

（六）、沖刺計劃會

這是第一場真正意義上的Scrum會議。Team、Scrum Master、PO坐到一起，規劃沖刺的內容。作為軟件開發項目，進入規劃沖刺的用戶故事，用戶故事應該已拆分完成，并且完成了視覺設計。沖刺周期一般是固定的，大部分是2至4周。團隊要從產品待辦事項列表優先級最高的用戶故事著手，看看一個沖刺迭代中能完成多少。

如果團隊已經開展過多個沖刺迭代，通過參考前幾次迭代中完成的“故事點數”，團隊可能預估到本次迭代完成的大概故事點數。“故事點數”相當于團隊的速度。Scrum Master與Team應努力在每一個沖刺迭代中提高這個數字。

對于沖刺目標，即在一個沖刺迭代需要完成的事項， team所有成員都應該形成共識。在沖刺計劃會上，PO需要告訴team用戶故事實現的優先級順序。team承諾在下一次沖刺迭代中他們能夠完成多少用戶故事。在沖刺的過程中，任何人不能單方面擅自變更沖刺內容。

（七）、每日站立會

這是Scrum的活力源泉。站立會參加人員一般包括PO、Scrum Master、team。團隊每天在固定地點、固定時間進行內部溝通，時間一般為早晨，時長不超過15分鐘，且站立進行，Scrum Master向team成員提出下列問題：

• 你昨天完成了哪些工作？
• 你今天計劃做哪些工作？
• 目前的困難及障礙？

這樣做的意義在于讓整個團隊清楚地知道在這一個沖刺周期內各項任務的進展。所有任務是否能夠按時完成？Team的任務都不是自上而下分派的，而是自主決定、自愿申領的。如果前一個任務沒有完成時，不能申領下一個任務，不能同時申領2個在當天不能完成的任務。Scrum Master負責消除團隊面臨的障礙。

（八）、項目看板及燃盡圖

在Scrum中，必須做到工作透明化，最常見的做法是實施項目看板制度。有的團隊善于借助第三方工具使用電子看板，比如Redmine看板，Leangoo看板；有的團隊樂于使用線下物理看板。

無論使用電子看板，還是物理看板，看板的欄目大致包括待辦事項、進行中事項以及已完成事項三個部分。隨著迭代進度的推進，由Team每天及時將事項轉移到對應看板欄目下。 

讓工作透明化的另一個工具是燃盡圖。在這張圖中，一個軸代表工作量，另一個軸代表時間。每天Scrum Master都會記錄待完成的剩余點數，而后畫在燃盡圖上。理想情況下，該圖是一條向下的曲線，隨著剩余工作的完成，“燃盡”至零。 

（九）、功能演示

在《Scrum指南》中將此環節稱為Sprint評審會議，書中認為Sprint評審會議應該包括開發團隊演示完成的工作并解答關于所交付增量的問題、評審市場或者潛在的產品使用方式所帶來的接下來要做的最有價值的東西的改變、為下個產品版本功能或能力的發布評審時間表、預算、潛在功能和市場等多個會議主題。會議一般在在本次迭代沖刺發布前召開。不過，從實踐來看，我更傾向于此次會議最重要的工作是功能和成果演示，驗證用戶故事的實現場景，并接受評價。

這是一場公開的會議，任何人都可以是參與者，不僅僅包括PO、Scrum Master及team，還包括利益相關者、業務方與管理者，乃至客戶。

團隊應該只展示那些符合“完成定義”的事項，也就是全部完成，不需要再做工作就能交付的成果。這個成果或許不是完整的產品，但至少是一項完整的、可以使用的功能。

（十）、沖刺回顧會

沖刺回顧會一般在本次迭代發布之后的第二天召開，會議時間最好不做具體的限制。

沖刺回顧會要認真分析以下幾個問題：

• 發生了哪些有待改進的事；
• 為什么會發生那件事；
• 為什么我們當時忽略了；
• 怎樣才能加快工作進度。

作為一個團隊，要讓這個沖刺回顧過程有效，團隊需要相互信任。必須記住基于項目和技術問題的討論和爭論；對事不對人，不當和事佬，鼓勵技術碰撞；不能把技術和業務討論牽扯到人身攻擊上去；抵制帶著有色眼睛看人，引導大家理性討論；勇敢接受別人的挑戰，接受自己的不完美 大家要對自己的流程和結果負責，要集思廣益，共同尋求問題解決之道。這一點是至關重要的。

最后，團隊確定一個最值得改善的地方，將其設定為下一個沖刺迭代的首要任務，當然，改善的結果必須通過“驗收測試”。你如何證明自己成功地完成了改善？你需要用具體的、可操作的方式界定什么是“成功”，這樣，在下一個沖刺回顧會議中才能很快判斷出是否已完成改善。

上一個沖刺迭代結束之后，開始進入新的沖刺迭代。

三、實施Scrum帶來的變化

通過在Scrum項目中的實踐，給我們的團隊和項目組帶來的變化主要有：

• 組織：

在瀑布流程下，通常會設置包括業務方、產品經理、項目經理、開發人員、測試人員、交互設計師、視覺設計師等多個角色，由于強化了不同角色的定位，而且不同角色又隸屬于不同的職能部門，無形中增加了項目協同的難度。

在Scrum項目實施中，僅設置了PO小組、master和team團隊這樣的角色和組織，而且大家在一起集中辦公，很大程度上淡化了角色隸屬關系，形成了團隊合力和向心力。

• 內聚：

團隊合作的要旨是提高團隊的內聚性，內聚也體現在個人工作焦點上，避免了一個人同一時段身兼多責。每個人都需要長時間的深度思考和環境浸染，如果天天在會上趕會，必定是失敗的。

• 節奏：

用用戶故事和站立會、沖刺會的形式，重構項目過程，細致而又綿密，靈活而又緊湊，減少時間死角，讓需求等人而非人等需求。

• 盡早與客戶互動：

實施Scrum，極大的縮短了發布周期，讓我們的用戶及早的感知產品，這對保持正確的產品航道有極大的幫助，也能更好的幫助公司做好戰略上的決策。

• 透明：

作為敏捷實踐，項目看板制度是必不可少的，通過項目看板制度，項目成員每天完成的任務情況一目了然，團隊目標感明確，顯著增強了工作的主動性和能動性。

• 心態：

深刻剖析和本地化執行scrum敏捷方法論，持續自省，自我革命，破除僵化流程，解除自我保護，項目團隊能夠“就事論事”的討論問題，解決了管理“人”的難題。

2018年，我們將繼續在用戶故事點數預評估，項目燃盡圖使用，代碼質量，持續集成、自動化等方面進行深入的探索。

如同《敏捷革命》所說的那樣，Scrum需要實踐和專注，只有持續不斷地付出努力，才能達到新的狀態。我們在前進的路上，我相信，我們會越來越好！