最近幾天看了一本好玩又有知識的敏捷入門書《輕鬆scrum之旅》，值得推薦。

書中總結的實踐經驗和一些概念如下：

第 4 章  Sprint 1——新手上路
1．當開始研發新產品或者已有產品的新模組時，由於各方面的原因，整個團隊 沒有能力在 Sprint 的開始就做出一份非常詳實的計劃，因此，採用“照明彈”策略 絕對不失為一個好辦法。
2．對於每一個 Story，要儘可能瞭解它的需求。
3．在開發過程中，為了提高交流的效率，要儘量避免把精力浪費在不必要的文 檔上，取而代之的是要提倡團隊之間面對面的直接交流。
4．在實際工作中，Scrum 提倡團隊自我管理，在任務分配時每個人都可以按自 己的興趣來選擇任務。
5．團隊成員的技能培訓是要在做 Sprint 計劃時就考慮在內的。
6．雖然每日 Scrum 會議的持續時間會根據整個團隊的大小而有所不同，但是， 請不要超過 15 分鐘。
7．經理應該充分信任開發團隊，不該把每日 Scrum 會議當成每日彙報。
8．在 Scrum 工具的使用上，一定要確保每天都進行準確的更新，只有這樣才能 讓團隊的其他成員以及專案經理掌握及時、準確的專案進度資訊。
9．通過 Burndown Chart，Scrum 將給專案帶來更多的可視性。
10．每日 Scrum 會議舉行的時間應該在早晨還是下午？
11．在每日 Scrum 會議上不要過多地討論技術難題的細節，如果有團隊成員遇 到無法解決的困難時，Scrum Master 應該將其記錄下來，會後再調配資源去解決。
12．Scrum 如何解決開發與測試工作同步的問題？
13．每個 Sprint 結束後，最基本的目標是得到一個可以工作的產品。Sprint 結束 時的 Sprint 評審會議和 Sprint 回顧會議都至關重要。 


第 5 章  Sprint 2——計劃與變化
14．在 Sprint 計劃會議中，Scrum Master 應該主動與 Product Owner 一起制定和 討論這個 Sprint 的工作。
15．在 Sprint 計劃會議中，Scrum Master 不應該拋棄團隊成員，團隊成員必須全 體參與到計劃的討論中去，並且及時對不明白的地方以及使用者需求等進行提問。
16．採用 Wiki 進行文件管理。
17．在 Sprint 計劃會議中應該如何制定具體的計劃？
18．在 Sprint 進行過程中，遇到臨時的員工變化，比如請假，應該怎麼辦？
19．在 Sprint 計劃會議中，應該如何更準確地估計每個 Task 的時間？應該怎樣 用計劃撲克來估計時間？
20．在 Scrum 中，例如除錯機器、準備開發環境這樣的任務的工作量也應該體 現在 Sprint 的工作分配中。
21．關於 Scrum 團隊大小的討論。
22．Scrum 與 XP 以及其他一些敏捷方法的關係是怎樣的？
23．每日 Scrum 會議為什麼需要團隊成員站著開，而不能坐著？
24．每日 Scrum 會議需要每天進行，而不能因為每天的任務相似就不召開。Scrum Master 應該在每日會議中敏銳地發現問題，並積極地鼓勵團隊成員進行討論。
25．作為一個 Scrum Master，對於自己上司臨時安排的非 Sprint 計劃的任務，應 該儘量提前在 Sprint 的計劃階段就留出一定的緩衝時間用於處理這些事情，並應該 儘量協調安排好，避免過多非 Sprint 計劃的任務出現。
26．作為一個 Scrum Master，應該如何有效地向經理彙報專案程序？
27．Scrum 不鼓勵加班。 
 

28．對於不好演示的功能，可以用執行測試用例等其他方式在 Sprint 評審會議 中進行展示。
第 6 章  Sprint 3——深入 Scrum
29．創造一個敏捷的工作環境，讓每個 Scrum 團隊成員都坐在一起工作。
30．敏捷開發的思想之一也包括避免不必要的浪費，在做 Sprint 計劃時應該放 棄實現一些不必要的功能。
31．如何制定一個 Sprint 的目標？
32．Sprint 計劃會議需要團隊成員事先進行很充分的準備。
33．測試應如何介入 Sprint 中？
34．嘗試“結對程式設計”。
35．在敏捷開發中，應該儘可能地尋找有效的工具提高效率。“工欲善其事，必 先利其器。”
36．對於異地團隊，增強溝通是最關鍵的。初期最好的溝通方式是面對面的交 流。核心人員最好能進行一些面對面的接觸。
37．Scrum Master 的職責之一是在完成日常工作的同時，還需要隨時幫助團隊 成員排除障礙。
38．測試人員應該融入 Scrum 團隊，這樣做有利於開發團隊與測試團隊之間的 溝通，以共同保證產品的質量。
39．Scrum 強調團隊協作，並且在業績評定上一直都是以整個團隊的成果來衡 量的，這似乎對團隊中的某些成員不太公平，畢竟術業有專攻。這種情況下應該怎 樣衡量每個人的績效價值呢？
40．由於團隊成員的每個個體在技能、精力、經驗上的差別，所以必然會導致 效率的差別。那麼，應該如何消除這種差別帶來的問題？ 

