1.用戶需求分析轉(zhuǎn)化為產(chǎn)品BACKLOG
這個部分的內(nèi)容由PM具體負責，主要的工作內(nèi)容如下：
用戶調(diào)研,、需求分析,，確定產(chǎn)品迭代功能，出具產(chǎn)品BACKLOG,。決定產(chǎn)品的發(fā)布日期與發(fā)布內(nèi)容,，給迭代計劃預設目標。根據(jù)RIO（商業(yè)價值/工作量）排序優(yōu)先級,，考慮必要風險,。
優(yōu)先級排序：排序的目的，是弄清楚哪些需求最重要因此可能在最近的一兩次迭代中進行開發(fā),。參與排序的條目一般足夠接近半年的開發(fā)工作量,，但多數(shù)只有一個簡短的名稱，只有最高優(yōu)先級的需求才會被真正細化,，也就是近一兩次迭代要開發(fā)的需求列表,。在每個Sprint結(jié)束或者臨時需求變更時，都需要更新優(yōu)先級的排列順序,。
關(guān)鍵物：產(chǎn)品BACKLOG
如圖：
2. Sprint計劃會議生成Sprint BACKLOG
這個部分的內(nèi)容主要由開發(fā)經(jīng)理負責,，主要工作內(nèi)容如下：
將產(chǎn)品BACKLOG拆分為在本次Sprint中可細化的Sprint BACKLOG,。Sprint BACKLOG中的開發(fā)任務以小時估算，預計1-16小時的工作量化,。根據(jù)開發(fā)優(yōu)先級管理Sprint BACKLOG,，隨時更新Sprint BACKLOG狀態(tài)。每個團隊成員都可以自主挑選任務,，修改Sprint BACKLOG,。
優(yōu)先級排序：要完成這個選擇其實不太容易，如果只是盯著產(chǎn)品BACKLOG“重要程度”這個排序依據(jù),，極有可能從很多功能模塊中各自挑出最重要的需求,，而這些需求湊在一起，只能形成一個四不像的版本,。因此常?？梢蕴暨x最重要的功能模塊中的多個條目，形成整體完整的一個“故事群”,，這樣無論開發(fā),、測試和演示環(huán)節(jié),，都有一個相對內(nèi)聚的目標,。為了防止大家中途跑偏，常常給每個沖刺要都起一個簡短的名稱,，比如：“本次迭代將發(fā)布一個具有電子節(jié)目單的版本,。”
關(guān)鍵物：Sprint BACKLOG
如圖：
3.迭代開發(fā)周期,，每日例會,，交付迭代版本
這部分內(nèi)容主要由開發(fā)團隊共同推進，主要工作內(nèi)容如下：
依照Sprint BACKLOG,，開始開發(fā)工作,，更新工作任務面板。參加每日例會,，圍繞昨日進度,、今日安排、所遇困難三個方面快速的梳理一遍任務面板上的工作內(nèi)容,，所遇困難在會后點對點進行討論解決,。保證整體開發(fā)進度不大幅度的偏離預設的Sprint燃盡圖。高度的自我組織管理,，保持良好的跨職能團隊溝通,，確保實現(xiàn)Sprint目標。
優(yōu)先級排序：一般在迭代計劃會上使用MoSCoW方法進行這種排序,，將要Sprint Backlog中的條目分為四級（其實只有前3級）：
Must：必須做的
Shoud：應該做的
Could：可以做的
Would not：不要做的
要按照這些順序來做,，保證Product Owner所需要的Must,、Should完成，并力爭Could能完成,；在發(fā)生重要變更的時候,，犧牲Could乃至Should保證變更。開發(fā)過程中避免在M,、S完成前就有人動C,。
關(guān)鍵物：燃盡圖
如圖：
4.驗收發(fā)布版本，評審回顧會議,，周期數(shù)據(jù)報表
這部分內(nèi)容主要由Sprint團隊成員共同參與,，主要工作內(nèi)容如下：
產(chǎn)品開發(fā)團隊通過操作演示的方式展示Sprint中完成的功能與架構(gòu)。PM根據(jù)產(chǎn)品BACKLOG,，驗收開發(fā)交付的迭代版本,，發(fā)布產(chǎn)品迭代版本。收集Sprint問題反饋,，尋找根本原因,，討論解決方法，改善Sprint過程,。
參考文章：
http://cloud.51cto.com/art/201711/559483.htm
