規(guī)劃的核心：用戶故事一看到這個標(biāo)題，是不是感覺馬上就激動起來了，自從講完敏捷框架之后，我估計大家最激動的地方就在今天這篇文章了。用戶故事這個東西吧，現(xiàn)在已經(jīng)是在敏捷中用來描述需求的通用工具了。但凡提敏捷，必須要問用戶故事。之前我們學(xué)習(xí)過的 待辦事項列表 ，迭代沖刺事項列表 之類的內(nèi)容，記錄的都是用戶故事。在沖刺中，白板、任務(wù)板上貼的，都是用戶故事。那么，真正的用戶故事你知道怎么寫么？ 用戶故事格式用戶故事（User Story）是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事要包括 3 個要素：
通過這個 3 個要素，我們就可以總結(jié)出一個用戶故事的標(biāo)準(zhǔn)格式： 作為一個｛角色｝，我想要｛活動｝，以便于｛商業(yè)價值｝。 比如說我們來一個例子：作為一名“打工人”，我希望“能方便地買到火車票”，以便于“不用大冷天的去火車站排隊”。通過這個用戶故事，12306 誕生了。 當(dāng)然，這個故事的范圍其實有點大了，如何買票、如何選座、怎么在線排隊等等都可以細(xì)化成更細(xì)致的故事。我們也稱這種范圍非常大的故事叫做 史詩 Epic 。這樣的故事其實并不是一個好的故事，而下面這個故事可能就相對來說好一些。 作為“公司的運(yùn)營”，我想要“看到新注冊的用戶數(shù)”，以便于“統(tǒng)計產(chǎn)品拉新的效果”。 需要注意的是，用戶故事盡量不要使用技術(shù)的語言來描述，上面這個故事是有一些偏技術(shù)了。我們應(yīng)該盡量以客戶和相關(guān)方的角度來以故事的形式描述要做的東西。而技術(shù)方面的語言則是在用戶故事在迭代中被分配并拆分成任務(wù)之后的事情。當(dāng)然，對于公司內(nèi)部員工提出的這種用戶故事還是可以接受的，畢竟這些數(shù)據(jù)還不算是特別的技術(shù)上的術(shù)語。 一般的用戶故事都會寫在一張卡片上，也稱為 用戶故事卡 。對于這個 用戶故事卡 ，有這樣一個 3C 原則。
INVEST 原則上面的 3C 原則可以看做是 用戶故事卡 的制作原則，不過其實也隱含著用戶故事的編寫原則。但是，沒有以下這六個特性的 用戶故事 ，就絕對稱不上是一個好的 用戶故事 ，也有不少人會稱這六個原則為 用戶故事 的基本原則。這六個原則的首字母組成的就是 INVEST 這個單詞，很有意思的是，這個 INVEST 的中文意思就是投入。用戶故事確實也是需要我們和團(tuán)隊以及相關(guān)方人員以全身心投入的狀態(tài)來建立和確定的。 獨(dú)立的（Independent）用戶故事之間應(yīng)該是獨(dú)立的，怎么理解呢？就是用戶故事之間沒有相互的依賴。如果用戶故事之間有依賴，那么被依賴的用戶故事就有了天生的優(yōu)先級。當(dāng)然，這個東西也確實是沒有辦法避免的，就像我們要開發(fā)積分功能，那肯定是要先開發(fā)用戶中心功能，而要開發(fā)用戶中心，那必然也得先要有個登錄吧，在用戶表都沒確定的情況下，那么后面和用戶相關(guān)的功能可能真的就沒辦法實現(xiàn)了。 那么就沒辦法了么解決這個問題了嗎？只能說，我們要盡可能要拆小用戶故事，然后在一個發(fā)布周期內(nèi)盡量讓本次發(fā)布內(nèi)的用戶故事減少依賴性。 可協(xié)商性（Negotiable）用戶故事不是像簽訂的合同一樣，簽訂了就不變了，它只是對用戶需求的一種描述，并不包含太多的細(xì)節(jié)。因此，用戶故事應(yīng)該是可以協(xié)商的，如果在一開始就定義了太多限制，那么也就無法更好地溝通和協(xié)商。因為細(xì)節(jié)和限制應(yīng)該是在開發(fā)階段才確定的東西，是在用戶故事分解成任務(wù)之后才進(jìn)行的。同時，開發(fā)者可以參與的協(xié)商也能夠讓用戶故事獲得更多開發(fā)者的贊同和支持。 有價值（Valuable）價值這個詞其實已經(jīng)不用多說了吧。之前專門就價值這個問題已經(jīng)討論過好幾篇文章了。如果用戶故事沒有價值，那我們交付的是什么？不是說好的要以用戶價值為驅(qū)動進(jìn)行交付嘛。最好的方案是讓用戶自己去寫用戶故事，如果不方便的話，那么用戶代理人或者 PO 也應(yīng)該盡量站在用戶的角度去寫。一般的用戶在知道用戶故事并不是確定的文檔待辦事項，也不是合同約束條款的情況下，都會非常愿意去嘗試自己編寫用戶故事的。 可估算的（Estimable）一般來說，故事越大可估算性越差，比如我們上面說的那個史詩型的故事?？此坪芎唵伟。茉诰W(wǎng)上買火車票，那你知道 12306 改過多少次版，想了多少方法才讓我們現(xiàn)在能比較順暢的買到火車票嗎？這就有點像開玩笑時會說的，甲方說需求很簡單，只是做個淘寶而已。這種東西，其實真的太虛了，根本就沒法估算，所以還是那個方案，拆分，一步一步的拆分，必須要足夠小，而且是讓開發(fā)人員能在一個迭代內(nèi)完成的。另外，領(lǐng)域知識對于估算也十分重要，如果沒有領(lǐng)域知識的鋪墊，估算的差距可能也會非常大。敏捷雖說不重視精確的估算，但是相差十萬八千里的那種也是沒法接受的。 小的（Small）這不，馬上就開始講這個小的事情了。一個好的故事在工作量上一定要盡量短小，前面已經(jīng)說過估算誤差的問題了，越小的故事其實估算是越精準(zhǔn)的，而且也要能在一個迭代沖刺周期內(nèi)完成，這個完成指的是測試通過之后一致認(rèn)為的那個“完成”。當(dāng)然，太小了也不是什么好事，瑣碎的故事列表會給維護(hù)帶來很大的麻煩。比如頁面上某個按鈕改個顏色，改個字，這類需求應(yīng)該又合并到一個合適大小的故事中更好。 可測試的（Testable）這個特性對于用戶故事來說非常重要。為什么呢？剛剛我們就講到過“完成”的問題。測試就是可以檢驗是否“完成”的一個標(biāo)準(zhǔn)。另外，用戶故事也為測試用例提供了基礎(chǔ)，并且在劃分任務(wù)的時候，也要以單元測試用例的通過率為標(biāo)準(zhǔn)來衡量任務(wù)的完成情況。因此，它關(guān)乎著我們這個故事如何才能結(jié)束。比如說一個用戶故事是系統(tǒng)應(yīng)該是易于使用的，易于使用這個東西沒法測試，同時它也是沒法估算的。 總結(jié)用戶故事這個東西，有一本非常著名的書，而且也是 PMI-ACP 考試推薦學(xué)習(xí)資料中排名第一的，是考試的必備用書，那就是 XP 創(chuàng)始人 Kent Beck 大神的 《用戶故事與敏捷方法》。不管你是考試還是為了了解學(xué)習(xí)，這本書都是相當(dāng)推薦的一本敏捷入門大作。今天的文章其實并沒有寫太多的用戶故事的例子，主要原因其實也是因為經(jīng)驗不多，之前也就帶過那么一次敏捷團(tuán)隊，而且間隔也比較久了。但是在這本書中有非常多，非常好的例子，真心還是推薦大家買來看一看。 參考文檔： 《某培訓(xùn)機(jī)構(gòu)教材》 《用戶故事與敏捷方法》 《高效通過PMI-ACP考試（第2版）》 《敏捷項目管理與PMI-ACP應(yīng)試指南》 |
|
|
