前提

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

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

使用 Backlog 來(lái)做計(jì)劃

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

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

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

長(zhǎng)篇故事（Epic）

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

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

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

特性（Feature）

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

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

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

在列表中
選擇一個(gè)長(zhǎng)篇故事，點(diǎn)擊前面的 “+” 號(hào)

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

在板中
如果還沒(méi)有特性

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

如果有特性，點(diǎn)擊獎(jiǎng)杯可以展開(kāi)

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

用戶(hù)故事（User Story）

在敏捷開(kāi)發(fā)中，使用用戶(hù)故事來(lái)體現(xiàn)真正的需求，由于故事一般是由客戶(hù)或PO來(lái)寫(xiě)，所以體現(xiàn)的是基于用戶(hù)本身的痛點(diǎn)和真實(shí)的需求，這樣避免了 曾經(jīng)的做出來(lái)不是客戶(hù)想要的 尷尬局面。用戶(hù)故事體現(xiàn)的是 我們?cè)鯓娱_(kāi)始做 這個(gè)需求。

比如剛才的例子：通過(guò)行業(yè)來(lái)搜索簡(jiǎn)歷。那故事里就要寫(xiě)清楚行業(yè)有哪些，如何展現(xiàn)，用戶(hù)如何操作，怎樣的布局和配色等等。這樣就完全涉及到細(xì)節(jié)上，因?yàn)槭钦嬲囊_(kāi)始開(kāi)發(fā)了。

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

在特性前面點(diǎn)擊 “+” 號(hào)

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

用戶(hù)故事的寫(xiě)法，有一個(gè)規(guī)范格式

---

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

總結(jié)

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

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

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

?

?

總結(jié)

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

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