緣起

2017年3月，應(yīng)移動事業(yè)群智能營銷平臺項目管理部負(fù)責(zé)人邀請，我開始支持智能營銷平臺CRM團(tuán)隊。智能營銷平臺是阿里文娛廣告團(tuán)隊，是阿里巴巴淘外變現(xiàn)的主力軍。CRM團(tuán)隊負(fù)責(zé)開發(fā)和維護(hù)CRM系統(tǒng)。CRM系統(tǒng)服務(wù)于銷售和代理商，串起商機(jī)管理、客戶開發(fā)、合同管理、風(fēng)控審核、賬戶管理、財務(wù)結(jié)算等業(yè)務(wù)鏈條。CRM系統(tǒng)的質(zhì)量和交付速度，直接影響銷售和代理商服務(wù)廣告主的效率和體驗。

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

從圖中可以看出，這個項目基本按照瀑布模式推進(jìn)，開發(fā)2個月后整體提測，測試1個月后一次性發(fā)布。開發(fā)2個多月后，業(yè)務(wù)方才有機(jī)會試用產(chǎn)品并給出反饋。

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

1.接力棒的協(xié)作模式帶來信息差

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

2.難以響應(yīng)變化

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

3.很遲才得到用戶反饋

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

CRM團(tuán)隊深受其痛，團(tuán)隊的訴求主要有：

1.業(yè)務(wù)、產(chǎn)品、研發(fā)密切協(xié)作，作為一個團(tuán)隊為共同的目標(biāo)努力。

2.縮短需求交付時長，貼合業(yè)務(wù)需要完善CRM系統(tǒng)。

改進(jìn)方案和落地實施

結(jié)合團(tuán)隊的訴求和CRM團(tuán)隊的實際情況，與智能營銷平臺業(yè)務(wù)、產(chǎn)品、研發(fā)、項目管理負(fù)責(zé)人溝通后，確定了改進(jìn)方案。改進(jìn)方案聚焦于兩點：

1. 組建One Team，促進(jìn)跨部門協(xié)作

One Team由業(yè)務(wù)、產(chǎn)品、研發(fā)核心成員組成，后來又加入了負(fù)責(zé)產(chǎn)品落地的運營同學(xué)。

One Team負(fù)責(zé)制定季度產(chǎn)品規(guī)劃。以往各職能部門分頭組織季度規(guī)劃，業(yè)務(wù)、產(chǎn)品、研發(fā)的目標(biāo)可能有偏差，執(zhí)行過程中容易對需求優(yōu)先級產(chǎn)生分歧。One Team成立后，成員共同制定季度規(guī)劃。目標(biāo)對齊后，團(tuán)隊的工作圍繞季度規(guī)劃展開，對需求優(yōu)先級容易達(dá)成共識。看一下CRM KA的例子：

?

產(chǎn)品路線圖

2018財年Q1的季度規(guī)劃執(zhí)行情況

?

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

• 回顧上個迭代已發(fā)布功能的用戶反饋；
• 同步當(dāng)前迭代的進(jìn)展；
• 梳理下個迭代的核心需求。

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

2. 向迭代模式轉(zhuǎn)型，縮短需求交付時長

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

從瀑布模式向迭代模式轉(zhuǎn)型有兩個關(guān)鍵的實踐：拆分需求和建立節(jié)奏。

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

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

對敏捷開發(fā)有個普遍的誤解，敏捷就是快，需求沒定義清楚就急于開工。事實上，這么做往往得不償失。正如Marco Behler所說：程序員的生產(chǎn)力始于“恰當(dāng)?shù)男枨蟆薄?/p>

為了減少研發(fā)過程的返工和浪費，需求進(jìn)入研發(fā)前要符合準(zhǔn)入標(biāo)準(zhǔn)DoR（Definition of Ready），發(fā)布前要符合準(zhǔn)出標(biāo)準(zhǔn)DoD（Definition of Done)。需求發(fā)布后，產(chǎn)品經(jīng)理會觀測埋點數(shù)據(jù)，業(yè)務(wù)和運營會搜集用戶反饋。One Team會上大家根據(jù)用戶反饋決定下一步的改進(jìn)和優(yōu)化。

迭代活動有節(jié)奏地進(jìn)行，迭代才能有序運轉(zhuǎn)。One Team成員商議后，一致同意嘗試如下的節(jié)奏：

?

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

?

迭代第一天，研發(fā)團(tuán)隊按照優(yōu)先級把符合準(zhǔn)入標(biāo)準(zhǔn)的需求拉入迭代，做初步的設(shè)計和估算。根據(jù)估算做出嚴(yán)肅的承諾，并制定研發(fā)計劃：

