敏捷開發與項目管理實戰之敏捷需求分析

發表于:2013-11-06來源:IBM作者:黃 文海點擊數: 標簽:
敏捷開發與項目管理實戰之敏捷需求分析. 敏捷開發中,全體成員都會參與需求分析。但是,通常多數的開發人員和測試人員他們的能力和經驗不足以勝任需求分析工作。這意味著全體成員參與的需求分析活動需要一個扮演導師角色的人帶領大家去進行有效的需求分析。本

  簡介: 敏捷開發中,全體成員都會參與需求分析。但是,通常多數的開發人員和測試人員他們的能力和經驗不足以勝任需求分析工作。這意味著全體成員參與的需求分析活動需要一個扮演導師角色的人帶領大家去進行有效的需求分析。本文以作者黃文海帶領團隊成員做需求分析的實際經驗分享了敏捷開發團隊中需求分析的一些關注點和方法。

  問題背景

  敏捷開發中許多活動都是全員參與而非專人參與。需求分析同樣也可以是全員參與的一個活動。這反映了敏捷開發的"個人與交互勝過過程與工具"的價值觀。需求分析是在需求理解的基礎上進行的。因此,全員參與需求分析有助于及時發現團隊成員對同一個需求理解不一致的問題,這很大程度上避免了缺陷的引入。另外,也有助于規避人力風險。比如,一個需求的開發者突然需要請假,其他開發者可以馬上頂替他,因為其他人也參與了其負責開發的需求的分析。此外,全員參與需求分析也有助于全體成員的能力的提升。但問題是,通常多數的開發人員和測試人員他們的能力和經驗不足以勝任需求分析工作。這意味著全體成員參與的需求分析活動需要一個扮演導師角色的人帶領大家去進行有效的需求分析。本文以筆者帶領團隊成員做需求分析的實際經驗分享了敏捷開發團隊中需求分析的一些關注點和方法。

  區分“什么”與“怎么”

  愛因斯坦曾說如果他有一個小時來拯救世界,他將花 55 分鐘去定義這個問題而只花5分鐘去需求解決方案。

  這句話道出了理解問題本身對于解決問題而言的重要性。而軟件開發可以看做解決問題的過程。軟件開發所要解決的問題就是如何將需求轉換為代碼。需求反映的是"什么"(What)的問題。開發人員在需求分析時往往易犯的一個問題是急于考慮"怎么"(How)的問題,而這是設計所要解決的問題。

  而從問題解決的角度來看,要解決一個問題首先要弄清楚的是"問題"究竟是什么。這就好比兩個人賽跑,先到終點的人有獎金。而終點明明在南邊,而甲以飛快的速度跑到北邊,結果他還是輸了。因此,項目經理應當引導團隊成員在需求階段先關注需求本身,而非過早得考慮設計的問題。

  分析需求的合理性與完整性的利器——需求背景

  敏捷開發中往往采用 User Story 的方式描述一個需求。一個 User Story 的典型格式如下:

  作為 XX(角色),我希望……(系統能夠實現...),以便……(達成某業務目標)。

  比如,下面是一個 User Story 的具體例子:

  作為手機用戶,我希望能夠查閱我的通話記錄,以便核實我的消費情況。

  可見,User Story 是從兩個方面對需求進行表述的:需求背景和需求陳述。需求陳述告訴我們系統要做什么,它反映了客戶所要(want)。而需求背景告訴我們系統為什么要做某件事,它反映了客戶的業務需要(need)。結合一個需求的這兩個方面,有助于分析需求的合理性。對于不合理的需求應該及時拒絕,否則不僅浪費了團隊資源,系統上線后還可能給利益干系人帶了損失。

  傳說,牛頓有大小兩只貓,為了方便讓這兩只貓出入,他在墻上開辟了大小兩個洞。這個故事里面描述了一個需求:要開辟大洞小洞各一(需求陳述),以方便大小兩只貓出入(需求背景)。

  事實上,一個大的洞就可以滿足實際的需要了??梢?,需求陳述可能和需求背景實際上是不吻合的,這也正是我們分析需求合理性的一個著實點。

  了解一個需求的背景對于理解和分析一個需求來說至關重要。因為需求背景不僅有助于理解需求,回答我們的疑問,也有助于對需求進行進一步分析。比如,移動網絡中的廣告可能要求廣告內容的個性化定制,即每個用戶看到的廣告的內容可能都不一樣,這些廣告的內容因受眾的年齡、性別等個人信息而異。顯然,系統需要先查詢用戶個人信息然后再根據終端用戶的個人信息去查詢廣告內容。那針對這樣一個需求,我們可能會提出這樣一個問題:如果用戶個人信息查詢失敗,系統是否還需返回廣告內容呢? 而需求陳述中并沒有提及這點??紤]需求背景可以幫助我們自行找到這類需求完整性問題的答案——根據個人信息獲取定制的廣告其目的是更好地定位潛在消費者,若無法獲取用戶個人信息,則返回適宜大眾閱讀的廣告也無妨。

  分析需求的一致性

  即便是同一個迭代中的需求,其描述也可能是前后矛盾的,或者前后不同的。這就產生了一致性的問題。只不過有些一致性問題比較明顯,如下文所描述的與前文并一致,文字描述與相關圖片、附件不一致。而另外一下一致性問題則比較隱蔽,需要通過邏輯推理和綜合分析才能發現。

  分析需求的兼容性

  迭代開發中,當前迭代往往涉及對前面迭代中已經實現的的需求的變更,而在此次變更之前該需求可能已經經歷若干次變更了。這種情況下,我們特別需要關注這些變更間的兼容性。因為前些迭代中實現的這個需求可能已經上線運行了,需求變更應當考慮到它對線上的系統可能帶來的兼容性問題。否則,新的迭代發布的版本若與線上的版本不兼容,很可能給客戶帶了重大損失。

  區分知識層與操作層

  我曾經聽說過這樣一個例子。在一個醫院管理信息系統中,客戶信誓旦旦得說一個病人轉科室最多只會出現三次。于是,開發團隊就把病人轉科室的功能做成了只能轉三次。后來這個系統上線后,有個病人轉了三次科室后又需要被轉回到最初的科室。于是,用戶開始抱怨為何只能轉三次。

  事實上,上面故事中的功能從需求階段上就已經引入了缺陷。其原因倒不在于客戶是怎么說的。而在于需求分析時沒有區分需求的知識層和操作層。上面例子中,允許病人被一個科室轉到另一個科室,這是知識層的問題,而轉科室的具體次數則是操作層的問題?;煜R層與操作層這兩個層次往往會產生問題。因此,上述例子中的需求應該正確得理解為:病人可以被從一個科室轉到另一個科室。轉科室的次數為 N 次(N>0)。也就是說系統只要能夠支持病人轉科室即可,而具體一個病人會被轉多少次科室,那是軟件上線后具體操作的問題。作為軟件開發人員我們并不能也沒有必要知道這個數量。

原文轉自:http://www.ibm.com/developerworks/cn/rational/r-cn-agilerequirementanalysis/index.html

国产97人人超碰caoprom_尤物国产在线一区手机播放_精品国产一区二区三_色天使久久综合给合久久97