敏捷開發(fā)方法需要為最后階段定義最小需求。換句話說，所創(chuàng)建的任何需求細節(jié)都必須是對整個團隊有關(guān)鍵性質(zhì)的。那么，怎樣確定最小需求，又由誰來負責(zé)呢？協(xié)作式或分布式團隊有什么不同？如何應(yīng)付這些需求在細節(jié)和優(yōu)先級上的變化？下面是關(guān)于這些問題所做的解答。
如何確定最小需求？
確定最小需求是一項既簡單又復(fù)雜的工作。簡單是指如果作對了就會一切順利；而復(fù)雜是指這里牽涉到許多元素，比如團隊的規(guī)模大小、團隊成員的融洽度、所構(gòu)建的軟件版本的復(fù)雜度、所開發(fā)的是插件模塊還是全新系統(tǒng)或產(chǎn)品，以及在業(yè)務(wù)上廣度與質(zhì)量哪一方面更為重要。因此，你可能需要一些如何為團隊確定需求的建議。本文將就這方面提供了一些簡單的建議。
選擇細節(jié)等級
首先要確定需求細節(jié)要做到什么程度。下面的表格提供了一些參考，但在最后階段仍然要隨時做好更改的準備。
細節(jié)較多 細節(jié)較少
新系統(tǒng) 對現(xiàn)有系統(tǒng)進行簡單到中等程度的修補
分散或分布式團隊 處于同一位置的團隊
大型復(fù)雜的方案 小型簡單的方案
新組成的團隊 有過協(xié)作經(jīng)歷的團隊
“需求卡片”不能滿足要求時
需求卡片是一種敏捷開發(fā)團隊中常用且很有價值的方法。這些需求卡片描述了“哪些人需要做哪些事，以及為什么要做”，有時也會用來提供一些關(guān)于屏幕樣圖和測試方案的信息。這種方法或許足以應(yīng)付小規(guī)模的開發(fā)，但如果涉及比較大型或較復(fù)雜的對其它部分有較強依賴性的模塊時，就會略顯不足。
不要勉強使用不適合的方法
有許多已經(jīng)經(jīng)過實踐證明的需求采集的方法。但適時選擇合適的方法是需要技巧的。比如，有時只需要在需求卡片上用文字簡單地概括出“哪些人、做什么、為什么這樣做”即可。而有些時候為這些描述添加一些圖片可能會更好，比如模擬屏幕截圖，或者再加上些腳注。
有時，要了解一個很復(fù)雜的需求的流程，可能要用到“用例流程（use case flows）”和/或“模擬過程（simulations）”來確定最小需求。但我認為，用“用例”來描述復(fù)雜的邏輯或業(yè)務(wù)規(guī)則（比如驗證邏輯）卻不是一個好方法。通常文字或表格更適合用來描述這種需求。比如，一個簡單的2x2的表便可以用行列分別表示驗證規(guī)則的功能及其作用，這比用“用例”來表示之間的選擇關(guān)系要有效得多。
同樣，在做模擬過程的時候也有可能因為做得過于細致而浪費與所得價值不成正比的精力。雖然模擬過程在“生動地描述一個概念”方面有不可估量的價值，但要將每一個細節(jié)都考慮進去卻需要時間。并且很顯然，對于開發(fā)人員來說，還要反向剖析這些模擬過程并從中抽取出離散的需求來，而這項工作有時會很困難。還以業(yè)務(wù)的驗證規(guī)則為例，開發(fā)人員通過閱讀一個2x2表格便能很快明白要做哪些事，但運行一個模擬過程并反向剖析出同樣的信息來卻要復(fù)雜的多。
此文章共有2頁 1 2 下一頁
文章來源：中國項目管理資源網(wǎng)
|
Leadge.com首頁 > 知識庫 
