《測試路上你問我答》怎麼才能讓敏捷軟著陸？

【背景】

今天來和大家聊聊怎麼才能讓敏捷軟著陸，它和其他規範或者工具引入還不太一樣，因為它包含了一整套研發體系流程，而且現在要引入敏捷的公司大多都是想從瀑布轉型的，這可是一套根深蒂固的傳統流程，所以如果硬著陸的話，很容易折翼。

【你問】

怎麼才能讓敏捷軟著陸？

【我答】

我也不敢說我今天聊得軟著陸成功率就是百分之一百，但至少這是我在實際的敏捷實施過程中，不斷總結和反思得出的一些經驗，有接地氣的，也有偏個人理想化的。

1、問題驅動：

我之前說過，敏捷並不是萬能的，所以不要只聽到別人家的公司說用了敏捷之後，效率提高了百分之多少，成本降低了百分之幾等等，就盲目的去追趕這股「敏捷風」。

還是應該由問題驅動，先收集當前的研發模式有哪些問題，分析一下，到底是人的問題、技術的問題、還是流程的問題，如果真的是流程問題，那就再看，是需要全盤替換，還是僅僅吸取敏捷里的若干特色工具或方法即可。

這裡舉一個真實的案例，曾經有一個項目組，想全面實施 Scrum 研發流程，所以找到我去給他們做了一次分享，分享結束後，我跟項目組的人溝通了一下他們想採用敏捷的初衷和當前到底有哪些問題，最後發現其實根本原因是因為項目組的規模比原來大了一些，導致項目經理對項目進度的把控和組內溝通上出了問題。所以我給了他們兩套方案：

方案A：引入 Scrum 的全套流程，前期可能需要消耗不少時間在學習和磨合上，所以同期的產出肯定會下降。

方案B：針對目前的問題，只引入 Scrum 里的「任務牆」和「Daily Scrum Meeting」，讓整個項目的進度變得直觀透明，同時讓溝通更及時快捷，其他流程保持不動，這種對於項目組成員來說，學習成本最低，基本不會影響產出量。

項目經理最終選擇了我推薦的方案B，而且在實施了一段時間後，反饋的確已經解決了他們的實際問題。所以說，敏捷的引入一定要切合實際要解決什麼問題，而不要為了敏捷而敏捷。

2、自上而下的推動：

敏捷的引入及推行，一定是要自上而下的。什麼意思呢？就是說，公司高層首先要從思想上認可敏捷，同時要給予最大限度地支持。這樣敏捷在落地的過程中，會少去很多障礙。千萬不能是自下而上地去推行敏捷，那樣基本上很難成功。

同樣舉個實際的例子，我們的 SM 和 Team 開了一整天的 Planning Meeting，制訂了團隊都認可的 Sprint Plan，大家正準備按照這個計劃開工的時候，職能經理跑過來質問團隊，哪天代碼完成提交測試啊？哪天代碼凍結啊？哪天提交運維發布啊？怎麼你們的計劃里都看不到這些里程碑了呢？

SM 跟他說，現在都拆分到 User Story 顆粒度了，每個 Sprint 結束的東西都可以發布上線的，結果職能經理來了一句，我不管你什麼顆粒度，也不管什麼 Sprint，我只想看到那幾個主要的里程碑，最終上線不會 Delay，就 OK 了。

結果，SM 又熬了一晚，從 Sprint Plan 里又提煉出來幾個主要的里程碑，按線性的模式列給了職能經理。最後，大家做計劃時，又回歸老的模式了。

3、專職的 Scrum Master：

很多公司在實施敏捷的時候，對於 Scrum Master 這個角色總是不夠重視，特別是那種內部研發類的項目，因為之前就沒有專門的項目經理角色，所以在轉敏捷時，也經常會讓開發組長或測試組長兼任。但從實踐角度出發，我個人一直都強烈建議這個角色要專人專職，特別是在初期。

在前期整個團隊開始採用敏捷時，SM 起到了很重要的教練的作用，他需要花很大的精力和時間在學習、指導、總結、分析和改進等工作上，還有相關會議的組織、項目數據的統計、項目問題的跟蹤、進度的彙報等等常規工作。如果不是一個專職的人去做，勢必會影響到他本職的工作，也會消耗他很多在教練這個角色上的精力，導致兩個角色都沒有做的很好。

另外，如果由某個角色的人去兼任，那他不管是在做教練還是保鏢時，不可避免地會下意識地站在自己的本職角色去考慮和看待問題。在做一些決策和判斷時，就會帶有偏向性。

4、核心成員，以老帶新：

敏捷團隊，強調的是自組織，自管理，對每個人的要求都相對較高，但從實際角度出發，不可能每個 Scrum Team 的人員配比都是高階人力，所以只能建議在初期組建時，至少保證每個角色都配備一名高階人力，再按實際需求配備中低階人力，以老帶新，通過若干個迭代的打磨和成長，讓整個團隊都能達到自組織和自管理的「理想」狀態；

5、從「循規蹈矩」到「因地制宜」：

很多 Scrum 團隊在剛開始的時候，就對本身標準的流程、方法和工具做優化和改進，我一直在問他們，你們所謂的「優化」和「改進」是基於什麼的呢？我聽到的最多的回答都是：」我們原來的流程就是這麼玩的呀！「 那你們就按你們原來的玩法玩唄，為什麼要用敏捷呢？

這些團隊最終的成果就是打造出了 N 個不同摸樣的，奇形怪狀的，似是而非的研發流程，不僅僅效率沒得到提升，團隊成員在執行起來，也是蹩手蹩腳的。

所以，我一直建議的實施步驟如下：

初始階段：在我們剛剛起步，什麼都不懂的學習階段，就讓我們嚴格按照 Scrum 教科書，採用標準的方法、流程和工具，打好理論基礎，學以致用，通過幾個迭代的」生搬硬套「，真正理解並掌握 Scrum 的精髓。

優化階段：有了幾個迭代的真實數據和經驗，我們可以開始嘗試對 Scrum 流程中做的不好的地方進行總結分析和反思，看到底是流程水土不服的問題，還是我們自身的問題，再針對性地進行優化。

推廣階段：我們已經形成了團隊自己的一套模式，而且是通過實踐證明，且整個團隊都認可的，這個時候，我們就可以開始結合公司實際的項目環境，總結流程，將其固化下來，作為「本地化」的 Scrum+ 流程，開始向其他項目組推廣運行。

自此，敏捷研發流程才算是真正地軟著陸了，不過不要忘記 Scrum 里的核心理念：持續改進！

《測試路上你問我答》里的 Q&A 48，如果是你要的，甚好！如果不是，你問，我答！

作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！