本文將從項(xiàng)目（產(chǎn)品）目標(biāo)，團(tuán)隊(duì)構(gòu)成和研發(fā)過程三個(gè)方面分析這種情況出現(xiàn)的原因，并希望從業(yè)者一起為敏捷開發(fā)在ToB項(xiàng)目中的推廣普及獻(xiàn)計(jì)獻(xiàn)策。

我在10年ToB的行業(yè)產(chǎn)品研發(fā)和項(xiàng)目實(shí)施的工作中，不止一次聽到關(guān)于“敏捷開發(fā)模式不適合大型ToB項(xiàng)目研發(fā)”的觀點(diǎn)，堅(jiān)持該觀點(diǎn)的往往也都是資深項(xiàng)目經(jīng)理和研發(fā)Leader。

這就很奇怪了，一方面最近這10年是敏捷開發(fā)在國內(nèi)IT產(chǎn)品研發(fā)中用的最多和普及率最高的項(xiàng)目（產(chǎn)品）開發(fā)模式，特別是在互聯(lián)網(wǎng)行業(yè)里混得風(fēng)生水起，一個(gè)產(chǎn)品經(jīng)理如果不懂Scrum或XP，都不好意思自稱是產(chǎn)品經(jīng)理。

另一方面大型企業(yè)的行業(yè)產(chǎn)品研發(fā)不斷嘗試敏捷的過程管理（例如：生產(chǎn)制造業(yè)的ERP，服務(wù)業(yè)的CRM，BILLING等系統(tǒng)），但最終收到的效果和傳統(tǒng)瀑布模式比并沒有顯著提高，客戶體驗(yàn)不好，項(xiàng)目周期延遲，開發(fā)bug多，需求變更適應(yīng)性差，研發(fā)成本高昂等老大難問題依然存在。

敏捷開發(fā)的普及在當(dāng)下仍處于冰火兩重天的狀態(tài)，在互聯(lián)網(wǎng)中小型項(xiàng)目中玩得風(fēng)風(fēng)火火，在大型ToB項(xiàng)目中卻又鎩羽而歸，受到業(yè)內(nèi)人士質(zhì)疑。

但不可否認(rèn)的是無論ToC還是ToB的產(chǎn)品研發(fā)過程對(duì)需求變更適應(yīng)性的要求只會(huì)越來越敏捷，不會(huì)再回到過去傳統(tǒng)瀑布模式的研發(fā)體系中，至少這是業(yè)界的共識(shí)，只是用敏捷方法論還是混合方法論才是爭議比較大的方面。本文將從項(xiàng)目（產(chǎn)品）目標(biāo)，團(tuán)隊(duì)構(gòu)成和研發(fā)過程三個(gè)方面分析這種情況出現(xiàn)的原因，并希望從業(yè)者一起為敏捷開發(fā)在ToB項(xiàng)目中的推廣普及獻(xiàn)計(jì)獻(xiàn)策。

產(chǎn)品目標(biāo)

一. 從項(xiàng)目（產(chǎn)品）實(shí)現(xiàn)目標(biāo)來看敏捷開發(fā)的必要條件

敏捷開發(fā)成功的首要條件是項(xiàng)目（產(chǎn)品）目標(biāo)的一致性認(rèn)知，只有企業(yè)，團(tuán)隊(duì)和個(gè)人的目標(biāo)在高度一致的情況，才能很好的利用敏捷開發(fā)帶來的快速，靈活，低成本的優(yōu)勢(shì)。

這和互聯(lián)網(wǎng)公司扁平化的管理模式的道理一樣。ToB和ToC的項(xiàng)目（產(chǎn)品）最大的區(qū)別是這個(gè)目標(biāo)還要加上同客戶的目標(biāo)一致性問題，在To C的項(xiàng)目（產(chǎn)品）中，研發(fā)團(tuán)隊(duì)對(duì)客戶的使用目標(biāo)是通過分析和預(yù)期得到的，客戶很少實(shí)際參與決策（當(dāng)然為提高客戶體驗(yàn)，很多產(chǎn)品研發(fā)引入自愿者用戶參與產(chǎn)品設(shè)計(jì)，但更多的是提供用戶體驗(yàn)的反饋，而不是決策）；但在ToB的項(xiàng)目（產(chǎn)品）研發(fā)過程中，客戶卻是最重要的決策者之一（很多時(shí)候就是客戶決策）。

