敏捷開發中,User Stories最佳實踐

敏捷開發中,User Stories最佳實踐

在本文中,討論User Stories創建、計劃和編寫User Stories相關的代碼的最佳方式,以及回答一些最常見的問題。

敏捷開發中,User Stories最佳實踐

許多團隊開始使用“用戶故事(User Stories)”這個術語,因為他們轉向了敏捷。用戶故事是一種收集客戶需求的簡單而優雅的技術。然而,使用用戶故事來構建優秀的軟件需要一定的理解和實踐。

讓我們仔細看看用戶故事(User Stories)是什麼,以及如何在項目中成功使用這種技術。

什麼是用戶故事?

用戶故事是一個簡短而簡單的功能描述,它為用戶或客戶帶來價值,並且團隊可以在迭代中交付這些功能。

用戶故事應該回答三個問題:

我們為誰實現它?——期望的類型

我們實現是什麼功能?——我希望

我們為什麼要實現它?——

在此之後,用戶故事的典型格式是:

作為一個,我想要,以便。

用戶故事的例子:作為註冊用戶,我希望能夠將我的照片下載到我的個人資料中,以便其他用戶可以看到我的樣子。

有創建用戶故事的過程嗎?

沒有創建用戶故事的正式過程。然而,應該遵循一個指導方針來創建一個好的用戶故事。它叫做3c,是由極限編程的創始人之一Ron Jeffries提出的。

卡片是用戶故事的書面描述。它沒有捕獲應該構建的所有細節。相反,它是一個提醒,一個必須進行後續溝通的承諾。

對話用於討論用戶故事的細節。它可以通過一些文檔來補充。

由用戶驗收測試來進行確認,以確保用戶故事滿足用戶/客戶的驗收標準。

如何編寫高質量的用戶故事

要確保用戶故事具有適當的質量,一個好的做法是遵循比爾•韋克(Bill Wake)的“投資”(INVEST)首字母縮寫的標準。INVEST還有助於確定用戶故事是否被很好地理解併為開發團隊開始工作做好了準備。

獨立——用戶故事不應該依賴於另一個用戶故事,因此用戶故事可以按照任何順序開發。

可協商——用戶故事的細節在產品所有者和開發團隊之間的口頭對話中協商。

有價值——用戶故事應該為用戶/客戶帶來所需的價值。

可評估——開發團隊應該充分理解用戶故事,以便對其進行評估。

小的-用戶故事應該小到適合在一個迭代(1-3周)中。

可測試性——應該為用戶故事編寫適當的驗收標準,以便對其進行驗證。

什麼不是用戶故事?

讓我們坦誠地告訴自己:用戶故事的定義必須是從真正業務用戶的角度,不可能是“技術用戶(開發者本身)故事”,因為在這種情況下,它不會給用戶/客戶帶來直接的價值。儘管如此,當許多團隊需要完成諸如代碼重構之類的技術任務時,他們還是喜歡創建用戶故事。我建議將其他工作項用於此類任務,並與您的產品所有者就此類工作達成一致,以便他了解為什麼有必要這樣做。與非功能性需求任務、界面設計任務、複雜的用戶交互任務或bug相關。

您可以自由地為這些任務創建其他工作項。例如,約束故事可以用來表示非功能需求。用戶故事是捕獲產品功能的一種很好的技術,但是我們沒有義務將它用於所有目的。

用戶是誰?

在編寫用戶故事之前,應該清楚地瞭解創建用戶故事的用戶是誰。有時,新接觸用戶故事技術的團隊會忽略它,他們最終會創建具有不必要功能的軟件。所以,做一個適當的用戶調查,讓所有的用戶類型或用戶角色或角色寫下和描述。可以幫助您實現這一點的兩種技術是用戶角色建模和角色。

通常,客戶代表(如產品所有者)負責用戶故事。儘管如此,用戶故事並不是高層給團隊的規範,而是產品所有者和團隊之間的協作技術。這就是為什麼如果用戶故事是合作編寫的更好。一個好的方法是成立一個故事編寫研討會,由團隊合作編寫。

細節在哪裡?

由於用戶故事不是規範,所以細節以不同的方式表達:

在用戶故事編寫的3C原則中,第二個C是對話(Conversation)。會話是敏捷最重要的方面之一。因此,大部分細節都是通過客戶代表和開發團隊之間的口頭交流來傳達的。

第三個“C”是確認( Confirmation)。用戶驗收測試是確認用戶故事滿足用戶/客戶的驗收標準,並作為正式的文檔細節。BDD(行為驅動開發)是編寫驗收測試的一種很好的技術。

如果需要,一些用戶故事可能包含額外的書面細節。

如何知道用戶故事何時完成?

使用已“完成”技術的定義。簡單地說,Done的定義是團隊成員之間對完成工作的意義的共同理解。完成的定義通常以活動檢查表的形式創建,該檢查表展示了商定的價值(滿足用戶接受標準的用戶接受測試)和質量(滿足質量標準的用戶接受測試)。

團隊有時會忽略最後一個,什麼會使用戶故事在迭代結束時不能交付給客戶。定義Done技術有助於避免這種情況。

參看下面定義的例子

完成時:

單元測試通過了

代碼是同行評議

通過用戶驗收測試

集成測試是通過了

迴歸測試是通過了

用戶指南更新了

如何開始定義產品範圍?

在項目的開始,我們需要定義一個產品的粗略範圍,以便對它有一個全局的看法。這可以用史詩(Epics)來完成。史詩是有一個共同目標的大量工作。可以將Epic視為稍後創建的更詳細的用戶故事的佔位符。史詩通常需要多次迭代才能完成。

組織用戶故事的最佳方式是什麼?

使用傑夫·巴頓發明的故事映射技術。故事映射代表了對需求組織的自頂向下的方法,也是確定優先級和計劃的好方法。

敏捷擴展BABOK® Guide v2 狀態:

“故事映射提供瞭解決方案支持的活動序列的可視化和物理視圖。它使用二維網格結構在水平維度上顯示產品關鍵方面的序列和分組,在垂直維度上顯示故事的細節和優先級。故事映射是一種分解技術,它允許從端到端視圖開始對解決方案進行演化理解,並深入到詳細的用戶故事。”

故事映射的例子(由Steve Rogalsky創建):

敏捷開發中,User Stories最佳實踐


分享到:


相關文章: