很多的項(xiàng)目在需求分析上耽誤的時(shí)間很長(zhǎng)，動(dòng)輒兩三個(gè)月，這樣做并不能帶來(lái)更好的結(jié)果，留給需求實(shí)現(xiàn)的時(shí)間往往都非常緊迫，反而是造成項(xiàng)目deliver周期延長(zhǎng)，風(fēng)險(xiǎn)更大。用戶(hù)故事和快速原型，講究的都是一個(gè)快字，都是可迭代的，講究的是先make things happen，再improve.
User Story 從結(jié)構(gòu)和表現(xiàn)形式上，實(shí)際上是Use case的變種，為啥又出來(lái)個(gè)User story, 應(yīng)當(dāng)要反方向思考一下，
1.極限編程需要快速地、大量頻繁的與用戶(hù)溝通、需求分析，需要一種容易適應(yīng)用戶(hù)理解的、白話(huà)方式的結(jié)構(gòu)表現(xiàn)形式，容易得到用戶(hù)的快速理解和雙方確認(rèn)。
2.迭代開(kāi)發(fā)，需要一種切割千頭萬(wàn)緒的需求為一個(gè)個(gè)可獨(dú)立分配的需求單位的策略、原則、手段、形式。只有劃分成可獨(dú)立分配合適粒度的單位，才能談的上工作量的可估算、優(yōu)先級(jí)的劃分、合理的制定計(jì)劃、task的合理分配、端到端的測(cè)試、單位性質(zhì)的可交付。
3.測(cè)試驅(qū)動(dòng)，需求的編寫(xiě)無(wú)法轉(zhuǎn)化成有效的test case，總體上來(lái)說(shuō)，不能算是合理的需求，要想達(dá)到test case中要求的可測(cè)試的需求，則上下文、輸入、輸出的必要描述，不可缺少。
從上可以得出一個(gè)User story的結(jié)構(gòu)或者模板：
1）上下文背景
2）用戶(hù)要達(dá)到的目的，價(jià)值.
3）故事細(xì)節(jié)
4）前置輸入
5）判斷故事是否完成實(shí)現(xiàn)的輸出
User story, 的前提是用戶(hù)能夠tell you a story, 不管這個(gè)story是粗糙的，還是精細(xì)的。但如果涉及到大量的可視化表現(xiàn)手段，才能在此基礎(chǔ)上進(jìn)一步說(shuō)清楚的，往往需要原型來(lái)表示，比如犯罪嫌疑人畫(huà)像，用戶(hù)先給出一個(gè)不著邊、不著調(diào)的罪犯描述，擱著一般人都不知道說(shuō)什么，如：個(gè)子不高，嘴角有點(diǎn)歪，鼻子短，胖胖的，但畫(huà)像專(zhuān)家，先快所素描一個(gè)人頭像，用戶(hù)看后說(shuō)，不太像，那個(gè)人的眼晴比這個(gè)大，還有個(gè)小胡子，專(zhuān)家又修改了一下，用戶(hù)在看看，這樣在較短的時(shí)間，一個(gè)相對(duì)比較接近的描述就出來(lái)了。
白板和power point只是有限的可視化溝通手段，最好的還是HTML原型，應(yīng)當(dāng)是動(dòng)態(tài)的可交互的，從鏈接、彈出、根據(jù)不同邏輯的頁(yè)面跳轉(zhuǎn)、邏輯判斷都盡量的表現(xiàn)出來(lái)。
原型快要快在兩個(gè)方面：
1）直觀，半天說(shuō)不清楚的，言語(yǔ)難以表達(dá)的，一個(gè)界面就搞定了，用戶(hù)會(huì)說(shuō)：“就是這樣，這就是我要的"。
這需要分析人員就是原型制作人員，像上面的畫(huà)像專(zhuān)家一樣，即能分析，又能畫(huà)像，而且畫(huà)得像。不能說(shuō)原型是出來(lái)了，但很丑，別別扭扭的，距離用戶(hù)的想法太遠(yuǎn)，還不如不用這種方法，耽誤時(shí)間得不償失。
2）能夠快速的做出原型，并且易于修改
制作原型的時(shí)間，不能太長(zhǎng)，一兩個(gè)星期，是適度的，當(dāng)用戶(hù)有不同的意見(jiàn)時(shí)，最好能當(dāng)場(chǎng)修改，如果團(tuán)隊(duì)中的人多利哆嗦的，十天半個(gè)月搞不出個(gè)結(jié)果，還是不要搞。
很多的分析人員，不會(huì)做原型，所以快速原型的手段就用的很少，其實(shí)快速原型在很多的項(xiàng)目上都非常實(shí)用：
1）用戶(hù)是分布式的，有的在美國(guó)，有的在印度，有的在國(guó)內(nèi)，溝通都是通過(guò)IM、電話(huà)、郵件的方式，快速原型很方便。
2）XP要占用用戶(hù)的很多時(shí)間，這一點(diǎn)在國(guó)內(nèi)，不一定實(shí)用，如果用戶(hù)不能抽出大量的時(shí)間參與其中，原型的優(yōu)勢(shì)就現(xiàn)出來(lái)了。
3）User story不會(huì)在界面交互需求、用戶(hù)體驗(yàn)上的描述細(xì)節(jié)，而是依靠快速的實(shí)現(xiàn)，然后用戶(hù)在可使用的交付系統(tǒng)上提出迭代修改的建議，在花一些不必要的，可以避免的時(shí)間去修改。所以時(shí)間還是要還回來(lái)的，不見(jiàn)得就是節(jié)省時(shí)間。對(duì)于新上馬的網(wǎng)站項(xiàng)目等不適用。
User story 和 Rapid prototype, 都是方法，作為方法論的使用者，自然會(huì)汲取長(zhǎng)處，靈活掌握，而不是亦步亦趨，照搬照抄，我最不喜歡聽(tīng)的就是"書(shū)上就是這么說(shuō)的".
兩者其實(shí)是互補(bǔ)的關(guān)系，User story由于XP的理念支撐，又從Use case中變種，基礎(chǔ)很扎實(shí)，但現(xiàn)在隨著Web2.0的奉行, Ajax, CSS, XTHML，大量的javascript framework如jquery, EXT, prototype等，在短時(shí)間內(nèi)搞定一個(gè)原型，不是難事。
現(xiàn)在國(guó)外的很多的創(chuàng)業(yè)團(tuán)隊(duì)（Freelance)，都可以做出一步到位的原型，團(tuán)隊(duì)中的人擅長(zhǎng)前端設(shè)計(jì)、開(kāi)發(fā)，Ajax, CSS, XTHML，web standard, cross browser不在話(huà)下，F(xiàn)lash, Flex, Fireworks 等RIA技術(shù)也是有豐富的項(xiàng)目經(jīng)驗(yàn)，很多人用flash, fireworks做的原型，非常棒。以用戶(hù)為中心的、注重用戶(hù)體驗(yàn)、準(zhǔn)確把握用戶(hù)業(yè)務(wù)的分析設(shè)計(jì)是他們的核心競(jìng)爭(zhēng)力。
未來(lái)這種做法會(huì)進(jìn)一步延伸到普通的項(xiàng)目團(tuán)隊(duì)中，用在合適的場(chǎng)景，它會(huì)更快：
1）CSS+XHTML+Javascript，遵循標(biāo)準(zhǔn)的一步到位的原型，需求分析完后，直接就是可開(kāi)發(fā)的界面了，對(duì)那些不擅長(zhǎng)前端開(kāi)發(fā)，只會(huì)寫(xiě)Java累的團(tuán)隊(duì)，無(wú)疑節(jié)省了非常可觀的時(shí)間。
2) User-centric, 將用戶(hù)體驗(yàn)的部分需求包含在內(nèi)，避免后期的rework.
3) 相對(duì)User story, 更容易理解和分工、開(kāi)發(fā)，直接實(shí)現(xiàn)，而不是思考如何表現(xiàn)。
前提是：
1）要的不是美工，是分析人員要會(huì)前端技術(shù)。
2）它不能替代User story，它的目的是快速開(kāi)發(fā)。復(fù)雜的邏輯、流程，仍然需要文檔和文字描述。
3) 一定不要使用原型生成工具，他們生成的原型，不能用來(lái)做開(kāi)發(fā)的。Editplus, 手寫(xiě)頁(yè)面，搞定一切。
我的項(xiàng)目中就是這樣做的，如果你處于On ready狀態(tài)，就不難，頁(yè)面模板，CSS庫(kù)，javascript框架，都準(zhǔn)備好了，就缺少一個(gè)有思想的組織者了。
需求分析的快，準(zhǔn)，是快速原型的目標(biāo)，一步到位，不丟棄原型，是原型設(shè)計(jì)的境界。