敏捷開發，你真的做對了嗎？阿里文娛廣告團隊敏捷實踐總結

很多人對敏捷開發有個普遍的誤解，認為敏捷就是快，經常在需求沒定義清楚的情況下就急于開工。事實上，這樣做往往得不償失。今天，我們邀請阿里巴巴敏捷教練問菊，為我們帶來阿里文娛廣告團隊敏捷實踐，看看他們是如何做敏捷開發的。

緣起

2017 年 3 月，應移動事業群智能營銷平臺項目管理部負責人邀請，我開始支持智能營銷平臺 CRM 團隊。智能營銷平臺是阿里文娛廣告團隊，是阿里巴巴淘外變現的主力軍。CRM 團隊負責開發和維護 CRM 系統。CRM 系統服務于銷售和代理商，串起商機管理、客戶開發、合同管理、風控審核、賬戶管理、財務結算等業務鏈條。CRM 系統的質量和交付速度，直接影響銷售和代理商服務廣告主的效率和體驗。

3 月初我訪談了銷售、產品、開發、測試等團隊核心成員，并觀察了團隊的周會、站會和需求討論會。當時團隊的目標是在 3 月 25 日交付框架合同功能，主要工作圍繞框架合同功能開展。根據訪談內容梳理出框架合同項目研發過程的時間線如下：

從圖中可以看出，這個項目基本按照瀑布模式推進，開發 2 個月后整體提測，測試 1 個月后一次性發布。開發 2 個多月后，業務方才有機會試用產品并給出反饋。

這個項目暴露了瀑布模式的弊端：

1. 接力棒的協作模式帶來信息差

 

瀑布模式下，業務、產品、研發三方很少共同參與討論。需求如同接力棒從業務方傳遞給產品經理，再從產品經理傳遞給研發團隊。信息每經過一次傳遞都有損失，業務方、研發團隊得到的大部分是二手信息；產品經理成為團隊溝通的瓶頸，業務方和研發團隊直接討論可以解決的問題，要經過兩輪甚至多輪溝通才能達成共識；業務方和研發團隊缺乏相互理解，研發團隊不了解需求背后真正的業務訴求，業務方不了解技術方案背后的權衡。

2. 難以響應變化

瀑布模式下，所有的需求分析和設計工作在開發前完成，并假設需求不會改變，研發過程只需遵循最初的項目計劃和范圍。實際項目中，變化在所難免。 即使再多花一倍的時間評審需求和制定項目計劃，也無法預見所有的變化。事實也正如此，框架合同項目中業務方組織結構調整，客戶 URL 與銷售的映射關系發生變化，原有的設計無法兼容這種變化，已實現的功能需要重新設計。正如何勉老師在《精益產品開發》所說：“希望一開始就能設定完整和正確的需求，這對軟件產品越來越不可能，因為用戶也不知道或說不清楚自己想要什么。事實上，對需求的發掘和理解，應該是一個持續的過程，需要不斷地反饋。”

3. 很遲才得到用戶反饋

瀑布模式下，所有的產出在項目末期交付，項目的風險也累計到最后，項目過程中沒有機會驗證假設和得到真實反饋。框架合同項目中，業務方在 3 月初才第一次試用產品，此時距離發布時間不到兩周，反饋的大部分問題在發布前來不及修改。3 月底發布后，產品功能持續迭代了數月，才達到業務方的期待。

CRM 團隊深受其痛，團隊的訴求主要有：

1. 業務、產品、研發密切協作，作為一個團隊為共同的目標努力。

2. 縮短需求交付時長，貼合業務需要完善 CRM 系統。

改進方案和落地實施

結合團隊的訴求和 CRM 團隊的實際情況，與智能營銷平臺業務、產品、研發、項目管理負責人溝通后，確定了改進方案。改進方案聚焦于兩點：

1. 組建 One Team，促進跨部門協作

One Team 由業務、產品、研發核心成員組成，后來又加入了負責產品落地的運營同學。

One Team 負責制定季度產品規劃。以往各職能部門分頭組織季度規劃，業務、產品、研發的目標可能有偏差，執行過程中容易對需求優先級產生分歧。One Team 成立后，成員共同制定季度規劃。目標對齊后，團隊的工作圍繞季度規劃展開，對需求優先級容易達成共識。看一下 CRM KA 的例子：

產品路線圖

2018 財年 Q1 的季度規劃執行情況

One Team 召開雙周會，會議有 3 個固定議題：

• 回顧上個迭代已發布功能的用戶反饋；

