如何實施 SCRUM ？

12-26

如何實施scrum？能重點介紹一些要點嗎？

如果嚴格按照書本上的 Scrum 法則一條條地看，那麼我們隊伍現在的做法也許根本不算 Scrum。不過好歹我們也被稱作 Scrum 一段時間了，我的資歷比不上前面的資深開發者，只能說一些目前的一點經驗。

經驗一：整個團隊必須理解 Scrum 的目的和限制。
如果管理團隊把 Scrum 當作一種新的管理流程，那麼這個理解絕對是錯誤的，而且有害。要正確理解 Scrum 的實施原則，需要從理解其設計目的開始。

我所理解的 Scrum 的目的在於兩點：

適應變化。Scrum 的一個基本假設，就是外部需求模糊而難以理解。Scrum 對此的理念是：讓客戶直接看到半成品，他們才知道自己要什麼。很多 Scrum 的原則都是圍繞如何解決這個問題的：比如每個 Sprint 結束時由 Product Owner 為客戶進行展示，又比如任務細化一般不超過一個 Sprint。理解了這一點，才會理解為什麼 Scrum 似乎總在變化，因為需求總在變化。
快速迭代。Scrum 的另一個基本假設，是團隊生存在一個快速變化且充滿競爭的世界。如果自己一年半才能發布一個新版本，而競爭對手半年就能發布，那麼幾年之內，我們就會被對手甩得遠遠的。Scrum 對此的理念是：發布即 Milestone（里程碑），寧可每次發布二十個功能發布五次，也不要在內部搞五個 Milestone 然後一口氣發布一百個功能。理解了這一點，才會理解為什麼 Scrum 會認為發布時砍功能是一種正常情況而非一種失敗。

要實施 Scrum，整個團隊至少必須取得共識，即以上兩點是不能商量的。流程必須為目的服務。如果隊伍相信增加前期溝通才是讓需求清晰起來的最好方法，或者相信發布的功能必須是大批量一次性，那麼請使用瀑布開發模式。

相應地，我們必須明白 Scrum 不能做什麼。我的理解可能聳人聽聞，仍是兩點：

因為發布周期縮短，團隊沒有能力保證作出的每一個決定都正確，很多開銷都必須花在試錯上；
快速發布實際上導致 Scrum 團隊的抗風險能力弱於瀑布模型團隊，因為一個人的離職或病假都可能對單一功能的進度造成影響，不利於短期頻繁發布。

Scrum 對此的解答是：不要試圖不犯錯誤，而是保證小的錯誤能被儘快發現從而不會釀成大錯。所以 Scrum 過程中總會有些不確定性，或者功能不合需求而返工，或者突然缺了人手導致一些單個功能必須延期完成。如果非要事先確定發布周期而且還得保證不許功能裁剪，請出門左轉找 CMM 認證：它可以把任務精確到每個對話框上該用什麼字體。前期計劃精確到這個粒度，什麼都可以在掌控之中。但問題是，我們必須用更長的發布周期來換。

理解了上面的內容，我們實施時就不會對某些形式性的東西過於糾結，比如 Burn down chart，比如 Scrum 撲克。需知形式服務於目的，而形式未必適用於每一個團隊，正如瀑布模型在每一個團隊中也都有差異。如果僅僅是因為團隊成員沒有在 planning meeting 上打撲克就認定這不是 Scrum，那麼未免愚蠢了些。反過來，某些看似煩人的「流程」卻不可或缺，比如每天的 15 分鐘 stand-up，如果我們明白它對交流方面的重要作用，就絕對不會認為它可以被省略。

舉個實際的例子，在我們的團隊里，我們強迫一周一個 Sprint。就我所知，即使在很多實施很成功的項目中，這種做法也是相當激進的。一開始我也不理解這一點，但實施了一段時間後，我開始認同這一條，因為一周的發布周期讓我們沒有機會把任務往後推，從而迫使我們儘快從瀑布模型中轉移出來。這對一個有著悠久瀑布開發傳統的團隊來說非常重要，但對別的團隊來說，就不一定了。

經驗二：正確定位隊伍中的 Scrum Master。
為什麼單獨提 Scrum Master？如果只是看書本和參加培訓，我相信多數人都會同意我的觀點，即 Scrum Master 或許是整個開發過程中作用最不清楚的角色：不參與需求分析、不參與代碼開發、甚至不參與任何人事問題，只有一句「去除阻礙」這種含糊的表述。但是，當我真正當起這個 Scrum Master 之後，才發現這個角色承擔的職責非常具體。比如：

確保流程執行正確。進入 Scrum 之後，很多團隊仍然會以各種方式走老路，比如有意無意地拉長 Sprint 周期，並以此區別計劃周、開發周和測試周，實際上是把原來三個月的瀑布開發周期變成了兩到四個星期的瀑布周期；又比如以開發時間有限為理由把自動測試開發任務縮減為手工測試。好的 Scrum Master 應該有能力發現並制止這種情況。——順便說一句，相信我，不要以為兩個星期的瀑布周期是個可行的開發計劃，我們不可能完成測試任務的。
制止官僚主義流程。典型的例子就是一個又一個的 spec/plan review 和 sign-off 郵件；又比如非要區分所謂 Unit Test、BVT 和 Functional Test：或許對一個圖形界面程序來說這兩者區別極大，可對於函數庫則幾乎沒有原則差別。合格的 Scrum Master 應該制止這樣的傾向。——不過我也得說，這一條我現在做得很差，還需要改進。
構建交叉知識結構。整個團隊的知識模型應該是各有專長但互有交叉的，而傳統開發的一個很重要的問題是知識結構不平衡，比如測試的只管測試，開發的只管開發。這種模式對於發布時間長的大團隊來說也許能接受，但對人手短缺又要求快速發布的小團隊則是致命的。好的 Scrum Master 應當能夠對團隊的決策具備影響力，確保不會讓某個任務陷入「只有一個人知道細節」的情況。——這一條在習慣了傳統瀑布開發模型的團隊中往往是最大的阻礙，需要時間改善。

但正因為上面的理解，我基本上不同意 Scrum Alliance 的教科書里關於 Scrum Master 的大多數表述。首先，Scrum Master 必須承擔一部分開發任務，因為沒有介入一線開發，很難想像 Scrum Master 會真正理解團隊的「痛點」。其次，Scrum Master 需要關注團隊的每一個人，不然隊伍可能由於所謂「自組織」的原則而隱藏一些問題，比如某個人過於專精某一項而忽略了和其它成員的交流。當然，也有些部門的 Scrum Master 只負責寫報告和推事情。這不是我共事過的任何一位 Scrum Master 的做法，而且我也可以很自信地說，這種 Scrum Master 在我們公司是生存不下去的。

Scrum Master，你是肩負著人類使命的人啊！嗯！（握拳）

最後，貼兩句最近剛學到的話：

50% percent of our decisions are wrong. Fail fast, learn fast. （我們作出的決定中， 50% 都是錯誤的。早早失敗，早早學習。）
No matter what you want to do, choose what is good for your team.（無論你選擇做什麼，選擇對你的團隊有利的事）

先聲明，說上面兩句話的哥們本人在我們隊伍里不算很受歡迎，但這兩句我很喜歡。在我眼裡，這兩句話指出了 Scrum 的所有實質。

共勉之。

如果你是一個程序開發者，Scrum這種目前當紅的敏捷開發方法，屬於必須熟練掌握的技能點。關於 Scrum，看這一篇就夠了~

