[轉載]敏捷開發，你真的作對了嗎？

緣起

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天之內發佈。更可喜的是，在轉型過程當中，團隊保持了高質量。

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

轉自：《敏捷開發，你真的作對了嗎？阿里文娛廣告團隊敏捷實踐總結》