• 同步當前迭代的進展；

• 梳理下個迭代的核心需求。

通過 One Team 雙周會，串起了需求反饋環。大家不再局限于部門和角色分工，快速同步信息，迅速解決問題。以前用戶反饋的問題在部門間層層流轉可能幾個月才解決，現在雙周會上大家商量一下方案立即排期解決。

2. 向迭代模式轉型，縮短需求交付時長

One Team 成員商議后，在月迭代和雙周迭代之間選擇了更有挑戰的雙周迭代。

從瀑布模式向迭代模式轉型有兩個關鍵的實踐：拆分需求和建立節奏。

拆分需求是小步迭代的前提，對于剛剛轉型到雙周迭代的團隊，我們沒有一刀切。進入研發環節前，需求最好拆分到 1 周內可以提測的粒度，以便在一個迭代內發布。如果需求確實難以拆分，也可以跨迭代交付。同時我們會關注需求的開發時長，以此衡量需求的粒度。期待隨著實踐的深入，越來越多的需求可以在一個迭代內發布。

需求拆分采用用戶故事地圖方法：對于一個復雜的大需求，按照用戶在特定場景下要解決的問題切分出用戶旅程，每次發布盡量交付一個完整的用戶旅程。一般會按照從簡單到復雜的順序，先實現 MVP（Minimum Viable Product），交付一個最簡單的用戶旅程。在此基礎上不斷豐富和完善，逐步實現附加功能和定制功能。以下是一個需求拆分的實例，其中“普遍品專詢價”和“普通品專合同”組成了一個 MVP。

對敏捷開發有個普遍的誤解，敏捷就是快，需求沒定義清楚就急于開工。事實上，這么做往往得不償失。正如 Marco Behler 所說：程序員的生產力始于“恰當的需求”。

為了減少研發過程的返工和浪費，需求進入研發前要符合準入標準 DoR（Definition of Ready），發布前要符合準出標準 DoD（Definition of Done)。需求發布后，產品經理會觀測埋點數據，業務和運營會搜集用戶反饋。One Team 會上大家根據用戶反饋決定下一步的改進和優化。

迭代活動有節奏地進行，迭代才能有序運轉。One Team 成員商議后，一致同意嘗試如下的節奏：

從圖中可以看出，本迭代的開發測試與下迭代的需求分析并發進行，這樣可以最大限度地減少研發環節的等待。代價是部分開發和測試同學要投入一些精力梳理下個迭代的需求，例如評估技術可行性、澄清驗收標準。大部分的需求梳理工作在 One Team 雙周會上進行，如果雙周會上發現一些待確認的問題，會記錄下來并由專人負責跟進。

迭代第一天，研發團隊按照優先級把符合準入標準的需求拉入迭代，做初步的設計和估算。根據估算做出嚴肅的承諾，并制定研發計劃：

從圖中可以看出，為了降低風險和分散壓力，團隊盡量做到小批量逐步提測。提測前測試同學會設計好測試用例，提測時開發同學要跑通 P0、P1 測試用例。測試同學驗證基本功能可用，立即邀請產品經理和業務同學試用，以便盡快發現體驗問題。功能發布前，業務方驗收即將發布的版本，業務驗收通過后才可以發布。

在確定節奏的同時，我們對迭代活動的產出、責任人、截止日期做了明確約定。大家分工協作，迭代很快有序運轉起來：

為了增加透明性，我們用工作流描述需求狀態的流轉：

用看板跟蹤需求的狀態：

效果評估

1. One Team 機制促進跨部門協作

業務、產品、研發之間曾經相互埋怨，業務覺得交付的功能不是最需要的，急需的功能反而沒給做，研發覺得辛苦做出來的功能沒人用非常冤，產品夾在中間兩頭受氣。

One Team 機制落地后，大家綜合權衡業務價值、技術風險、人員情況、外部依賴、投入產出比等相關因素，一起決定需求優先級。即便最初大家的意見不一致，通過開誠布公的討論，對最后的結論也能夠認可，并積極推進執行。CRM SME 雙周會上，產品經理預先準備了一些產品優化需求。業務方提出目前更需要看到數據報表。大家迅速達成共識，數據報表是最高優先級，產品優化需求靠后。

CRM 產品團隊季度總結時，CRM KA 的產品經理和業務接口人表示：One Team 機制建立以來，跑通了業務需求從提出到上線后反饋的大閉環，業務、產品、研發有序協作，接下來會把這個機制順利地運轉下去。

