敏捷過程中的需求分析

1、【摘要】在日趨劇烈的電信業(yè)競爭態(tài)勢下,持續(xù)而快速地開掘和響應商機成為新的課題.作為響應機制中的關鍵環(huán)節(jié),需求工程應用敏捷過程方法,以關注商業(yè)價值、快速響應、持續(xù)迭代的特征來應對變化和難測的未來,是嘗試提升組織敏捷水平的核心.在這其中,作為溝通橋梁的需求分析同樣可以應用敏捷的過程方法參與到生命周期的演進.敏捷需求分析將在需求時機與過程、文檔要求、變更、參與者角色等方面展現(xiàn)其不同傳統(tǒng)的特性.本文將結合電信業(yè)背景及企業(yè)實際情況,對敏捷需求分析作出初步的探索.1、敏捷需求分析：電信行業(yè)背景與敏捷過程的需要從中國電信行業(yè)ITSP戰(zhàn)略推出至今,數(shù)年中我們已經(jīng)看到了明顯的變化,作為其信息化體系落地的CTG-

2、MBOSS,也已初具規(guī)模和成效.大規(guī)模實施的下一個階段,將是在商業(yè)價值引領下的重構競爭模式、市場細分,以及作為支撐的需求深入研究.在工程實施過程中,各種挑戰(zhàn)和困難紛至沓來,工程治理者不管是做時間、本錢、質(zhì)量的三角平衡,還是人與技術的雙向選擇,始終無法繞開的一個問題跟源是：如何快速響應環(huán)境的變化,使客戶在優(yōu)化的體驗過程中滿足其商業(yè)目標,從而實現(xiàn)企業(yè)本身的價值？用失控的過程膨脹來形容近10年的許多軟件公司的情形是很適宜的.雖然有很多團隊在工作中沒有使用過程的方法,但是采用龐大、重型的過程方法的趨勢卻在快速增長,在大公司中尤為如此.但現(xiàn)實的發(fā)展確與此不相同步,競爭態(tài)勢造成了更多的不確定性和快速調(diào)整的

3、時機.從近年ERP上線的平均速度來看,工程的交付時間都比擬長,這讓用戶產(chǎn)生了顧慮.但實際上軟件上線僅僅是一個軟件生命周期早期的階段,軟件的價值是在使用中表達出來的,其投資回報也只能在后期的運營得到完成.未來的變化如同納西姆？塔勒布的黑天鵝一般不可預測且重要,和過去瑣碎的重復并缺乏以預測未來的重大影響.以預測性度量為限制根底的過程模型,只能以經(jīng)驗涵蓋一般性事件,所以與此同時,隨機應變,保持快速集成和持續(xù)改良以應對商業(yè)環(huán)境的不確定性,延長軟件的生命周期提升它的最大價值,從而為獲取更多投資回報提供保證,也成為軟件工程開展的必然.敏捷過程(AgileProcess)的主要優(yōu)勢是能夠適應系統(tǒng)需求的不確定

4、性,將客戶作為需求團隊中密不可分的成員,而在實現(xiàn)過程中盡量在最短時間內(nèi)實現(xiàn)對用戶來說業(yè)務價值最大的需求；同時,敏捷開發(fā)(AgileDevelopment)是一種面臨迅速變化的需求快速開發(fā)軟件的水平,它幫助處理了未來不確定性的問題；但是對于過去,應該沒有不確定的事.而敏捷需求分析,是面對迅速變化的商業(yè)狀況,提升其響應和組織成可理解和接受的需求說明并對敏捷開發(fā)作出水平保證的方法論.2、敏捷與過程改良和度量模型從軟件工程開展起,過程改良在全球日益得到重視,ISO9000/SW-CMM/CMMI各級的評估也在業(yè)界得以推展,這種氣氛下,以RUP等為代表的過程模型也得到了廣泛的應用.但與此同時,敏捷的論調(diào)

