本文作者@朱軍華Ronzhu 敏捷開發(fā)其實(shí)不光光要求開發(fā)層面和測試層面的敏捷，其實(shí)對需求設(shè)計層面也是要敏捷的，這樣才能配合后續(xù)的開發(fā)和測試，使之真正的敏捷起來。

我們可以通過在實(shí)際操作過程當(dāng)中在需求層面進(jìn)行敏捷設(shè)計的分析來了解需求的敏捷設(shè)計。

大多數(shù)情況下需求的處理過程都可以分為需求分析和需求設(shè)計兩部分，前者要將業(yè)務(wù)需求轉(zhuǎn)化成產(chǎn)品需求，后者要將產(chǎn)品需求轉(zhuǎn)化為產(chǎn)品設(shè)計，也即成品的PRD。

在做需求分析的時候，我們也是接到一部分需求之后，按鈕業(yè)務(wù)優(yōu)先級來做分析，每次分析肯定是將相互關(guān)聯(lián)的需求放在一起分析，或者是先分析優(yōu)先級較高的，后分析優(yōu)先級較低，這個過程將分析的任務(wù)進(jìn)行了劃分。

因此其也較為接近于敏捷的模式，這里撇開不談，主要講需求設(shè)計部分如何與后面的開發(fā)、測試結(jié)合起來。

在真正開始談敏捷設(shè)計之前，我覺得有必要思考一下是否所有的需求都適合用敏捷設(shè)計？ 為什么有這樣的疑問，在于敏捷開發(fā)其實(shí)是較為靈活的，并不是一味的為了敏捷而敏捷，其也可以分成產(chǎn)品敏捷和項(xiàng)目敏捷兩種方式。

在我的理解里面，產(chǎn)品敏捷是真正的將敏捷設(shè)計、敏捷開發(fā)、敏捷測試結(jié)合在一起的，從產(chǎn)品的層面講所有的任務(wù)都用敏捷的方式進(jìn)行管理；而項(xiàng)目敏捷則采用的是需求設(shè)計走的是瀑布的模式，開發(fā)和測試才是敏捷的，因此兩者之間還是有點(diǎn)差異。

有的需求不適合用敏捷的方式的來設(shè)計

 

敏捷的模式總的來講就是將整體拆為多個個體，然后再單獨(dú)的完成各個個體以達(dá)到這些個體合成之后就是整體的效果，所以這里就有一個問題存在，產(chǎn)品的整體需求是否適合拆分？個人在操作經(jīng)驗(yàn)中總結(jié)如下：

• 各功能之間較為獨(dú)立的適合敏捷。一個產(chǎn)品有十個功能點(diǎn)，各個功能點(diǎn)之間相互依賴關(guān)系不強(qiáng)的，松耦合，就可以每個功能點(diǎn)單獨(dú)抽取出來做設(shè)計。
• 功能本身的邏輯遵循某種操作流程的適合敏捷。功能的實(shí)現(xiàn)是按照一個較為固定的流程一步一步往下走的，這樣可以將每一個步驟單獨(dú)拆分開。
• 產(chǎn)品上線之后的版本維護(hù)適合敏捷。上線之后，對一些BUG、問題、小需求的縫縫補(bǔ)補(bǔ)，都適合用敏捷的方式來設(shè)計。
• 上線后的新增需求適合敏捷。上線的的新增需求一般都針對某個功能模塊來進(jìn)行設(shè)計，相對來說較為獨(dú)立，因此也適合敏捷設(shè)計。

反之，如果不能滿足以上幾個條件的，特別是耦合度較高的需求，個人建議還是走瀑布的模式，把整體的需求都梳理清楚之后做整體的需求設(shè)計，這樣可以避免后面的設(shè)計過程要改動前面的設(shè)計結(jié)果的問題，減少一部分的需求變更.

敏捷雖然說很大的一個優(yōu)勢就在于可以較好的適應(yīng)需求變化，但這個需求變化是指來自于業(yè)務(wù)層面的，而不是來自于產(chǎn)品設(shè)計人員或者產(chǎn)品經(jīng)理自身的工作方式所導(dǎo)致產(chǎn)生的。

當(dāng)然肯定也有人是全部都走敏捷的，這樣的話對其產(chǎn)品規(guī)劃能力要求較高，整體思維邏輯要很清晰，才能避免出錯，這里只是個人建議，僅供參考。

敏捷設(shè)計的產(chǎn)出如何維護(hù)

 

平常我們稱一個功能點(diǎn)為一個CASE或者是一個Story，而在敏捷里面稱之為backlog產(chǎn)品條目，其實(shí)只是換了個名稱而已，實(shí)質(zhì)沒有變。

之前我也說過在學(xué)習(xí)他人長處的時候，重要的是理解和變通，而不是照抄。 產(chǎn)品backlog是敏捷的核心，也是整個產(chǎn)品敏捷過程的起源。從根本上說，它就是一個需求、或故事、或特性等組成的列表，按照重要性的級別進(jìn)行了排序。