出現(xiàn)這種情況，是因?yàn)榇蟛糠諸oB的項(xiàng)目（產(chǎn)品）都是合同驅(qū)動(dòng)的，先簽合同，后開展產(chǎn)品研發(fā)或者項(xiàng)目實(shí)施，所以客戶在將得到一個(gè)什么樣的產(chǎn)品的問題上占有決策的主導(dǎo)地位。這時(shí)研發(fā)企業(yè)或者團(tuán)隊(duì)想要開展敏捷開發(fā)模式，如果不把客戶的目標(biāo)和研發(fā)團(tuán)隊(duì)定義的MVP產(chǎn)品目標(biāo)以及后續(xù)迭代計(jì)劃相整合，那敏捷開發(fā)是很難推進(jìn)展開的。

1. 企業(yè)客戶的軟件目標(biāo)是什么？

一般來講，在ToB的大型企業(yè)級(jí)軟件交付市場(chǎng)中，企業(yè)客戶對(duì)于即將交互的軟件總是希望能最大可能的解決目前企業(yè)的全部問題；能一次性割接和替換掉現(xiàn)有的老系統(tǒng)

這種最大化價(jià)值產(chǎn)品期待和敏捷開發(fā)的最簡化價(jià)值產(chǎn)品（MVP）的理念是恰好是相反的，可以想象如果企業(yè)客戶希望的第一個(gè)上線運(yùn)行版本，是一套功能完整和徹底改進(jìn)的產(chǎn)品，而你的開發(fā)模式又采用敏捷開發(fā)模式，這樣的項(xiàng)目從一開始就注定是一個(gè)失敗產(chǎn)品（至少從期望上看）。

2. 改造企業(yè)客戶的產(chǎn)品預(yù)期

敏捷開發(fā)產(chǎn)品理念和企業(yè)客戶的產(chǎn)品預(yù)期由于綜上所述原因，存在天然矛盾，這就為軟件提供商和企業(yè)客戶提出了一道選擇題：

1）如果企業(yè)需求變更小，項(xiàng)目預(yù)期周期短（恰恰是因?yàn)轫?xiàng)目周期短，需求變更的可能性才?。?，請(qǐng)還是使用瀑布模式或者螺旋模式。

2）如果企業(yè)需求本身不穩(wěn)定，項(xiàng)目預(yù)期又是一個(gè)長周期，那請(qǐng)使用敏捷方法。在當(dāng)今激烈的市場(chǎng)競(jìng)爭過程，如果項(xiàng)目周期是以年為單位開展實(shí)施的，恰恰需要用敏捷方法，因?yàn)樾枨髲捻?xiàng)目開始到結(jié)束必然會(huì)發(fā)生變化，如果還采用瀑布模式，得到的產(chǎn)品一定不是最后客戶想要的產(chǎn)品。

而我們要在企業(yè)客戶的產(chǎn)品研發(fā)中采用敏捷開發(fā)方法，首要條件是要說服企業(yè)客戶轉(zhuǎn)變產(chǎn)品預(yù)期，把產(chǎn)品目標(biāo)從一次性的整體性解決方案改為小步快步的分流程分業(yè)務(wù)的迭代改進(jìn)。

