《輕鬆scrum之旅–敏捷開發故事》以**的方式向我們介紹了主人公在經歷了如噩夢般的傳統的瀑布開發模型後，成功向敏捷開發轉型的故事。
作者通過4個迭代開發過程，展現了主人公是如何從乙個敏捷開發的新手逐步成長為乙個資深的scrum master的過程；通過這4個迭代開發過程，作者由淺入深的逐步介紹了在scrum在實施過程中遇到的乙個個問題，並通過主人公與乙個scrum專家的郵件互動向我們提供解決辦法。同時，還恰如其分的在文章中適當的對敏捷開發的各種概念、實踐工具等進行了介紹，讓我們能及時了解相關的scrum知識，而不會感到突然。
這本書非常適合那些想學習scrum卻又無從下手的同學，而且對剛剛實施scrum的團隊來說，也非常具有借鑑意義！
這邊書我一口氣讀完，使我對scrum實踐有了更加深入認識，也促使我回過頭來對我們的敏捷過程進行更深入的思考，讓我收益頗深！
世上充滿無數的選擇和努力，但對於成功，選擇大於努力。
回家的啟發：
stakeholders，我們所有的目標是為了實現利益相關者的利益
sustainable pace，保持乙個可以持續的進度，決不能太累
自我管理的團隊
敏捷價值觀
個體和互動重於過程和工具
可以工作的軟體重於面面俱到的文件
客戶協作重於合同談判
隨時響應變化重於遵循計畫
核心思想
適應變化和以人為本
其他1, 敏捷開發方法是面向人的而非面向過程
2, 敏捷開發方法是「主動適應」而不是「預先設定的」
敏捷開發的理念
信任開發團隊，信任每乙個人
敏捷開發中的管理
非命令式，戰略指導和服務性質；敏捷開發中，管理者對團隊的管理表現在挑選合適的人、為團隊創造乙個開發自由的工作環境、經常性的反饋、為團隊建立評估和獎勵機制、當團隊有方向性錯誤時能及早發現並糾正、容忍錯誤的發生等。
兩個故事
買土豆的故事
「雞」和「豬」的故事
任務板
敏捷專案管理工具
在專案的開始制定乙個有效的溝通計畫至關重要！
產品backlog、sprint backlog、user story
user story：作為《某個角色》，我可以《做什麼》，已完成《什麼目的》。
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團隊是跨職能的，應該包含開發、測試、美工即文件人員。
每日scrum會議是scrum的精髓，最簡單又最複雜，如何有效的召開，需要不斷的改進和摸索；
一般15分鐘，3個問題:
1)昨天我完成了什麼工作？
2)今天我打算做什麼？
3)我在工作中遇到了什麼障礙？
通過每日scrum會議，團隊成員之間可以彼此相互熟悉工作內容，充分了解專案進度，相互幫助解決問題。sm除了傾聽團隊成員的發言外，還有責任設法解決團隊成員在會上提出的困難，盡快掃除阻礙他們工作順利進行的障礙。即使有的問題sm沒有能力解決，他也應該找到團隊中的或其他團隊中的成員來幫組快速地解決問題。另外，還有兩點需要注意：其一，這是團隊成員之間的交流，也是相互的承諾，並不是向老闆匯報工作進度的；其二，這也不是乙個專門用於解決各種問題的會議，團隊成員在工作中遇到的問題可以在會上提出來，而又能力解決這些問題的人可以在會後幫助他們解決問題。
是常用的衡量團隊進度的視覺化攻擊。敏捷開發可以給專案提供更多的可視性。
參加人員：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 goal是個鼓舞士氣的好工具。
真正的scrum master要能夠排除開發人員和產品負責人之間的障礙，確保scrum達成目標，實現投資回報最大化，確保團隊進度，確保團隊狀態具有高度的可視性，激發團隊創造力，提高團隊開發水平，採用各種優秀的工程實踐，提高生產力等。
兩個sprint之間的緩衝時間，可以起到承上啟下的作用。
team pulse survey統計結果的各項實際上告訴我們應該如何成為乙個成熟的scrum團隊
scrum要求在乙個sprint中團隊成員高度穩定
持續整合是敏捷開發中核心的工程實踐，它是敏捷產出「可以工作的軟體」（working sofeware）的有利保障。
Scrum敏捷開發
只有實踐起來才能提出有針對性的改進建議 在這個框架中，整個開發過程由若干個短的迭代週期組成，乙個短的迭代週期稱為乙個sprint，每個sprint的建議長度是2到4周 網際網路產品研發可以使用1周的sprint 在scrum中，使用產品backlog來管理產品的需求，產品backlog是乙個按照商業...
《使用者故事與敏捷方法》 Scrum
scrum是乙個迭代和遞增的過程。一輪迭代的過程是一種持續改進的過程 乙個遞增的過程是指按照功能點開發和發布軟體。每乙個功能點 功能增量 代表乙個完整的功能子集。每乙個功能增量都能被完整地實現以及測試通過。scrum和極限程式設計都是基於遞增和迭代方式的過程。這兩種過程都在一輪新的迭代開始之前為迭代...
敏捷開發（一）敏捷開發和Scrum
工作的軟體是首要 進度度量標準。敏捷過程 提倡可持續的開發速度。責任人 開發者和使用者應該能夠保持乙個長期的 恆定的開發速度。不斷地關注 優秀的技能和好的設計會增強敏捷能力 簡單 盡最大可能減少不必要的工作 是根本的。最好的構架 需求和設計出自與 自組織的團隊。每隔一定時間，團隊會在如何才能更有效地...