簡要介紹

《輕鬆Scrum之旅–敏捷開發故事》以小說的方式向我們介紹了主人公在經歷瞭如噩夢般的傳統的瀑布開發模型後，成功向敏捷開發轉型的故事。
作者通過4個迭代開發過程，展現了主人公是如何從一個敏捷開發的新手逐步成長為一個資深的Scrum Master的過程；通過這4個迭代開發過程，作者由淺入深的逐步介紹了在Scrum在實施過程中遇到的一個個問題，並通過主人公與一個Scrum專家的郵件交互向我們提供解決辦法。同時，還恰如其分的在文章中適當的對敏捷開發的各種概念、實踐工具等進行了介紹，讓我們能及時瞭解相關的Scrum知識，而不會感到突然。
這本書非常適合那些想學習Scrum卻又無從下手的同學，而且對剛剛實施Scrum的團隊來說，也非常具有借鑑意義！
這邊書我一口氣讀完，使我對Scrum實踐有了更加深入認識，也促使我回過頭來對我們的敏捷過程進行更深入的思考，讓我收益頗深！
世上充滿無數的選擇和努力，但對於成功，選擇大於努力。

根據書中內容，總結一下Scrum開發基本的知識：

David的敏捷開發培訓–什麼是敏捷開發

回家的啟發：

stakeholders，我們所有的目標是為了實現利益相關者的利益
sustainable pace，保持一個可以持續的進度，決不能太累
自我管理的團隊

敏捷價值觀

個體和互動重於過程和工具
可以工作的軟體重於面面俱到的文件
客戶協作重於合同談判
隨時響應變化重於遵循計劃

核心思想

適應變化和以人為本

其他

1, 敏捷開發方法是面向人的而非面向過程
2, 敏捷開發方法是“主動適應”而不是“預先設定的”

敏捷開發的理念

信任開發團隊，信任每一個人

敏捷開發中的管理

非命令式，戰略指導和服務性質；敏捷開發中，管理者對團隊的管理表現在挑選合適的人、為團隊創造一個開發自由的工作環境、經常性的反饋、為團隊建立評估和獎勵機制、當團隊有方向性錯誤時能及早發現並糾正、容忍錯誤的發生等。

兩個故事

買土豆的故事
“雞”和“豬”的故事

敏捷開發的軟素質

A very good team player
Excellent communication skills
Open minded, pro-active, and self-motivated

敏捷開發過程比較

XP
RUP
Lean

Scrum總體結構

任務板
敏捷專案管理工具

在專案的開始制定一個有效的溝通計劃至關重要！
產品Backlog、Sprint Backlog、User Story
User Story：作為<某個角色>，我可以<做什麼>，已完成<什麼目的>。

Scrum三種角色

Product Owner、Scrum Master、Scrum團隊成員

1 Product Owner：
需要確定產品的功能和完成時間，並對產品的收益負責，要根據市場需求確定產品功能的優先順序。在每個sprint開始之前，Product Owner可以修改功能需求和優先順序。而且PO有權決定接受或者否決各個Sprint的工作成果。
Prouduct Owner的角色通常由市場部門的人員或開發部門內部主要使用該產品的人員來擔任，主要工作是根據市場需求確定產品功能，將其列入Product Backlog中斌未這些功能確定優先順序。
Scrum團隊按照功能的優先順序，將它們從高到低分配到各個Sprint中進行開發，這些被分配到一個Sprint中完成的功能就形成了Sprint Backlog。
在產品的整個開發過程中，Product Owner對於產品的需求可能會發生改變。他可以修改Product Backlog， 以及增加某些功能需求、刪除某些功能需求、修改優先順序等，但這些行為只能在各個Sprint之間進行。

2 Scrum Master：
負責監督整個Scrum專案程序，調整專案計劃；確保開發團隊成員的能力能夠勝任產品的開發；促進團隊中不同角色的團隊成員充分交流和溝通，併為專案的進行掃除障礙；保證開發團隊不受外力的干擾和阻擾；掌握產品的開發進度，參與每日Scrum會議、Sprint計劃會議和Sprint平時會議。

3 Scrum成員：
要求Scrum團隊是跨職能的，應該包含開發、測試、美工即文件人員。

Sprint計劃會議：