這是相當(dāng)不容易的，在ToB的軟件交付過程中，客戶是合約權(quán)責(zé)的行權(quán)方，客戶有理由要求得到與合同額價(jià)值相匹配的產(chǎn)品，所以除了從敏捷開發(fā)理念上去說服客戶以外（靠理念說服效果最差），最重要的是要切入企業(yè)客戶業(yè)務(wù)運(yùn)營架構(gòu)，從企業(yè)SOP（Standard Operating Procedure）中去建立企業(yè)核心core流程（服務(wù)或生產(chǎn)），區(qū)分核心業(yè)務(wù)流程優(yōu)先級(jí)，為企業(yè)客戶提供一套可行的產(chǎn)品迭代業(yè)務(wù)框架。 關(guān)于企業(yè)核心SOP Core流程可以參看：《初建電商優(yōu)先關(guān)注的7個(gè)流程(一)》。

而MVP產(chǎn)品范圍的定義一定要滿足企業(yè)客戶的Core業(yè)務(wù)流程中的Core業(yè)務(wù)。軟件提供商在提供第一個(gè)MVP版本的功能框架中要選擇實(shí)現(xiàn)完整的一個(gè)Core業(yè)務(wù)流程或者流程中完整的一個(gè)Core業(yè)務(wù)。例如：Request-to-answer （客戶請(qǐng)求到響應(yīng)）中的某產(chǎn)品咨詢流程。

軟件提供商為企業(yè)客戶提供一套具備產(chǎn)品迭代優(yōu)先級(jí)的企業(yè)Core業(yè)務(wù)流程框架（注意是框架不是具體需求）和第一個(gè)MVP版本功能范圍，是建立和企業(yè)客戶之間的信任，從而說服企業(yè)客戶采用敏捷方法驗(yàn)收的必要條件。

3. 改造研發(fā)企業(yè)的內(nèi)部KPI

要在ToB項(xiàng)目中成功實(shí)踐敏捷開發(fā)，研發(fā)企業(yè)內(nèi)部的KPI考核體系也需要隨之調(diào)整。在傳統(tǒng)ToB項(xiàng)目中，研發(fā)企業(yè)內(nèi)部往往通過合同簽約，客戶階段性驗(yàn)收和項(xiàng)目回款等考核體系來評(píng)價(jià)研發(fā)團(tuán)隊(duì)或項(xiàng)目實(shí)施團(tuán)隊(duì)，評(píng)估反饋者是客戶（企業(yè)客戶）。

這種評(píng)估和管理手段在敏捷開發(fā)中是無效的，敏捷的迭代單元是一個(gè)Core流程或者Core業(yè)務(wù)，同時(shí)敏捷的評(píng)估反饋者是最終用戶的產(chǎn)品實(shí)際體驗(yàn)（是軟件的最終使用者）。

有效的考核體系應(yīng)該建立在有最終用戶參與的產(chǎn)品反饋體系中，我們知道很多主流B2C的網(wǎng)站和APP在設(shè)計(jì)之初就把流量反饋和用戶使用反饋等作為上線后的運(yùn)營重點(diǎn)，這些產(chǎn)品用戶一線的使用反饋才是在敏捷開發(fā)中，幫助修正需求和開發(fā)偏差重要考核依據(jù)。

4. 提供多系統(tǒng)并行的運(yùn)維保障

如果在ToB項(xiàng)目中采用敏捷開發(fā)，以提供MVP產(chǎn)品的作為上線標(biāo)準(zhǔn)，那就會(huì)出現(xiàn)在未來的一段時(shí)間內(nèi)新老系統(tǒng)同時(shí)并行運(yùn)行的問題。上面講過，在ToB的MVP產(chǎn)品定義，是實(shí)現(xiàn)一個(gè)完整的Core業(yè)務(wù)流程或者流程中Core業(yè)務(wù)，而這樣就會(huì)出現(xiàn)企業(yè)其余業(yè)務(wù)流程或業(yè)務(wù)還需要在原有老系統(tǒng)中完成，這種多系統(tǒng)并行的運(yùn)營模式，是企業(yè)客戶不愿意看到的，這會(huì)帶來運(yùn)維成本高，運(yùn)維難度大的問題。

