前提

我以前在之前的文章里大概介紹了 Azure Board 的基本使用，可以回看《Azure Board 的基本使用》。如果你想使用 Azure Board 來安排工作的話，請提前了解《敏捷開發》的相關知識。

作者將使用?“Agile”?作為項目的模板，不明白的先閱讀《Azure?DevOps 的工作流進程的區別》。

使用 Backlog 來做計劃

什么是 Backlog？這是敏捷開發中的一個概念，通俗地說就是需求積壓池。

產品負責人（PO）或項目經理需要把要做的事情預先的在 Backlog 中記錄下來。在敏捷中需要把每一個功能單獨的寫出來，而不是傳統的文檔模式。

在 Azure Board 中，記錄需求有三種類型：長篇故事（Epic）、特性（Feature） 和 用戶故事/情景（User Story），而他們的結構一般都是父子關系，即 長篇故事 （需要完成的需求）-> 特性（將該需求分成幾個階段完成）?-> 情景（描述具體到? 角色-操作-效果）->WorkItem（具體實現）。接下來我將以 “一個找工作的網站” 來作為例子，順便也會提及一些敏捷開發的知識來做需求管理。

長篇故事（Epic）

通俗地說，長篇故事只記錄，這個 模塊（搜索模塊）要做的事情，比如：“企業可以搜索簡歷”。很多時候，這只是在立項時的一種大想法，記錄這個系統的一些主要功能，并不涉及具體需求。這里的核心思想是：“我打算做…這樣的功能”，或者“我需要一個...的模塊”。

如果說你想要做這樣的功能，那你得說出這個功能的商業價值，比如有這樣的功能的話，能幫客戶或者公司賺多少錢等等，所以在敏捷開發中，在最前期的可行性分析里，會有個投票機制，來確定這功能有沒有必要做，在什么時候做。畢竟你會有很多的想法，比如：“用戶可以搜索企業”，或者 “用戶可以搜索其他人的簡歷” 等等，也許在這個項目的初期階段，相比較而言 “用戶可以搜索公司” 這樣的需求可能就不顯得那么有價值了。

通過這樣的方式，公司可以規劃出在一定時間內的產品價值，如果總是做一些市場價值不高的功能，那必然離失敗又更近一步。

特性（Feature）

特性一般在項目中表示里程碑，將長篇故事中的事情分成幾個步驟完成。也就是當前?Epic 要完成的大致內容。

比如上面的例子 “企業可以搜索簡歷” ，你需要再稍微細化到具體點的內容，怎樣搜索？比如：通過搜索框輸入關鍵字，可以通過省市區，可以通過行業等等。特性主要體現的是 從哪些方面才能完成這個長篇故事。

在 Azure Board 中添加特性，和上面的操作步驟差不多

在列表中
選擇一個長篇故事，點擊前面的 “+” 號

注意彈框的提示，輸入標題，按 “Ctrl + S” 保存或 “Ctrl + Enter” 保存并關閉。

在板中
如果還沒有特性

會在下方多出一個層的文本框，很明顯這就是標題，輸入完回車即可。

如果有特性，點擊獎杯可以展開

數字是告訴你 完成/總共

用戶故事（User Story）

在敏捷開發中，使用用戶故事來體現真正的需求，由于故事一般是由客戶或PO來寫，所以體現的是基于用戶本身的痛點和真實的需求，這樣避免了 曾經的做出來不是客戶想要的 尷尬局面。用戶故事體現的是 我們怎樣開始做 這個需求。

比如剛才的例子：通過行業來搜索簡歷。那故事里就要寫清楚行業有哪些，如何展現，用戶如何操作，怎樣的布局和配色等等。這樣就完全涉及到細節上，因為是真正的要開始開發了。

回到 Azure Board 中，和添加特性的方式一樣

在特性前面點擊 “+” 號

在板中，你需要先切換成 “特性”

用戶故事的寫法，有一個規范格式

---

這種規范，基本告訴了程序員，什么角色做這個操作，大概是怎樣的操作，為什么要這樣做。同樣也會告訴客戶或者PO或者寫用戶故事的人，這樣的需求有沒有必要。

總結

我們已經明白了長篇故事（Epic）、特性（Feature）和用戶情景/故事（User Story）在 Azure Board 中的用法以及如何進行管理，同時也大致了解了敏捷開發是怎么回事，以及如何寫用戶故事的標題。

長篇故事 （模塊：需要完成的需求）-> 特性（階段：將該需求分成幾個階段完成）?-> 情景（功能：描述具體到? 角色-操作-效果）->WorkItem（代碼：具體實現）

下面的圖是我在公司里的真實案例，這樣各位同學應該更有概念了。

?

?

總結

以上是生活随笔為你收集整理的【转】Azure DevOps —— Azure Board 之 长篇故事、特性、用户情景（故事）的用法应用场景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。