Sprint回顧大揭祕——「寶典」來了

我始終記得當年我做爲敏捷教練所作的第一次Sprint回顧，這一切都彷彿就發生在昨天。這家公司實行Scrum有好幾年了，我天然而然地認爲他們這羣人是紀律嚴明而且成熟穩重的敏捷專家。

所以，當他們計劃了一系列Sprint回顧會議，用來展現X團隊最新Sprint成果時，我感到異常興奮。我早早地溜進了會議室，併爲本身找了個絕佳的位子坐下，翹首以盼。

漸漸地會議室裏的人愈來愈多，並變得嘈雜起來，這反而使個人指望到達頂點，我知道好戲就要開演了。這時，第一個團隊登上了「舞臺」，準備他們的回顧，他們打開PowerPoint作的幻燈片，「演出」終於開始了！

 

第一個團隊準備的材料實在是精挑細選，他們準備了在這個Sprint中他們所完成的事情的列表，還配了插圖，甚至還準備了些在適當時刻調節氣氛的小笑話。他們一一講述團隊所作的工做，一頁接一頁地翻動着幻燈片，在恰當的時機，聽衆也不失時宜地禮貌地鼓掌以表示對他們的讚許。

然而，當第一場回顧進行到一半的時候，我意識到彷佛有很是、很是重要的東西被遺漏掉了，怎麼沒有代碼演示呢？我心中感慨，這樣的錯誤怎麼會發生在這樣一羣成熟且經驗豐富的敏捷專家身上呢？整個Sprint回顧的最終目的就在於向各位利益相關者展現這個Sprint所完成的代碼，並獲得你們的反饋。當時我想，也許這只是一個特例，只是被這個團隊疏忽了，接下去確定會有代碼演示。

然而，我期待的事情並無發生，以後的每個團隊使用着跟第一個團隊相同的模式——風趣幽默的幻燈片和文字，對他們的工做量進行說明，並無代碼演示，這讓個人熱情迅速耗盡， 也讓我完全失望。

相關廠商內容

Droid Plugin如何實現免安裝運行第三方插件APK？

在容器時代，雲計算下一步將如何發展？

ArchSummit8折優惠期，節省1360元/張！

 

相關贊助商

全球架構師峯會，12月18-19日，北京·國際會議中心，8折報名。

 

對於整個團隊而言，還有那些詮釋過Sprint回顧意義的人而言，顯而易見地是，他們並無真正理解Sprint回顧的意義。固然，利益相關者也沒能理解這麼作的目的，他們仍然對那些設計好的笑點禮貌地迴應，並鼓掌確定團隊的工做，彷佛這個儀式僅僅是爲了給Scrum流程列表上的這一項打上個勾而已。

千萬杜絕！

在此後的Sprint回顧中，毋庸置疑的是，我不再會讓這類事情發生了。我很敬佩這些團隊的自主精神，但我仍然當即列出了從此Sprint回顧應該完成的目標以及如何實現這些目標的綱領。

綱領中的某些項目跟敏捷宣言（Agile Manifesto）很是合拍，例如在每一個迭代或Sprint結束時進行代碼演示的理念，但有些項目倒是咱們的組織以及企業文化中特有的。

這纔是文章的重點。我打算與你們分享，咱們當時是如何轉變Sprint回顧的主要綱領、戰略以及心態的，正如：

• 從禮節性地鼓掌轉變到熱烈地歡呼
• 從禮節性地鼓掌轉變到得到有建設性的反饋
• 從兜售咱們的成果轉變到讓成果變成真實透明
• 從小衆羣體參與轉變到大衆站立方式並運用錄影
• 從幻燈片轉變到代碼演示
• 從娛樂大衆的心態轉變到展現團隊能力及產品價值
• 從「授課」形式的演示轉變到有交流、有互動的形式
• 從刻意兜售咱們的成果轉變到「姜太公釣魚，願者上鉤」、讓事實說話的形式

固然，冰凍三尺非一日之寒，這些不會立刻發生，咱們仍然在日復一日持續對咱們的Sprint回顧進行着調整和優化。幸運的是，咱們當真找到了一些門路，使之成爲貫穿組織架構中實施敏捷流程的基礎。 讓我來分享幾件咱們用心作的事情吧。

「出色」的Sprint回顧

整體來講，我認爲Sprint回顧很是重要，之因此這麼說是由於：