要解決該問題軟件提供商就必須提供一套在敏捷開發(fā)模式下支撐多系統(tǒng)并行需要的運(yùn)維保障框架，包括：數(shù)據(jù)同步，業(yè)務(wù)接口調(diào)用，流程串接等。只有認(rèn)識(shí)到多系統(tǒng)并行也是敏捷開發(fā)所帶來的必然結(jié)果，并且用完整的運(yùn)維保障去克服新老系統(tǒng)的銜接和過渡問題，才能使企業(yè)客戶打消疑慮，愿意采用對(duì)MVP產(chǎn)品逐步迭代方式完成軟件交付。

二. 從敏捷團(tuán)隊(duì)構(gòu)成看敏捷開發(fā)的必要條件

相信很多在ToB項(xiàng)目中嘗試過敏捷開發(fā)的朋友都有這樣的經(jīng)歷，往往我們要實(shí)踐敏捷方法，首先實(shí)踐的是敏捷的迭代計(jì)劃，規(guī)則和流程這些制度化的指標(biāo)，例如：每個(gè)迭代Sprint控制在1-4周，每日站立會(huì)議，迭代中是否允許需求變更，是否遵守優(yōu)先級(jí)等方面。

但我們常常忽略人的因素，從敏捷開發(fā)的觀點(diǎn)看是：交付產(chǎn)品的關(guān)鍵因素是人，而非過程，所以我們對(duì)過程的精益求精，往往是以忽略“敏捷人”本身素質(zhì)為代價(jià)的。

在傳統(tǒng)ToB開發(fā)模式中，每個(gè)開發(fā)階段都有相對(duì)應(yīng)的組織或部門分工協(xié)作，細(xì)分每個(gè)步驟，從需求分析，架構(gòu)設(shè)計(jì)，研發(fā)，測(cè)試，項(xiàng)目實(shí)施，項(xiàng)目管理都是由林林總總的部門和組織構(gòu)成，而這些部門之間的溝通由接口人和接口文檔構(gòu)成，各自只負(fù)責(zé)自己的專業(yè)和領(lǐng)域，所以當(dāng)需求發(fā)生變更的時(shí)候從上至下的變更成本高，大家都抵觸。

而在敏捷的開發(fā)模式中，團(tuán)隊(duì)構(gòu)建以MVP產(chǎn)品完整的端到端業(yè)務(wù)線為組織單元，不再以職能劃分，不同的研發(fā)角色按完整業(yè)務(wù)流程混合搭配，組成特戰(zhàn)混合團(tuán)隊(duì)，保證研發(fā)目標(biāo)是最終用戶的認(rèn)可，為此不惜重構(gòu)代碼。

而每個(gè)參與團(tuán)隊(duì)的人員綜合素質(zhì)需要更加全面，產(chǎn)品經(jīng)理要理解系統(tǒng)，研發(fā)要懂得設(shè)計(jì)，測(cè)試要熟悉客戶，而全部成員都要懂得產(chǎn)品的概念模型。

這種特戰(zhàn)混合團(tuán)隊(duì)的開發(fā)模式從當(dāng)前的軍隊(duì)改革進(jìn)程中可以窺見一斑，目前我國軍隊(duì)正在從傳統(tǒng)按裝備分類（類似我們的研發(fā)職能部門）的師級(jí)單位向混合旅單位轉(zhuǎn)型，按照不同的作戰(zhàn)方向（類似我們的業(yè)務(wù)線）為每個(gè)混合旅配置不同的裝甲部隊(duì)，火炮，陸航甚至戰(zhàn)術(shù)彈道導(dǎo)彈等，以適應(yīng)不同情況下（類似我們的產(chǎn)品需求）的作戰(zhàn)需求。

所以以MVP為目標(biāo)的敏捷開發(fā)，除了必要的一些規(guī)則和方法以外，最重要的是要從參與人的敏捷素質(zhì)上要求，并建立敏捷的開發(fā)團(tuán)隊(duì)。

XP

三. 從開發(fā)過程管理看敏捷開發(fā)的必要條件

