Scrum精髓

四 . Sprint

Sprint的定義

1. Scrum在最長一個月的迭代或周期中安排工作，一般為2個星期，這些迭代或周期稱為Sprint

2. Sprint提供基本的Scrum骨架，大多數(shù)其他的活動和工件都以他為基礎，Sprint是短期的，在時間盒之內，并且具有一致性的持續(xù)期，通常用Sprint的目標來定義Sprint,Sprint目標沒有合理的理由不能更改，Sprint要產生一個潛在可發(fā)布的產品增量，完成時達到大家所認可的完成的定義，一致的程度

Sprint 的內容

1. Sprint是Scrum框架的基礎，一個Sprint 中包含，Scrum中的三個工件，5個事件

2. 所有的Sprint都在一個時間盒內，都有固定的起始日期，一般為2周，每個Sprint的長度盡量保持一致

3. 每個Sprint都有Sprint的目標，每個Sprint都要完成一個潛在可發(fā)布產品增量，并且要達到團隊一致認同的完成目標的定義

4. Sprint以時間盒這個概念為基礎，幫助安排工作執(zhí)行的情況和管理工作范圍，每個Sprint都發(fā)生在一定的時間期限之內，有明確的開始日期和結束日期

時間盒

1. 設定開始但尚未完成的工作清單，范圍是確定的

2. 強制排列優(yōu)先順序

   • 按照優(yōu)先級排序工作清單，快速完成有價值的事情

3. 展示進度

   • 通過完成和驗證重要的工作清單，確保每個Sprint都能產生有價值，可度量的進度，幫助干系人和團隊知道為交付整個特性還需要做多少工作

4. 避免不必要的完美主義

5. 促進結束

6. 增強可預測性

持續(xù)期短的Sprint有很多好處

1. 容易規(guī)劃

   • 為短時間做規(guī)劃需要的時間更短，更容易一些，結果也準確的多

2. 反饋快

   • 快速的產生反饋，每個Sprint開發(fā)出可以工作的軟件，然后有機會檢視和調整，小步試錯

3. 投入產出比高

4. 錯誤有限

5. 檢查點多

一致的持續(xù)周期

團隊應為Sprint選擇一致的持續(xù)期，沒有很特殊的理由，不要輕易的變更長度

1. 有節(jié)奏感
2. 簡化規(guī)劃活動

鎖定Sprint目標

Scrum有一條重要的規(guī)則：一旦制定Sprint目標，在Sprint開始后，就不允許有任何變更對Sprint目標實際產生影響

Sprint目標描述當前Sprint的商業(yè)目的和價值。通常有清晰而單一的重點

1. 共同承諾

   • Sprint目標是團隊和產品負責人做出共同承諾的基礎，團隊承諾在Sprint結束之前完成目標，產品負責人承諾在Sprint過程中，不更改目標

   • 順應變化而調整業(yè)務需求，讓團隊集中精力在短周期內高效的發(fā)揮其才創(chuàng)造價值，Scrum團隊高度關注一個明確定義的，有價值的目標

2. 是變更，還是澄清？

   • 變更：工作或資源的變動，在經濟和時間上造成嚴重的浪費，中斷工作流或在一個Sprint內增加工作范圍，影響整個Sprint目標的進度和實現(xiàn)，放到下一個Sprint中去

   • 澄清：在Sprint執(zhí)行期間提供更多的細節(jié)來幫助團隊實現(xiàn)Sprint目標

3. 變更引起的后果

   • 造成額外的浪費

   • 損害團隊的士氣和信任關系

4. 注重實效，異常終止

   • Scrum團隊注重實效不是鐵律，業(yè)務發(fā)生變化，理應改變Sprint目標，用價值衡量，適應變化

   • Sprint的目標完全無效時，應當異常終止Sprint，并回顧當前Sprint

完成的定義

