敏捷過程中的軟件需求分析(2)

這引發了我們進入詳細的敏捷需求分析話題中第一個問題，需求的參與者如何定義？
3.1需求的參與者
敏捷需求分析過程的參與者，包括客戶/用戶、需求分析人員（業界一般也稱之為商務分析師或業務分析師，business analyst，本文并不討論詞匯的細致差異，下文統一簡稱BA）、開發人員、測試人員，其他相關的角色有項目管理者等。在《敏捷宣言》（Manifesto for Agile Software Development）中[3]，強調了客戶一起現場工作的重要性。而在企業實際的實施過程中，由于限制，項目經理及實施人員，以及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需求分析時機
傳統的需求分析時機集中在項目前期，總是遵循前期調研—分析—需求定義，轉給開發后需求工作便就此結束，其思想里，便是一次性完整、清楚地做完所有層次的需求，并在整個過程中遵循計劃。
敏捷需求分析對這種慣例做出調整，源于其認為：需求的逐步細化過程中，變更是不可避免的；同時，為了快速的商業響應，保證能產出可見、可執行的結果也是必要的。后續的迭代和持續集成保證了需求的演進路線，簡言之，需求分析貫穿于項目的整個生命周期。

原文轉自：http://www.anti-gravitydesign.com