接著我們談?wù)剰拈_發(fā)過程的細(xì)節(jié)處，看敏捷方法在ToB中容易忽略的問題，為了描述方便我簡單從：需求，計(jì)劃，測(cè)試和重構(gòu)四個(gè)方面入手談敏捷，因?yàn)槭敲艚?，所以這四個(gè)方面并沒有傳統(tǒng)的順序，而是相互融合的過程。

在此之前我們先得了解一下目前最為流行的兩種敏捷方法：Scrum和XP(Extreme Programming)從差別，具體細(xì)節(jié)差別大家可以參看：《Differences Between Scrum and Extreme Programming》這篇文章，從總體上來講Scrum是一套敏捷框架，它并沒有具體的操作方法，所以對(duì)成員的敏捷素質(zhì)要求比較高，比較敏捷經(jīng)驗(yàn)豐富，能力比較綜合或者是小型的研發(fā)團(tuán)隊(duì)。

而XP則對(duì)團(tuán)隊(duì)組成（包括客戶），辦公區(qū)域大小，環(huán)境（開發(fā)空間），需求的結(jié)構(gòu)，交付周期，測(cè)試方法，編程方法（結(jié)對(duì)編程），計(jì)劃，持續(xù)集成，重構(gòu)都有具體的實(shí)踐方法，所以對(duì)于喜歡用制度和規(guī)定來實(shí)踐敏捷的企業(yè)，比較適合，更適合中大型研發(fā)團(tuán)隊(duì)。所以后面主要參考XP，作為ToB項(xiàng)目敏捷研發(fā)方法對(duì)比。

1. 需求

在傳統(tǒng)ToB的軟件交付過程中，同客戶溝通，收集，分析，整理需求的工作都是由BA（或者叫需求分析師）這個(gè)角色完成，其他角色只是被動(dòng)等待BA的輸出文檔，如：RFP（Request for Proposals）和RFS（Function Requirements Specification）,RFP文檔負(fù)責(zé)與客戶溝通，RFS文檔負(fù)責(zé)與研發(fā)團(tuán)隊(duì)溝通。這樣分工清晰的界面，在敏捷過程中卻很容易嚴(yán)重限制需求響應(yīng)的靈活性。

敏捷（XP）的需求，首先要求的是框架性需求，而不是一次性搞清楚所有問題；從客戶需求到研發(fā)需求盡量采用一套文檔，而不是多套文檔間轉(zhuǎn)換（需求失真往往是通過文檔轉(zhuǎn)換產(chǎn)生的）；大量采用概念模型方式驗(yàn)證和說明業(yè)務(wù)含義，減少純文字描述性需求（大量文字描述會(huì)影響需求變更的代價(jià)）；而由于客戶本身就是敏捷團(tuán)隊(duì)的成員，客戶需求直接對(duì)接研發(fā)單位，傳統(tǒng)BA向產(chǎn)品經(jīng)理轉(zhuǎn)型。

需求的分析重點(diǎn)也發(fā)生了變化，需求不再是大而全的收集和分析，而是根據(jù)企業(yè)的運(yùn)營核心實(shí)體，核心運(yùn)營流程，以MVP定義產(chǎn)品目標(biāo)為方向的重點(diǎn)分析核心流程和核心業(yè)務(wù)。重點(diǎn)保障核心流程和核心業(yè)務(wù)實(shí)現(xiàn)完整的端到端貫通。

需求是敏捷開發(fā)的素材，這種素材不需要立刻填充完整，而是需要先有需求骨架（需求骨架用于制定迭代計(jì)劃），然后需求內(nèi)容和細(xì)節(jié)是要在開發(fā)中和用戶不斷碰撞的過程中逐漸豐滿的。所以敏捷的需求分析過程是持續(xù)性的，迭代的，由粗到細(xì)的。

2. 計(jì)劃