每個Sprint的結果，都會產出一個潛在可發(fā)布的產品增量，并不意味著構建的增量真的交付給用戶，如何業(yè)務上需要，可以交付，為了確定開發(fā)出來的東西是潛在可發(fā)布的Scrum團隊，必須要有一個明確定義的，大家一致認同的完成的定義

完成的定義是，在宣布潛在可發(fā)布的產品增量之前，要求團隊成功的完成各項定義的工作檢查，比如

1. 單元測試
2. 測試人員覆蓋所有的測試用例
3. 采用的技術
4. 最終的文檔
5. 驗證產品增量，能否實現(xiàn)用戶的期望和價值

五 . 需求與用戶故事

1. Scrum認為，可以自由掌控需求是達成業(yè)務目標的關鍵，關注高價值的需求，需求的細節(jié)是在開發(fā)期間持續(xù)不斷的對話中商討出來的
2. PBI ，每個PBI代表客戶期待的一個業(yè)務價值
3. Product Backlog 中的用戶故事的粗細度，呈現(xiàn)為金字塔結構 ，近期需要開發(fā)的用戶故事中需要進行細化，拆分 ，后面的故事可以是史詩級的用戶故事，逐步的迭代，拆分
4. Sprint Backlog中用戶故事來源于Product Backlog ，產品 負責人根據(jù)業(yè)務的愿景，目標，發(fā)布計劃，以及價值，選取團隊在一個Sprint能做完的用戶故事，并進行細化和拆分用戶故事

收集故事

1. 用戶故事寫作研討會
2. 用戶故事地圖

六 . 產品列表

產品列表的定義

? 產品列表是一個按優(yōu)先級順序排列的，預期產品功能列表，我們把所了解的以什么順序構建什么特性這些信息都集中到產品列表，并團隊共享

產品列表的內容

1. PBI，產品列表由各個待辦事項組成，Product Backlog Item 或簡稱條目

四大特征DEEP

1. 詳略得當，在同一時刻，各個PBI的詳盡程度不相同，呈金字塔結構，越接近迭代開發(fā)的，越細

   • 馬上要做的PBI應該放到列表頂部，工作量小，內容非常詳細，可以在最近的一個Sprint中實現(xiàn)

   • 馬上要做大的PBI時，應當將史詩級故事，拆分成一組小的，可以在一個Sprint內完成的故事

2. 涌現(xiàn)的

   • 根據(jù)實際需求，需求的價值，持續(xù)的更新條目，產品負責人必須考慮新涌現(xiàn)的信息，讓產品列表重新保持平衡并排列優(yōu)先級

3. 做過估算的

   • 每個條目都有大小的估算

   • 故事點，大多數(shù)都是以理想人天數(shù)估算，非常大的，靠近底部的條目，可以用類似于衣服的尺碼的方式來估算，L ,M ,XL等

4. 排列優(yōu)先級順序的

   • 產品列表是一個排列好優(yōu)先級順序的PBI列表，但不可能其中所有的PBI都已經排好優(yōu)先級順序

   

近期的Sprint要做的條目，排列優(yōu)先級很有用，如果在開發(fā)的過程中出現(xiàn)新的條日，需要按照正確的順序插入新條目

梳理

為了得到一個良好的，符合DEEP原則的產品列表，必須積極主動的管理，組織，監(jiān)督產品列表

梳理的重要三大活動，確定并細化PBI（增加PBI細節(jié)），對PBI進行估算，為PBI排列優(yōu)先順序

1. 由誰來梳理

   • 梳理產品列表是一個持續(xù)不斷，合作完成的活動，有產品負責人牽頭，內外部干系人中的主要參與者，包括Scrum Master 和開發(fā)團隊

   • 優(yōu)秀的產品負責人，會充分利用集體智慧和各個組員的不同觀點，發(fā)現(xiàn)可能遺漏的重要信息，讓團隊成員參與梳理活動，可以讓每一個人，更清晰，更一致的理解產品列表

   • 開發(fā)團隊幫助產品負責人，根據(jù)技術依賴關系和資源約束來排列PBI的優(yōu)先順序

