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