敏捷過程中的需求分析

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

2、MBOSS,也已初具規(guī)模和成效.大規(guī)模實(shí)施的下一個(gè)階段,將是在商業(yè)價(jià)值引領(lǐng)下的重構(gòu)競爭模式、市場細(xì)分,以及作為支撐的需求深入研究.在工程實(shí)施過程中,各種挑戰(zhàn)和困難紛至沓來,工程治理者不管是做時(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)整的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17、劃分使需求單位粒度較大,缺乏以描述其特征；而傳統(tǒng)由開發(fā)人員來做的分析,往往會(huì)越過業(yè)務(wù)價(jià)值層面而轉(zhuǎn)入底層的設(shè)計(jì).敏捷需求分析中的劃分,將以獨(dú)立業(yè)務(wù)價(jià)值為根底,劃分為一個(gè)個(gè)用戶故事可以去類比理解UP意義上的usecase,它可以是很小顆粒的業(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ì)化過程中最顯著的方式.迭代的

18、特征包含如前文所述的兩局部全生命過程、小粒度的以業(yè)務(wù)價(jià)值為根底的劃分.RobertC.Martin認(rèn)為每一次迭代都是一個(gè)完整的工程產(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è)似是而非的大方案而囊括之.迭代是一種快速反響和逐步確認(rèn)成果的方式.敏捷意味著快速反響、注重核心價(jià)值,但并不是要

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

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

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

22、用戶故事是小粒度的,可測試的,可見的,并且是有價(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)需求.對于組織過程資產(chǎn)治理要求,可以在此根底上形成可閱讀可理解的輕型文檔.需求文檔同步工程中后期一般都處于不同步狀態(tài)即時(shí)的同步需求傳遞單向的陳述與記錄,文檔傳導(dǎo)線性的傳聚議,共同參與,業(yè)務(wù)場景與用戶故事,及時(shí)的非過程遞,誤導(dǎo)放大,緩慢正式溝通應(yīng)對需求變更有嚴(yán)格的限制流程,視變更為風(fēng)險(xiǎn)視變更為必然或預(yù)期中的事情表2:敏捷需求分析的特征比照