CRM SME 的業務接口人在郵件中提到：“目前中小 CRM 的產品工作在正常有序推進，項目進行的同時，也在積極進行存量需求的消化”，并感謝團隊付出的努力。

智能營銷平臺的技術負責人高度評價 One Team 機制：“不僅提升了團隊的開發效率，也提升了團隊的溝通效率”。

One Team 成員在持續的協作中，增進了信任和了解，研發更了解業務，業務也更體諒研發。以下是兩個具體的例子：

2. 雙周迭代縮短需求交付時長

CRM 團隊的所有需求都在 Aone 中跟蹤，團隊在站會上更新需求狀態，根據需求狀態流轉生成的統計圖表能夠反映真實情況。

雙周迭代的首要目標是縮短需求交付時長。結合這個目標，我們主要關注 2 個指標：開發時長和從開發到發布的交付時長。需求拆分得越小，開發時長越短，越適合迭代開發。交付時長越短，研發團隊的適應性越好。業務需要時，團隊能夠迅速實現需求并交付到用戶手里。

CRM KA 團隊從 6 月中開始嘗試雙周迭代，開發時長和交付時長的周移動平均值如下：

從圖中可以看出，開發時長從 12 天縮短到 6 天以下，說明需求拆分得更小了。交付時長基本都在 20 天以內，唯一的例外是 7 月 31 日至 8 月 6 日一周。原因是這部分功能要跟關聯方同步上線，CRM KA 團隊完成了開發測試后，等待兩周才與關聯方聯調上線。

值得一提的是，在向雙周迭代轉型的過程中，CRM 團隊保持了很高的質量水準，無論是提測質量、線上質量還是缺陷修復速度，都達到了集團領先水平。

更短的交付時長、更頻密地交付功能，有利于快速驗證假設、交付價值、響應變化。以業務方急需的數據報表為例，CRM 團隊把 55 個業務指標按照優先級分批交付，確保每兩周都交付一些報表，縮短了業務方的等待時間，貼合業務方的反饋快速調整和優化，贏得了業務方的高度肯定。

應對挑戰

在人力有限的情況下，如何以最快的速度、最低的成本迅速滿足業務發展的需要，是 CRM 團隊在未來一段時間內面臨的最大挑戰。One Team 和雙周迭代的實踐為團隊通力協作、小步快跑、持續改進奠定了基礎，未來繼續深化敏捷實踐能夠獲得更大的收益。

1. 聚焦于持續快速交付業務價值

相比于交付更多功能，我們更應關注為業務帶來了多大價值。從眾多的需求中，如何發掘提煉出業務價值最高的需求？在多種解決方案中，如何找到最佳迭代路線優先解決業務痛點？把 80/20 原則發揮到極致，我們就有機會以小博大，為業務發展贏得更多機遇。要做到這一點，需要我們善于取舍，相比于決定做什么，更重要的是決定不做什么。相比于一次性交付一個大而全的解決方案，更合理的是先實現一個小而輕的方案滿足核心用戶的核心訴求，迅速交付給用戶使用，基于真實的用戶反饋迭代優化。

2. 用技術手段提高生產率

相比于項目結束時一次性發布，每兩周都發布的確會帶來額外的發布成本，例如回歸測試的成本、部署上線的成本。為了獲得雙周迭代帶來的靈活性，我們要想辦法不斷降低發布成本，直至發布變得如此容易以至于我們完全可以忽略發布成本。這正是持續集成、持續部署等敏捷工程實踐解決的問題。

持續部署流水線能夠實現從代碼提交到單元測試、靜態掃描、編譯、打包、部署、測試、發布全流程的自動化。把一切重復的工作交給機器，解放工程師去做更有創造性的工作，是提升效率的根本之道。CRM 測試團隊已經實現部分自動化測試，也有自動編譯打包的 Jenkins job，再努力一步完全可以實現持續集成、甚至持續部署。智能營銷平臺測試團隊已經在朝著這個方向努力，這是非常有價值的工作。如果研發同學也加入進來，大家齊心協力，相信很快就有成果。

總結

通過 One Team 機制，業務、產品、研發間增進了信任和了解，彼此協作更順暢。

通過拆分需求和有節奏的短迭代，CRM 團隊從瀑布開發模式比較順利地轉型到了迭代開發模式。發布頻率從數月一次變為兩周數次，基本做到 6 天以內提測，20 天以內發布。更可喜的是，在轉型過程中，團隊保持了高質量。

研發團隊持續快速交付業務急需的功能，得到了業務團隊的高度認可。

來自: mp.weixin.qq.com