用戶故事：敏捷開發的起點
作者：Rick Freedman
翻譯：Renee
3Cs
想象一下這樣一個用戶故事，“作爲一名求職者，我可以找工作。”大多數的開發人員都會認爲這種描述太籠統了，無法在這個基礎上進行系統搭建。 敏捷開發宣言的署名者之一Ron Jeffries在 《 極限編程關鍵：卡片（Card）、對話（Conversation）和確認（Confirmation）》一文中提出了一個很好的用戶故事描述說明指導。
(圖片來自網絡)
簡單描述一個用戶的功能性需求（例如：“作爲一名求職者，我可以找工作”）可以用一張索引卡片（Card）表述出來，這張卡片並不是需求描述；還需要對話（Conversation）和確認（Confirmation）是描述變得完整。在敏捷方法中，開發人員和用戶的互動至關重要。用途描述是需求對話的開始，而不是結束。沒有描述，記錄在卡片上的句子就毫無意義。
使用敏捷方法是爲了避免傳統開發方法中的錯誤和陷阱，其中最臭名昭著的一個陷阱就是“隨意丟給你”的需求。這種需求臨時交給開發團隊，強制他們“去開發這個”。敏捷開發人員認爲，成功的開發工作最重要的一個因素就是用戶與其合作，這種合作最好是就系統的外觀、體驗和功能與開發人員持續的不斷地對話、交流。正是在這種持續的交流中，更多的細節（譬如，“一個求職者可以以自己的特長來找工作”或“一個求職者可以以遊客的身份登錄，也可注冊成爲會員”），才會被涉及，一個可行的系統才能被創造出來。
通过不断增加细节，开发团队和用户可以决定哪些细节是原始需求的详尽阐述，哪些细节可能需要单独作为一个需求来写。例如，会员制是一个终端産品的关键要素（如用户在网站哪里可以付款进入职位发布），会员故事有更多的细节描述，可能需要作为一个单独的需求，有自己的一些列的开篇、对话和确认。对话产生的细节通常可以以文档记录下来。
確認這一環節說明用戶是那些定義如何測試系統功能的人。實際操作中，顧客協同確認環節也是很多細節被商榷的環節。如果項目內容是建一個會員制的網站，在這個網站上，求職者可以付費獲得浏覽表單的權限。那麽有個顯而易見的問題，那就是會員怎麽付費呢？這個問題就要考慮測試可以接受哪些信用卡付款，貝寶、支票、借記卡或其它會員可能會使用的轉賬方式。
和客户不断的对话可以引导客户细化他们的需求，这是敏捷开发的艺术所在。敏捷开发是为了 避免开发中先前出现错误，其中一个错误就是程序员创造的测试。开发人员通常会指定系统通过的测试，这只是为了检测系统会不会在使用中崩溃。这并不是因为开发人员想要和系统玩个游戏。这样做是因为程序员要测试其编写的功能，而这些功能可能和用户预期的用例并不符合。
