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

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

什么是用戶故事？

用戶素材是對(duì)功能的簡(jiǎn)短描述，它為用戶或客戶帶來(lái)價(jià)值，團(tuán)隊(duì)可以在迭代中提供這些功能。

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

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

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

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

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

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

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

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

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

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

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

什么不是用戶故事？

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

誰(shuí)是用戶？

在編寫用戶故事之前，應(yīng)該清楚地了解創(chuàng)建用戶素材的用戶是誰(shuí)。有時(shí)它被新用戶故事技術(shù)的團(tuán)隊(duì)所忽視，他們最終創(chuàng)建了具有不必要功能的軟件。因此，做一個(gè)適當(dāng)?shù)挠脩粞芯?#xff0c;讓你的所有用戶類型或用戶角色或角色寫下來(lái)并描述。可以幫助您解決此問題的兩種技術(shù)是用戶角色建模和角色。

誰(shuí)負(fù)責(zé)撰寫用戶故事？

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

細(xì)節(jié)在哪里？

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

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

你怎么知道用戶故事何時(shí)完成？

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

完成定義的示例：

完成時(shí)間：

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

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

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

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

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

對(duì)BABOK?Guidev2的敏捷擴(kuò)展指出：

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

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

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

總結(jié)

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

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