我們公司的開發團隊，實踐Scrum的效果非常好。在項目開始之前，我們在內部做了一個 Scrum 的科普，非常適合這個問題，我稍加修改發在這裡，肯定能幫到大家。

一、角色分配和價值觀

我們先來看看，一個團隊實踐 Scrum 的角色分配▼

Scrum 中的角色結構非常扁平，有三種角色：

PO：Product Owner，產品負責人，確定「大家要做什麼」。互聯網公司的 PO 一般由相關的產品經理擔任；如果是為客戶做項目，PO 一般就是客戶負責人。
Scrum Master：Scrum的推動者，掌控大節奏的人。
Team：一般由多個 developer 組成，開發的主力。

三種角色有各自的責任，但三者間並沒有上司和下屬的關係。這正是 Scrum 區別於傳統開發流程的精華：

傳統的開發流程，是由領導拍板的中央集權制；
Scurm 是人人平等的民主制，每個人的能力都被信任，更加自主，能發揮出更高的效率。

Scrum 的價值觀▼

二、三大神器

Production Backlog、Sprint Backlog 和燃盡圖是三大神器。下面一一介紹。

Backlog 是 Scrum中的一個專用名詞，意思是待辦工作事項的集合。

1. Product Backlog (產品待辦事項列表)是量化的用戶需求，條目化地表達實際需要開發的需求。

2. Sprint Backlog（任務列表）是一次迭代中需要完成的任務，也是開發過程用得最多的Backlog，非常細化。

兩者區別見下圖▼

3. 什麼是燃盡圖？

我們每天累加所有任務的剩餘時間，將其標註在圖表上。用藍色的表示計划走向，紅色線則是實際走向，兩條線共同組成了燃盡圖。

比如下圖中的燃盡圖，一開始代表實際走向的紅線高於計劃藍線，說明開發初始，任務完成慢，可能遇到了困難。

三、Scrum 的四個會議

1. Sprint 計劃會

Sprint 計劃會就是大家坐下來，PO 向大家介紹排好序的產品待辦事項（Production Backlog），然後大家共同思考決定如何推進計劃，梳理出 Sprint Backlog 來完成後續的工作。

簡單點說，這是一個大家理解「需要做什麼」，然後討論「怎麼完成」，並形成待辦事項列表的會議。

2. 每日站會 Daily Scrum

大家在一起，自發地彙報三點：

從昨天Daily Scrum到這一刻，我完成了什麼工作？
從這一刻到明天的Daily Scrum，我計劃完成什麼工作？
是否有什麼困難阻礙了我的進展？

3. Sprint 評審會（Sprint Review）

在 Sprint 結束後，大家一起評審本次 Sprint 的產出。每個人都可以自由發表看法，協助產品負責人對未來工作做出最終決定。並根據實際情況，適度調整產品待辦事項列表（Product Backlog）。

4. Sprint回顧會（Sprint Retrospective）

在一次Sprint結束後，大家聚在一起開這個會，回顧一下團隊在流程和溝通等方面的成效。大家一起討論，哪裡完成得好，哪裡還需改進？

以上四種會議，都是大家集思共享的快速會議，注意控制好每次會議的時長。

四、用 Teambition 打造小而美的 Scrum 團隊

傳統的 Scrum，會用白板和 Excel 等工具。但正如前面所說，Scrum 不拘泥於形式，是探索更高效率的實踐，所以有不少團隊開始使用協作工具，在這方面我們選了 Teambition。

使用協作工具來實踐 Scrum，最直觀的感受就是，對 Backlog 的管理和會議活動管理非常方便，能更好地實現團隊協作、需求到研發的信息關聯與共享。比如 Teambition 中的「任務」看板功能，把所有任務及進程都「平鋪」開來顯示，實現了便捷的項目流程化管理；「分享」功能，大家在其中共享工作信息、總結知識經驗；「文檔」相當於該項目的共享協作網盤，大家能隨時訪問、更新共享資料；「群聊」則更像是該項目的微信群聊，支持項目成員隨時溝通想法，並且自動保留每一條消息。別再用微信溝通工作，讓工作的溝通發生在工作的平台上。

除了團隊的溝通與共享，協作工具在對 Backlog 上的管理也非常方便。

用 Teambition 管理 Product Backlog

用 Teambition 管理 Sprint Backlog ▼

不同 Backlog 間的聯動，從 Product Backlog中提取需求到 Sprint Backlog▼

關於實踐 Scrum，前面介紹了四種會議，用協作工具線上開會也非常方便，這裡以 Daliy Scrum 為例：每日立會可以通過在 TB 項目的日程中設置，Scrum的團隊成員都添加為參與者，將站會的日程設為每個工作日重複，並且提前15分鐘提醒大家▼

開 Sprint 評審和回顧會議時，可以將會議記錄在線記錄在分享中，並和日程關聯起來，方便大家查閱▼