5、卻異軍突起,方興未艾.軟件過程的多樣性,源于過程環(huán)境和層次的不同；而過程選擇的多樣性和CMMI目標的通用性決定了過程改良途徑的多樣化.運用一系列重方法,將在應對商機方面造成挑戰(zhàn)；尤其是在企業(yè)的治理考核和過程模板仍更多的是一種瀑布式體系下,軟件的實現(xiàn)過程將在不同模型下?lián)u擺卻顯得不那么靈活.一個適宜的生命周期模型選擇是重要的,由于慣性的教育,瀑布在我們的工作環(huán)境中隨處可見.但如果不去分析CMMI等的實質(zhì),將無助于改良這一點而提升響應.強調(diào)結構化方法與重型的治理策略,往往在內(nèi)心中拒絕變更,把變更作為被治理甚至被管制的對象；而為了盡可能防止變更,常常要求開發(fā)之前的需求獲取、分析與定義要完整無誤且精確.

6、這是一種理論上的理想狀態(tài),盡管我們可以采取諸如CMMI的一些理念及過程改良模板對其治理,但實際上往往會出現(xiàn)與用戶商業(yè)價值要求的脫節(jié)；而為達成此目標,使得前期的需求開發(fā)工作變得小心翼翼,最終有可能在壓力與時間約束下難免簡單化而草草了事,在后期又不能得到及時的修正,從而形成一個隱患.但實質(zhì)上,重型、輕型過程方法論之間并不存在根本性的矛盾沖突,這表達于它們最終理念和出發(fā)點的一致.把這些互補方法論拼在一起,恰好可以發(fā)現(xiàn)整個軟件過程體系全貌的一局部CMM/CMMI中不包括更為具體一點的如何寫好需求,如何做好設計,如何寫好測試等許多方面的軟件工程技術、技能方面的指導,而這些恰好是敏捷的強項.敏捷方法整合了

7、一套輕量的治理、過程和工程技術方法,這是它作為一種先進方法體系補充于CMMI的地方.敏捷過程并不像業(yè)界所傳的那樣只適合小工程和新工程的研發(fā),實際上它對于各種類型,包括企業(yè)所定義的A類、B類、C類在CMMI體系根底上都是可取舍適用的.這需要過程體系間的適當裁剪和調(diào)整組合.敏捷需求分析,將在全過程中扮演銜接、溝通和滲透的作用.3、敏捷需求分析的過程特性IEEE對需求的定義是用戶解決問題或到達目標所需的條件或性能；系統(tǒng)或系統(tǒng)部件要滿足合同、標準或其他正式規(guī)定文檔的條件或性能.需求是設計、構造產(chǎn)品的前提,簡單地說,是必須完成的事及其所必須具備的品質(zhì).需求存在的原因要么是該類型的產(chǎn)品要求一定的功能和品質(zhì)