41．對於專案進行中有可能影響專案結果和交付日期的突發事件，絕不能隱瞞， 而是應當從客戶的立場出發，告訴客戶實情，並在現有的條件下儘可能滿足客戶的 需求，同時為客戶提供多個解決方案作為備選。
第 8 章  Scrum 4——最後的衝刺
42．在一個 Sprint 結束和新一個 Sprint 開始的中間，應該有一定的緩衝時間。
43．採用 Scrum 回顧模板“團隊聽診工具”進行 Scrum 回顧。
44．利用演示工具有效地傳遞 Sprint 需求。
45．採用 Scrum 後的新部門組織結構。
46．推薦敏捷工具 IBM Rational Team Concert。
47．如果測試人員不習慣自身的角色轉換，應該鼓勵他們轉變思維方式，主動 參與開發過程。
48．關於效能測試的介入時機問題，常見的做法是在第 N+1 個迭代測試第 N 個 迭代的功能。
49．測試新功能前要對老功能做迴歸測試，以保證新功能不會破壞老功能。
50．關於自動化測試，應該盡力而為，但不能急於求成。
51．一個產品的成功與否需要市場來檢驗。在產品正式釋出之前，如果能有客 戶儘早地參與到開發過程中進來，無疑會增加成功的砝碼。
52．Scrum 強調在一個 Sprint 中團隊的穩定，一個 Sprint 中間的人員變動會對 Sprint 不利，即使加進來足夠多的人往往也不能起到提高效率的作用。
53．如何管理素質較低的團隊？
54．傳統的軟體管理體系 CMM/CMMI 的理念與 Scrum 的關係。
55．持續整合的實踐。 
               

相關概念 ：
Agile ：敏捷開發。
Backlog ：一項工作。
Build : 指已經編譯、構建好的一個可執行的軟體版本。
Burndown Chart :  用來顯示當前還剩下多少工作未完成的圖形化工具。通常以時間為橫軸，以本次迭代要完成的工作為縱軸。
Code Review: 程式碼稽核，通常由非程式碼編寫者完成。
Daily Scrum Meeting :
每日 Scrum 會議。每天 15 分鐘的每日例會，團隊中的每個成員都要回答以下 3 個問題：上次例會到現在我完成了哪些工作？下次例會前我將完成哪些工作？有沒 有什麼事情阻礙了我的工作？
In Progress : 進行中。
Product Backlog : 產品功能特性列表，主要由產品責任人負責維護並定義優先順序。
Product Backlog Item : 產品功能特性列表中的條目，每個條目就是一個工作單元，其大小必須限制在團隊可以在一個迭代之內完成。一個工作單元可以被分解成多個任務。
Product Owner : 產品責任人，負責確定 Backlog 中各條目的優先順序，同時解決所有關於需求的 問題。
Safari : 蘋果作業系統上的瀏覽器。
Scrum : Scrum 一詞來自英式橄欖球，它把軟體開發團隊比作橄欖球隊。Scrum 是當今流 行的敏捷開發方法之一。
Scrum Master : 負責管理每日 Scrum 流程的人，是 Product Owner 和 Team 之間的橋樑，要推動 雙方的合作，負責為 Team 成員解決障礙和問題，保證他們工作的順利進行。Scrum Master 相當於傳統軟體開發專案中的專案經理或主管。
Sprint : Sprint 代表 Scrum 的一次迭代，週期通常是 30 天，期間不能給 Team 增加額外 的需求，以確保迭代結束時能夠獲得預期的結果。
Sprint Planning Meeting : Sprint 計劃會議，在一次迭代開始時召開，由 Team 與 Product Owner 一起商討本 次迭代的目標，決定本次迭代要完成哪些工作。
Sprint Review Meeting :Sprint 評審會議，在一次迭代結束時召開，一般以 Demo 的形式由 Team 展示這 個迭代中完成的功能。 
 


Sprint Retrospective Meeting :
Sprint 回顧會議，在 Sprint 評審會議之後召開，由 Team 與 Scrum Master 共同討 論這個迭代中哪些地方做得比較好，哪些地方需要改進，使團隊持續成長。
Stakeholders :
利益相關者，是專案成敗對他們影響不大的一類人，他們參與提出產品的需求 並積極提出反饋意見。
Task : 任務。
Team :
跨功能的 Scrum 團隊，人數限制在 3～10 人，可能包括的角色有開發人員、架 構師、測試人員、UI 設計師等，是一個自組織的團隊，由團隊成員自己決定如何更 好地滿足使用者需求，並承擔相應的責任。
User Story :
使用者故事（情景），從使用者的角度對系統的某個功能模組進行簡短描述。
Welcome Lunch  歡迎午宴。
Wiki :
維基百科，一種開放和共享的線上文件編輯系統，任何人都可以在這個系統中 編輯和修改文件，最早的應用是線上的開放式百科全書，現在廣泛應用於各種文件 系統。