用戶故事是用于軟件開發的簡單且有益的工具，專注于滿足用戶需求，同時提供最大的商業價值。它們通過促進一致和有效的溝通，為具有詳細要求的傳統軟件開發計劃提供了替代方案。學習編寫好的用戶故事可以幫助您的團隊在整個開發過程中保持與產品所有者的透明度，并為最終用戶提供最大的價值。
什么是用戶故事？
用戶故事是通過利益相關者之間使用敏捷方法進行軟件開發的對話來擴展用戶需求的表達。故事以對用戶、他或她的愿望以及最終目標或利益的書面描述開始。用戶故事最初用 1-2 句話寫在索引卡或便利貼上。它遵循以下格式：
作為[特定用戶]，我想要[需要]以便[利益/獎勵]。
用戶故事示例：
作為一名學生，我希望我的個人資料列出我的課程并包含指向每個課程主頁的鏈接，以便我可以訪問日常作業。
作為網站訪問者，我想每天在主頁上閱讀一篇新文章，以便及時了解最新事件。
作為網站訪問者，我想閱讀隱私政策，以便了解哪些信息將保持私密。
一個好的用戶故事簡單明了。使用技術語言會在團隊和產品負責人之間造成障礙，過多的細節沒有什么可討論的。故事應該是討論的提示，而不是詳細標準的文件。Ron Jeffries使用 3C 描述了該過程：卡片、對話和確認。在像 Scrum 這樣的敏捷框架中，用戶故事是在迭代或沖刺期間開發的，并通過實施來自對話的反饋來改進。
用戶故事應該包括什么？
用戶故事應該包括用戶[誰]、他或她需要[什么]和最終目標[為什么]。格式很簡單，但某些品質將好的用戶故事與壞的用戶故事區分開來。Bill Wake 在Extreme Programming Explored中使用首字母縮略詞 INVEST來解釋編寫良好的用戶故事的特征。
獨立的。一個用戶故事不應依賴于另一個用戶故事來完成。
面議。故事是一個簡短的對話提示，并不那么詳細，以至于沒有什么可以討論的。
有價值的。故事的結構是為了突出特定軟件將為其用戶提供的價值
估計。故事的完成時間應該可以根據其復雜性 進行衡量，并在迭代中分配。
小的。一個故事應該足夠易于管理，可以在幾天內完成。
可測試。一個故事的成功完成可以通過預先確定的驗收測試來衡量。
如何編寫用戶故事
了解您的用戶。首先，弄清楚用戶的范圍和目標，以避免為每種類型的用戶開發用戶故事。也許任何人都想使用您的網站或應用程序。也許只有特定區域內的人會受益于它的功能。創建準確的用戶故事的最佳方法是與潛在用戶交談并在開發過程中接收他們的反饋。
定義您的用戶。在卡片上亂寫名字是不夠的。名稱不提供有關用戶的任何信息。相反，給出一個標題（站點管理員）或簡要說明（新用戶）。您不需要注意您的用戶喜歡足球、住在克利夫蘭、只在星期六使用該應用程序，并且喜歡 Lay 的薯片，但您可能想要這樣做。創建用戶角色可能會令人興奮，并讓您深入了解用戶的需求。用戶角色包括用戶的姓名、描述和目標。
寫故事描述。保持簡短（1-2 句話）和非正式的。您可能希望從更大的史詩故事開始，并在規劃過程中將它們分解為更小的部分。不要使用與用戶角色不匹配且開發團隊以外的人不易理解的技術術語。
與團隊成員和產品負責人交談。細節在討論過程中被揭示，不應該在迭代規劃過程中被仔細檢查。
完善故事卡。所有好的故事都要經過修改。用戶故事是流動的，不是契約性的，實施反饋對于他們的完成至關重要。
將驗收測試添加到故事卡。驗收測試保證故事滿足用戶的需求，以及開發團隊的任何詳細標準。
創建敏捷用戶故事
用戶故事在敏捷框架中經歷了不同的開發階段：
寫作
產品積壓
迭代計劃
發展
測試
確認
誰編寫用戶故事？
客戶團隊或產品負責人編寫用戶故事。開發人員通常不會編寫故事，但會在規劃過程中進行協作。他們估計完成每個故事需要多長時間，根據復雜性為每個故事分配一定數量的點，然后確定每次迭代可以完成多少故事點。
什么時候應該寫用戶故事？
用戶故事可以在項目期間的任何時候編寫并添加到產品待辦事項中。故事優先考慮最大的用戶和商業價值。它們是從積壓中選出的，并根據優先級分類成堆。每 1-2 周的 sprint 平均包含 10 個故事。一個用戶故事不應該跨越多個沖刺。相反，它應該被分成更小的故事或保存在積壓中。包括客戶團隊、開發人員和產品負責人在內的對話應該在迭代或沖刺計劃期間以及每個 3-6 個月的發布之后進行。
如何為用戶故事添加細節？
驗收測試證明所有細節都已成功處理并確保完成用戶故事。如果一個故事太寬泛，它可以分成更小的故事。項目工作開始后，在對話期間添加細節，而不是在故事寫作階段。
用戶故事的類型
1. 史詩：一個更大、更廣泛的用戶故事，旨在在開發之前分成更小的故事。史詩可以以用戶故事格式或簡單的短語形式編寫。
示例：用戶個人資料
2. 功能性：描述為最終用戶帶來直接價值的功能的高級故事。這種類型的故事遵循標準的用戶、需求、利益格式。
示例：作為網站成員，我希望我的個人資料顯示我的工作經驗，以便吸引潛在雇主。
3. 技術：支持功能性用戶故事的可選子故事，以提高清晰度和組織性。技術用戶故事由開發人員或其他了解技術后果的人編寫。這些故事是為開發團隊的利益而編寫的，而不是呈現給產品所有者。它們可用于錯誤修復、重構和開發基礎設施。
示例：為了建立用戶檔案，我們必須允許用戶通過 LinkedIn 社交登錄按鈕與他們的 LinkedIn 帳戶同步，以將他們的工作歷史直接拉入數據庫。
用戶故事與用例
用戶故事和用例相似，但在編寫時考慮了不同的目標。用例優先考慮文本，而用戶故事優先考慮對話。用例一開始就關注技術細節，在整個開發過程中提供較少的討論空間。它提供了一個更永久的文檔，包括擴展的場景和擴展的詳細信息。
用戶故事與需求：編寫需求，但討論用戶故事。需求文檔類似于“待辦事項”列表，但故事充當需求的來源。
用戶故事與任務：任??務是可以獨立完成的一項工作。用戶故事永遠不會作為一個單獨的項目來完成。協作和對話保證了成功的用戶故事。
好的用戶故事的好處
確保您的團隊始終如一地提供為用戶帶來直接價值的功能
防止在項目開始時浪費時間開發大量功能，而不考慮糟糕的用戶體驗并減少用戶流失
在項目開始時消除詳細的合同協議，這些協議會限制創造力并阻止基于經驗的決策
允許產品負責人參與開發過程
能夠創造性地解決問題
通過透明度和一致的溝通幫助與產品所有者建立牢固的關系
允許在整個項目中進行調整
移動應用的用戶故事
創建應用程序用戶故事會引發關于您的應用程序成功之處、用戶對您的應用程序的需求以及您的應用程序在參與度和體驗方面缺乏什么的反饋和討論。在為您的移動應用編寫用戶故事時，請注意不要假設每個用戶都想要某個特定功能。如果你的應用有太多的功能，你可能需要回到繪圖板來處理那些為用戶提供最大價值的最基本的功能。
為確保您創建最適合用戶需求的應用用戶故事，請詢問：
誰在使用該應用程序？
誰不太可能使用該應用程序？
他們的愿望、需求和期望是什么？
這個應用程序提供了您的網站無法提供的或競爭對手無法提供的功能？
我們將如何確保適當的反饋和指標來跟蹤這些信息？
應用程序開發的用戶故事示例
作為一個典型的用戶，我想要簡單的導航，因為在應用程序上有很多事情要做。
作為一個罕見的用戶，我想要重新沉浸式參與，以便我可以輕松地重新熟悉應用程序的工作方式。
作為一個持懷疑態度的用戶，我想輕松控制我的隱私設置并知道使用了哪些安全協議，這樣我才能感到安全。
確保根據實際應用使用情況和體驗應用來自真實用戶的反饋。不要總是假設您的團隊對您的最終用戶了如指掌。他們的愿望、行為和偏好各不相同。并且不要僅僅依賴于應用程序開發中的用戶故事。利用其他方法，如細分分析、客戶映射和跟蹤用戶流，有助于更好地了解用戶行為。
為什么要寫用戶故事？
開發良好的應用程序或其他軟件應該以某種方式改善用戶的生活，或者根據他們的使用情況提供獎勵。用戶故事可幫助您的團隊在應用體驗和應用獎勵之間取得平衡，并幫助確保功能滿足并超出用戶期望。如果使用某項功能的回報很大，但體驗卻是壓倒性的，或者如果體驗很有趣但回報不足，則用戶不太可能返回。用戶故事允許在整個開發過程中不斷審查和修改，團隊成員開始項目時知道每個功能將提供的價值。
本文地址：
http://www.ncfbp.net/news/5807.html
Tag：
專業服務：
南京網站制作,
南京網站制作公司,
南京網站建設公司
聯系電話：025-65016872
上一篇：
「南京建設網站公司」構建應用程序需要多長時間？
下一篇：
「南京集團網站建設」如何成功地將您的應用提交到 App Store
珠?？缇畴娚?/span>
