如果嚴格按照書本上的 Scrum 法則一條條地看，那麼我們隊伍現在的做法也許根本不算 Scrum。不過好歹我們也被稱作 Scrum 一段時間了，我的資歷比不上前面的資深開發者，只能說一些目前的一點經驗。
經驗一：整個團隊必須理解 Scrum 的目的和限制。
如果管理團隊把 Scrum 當作一種新的管理流程，那麼這個理解絕對是錯誤的，而且有害。要正確理解 Scrum 的實施原則，需要從理解其設計目的開始。
我所理解的 Scrum 的目的在於兩點：

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

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

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

1. 因為釋出週期縮短，團隊沒有能力保證作出的每一個決定都正確，很多開銷都必須花在試錯上；
2. 快速釋出實際上導致 Scrum 團隊的抗風險能力弱於瀑布模型團隊，因為一個人的離職或病假都可能對單一功能的進度造成影響，不利於短期頻繁釋出。Scrum 對此的解答是：不要試圖不犯錯誤，而是保證小的錯誤能被儘快發現從而不會釀成大錯。所以 Scrum 過程中總會有些不確定性，或者功能不合需求而返工，或者突然缺了人手導致一些單個功能必須延期完成。如果非要事先確定釋出週期而且還得保證不許功能裁剪，請出門左轉找 CMM 認證：它可以把任務精確到每個對話方塊上該用什麼字型。前期計劃精確到這個粒度，什麼都可以在掌控之中。但問題是，我們必須用更長的釋出週期來換。

理解了上面的內容，我們實施時就不會對某些形式性的東西過於糾結，比如 Burn down chart，比如 Scrum 撲克。需知形式服務於目的，而形式未必適用於每一個團隊，正如瀑布模型在每一個團隊中也都有差異。如果僅僅是因為團隊成員沒有在 planning meeting 上打撲克就認定這不是 Scrum，那麼未免愚蠢了些。反過來，某些看似煩人的「流程」卻不可或缺，比如每天的 15 分鐘 stand-up，如果我們明白它對交流方面的重要作用，就絕對不會認為它可以被省略。
舉個實際的例子，在我們的團隊裡，我們強迫一週一個 Sprint。就我所知，即使在很多實施很成功的專案中，這種做法也是相當激進的。一開始我也不理解這一點，但實施了一段時間後，我開始認同這一條，因為一週的釋出週期讓我們沒有機會把任務往後推，從而迫使我們儘快從瀑布模型中轉移出來。這對一個有著悠久瀑布開發傳統的團隊來說非常重要，但對別的團隊來說，就不一定了。
經驗二：正確定位隊伍中的 Scrum Master。
為什麼單獨提 Scrum Master？如果只是看書本和參加培訓，我相信多數人都會同意我的觀點，即 Scrum Master 或許是整個開發過程中作用最不清楚的角色：不參與需求分析、不參與程式碼開發、甚至不參與任何人事問題，只有一句「去除阻礙」這種含糊的表述。但是，當我真正當起這個 Scrum Master 之後，才發現這個角色承擔的職責非常具體。比如：

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

但正因為上面的理解，我基本上不同意 Scrum Alliance 的教科書裡關於 Scrum Master 的大多數表述。

1. 首先，Scrum Master 必須承擔一部分開發任務，因為沒有介入一線開發，很難想象 Scrum Master 會真正理解團隊的「痛點」。
2. 其次，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 的所有實質。