中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文將從項目（產品）目標，團隊構成和研發過程三個方面分析這種情況出現的原因，并希望從業者一起為敏捷開發在ToB項目中的推廣普及獻計獻策。

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

這就很奇怪了，一方面最近這10年是敏捷開發在國內IT產品研發中用的最多和普及率最高的項目（產品）開發模式，特別是在互聯網行業里混得風生水起，一個產品經理如果不懂Scrum或XP，都不好意思自稱是產品經理。

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

敏捷開發的普及在當下仍處于冰火兩重天的狀態，在互聯網中小型項目中玩得風風火火，在大型ToB項目中卻又鎩羽而歸，受到業內人士質疑。

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

產品目標

一. 從項目（產品）實現目標來看敏捷開發的必要條件

敏捷開發成功的首要條件是項目（產品）目標的一致性認知，只有企業，團隊和個人的目標在高度一致的情況，才能很好的利用敏捷開發帶來的快速，靈活，低成本的優勢。

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

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

1. 企業客戶的軟件目標是什么？

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

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

2. 改造企業客戶的產品預期

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

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

2）如果企業需求本身不穩定，項目預期又是一個長周期，那請使用敏捷方法。在當今激烈的市場競爭過程，如果項目周期是以年為單位開展實施的，恰恰需要用敏捷方法，因為需求從項目開始到結束必然會發生變化，如果還采用瀑布模式，得到的產品一定不是最后客戶想要的產品。

而我們要在企業客戶的產品研發中采用敏捷開發方法，首要條件是要說服企業客戶轉變產品預期，把產品目標從一次性的整體性解決方案改為小步快步的分流程分業務的迭代改進。

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

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

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

3. 改造研發企業的內部KPI

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

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

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

4. 提供多系統并行的運維保障

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

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

二. 從敏捷團隊構成看敏捷開發的必要條件

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

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

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

而在敏捷的開發模式中，團隊構建以MVP產品完整的端到端業務線為組織單元，不再以職能劃分，不同的研發角色按完整業務流程混合搭配，組成特戰混合團隊，保證研發目標是最終用戶的認可，為此不惜重構代碼。

而每個參與團隊的人員綜合素質需要更加全面，產品經理要理解系統，研發要懂得設計，測試要熟悉客戶，而全部成員都要懂得產品的概念模型。

這種特戰混合團隊的開發模式從當前的軍隊改革進程中可以窺見一斑，目前我國軍隊正在從傳統按裝備分類（類似我們的研發職能部門）的師級單位向混合旅單位轉型，按照不同的作戰方向（類似我們的業務線）為每個混合旅配置不同的裝甲部隊，火炮，陸航甚至戰術彈道導彈等，以適應不同情況下（類似我們的產品需求）的作戰需求。

所以以MVP為目標的敏捷開發，除了必要的一些規則和方法以外，最重要的是要從參與人的敏捷素質上要求，并建立敏捷的開發團隊。

XP

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

接著我們談談從開發過程的細節處，看敏捷方法在ToB中容易忽略的問題，為了描述方便我簡單從：需求，計劃，測試和重構四個方面入手談敏捷，因為是敏捷，所以這四個方面并沒有傳統的順序，而是相互融合的過程。

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

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

1. 需求

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

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

需求的分析重點也發生了變化，需求不再是大而全的收集和分析，而是根據企業的運營核心實體，核心運營流程，以MVP定義產品目標為方向的重點分析核心流程和核心業務。重點保障核心流程和核心業務實現完整的端到端貫通。

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

2. 計劃

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

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

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

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

所以敏捷的計劃是在實踐中開展修正的，一切以先做起來為目標，不會因為項目經理和企業客戶還在對整體系統的上線時間點上爭吵不休，而停滯不前。敏捷的計劃是戰術計劃，更具備可執行性。

3. 測試

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

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

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

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

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

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

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

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

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

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

4. 重構

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

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

1）系統所有權問題，一旦ToB的項目上線，系統所有權就是企業客戶的，后續軟件提供商就是再想優化和重構以前的代碼，如果企業客戶不愿意承擔重構帶來的系統風險，那也很難開展。

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

3）怕重構，軟件提供商往往已經達到談重構色變的地步，記得有一次產品研討會上我向企業領導提出了重構的想法，這位領導立刻打段我的話，說：“我們投入這么大的研發成本，就是希望不要再重復修改我們產品”。我想他一定覺得自己的產品是一架設計優美，做工精良的鐘表。

重構是實現敏捷的必然之路，如果沒有重構，我們怎么優化和適應對需求的理解呢？敏捷開發強調對需求的理解是從點到線再到面的過程也是和產品由局部到完整的迭代過程同步的，任何只想使用敏捷方法的形式（如：迭代周期，站立式晨會，任務跟蹤等），而忽略敏捷方法的本質：鼓勵重構，的系統建設想法都是錯誤的，這樣做你并不能得到一個敏捷的系統。

總結

從業務發展趨勢來說，未來ToB系統的需求只會越來越不穩定，沒有哪個企業客戶能保證年初的想法和市場需求到年底不會變化，這種需求變化頻率從原來的年度提高到季度和月，這種現象也是不可逆轉的，我們只能去適應和解決它。

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

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

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

本文由 @烏士兒 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議