在傳統(tǒng)ToB項(xiàng)目中計(jì)劃的安排基本是以項(xiàng)目里程碑的框架形成的，如：需求， 開發(fā)，測(cè)試，上線，初驗(yàn)，終驗(yàn)等，而系統(tǒng)上線，這樣一個(gè)關(guān)鍵里程碑的時(shí)間設(shè)定，往往是商務(wù)談判的結(jié)果，并不是對(duì)需求實(shí)際分析和實(shí)踐后的結(jié)果，而剩下的細(xì)分計(jì)劃就是以上線時(shí)間點(diǎn)的基準(zhǔn)倒推形成，當(dāng)然最后結(jié)果就是80%的大型項(xiàng)目上線都要延遲（在我經(jīng)歷過的大型項(xiàng)目中好像就沒有準(zhǔn)時(shí)交付的），這種延遲更多的是軟件提供商和企業(yè)客戶之間的商業(yè)博弈的結(jié)果和技術(shù)性無關(guān)。

企業(yè)客戶和軟件提供商在對(duì)待項(xiàng)目計(jì)劃的制定上，總是處于對(duì)立面，這是因?yàn)槠髽I(yè)客戶并沒有把軟件交付過程看成是一種相互協(xié)作的過程，而是一種商品交易過程。所以花了大錢肯定就要提出更快更多的要求。

如果要采用敏捷開發(fā)模式，在計(jì)劃的制定上就要從整個(gè)系統(tǒng)這個(gè)很難技術(shù)化評(píng)估的單元（如：CRM系統(tǒng)），轉(zhuǎn)移到具體實(shí)例化的某個(gè)流程和業(yè)務(wù)（如：完整的快消品訂購過程），因?yàn)榱鞒?，業(yè)務(wù)和具體的功能是雙方可以開展技術(shù)化辯論和評(píng)估的依據(jù)。

敏捷開發(fā)的計(jì)劃安排，總是從某個(gè)完整的具體流程和業(yè)務(wù)入手，通過團(tuán)隊(duì)成員共同制定的。一開始的任務(wù)執(zhí)行偏差是允許的，項(xiàng)目可以通過某個(gè)完整的一個(gè)Sprint的完成，實(shí)現(xiàn)對(duì)團(tuán)隊(duì)效率，能力和任務(wù)難易程度的評(píng)估，從而以此為基準(zhǔn)制定其他計(jì)劃。

所以敏捷的計(jì)劃是在實(shí)踐中開展修正的，一切以先做起來為目標(biāo)，不會(huì)因?yàn)轫?xiàng)目經(jīng)理和企業(yè)客戶還在對(duì)整體系統(tǒng)的上線時(shí)間點(diǎn)上爭吵不休，而停滯不前。敏捷的計(jì)劃是戰(zhàn)術(shù)計(jì)劃，更具備可執(zhí)行性。

3. 測(cè)試

在敏捷的測(cè)試過程中強(qiáng)調(diào)測(cè)試用例的前置，這和傳統(tǒng)ToB項(xiàng)目中在功能開發(fā)完成后，再編寫測(cè)試用例的過程截然不同。測(cè)試用例前置到需求分析階段同步開展，以測(cè)試驅(qū)動(dòng)開發(fā)是敏捷方法的典型特征。

在敏捷的測(cè)試中我們簡單分為單元測(cè)試（白盒測(cè)試）和驗(yàn)收測(cè)試（黑盒測(cè)試），在這兩類測(cè)試用例前置到開發(fā)前編寫，通過測(cè)試用例設(shè)計(jì)，我們會(huì)收到意想不到的效果。

1）單元測(cè)試（白盒測(cè)試）

在需求分析階段就要求開發(fā)人員編寫代碼級(jí)的單元測(cè)試用例，這樣可以讓開發(fā)人員積極參與需求討論和分析，深刻理解需求本質(zhì)，由于為了保障用例編譯通過，還需要開發(fā)人員依據(jù)功能要求預(yù)先編寫功能接口，從而保障單元測(cè)試完整性。

