公司流程的改變，這周主要對敏捷的Scrum培訓和Daptiv工具 的培訓，因爲是英語培訓，許多東西自己要整理一下。
首先是和開發傳統模型（Waterfall）的對比，傳統模型隨着系統因素（內部和外部因素）的複雜度增加，項目成功的可能性就迅速降低。而scrum模型非常靈活，是一個增量迭代的開發過程。在這個框架整個開發週期由若干個小的迭代週期（Iteration Cycle），每個小的迭代週期稱爲一個Sprint，每個sprint的週期是14到30天。每個sprint 由inspection process 組成，各個team的成員每天碰一次頭review項目進行的活動並做適當的修改。推進迭代過程的需求來自Product Backlog，scrum的開發團隊拿到一個排列好優先級的需求列表，因此開發的是對客戶就有較高價值的需求。每個迭代結束後，都會完成可交付的產品。
這裏先解釋兩個術語：
Product Backlog：在項目開始的時候，product owner要準備一個根據商業價值排好序的客戶需求列表，這個列表就是product backlog，一個最終會交付給客戶的產品特性列表，它們根據商業價值來排列優先級別。Scrum team會根據這個來做工作量的估計。
Product Backlog應該涵蓋所有用來構建滿足客戶需求的產品特性，包括技術上的需求。高優先級的一些產品特性需要足夠的細化以便我們做工作量估計和做測試。對於那些可以在下個Sprint中完成的Product Backlog功能點，大約10人天的工作量的粒度就不錯了。對於那些以後將要實現的特性可以不夠詳細。
Sprint Backlog：Sprint Backlog是Sprint規劃會上產出的一個法寶。當Scrum team選擇並承諾了Product Backlog 中要遞交的一些高優先級的產品功能後，這些功能點就會被細化成爲Sprint Backlog：一個完成Product Backlog功能點的必需的任務列表。這些點會被細化爲更小的任務，工作量小於兩天。Sprint Backlog完成後，scrum team會根據它重新估計工作量，如果這些工作量和原始設計的工作量有較大差異， scrum team和product owner協商，調整合理的工作量到sprint中，以確保sprint的成功實施。
Burndown Chart現實了sprint中累積剩餘的工作量，它是一個反應工作量完成狀況的趨勢圖。在sprint開始的時候，develop team會表示和估計在這個sprint需要完成的詳細的任務。所有這個sprint需要完成，但沒有完成的任務的工作量是累積工作量，scrum master會根據進展情況每天更新和積累工作量，如果在sprint結束時，累計工作量降低到0，sprint就成功結束。
Sprint的會議形式：
Daily Scrum 會議：Scrum組織成員每天要開Daily Scrum會議，用15分鐘的時間讓大家review項目的進度情況。在會上，每個團隊成員需要問3個問題：（What have you done on the project since the last daily Scrum meeting?
What do you plan on doing on this project between now and the next daily Scrum meeting?
What impediments stand in the way of you meeting your commitments to this Sprint and to this project?）就是我昨天做了什麼，今天做了什麼，遇到哪些障礙。這個會議的目標是監測項目的全局，定位項目成員的要求，實時的調整當天開發計劃。Note：不允許非項目內的人發言。
Sprint Planning Meeting（sprint規劃會）：參加者有product owner，develop team，scrum master。需要要雞的角色的人蔘與，第三方提供數據後就可以解散。第一個四個小時的會議來對product backlog進行選擇，肯能否在sprint內完成。Product owner在會議之前準備好product backlog，product owner決定哪些要在sprint，develop team可以提出建議。然後team再從product owner選好的product backlog中決定哪些在在sprint。第二個四個小時，develop team列出所有的任務，進行時間的評估和分配。
Sprint Review meeting（sprint 評審會）：一個小時準備時間，四個小時的review時間。參加會議的developteam表明已經完成功能，沒有完成的team不能參見。會議的開始是develop team演示完成的product backlog或sprint backlog，develop team的成員會討論在這個sprint中哪些做得好需要保持，哪些需要改進。會議的大部分時間是產品的演示，以及回答stake-holder的問題。功能演示完之後，stakeholders會對此評價，並提出想要改變的東西以及優先級。接下來product owner會和develop team和stakeholders對product的backlog的反饋進行重現安排和規劃。Stakeholders也許會發表自己對演示的想法，或是提出新要增加的product backlog。在會議的最後，會宣佈下一次評審會議的時間和地點。
Sprint Retrospective Meeting：設定三個小時，參加者有，develop team，scrummaster， product owner可選。所有的develop team需要回答兩個問題：上一個sprint哪裏做得好，哪裏需要改進。Scrummaster會記錄所有的回答，並和team一起排列優先順序。需要改進的項目添加到下一個sprint中作爲高優先級非功能性product backlog。
Scrum定義了許多角色，根據Pig和chicken的笑話分爲兩組，pig和chicken。
豬是全身投入項目和scrum過程的人：Product owner，scrummaster，和Develop Team。
Product Owner的職責：
確定產品的功能；
決定發佈日期和發佈內容；
爲產品的ROI負責；
根據市場價值確定功能優先級；
接受或拒絕接受開發團隊的工作成果。
Develop Team
具有不同特長的團隊成員，人數控制在7個左右；
確定sprint目標和具體說明工作成果；
在項目嚮導範圍內有權利做任何事情已確保到sprint的目標。
高度的自我管理能力；
向product owner演示產品功能。
ScrumMaster
保證團隊資源完全可被利用並且全部是高產出的。
保證各個角色及職責的良好協作。
解決團隊開發中的障礙。
做爲團隊和外部的接口，屏蔽外界對團隊成員的干擾。
保證開發過程按照計劃進行，組織daily scrum，sprint review和sprint planning meetings。
Note：ScrumMaster is not a project manager， the team is self-managing.