時間：一般4-8小時，
參與人員：PO、SM、Scrum團隊成員和其他對產品感興趣的人員，PO從產品Backlog中挑選高優先順序的任務，並與Scrum團隊成員一起決定這個Sprint中需要完成多少功能。Scrum團隊將這些任務分解成小的功能模組。Scrum團隊成員詳細討論如何才能按需求完成這些功能模組，並估計完成每個功能模組所需要的大概時間。
確定sprint最後演示的時間和每個story演示的方式

每日scrum會議

每日Scrum會議是Scrum的精髓，最簡單又最複雜，如何有效的召開，需要不斷的改進和摸索；
一般15分鐘，3個問題:
1)昨天我完成了什麼工作？
2)今天我打算做什麼？
3)我在工作中遇到了什麼障礙？
通過每日Scrum會議，團隊成員之間可以彼此相互熟悉工作內容，充分了解專案進度，相互幫助解決問題。SM除了傾聽團隊成員的發言外，還有責任設法解決團隊成員在會上提出的困難，儘快掃除阻礙他們工作順利進行的障礙。即使有的問題SM沒有能力解決，他也應該找到團隊中的或其他團隊中的成員來幫組快速地解決問題。另外，還有兩點需要注意：其一，這是團隊成員之間的交流，也是相互的承諾，並不是向老闆彙報工作進度的；其二，這也不是一個專門用於解決各種問題的會議，團隊成員在工作中遇到的問題可以在會上提出來，而又能力解決這些問題的人可以在會後幫助他們解決問題。

Burndown Chart

是常用的衡量團隊進度的視覺化攻擊。敏捷開發可以給專案提供更多的可視性。

Sprint評審會議：

Sprint結束時召開，一般2小時左右，非正式的會議，可以邀請高層參加，氣氛要活躍點，避免變成嚴肅的報告會。
要避免過多的談論技術細節，要重點關注最後的成果。
注意任務完成（Done）的定義，

Sprint回顧會議：

參加人員：PO、Scrum團隊成員、Scrum Master
宗旨：Scrum團隊如何在下一個Sprint中做的更好
重要性：第二重要的事件（最重要的是Sprint計劃會議），因為它是讓Scrum團隊成員成長和進步的最好機會。如果不開回顧會議，不久以後，你就會發現，你的團隊在不斷地犯著同樣的錯誤。
會議內容：
會議中需要討論有哪些好的建議或方法應該被採納，在這個Sprint中有什麼做法不可取，有哪些做法效果很好，應該繼續下去。
Sprint結束後，Scrum團隊成員回顧剛剛結束的Sprint，對其進行總結和反思，使整個團隊能持續成長。
Sprint回顧會議的形式可以比較隨意，主要做到以下幾個方面：
SM首先給大家看Sprint Blacklog，總結這個Sprint。然後，團隊成員討論在這個Sprint中發生的一些比較重要的事件。與會人員輪流發言，每個人都有機會發表自己的意見：他認為哪些方面做的好、哪些方面需要改進、應該如何改進等。此外還要對比Sprint Backlog中各個Story的估計值於它們的實際完成時間，如果差距太大，就應該好好分析出現這種情況的原因。
在Sprint回顧會議結束之前，Scrum Master要總結會上的討論成果，即“如何才能在下個Sprint中做得更好”。
總之，Sprint回顧會議的宗旨就是：Scrum團隊如何在下一個Sprint中做得更好！

Wiki是個不錯的敏捷專案文件管理工具

計劃撲克：

撲克背後的敏捷思想是團隊裡沒有絕對的權威，每個人都有可取之處，要避免少數服從多數。

Sprint目標：

Sprint Goal是個鼓舞士氣的好工具。

代理Scrum Master給我的啟示：

真正的Scrum Master要能夠排除開發人員和產品負責人之間的障礙，確保Scrum達成目標，實現投資回報最大化，確保團隊進度，確保團隊狀態具有高度的可視性，激發團隊創造力，提高團隊開發水平，採用各種優秀的工程實踐，提高生產力等。

其他知識點

兩個Sprint之間的緩衝時間，可以起到承上啟下的作用。

Team Pulse Survey統計結果的各項實際上告訴我們應該如何成為一個成熟的Scrum團隊

Scrum要求在一個Sprint中團隊成員高度穩定

持續整合是敏捷開發中核心的工程實踐，它是敏捷產出“可以工作的軟體”（Working Sofeware）的有利保障。