以上是我們實踐 Scrum 的一些心得，通過共享與協作，在開發過程中提高了效率，這應該也是 Scrum 如今這麼受歡迎的原因。覺得回答有幫助，歡迎點贊支持~(?′ω`?)

Scrum 是眾多敏捷開發方法中的一種，它既是方法論，也包括了一系列預定義的角色、一系列的流程，以及一系列的實踐經驗。那麼踐行Scrum 到底是應該堅持以理論為準繩，還是從實際角度出發，有所捨棄和調整？一個可運行的 Scrum 流程的主要步驟是怎樣的？

首先聊聊敏捷開發的價值觀
對於敏捷開發來講，有人說是流程、是方法論是工具，但對於我來講它更是一種精神，它並沒有局限在流程、方法、工具上。敏捷軟體開發的目的就是解決需求中的變化和中的不可控因素。
當時提出敏捷開發的這個人或者這個群體，提出來的是敏捷開發的四個價值觀：第一，個體的互動要高於流程和工具；第二，可工作的軟體要高於詳盡的文檔；第三，客戶的合作高於合同談判；第四，響應變化高於遵循計劃。這四點價值觀是最能體現敏捷開發的核心的東西，其精髓就是擁抱變化，而不是控制變化。

了解Scrum 是什麼很重要
Scrum 是什麼？它既是方法論，也包括了一系列預定義的角色、一系列的流程，以及一系列的實踐經驗，包括需要的文檔。我提出的一個觀點是，對於我有用的就做，對於產品、項目沒有用的就不做，但是Scrum 實際上不是這樣的。你想做到Scrum 有些東西是必須要做的。所以我也希望大家能夠自己批判性、靈活用它，而不是死板用它。

Scrum的主要角色
Scrum 主要定義了三個角色：Scrum Master，Product Owner，Development Team 。
Scrum Master 不是Project Manager，他的主要的工作是要保證這個團隊執行 Scrum 的順暢。Product Owner 是真正對產品負責的人。如果我們是做產品研發的話，產品經理就是Product Owner。如果我們是做項目開發，客戶就是Product Owner，這也體現了我們剛剛提到，我們並不是和客戶去談判，而是真正把客戶放在我們的這種流程中，真正與他合作。第三種 Development Team 就是幹活兒的。
所以在Scrum 裡面沒有管理者的概念。另外，Scrum 裡面實際上所有的真正為最終產出的軟體付出的，都叫Development Team。這個地方也體現了一個Scrum 的觀點，就是它希望能夠打造Cross-Functional Team，即在這個團隊中的所有人可以做所有的事情，每個人都是Development Team。

Scrum的開發流程

Step1. 需要一個 Vision
真正Scrum 的流程是什麼樣子的？首先，我們需要有一個Vision ，就是我們所做的產品或者所做項目的願景。這個需要所有Team Members，包括Product Owner 一起確定，然後大家朝著同樣的目標前進。

Step2. 維護Backlog
Vision 出現後，Product Owner 會維護一個Scrum 中我們提到的第一個文檔，即 Backlog。它可以理解成我們從產品當中，從各個角度收集的需求， Product Owner 要做的事情就是維護Product Backlog，並且將Backlog 一條一條的按照優先順序排好順序。Product Owner 是唯一有權利維護這個列表的人。
這個時候合理利用工具，就能免去寫文檔的的這一步，可以直接將需求通過任務的方式收集，每個需求就是一條任務，Product Owner 可以給任務打標籤來標示優先順序。

Step3. 拆分Sprint
隨後我們會針對這個Scrum 把它拆分成一個個的Sprint ，就是開發周期。然後將 Backlog 裡面的項目添加到Sprint 中去，成為Sprint Backlog。每一個Sprint 開始的時候，需要進行一個Sprint Plan。

Step4. 運行Sprint Plan
Sprint Plan 就是整個團隊一起，通過Backlog 從優先順序最高的這個item 開始挑，挑出Product
Owner 對Backlog 進行介紹。緊接著的是，大家將Backlog 拆分成單個的Task，每一個成員在每一天的工作當中領Task，完成Task。

由此可見，在完美的Scrum 裡面，是沒有任務指派一說的。每個成員會根據任務、完成度，去及時更新任務的狀態。為了讓大家了解整個項目的進度，Scrum會引入白板（在牆上或者在板子上釘好多的小紙條，讓大家明確項目進度和任務完成情況）。
說到這個，我可以向大家推薦一個工具：Worktile。這個工作可以在Worktile 的看板視圖上做，看板視圖非常像真正的白板。通常情況下，在 Scrum 里的白板列表只有三列：TO DO、IN PROGRESS，以及 DOWN。這個在Worktile 裡面就十分簡單，你可以打標籤、分配人、設置截止時間、在任務上進行評論，並且任務可以直接在列表間拖拽，從而推進流程的進展。並且這一切都是實時的，所有人都能看到。

Step5. Daily Scrum
在Scrum run 起來之後，還有一件事情是Daily Scrum 。在 Daily Scrum 中，每個成員只需三件事情：我今天做了什麼，明天要做什麼，有什麼是我搞不定的。Daily Scrum 一般來說會控制在15分鐘之內，而且所有的成員必須要站著開會。

Step6. Sprint Rview
當Scrum 結束後，我們會產出一個產出物。這個產出物在Scrum 裡面，可以是一個可以運行的軟體，也可以是一個可展示的功能。之所以這麼說是因為有一個Sprint Rview 的階段，我們需要通過Demo 在Product Owner 以及其他的Stake Holders 面前，現場演示你做好的東西（而不是給大家講你做了什麼）。

Step7. Retrospective
在Sprint Review 結束之後就是Retrospective。我們整個團隊的人都要坐下來聊一聊，我們的Sprint 做得好不好，有哪些地方需要修改。

敏捷實際上就是一種理念，然後基於這個理念提供了一些方法和實踐，在我眼裡它意味著持續改進。所謂持續改進就是在產品設計上的持續改進，包括那我們盡量快速的迭代。我們每一個 Scrum 的Sprint 都不會太長，保證我們的每一個Scrum 都能提供給客戶一個可運行的版本，能夠快速得到客戶的反饋。同時在產品區改進中，架構設計也會持續的改進。我們的設計並不是上了之後就把所有的東西都想好，而是基於我們產品的不斷改進，在架構上持續的改進。敏捷本來就是持續改進，改進敏捷的流程，並用敏捷開發的精神改變我們自己的開發流程。

我個人理解的敏捷開發的精髓，就是我們永遠只做對產品和項目有用的事情 。

工具的作用（利益相關兼具乾貨）

上文是對Scrum 做的概要介紹，我們可以審視流程中的一些環節：Backlog 階段需求的收集和優先順序排序、Sprint Plan 階段任務的拆分、領取和進度跟蹤、Daily Scrum 的統計……這些環節其實都需要一些工具的輔助，甚至可以說，整個Scrum 流程都可以通過工具的輔助來更好的運行。

依據Worktile 本身看板管理的特性和任務驅動的方式，可以很好的將一些進度和概要信息展示出來：每個需求可以直接創建一個任務，任務標籤可以標示優先順序，看板上的列表直接就能展示進度和階段，也能很好地實現整體進度和個人進度的統計。並且在伺服器監控和代碼共享等具體的研發問題上，Worktile 也通過接入對應的監控服務和代碼託管平台（比如github），得以一站式的解決。通過對比以前的研發進度和使用Worktile 做研發管理之後的迭代速度來看，整體的研發效率提升50%是很容易做到的。

對於希望梳理研發管理體系或者實施Scrum 的團隊，可以[點擊了解&>&>](解決方案 - Worktile)

我來分享點拙見。分別在通信行業和互聯網行業實踐過幾年的Scrum，有一些體會。
首先，敏捷被很多人和團隊視為對傳統項目管理的否決，視為不要流程，不要規則的依據。項目管理本身是一門高深的，非常有價值的學問。不懂項目管理的人做敏捷常常做成野雞流程。

Scrum的精華有兩點，第一是短迭代，第二是自組織。
短迭代讓團隊可以形成節奏感，並在每個迭代後有機會進行回歸，並在下一個迭代中提高。相比傳統的瀑布流程，因為缺乏這樣的反饋機制，團隊的改進相對困難。
自組織的目的是讓團隊對目標進行自我承諾，激發團隊最大的能量以達成目標。這是在公司這種權威組織中實行的小規模民主激勵。對於自尊心較強的工程師團隊，相當有效。不過也有缺點，那就是團隊自我意識可能過強，導致跨團隊合作出現問題。

但如果僅僅實現這兩點，Scrum的結果可能是非常糟糕的。特別是短迭代造成兩個負面後果：
第一，短迭代傾向於產生短期設計，在將來的迭代中需要經常重寫。
第二，短迭代導致沒有時間進行全面的回歸測試，導致bug數量上升。

為了有效的解決這兩個問題，Scrum必須伴隨一些關鍵的工程實踐。
第一，最重要的，是測試自動化。無論是單元測試還是功能測試，都是在短迭代下保證質量的重要，甚至是唯一手段。
第二，重構。有了自動化測試，敏捷團隊應該勇敢的不斷重構代碼，消除技術債務
第三，持續集成。有了自動化測試，持續集成可以在最短的時間內報告問題，並要求團隊將CI的錯誤作為最高優先順序立即處理。

所以可以看出來，自動化測試是scrum最重要的實踐之一。一個沒有自動化測試的組織，採用scrum雖然也可以受益，但達不到「高績效團隊」的水準。

在下已多年不參與SP的話題。但見題主求知心切，特將壓箱底的法寶傾囊相授與你：

最重要的一點：
每天早上把你的夥計們弄來站著開會

第二重要的一點：
找塊白板，上面貼滿五顏六色的紙條

第三重要的一點：
把工位隔斷統統拆了，買幾張長條桌子即可

然後你的團隊甚至整個企業就敏捷啦，SCRUM啦。

從此以後，就可以享受以下福利：
一、不用設計、不用建模、不寫文檔；
二、四處參加party、各種網站上發雞湯、Title升級為XX認證專家；
三、就算項目做成狗屎，也跟你無關，因為你已經敏捷了；
四、誰要不服，掄起Agile和Scrum大棒就砸。

哦，還有最最重要的一點，特補充於後：
一定要多拍照片髮網上（包括但不僅限於站著開會的碼農、白板上的紙條、倆頭湊一塊兒pair programming、沒有工位通鋪似的Office、或者team一起開香檳最次也得舉個啤酒杯）

切記，切記。

最精簡Scrum配置：

1. 一個Backlog，記錄要做哪些事情，大事小事都往裡堆；

2. 一個Scrum Master，負責協調和商量每個Sprint做啥；

3. 一個Sprint計劃，簡單說就是一個Sprint多長時間，從幾號到幾號。

4. 一批程序員。

結束了。

什麼？要Product Owner，真的項目中大多沒這個角色，讓Scrum Master去找相關人吧。

多列圖表？不需要用什麼工具，拿小紙片貼在牆上也能用。

這就是最簡單配置，用了你就知道，項目管理主要在人，工具都是輔助。

之前我們公司內部的一位大神作過分享，主題和這個問題幾乎一樣，果斷貼過來。

前言
BB-Talk 是什麼？
BB-Talk 是由Worktile 特別推出的線上分享活動，聚焦互聯網時代更高效的工作流，橫跨TMT、電商、律師、教育等各行業，覆蓋研發、產品、設計、市場、運營、HR、行政等各職業。
每期邀請一位相關領域的大牛嘉賓，通過微信群內的語音、文字、圖片等形式，分享乾貨、自在交流。
本文為6月14日BB-Talk 第一期嘉賓分享與互動提問的總結。

本期嘉賓

徐子岩，Worktile 首席科學家，軟體架構師，連續5屆微軟MVP，著有《實戰Windows Azure》。

內容概要

Scrum 是眾多敏捷開發方法中的一種，它既是方法論，也包括了一系列預定義的角色、一系列的流程，以及一系列的實踐經驗。那麼踐行Scrum 到底是應該堅持以理論為準繩，還是從實際角度出發，有所捨棄和調整？一個可運行的 Scrum 流程的主要步驟是怎樣的？在這個過程中，工具應該扮演什麼角色？Worktile 怎樣做到了讓原本的Scrum 效率提升50%？這些，在徐子岩近一個小時的分享中都有著重提到，幫助大家快速地梳理出了Scrum 的關鍵性要素。

分享內容

我是Worktile 的徐子岩，Worktile 是為互聯網時代的企業打造的協作辦公平台，支持企業內部溝通、電話會議、任務管理、日程安排、企業網盤和辦公應用，連接企業內外部一切服務。而作為一個效率平台，為用戶帶來便利是Worktile 最基本的屬性，同時作為一個研髮型的企業，我們在研發方面有深厚的積累和經驗。近期，Worktile 從我們超過30萬的使用企業中找到30支研發團隊、與之深度溝通，重裝打造了從 研發流程管理 到 工作效率評估 的一站式研發解決方案。其中就包含了我今天要與大家聊的關於「Scrum 到底怎麼玩兒」。

敏捷開發也有價值觀？

對於敏捷開發來講，有人說是流程、是方法論是工具，但對於我來講它更是一種精神，它並沒有局限在流程、方法、工具上。敏捷軟體開發的目的就是解決需求中的變化和中的不可控因素。

當時提出敏捷開發的這個人或者這個群體，提出來的是敏捷開發的四個價值觀：第一，個體的互動要高於流程和工具；第二，可工作的軟體要高於詳盡的文檔；第三，客戶的合作高於合同談判；第四，響應變化高於遵循計劃。這四點價值觀是最能體現敏捷開發的核心的東西，其精髓就是擁抱變化，而不是控制變化。

敏捷開發方法有很多種，我們今天主要講的就是其中的一種：Scrum。

了解Scrum 是什麼很重要

首先我們說Scrum 是什麼。它既是方法論，也包括了一系列預定義的角色、一系列的流程，以及一系列的實踐經驗，包括需要的文檔。我提出的一個觀點是，對於我有用的就做，對於產品、項目沒有用的就不做，但是Scrum 實際上不是這樣的。你想做到Scrum 有些東西是必須要做的。所以我也希望大家，在聊完Scrum 之後，能夠自己批判性，靈活用它，而不是死板用它。

Scrum的主要角色

Scrum 主要定義了三個角色：Scrum Master，Product Owner，Development Team 。

Scrum Master 不是Project Manager，他的主要的工作是要保證這個團隊執行 Scrum 的順暢。Product Owner 是真正對產品負責的人。如果我們是做產品研發的話，產品經理就是Product Owner。如果我們是做項目開發，客戶就是Product Owner，這也體現了我們剛剛提到，我們並不是和客戶去談判，而是真正把客戶放在我們的這種流程中，真正與他合作。第三種 Development Team 就是幹活兒的。

所以 在Scrum 裡面沒有管理者的概念 。另外，Scrum 裡面實際上所有的真正為最終產出的軟體付出的，都叫Development Team。這個地方也體現了一個Scrum 的觀點，就是它希望能夠打造Cross-Functional Team，即在這個團隊中的所有人可以做所有的事情，每個人都是Development Team。

Scrum的開發流程

Step1. 需要一個 Vision

真正Scrum 的流程是什麼樣子的？首先，我們需要有一個Vision ，就是我們所做的產品或者所做項目的願景。這個需要所有Team Members，包括Product Owner 一起確定，然後大家朝著同樣的目標前進。

Step2. 維護Backlog

Vision 出現後，Product Owner 會維護一個Scrum 中我們提到的第一個文檔，即 Backlog。它可以理解成我們從產品當中，從各個角度收集的需求， Product Owner 要做的事情就是維護Product Backlog，並且將Backlog 一條一條的按照優先順序排好順序。Product Owner 是唯一有權利維護這個列表的人。

在Worktile 中，其實就免去了寫文檔的的這一步，可以直接將需求通過任務的方式收集，每個需求就是一條任務，Product Owner 可以給任務打標籤來標示優先順序。

Step3. 拆分Sprint

隨後我們會針對這個Scrum 把它拆分成一個個的Sprint ，就是開發周期。然後將 Backlog 裡面的項目添加到Sprint 中去，成為Sprint Backlog。每一個Sprint 開始的時候，需要進行一個Sprint Plan。

Step4. 運行Sprint Plan

Sprint Plan 就是整個團隊一起，通過Backlog 從優先順序最高的這個item 開始挑，挑出Product
Owner 對Backlog 進行介紹。緊接著的是，大家將Backlog 拆分成單個的Task，每一個成員在每一天的工作當中領Task，完成Task。

由此可見，在完美的Scrum 裡面，是沒有任務指派一說的。每個成員會根據任務、完成度，去及時更新任務的狀態。為了讓大家了解整個項目的進度，Scrum會引入白板（在牆上或者在板子上釘好多的小紙條，讓大家明確項目進度和任務完成情況）。

但是現在，因為我們有了Worktile，這個工作不用在白板上做，可以在Worktile 的看板視圖上做，這個看板視圖非常像真正的白板。通常情況下，在 Scrum 里的白板列表只有三列：TO DO、IN PROGRESS，以及 DOWN。這個在Worktile 裡面就十分簡單，你可以打標籤、分配人、設置截止時間、在任務上進行評論，並且任務可以直接在列表間拖拽，從而推進流程的進展。並且這一切都是實時的，所有人都能看到。

Step5. Daily Scrum

在Scrum run 起來之後，還有一件事情是Daily Scrum 。在 Daily Scrum 中，每個成員只需三件事情：我今天做了什麼，明天要做什麼，有什麼是我搞不定的。Daily Scrum 一般來說會控制在15分鐘之內，而且所有的成員必須要站著開會。

在Worktile 裡面，工作台就可以對自己的個人任務進行集中的匯總展示，可以清晰的看到自己最近完成的任務以及接下來需要完成的工作。

Step6. Sprint Rview

當Scrum 結束後，我們會產出一個產出物。這個產出物在Scrum 裡面，可以是一個可以運行的軟體，也可以是一個可展示的功能。之所以這麼說是因為有一個Sprint Rview 的階段，我們需要通過Demo 在Product Owner 以及其他的Stake Holders 面前，現場演示你做好的東西（而不是給大家講你做了什麼）。

Step7. Retrospective

在Sprint Review 結束之後就是Retrospective。我們整個團隊的人都要坐下來聊一聊，我們的Sprint 做得好不好，有哪些地方需要修改。

工具的作用

上面是對Scrum 的流程做的概要介紹，我們可以審視其中的一些環節：Backlog 階段需求的收集和優先順序排序、Sprint Plan 階段任務的拆分、領取和進度跟蹤、Daily Scrum 的統計……這些環節其實都需要一些工具的輔助，甚至可以說，整個Scrum 流程都可以通過工具的輔助來更好的運行。

在和一些研發企業做過深入交流並總結我們自己使用Worktile 做研發管理的經驗之後，我們整理出了一套使用Worktile 做研發管理的解決方案，涵蓋了需求管理、敏捷開發、bug 管理、代碼共享、部署運維、研發周報和效率評估。其中貫穿了敏捷的思想和Scrum 的一些精髓，並且根據研發過程中的實際情況，做了針對性的調整，對於希望梳理研發管理體系或者實施Scrum 的團隊有著非常好的借鑒意義。

有需要的同學，可以點擊了解&>&>

關於Scrum的個人心得

通過上面的介紹，可以看到通過Scrum 這種方式能夠把一個真正大的軟體，拆分成小段，每一個成員都對工作非常清楚，所有的數據都是經過大家充分討論、達成共識的。而且每一個任務，都是成員通過優先順序，自己去領的。在Cross-Functional 的工作團隊中，每一個人的工作能力、技能都是一樣的，任何人領任何的任務，都能達成一致的效果。

但是理想跟現實之間永遠是存在差距的，今天我們講的都是理論狀態下的Scrum 的樣子。真正執行起來之後，會出現各種各樣的問題。你會發現有的時候這個東西是不可能實現的。那麼就面臨的是說你們這種團隊，或者說我們的這種研發團隊究竟是死板的去追著Scrum 的原則來做呢？還是說我們自己也敏捷一把，把Scrum 也敏捷掉。

最後，我個人理解的敏捷開發的精髓，就是我們永遠只做對產品和項目有用的事情 。

本期最佳提問人：@仕星中醫藥大數據（BB-Talk 每期會挑選一位最佳提問人，並給予大禮包獎勵！）

1.你們之前做到過Scrum 嗎？@小悠

徐大神：開始做會很彆扭，等做了四到五個Sprint 之後就會有一種節奏感和默契感。Scrum 對於團隊來說重要的是找到節奏感，並且做的好的團隊一定不會加班。

（小蝸語錄：用了 Worktile 不加班哦）

2.不能演示的Task，如何 Review？@Nemo 前聯想PM

徐大神：除了task 還有很多可Review 的東西，比如文檔，一定要Review 成果性的東西。

3.產品老覺得我們不願意做他們的需求，抵制情緒強烈，怎麼破？@Rex.M AZT PM

徐大神：很好的例子，把產品拉進Team，因為不同的部門產品、測試、開發都有不同的事情和進度，都不願意被打亂計劃。而Scrum 里沒有部門之分，大家都在一個 Develop Team 裡面，更透明的方式就能夠更好的溝通。

（小蝸語錄：用Worktile 協作，更透明，無縫溝通）

4.如何讓團隊成員更主動去做事，如何在應用項目中推行敏捷開發？有時很艱難，格格不入。@王小中科軟程序員

徐大神：預設成員都是積極主動能做好工作，這是前提條件，其次要重視管理的藝術，對於成員的保護和激勵。有的項目不適合做敏捷開發就不要勉強。可能有的項目更適合使用瀑布式流程，找到項目的對的方式去做也是敏捷的精髓之一。

5.如何讓水平高低不同的團隊整體提高協作水平，從而提高產品質量？@高杉 CBEC 產品運維

徐大神：確實一開始做的很痛苦，做了幾個Sprint 就會好很多，大家看到這種開發模式的好處的時候，在不爽的地方對Sprint 改進，不斷演進，讓大家喜歡上這件事。讓團隊成員自己去領自己想要的任務，提倡成員去領感興趣、想要做、想要挑戰的那部分工作，同時讓工作更透明化。

6.測試用例有專人負責寫嗎？@我在睡覺 http://openrec.tv

徐大神：在之前的項目中有個要求是不允許手動測試，只能自動化測試，有測試去寫自動化測試代碼。每個人都有分工和專長，在Scrum 裡面也會有一定分工。

7.測試人員在敏捷團隊中是什麼樣的角色？如何能更融入？@王晴開目開發

徐大神：盡量讓測試人員也進入開發，進入自動化測試的範疇內，如果測試願意，也可以Take 一部分開發的工作，這都是可以的。

8.目前團隊還是以職能分工，所以不同部門之間的矛盾和分歧怎麼解決？@Rex.M AZT PM

徐大神：推進敏捷開發需要的是管理層的支持，部門間有了分歧需要管理層切實去協調和協助，可以選擇把重要的人加進Scrum Team 里，他感同身受的時候也會承受一部分壓力，不同部門的 Leader 互相了解對方才能更好地配合。

9.Product item 拆成 Task 的力度如何控制？用Worktile 如何實現比較方便？@仕星中醫藥大數據

徐大神：Task 盡量在一天內完成，一個 Product item 必須要在一個 Sprint 內完成，否則搞的太大就失去敏捷開發的意義了。

10.技術團隊管理的問題，如何處理團隊內任務負荷不均以及由此造成的矛盾和衝突？@凡

徐大神：在任務是被強制指派可能出現這種情況。如果是Scrum ，Cross functional ，至少做到一個模塊兩三個人都能 Take。而後者，如果有人沒法做自己想做的東西可能出現，Scrum 提倡自己去Take 自己想要的任務，一般來說就不會有不滿了。

11.任務由開發人員完成後是否需要其他人來審核任務完成度？@我在睡覺 http://openrec.tv

徐大神：在Scrum 里是沒有的，啟動之後，整個team組確定 DOD ，怎麼判斷一個任務算完成了，是整個 Dev Team確定的，做這個功能的人符合要求，就可以他認為完成了這部分工作。而最終能不能Release 出去還是在Sprint Review 時由Product Owner 看 Demo 來決定是不是可以Release，如果不可以，需要再新開一個Work item，重新改模塊。

我在公司不同的部門都推動過敏捷轉型，有成功也有失敗，下面就說說我的體會吧。

要在部門內部做調查，明確現在的狀況是怎樣的，有哪些痛點。

即使你在部門內已經工作多年，也不要忽略這一步，因為我們後面要推動Scrum，必須要有明確的事實為基礎，堅實的統計數據做支撐。盡量多和員工做一對一的訪談，了解他們對團隊現狀的看法和對敏捷的理解，識別其中對變革有熱情的人，他們在未來會幫到你很多。收集到的數據可以作為未來衡量Scrum實施效果的基線（baseline）。

要能夠同時獲得管理層和團隊兩方面的支持。

這對成功實施敏捷非常重要。要分別對領導和團隊進行培訓。對管理層方面，要針對Scrum實施目標和老闆達成一致。對於團隊，要讓他們理解實施Scrum的目的以及你的計劃，並在一開始要對Scrum有初步了解。

要把對變革有熱情的，有影響力的團隊成員組織起來。

比如說成立敏捷實施小組。先發動這些人，讓他們在敏捷實施過程中成為領頭羊。另外，Scrum實施本身也要以Scrum的方式推進，。

容易的、立竿見影的實踐可以先做。

比如說持續集成。對於計劃會，每日站會，回顧會等等的日常實踐先做到有形，再逐步做到神形兼備。這個需要敏捷實施小組日常做大量的工作。

團隊管理方式要從命令與控制式逐步轉換成支持、服務式。

這個是形成自組織的重要保障，一定要促成這一轉變。

首先當然是需要自己先把Scrum給吃透，至少從理論知識方面先做足準備，這方面有很多不錯的書可以先看看，例如小部頭的《Elements of Scrum》，中等規模的Ken Schwaber的書例如《敏捷軟體開發——使用Scrum過程》、《Scrum敏捷項目管理》等等，以及更大部頭的Mike Cohn、Craig Larman他們的書。

其次呢，如果想驗證自己的知識了解得如何了，可以先做做http://scrum.org的免費公開測試題目：http://www.scrum.org/Assessments/Scrum-Open-Assessment。想進一步測試的話，可以選擇參加http://scrumalliance.org的CSM、CSPO培訓課，或者是http://scrum.org的PSM、PSPO培訓課，課程都有進一步的測試，可以驗證自己的知識。

此時就可以開始著手在自己的團隊內開始嘗試了，建議此時不要急著鋪開大範圍推廣，因為Scrum框架本身雖然簡單，但能夠在實地產生實效，全看調整實施的功力。

在開展Scrum方式的過程中，可以多多加入各種敏捷和Scrum的社區和大家交流，大家主要在Yahoo Groups和Google Groups上面討論交流的比較多；還可以多參加一些本地敏捷社區的聚會活動，見見其他Scrum實踐者，和他們多交流交流心得，看看他們是否也有相同的疑問和問題；另外就是，建議參加一些業內大會，如果在上海，可以考慮Scrum Gathering，北京的話可以考慮敏捷中國，其他地區可以考慮敏捷之旅，等等；最後，當然，如果有足夠的預算支持，建議邀請一些有經驗的實踐者參與更深入的交流，或者是聘請外部敏捷諮詢師，會很有幫助（我在惠普的時候，我們團隊就是專門對外提供敏捷諮詢服務的）。

最後就是，按照Scrum自身的方式來看待Scrum的開展，通過檢驗和適應不斷地觀察開展Scrum的過程和變化，進行相應的調整，即可。

這個問題比較大，首先需要知道你和被實施的團隊中是什麼關係？
如果是團隊負責人，這個我認為就相對難度小一些，只要你對scrum有較深的理解，相信可以穩步的做好。
如果你是團隊外部的人，難度就要稍微大一點，你需要對scrum有很深的了解，並且要有實際的實施經驗。
建議幾點：
1.明確自己的出發點：實施scrum是為了幫助實施團隊解決問題，而不是證明scrum是有用的，站好位置，至少就減少了一大部分難題
2.看重差異，了解目前團隊中的難題
3.通過解決問題的方式，將scrum引入
a）做好鬆土--對團隊成員作知識和理念上的培訓
b）建立信心--持續的進行scrum的交流，對團隊中遇到的問題進行關注和解決
c）度量價值--做好數據的度量，例如質量變化，計劃符合度等等

以我的經驗來說，實施Scrum最難的不是方法的改變，而是文化的改變。自己首先要吃透，了解Scrum之前先要了解整個Agile家族的文化，產生的背景，價值，適用場景等等，然後了解Scrum這一具體方法的框架。如果自己可以很好的闡述為什麼要使用Scrum，以及Scrum的基本流程框架，基本上知識上已經做好了先期的準備。接下來要評估一下是不是要轉變成Scrum，因為Scrum對項目，團隊，組織文化都有一些要求，一定要將轉變基於現有的環境定製化的進行。我看到的很多Scrum都是結合自身定製的，或者講只是進行了部分的Scrum轉變，其實這些都沒有問題，能夠發揮效力，產生價值就行。項目本身的特質，決定了採取什麼樣的軟體開發過程，什麼樣的軟體開發過程決定了要匹配什麼樣的團隊和項目規劃以及項目管理的整體框架。Scrum實施操作中的幾個要點：1. Sprint的節奏，即多長時間周期一個Sprint，這個節奏一旦確定，不要輕易改變。2.把團隊按照需求解決方案和開發測試的方式拆開，分成兩個Scrum團隊來管理。需求及解決方案的確認一般比開發測試提前一個Sprint周期。3.Sprint開頭第一天，花點時間把需求和開發團隊理清楚，不要急著動手。4. 每天的Scrum的會議一定要定時開，讓成員主說，時間一定要控制在15分鐘以內，避免溝通蔓延。5. 每天的掙值要通過更新Burndown chart看清楚。6. 每個Sprint結束要回顧，一方面是展示Sprint成果，更重要的是總結最佳實踐和經驗教訓，持續改進，這個在團隊剛剛接觸Scrum的時候尤其重要。主要就是這幾點吧！

先潑你一攤冷水吧，實施scrum很困難。無論是對上層還是下層，你都得好好去說服和培訓他們，否則，一定做不好！

說點我的故事作為反例吧。

今年有個項目，管理層覺得需要快，所以對項目經理說要搞Agile。於是發生了下面的事情：

項目經理不懂Agile，為了討好上層，買了一堆白板，貼了一堆的紙條，發了一堆所謂的backlog。沒有制定驗收的標準，當然項目經理自己也不碰產品，所以也就呵呵了。
因為項目經理不懂Agile，所以也就沒有做Velocity，也沒有嚴格按照Scrum去分小組搞Daily Update，仍然搞的是Waterfall的全體大會。每天早上都需要耗費1個多小時開會。後期則因為隊員投訴太多，會議都取消了，只留下一個一個星期一次的全體大會。
因為項目經理不懂Agile，所以沒有迭代出build，每次都是為了要給上層Demo才去出一個。當然，那一定是個非常不穩定的build。
由於在Waterfall浸淫太深，大部分隊員都只會死守自己的那個崗位。開發的不想做測試，也不想跟測試溝通，只想code完且review完就算了。而測試的人因為之前啥技術都不怎麼懂，既做不來代碼審議，也做不來自動化測試。最大的問題是，公司的整套流程和工具就是為了waterfall而設計的，每次check in，每次review都需要一堆的設計文檔，一堆人的review，每個新的特性都得開會開會開會，否則根本不能check in。雖然本公司印度那邊的人宣稱公司一直是Agile，但是我從來不知道有哪些項目是搞Agile的。
對Agile這個詞的理解，大部分人都以為敏捷就是快速開發和交付，我只能說呵呵了。Agile不應該被翻譯成敏捷，應該翻譯成「快速響應與調整」。因為項目經理和部分管理者覺得敏捷就是要「快」，所以搞得經常加班且身心疲倦。如果不能說服管理層敏捷的目的是為了早試錯，早反應，早超生的話，我建議還是waterfall吧。
上層的人也很少過來抓項目或過來看項目是如何的，雖然上層的人來自某些大公司。
哦，還有，我們的敏捷項目可是沒有Scrum Master的哦，因為項目經理覺得自己啥都懂，完全都是按照他想的去做的。別的開發經理或者測試經理想插嘴都不行。我的測試經理被挪出了郵件組，每次開會都不叫他。當然最後上層覺得這個項目似乎很混亂，才把測試經理和開發經理加到某些會議去，當然，郵件組還是沒有加。哈哈。

下面是我的經驗總結：

如果你的項目是需求已定，且基本相當於copy paste的，我建議走waterfall，或者學工廠的模式，設置人開發，集成和測試。可別以為這種項目沒有哦，我們公司大部分項目就是如此。
如果你的人員都不懂Agile，且技能不能交叉的，建議你換血或者精挑某些人，否則會累死你！除非你覺得這些人學習能力都不錯。我所遇到的問題就是，測試的不懂開發，開發的不懂測試，配置環境的事情基本沒多少人管。
去說服上層管理人員，一般上層管理人員對大詞都是一知半解的，什麼大數據啊，什麼雲啊，什麼敏捷啊，他們幾乎都是根據營銷的數據來覺得這個是如何如何的，至於實際嘛，呵呵。
找個有權力且聰明的人去做Scrum Master，尤其是在中國的環境下。

建議把Scrum分成兩部分，1是Scrum流程，比如計劃會議、每日會議、燃盡圖、回顧、用戶故事、撲克估算等等，2是Scrum團隊，三個典型的角色。
建議先從Scrum流程開始，然後考慮是否採納Scrum團隊典型角色，不採用Scrum典型角色，也是可以執行Scrum流程的。

關於Scrum是什麼、為什麼、怎麼辦，我推薦上Lynda看Doug Rose的視頻Agile at Work系列。如果你覺得網上Scrum相關內容冗長、空洞、不知所云、讀起來助眠效果好，那一定要看他的視頻。認真的說，Scrum是無法在一篇知乎回答的篇幅里（負責任的）講完的。

華為說的「先僵化、後優化、再固化」適合Scrum也適合其他開發流程。我想從這個角度說怎樣實施Scrum。一般來說，實施Scrum遇到的問題有：

有資歷的員工嫌麻煩，不耐煩
沒資歷的員工不嫌麻煩，但也不懂Scrum
Scrum紙面寫的有些在實際情況里不適用。負責人覺得必須按實際情況調整，調整完了面目全非，已經不算Scrum了自己還意識不到

以上三點導致Scrum逐漸走形、脫離初衷，反而變成了浪費時間的走形式。

「先僵化」是說你們先別急著「優化」。先理解後修改、先熟練後創新。先『故意』脫離實際情況、完全照書本練習熟練了。只有這樣才會擺脫舊習慣、進而搞懂Scrum，只有懂了Scrum你才知道怎麼改Scrum使之適配自己的團隊。哪怕你改的每日Scrum是下班才Stand-up（如我們組），那也完全OK：你知道你在做什麼、為了什麼。如果沒親身實踐過那些教條，那你所謂的「適配」幾乎都是基於想像，而不是基於經驗。「先僵化」是說你要先懂得精髓。

「再優化」是說不可以教條主義，一定要按實際情況適配。如果事無巨細都按照文檔去做，那團隊很快會被逼瘋的，工程師們一天也不用干別的了。優化這步是最考驗負責人的智慧的，比如一個組在做2個項目，彼此沒關係，互相聽不懂，那就拆開分2個Scrum做；根據Scrum Points算Velocity啥的麻煩，你就可以把剩餘小時數當做Scrum Points（如果你隊友都很靠譜，那麼Velocity就不會怎麼變，你就可以這麼簡化），然後去畫Burn Down圖。

「再固化」是說，你優化的過程會做不同的嘗試，這些嘗試有的效果好有的效果差，你試了一段時間覺得差不多了，就要固化這套流程。固話是指要讓所有新老員工知道這套流程，知道我們為什麼這麼做、以及怎麼做，且你不該太隨性的改變流程了（那是自降威嚴）。知道為什麼這麼做會解決抵觸情緒的問題，知道怎麼做是省去日常的溝通成本。為什麼軟體開發要有個流程呢，就是省去你告訴每個員工這時候該幹啥、該怎麼辦的時間，讓大家彼此有個默契：我信任你的Scrum Board上面的東西是更新過的，我不需要每天告訴你去更新一下進度。每個人各執其責，像習慣一樣自然。無需提醒，我知道我該幹啥、也知道你會幹啥。習慣了，做得就快，就可以省出時間寫code。

「先僵化、再優化、再固化」是說給誰的呢？是說給ScrumMaster的。得ScrumMaster者得天下。因為ScrumMaster這個角色要求對Scrum有足夠的知識，且不兼任組裡的老闆，且非常會與人溝通。ScrumMaster不可以是老闆，是因為如果本身就是管理角色，那大家會為了給老闆留下好印象而刻意「優化」Scrum Board上的數字，讓人覺得：啊，進度好棒棒。只要Scrum Board上面的數據不準，那Scrum就失去意義變成累贅：Burn Down Chart都是假數據了，你無法及時看到組內出現了啥問題，這會導致項目每次都是deadline前出毛病。為什麼ScrumMaster難做？因為他既要服務老闆又要服務團隊。讓老闆高興，他得督促大家執行Scrum，去更新狀態，這很容易讓人覺得「小樣，覺得自己是個人物呢，年紀輕輕管我來了」；而如果迎合組員、不推動Scrum了，那老闆就不會得到及時有效的數據、做出正確的決定。夾在中間，是對情商和智慧的考驗。

「先僵化、再優化、再固化」這句話做到極致，你可能除了有個Stand Up，有個Board外其餘的都和Scrum很不像了。沒有關係，這可能正說明你掌握了精髓，你知道你的目的是什麼、且知道如何達到它。Scrum標準之所以寫的那麼繁雜，是因為它要考慮新手，它得給你應對任何情況的對策，而你實際可能只需要一部分。這就是為什麼大家把Scrum定義成一個「框架」——聯想一下軟體框架，你用一個軟體框架，多數情況只用到裡面一小部分功能。但是這個軟體框架的文檔一定會事無巨細介紹一遍。

總結：僵化，讓你知道有哪些可用。優化讓你知道需要用啥。固化讓大家不用每次幹活都查文檔。

企業實施Scrum是一場企業變革，總體思路：先僵化，再優化，再固化。
實施Scrum的基本步驟建議：
1. 管理層支持
2. 培養種子選手
3. 統一思想（團隊需要對敏捷和Scrum有統一的正確地認識，要全面徹底！）
4. 建立轉型推動團隊
5. 制定轉型具體計劃（轉型目標是什麼，完成目標具體需要做哪些改變）
6. 按照迭代地方式來做，不斷試錯，持續改進

更新，如何使用Teambition打造小而美的Scrum團隊
Scrum只是一個過程，最重要的就是不要死守教條，比如Scrum中是可以採用XP的一些方法的，不要因為XP也是敏捷開發的一種，採用了Scrum之後就不用XP了，還有的可以看看teambition這個網站，上文鏈接就很好地介紹了如何利用teambition來開展scrum。
目前好多Scrum的書看起來比較生硬，有些是直接翻譯的，有些寫的太過形式主義。推薦一本書，叫做《輕鬆Scrum之旅:敏捷開發故事》，是以前的IBM的人寫的，以小說的形式來講Scrum的，你也可以看一看，
希望對你有幫助。

不邀自來哈~
我最近也在學習SCRUM，其實，這個方法論看起來簡單，但實施起來很困難，一不小心就會把一些重要環節變成一種形式般的存在。
下面是我之前總結的，比較淺顯易懂，看完能知道工作流程及每一步工作中哪些人應做什麼事情。

捷開發的定義：敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。

敏捷開發誕生的背景：在瀑布流開發方式中，每個階段之間都有強烈的依賴關係，前一個階段被視為後一個階段的輸入，如果輸入質量不高，便會嚴重影響後續階段的輸出質量。同時，如果前一個階段未能達到標準，也會造成後續階段的停滯，導致開發周期拉長。並且，項目早期即作出承諾導致對後期需求的變化難以調整，代價高昂。

敏捷開發的流程：

1.討論，確定user stories滿足客戶要求（參與人：Project owner，client）

2.編寫user stories（參與人：Project owner）

user stories的格式為：作為......，我希望.....，則......。（用客戶語言來描述（通俗說就是我希望有什麼功能，理由是什麼））

3.討論，明確user stories（參與人：Project owner，Developer,Designer）

Project owner修改user stories，並確定每項的priority，story point。

4.編寫task（參與人：Developer,Designer）

Developer,Designer書寫task，關聯相應的story，Estimate（允許一層子task，每類用戶1~2個task，一般1個）

5. Project owner檢查task，計算sprint期內時間，確定入選stories。

6.Meeting ，確定sprint期工作內容。

對其中重要內容的解釋：

1.user stories

是從最終用戶的角度定義軟體功能的一種方式

#The Extended DAD lifecycle（生命周期）

工作過程中，也可根據需求修改story。

#User story card

正反均為story內容，大項vs小項列表。

若關聯有task，則task完成即其內容完成。

2.Epic

是由選出的部分stories組成，先有user stories，再有Epic.

Epic 是user stories 的容器，用於存儲關於整個功能的文檔。

3.維度

Story組裝Epic

Task關聯Story

我跟樓主有一樣的問題，說下我自己的實際情況。
我去年6月份才畢業，最開始接觸Scrum是去年3月份，因為面試的筆試題就是做份介紹scrum怎麼去解決瀑布所帶來的問題的PPT，那份筆試題一直被老闆們認為做得非常好。
去年8月底，我拿到ScrumAlliance的Certified Scrum Master，我以為我對Scrum的理解已經非常好了。
今年7月份換工作，新公司老闆就是看重我有CSM才招我進來，想讓我來改善現有鬆散的流程。來了之後，我才發現自己對Scrum的理解其實太少了，儘管理論看得多又怎樣，沒有實戰經驗，面對一個十幾個人的鬆散的團隊，還是有心無力。團隊里有的人工作了很多年了早就習慣了瀑布，有的人的意識里就沒有self-organized的概念，特別是基層做事的人覺得Scrum對他來說沒什麼改變，而老闆一方面讓我去主導改革，一方面又強調了幾個主美術主程序的關鍵性地位，傾向由他們來分配任務估算工作量，讓下面的人直接執行，忽略了團隊一同參與的自主性和承諾性。
而我自己，一方面實戰經驗少，一方面沒什麼話語權，又是個才進來的新人，一來就要改革，所以現在是困難重重。我組織過大家一起開會，分享和培訓過Scrum的基本流程，會議結束我也整理了流程改變內容發給所有人，結果。。。發現大家都沒看。。。我想的也是一步一步慢慢來調試過來，之前定好的開始跑Sprint的時候，還有人問我和之前相比有啥好處，而定義為PO的那個人就說其實跟之前比沒啥本質變化/(ㄒoㄒ)/~~

目前我想到的應對方法是這樣的，不知道對不對：
1. 讓老闆動員大家，強制說明以後就用Scrum了，這樣大家才會主動接受
2. 我找幾個主要負責人主程序主美術啥的聊聊，了解他們的想法，並且先對他們進行說服，讓他們能夠帶動起來
3. Scrum的各種慣例會議還是要跑起來，在實踐中促成大家的習慣，慢慢的轉變

準確來說，Scrum是ACP敏捷項目管理其中的一個方法。

敏捷之所在能在競爭激烈的市場中脫穎而出，主要就是能及時交付客戶價值。客戶必須求新、求變、求快，才能在市場勝出，而有價值的需求，必須不斷地溝通、執行、展示和回顧。而敏捷能在此基礎上推動項目的進程。

Scrum是一個敏捷開發框架,它由一個開發過程、幾種角色以及一套規範的實施方法組成。在Scrum中,產品需求被定義為產品需求積壓(productbacklogs)。所有的產品需求積壓都是從一個簡單的想法開始,並逐步被細化,直到可以被開發的程度。Scrum將開發過程分為多個Sprint周期,每個Sprint代表一個2~4周的開發周期,有固定的時間長度。

Scrum 的一些關鍵實踐包括：

自我指導和自我組織團隊
每日就特殊問題（您做了什麼、您將做什麼和您遇到哪些問題）開站立會議
通常採用 30 天的日曆循環
在每個循環的開始，制訂客戶驅動的適應計劃
向參與者演示功能（在每個循環結束時）

對於企業級活動，了解和管理項目間的依賴項非常重要。在 Scrum 中使用「Global Backlog」就可以很好地做到這一點，Global Backlog 是對用戶有價值的功能和非功能需求的企業視圖。Global Backlog 在全局區分優先順序。每個項目從 Global Backlog 獲得項目範圍內的最重要的部分。「Scrum of Scrums」還涉及項目間的同步，這是一個每兩天（或每周）一次的會議，來自每個團隊的代表參加這個會議，以便在團隊之間同步。

Scrum9條規則：

Scrum Master
Product Owner）
Team
計劃會 Sprint Planning Meeting
Daily Scrum
Sprint review
Product Backlog
Sprint Backlog
Burndown Chart

但是在現在的項目中，很多項目經理有PMBOK，但是不懂敏捷，缺乏實踐，不懂如何打造高效團隊，保持多團隊、多迭代同步。為了適應越來越激烈的市場環境，後PMP時代下的敏捷項目管理前景愈來愈好，這也需要不斷的學習和實踐，才能更好交付客戶，提高個人或企業的競爭優勢。

可以參考這個總結，另外特別注意不要落入形式主義，也不一定要完全按照這上面的來，我的經驗就是最好找出適合你的一兩條，逐步引入。

大圖下載地址

https://img.pmowner.com/wp/2017-06-24/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91%E5%AE%9E%E8%B7%B5_by_lenxeon.jpg