它里面包含的是用戶或者業(yè)務(wù)方想要的東西，并用用戶或者業(yè)務(wù)方可以理解的術(shù)語加以描述。通常有如下幾個部分：

序號ID

統(tǒng)一標(biāo)識符，就是個自增長的數(shù)字而已，用以唯一標(biāo)示每個backlog，主要用來做標(biāo)示用，以及在PRD當(dāng)中標(biāo)注每個backlog所對應(yīng)的需求設(shè)計描述；

名稱Name

簡短的、描述性的backlog標(biāo)題，比如“查看你自己的交易明細(xì)”。它必須要含義明確，這樣開發(fā)人員、測試人員才能大致明白我們說的是什么東西，其實(shí)也方便產(chǎn)品經(jīng)理自身做checklist檢查，可以跟其他backlog區(qū)分開。 它一般由2到10個字組成；拆分backlog是有要求的，一般要求每條backlog都能在規(guī)定的單個迭代周期里面完成；

重要性Importance

產(chǎn)品經(jīng)理評出一個數(shù)值，指示這個backlog有多重要，一般為1到10之間的整數(shù)值，分?jǐn)?shù)越高越重要。 其實(shí)就是優(yōu)先級，只不過有的人所理解的優(yōu)先級是1最優(yōu)先，所以這里用重要性來表述。優(yōu)先級的評定主要參考兩個維度，一是業(yè)務(wù)價值，二是緊迫性，其他的都可以暫不考慮；

工作量估算Initial estimate

團(tuán)隊(duì)的初步工作量估算，表示完成該backlog所需的工作量，最小的單位是0.5人/天。為盡量提高估算的準(zhǔn)確性，目前個人采用的是整個團(tuán)隊(duì)每人都寫一個估算工作量，去掉一個最高的，去掉一個最低的，剩下做平均，呵呵。 然后再安排各自講解一下為什么，最終要在團(tuán)隊(duì)內(nèi)部達(dá)成一致；

演示How to demo

大略描述了這個backlog應(yīng)該如何進(jìn)行示范，本質(zhì)就是一個簡單的測試規(guī)范。一般為“先這樣做，然后那樣做，就應(yīng)該得到……的結(jié)果”，敏捷對每個backlog的要求就是可演示可單獨(dú)上線的；

備注Notes

相關(guān)信息、解釋說明和對其它資料的引用等等，一般都非常簡短； 通常都把backlog存放在共享的Excel文檔里面，以便團(tuán)隊(duì)成員都可以隨時查看編輯。一般來說這個文檔歸產(chǎn)品經(jīng)理維護(hù)，但也并不把其他團(tuán)隊(duì)成員排斥在外。開發(fā)人員和測試人員常常要打開這個文檔，弄清一些事情，或者修改估算值。

這里又會產(chǎn)生一個問題，那就是如何讓產(chǎn)品backlog停留在業(yè)務(wù)層面上？

舉例來說，如果產(chǎn)品經(jīng)理有技術(shù)相關(guān)的背景，那他就可能添加這樣一個backlog：“給Events表添加索引”。真正目的也許是“要提高在后臺系統(tǒng)中搜索事件表單的響應(yīng)速度”。到后面可能會發(fā)現(xiàn)索引并不是帶來表單速度變慢的瓶頸，也許原因與索引完全不相干。

所以指出如何解決問題的應(yīng)該是開發(fā)團(tuán)隊(duì)，產(chǎn)品經(jīng)理只需要關(guān)注業(yè)務(wù)目標(biāo)即可。這種面向技術(shù)的backlog，可以一直問下去“為什么”，直到發(fā)現(xiàn)內(nèi)在的目的為止.

然后再用真正的目的來改寫這個backlog（“提高在后臺系統(tǒng)中搜索并生成表單的響應(yīng)速度”）。最開始的技術(shù)描述只會作為一個注解存在（“為事件表添加索引可能會解決這個問題”）。

維護(hù)backlog表就是一個對產(chǎn)品需求進(jìn)行拆分的過程，拆分完成后再根據(jù)迭代計劃來設(shè)計具體的實(shí)現(xiàn)，前面所講的項(xiàng)目敏捷則是將所有需求都設(shè)計完成之后才進(jìn)行拆分，這時主要就是為了把開發(fā)任務(wù)和測試任務(wù)拆分出來了。

相對來說，敏捷還是一種較為新穎的模式，目前在互聯(lián)網(wǎng)行業(yè)用的較多，每個公司在用的時候?qū)嶋H情況可能都不大一樣，其實(shí)沒有關(guān)系的，適合自己的就是最好的，只要能提高產(chǎn)品迭代發(fā)布的效率，就可以了，先用起來，然后在用的過程當(dāng)中慢慢優(yōu)化，發(fā)揮敏捷的最大的效用。

作者博客：IT民工