在轉(zhuǎn)向敏捷之后，很多團隊開始使用“用戶故事”一詞。用戶故事是一種簡單而優(yōu)雅的技術(shù)，可以收集客戶需求。然而，它需要一定的理解和實踐才能用User Stories構(gòu)建出色的軟件。

讓我們仔細看看用戶故事是什么以及如何使用這種技術(shù)取得成功。

什么是用戶故事？

用戶素材是對功能的簡短描述，它為用戶或客戶帶來價值，團隊可以在迭代中提供這些功能。

用戶故事應(yīng)該回答3個問題：

• 我們?yōu)檎l建造它？ - 作為<用戶類型>
• 我們在建什么？ - 我想<feature>
• 我們?yōu)槭裁匆ㄔ焖?#xff1f; - 這樣<值或利益>

在此之后，用戶故事的典型格式是：

作為<用戶類型>，我想要<feature>，以便<value或benefit>。

用戶故事示例：作為注冊用戶，我希望能夠?qū)⑽业膱D片下載到我的個人資料中，以便其他用戶可以看到我的樣子。

有沒有創(chuàng)建用戶故事的程序？

沒有正式的過程來創(chuàng)建用戶素材。盡管如此，還是應(yīng)該遵循一條準則來創(chuàng)建一個好的用戶故事。它被稱為3 C，由極限編程的創(chuàng)始人之一Ron Jeffries提出。

• 該卡是用戶故事的書面說明。它沒有捕獲有關(guān)應(yīng)該構(gòu)建的內(nèi)容的所有詳細信息。相反，它是一個提醒，是對必須進行的后續(xù)通信的承諾。
• 對話用于討論用戶故事的細節(jié)。它可能會被一些文檔補充。
• 確認由用戶驗收測試表示，確保用戶故事滿足用戶/客戶的驗收標準。

如何撰寫高質(zhì)量的用戶故事

確保用戶故事具有適當(dāng)質(zhì)量的良好做法是遵守Bill Wake的INVEST首字母縮略詞的標準。INVEST還有助于確定用戶故事是否已被充分理解并為開發(fā)團隊開始工作做好準備。

• 獨立 - 用戶故事不應(yīng)該依賴于另一個用戶故事，因此用戶故事可以按任何順序開發(fā)。
• 可協(xié)商 - 用戶故事的詳細信息通過產(chǎn)品負責(zé)人和開發(fā)團隊之間的口頭對話進行協(xié)商。
• 有價值 - 用戶故事應(yīng)該為用戶/客戶帶來所需的價值。
• 估計 - 開發(fā)團隊?wèi)?yīng)該很好地理解用戶故事來估計它。
• 小 - 用戶故事應(yīng)足夠小，以適應(yīng)迭代。
• 可測試 - 應(yīng)為用戶故事編寫正確的驗收標準，以便進行驗證。

什么不是用戶故事？

讓我們對自己說實話：用戶故事不能通過其定義成為“技術(shù)用戶故事”，因為在這種情況下它不會給用戶/客戶帶來直接價值。不過，許多團隊喜歡在需要執(zhí)行代碼重構(gòu)等技術(shù)任務(wù)時創(chuàng)建用戶故事。我建議將其他工作項用于此類任務(wù)，并與您的產(chǎn)品負責(zé)人就此類工作達成一致，以便了解為何需要這樣做。這同樣涉及非功能性需求任務(wù)，界面設(shè)計任務(wù)，復(fù)雜的用戶交互任務(wù)或錯誤。您可以自由地為這些任務(wù)創(chuàng)建其他工作項。例如，Constraint Story可用于表示非功能性需求。用戶故事是捕獲產(chǎn)品功能的絕佳技術(shù)，但我們沒有義務(wù)將其用于所有目的。

誰是用戶？

在編寫用戶故事之前，應(yīng)該清楚地了解創(chuàng)建用戶素材的用戶是誰。有時它被新用戶故事技術(shù)的團隊所忽視，他們最終創(chuàng)建了具有不必要功能的軟件。因此，做一個適當(dāng)?shù)挠脩粞芯?#xff0c;讓你的所有用戶類型或用戶角色或角色寫下來并描述?？梢詭椭鉀Q此問題的兩種技術(shù)是用戶角色建模和角色。

誰負責(zé)撰寫用戶故事？

通常，客戶代表（例如產(chǎn)品負責(zé)人）負責(zé)用戶故事。盡管如此，用戶故事并不是從頂級到團隊的規(guī)范，而是產(chǎn)品負責(zé)人和團隊之間的協(xié)作技術(shù)。這就是為什么如果用戶故事是協(xié)作編寫的話會更好。一個很好的方法是做一個故事寫作研討會。

細節(jié)在哪里？

由于用戶故事不是規(guī)范，因此詳細信息以不同方式傳達：

• 3 C指南中的第二個“C”是Conversation。對話是敏捷最重要的方面之一。因此，大多數(shù)細節(jié)都是通過客戶代表和開發(fā)團隊之間的口頭溝通來傳達的。
• 第三個“C”是確認。用戶驗收測試確認用戶故事滿足用戶/客戶的驗收標準，并且它們用作正式的文檔詳細信息。BDD（行為驅(qū)動開發(fā)）是一種編寫驗收測試的好方法。
• 如果需要，某些用戶故事可能包含其他書面詳細信息。

你怎么知道用戶故事何時完成？

使用“完成定義”技術(shù)。簡而言之，Done的定義是團隊成員之間對工作完成意義的共同理解。完成的定義通常以活動清單的形式創(chuàng)建，其表明商定的價值（用戶驗收測試以滿足用戶驗收標準）和質(zhì)量（以滿足質(zhì)量標準）。團隊有時會忽略最后一個，在迭代結(jié)束時，什么可以使用戶故事不可能發(fā)送給客戶。完成技術(shù)的定義有助于避免這種情況。

完成定義的示例：

完成時間：

• 單元測試通過
• 代碼經(jīng)過同行評審
• 用戶驗收測試通過
• 集成測試通過
• 回歸測試通過
• 用戶指南已更新

如何開始定義產(chǎn)品范圍？

在項目開始時，我們需要定義產(chǎn)品的粗略范圍，以便對其有全局視野。這可以通過Epics完成。史詩是一大塊工作，有一個共同的目標。Epic可以被視為占位符，用于稍后創(chuàng)建的更詳細的用戶故事。Epic通常需要多次迭代才能完成。

什么是組織用戶故事的最佳方式？

使用由Jeff Patton發(fā)明的故事映射技術(shù) (User story Mapping)。故事映射代表了一種自上而下的需求組織方法，也是確定優(yōu)先級和規(guī)劃的好方法。

對BABOK?Guidev2的敏捷擴展指出：

“故事映射提供了解決方案支持的活動序列的視覺和物理視圖。它使用二維網(wǎng)格結(jié)構(gòu)來顯示產(chǎn)品在水平維度上的關(guān)鍵方面的順序和分組，詳細信息和優(yōu)先級關(guān)于垂直維度的故事。故事映射是一種分解技術(shù)，它允許從端到端視圖開始逐步理解解決方案，并深入到詳細的用戶故事。

故事映射示例 (Visual Paradigm User Story Mapping)：

https://www.youtube.com/watch...

總結(jié)

以上是生活随笔為你收集整理的User Stories - 最佳实践 (Best Practices)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。