用代碼方式實(shí)現(xiàn)一套單元測(cè)試用例和功能接口以及相應(yīng)的代碼注釋，你會(huì)收到第一個(gè)敏捷衍生品API文檔（代碼），在敏捷開發(fā)中提倡以代碼（接口）和模型方式作為輸出文檔，盡量減少文字的運(yùn)用，能用代碼直接描述功能的就不用文字，最敏捷的描述功能的方法就是接口類，最敏捷的描述數(shù)據(jù)的方法就是數(shù)據(jù)模型。

你收到的第二個(gè)衍生品是代碼解耦，通過單元測(cè)試用例來驅(qū)動(dòng)后續(xù)的功能開發(fā)，可以讓開發(fā)人員在投入具體編碼前，站在客戶端的角度整體性的去思考功能調(diào)用間的關(guān)系，而不是一頭扎進(jìn)具體的某個(gè)功能實(shí)例中思考另一個(gè)功能調(diào)用。這樣好處是讓你最終可以收獲一套相對(duì)解耦的功能實(shí)現(xiàn)，解耦對(duì)于敏捷開發(fā)是至關(guān)重要的，直接影響到你的代碼是否可以適應(yīng)需求變更和重構(gòu)。

2）驗(yàn)收測(cè)試（黑盒測(cè)試）

如果說在需求分析階段，編寫單元測(cè)試用例是從微觀上實(shí)現(xiàn)代碼接口的定義和限制，那編寫驗(yàn)收測(cè)試用例就是從外觀上實(shí)現(xiàn)功能的定義和限制。一般驗(yàn)收測(cè)試用例由QA和客戶一同編寫，首先確定驗(yàn)收測(cè)試用例模板（可以參考5W1H），通過測(cè)試變量的可調(diào)整，最終生成測(cè)試用例的腳本實(shí)例。

測(cè)試用例模板可以用作產(chǎn)品功能定義，在傳統(tǒng)ToB項(xiàng)目的FRS中描述的大多數(shù)是靜態(tài)功能（如：賬戶增加，綁定，刪除等），文檔中無時(shí)間，地點(diǎn)，環(huán)境等，所以開發(fā)人員如果直接依據(jù)FRS文檔開發(fā)出的產(chǎn)品，很多都無法獲得客戶認(rèn)可，是一套死系統(tǒng)。而如果采用測(cè)試用例模板獲得是一套場(chǎng)景化的功能動(dòng)態(tài)描述，更具適用性和友好性。另外生成的測(cè)試用例的腳本實(shí)例（帶上具體變量枚舉參數(shù)）則自然成為后續(xù)自動(dòng)化測(cè)試的素材。

在傳統(tǒng)ToB項(xiàng)目中往往通過細(xì)化分工完成協(xié)作，BA負(fù)責(zé)需求分析，Developer和QA依據(jù)BA輸出的FRS編寫單元測(cè)試和驗(yàn)收測(cè)試用例，所以FRS文檔就成了上下游的銜接關(guān)鍵點(diǎn)，當(dāng)我們把一切后續(xù)研發(fā)產(chǎn)生的代價(jià)和成本都押在一份沒有溝通和反饋的文檔上的時(shí)候，大家可以預(yù)知后面的產(chǎn)品會(huì)長成什么樣。

4. 重構(gòu)

我不止一次問過在ToB的項(xiàng)目中的資深工程師，我們的項(xiàng)目有開展過重構(gòu)嗎? 他們的回答是：“有重構(gòu)，每年我們的版本都在升級(jí)，從1.0到2.0”，確實(shí)記得我參與過的一個(gè)項(xiàng)目從1.0一直升級(jí)到9.0，最后不得不換個(gè)系統(tǒng)名稱。但系統(tǒng)升級(jí)顯然不是系統(tǒng)重構(gòu)，系統(tǒng)升級(jí)是功能升級(jí)，而系統(tǒng)重構(gòu)是代碼重構(gòu)，代碼重構(gòu)并不一定會(huì)有功能升級(jí)，這有本質(zhì)區(qū)別。

在我經(jīng)歷過的ToB的項(xiàng)目中沒有一個(gè)是主動(dòng)開展過代碼重構(gòu)過程的，原因大致有三方面：

