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