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

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

這就很奇怪了，一方面最近這10年是敏捷開發(fā)在國內(nèi)IT產(chǎn)品研發(fā)中用的最多和普及率最高的項目（產(chǎn)品）開發(fā)模式，特別是在互聯(lián)網(wǎng)行業(yè)里混得風(fēng)生水起，一個產(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)瀑布模式比并沒有顯著提高，客戶體驗不好，項目周期延遲，開發(fā)bug多，需求變更適應(yīng)性差，研發(fā)成本高昂等老大難問題依然存在。

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

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

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

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

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

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

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

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

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

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

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

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

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

2）如果企業(yè)需求本身不穩(wěn)定，項目預(yù)期又是一個長周期，那請使用敏捷方法。在當(dāng)今激烈的市場競爭過程，如果項目周期是以年為單位開展實施的，恰恰需要用敏捷方法，因為需求從項目開始到結(jié)束必然會發(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)方，客戶有理由要求得到與合同額價值相匹配的產(chǎn)品，所以除了從敏捷開發(fā)理念上去說服客戶以外（靠理念說服效果最差），最重要的是要切入企業(yè)客戶業(yè)務(wù)運營架構(gòu)，從企業(yè)SOP（Standard Operating Procedure）中去建立企業(yè)核心core流程（服務(wù)或生產(chǎn)），區(qū)分核心業(yè)務(wù)流程優(yōu)先級，為企業(yè)客戶提供一套可行的產(chǎn)品迭代業(yè)務(wù)框架。 關(guān)于企業(yè)核心SOP Core流程可以參看：《初建電商優(yōu)先關(guān)注的7個流程(一)》。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XP

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

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

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

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

1. 需求

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

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

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

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

2. 計劃

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

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

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

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

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

3. 測試

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

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

1）單元測試（白盒測試）

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

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

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

2）驗收測試（黑盒測試）

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

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

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

4. 重構(gòu)

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

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

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

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

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

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

總結(jié)：

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

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

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

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

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

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

愛盈利-運營小咖秀(www.jza6.com) 始終堅持研究分享移動互聯(lián)網(wǎng)App運營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運營從業(yè)者的知識啟蒙、成長指導(dǎo)、進(jìn)階學(xué)習(xí)的集聚平臺；

想了解更多移動互聯(lián)網(wǎng)干貨知識，請關(guān)注微信公眾號運營小咖秀（ID: yunyingshow）