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

3.4需求的劃分
開發人員總是希望能明確地知道系統分幾個模板，功能是什么，但這些信息并不是需求的本身?；谀K和功能分解，專門的需求分析人員會使之流于粗放——這種情況是最多見的，功能劃分使需求單位粒度較大，不足以描述其特征；而傳統由開發人員來做的分析，往往會越過業務價值層面而轉入底層的設計。
敏捷需求分析中的劃分，將以獨立業務價值為基礎，劃分為一個個用戶故事（可以去類比理解UP意義上的use case），它可以是很小顆粒的業務與特征集，也可能會跨越傳統的子模塊邊界。用戶故事以參與者為中心，描述了參與者“作為（系統的一個涉眾），想要（做一件事），從而（達到一個業務價值）[7]”的集合。用戶故事是可見的業務價值，而不是功能描述。每個用戶故事的粒度和開發工作量都相差不多，這是其與用例的區別。以此構建的測例，將指導測試與需求驗證。
3.5敏捷需求分析與細化過程
迭代是敏捷需求分析與細化過程中最顯著的方式。迭代的特征包含如前文所述的兩部分：全生命過程、小粒度的以業務價值為基礎的劃分。Robert C. Martin認為每一次迭代都是一個完整的項目產品[3]，換言之，迭代是要產生最終產品的反復[4]，也就是說你的一次一次的反復必須都能產生最終的產品，而不是中間的半成品。這也反映了需求劃分的原則，以及每一次小的迭代，其結果都是可確認的。因此，迭代過程中重要的一種方法是分解，以及關注于當前價值實現的部分。如果一個需求暫時不能被理解并且與當前的商業目標的關系并不那么直接，那么它應該被分解和延后，而不是草草地做一個似是而非的大方案而囊括之。
迭代是一種快速反應和逐步確認成果的方式。敏捷意味著快速反應、注重核心價值， 但并不是要求每件事都盡快地完成和提交。迭代計劃的依據便是優先級的確定。因此，迭代的實施要求正確引導客戶劃分優先級，實施逐步的集成改進。必要時，項目上線也是可以逐步推行的，因為僅僅上線并不意味著價值的實現。
傳統的需求分析總是希望能一定完成所有的事情以便于直接作出功能劃分和設計，但這在我們以往經歷的項目實踐中遇到了挑戰，不得不把項目的需求分析肢解成似乎是多個不同項目的需求集合。敏捷而持續的過程，對此作出修正。
3.6文檔與變更
正如Martin對那種什么文檔也不寫就自稱為敏捷的善意批評[3]，敏捷過程對文檔的態度只是一種思想的轉變，而非重型的過程控制要求。敏捷方法需要兩種類型的文檔，它們分別是需求文檔和設計文檔，而其它所有類型的文檔都是選擇性的。對于需求文檔，在敏捷方法中，往往會在某次迭代之中進行。它經常先于其他開發過程，但也要到開發過程的迭代開始的時候才在內容上達到完整。對于暫時不做的開發，就不會做細部特征的定義，以免浪費。撰寫文檔，其實是一件頗耗精力的事情，所以選擇做什么樣的文檔需要有一種“投資回報”的考慮。
傳統的大量正式文檔，規格嚴整而厚重，但在項目的中后期卻往往不能保持同步（現狀、文檔之間以及與軟件系統），難以維護和跟蹤，生產和維護成本也很高。這些文檔除表明需求本身外，更多地是一種管理控制的角色，比如，對于變更。
敏捷過程并不是由文檔主導、支撐和控制變更。如《敏捷宣言》中所透露的“響應變化勝過遵循計劃” [3]，對于變更，敏捷過程是一個態度的轉變。變更除過軟件工程組織或者PMI等定義大部分類似于由“工作缺陷”引起的以外，在現代信息化競爭時代，它往往意味著商機。當然，對于這種商機的“歡迎”，企業需要商務模式的準備，否則將極易陷入“需求黑洞”之中。
3.7敏捷需求分析小結
綜合以上的陳述，對敏捷需求分析歸納如下表（角色職責的變化也是一種重要的對比，請參見表1，此處不贅言）：

角度	傳統需求分析	敏捷需求分析
需求分析時機	更多地集中在項目早期	近乎均勻地貫穿于項目的整個生命周期
需求劃分單位	基于功能分解，劃分模塊或子系統，一個模塊或子系統的顆粒度通常較大	基于能否獨立業務價值，切割成一個個用戶故事，一個故事有時會跨越傳統的模塊或子系統邊界；用戶故事是小粒度的，可測試的，可見的，并且是有價值
需求細化過程	一步到位，可供開發人員設計開發	逐步細化，僅就下一個迭代需要實現的部分進行詳細分析
需求文檔要求	正式文檔，往往有明確的格式要求。既作為設計開發人員必須嚴格遵守的規約，也作為向客戶提交的必備產出物之一。難維護，難驗證（跟蹤），很多產出物最終難以被閱讀。	非正式文檔。僅僅是輔助開發團隊與客戶溝通，不作為規約，也不作為必備產出物。更多強調通過自動化功能測試用例來跟蹤系統需求。（對于組織過程資產管理要求，可以在此基礎上形成可閱讀可理解的輕型文檔）。
需求文檔同步	項目中后期一般都處于不同步狀態	即時的同步
需求傳遞過程	單向的陳述與記錄，文檔傳導（線性的傳遞，誤導放大，緩慢）	聚議，共同參與，業務場景與用戶故事，及時的非正式溝通
應對需求變更	有嚴格的控制流程，視變更為風險	視變更為必然或預期中的事情

表2：敏捷需求分析的特征對比
4. 應用敏捷需求分析的質量保證
一個傳統的軟件實現過程，遵循計劃與嚴格的控制來保證質量。管理手段的控制有時不能及時糾正工程領域的偏差，即使控制體系給了更多的回饋機制，實質上更多地只是增加了信息層級和復雜度。

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