【摘要】 在日趨激烈的電信業競爭態勢下，持續而快速地發掘和響應商機成為新的課題。作為響應機制中的關鍵環節，需求工程應用敏捷過程方法，以關注商業價值、快速響應、持續迭代的特征來應對變化和難測的未來，是嘗試提高組織敏捷能力的核心。在這其中，作為溝通橋梁的需求分析同樣可以應用敏捷的過程方法參與到生命周期的演進。敏捷需求分析將在需求時機與過程、文檔要求、變更、參與者角色等方面展現其不同傳統的特性。本文將結合電信業背景及企業實際情況，對敏捷需求分析作出初步的探索。
1、敏捷需求分析：電信行業背景與敏捷過程的需要
從中國電信行業ITSP戰略推出至今，數年中我們已經看到了明顯的變化，作為其信息化體系落地的CTG-MBOSS，也已初具規模和成效。大規模實施的下一個階段，將是在商業價值引領下的重構競爭模式、市場細分，以及作為支撐的需求深入研究。在項目實施過程中，各種挑戰和困難紛至沓來，項目管理者不管是做時間、成本、質量的三角平衡，還是人與技術的雙向選擇，始終無法繞開的一個問題跟源是：如何快速響應環境的變化，使客戶在優化的體驗過程中滿足其商業目標，從而實現企業本身的價值？
用失控的過程膨脹來形容近10年的許多軟件公司的情形是很合適的。雖然有很多團隊在工作中沒有使用過程的方法，但是采用龐大、重型的過程方法的趨勢卻在快速增長，在大公司中尤為如此。但現實的發展確與此不相同步，競爭態勢造成了更多的不確定性和快速調整的機會。從近年ERP上線的平均速度來看，項目的交付時間都比較長，這讓用戶產生了顧慮。但實際上軟件上線僅僅是一個軟件生命周期早期的階段，軟件的價值是在使用中體現出來的，其投資回報也只能在后期的運營得到完成。未來的變化如同納西姆？塔勒布的黑天鵝一般不可預測且重要，已知和過去瑣碎的重復并不足以預測未來的重大影響。以預測性度量為控制基礎的過程模型，只能以經驗涵蓋一般性事件，所以與此同時，隨機應變，保持快速集成和持續改進以應對商業環境的不確定性，延長軟件的生命周期提高它的最大價值，從而為獲取更多投資回報提供保障，也成為軟件工程發展的必然。
敏捷過程（Agile Process）的主要優勢是能夠適應系統需求的不確定性，將客戶作為需求團隊中密不可分的成員，而在實現過程中盡量在最短時間內實現對用戶來說業務價值最大的需求；同時，敏捷開發（Agile Development）是一種面臨迅速變化的需求快速開發軟件的能力，它幫助處理了未來不確定性的問題；但是對于過去，應該沒有不確定的事。而敏捷需求分析，是面對迅速變化的商業狀況，提高其響應和組織成可理解和接受的需求說明并對敏捷開發作出能力保證的方法論。
2、敏捷與過程改進和度量模型
從軟件工程發展起，過程改進在全球日益得到重視，ISO 9000/SW-CMM/CMMI各級的評估也在業界得以推展，這種氛圍下，以RUP等為代表的過程模型也得到了廣泛的應用。但與此同時，敏捷的論調卻異軍突起，方興未艾。軟件過程的多樣性，源于過程環境和層次的不同；而過程選擇的多樣性和CMMI目標的通用性決定了過程改進途徑的多樣化。
運用一系列重方法，將在應對商機方面造成挑戰；尤其是在企業的管理考核和過程模板仍更多的是一種瀑布式體系下，軟件的實現過程將在不同模型下搖擺卻顯得不那么靈活。一個合適的生命周期模型選擇是重要的，由于慣性的教育，瀑布在我們的工作環境中隨處可見。但如果不去分析CMMI等的實質，將無助于改進這一點而提高響應。
強調結構化方法與重型的管理策略，往往在內心中拒絕變更，把變更作為被管理甚至被“管制”的對象；而為了盡可能避免變更，常常要求開發之前的需求獲取、分析與定義要完整無誤且精確。這是一種理論上的理想狀態，盡管我們可以采取諸如CMMI的一些理念及過程改進模板對其管理，但實際上往往會出現與用戶商業價值要求的脫節；而為達成此目標，使得前期的需求開發工作變得小心翼翼，最終有可能在壓力與時間約束下難免簡單化而草草了事，在后期又不能得到及時的修正，從而形成一個隱患。
但實質上，重型、輕型過程方法論之間并不存在根本性的矛盾沖突，這體現于它們最終理念和出發點的一致。把這些互補方法論拼在一起，“恰好可以發現整個軟件過程體系全貌的一部分”。CMM/CMMI 中不包括更為具體一點的如何寫好需求，如何做好設計，如何寫好測試等許多方面的軟件工程技術、技能方面的指導，而這些恰好是敏捷的強項。敏捷方法整合了一套輕量的管理、過程和工程技術方法，這是它作為一種先進方法體系補充于CMMI 的地方。敏捷過程并不像業界所傳的那樣只適合小項目和新項目的研發，實際上它對于各種類型，包括企業所定義的A類、B類、C類在CMMI體系基礎上都是可取舍適用的。這需要過程體系間的適當裁剪和調整組合。敏捷需求分析，將在全過程中扮演銜接、溝通和滲透的作用。
3、敏捷需求分析的過程特性
IEEE對需求的定義是用戶解決問題或達到目標所需的條件或性能；系統或系統部件要滿足合同、標準或其他正式規定文檔的條件或性能。 需求是設計、構造產品的前提，簡單地說，是必須完成的事及其所必須具備的品質。需求存在的原因要么是該類型的產品要求一定的功能和品質，要么是客戶希望需求成為提交的產品的一部分[5]。
軟件需求包括三個不同的層次—業務需求、用戶需求和功能需求—也包括非功能需求。業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。用戶需求（user requirement） 文檔描述了用戶使用產品必須要完成的任務，這在使用用例（use case）文檔或方案腳本（scenario）說明中予以說明。功能需求（functional requirement）定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。所謂特性（feature）是指邏輯上相關的功能需求的集合，給用戶提供處理能力并滿足業務需求。
圖1. 需求的層次及組成
我們可以看到，不管是傳統的還是敏捷的需求開發階段，需求的層級及組成，其基本特性是一致的，這反映方法的差異并不改變需求的本身屬性。一般的需求三個層次，忽略了一個問題，即每個層次所需的知識、技能、經驗、背景等是不同的，不同的層次過程中，需要不同資源的整合。業界相關的論述中，只是給出了籠統的需求分析人員的統一角色，但并未對其作出區別。實際上，這很難映射到中小企業的現實操作層面。
這引發了我們進入詳細的敏捷需求分析話題中第一個問題，需求的參與者如何定義？
3.1 需求的參與者
敏捷需求分析過程的參與者，包括客戶/用戶、需求分析人員（業界一般也稱之為商務分析師或業務分析師，business analyst，本文并不討論詞匯的細致差異，下文統一簡稱BA）、開發人員、測試人員，其他相關的角色有項目管理者等。在《敏捷宣言》（Manifesto for Agile Software Development）中，強調了客戶一起現場工作的重要性。而在企業實際的實施過程中，由于限制，項目經理及實施人員，以及BA——如果有的話，在虛擬團隊中，他們演繹客戶的角色，從而使得“客戶”也更好地“納入”到了項目團隊中。但應該清楚，這種納入并不能真正代替真實的客戶參與。
對于客戶無法全程現場參與的情況，BA的出現是一種彌補。BA最重要的職責就是與客戶交談，了解和分析需求，將其制作成用戶故事（user story）并將需求傳遞給開發人員。同時，BA也要在某種參與度較深的情況下代替客戶負責功能驗收測試（Acceptance test）。而對內，BA顯然扮演了客戶，那么除了需求提供者的職責，如果需要的話，相應地也要有評價和驗收否決的權利。當然，這項工作可以分解為另外的角色來進行。
開發、測試人員進入需求團隊，便于他們理解用戶故事或者典型的RUP式的用例。一個完整描述的用例可以很方便地導出測例（test case）。而用例和測例是一致的，它描述在一個具體業務場景中可見的需求特征。我們可以根據這樣的可見性寫出功能測試，從而驅動這個用戶故事的開發，這被稱為 Acceptance Driven Development。從整個過程來說，分析和實現的過程就是場景擬合和檢驗，以及類似于XP中結對式的及時糾偏。各種角色的積極參與在不同角度和層次下的場景擬合，表明需求不是程序員的事情，也不是寄望于抽象出一個BA的角色甚至實例化為一個職位，就可以全能地做出需求定義。
對于角色及其參與方式，我們可以比較如下：
| 角色及職責 | 傳統的需求參與 | 敏捷的需求參與 |
| 用戶/客戶 | 需求的提供者 | 需求演進的參與者 |
| 用戶的主要參與方式 | 陳述 | 遵循游戲規則的積極的交互參與 |
| BA | 需求的定義者 | 需求的組織者 |
| BA的主要參與方式 | 前期的調查獲取和整理成文檔 | 參與全周期的迭代與演進 |
| 開發 | 需求的接受者和實現者 | 場景擬合者與改進者 |
| 開發的主要參與方式 | 被傳導需求并使之功能化 | 完成完整的業務場景實現 |
| 測試 | 功能測試者 | 場景測試者（需求測試者） |
| 測試的主要參與方式 | 找出軟件的顯性的bug | 找出不滿足需求邏輯和不能擬合場景的缺陷 |
表1：需求的主要參與者
（其他的stakeholders并未全部列出，比如PM、QA等）
這些參與者如何工作的呢？我們引入到需求分析的工作形式。
3.2 敏捷需求分析工作形式
敏捷宣言強調了客戶在一起工作的重要，敏捷是大家在一起高效率地工作，清楚所有溝通上的障礙，關注于增值的活動，從而使得項目更加成功。比如，敏捷聯盟所推薦的現場客戶工作。但多數情況下，客戶都是很忙碌的，很難全力投入到過程中。這時候，我們就需要BA這個角色，來充當客戶的角色。
BA的參與使他變成了需求的組織者，需要使需求分析過程中具備資源快速聚合的能力。而工作方式，在傳統之外，可以使用聚議和需求迭代計劃會議的形式。
敏捷思想的核心是人與人的交流。聚議是一種面對面的最好形式，它能促成問題從多個角度的現場核清。在前期的高層訪談之后，需求分析過程中至少要有以下的準備：（1）明確業務價值及其所推導的業務場景；（2）范圍劃分使得每個議題都有獨立的業務價值，對于大而籠統的“需求”，則分解或置入下次迭代，而本次完成的將是一個相對完整的結果。對于需求分析中所用的各種形式，用戶其實并不排斥參與——尤其是當他掌握了一定方法并能看到迅速回應帶來的好處時，將極大地提升這種興趣。在某省電信運營商的項目中，我們已經發現了這一點。用戶明白積極參與的好處時，能主動從業務角度審視自己的需求，刪減調整并作出易理解的文檔。在一個已經實施的項目中做增量改進時，用戶參與尤為重要，并且能部分地把前端人員從繁瑣而低效的溝通（其實只是“傳話筒”）和文檔化中解脫出來。
迭代是敏捷最顯著的形式，而迭代的前提，則是對業務價值分解為用戶故事的工作。這些將在下文中討論。迭代計劃會議是一種需求組織方式，在每個迭代開始的時候，由BA主持召開迭代計劃會議，在會議上向開發人員解釋這個迭代要完成的用戶故事，然后由開發人員自由提問，知道他們能夠獲得足夠開始實現該功能的信息。包括了用戶參與的需求分析迭代會議，則可適時地作出review，避免錯誤的擴大和帶入下次迭代。
3.3 需求分析時機
傳統的需求分析時機集中在項目前期，總是遵循前期調研—分析—需求定義，轉給開發后需求工作便就此結束，其思想里，便是一次性完整、清楚地做完所有層次的需求，并在整個過程中遵循計劃。
敏捷需求分析對這種慣例做出調整，源于其認為：需求的逐步細化過程中，變更是不可避免的；同時，為了快速的商業響應，保證能產出可見、可執行的結果也是必要的。后續的迭代和持續集成保證了需求的演進路線，簡言之，需求分析貫穿于項目的整個生命周期。
3.4 需求的劃分
開發人員總是希望能明確地知道系統分幾個模板，功能是什么，但這些信息并不是需求的本身。基于模塊和功能分解，專門的需求分析人員會使之流于粗放——這種情況是最多見的，功能劃分使需求單位粒度較大，不足以描述其特征；而傳統由開發人員來做的分析，往往會越過業務價值層面而轉入底層的設計。
敏捷需求分析中的劃分，將以獨立業務價值為基礎，劃分為一個個用戶故事（可以去類比理解UP意義上的use case），它可以是很小顆粒的業務與特征集，也可能會跨越傳統的子模塊邊界。用戶故事以參與者為中心，描述了參與者“作為（系統的一個涉眾），想要（做一件事），從而（達到一個業務價值）”的集合。用戶故事是可見的業務價值，而不是功能描述。每個用戶故事的粒度和開發工作量都相差不多，這是其與用例的區別。以此構建的測例，將指導測試與需求驗證。
3.5 敏捷需求分析與細化過程
迭代是敏捷需求分析與細化過程中最顯著的方式。迭代的特征包含如前文所述的兩部分：全生命過程、小粒度的以業務價值為基礎的劃分。Robert C. Martin認為每一次迭代都是一個完整的項目產品[3]，換言之，迭代是要產生最終產品的反復[4]，也就是說你的一次一次的反復必須都能產生最終的產品，而不是中間的半成品。這也反映了需求劃分的原則，以及每一次小的迭代，其結果都是可確認的。因此，迭代過程中重要的一種方法是分解，以及關注于當前價值實現的部分。如果一個需求暫時不能被理解并且與當前的商業目標的關系并不那么直接，那么它應該被分解和延后，而不是草草地做一個似是而非的大方案而囊括之。
迭代是一種快速反應和逐步確認成果的方式。敏捷意味著快速反應、注重核心價值， 但并不是要求每件事都盡快地完成和提交。迭代計劃的依據便是優先級的確定。因此，迭代的實施要求正確引導客戶劃分優先級，實施逐步的集成改進。必要時，項目上線也是可以逐步推行的，因為僅僅上線并不意味著價值的實現。
傳統的需求分析總是希望能一定完成所有的事情以便于直接作出功能劃分和設計，但這在我們以往經歷的項目實踐中遇到了挑戰，不得不把項目的需求分析肢解成似乎是多個不同項目的需求集合。敏捷而持續的過程，對此作出修正。
3.6 文檔與變更
正如Martin對那種什么文檔也不寫就自稱為敏捷的善意批評，敏捷過程對文檔的態度只是一種思想的轉變，而非重型的過程控制要求。敏捷方法需要兩種類型的文檔，它們分別是需求文檔和設計文檔，而其它所有類型的文檔都是選擇性的。對于需求文檔，在敏捷方法中，往往會在某次迭代之中進行。它經常先于其他開發過程，但也要到開發過程的迭代開始的時候才在內容上達到完整。對于暫時不做的開發，就不會做細部特征的定義，以免浪費。撰寫文檔，其實是一件頗耗精力的事情，所以選擇做什么樣的文檔需要有一種“投資回報”的考慮。
傳統的大量正式文檔，規格嚴整而厚重，但在項目的中后期卻往往不能保持同步（現狀、文檔之間以及與軟件系統），難以維護和跟蹤，生產和維護成本也很高。這些文檔除表明需求本身外，更多地是一種管理控制的角色，比如，對于變更。
敏捷過程并不是由文檔主導、支撐和控制變更。如《敏捷宣言》中所透露的“響應變化勝過遵循計劃” ，對于變更，敏捷過程是一個態度的轉變。變更除過軟件工程組織或者PMI等定義大部分類似于由“工作缺陷”引起的以外，在現代信息化競爭時代，它往往意味著商機。當然，對于這種商機的“歡迎”，企業需要商務模式的準備，否則將極易陷入“需求黑洞”之中。
3.7 敏捷需求分析小結
綜合以上的陳述，對敏捷需求分析歸納如下表（角色職責的變化也是一種重要的對比，請參見表1，此處不贅言）：
| 角度 | 傳統需求分析 | 敏捷需求分析 |
| 需求分析時機 | 更多地集中在項目早期 | 近乎均勻地貫穿于項目的整個生命周期 |
| 需求劃分單位 | 基于功能分解，劃分模塊或子系統，一個模塊或子系統的顆粒度通常較大 | 基于能否獨立業務價值，切割成一個個用戶故事，一個故事有時會跨越傳統的模塊或子系統邊界；用戶故事是小粒度的，可測試的，可見的，并且是有價值 |
| 需求細化過程 | 一步到位，可供開發人員設計開發 | 逐步細化，僅就下一個迭代需要實現的部分進行詳細分析 |
| 需求文檔要求 | 正式文檔，往往有明確的格式要求。既作為設計開發人員必須嚴格遵守的規約，也作為向客戶提交的必備產出物之一。難維護，難驗證（跟蹤），很多產出物最終難以被閱讀。 | 非正式文檔。僅僅是輔助開發團隊與客戶溝通，不作為規約，也不作為必備產出物。更多強調通過自動化功能測試用例來跟蹤系統需求。（對于組織過程資產管理要求，可以在此基礎上形成可閱讀可理解的輕型文檔）。 |
| 需求文檔同步 | 項目中后期一般都處于不同步狀態 | 即時的同步 |
| 需求傳遞過程 | 單向的陳述與記錄，文檔傳導（線性的傳遞，誤導放大，緩慢） | 聚議，共同參與，業務場景與用戶故事，及時的非正式溝通 |
| 應對需求變更 | 有嚴格的控制流程，視變更為風險 | 視變更為必然或預期中的事情 |
表2：敏捷需求分析的特征對比
4、應用敏捷需求分析的質量保證
一個傳統的軟件實現過程，遵循計劃與嚴格的控制來保證質量。管理手段的控制有時不能及時糾正工程領域的偏差，即使控制體系給了更多的回饋機制，實質上更多地只是增加了信息層級和復雜度。
一個典型的缺陷放大過程如下圖所示：
圖2：軟件實現各階段的缺陷放大
敏捷需求分析參與生命周期的迭代，而每一次迭代都是一個完整的過程，并產生項目交付品，而在下一個迭代之前，其交付品都是可用的。這種方法能有效地及時調整，從源頭消除可能被放大的缺陷。
敏捷過程中，需要BA、QA的全程參與（當然，在企業實踐中，可能存在著職能劃分的現狀。從更有效的角度看，由于項目經理參與了項目全生命周期，尤其是對需求管理的全過程的跟蹤，項目經理擔任某一項目的BA角色，也是現實可行的，其優點是可以保證有及時的客戶溝通、長期而細致的跟蹤），保證需求能始終被正確地理解、傳遞和驗證。從敏捷需求出發導出的場景擬合驗收測試，能從更廣闊的層級（業務價值視角）來驗證需求的達成性而不僅僅是軟件的可用性等指標。這對質量保證是一個提高。迭代演進中應對需求變更，是從客戶視野上的更高的質量改進。
5、總論
敏捷過程是一種結合管理理念與工程方法的最佳實踐，它關注人的價值，倡導客戶合作與響應變化，是中小企業持續過程改進的最有效途徑之一。敏捷過程意味著全過程的敏捷，而不僅僅只是片面理解諸如XP、Scrum等方法而局限于開發環節。這其中，敏捷需求分析構成了方法體系的重要因素，它以溝通、迭代、響應變化、獨立業務價值導出的可見的用例等特征，貫穿于產品全生命周期。
在電信業競爭態勢與管理細化背景下，將出現需求迭出但保持持續演進的特征。應用敏捷過程方法論，結合CMMI體系的適度裁剪與敏捷化，化變化為商機，關注商業價值，是應對挑戰的有效方法。