1. 一個敏捷團隊爲世界上最重要的故事（story）專心工做了一段時間，並準備交付與之相關的功能或故事。單從這點上看，回顧就足夠重要，人們的目光都彙集在這裏，你們渴望見到成果，因此你必須知足你的「觀衆」。
2. 團隊有義務展現他們的工做成果，但這不僅僅停留在代碼演示，團隊應該站出來說述圍繞他們的工做所發生的故事。這能夠是圖文並茂的，伴有情節的，並且這必須與上一次的Sprint回顧有聯繫，並對下一次的Sprint回顧作出鋪墊。

接下去我將爲你們分享Sprint回顧的7個最重要的方面以及一個簡單的回顧會議日程。我但願這些建議能幫助你們改進你的Sprint回顧，能更有效地拉攏你的利益相關者，並更全面、更充滿激情地展現你的團隊。

Sprint回顧的7招絕殺

1. 職責
   在每次Sprint回顧中，咱們都會創建起一種產品負責人對此全權負責的理念。誠然，這是每一個團隊成員的事情，但在天天工做結束時，產品負責人會負責進行外部溝通、展現計劃中所交付的代碼，以及對收集到的反饋意見進行相應地調整。他們還負責把你們找來作回顧——若是與會者良莠不齊，人數稀少（小衆參與），他們就必須找到問題所在並作出相應改變，讓「合適的」人聚到會議室裏進行Sprint回顧（大衆站立式）。 我時常把產品負責人比做典禮的主持人——他們負責引導Sprint回顧的各個方面。固然他們不須要事事親歷親爲，但他們須要把握整體的回顧質量，考慮回顧的重點以及對回顧的成果負責。

2. 形式
   咱們對回顧的日程安排以及時間控制出了不少主意（若是你置身於多個Sprint團隊，那麼也能夠是多個Sprint的回顧）。你確定但願你的回顧具備固定的節奏（時間與間隔），在進行Spring內容回顧時，你也確定但願每一個團隊都聽從統一的流程（以後的章節將給出回顧會議日程安排的例子）。 在咱們的案例中，因爲咱們有多個Sprint，而且是同步的，咱們在同一天演示多支團隊的成果，所以咱們的回顧形式有一種跨團隊的平常安排，將3個小時的回顧會議合理地分配給每一個團隊。咱們不只對每一個團隊的回顧作出安排，更重要的是，咱們的首席產品負責人對每一個團隊的回顧流程進行統一的節奏掌控。

3. Sprint目標
   就我的而言，我更傾向於Sprint回顧主動地去契合團隊成員都認同的Sprint目標。我常常囑咐個人團隊，當他們在制定Sprint目標的時候，多想想如何撰寫他們須要發送的回顧邀請郵件。這個Sprint的故事就會契合Sprint目標，團隊成員也將採起相應的行動來達到Sprint目標。

   另外，你必須對團隊所要承諾的Sprint交付物100%的誠實，你必須告訴你們成功了或是失敗了。但千萬不要讓「失敗」這個詞把你們都嚇壞了，失敗乃成功之母，它是團隊自我學習的一部分，也是整個組織保持一種「向失敗學習，不被其戰勝」的積極態度的重要組成部分。

4. 人人蔘與
   正如我所說，我崇尚把產品負責人看成整個典禮的主持人，那麼Scrum Master則是協調者（若是須要的話），而整個團隊纔是真正的大明星。給予你的團隊成員一個表現本身的機會，讓他們站出來展現他們的成果。人人蔘與的方式，將給予你的團隊足夠的表現空間——讓團隊成員輪流地去作代碼演示，這樣一來，每一個人都有機會爲你們演示本身的勞動成果。

   但必須記住，不要強迫性格內向的成員去作大範圍的演講，你能夠鼓勵每一個團隊成員去表現，但這必須不是強制性的。一般，性格內向的成員能夠成爲演示的參與者，他們是很好的聆聽者，安靜地參與回顧。可是，你必需要鼓勵團隊的每一個成員積極參與回顧。

5. 準備 若是說什麼是成功的Sprint回顧祕訣，那就是以前的準備工做了——別放太多的內容，也別過於簡單了，把握好這個度。你必須去思考，什麼內容是和此次Sprint回顧相關的；回顧應該以怎樣的流程進行下去；你還要去想，此次回顧如何與前一次，後一次的回顧相互呼應。

   一般，有着質量保障（Quality Assurance）背景的人會提早寫一個回顧的「腳本」，幫助本身更緊湊地揭示工做成果。但最終，產品負責人才是決定回顧哪些內容，以及爲何作這些回顧一槌定音的人，他爲利益相關者搭建好回顧的「舞臺」。

   若是有疑問，在Sprint計劃階段就給回顧的準備留出足夠的時間，並認真地去作準備。

