這是《落葉》文集里第?189?片落葉扁耐，希望你能喜歡，不為別的产阱，只為這份堅持婉称。
【背景】
這幾天從什么是敏捷，聊到了為什么要引入敏捷构蹬，又聲明了敏捷并不是萬能的王暗，在這個過程中給不少同學產(chǎn)生了一種困難重重感，所以有人就在問我怎燥，敏捷落地是不是真的很難瘫筐？
【你問】
敏捷落地是不是真的很難？
【我答】
今天我依然還是說說自己在敏捷實施落地過程中感受到的那些痛吧铐姚，看看是否能給不同的同學帶去不一樣的感同身受策肝。
第一步：全員培訓
1、面向管理層隐绵、未來的PO和SM的敏捷實施培訓之众；
2、面向公司所有員工的敏捷思想和基本概念的培訓依许；
【問題1】：實施過程中棺禾，每個 PO 和 SM 都按照自己的理解去貫輸敏捷流程，并指導團隊如何去執(zhí)行峭跳，導致同一類型的項目膘婶，不同的 Scrum Team 卻有著不同的流程。
【分析1】：先嚴格按照 Scrum 標準流程去執(zhí)行蛀醉，讓團隊通過實踐悬襟，理解并熟悉了 Scrum 流程和方法之后，再結(jié)合原有的流程進行融合改造拯刁。同時脊岳，讓各個 Scrum 團隊的 PO 和 SM 定期開展 Lean Coffee 活動去交流分享各自的經(jīng)驗心得。
第二步：在新產(chǎn)品的研發(fā)過程中要求使用 Scrum
【問題2】：產(chǎn)品雖然是新的垛玻，但是團隊成員都是從老的項目組抽調(diào)出來的割捅，所以大家不論是思想，還是骨子里帚桩，其實都還是傳統(tǒng)的瀑布式流程亿驾，而且在開工之前，并沒有人提供相關的模板或工具账嚎，導致團隊成員無從下手颊乘，最后只能又做成每個 Sprint 里包著一個個小瀑布参淹。
【分析2】：PO 和 SM 通過理論結(jié)合實際，預先定義一些算法乏悄、公式和模板浙值，包括但不限于：用戶故事的顆粒度、故事點大小的估算檩小、Team Capacity 的算法开呐、相關會議流程和注意事項等等。在前幾個 Sprint Planning Meeting 和 Retrospective Meeting 時做持續(xù)性的宣貫和討論规求。
【問題3】：公司的產(chǎn)品團隊在美國筐付，因為時差和地域的差異，和本地團隊的工作節(jié)奏很難同步阻肿，是否能由開發(fā)團隊的開發(fā)人員或測試人員兼任瓦戚？
【分析3】：我們通過在本地設立了 PPO （Proxy Product Owner，產(chǎn)品負責人代理）的角色來解決這個問題丛塌，他們相當于 US PO 在本地的角色投影较解，他們從 US PO 那兒獲取產(chǎn)品的需求和相關信息，和本地的 Scrum Team 緊密地工作在一起赴邻。
【問題4】：有些團隊成員在學習敏捷時印衔，以為敏捷是輕文檔的，就簡單地認為文檔就可以能省則省姥敛，甚至包括 SPEC 和 Test Plan 等奸焙。
【分析4】：很多敏捷的團隊在初期階段都有這樣的誤解，敏捷思想是說有價值且可工作的軟件勝于詳盡的文檔彤敛，但是必要的需求文檔与帆、設計文檔、測試計劃墨榄、測試用例等等玄糟，在產(chǎn)品的項目實施過程中，都是需要的渠概，否則無法做到好的知識積累和傳承。
敏捷里只是不需要像傳統(tǒng)瀑布流程一樣嫂拴，把文檔作為每個階段的一個輸入條件播揪，比如說 PRD 是開發(fā)設計階段的輸入，開發(fā)的 SPEC 是測試用例設計階段的輸入等等筒狠。在敏捷里猪狈，文檔應該就是一個輸出產(chǎn)物，產(chǎn)品經(jīng)理辩恼、開發(fā)雇庙、測試在完成一個 Sprint 任務的同時谓形，協(xié)同產(chǎn)出的有價值，并持續(xù)更新的一些知識和資料疆前。
第三步：在本身就是一個月發(fā)布一次的項目中推行寒跳。
【問題5】：項目組成員在最初推行 Scrum 時會有較大困惑，因為本身已經(jīng)是一個月發(fā)布一個版本了竹椒，為什么還要轉(zhuǎn)為敏捷模式童太，而且迭代周期也是一個月，那又有什么區(qū)別呢胸完？
【分析5】：PO 和 SM 引導團隊從幾個方面去感受傳統(tǒng)的瀑布式流程和敏捷流程的區(qū)別：對需求理解的一致性书释、對代碼改動的回歸測試范圍的確定性、對項目整體進度和自身能力的可視化等等赊窥，雖然從項目周期上看沒有區(qū)別爆惧，但是從開發(fā)到測試對質(zhì)量的信心和減少需求實現(xiàn)偏差上都有了很大的提高和改進。
第四步：在公司所有項目中開始運行锨能。
【問題6】：管理層認為敏捷團隊是一個自組織扯再、自管理的團隊，所以可以是鐵打的營盤流水的兵腹侣，因此會隨意調(diào)動人員去應對一些 EP叔收，或者喜歡每個項目開始之前打散原有團隊重新自由組合。
【分析6】：SM 需要通過對執(zhí)行過程中的問題分析和燃盡圖的對比傲隶，讓管理層明白饺律，一個團隊的合作熟練度是需要時間去磨合的，當團隊成員之間的默契度達到一個較高指數(shù)時跺株，戰(zhàn)斗力將會呈幾何級的增長复濒，任何任務都可以很好的完成。所以乒省，我一直認為 Scrum Team 應該是鐵打的兵團巧颈，流水的營盤。另外袖扛，團隊在做 Sprint Plan 時砸泛，應該要預留10%~20%的 Buffer，來應對 EP和一些臨時任務蛆封。
【問題7】：在引入 Scrum 的初期唇礁，因為美國的 Release Manager 和 Cloud Service 團隊并沒有同步地跟上轉(zhuǎn)型的節(jié)奏，他們?nèi)匀话凑掌俨寄Ｐ屠?CC惨篱，CF盏筐，ER 等幾個 milestone 去跟本地團隊討論發(fā)布和部署計劃，讓本地團隊覺得同時在兩種流程標準下做項目很痛苦砸讳。
【分析7】：PO 和 SM 在跟 team 做 Sprint Plan 的時候琢融，會把團隊承接的有代碼改動的 User Story 工作量控制在 CF 能完成界牡，CF 到 ER 之間主要承接的是版本的回歸測試、升降級測試漾抬、發(fā)布文檔的編寫等 User Story宿亡，同時 SM 也會盡可能地去跟 RM 和 CS 統(tǒng)一溝通，保護團隊不受太多的干擾奋蔚。
【問題8】：在前期引入 Rally（適用于 Scrum 的一種管理工具）她混，增加了團隊額外的一些工作量，從表面上看泊碑，工作效率反而下降了坤按，從而產(chǎn)生了一些抵觸情緒。
【分析8】：SM 在跟團隊做 Sprint Plan 的時候就把工具的學習量也算在內(nèi)馒过，并跟管理層和團隊做好溝通臭脓，敏捷團隊的 Capacity 算法里要加上學習量的計算，因為團隊是在不斷總結(jié)腹忽、不斷學習中成長的来累，不管是工具，還是新的項目窘奏，新的技術領域嘹锁，都需要花時間去學習，這些都需要在每個 Sprint 開始做計劃的時候考慮進去着裹。
【問題9】：有的團隊覺得過多的會議耗費了他們的精力领猾，而且一個 Sprint 結(jié)束之后就要立即投入下一個 Sprint 的工作當中了，所以取消了項目結(jié)束之后的反思會議骇扇，還自以為對流程效率做了優(yōu)化摔竿。
【分析9】：SM 通過對幾個 Sprint 的 Capacity 數(shù)據(jù)進行統(tǒng)計對比，讓團隊認識到這個值已經(jīng)連續(xù)幾個 Sprint 沒有變化了少孝，再引入一些成功案例做對比继低，在團隊里做幾次分享和頭腦風暴，并采用各種方法引導團隊成員慢慢說出自己眼中的不足稍走，持續(xù)總結(jié)袁翁，持續(xù)改進，讓團隊切身體會到這種反思會議正是敏捷中持續(xù)改進的重要基石婿脸，那么團隊自然就不會覺得開 Retrospective Meeting 是在浪費時間了粱胜，另外，就是這種會一定要切記盖淡，不能開成抱怨大會或者批斗大會年柠。
《測試路上你問我答》里的Q&A47凿歼，如果是你要的褪迟，甚好冗恨！如果不是，你問味赃，我答掀抹！
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