2. 梳理就緒的定義

   梳理時，應當確保列表頂部的條目已就緒，可以放入Sprint中，讓開發(fā)團隊有信心做相關工作，并在Sprint結束時完成

   

九 . 產品負責人

1. 產品負責人必須很好的理解組織中利益干系人，客戶和用戶的需求及其優(yōu)先級，從這個角度來看，擔任的是產品經理的角色

2. 對于要構建的特性及其構建順序，產品負責人必須和開發(fā)團隊進行交流，定義驗收標準，確保特性完成

主要職責

1. 參與規(guī)劃

   • 產品負責人和利益干系人一起制定產品愿景

   • 在做版本規(guī)劃時，產品負責人與利益干系人及團隊一起確定下一個版本的內容

   • 在做Sprint規(guī)劃時，產品負責人與開發(fā)團隊一起確定Sprint目標，給出有價值的意見，讓開發(fā)團隊根據(jù)實情在Sprint結束時能交付一組PBI

2. 梳理產品列表

   • 產品負責人負責管理產品列表的梳理活動，包括PBI的建立，細化，估算和排列優(yōu)先順序

   • 負責解答問題，澄清問題，確保梳理活動有助于價值交付，并順利進行

3. 定義驗收標準并驗證

   • 產品負責人負責為每一個PBI定義驗收標準，并確認PBI是否滿足驗收標準

   • 產品負責人要在執(zhí)行Sprint的過程中驗證，及時發(fā)現(xiàn)問題，讓團隊知道哪些特性滿足了完成的定義

4. 與開發(fā)團隊協(xié)作

   • 產品負責人必須經常與開發(fā)團隊保持緊密合作，積極的參與，及時的給出反饋

5. 與利益干系人協(xié)作

   • 產品負責人必須與整個利益干系人團隊，緊密合作，集思廣益，形成一個統(tǒng)一的，愿景來指導產品開發(fā)工作

6. 管理經濟利益和價值

特征/技能

1. 領域能力

   • 產品負責人要有預見性，能夠結合干系人的關注點和期望，統(tǒng)一產品的愿景和目標

   • 有些事情，無法預見時，愿意做出調整，產品負責人必須具備適當?shù)臉I(yè)務和領域知識

2. 人際交往能力

   • 產品負責人和利益干系人保持良好的人際關系，多個利益干系人需求沖突時，能協(xié)調并促成一致意見

   • 產品負責人需要在開發(fā)團隊，利益干系人之間，傳遞信息，大膽發(fā)表意見，能簡單明了，易于理解的方式進行溝通并且取得信任

   • 激勵和鼓舞團隊和利益干系人，讓人們知道業(yè)務的價值和觀點，讓人們保持熱情

3. 決策力

   • 產品負責人得到授權，可以制定決策，有決斷力，關鍵時刻能做出判斷

   • 制定決策時需要在業(yè)務需求和技術實現(xiàn)之間保持適當?shù)钠胶猓趦r值的視角進行平衡

4. 責任心

   • 產品負責人要負責交付令人滿意的業(yè)務成果,重價值的角度合理利用資源

   • 產品負責人時Scrum團隊的成員，團隊協(xié)作一起交付成果

十. ScrumMaster

? 主要負責幫助每個人理解并樂于接受Scrum的價值觀，原則和實踐，幫助團隊和組織其他成員發(fā)展其具有組織特色的，高效的Scrum方法

主要職責

1. 教練

   • 團隊中的敏捷教練，指導開發(fā)團隊和產品負責人，理解和履行Scrum

   • 幫助團隊和成員自己解決自己的問題，遇到團隊和成員無法解決的問題時，才由ScrumMaster解決

   • 協(xié)助和組織，Scrum 過程中的各個活動

2. 服務型領導

   • 幫助團隊高效的運行

