1 Scrum是什麼
遵循Agile宣言的一種具體的實踐方法，Agile宣言如下：
我們一直在實踐中探尋更好的軟體開發方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀：
個體和互動高于 流程和工具
工作的軟體 高于 詳盡的文檔
客戶合作 高于 合同談判
響應變化 高于 遵循計劃
也就是說，盡管右項有其價值，
我們更重視左項的價值。
Agile宣言遵循以下原則：
1) 我們最重要的目标，是通過持續不斷地及早傳遞有價值的軟體使客戶滿意。
2) 欣然面對需求變化，即使在開發後期也一樣。為了客戶的競争優勢，靈活過程掌控變化。
3) 經常地傳遞可工作的軟體，相隔幾星期或一兩個月，傾向于采取較短的周期。
4) 業務人員和開發人員必須互相合作，項目中的每一天都不例外。
5) 激發個體的鬥志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，進而達成目标。
6) 不論團隊内外，傳遞資訊效果最好效率也最高的方式是面對面的交談。
7) 可工作的軟體是進度的首要度量标準。
8) 靈活過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。
9) 堅持不懈地追求技術卓越和良好設計，靈活能力由此增強。
10) 以簡潔為本，它是極力減少不必要工作量的藝術。
11) 最好的架構、需求和設計出自自組織團隊。
12) 團隊定期地反思如何能提高成效，并針對其中出現的問題，在後續研發中持續改進。
Scrum在遵循靈活宣言的同時，也融入了XP（極限程式設計）的部分實踐：
1) 團隊協作(Whole Team)
2) 規劃政策(The Planning Game)；
3) 結對程式設計(Pair programming)
4) 測試驅動開發(Testing-Driven Development)
5) 重構(Refactoring)
6) 簡單設計(Simple Design)
7) 代碼集體所有權(Collective Code Ownership)
8) 持續內建(Continuous Integration)
9) 客戶測試(Customer Tests)
10) 小型釋出（Small Release）
11) 每周40小時工作制（40-hour Week）
12) 編碼規範（Code Standards）
13) 系統隐喻（System Metaphor）
定義：它是将整個系統聯系在一起的全局視圖；它是系統的未來景像，是它使得所有單獨子產品的位置和外觀（shape）變得明顯直覺。如果子產品的外觀與整個系統的隐喻不符，那麼你就知道該子產品是錯誤的。
想想一下“拼圖遊戲”。
2 Scrum的流程
3 Scrum的4種角色
3.1 Product Owner
代表客戶利益，最好是客戶方的人或者是商務人員。如果團隊内部人，必須具有如下特性：
能換位思考，能在2種不同類型的角色之間切換，作為“PO”：堅持以客戶價值為導向，以高标準嚴格定義“Done”的标準，不能随便妥協；作為“Team Member”：需要嚴格按照Scrum流程完成每日工作，對自身的工作産出的要求要與其他團隊成員保持一緻。
3.2 Scrum Master
類似于“足球/籃球場上的教練”,職責：
1) 負責規範化流程；
2) 保護團隊在不受幹擾的環境下工作；
3) 解決阻礙團隊前進的問題。
3.3 Team
1) 選取Product Backlog組成Sprint Backlog，将User Story拆分成Task，進行工作量估算；
2) 每日領取并按照計劃完成Task；
3) 遵循Scrum Master的指導，按照規範的流程完成一次Sprint；
4) 總結團隊的在每次Sprint之中的做的好與不好的地方，并實施持續改進。
作為Team成員，需要有如下精神：
1) 對團隊承諾和履行承諾的精神；
2) 集體主義精神，按時完成自己領取的任務，不拖團隊的後腿。
3.4 Stake Holder
其他與項目相關的利益相關人，如二甲方、公司管理層等，他們受邀參加項目團隊的活動，例如示範會和計劃會議等，他們隻是團隊的“外因”。
4 Scrum的4種活動
推行Scrum應具備的基本條件
團隊成員都是“多面手”，既能開發又能測試，技術全面；
開發團隊最好能集中在一處開發，面對面地溝通；
團隊在Sprint當中要避免受其他事情的打擾，全心全意；
我們現在面臨的不利條件：
1) 團隊分隔兩地，溝通不便，溝通成本高；
2) 存在管理問題，團隊成員同時做幾件事情的時候比較多。
5 計劃撲克
“計劃撲克”的使用方法：
1) 每個團隊成員拿到一組卡片，包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共計12張。why斐波那契？避免連續值，你真的說得清楚故事點=4和=5之間的差別？
2) 産品負責人或者一名團隊成員扮演閱讀者的角色，他負責閱讀需要估算産品Backlog的條目，并且詢問大家是否有疑問
3) 團隊讨論這個條目。
4) 當團隊了解了這個條目之後，每個團隊成員按照自己的想法給出估算結果，并且選擇對應的撲克出牌，估算結果不能告訴其他人，出牌時數字朝下扣在桌面上。
5) 所有人都出牌之後，閱讀者向大家确認是否都已經确定估算結果，确認後，數大家同時展示估算結果。
6) 團隊評估不同的估算結果，我們是否想法一緻？我們是否存在分歧？有沒有什麼是我沒有考慮到的？團隊共同讨論估算的差異，最終達成一緻。
7) 回到第二步，開始估算下一個條目。
為什麼要使用估算撲克來做估算：
1) 團隊的智慧要高于某一個人的智慧。
2) 真正參與工作的人做出的估計要高于其他人做出的估計。估算撲克有效還有如下幾個方面的原因：
a) “三個臭皮匠抵過諸葛亮”，況且還是”不同工作性質的臭皮匠”。
b) 在估算的過程中，團隊對估算的結果進行讨論和評判，在一個高度透明的環境下，估算的結果更加真實和客觀。這樣也避免了很多時候過于武斷，或是拍腦袋做出的決定。
c) 估算的過程也是一個知識分享和學習的過程，對某一個條目不清楚的成員通過其他成員的闡述會增加對該條目涉及到的要點的認
6 User Story&Task
User Story的寫法應該遵循如下“八股文”：
As a <User Type>
I want to <achieve goal>
So that I can <get some value>
User Story需要遵循的原則：
1) Independent 獨立性，避免與其他Story的依賴性。
2) Negotiable 可談判性，Scrum中的story不是瀑布開始某事中的Contract,Stories不必太過詳細，開發人員可以給出适當的建議。
3) Valueable 有價值性， Story需要展現出對于使用者的價值
4) Estimable 可估計性，Story應可以估計出Task的開發時間。
5) Sized Right 合理的尺寸，Stories應該盡量小，并且使得團隊盡量在1個sprint(2 weeks)中完成。
6) Testable 可測試性， UserStory應該是可以測試的，最好有界面可以測試和自動化測試。每個任務都應有Junit Test.
一些經驗：
1) 不要在User Story中使用And和Or，因為這是些分支詞就表示分支任務，把它們拆成兩個Story.
2) 團隊要根據自己的幾次的嘗試，不斷提高自己估計一個Sprint能夠完成多少User Story的能力，保證在可持續工作的情況下，一直保持一個固定的節奏推進Scrum開發。
3) User Story用于描述使用者故事，不要包括任何的技術，架構等内容。Task可以包括架構，技術等内容。
7 看闆
為什麼要看闆？
1) 來自“豐田”“精益管理”思想；
2) 資訊公開和共享的管道。
看闆的典型布局：
ToDO|Doing|Done|Problem|BurnDown Chart，可選的WithDraw|Added，實際項目推進中看闆的例子：
8 一頁紙Scrum