scrum是乙個輕量級的軟體開發方法
scrum是乙個敏捷開發框架，是乙個增量的、迭代的開發過程。在這個框架中，整個開發周期包括若干個小的迭代週期，每個小的迭代週期稱為乙個sprint，每個sprint的建議長度2到4周。
在scrum中，使用產品backlog來管理產品或專案的需求，產品backlog是乙個按照商業價值排序的需求列表，列表條目的體現形式通常為使用者故事。scrum的開發團隊總是先開發的是對客戶具有較**值的需求。在每個sprint中，scrum開發團隊從產品backlog中挑選最有價值的需求進行開發。
sprint中挑選的需求經過sprint計畫會議上的分析、討論和估算得到乙個sprint的任務列表，我們稱它為sprint backlog 。 在每個迭代結束時，scrum團隊將交付潛在可交付的產品增量。
個體與互動勝過過程與工具
可以工作的軟體勝過面面俱到的文件
客戶協作勝過合同談判
響應變化勝過遵循計畫
這四句價值觀用語句表達就是：
自組織團隊與客戶緊密協作，通過高度迭代式、增量式的軟體開發過程響應變化，並在每次迭代結束時交付經過編碼與測試的有價值的軟體。
勝過與客戶確定合同後在初期制定並遵循基於活動的完整計畫，在重型過程和工具指導下，通過完成大量文件進行知識傳遞，最後交付需求。
《敏捷宣言》12條原則
1.最優先的目標是通過盡早地、持續地交付有價值的軟體來滿足客戶。
2.歡迎需求變化，甚至在開發後期。敏捷過程控制、利用變化幫助客戶取得競爭優勢。
3.頻繁交付可用的軟體，間隔從兩周到兩個月，偏愛更短的時間尺度。
4.在整個專案中業務人員和開發人員必須每天在一起工作。
5.以積極主動的員工為核心建立專案，給予他們所需的環境和支援，信任他們能夠完成工作。
6.在開發團隊內外傳遞資訊最有效率和效果的方法是面對面的交流。
7.可用的軟體是進展的主要度量指標。
8.敏捷過程提倡可持續發展。發起人、開發者和使用者應始終保持穩定的步調。
9.簡化——使必要的工作最小化的藝術——是關鍵。
10.持續關注技術上的精益求精和良好的設計以增強敏捷性。
11.最好的架構、需求和設計產生於自我組織的團隊。
12.團隊定期地對運作如何更加有效進行反思，並相應地調整、校正自己的行為。
產品負責人（product owner）的職責如下：
確定產品的功能。
決定發布的日期和發布內容。
為產品的roi負責。
根據市場價值確定功能優先順序。
每個sprint，根據需要調整功能和優先順序（每個sprint開始前調整）。
接受或拒絕接受開發團隊的工作成果。
作為team leader和product owner緊密地工作在一起，他可以及時地為團隊成員提供幫助。
他必須:
保證團隊資源完全可被利用並且全部是高產出的。
保證各個角色及職責的良好協作。
解決團隊開發中的障礙。
做為團隊和外部的介面，遮蔽外界對團隊成員的干擾。
保證開發過程按計畫進行，組織daily scrum, sprint review and sprint planning meetings。
負責產品的開發
一般情況人數在5-9個左右
團隊要跨職能
（包括開發人員、測試人員、使用者介面設計師等）
團隊成員需要全職。（有些情況例外，比如資料庫管理員）
在專案嚮導範圍內有權利做任何事情已確保達到sprint的目標。
高度的自組織能力。
向product owner演示產品功能。
團隊成員構成在sprint內不允許變化。
團隊整體向產品開發負責。
有優先順序的故事列表，並估算故事點
產品訂單：產品訂單（product backlog）是整個專案的概要文件，它包含已劃分優先等級的、專案要開發的系統或產品的需求清單，包括功能和非功能性需求及其他假設和約束條件。產品負責人和團隊主要按業務和依賴性的重要程度劃分優先等級，並作出預估。
預估值的精確度取決於產品訂單中條目的優先順序和細緻程度，入選下乙個衝刺的最高優先等級條目的預估會非常精確。產品的需求清單是動態的，隨著產品及其使用環境的變化而變化，並且只要產品存在，它就隨之存在。而且，在整個產品生命週期中，管理層不斷確定產品需求或對之做出改變，以保證產品適用性、實用性和競爭性。
當前sprint要完成的任務列表，並估算工時
團隊成員自己挑選任務，而不是指派任務
對每乙個任務，每天要更新剩餘的工作量估算
每個團隊成員都可以修改sprint backlog，增加、刪除或者修改任務
衝刺訂單：衝刺訂單是大大細化了的文件，用來界定工作或任務，定義團隊在 story 中的任務清單，這些任務會將當前衝刺選定的產品訂單轉化為完整的產品功能增量。衝刺訂單在衝刺規劃會議中形成，其包含的不會被分派，而是由團隊成員簽名認領他們喜愛的任務。
任務被分解為以小時為單位，沒有任務可以超過 16 個小時。如果乙個任務超過 16 個小時，那麼它就應該被進一步分解。每項任務資訊將包括其負責人及其在衝刺中任一天時的剩餘工作量，且僅團隊有權改變其內容。
直觀反應當前發布剩餘的工作量，以sprint週期數和故事點數為單位。
燃盡圖（burndown chart）是乙個公開展示的圖表，縱軸代表剩餘工作量，橫軸代表時間，顯示當前衝刺中隨時間變化而變化的剩餘工作量（可以是未完成的任務數目，或在衝刺訂單上未完成的訂單項的數目）。剩餘工作量趨勢線與橫軸之間的交集表示在那個時間點最可能的工作完成量。我們可以借助它設想在增加或減少發布功能後專案的情況，我們可能縮短開發時間，或延長開發期限以獲得更多功能。
它可以展示專案實際進度與計畫之間的矛盾。
sprint燃盡圖直觀的反映了sprint過程中，剩餘的工作量情況，y軸表示剩餘的工作，x軸表示sprint的時間。隨著時間的消耗工作量逐漸減少，在開始的時候，由於估算上的誤差或者遺漏工作量有可能呈上公升態勢。
團隊從產品backlog中挑選他們承諾完成的條目。（做什麼）
建立sprint backlog （怎麼做）
標識具體的任務並為任務做估算
由團隊協作完成，而不是scrummaster
考慮了高層設計
團隊每天進行15分鐘的檢驗和適應的會議稱為scrum每日站會。每日站會上，每個團隊成員需要匯報以下三個問題：
從上次會議到現在完成了哪些工作。
下次會議前準備完成什麼。
工作中遇到了哪些障礙。
匯報的物件是團隊，不是任何一位領導（po,sm,團隊負責人）。
匯報的重點在於提出問題，進而解決。
每日站會不是進度匯報會議，這個會議是為將產品backlog條目轉化成為增量的人（團隊）召開的。團隊承諾實現sprint目標和完成產品backlog條目。每日站會是檢驗朝向sprint目標的程序，如果有必要進行後續會議對sprint中的下一步工作進行調整，目的在在於增加團隊實現目標的可能性。
這是scrum經驗過程中的重要檢驗和適應的會議。
sprint評審會議用來演示在這個sprint中開發的產品功能給product owner會組織這階段的會議並且邀請相關的干係人參加。
團隊展示sprint中完成的功能
一般是通過現場演示的方式展現功能和架構
不要太正式
不需要ppt
一般控制在2個小時
團隊成員都要參加
可以邀請所有人參加
sprint回顧會議上，全體成員討論有哪些好的做法可以啟動，哪些不好的做法不能再繼續下去了，哪些好的做法要繼續發揚。
團隊的定期自我檢視，發現什麼是好的，什麼是不好的。
一般控制在15-30分鐘
每個sprint都要做
全體參加
scrum master
產品負責人
團隊可能的客戶或其它干係人
1首先組建scrum團隊（5-9人）
2 確定團隊成員職責（scrummaster,po,team）
3需求設計分析，列出product backlog,格式如下:
id name imp est how to demo notes
注意事項：deep
detailed appropriately(粗細適中)：指將當前優先順序高的功能模組盡量細化，而相對優先順序較低的功能模組，只需要知道大體功能點既可。
estinnated(估算過的)：對每個功能點進行估算。
emergent(湧現的)：功能模組隨著開發的推移是變化的，因此每次迭代完成都要重新調整。
敏捷開發與敏捷測試
敏捷開發 1.敏捷型方法是 適配性 而非 預設性 重型方法試圖對乙個軟體開發專案在很長的時間跨度內作出詳細的計畫，然後依計畫進行開發。這類方法在計畫制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。2.敏捷型方法是 面向人 的 peop...
敏捷開發方法
常見的敏捷開發流程比較 2010 07 13 網路 速度是企業競爭致勝的關鍵因素，軟體專案的最大挑戰在於一方面要應付變動中的需求，一方面要在緊縮的時程內完成專案，所以軟體團隊除了在技術上必須日益精進，更需要運用有效的開發流程，以確保團隊能夠發揮綜效。這正是agile process 敏捷的軟體開發流...
專案的敏捷開發與敏捷測試
敏捷開發 1.敏捷型方法是 適配性 而非 預設性 重型方法試圖對乙個軟體開發專案在很長的時間跨度內作出詳細的計畫，然後依計畫進行開發。這類方法在計畫制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。2.敏捷型方法是 面向人 的 peop...