敏捷過程中的需求分析(編輯修改稿)
2025-09-01 07:05 本頁面
【文章內容簡介】 開發(fā)人員。同時，BA也要在某種參與度較深的情況下代替客戶負責功能驗收測試（Acceptance test）。而對內，BA顯然扮演了客戶，那么除了需求提供者的職責，如果需要的話，相應地也要有評價和驗收否決的權利。當然，這項工作可以分解為另外的角色來進行?！ ￠_發(fā)、測試人員進入需求團隊，便于他們理解用戶故事或者典型的RUP式的用例。一個完整描述的用例可以很方便地導出測例（test case）。而用例和測例是一致的，它描述在一個具體業(yè)務場景中可見的需求特征。我們可以根據(jù)這樣的可見性寫出功能測試，從而驅動這個用戶故事的開發(fā)，這被稱為 Acceptance Driven Development。從整個過程來說，分析和實現(xiàn)的過程就是場景擬合和檢驗，以及類似于XP中結對式的及時糾偏。各種角色的積極參與在不同角度和層次下的場景擬合，表明需求不是程序員的事情，也不是寄望于抽象出一個BA的角色甚至實例化為一個職位，就可以全能地做出需求定義?！ τ诮巧捌鋮⑴c方式，我們可以比較如下：角色及職責傳統(tǒng)的需求參與敏捷的需求參與用戶/客戶需求的提供者需求演進的參與者用戶的主要參與方式陳述遵循游戲規(guī)則的積極的交互參與BA需求的定義者需求的組織者BA的主要參與方式前期的調查獲取和整理成文檔參與全周期的迭代與演進開發(fā)需求的接受者和實現(xiàn)者場景擬合者與改進者開發(fā)的主要參與方式被傳導需求并使之功能化完成完整的業(yè)務場景實現(xiàn)測試功能測試者場景測試者（需求測試者）測試的主要參與方式找出軟件的顯性的bug找出不滿足需求邏輯和不能擬合場景的缺陷表1：需求的主要參與者 ?。ㄆ渌膕takeholders并未全部列出，比如PM、QA等） 這些參與者如何工作的呢？我們引入到需求分析的工作形式?！ ?敏捷需求分析工作形式 敏捷宣言強調了客戶在一起工作的重要，敏捷是大家在一起高效率地工作，清楚所有溝通上的障礙，關注于增值的活動，從而使得項目更加成功。比如，敏捷聯(lián)盟所推薦的現(xiàn)場客戶工作。但多數(shù)情況下，客戶都是很忙碌的，很難全力投入到過程中。這時候，我們就需要BA這個角色，來充當客戶的角色?！ A的參與使他變成了需求的組織者，需要使需求分析過程中具備資源快速聚合的能力。而工作方式，在傳統(tǒng)之外，可以使用聚議和需求迭代計劃會議的形式。 敏捷思想的核心是人與人的交流。聚議是一種面對面的最好形式，它能促成問題從多個角度的現(xiàn)場核清。在前期的高層訪談之后，需求分析過程中至少要有以下的準備：（1）明確業(yè)務價值及其所推導的業(yè)務場景；（2）范圍劃分使得每個議題都有獨立的業(yè)務價值，對于大而籠統(tǒng)的“需求”，則分解或置入下次迭代，而本次完成的將是一個相對完整的結果。對于需求分析中所用的各種形式，用戶其實并不排斥參與——尤其是當他掌握了一定方法并能看到迅速回應帶來的好處時，將極大地提升這種興趣。在某省電信運營商的項目中，我們已經(jīng)發(fā)現(xiàn)了這一點。用戶明白積極參與的好處時，能主動從業(yè)務角度審視自己的需求，刪減調整并作出易理解的文檔。在一個已經(jīng)實施的項目中做增量改進時，用戶參與尤為重要，并且能部分地把前端人員從繁瑣而低效的溝通（其實只是“傳話筒”）和文檔化中解脫出來?！ 〉敲艚葑铒@著的形式，而迭代的前提，則是對業(yè)務價值分解為用戶故事的工作。這些將在下文中討論。迭代計劃會議是一種需求組織方式，在每個迭代開始的時候，由BA主持召開迭代計劃會議，在會議上向開發(fā)人員解釋這個迭代要完成的用戶故事，然后由開發(fā)人員自由提問，知道他們能夠獲得足夠開始實現(xiàn)該功能的信息。包括了用戶參與的需求分析迭代會議，則可適時地作出revi
法律信息相關推薦
鄂ICP備17016276號-1