?

從圖中可以看出，為了降低風(fēng)險和分散壓力，團(tuán)隊盡量做到小批量逐步提測。提測前測試同學(xué)會設(shè)計好測試用例，提測時開發(fā)同學(xué)要跑通P0、P1測試用例。測試同學(xué)驗證基本功能可用，立即邀請產(chǎn)品經(jīng)理和業(yè)務(wù)同學(xué)試用，以便盡快發(fā)現(xiàn)體驗問題。功能發(fā)布前，業(yè)務(wù)方驗收即將發(fā)布的版本，業(yè)務(wù)驗收通過后才可以發(fā)布。

?

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

為了增加透明性，我們用工作流描述需求狀態(tài)的流轉(zhuǎn)：

?

用看板跟蹤需求的狀態(tài)：

?

效果評估

1.One Team機(jī)制促進(jìn)跨部門協(xié)作

業(yè)務(wù)、產(chǎn)品、研發(fā)之間曾經(jīng)相互埋怨，業(yè)務(wù)覺得交付的功能不是最需要的，急需的功能反而沒給做，研發(fā)覺得辛苦做出來的功能沒人用非常冤，產(chǎn)品夾在中間兩頭受氣。

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

CRM產(chǎn)品團(tuán)隊季度總結(jié)時，CRM KA的產(chǎn)品經(jīng)理和業(yè)務(wù)接口人表示：One Team機(jī)制建立以來，跑通了業(yè)務(wù)需求從提出到上線后反饋的大閉環(huán)，業(yè)務(wù)、產(chǎn)品、研發(fā)有序協(xié)作，接下來會把這個機(jī)制順利地運轉(zhuǎn)下去。

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

智能營銷平臺的技術(shù)負(fù)責(zé)人高度評價One Team機(jī)制：“不僅提升了團(tuán)隊的開發(fā)效率，也提升了團(tuán)隊的溝通效率”。

One Team成員在持續(xù)的協(xié)作中，增進(jìn)了信任和了解，研發(fā)更了解業(yè)務(wù)，業(yè)務(wù)也更體諒研發(fā)。以下是兩個具體的例子：

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

CRM團(tuán)隊的所有需求都在Aone中跟蹤，團(tuán)隊在站會上更新需求狀態(tài)，根據(jù)需求狀態(tài)流轉(zhuǎn)生成的統(tǒng)計圖表能夠反映真實情況。

雙周迭代的首要目標(biāo)是縮短需求交付時長。結(jié)合這個目標(biāo)，我們主要關(guān)注2個指標(biāo)：開發(fā)時長和從開發(fā)到發(fā)布的交付時長。需求拆分得越小，開發(fā)時長越短，越適合迭代開發(fā)。交付時長越短，研發(fā)團(tuán)隊的適應(yīng)性越好。業(yè)務(wù)需要時，團(tuán)隊能夠迅速實現(xiàn)需求并交付到用戶手里。

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

?

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

?

值得一提的是，在向雙周迭代轉(zhuǎn)型的過程中，CRM團(tuán)隊保持了很高的質(zhì)量水準(zhǔn)，無論是提測質(zhì)量、線上質(zhì)量還是缺陷修復(fù)速度，都達(dá)到了集團(tuán)領(lǐng)先水平。

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

應(yīng)對挑戰(zhàn)

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

1. 聚焦于持續(xù)快速交付業(yè)務(wù)價值

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

2. 用技術(shù)手段提高生產(chǎn)率

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

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

總結(jié)

通過One Team機(jī)制，業(yè)務(wù)、產(chǎn)品、研發(fā)間增進(jìn)了信任和了解，彼此協(xié)作更順暢。

通過拆分需求和有節(jié)奏的短迭代，CRM團(tuán)隊從瀑布開發(fā)模式比較順利地轉(zhuǎn)型到了迭代開發(fā)模式。發(fā)布頻率從數(shù)月一次變?yōu)閮芍軘?shù)次，基本做到6天以內(nèi)提測，20天以內(nèi)發(fā)布。更可喜的是，在轉(zhuǎn)型過程中，團(tuán)隊保持了高質(zhì)量。

研發(fā)團(tuán)隊持續(xù)快速交付業(yè)務(wù)急需的功能，得到了業(yè)務(wù)團(tuán)隊的高度認(rèn)可。

轉(zhuǎn)自：《敏捷開發(fā)，你真的做對了嗎？阿里文娛廣告團(tuán)隊敏捷實踐總結(jié)》?

總結(jié)

以上是生活随笔為你收集整理的【转】敏捷开发，你真的做对了吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。