有效的衝刺追溯性
David Starr 是 Scrum.org 的首席軟體大師，他致力於提升軟體開發業界的專業素質： 他也設立了線上技術社群 ElegantCode.com (英文)。
2012 年 7 月
探索核心品質，以及用於的做法可確保追溯性會議是小組的最強的改善工具。 超出技術範圍，本文提供方式維護和改善追溯性的作法和結果。
套用至
應用程式開發週期管理， Visual Studio Team Foundation Server，
沒有故意維護和改善效能，系統趨勢往 Entropy 並隨時間而降低。 這是相同的真正的軟體開發小組，不如特定動作成員和高度耗費資源的執行)。 因此 Scrum 規定衝刺 (Sprint) 追溯性會議、需健康集中的通常發生的 Scrum 小組的事件和效能。
衝刺 (Sprint) 追溯性會議是 Scrum 小組在本身和其工作反映的工作階段，產生改善的可採取的動作。 衝刺 (Sprint) 追溯性會議是最後的事件在每個衝刺 (Sprint) 中，指出每個衝刺 (Sprint) 循環結束。
從 2011 年 10 月 Scrum Guide:
衝刺 (Sprint) 追溯性會議是 Scrum 小組的機會可以檢查自己和建立計劃才能在下一個衝刺 (Sprint) 期間要立法的改善。衝刺 (Sprint) 追溯性會議的目的是:•檢查最後衝刺 (Sprint) 如何移至相關人員、關聯性、處理序和工具;•識別並指令進展順利和潛在改良的大寫項目;然後，•建立實作改善的一個規劃 Scrum 小組完成工作的方式。
小組在衝刺 (Sprint) 追溯性會議刻意改善。 有效的衝刺 (Sprint) 追溯性會議是協助小組好的一個重要因素來變得很大，而且大型小組承受自己。
概觀
衝刺 (Sprint) 追溯性會議的原因會造成
追溯性會議廣泛視為最不可缺少連絡人焦點的 Agile 技術。 檢查並調整位於靈活度的核心，，和追溯著重於檢查並調整在軟體組織的價值迴資產，小組。 未達成改善做為追溯需要，真正的靈活度無法達成。
效能不可以改進和維護沒有練習。 不過進行工作階段不是足夠成功。 必須注意確定小組計劃改善。 如果改善的計劃不屬於這個結果的一部分，它不一定是衝刺 (Sprint) 追溯性會議。
這樣很好，追溯性會議通常最有利的計量表式小組採用。 當進行不足，可以是大手大指令和嚴重的呈現需求。
健康衝刺 (Sprint) 追溯性會議的結構
Scrum 是一點有關衝刺 (Sprint) 追溯性會議內部結構。 而非規定衝刺 (Sprint) 追溯性會議方式進行， Scrum 指定衝刺 (Sprint) 追溯性會議的輸出:Scrum 小組為下一個衝刺 (Sprint) 將立法的改善。
這種彈性 birthed 大多特別設計的工具和技術進行追溯性。 數個通用的做法在本文稍後將說明，不過，不管使用的這個特定技術，好衝刺 (Sprint) 追溯性會議有下列特性:
整個小組進行
在小組討論焦點而不是個別
小組的定義會被瀏覽和希望展開
採取行動的認可清單建立
目前衝刺 (Sprint) 追溯性會議的結果會造訪
這項討論與所有出席者相關
整個 Scrum 小組參與每個衝刺 (Sprint) 追溯性會議。 通常，這表示產品擁有者和開發小組要做為參與者時， Scrum 主管有助於會議時。 在某些情況下， Scrum 小組邀請其他參與者到達會議。 在嚴格地使用客戶或其他專案關係人，這特別設定獨立的。
不論誰出席，衝刺 (Sprint) 追溯性會議的環境必須是安全的所有參與者。 這表示出席者一定誠執行和透明，當將其他與接受時。 激情在追溯性會議可能光源和改善效能問題討論;熟熟悉的便利確保正討論的保持和專家，著重於整個小組的改善。 這不是個人平移或攻擊的機會。
(如需協助您的 Microsoft Visual Studio 2012 工具的詳細資訊規劃及管理衝刺 (Sprint)，請參閱 共同作業 [重新導向])。
加入定義做
在 Scrum 的開發小組使用定義會注意什麼條件必須成立有關其工作，會被視為完成之前。 例如，它實作的開發小組可能會決定每個功能必須至少有一個傳遞的自動化的接受度測試。 或小組完工定義可能出現，必須檢閱的所有程式碼。
開發小組的定義會被視為一段時間的展開。 新建立的小組與共用記錄的更成熟的小組將不變地具有較不嚴格和較小的定義會改善。 展開完成的位於的小組的定義是 Kaizen 核心，這表示在改善的日文術語的一個記住及常數的焦點。 當小組最初可能需要只在簽入之前的程式碼組建，它們應該一段時間演化像需要更多登記暴斂準則對於單元測試隨附於新的程式碼。
每個衝刺 (Sprint)，開發小組希望學習通知擴充定義所做的事。 衝刺 (Sprint) 追溯性會議是討論哪些已觀察並了解了在衝刺 (Sprint) 期間結果，以及完善的論壇變更可能對定義做。
因為並非所有產品擁有者有興趣或包含在內部開發小組練習，某一個 Scrum 小組除了衝刺 (Sprint) 追溯到兩個不同階段中:
在整個 Scrum 小組的焦點
在開發小組的焦點
如需完工定義的詳細資訊，請參閱 MSDN 文章 完成與未完成。
這樣可採取行動的承諾
在會議期間，雖然討論可能分離和彙總，衝刺 (Sprint) 追溯性會議不成功，則不會產生認可由小組。 它不是以足夠在衝刺 (Sprint) 期間，所發生。 Scrum 小組完成的可採取行動的認可它將:
保持做
開始進行
停止執行
「採取行動」這個字是很重要的。 採取行動的認可會清除的步驟來完成和驗收準則，像是個好要求。 可採取行動的認可由小組清楚明確表示並了解。
當小組先開始執行追溯性會議期間，所以它們比配置通常會出現容易識別問題如何對它們。 因此，小組發行的承諾可能看起來與下列:
在較小批次的工作
使要求更容易閱讀
撰寫多個單元測試
在評估時，將會更精確。
這些不是認可;可能有目標或小型地遮掩的抱怨。 在衝刺 (Sprint) 追溯性會議期間，這些一定是小組可能希望討論的問題，不過，採取行動的認可的清單詳細如下所示:
每天至少兩個簽入程式碼:午餐之前和在開頭的前
為使用者劇本和包含驗收準則的明確新產品待處理項目
建立在固定之前證明缺失存在的失敗的自動化測試。
在產品待處理項目整備會議期間，使用規劃撲克牌 (Planning Poker)
在衝刺 (Sprint) 追溯性會議前進行認可在每個衝刺 (Sprint) 追溯性會議已瀏覽過的。 這是為了追溯性可以保留其意義和值。 少數情況一樣令人按下會像在不斷地決定改善，而取得具體的進度這麼做的小組。
在衝刺 (Sprint) 追溯性會議可以是重要的小組成員比必須投入必須更是存在時，它們。 建立可採取行動的認可的合作小組中成功進行出席者會將它們。
保持其相關
衝刺 (Sprint) 追溯性會議基本上是一種技術顯示做法，而 Scrum 的行為合作對本身。 當自組織變得自知時，便會修正和刻意改善，當工具即可。
若要讓的追溯性可以有用，它們必須是有意義的參與者。 如果焦點不在參與者重要的事情，優點不會實現。 它認為必須允許的小組考量，並改善在區域中很重要的。 此外，如果，方便或規則的屬性巡覽追溯到特定的討論，小組避免承擔本身和其工作的責任。
已瀏覽過的主題應該與所有層級專業知識相關。 例如，在瀏覽進階測試驅動式開發 (TDD) 案例中儲存為的點值，如果某些小組成員不熟悉即使單元測試。 實際值可能會決定將小組寫入測試數目，以取得一些訓練，或是有確定的小組成員在 TDD 指導其他。
保留在 Scrum 小組、不是這個取代這個更廣泛的組織的焦點。 反白顯示全部讓小組真誠地查看自己為自我組織單位，而不是個別的鬆散聯邦。
解決個別效能問題在小組追溯性會議期間不適當。 不僅是最適當地為個人意見，個別的行為不是小組可以同時變更的項目。 有一個小組專注在衝刺 (Sprint) 追溯性會議期間是嚴重危害 recipe，可能導致無法彌子目錄的損害之小組成員的信任彼此。
若要讓的追溯性可以有意義，它們應該專注於小組可以控制的問題。 移動一項全公司假期原則可能是名稱解析為搜尋有同情心的字耳的人，採取行動，但是會說明小組改善。 必須注意小組可以影響本身可能選擇一項特定原則中的問題，例如回應
變更技術
有進行追溯性的許多技術。 嘗試不同的衝刺 (Sprint) 追溯性會議的建構維持簡易性更新和有趣。 身為 Scrum 小組的主要便利， Scrum 主管應該至少熟悉更普遍的技術。
包含整個憑證有關追溯性和豐富的部落格文章說明人從其作法取得多。 某些最普遍則簡短描述此處。
基本技術
以最基本衝刺 (Sprint) 追溯性會議的方便存取小組的基礎問題並協助討論。 方便或 Scrum 主管可以使用各種激發行精靈有技術可讓小組回答:
要在這個衝刺 (Sprint) 中進展順利?
會顯示任何項目使用的改善這個衝刺 (Sprint) 中發生?
我們將決定在衝刺 (Sprint) 中?
在無訊息，的 3-5 分鐘期間取得這些回應的簡單技術有每個小組成員寫入 2-3 回應要自黏便箋的問題。 一旦建立，建議在所有的圍牆上群組可以在輪詢之前參閱。 採取行動的認可清單可以藉此的問題集需要大量益衍生。
其他大部分衝刺 (Sprint) 追溯性技術只在這個主題的變化，而且可能以此流程的問題或階段。 在任何情況下，結果是最重要和所有最有用的技術支援基礎模型。
檢閱前認可
除了向右合樣下個衝刺 (Sprint) 之外，每個衝刺 (Sprint) 追溯性會議上一個衝刺 (Sprint) 和相關討論應包含進行認可檢閱有關小組成功在符合那些認可。 如果這個討論不是每個衝刺 (Sprint) 追溯性會議的部分，出席者很快了解其承諾不重要，因此，它們會停止符合它們。
此外，檢閱衝刺 (Sprint) 追溯性認可的正確位置是在衝刺 (Sprint) 期間，而不只是這一端。 一旦改善的認可，則將其張貼可能公開有助於確保它們一天視為。 某些小組值張貼在衝刺 (Sprint) 追溯性會議期間所做的認可在公用區域的圍牆做為提醒對哪些人應該專注於每天改善。
特定技術
有執行部分或衝刺 (Sprint) 追溯性會議的整體的許多其他技術。 許多技術名稱下面列出，而每個都是值得的詳細討論。 下列所有具有大量說明連接和各種發行。
衝刺 (Sprint) 追溯性會議的技術。
Fishbowl
瘋狂終結哀人士高。
海星
問題樹狀結構
旅途行
6 的概念、
會識別賞力的需求
前 5
動作計劃
遊戲)。
深層淵
完美遊戲
更符合
自船追溯
強制執行分析
四個升級
全局 Café
情感地震檢測
請的便利的特殊兩豐富的資源展開其追溯性工具箱為:
書籤 Agile 回顧:使優秀小組大由酯類別德比和 Diana Larsen。
衝刺 (Sprint) 追溯性不是 Scrum 主管的向下不變。 最近轉型的 Scrum 主管有時會誘想要從衝刺 (Sprint) 胡 Scrum 地變更技術到衝刺 (Sprint)。 當在追溯性的各種防止落入車輪痕跡時的小組，磨修改此與一些一致性會產生最佳結果。 將焦點放在需要追究之結果的小組將會從其追溯性的大部分的值。
當追溯無法運作
終結比無法使用或浪費時間，非常執行衝刺 (Sprint) 追溯性會議可以是解構性和有害給小組。 因此，，特別是當小組剛作法，有熟熟悉的便利品行會議是高度建議的。
說明通常是 Scrum 主管的工作，不過，為 Scrum 主管新增角色，這可能不是或專業領域。 它比 Scrum 的操作知識需要更多為了衝刺 (Sprint) 追溯性會議可以有正面影響;它要求說明技術以及導致離開負數討論群組趨向於正影響。
一般顯示特定
終結追溯性的常見範例為惡化的牢 ADO 工作階段的一個。 請記得要識別工作進展順利不足去的比較容易，因此， 「改善建議儲存流很容易會變成抱怨洪流，當便利不會對談方向時。
衝刺 (Sprint) 追溯性會議不適合還顯示特定:
就追溯而論「事後」或「之後動作」報告而非機會改善計劃。
無繫結出席者
註解的單一的效能
沒有產生的可執行動作的承諾
沒有「我們顯露出了」回應;小組必須了解和達成賞其正和負無限大的行為模式和實務
總共上述情況，追蹤否定性根本原因到缺乏信任和認可一或多位小組成員部分通常是容易的。 當未處理此時的銀色符號， Scrum 明確收費 Scrum 主管與工作往這類定址的情況。
它運作我們會很好停止
雖然衝刺 (Sprint) 追溯性會議強大且重要的事件，它們是 Scrum 的一個通常會捨棄的項目。 與最新規則成功 Scrum 小組傾向於合理化需要執行衝刺 (Sprint) 追溯性會議。 這能與決定一個適當的人員停止執行。
這個項目互動可能看起來如下:
六個月在展示 ScrumDeveloper 之後戴維度:品質引發， Bug 關閉。士顯示為高，手動復原成本不足。因為這樣很好的作法，我們不需要在衝刺 (Sprint) 追溯性會議協助我們再改善。上司 Bob:該音效合理。取消這個工作階段將儲存我們可以在上加入更多功能所花費的時間。六個月 LaterBoss Bob:品質拒絕，並加入 Bug。小組成員未滿足，許多復原工作手動執行。開發人員戴維度:由於 Scrum，它是。我們告訴您不是銀色符號，而且不清楚地運作。上司 Bob:true。我要尋找一位方法顧問實作新的處理序。
很明顯地，它不是失敗這裡的 Scrum。 省略 Scrum 的成功關鍵字元件的組織的階段是失敗的觸發程式庫。 可惜的是這個案例中是所有太一般。
Scrum 小組達到高效能大部分儲存狀態很罕見，內容會和易損壞的基底類別。 有意義的追溯性會議是繼續這些小組的一個重要因素來作用在這類高階。 反映本身可讓小組自動調整並達到更高層級的效能和產品品質。 這是 Kaizen 基本資訊和核心改進對任何實際的程式。
當追溯運作時，結果是可觸發知的。 在嘗試新增項目的小組的相關奮。 當追溯運作時，這些作業可能不可避免為 true:
小組在一段時間內達到可測試量地越来越高品質等級。
個別小組內了解其角色
採取行動的認可由所有小組成員知道
最後，，在衝刺 (Sprint) 追溯性會議正常運作時，小組成長到這個組織的反白顯示，具有高生產力、高迴物品。 絕佳軟體開發小組不會出現。 它們對改善的故意擔心只經過一段時間後再出現。 衝刺 (Sprint) 追溯性會議是出生的關鍵字元件。