3. 過程權威

   • 確保，團隊使用特定的方法實施和遵循Scrum的價值觀，原則和實踐

   • 持續(xù)幫助Scrum團隊改進過程，幫助團隊定義并遵守自己的流程，確保工作完成

4. 保護傘

   • 保護團隊免受外部干擾，讓團隊集中精力在每個Sprint交付業(yè)務價值，讓團隊專注于價值交付

5. 清道夫

   • 承擔清道夫的職責，掃清妨礙團隊生產效率的一切障礙

6. 變革代言人

   • 積極推動變更，幫助他人理解變革的需要，價值

特征/技能

1. 見多識廣

   • 了解Scrum方方面面的知識，理解團隊需要解決的技術問題以及解決方案

2. 善于提問

   • 結合流程，技術和業(yè)務方面的知識，提出重要的問題，幫助團隊人員能夠自己找到答案

3. 由耐心

   • 通過啟發(fā)性的問題，一路指導，團隊或者人員找到解決方案

4. 有協(xié)作精神

   • 想法設法的幫助團隊之間高效率的合作，可以展現(xiàn)個人有效的協(xié)作技能協(xié)助團隊開展工作

5. 保護團隊

   • 幫助落后的團隊成員，遇到困難時，人們容易回退到原來熟悉的非敏捷工作方式，幫助他們客服困難

6. 公開透明

   • 所有形式的溝通都是透明的，做到信息透明

工作內容

1. 每天準備，組織和推進Scrum活動，管理執(zhí)行過程，使團隊其他人的工作過程取的高價值的結果
2. 指導團隊成員，幫助他們提高使用Scrum的技術實踐和能力
3. 與產品負責人一起執(zhí)行梳理活動，關于重要可變的因素，一起進行權衡
4. 變更的推動者，利用靈活時間，掃清團隊遇到的障礙

十一 . 開發(fā)團隊

? 開發(fā)團隊成員整體具備的技能足以實現(xiàn)產品負責人要求交付的業(yè)務價值

1. 專職團隊

   開發(fā)團隊能在每個Sprint都能完整的交付業(yè)務價值，包含，設計，開發(fā)，測試 ，產品等

   只要可能，我們就要建立跨職能團隊

主要職責

1. 每日檢視和調整

   • 每個開發(fā)團隊成員，都應該參加每日站會，在會上，團隊成員一起檢驗Sprint目標的進展情況，根據(jù)當天工作情況調整計劃

2. 梳理產品列表

   • 準備下一個Spint，主要是梳理產品列表，包括PBI的創(chuàng)建和細化，估算，和排列優(yōu)先順序

3. Sprint 規(guī)劃

   • 開發(fā)團隊參與Sprint規(guī)劃會，在ScrumMaster的協(xié)助下，開發(fā)團隊和產品負責人合作為下一個Sprint建立目標，對于2周的Sprint，規(guī)劃通常花半天時間

   • 團隊更愿意在每個Sprint開始時，制定一系列更小的，更確定的且更集體的及時計劃

4. 檢視和調整產品和過程

   • 開發(fā)團隊參加，Sprint評審會議和Sprint回顧會議，在Sprint評審會議上，評審當前Sprint完成的特性，并討論下一步改進措施

   • 在Sprint回顧會議上，Scrum團隊檢視和調整自己的Scrum過程和技術實踐，進一步改善團隊使用Scrum來交付業(yè)務價值的方法

特征/技能

1. 自組織

   • 團隊成員自組織決定實現(xiàn)Sprint目標的最佳方式，沒有自上而下,命令與控制的權威告訴他們如何工作

2. 跨職能

   • 開發(fā)團隊成員應該是跨職能多樣化的，他們共同擁有必要的，足以完成工作的技能

3. T 型技能

   • 靈活的開發(fā)團隊是由T型技能的成員組成，技能的深度和廣度

   • 團隊成員掌握的知識不一樣，鼓勵成員幫助其他成員掌握一些自己掌握的知識

4. 火槍手態(tài)度

   • "人人為我，我為人人"，團隊成員共同承擔完成工作的責任，成敗是整個團隊的事情

