前提

我以前在之前的文章里大概介紹了 Azure Board 的基本使用，可以回看《Azure Board 的基本使用》。如果你想使用 Azure Board 來安排工作的話，請?zhí)崆傲私狻睹艚蓍_發(fā)》的相關(guān)知識。

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

使用 Backlog 來做計劃

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

產(chǎn)品負責(zé)人（PO）或項目經(jīng)理需要把要做的事情預(yù)先的在 Backlog 中記錄下來。在敏捷中需要把每一個功能單獨的寫出來，而不是傳統(tǒng)的文檔模式。

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

長篇故事（Epic）

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

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

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

特性（Feature）

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

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

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

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

注意彈框的提示，輸入標(biāo)題，按 “Ctrl + S” 保存或 “Ctrl + Enter” 保存并關(guān)閉。

在板中
如果還沒有特性

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

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

數(shù)字是告訴你 完成/總共

用戶故事（User Story）

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

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

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

在特性前面點擊 “+” 號

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

用戶故事的寫法，有一個規(guī)范格式

---

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

總結(jié)

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

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

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

?

?

總結(jié)

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

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