1）系統(tǒng)所有權(quán)問題，一旦ToB的項(xiàng)目上線，系統(tǒng)所有權(quán)就是企業(yè)客戶的，后續(xù)軟件提供商就是再想優(yōu)化和重構(gòu)以前的代碼，如果企業(yè)客戶不愿意承擔(dān)重構(gòu)帶來的系統(tǒng)風(fēng)險(xiǎn)，那也很難開展。

2）重構(gòu)代碼無利可圖，對(duì)于軟件提供商和企業(yè)客戶來講，重構(gòu)都不能直接產(chǎn)生經(jīng)濟(jì)效應(yīng)，企業(yè)客戶需要的是功能，歡迎功能升級(jí)，拒絕無功能升級(jí)的重構(gòu)；軟件提供商需要的是合同，新功能帶來新合同，拒絕無收益的成本投入。

3）怕重構(gòu)，軟件提供商往往已經(jīng)達(dá)到談重構(gòu)色變的地步，記得有一次產(chǎn)品研討會(huì)上我向企業(yè)領(lǐng)導(dǎo)提出了重構(gòu)的想法，這位領(lǐng)導(dǎo)立刻打段我的話，說：“我們投入這么大的研發(fā)成本，就是希望不要再重復(fù)修改我們產(chǎn)品”。我想他一定覺得自己的產(chǎn)品是一架設(shè)計(jì)優(yōu)美，做工精良的鐘表。

重構(gòu)是實(shí)現(xiàn)敏捷的必然之路，如果沒有重構(gòu)，我們?cè)趺磧?yōu)化和適應(yīng)對(duì)需求的理解呢？敏捷開發(fā)強(qiáng)調(diào)對(duì)需求的理解是從點(diǎn)到線再到面的過程也是和產(chǎn)品由局部到完整的迭代過程同步的，任何只想使用敏捷方法的形式（如：迭代周期，站立式晨會(huì)，任務(wù)跟蹤等），而忽略敏捷方法的本質(zhì)：鼓勵(lì)重構(gòu)，的系統(tǒng)建設(shè)想法都是錯(cuò)誤的，這樣做你并不能得到一個(gè)敏捷的系統(tǒng)。

總結(jié)

從業(yè)務(wù)發(fā)展趨勢(shì)來說，未來ToB系統(tǒng)的需求只會(huì)越來越不穩(wěn)定，沒有哪個(gè)企業(yè)客戶能保證年初的想法和市場(chǎng)需求到年底不會(huì)變化，這種需求變化頻率從原來的年度提高到季度和月，這種現(xiàn)象也是不可逆轉(zhuǎn)的，我們只能去適應(yīng)和解決它。

而敏捷方法給我們指出了一條快速適應(yīng)需求的路，敏捷可以給我們的系統(tǒng)帶來更多的靈活性，但它并不能直接幫助軟件提供商提高合同額，提高研發(fā)效率，對(duì)，你沒有看錯(cuò)，敏捷并不是提高效率的手段，有時(shí)反而因?yàn)榈_發(fā)還會(huì)延長產(chǎn)品交付周期，但敏捷帶來了更好的產(chǎn)品需求適應(yīng)性，選擇敏捷模式同學(xué)們一定要記住。

因?yàn)槠椭黝}的限制其實(shí)關(guān)于敏捷的開展是否最終能成功還有一個(gè)關(guān)鍵因素，本文并沒有涉及，這就是：敏捷設(shè)計(jì)，由于話題太大，需要另設(shè)立主題聊，所以我打算后續(xù)通過領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD: Domain-Driven Design）中聊聊敏捷的設(shè)計(jì)話題。

我們很多把敏捷形式開展的很好的團(tuán)隊(duì)，常常忽略了敏捷設(shè)計(jì)的重要性，就如同兩條腿走路，斷其一只都寸步難行，如果沒有敏捷化的代碼和模塊設(shè)計(jì)，再好的敏捷想法也不能通過系統(tǒng)本身實(shí)現(xiàn)。

本文由 @烏士兒 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議