5. 溝通廣泛

   • 開發(fā)團隊成員，產品負責人，ScrumMaster 之間，需要進行廣泛的溝通，彼此之間以最低的成本速度，高效的交換有價值的信息，更好的檢視和調整，也增強自己在實現(xiàn)時的判斷力

6. 透明溝通

   • 團隊內部溝通也要透明，溝通透明能夠使所有的成員都清楚現(xiàn)狀，建立互信

7. 規(guī)模適中

   • 推崇小團隊，由5到9名成員組成

8. 專注，由責任感

   • 專注是指每個團隊成員參與并集中精力關注團隊目標，責任感是指不論情況好壞，每個團隊成員都會致力于完成團隊共同的目標

9. 工作步調可持續(xù)

   • 團隊成員必須以可持續(xù)的節(jié)奏工作，達到工作的平衡，不會出現(xiàn)大量高強度的工作

10. 團隊人員穩(wěn)定

十九 . Sprint規(guī)劃

為了確定在下個Sprint中構建的，最重要的PBI子集，Scrum團隊會做Sprint規(guī)劃，對Sprint目標達成一致，開發(fā)團隊確定與目標一致的具體每個PBI，同時確定時 間能在Sprint結束之前交付，開發(fā)團隊創(chuàng)建一個PBI完成計劃，PBI和計劃共同組成Sprint列表

1. 時間安排

   一般發(fā)生在每個Sprint開始，利用最優(yōu)信息來決定下個Sprint做那些PBI

2. 參與者

   Sprint規(guī)劃由整個Scrum團隊協(xié)作完成，

   產品負責人分享初始Sprint目標，展示排定優(yōu)先級順序的產品列表，回答團隊提出的問題

   開發(fā)團隊用心確定可以交付那些特性，在Sprint結束之前做出靠譜的承諾，

   ScrumMaster,提出深入細節(jié)的問題，引導并且?guī)椭鷪F隊導出成果

3. 流程

   Sprint規(guī)劃依賴于產品列表，產品列表最上面的PBI，是大小合適，經過估算，而且有優(yōu)先順序的

   

大多數(shù)團隊會把每個目標PBI分解成一系列的任務經過估算的任務，遵循一個有用的任務分解規(guī)則，團隊達成共識，實際要做什么，是否能在可用的時間內完成，確定Sprint目標，并對Sprint列表作出承諾

Sprint規(guī)劃的兩種方式

1. 兩段式Sprint規(guī)劃

? 在1階段，確定其完成工作的生產能力，預估在Sprint結束時能夠完成的PBI，如果團隊能完成40個故事點，就選大概40個故事點的工作

? 在2階段，大多數(shù)團隊把PBI分解成一系列的任務，然后估算（以小時計）完成每個任務需要多少 工作量，根據(jù)任務估算的小時數(shù)和團隊的以小時計的生產能力，確定1階段的承諾是否現(xiàn)實

? 如果團隊發(fā)現(xiàn)選取的PBI太多或者太少，或者選取的PBI由于種種限制不能在一個Sprint中完成，可以進行調整，能達到預期后，確定承諾的PBI列表，結束Sprint規(guī)劃活動

2. 一次性Sprint規(guī)劃

? 開發(fā)團隊首先確定可用的生產能力，Sprint目標可能需要細化，接下來，團隊依次選擇PBI，并表示有信心在當前Sprint完成它，直到團隊沒有余力做更多的工作，確定承諾，結束Sprint規(guī)劃活動

確定生產能力

確定可用的團隊生產能力，了解團隊在每個Sprint中能完成多少工作，有助于能夠交付那些特性

1. 用故事點來表示生產能力

   PBI的故事點或者理想人天，Sprint列表的任務工時

   利用團隊的平均速率和上一個Sprint的速率，作為新一輪Sprint的初始速率