8、,要么是客戶希望需求成為提交的產(chǎn)品的一局部5.軟件需求包括三個不同的層次一業(yè)務需求、用戶需求和功能需求一也包括非功能需求.業(yè)務需求(businessrequirement)反映了組織機構或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求,它們在工程視圖與范圍文檔中予以說明.用戶需求(userrequirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務,這在使用用例(usecase)文檔或方案腳本(scenario)說明中予以說明.功能需求(functionalrequirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能,使得用戶能完成他們的任務,從而滿足了業(yè)務需求.所謂特性(feature)是指邏輯上相關的功能

9、需求的集合,給用戶提供處理水平并滿足業(yè)務需求.圖1.需求的層次及組成我們可以看到,不管是傳統(tǒng)的還是敏捷的需求開發(fā)階段,需求的層級及組成,其根本特性是一致的,這反映方法的差異并不改變需求的本身屬性.一般的需求三個層次,忽略了一個問題,即每個層次所需的知識、技能、經(jīng)驗、背景等是不同的,不同的層次過程中,需要不同資源的整合.業(yè)界相關的論述中,只是給出了籠統(tǒng)的需求分析人員的統(tǒng)一角色,但并未對其作出區(qū)別.實際上,這很難映射到中小企業(yè)的現(xiàn)實操作層面.這引發(fā)了我們進入詳細的敏捷需求分析話題中第一個問題,需求的參與者如何定義？3.1 需求的參與者敏捷需求分析過程的參與者,包括客戶/用戶、需求分析人員(業(yè)界一般

10、也稱之為商務分析師或業(yè)務分析師,businessanalyst,本文并不討論詞匯的細致差異,下文統(tǒng)一簡稱BA)、開發(fā)人員、測試人員,其他相關的角色有工程治理者等.在?敏捷宣言?(ManifestoforAgileSoftwareDevelopment)中,強調(diào)了客戶一起現(xiàn)場工作的重要性.而在企業(yè)實際的實施過程中,由于限制,工程經(jīng)理及實施人員,以及BA如果有的話,在虛擬團隊中,他們演繹客戶的角色,從而使得客戶也更好地納入到了工程團隊中.但應該清楚,這種納入并不能真正代替真實的客戶參與.對于客戶無法全程現(xiàn)場參與的情況,BA的出現(xiàn)是一種彌補.BA最重要的責任就是與客戶交談,了解和分析需求,將其制作成

11、用戶故事(userstory)并將需求傳遞給開發(fā)人員.同時,BA也要在某種參與度較深的情況下代替客戶負責功能驗收測試(Acceptancetest.而對內(nèi),BA顯然扮演了客戶,那么除了需求提供者的責任,如果需要的話,相應地也要有評價和驗收否決的權利.當然,這項工作可以分解為另外的角色來進行.開發(fā)、測試人員進入需求團隊,便于他們理解用戶故事或者典型的RUP式的用例.一個完整描述的用例可以很方便地導出測例testcase.而用例和測例是一致的,它描述在一個具體業(yè)務場景中可見的需求特征.我們可以根據(jù)這樣的可見性寫出功能測試,從而驅(qū)動這個用戶故事的開發(fā),這被稱為AcceptanceDrivenDeve

12、lopment.從整個過程來說,分析和實現(xiàn)的過程就是場景擬合和檢驗,以及類似于XP中結對式的及時糾偏.各種角色的積極參與在不同角度和層次下的場景擬合,說明需求不是程序員的事情,也不是寄望于抽象出一個BA的角色甚至實例化為一個職位,就可以全能地做出需求定義.對于角色及其參與方式,我們可以比擬如下:角色及責任傳統(tǒng)的需求參與敏捷的需求參與用戶/客戶需求的提供者需求演進的參與者用戶的主要參與方式陳述遵循游戲規(guī)那么的積極的交互參與BA需求的定義者需求的組織者BA的主要參與方式前期的調(diào)查獲取和整理成文檔參與全周期的迭代與演進開發(fā)需求的接受者和實現(xiàn)者場景擬合者與改良者開發(fā)的主要參與方式被傳導需求并使之功能化

13、完成完整的業(yè)務場景實現(xiàn)測試功能測試者場景測試者需求測試者測試的主要參與方式找出軟件的顯性的bug找出不滿足需求邏輯和不能擬合場景的缺陷表1:需求的主要參與者其他的stakeholders并未全部列出,比方PM、QA等這些參與者如何工作的呢？我們引入到需求分析的工作形式.3.2 敏捷需求分析工作形式敏捷宣言強調(diào)了客戶在一起工作的重要,敏捷是大家在一起高效率地工作,清楚所有溝通上的障礙,關注于增值的活動,從而使得工程更加成功.比方,敏捷聯(lián)盟所推薦的現(xiàn)場客戶工作.但多數(shù)情況下,客戶都是很忙碌的,很難全力投入到過程中.這時候,我們就需要BA這個角色,來充當客戶的角色.BA的參與使他變成了需求的組織者,

14、需要使需求分析過程中具備資源快速聚合的水平.而工作方式,在傳統(tǒng)之外,可以使用聚議和需求迭代方案會議的形式.敏捷思想的核心是人與人的交流.聚議是一種面對面的最好形式,它能促成問題從多個角度的現(xiàn)場核清.在前期的高層訪談之后,需求分析過程中至少要有以下的準備：1明確業(yè)務價值及其所推導的業(yè)務場景；2范圍劃分使得每個議題都有獨立的業(yè)務價值,對于大而籠統(tǒng)的需求,那么分解或置入下次迭代,而本次完成的將是一個相對完整的結果.對于需求分析中所用的各種形式,用戶其實并不排斥參與一一尤其是當他掌握了一定方法并能看到迅速回應帶來的好處時,將極大地提升這種興趣.在某省電信運營商的工程中,我們已經(jīng)發(fā)現(xiàn)了這一點.用戶明白積

15、極參與的好處時,能主動從業(yè)務角度審視自己的需求,刪減調(diào)整并作出易理解的文檔.在一個已經(jīng)實施的工程中做增量改良時,用戶參與尤為重要,并且能局部地把前端人員從繁瑣而低效的溝通其實只是傳話筒和文檔化中解脫出來.迭代是敏捷最顯著的形式,而迭代的前提,那么是對業(yè)務價值分解為用戶故事的工作.這些將在下文中討論.迭代方案會議是一種需求組織方式,在每個迭代開始的時候,由BA主持召開迭代方案會議,在會議上向開發(fā)人員解釋這個迭代要完成的用戶故事,然后由開發(fā)人員自由提問,知道他們能夠獲得足夠開始實現(xiàn)該功能的信息.包括了用戶參與的需求分析迭代會議,那么可適時地作出review,防止錯誤的擴大和帶入下次迭代.3.3 需

16、求分析時機傳統(tǒng)的需求分析時機集中在工程前期,總是遵循前期調(diào)研一分析一需求定義,轉(zhuǎn)給開發(fā)后需求工作便就此結束,其思想里,便是一次性完整、清楚地做完所有層次的需求,并在整個過程中遵循方案.敏捷需求分析對這種慣例做出調(diào)整,源于其認為：需求的逐步細化過程中,變更是不可防止的；同時,為了快速的商業(yè)響應,保證能產(chǎn)出可見、可執(zhí)行的結果也是必要的.后續(xù)的迭代和持續(xù)集成保證了需求的演進路線,簡言之,需求分析貫穿于工程的整個生命周期.3.4 需求的劃分開發(fā)人員總是希望能明確地知道系統(tǒng)分幾個模板,功能是什么,但這些信息并不是需求的本身.基于模塊和功能分解,專門的需求分析人員會使之流于粗放一一這種情況是最多見的,功能

17、劃分使需求單位粒度較大,缺乏以描述其特征；而傳統(tǒng)由開發(fā)人員來做的分析,往往會越過業(yè)務價值層面而轉(zhuǎn)入底層的設計.敏捷需求分析中的劃分,將以獨立業(yè)務價值為根底,劃分為一個個用戶故事可以去類比理解UP意義上的usecase,它可以是很小顆粒的業(yè)務與特征集,也可能會跨越傳統(tǒng)的子模塊邊界.用戶故事以參與者為中央,描述了參與者作為系統(tǒng)的一個涉眾,想要做一件事,從而到達一個業(yè)務價值的集合.用戶故事是可見的業(yè)務價值,而不是功能描述.每個用戶故事的粒度和開發(fā)工作量都相差不多,這是其與用例的區(qū)別.以此構建的測例,將指導測試與需求驗證.3.5 敏捷需求分析與細化過程迭代是敏捷需求分析與細化過程中最顯著的方式.迭代的

18、特征包含如前文所述的兩局部全生命過程、小粒度的以業(yè)務價值為根底的劃分.RobertC.Martin認為每一次迭代都是一個完整的工程產(chǎn)品3,換言之,迭代是要產(chǎn)生最終產(chǎn)品的反復4,也就是說你的一次一次的反復必須都能產(chǎn)生最終的產(chǎn)品,而不是中間的半成品.這也反映了需求劃分的原那么,以及每一次小的迭代,其結果都是可確認的.因此,迭代過程中重要的一種方法是分解,以及關注于當前價值實現(xiàn)的局部.如果一個需求暫時不能被理解并且與當前的商業(yè)目標的關系并不那么直接,那么它應該被分解和延后,而不是草草地做一個似是而非的大方案而囊括之.迭代是一種快速反響和逐步確認成果的方式.敏捷意味著快速反響、注重核心價值,但并不是要

19、求每件事都盡快地完成和提交.迭代方案的依據(jù)便是優(yōu)先級確實定.因此,迭代的實施要求正確引導客戶劃分優(yōu)先級,實施逐步的集成改良.必要時,工程上線也是可以逐步推行的,由于僅僅上線并不意味著價值的實現(xiàn).傳統(tǒng)的需求分析總是希望能一定完成所有的事情以便于直接作出功能劃分和設計,但這在我們以往經(jīng)歷的工程實踐中遇到了挑戰(zhàn),不得不把工程的需求分析肢解成似乎是多個不同工程的需求集合.敏捷而持續(xù)的過程,對此作出修正.3.6 文檔與變更正如Martin對那種什么文檔也不寫就自稱為敏捷的善意批評,敏捷過程對文檔的態(tài)度只是一種思想的轉(zhuǎn)變,而非重型的過程限制要求.敏捷方法需要兩種類型的文檔,它們分別是需求文檔和設計文檔,而

20、其它所有類型的文檔都是選擇性的.對于需求文檔,在敏捷方法中,往往會在某次迭代之中進行.它經(jīng)常先于其他開發(fā)過程,但也要到開發(fā)過程的迭代開始的時候才在內(nèi)容上到達完整.對于暫時不做的開發(fā),就不會做細部特征的定義,以免浪費.撰寫文檔,其實是一件頗耗精力的事情,所以選擇做什么樣的文檔需要有一種投資回報的考慮.傳統(tǒng)的大量正式文檔,規(guī)格嚴整而厚重,但在工程的中后期卻往往不能保持同步現(xiàn)狀、文檔之間以及與軟件系統(tǒng),難以維護和跟蹤,生產(chǎn)和維護本錢也很高.這些文檔除說明需求本身外,更多地是一種治理限制的角色,比方,對于變更.敏捷過程并不是由文檔主導、支撐和限制變更.如?敏捷宣言?中所透露的響應變化勝過遵循方案,對于

21、變更,敏捷過程是一個態(tài)度的轉(zhuǎn)變.變更除過軟件工程組織或者PMI等定義大局部類似于由工作缺陷引起的以外,在現(xiàn)代信息化競爭時代,它往往意味著商機.當然,對于這種商機的歡送,企業(yè)需要商務模式的準備,否那么將極易陷入需求黑洞之中.3.7 敏捷需求分析小結綜合以上的陳述,對敏捷需求分析歸納如下表角色責任的變化也是一種重要的比照,請參見表1,此處不贅言：角度傳統(tǒng)需求分析敏捷需求分析需求分析時機更多地集中在工程早期近乎均勻地貫穿于工程的整個生命周期需求劃分單位基于功能分解,劃分模塊或子系統(tǒng),一個模塊或子系統(tǒng)的顆粒度通常較大基于能否獨立業(yè)務價值,切割成一個個用戶故事,一個故事有時會跨越傳統(tǒng)的模塊或子系統(tǒng)邊界；

22、用戶故事是小粒度的,可測試的,可見的,并且是有價值需求細化過程一步到位,可供開發(fā)人員設計開發(fā)逐步細化,僅就下一個迭代需要實現(xiàn)的局部進行詳細分析需求文檔要求正式文檔,往往有明確的格式要求.既作為設計開發(fā)人員必須嚴格遵守的規(guī)約,也作為向客戶提交的必備產(chǎn)出物之一.難維護,難驗證跟蹤,很多產(chǎn)出物最終難以被閱讀.非正式文檔.僅僅是輔助開發(fā)團隊與客戶溝通,不作為規(guī)約,也不作為必備產(chǎn)出物.更多強調(diào)通過自動化功能測試用例來跟蹤系統(tǒng)需求.對于組織過程資產(chǎn)治理要求,可以在此根底上形成可閱讀可理解的輕型文檔.需求文檔同步工程中后期一般都處于不同步狀態(tài)即時的同步需求傳遞單向的陳述與記錄,文檔傳導線性的傳聚議,共同參與,業(yè)務場景與用戶故事,及時的非過程遞,誤導放大,緩慢正式溝通應對需求變更有嚴格的限制流程,視變更為風險視變更為必然或預期中的事情表2:敏捷需求分析的特征比照