這是《落葉》文集里第?189?片落葉，希望你能喜歡，不為別的，只為這份堅持。
【背景】
這幾天從什么是敏捷，聊到了為什么要引入敏捷，又聲明了敏捷并不是萬能的，在這個過程中給不少同學產生了一種困難重重感，所以有人就在問我，敏捷落地是不是真的很難？
【你問】
敏捷落地是不是真的很難？
【我答】
今天我依然還是說說自己在敏捷實施落地過程中感受到的那些痛吧，看看是否能給不同的同學帶去不一樣的感同身受。
第一步：全員培訓
1、面向管理層、未來的PO和SM的敏捷實施培訓；
2、面向公司所有員工的敏捷思想和基本概念的培訓；
【問題1】：實施過程中，每個 PO 和 SM 都按照自己的理解去貫輸敏捷流程，并指導團隊如何去執行，導致同一類型的項目，不同的 Scrum Team 卻有著不同的流程。
【分析1】：先嚴格按照 Scrum 標準流程去執行，讓團隊通過實踐，理解并熟悉了 Scrum 流程和方法之后，再結合原有的流程進行融合改造。同時，讓各個 Scrum 團隊的 PO 和 SM 定期開展 Lean Coffee 活動去交流分享各自的經驗心得。
第二步：在新產品的研發過程中要求使用 Scrum
【問題2】：產品雖然是新的，但是團隊成員都是從老的項目組抽調出來的，所以大家不論是思想，還是骨子里，其實都還是傳統的瀑布式流程，而且在開工之前，并沒有人提供相關的模板或工具，導致團隊成員無從下手，最后只能又做成每個 Sprint 里包著一個個小瀑布。
【分析2】：PO 和 SM 通過理論結合實際，預先定義一些算法、公式和模板，包括但不限于：用戶故事的顆粒度、故事點大小的估算、Team Capacity 的算法、相關會議流程和注意事項等等。在前幾個 Sprint Planning Meeting 和 Retrospective Meeting 時做持續性的宣貫和討論。
【問題3】：公司的產品團隊在美國，因為時差和地域的差異，和本地團隊的工作節奏很難同步，是否能由開發團隊的開發人員或測試人員兼任？
【分析3】：我們通過在本地設立了 PPO （Proxy Product Owner，產品負責人代理）的角色來解決這個問題，他們相當于 US PO 在本地的角色投影，他們從 US PO 那兒獲取產品的需求和相關信息，和本地的 Scrum Team 緊密地工作在一起。
【問題4】：有些團隊成員在學習敏捷時，以為敏捷是輕文檔的，就簡單地認為文檔就可以能省則省，甚至包括 SPEC 和 Test Plan 等。
【分析4】：很多敏捷的團隊在初期階段都有這樣的誤解，敏捷思想是說有價值且可工作的軟件勝于詳盡的文檔，但是必要的需求文檔、設計文檔、測試計劃、測試用例等等，在產品的項目實施過程中，都是需要的，否則無法做到好的知識積累和傳承。
敏捷里只是不需要像傳統瀑布流程一樣，把文檔作為每個階段的一個輸入條件，比如說 PRD 是開發設計階段的輸入，開發的 SPEC 是測試用例設計階段的輸入等等。在敏捷里，文檔應該就是一個輸出產物，產品經理、開發、測試在完成一個 Sprint 任務的同時，協同產出的有價值，并持續更新的一些知識和資料。
第三步：在本身就是一個月發布一次的項目中推行。
【問題5】：項目組成員在最初推行 Scrum 時會有較大困惑，因為本身已經是一個月發布一個版本了，為什么還要轉為敏捷模式，而且迭代周期也是一個月，那又有什么區別呢？
【分析5】：PO 和 SM 引導團隊從幾個方面去感受傳統的瀑布式流程和敏捷流程的區別：對需求理解的一致性、對代碼改動的回歸測試范圍的確定性、對項目整體進度和自身能力的可視化等等，雖然從項目周期上看沒有區別，但是從開發到測試對質量的信心和減少需求實現偏差上都有了很大的提高和改進。
第四步：在公司所有項目中開始運行。
【問題6】：管理層認為敏捷團隊是一個自組織、自管理的團隊，所以可以是鐵打的營盤流水的兵，因此會隨意調動人員去應對一些 EP，或者喜歡每個項目開始之前打散原有團隊重新自由組合。
【分析6】：SM 需要通過對執行過程中的問題分析和燃盡圖的對比，讓管理層明白，一個團隊的合作熟練度是需要時間去磨合的，當團隊成員之間的默契度達到一個較高指數時，戰斗力將會呈幾何級的增長，任何任務都可以很好的完成。所以，我一直認為 Scrum Team 應該是鐵打的兵團，流水的營盤。另外，團隊在做 Sprint Plan 時，應該要預留10%~20%的 Buffer，來應對 EP和一些臨時任務。
【問題7】：在引入 Scrum 的初期，因為美國的 Release Manager 和 Cloud Service 團隊并沒有同步地跟上轉型的節奏，他們仍然按照瀑布模型里 CC，CF，ER 等幾個 milestone 去跟本地團隊討論發布和部署計劃，讓本地團隊覺得同時在兩種流程標準下做項目很痛苦。
【分析7】：PO 和 SM 在跟 team 做 Sprint Plan 的時候，會把團隊承接的有代碼改動的 User Story 工作量控制在 CF 能完成，CF 到 ER 之間主要承接的是版本的回歸測試、升降級測試、發布文檔的編寫等 User Story，同時 SM 也會盡可能地去跟 RM 和 CS 統一溝通，保護團隊不受太多的干擾。
【問題8】：在前期引入 Rally（適用于 Scrum 的一種管理工具），增加了團隊額外的一些工作量，從表面上看，工作效率反而下降了，從而產生了一些抵觸情緒。
【分析8】：SM 在跟團隊做 Sprint Plan 的時候就把工具的學習量也算在內，并跟管理層和團隊做好溝通，敏捷團隊的 Capacity 算法里要加上學習量的計算，因為團隊是在不斷總結、不斷學習中成長的，不管是工具，還是新的項目，新的技術領域，都需要花時間去學習，這些都需要在每個 Sprint 開始做計劃的時候考慮進去。
【問題9】：有的團隊覺得過多的會議耗費了他們的精力，而且一個 Sprint 結束之后就要立即投入下一個 Sprint 的工作當中了，所以取消了項目結束之后的反思會議，還自以為對流程效率做了優化。
【分析9】：SM 通過對幾個 Sprint 的 Capacity 數據進行統計對比，讓團隊認識到這個值已經連續幾個 Sprint 沒有變化了，再引入一些成功案例做對比，在團隊里做幾次分享和頭腦風暴，并采用各種方法引導團隊成員慢慢說出自己眼中的不足，持續總結，持續改進，讓團隊切身體會到這種反思會議正是敏捷中持續改進的重要基石，那么團隊自然就不會覺得開 Retrospective Meeting 是在浪費時間了，另外，就是這種會一定要切記，不能開成抱怨大會或者批斗大會。
《測試路上你問我答》里的Q&A47，如果是你要的，甚好！如果不是，你問，我答！
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