2. 用工時來表示生產能力

   確定團隊成員每天有多少時間能完全投入到Sprint的工作，每個人都給出一個范圍，團隊估算出能用于做PBI的生產能力的范圍

選取PBI

1. 有Sprint目標，就選取與目標一致的PBI
2. 產品列表從最上面的PBI開始，依次選取合適的的PBI
3. 最好不用選擇評估出來比較大的PBI，需要拆分和細化，選取合適的，選取的PBI在Sprint結束之前能達到一個潛在可發(fā)布產品增量的目標

獲得信心

1. 使用預測速率來看看承諾是否實際，對承諾進行檢查和權衡
2. PBI分解成任務需要精心設計，適當?shù)囊?guī)劃
3. 讓團隊成員在Sprint執(zhí)行過程中，見機行事，適時，自主的選擇工作任務

細化Sprint目標

1. Sprint目標總結了業(yè)務目標的價值，產品負責人帶著初步的Sprint目標參與Sprint規(guī)劃活動，團隊可以進行優(yōu)化，可以一起決定實際能夠交付那些PBI

2. 確定Sprint承諾，表明團隊能夠交付的業(yè)務價值

二十 . Sprint執(zhí)行

? Sprint執(zhí)行有點像一個小的項目,為交付一個潛在可發(fā)布產品增量而必須完成的所有工作

1. 時間安排

   • Sprint執(zhí)行占Sprint中大部分時間，開始與Sprint規(guī)劃，結束于Sprint評審

2. 參與者

   • 開發(fā)團隊成員自組織并想方設法完成Sprint確定的目標

   • ScrumMaster作為教練，引導師和清道夫，參與執(zhí)行，幫助團隊取得成功

   • 產品負責人在執(zhí)行的過程中，回答需要澄清的問題，檢視工作進展，為團隊提供反饋，討論Sprint目標的調整，驗證PBI是否滿足驗收標準

3. 流程

工具

1. 任務板 + 燃盡圖

   • 團隊成員在每日站會上，按照合理的順序，領取任務，更新任務 ，并匯總任務工時，更新燃盡圖

二十一 . Spring 評審

檢視和調整當前構建的產品，讓干系人清楚的看到產品當前的狀態(tài)，包括各種讓人頭痛的真相

干系人可以進行提問，發(fā)表見解或給出建議，討論結合當前實際最好采取那些措施，來解決各種問題

1. 參與者

   • Scrum整個團隊

   • 能邀請到的所有的干系人

準備工作

1. 確定邀請誰參加

   • 確定干系人，并邀請他們參加會議

   • 如果某個人或某個團隊的意見對Sprint評審非常重要，應該重點關注

2. 安排活動日程

   • 需要安排Sprint評審的活動日程（時間，地點，多長時間）

3. 確定Sprint工作完成

   • Sprint評審時，只允許團隊展示已經完成的工作，并且滿足完成的定義

4. 演示準備工作

   • 團隊在Sprint評審時演示潛在可發(fā)布產品的增量，需要做準備工作，比如部署環(huán)境，數(shù)據(jù)準備等

   • 一次儀式少，價值高的非正式會議，開城布工的方式進行檢視和調整

5. 確定誰做什么

   • 團隊需要確定誰負責組織評審會議，誰來演示

方法

執(zhí)行Sprint評審的常見方式是：總結或概要說明Sprint的目標中那些完成了，那些沒有完成，演示潛在可發(fā)布的產品增量，討論產品當前的章臺，調整產品未來的方向

由Scrum團隊成員（通常是產品負責人）展示Sprint目標和Sprint目標相關的PBI，概述在Sprint中實際產生的產品增量，如果結果與目標不符，Scrum團隊需要給出解釋，不要指責他人

評審的目標：描述完成的目標，參與者之間深入交談和合作碰撞得出建設性的，實際可行的調整建議，然后利用這些信息確定最佳前進路線