6. 執行與演示 你須要保證整個回顧演示必須是順暢的、有思想的、精心商榷的，而且最終的軟件是能夠無差錯地工做。你須要執行試運行（Dry-running）演示，並確保全部代碼環境都事先調試經過。你還必須計算好演示的時間，保證不會超過預留給你的時間，同時也不要忘記提問部分。

   除了演示，你最好能描述一下你所開發的功能特性或工做流。我曾見過一些團隊在他們的第一次Sprint回顧中就給出了他們在將來6次Sprint所規劃的工做的架構圖。在此後的每一次Sprint回顧，他們只需作作簡單的「填空遊戲」就能把他們的應用程序架構附上「皮肉」（意指代碼實現）。我以爲這是一種很是好的方法，可以幫助回顧會議的聽衆涉點及面。

   在我看來，團隊在一個Sprint中涉及的全部工做均可以在Sprint回顧中被展現，這包括：功能特性、功能改進、Bug修復、重構、文檔、測試架構等等，任何工做均可以放進來。固然有些東西可能要等到必定的程度才能拿得出，但只要是團隊作的，均可以成爲回顧的內容之一。

   最後，考慮好如何描述清楚你的演示，讓你的聽衆可以理解你所演示的內容，內容的關鍵部分，以及團隊在這些內容背後的辛苦付出。

7. 總結 最後，咱們老是對兩個方面進行回顧總結——軟件自己的反饋意見以及回顧會議的反饋意見。例如：這個過分是否平穩？全部人都明白咱們作的東西了嗎？你清楚如何向咱們提供反饋意見了嗎？下一次回顧有什麼地方須要改進嗎？咱們一般都會在這個階段花上幾分鐘，但這幾分鐘絕對超值！若是你對舉手表決（Fist-of-Five）的理念比較熟悉的話，咱們一般使用這個方法來結束反饋過程。

回顧會議日程安排舉例

你能夠考慮將如下做爲你的團隊Sprint回顧會議日程安排的模板：

1. 介紹

2. 組織架構

   • 團隊成員角色：名字、角色、工做地點等
   • 對Sprint提供幫助的外部成員

3. 工做承認——感謝

   • 這個絕對是團隊成員的出彩時間
   • 這也是對Sprint提供幫助的外部成員的工做進行承認的好時機

4. Sprint目標

   • 闡明Sprint目標，以及有何調整
   • 宣佈Sprint是否成功，團隊成員是否兌現承諾

5. 戰略目標、成功定義、工做量、新發現、成果

   • 分享團隊交付的代碼所考慮到的總體戰略目標
   • 圍繞Sprint幕後的工做量
   • 是否有考慮不周全的地方；關鍵的成果
   • 全部這些都爲回顧會議的聽衆提供了一個瞭解團隊Sprint幕後故事的機會

6. 演示、提問時間

   • 演示所選擇的用戶故事集以及功能特徵——接受提問

7. 將來議項

   • 宣佈現行目標的進程以及將來Sprint所涉及的工做

8. 回顧改進意見的舉手表決（Fist-of-Five）

   • 鼓勵回顧會議的聽衆對團隊的表現進行反饋
9. 結束

總結

我沒法用語言表達一次高質量的Sprint回顧將帶給你何種感覺，這須要你親身去感覺。儘管產品負責人及團隊很大程度地左右着回顧成果，但做爲敏捷項目的項目經理，你一樣扮演着相當重要的角色。 一般，團隊成員在努力工做時被抓出來，倉促地準備Sprint回顧。事實上，這麼作是典型的反例。你必須在Sprint計劃時就囑咐團隊留出相應的時間給Sprint回顧，而且在Sprint即將完成的時候，善意地提醒他們，作好Sprint回顧的準備工做。

請記住，這個回顧會議也是團隊能力的一個「質量檢查點（QA Checkpoint）」。將各項工做放在一塊兒並演示出來，無疑是提升團隊Sprint能力的最佳途徑了。你每每會發現——環境沒有準備好、整合沒有作好或者交互沒有實現等等諸如此類的麻煩事。

所以，各位敏捷項目的項目經理們，我但願這篇文章可以影響大家，使大家發生轉變，把Sprint回顧作成敏捷實現中最有利的一種手段，真正擔當起Sprint回顧的重任。雖然團隊纔是作準備及完成交付的人，但你的任務是去影響他們進行回顧的態度與方式。隨着項目的進行而不斷的進步，你能夠將你能得到的正向反饋無限放大，幫助你的團隊更好地完成敏捷項目。