1. 演示

   • Scrum團隊演示當前Sprint產生的產品增量
   • 有演示的東西，必須是測試通過的，產品負責人，驗證符合驗收標準的
   • 沒有演示的東西，比如，架構和重構等，必須說服產品負責人，加入到Sprint的PBI中，讓產品負責人，認識到其價值

2. 討論

   • 產品增量的演示會成為深度討論的焦點，積極鼓勵參與者就產品和方向發(fā)表言論，評論與合理的討論
   • 討論使非Scrum團隊的參與者能夠提出問題，了解產品當前的狀態(tài)，幫助指導產品的方向，同時，Scrum 團隊成員，獲得客戶或用戶的反饋意見之后，能夠更深入的從業(yè)務和市場兩方面理解產品

3. 調整

   1. 通過演示和討論，團隊能夠提出并回答下面幾個問題
      • 利益干系人喜歡他們看到的東西嗎？
      • 他們希望看到變化嗎？
      • 產品在市場上或對內部客戶來還是一個好的想法嗎？
      • 我們是否遺漏重要的特性？
      • 我們是否在不必要的特性上過度開發(fā)和投入？
      • 產品的增量，滿足了干系人的期望嗎，解決了他們的痛點嗎？
   2. 大多數(shù)團隊會在Sprint評審會上都會順帶做一些梳理工作，干系人更多的了解當前開發(fā)工作和進展情況，新增，修改，一些PBI，調整PBI的排列順序，可能會影響下一個Sprint中的內容
   3. 根據(jù)梳理工作的影響，確定影響的范圍和時間，調整版本計劃，Sprint評審結束時找出調整方案，響應變化

二十二 . Sprint回顧

在回顧期間內團隊可以無拘無束的檢查發(fā)生的事情，分析自己的工作方式，找出改進的辦法，制定改進計劃，任何影響團隊產品構建的事都可以仔細的檢查，討論，包括，過程，實踐，溝通，環(huán)境，工件，工具等

每個Sprint都要舉行回顧會議，檢視和調整Scrum過程，盡早的發(fā)現(xiàn)問題，解決問題

怎樣執(zhí)行Sprint回顧

1. Sprint可以很簡單，比如團隊成員一起討論下面幾個問題
   • 這個Sprint那些地方做的好，需要繼續(xù)發(fā)揚?
   • 這個Sprint那些地方做的不好，今后要避免?
   • 我們要開始做什么或改進什么?
   • 團隊成員制定出一些可實施改進的措施，一次最好不要解決太多的問題，選取最有價值的問題，一起找到根本原因，并給出解決方案，并記錄問題和解決方案，形成列表，方便以后對照，并貫徹執(zhí)行

參與者

1. Scrum團隊全員參加

準備工作

1. 定義回顧重點

   • 每次Sprint回顧都要有一個明確定義的重點默認重點是各方面回顧當前Sprint中使用的過程
   • 確定重點有利于回顧會議的準備和進行比如，數(shù)據(jù)，邀請參與者，縮短會議的時間

2. 選擇練習活動

   選擇合適的練習活動可以幫助參與者投入，思考，探索和決策，做好準備工作，保持靈活，典型的回顧會議包括下面幾個二練習

   • 建立并挖掘Sprint事件的時間線
   • 通過頭腦風暴獲得見解
   • 將獲得的見解進行分組并投票表決

3. 收集客觀的數(shù)據(jù)

   短時間內完成的在回顧會議開始之前應當完成數(shù)據(jù)收集工作，比如，PBI的完成情況，燃盡圖等

4. 安排回顧日程

   • 確定會議的時間，地點，以及會議的大概時長
   • 確定負責引導回顧的人，一般有ScrumMaster 做引導

方法

• 回顧期間要求分析團隊的行為和表現(xiàn)，最好先營造氛圍，讓人們能夠輕松參與
• 人們發(fā)表意見時必須要有安全感，不用擔心，回顧側重于組織體系和過程，不針對個人
• 建立一個積極參與的慣例也很重要，團隊積極的發(fā)言，討論