大多數(shù)人寫用戶故事的時(shí)機(jī)都是錯(cuò)的 | IDCF

來源：徐東偉敏捷教練

作者：徐東偉?

用戶故事對于每個(gè)敏捷小伙伴來說，似乎是再熟悉不過的東西了。然而，雖然我們對用戶故事的寫法如數(shù)家珍，但大多數(shù)人寫用戶故事的時(shí)機(jī)卻是不對的。

What? 時(shí)機(jī)？不對？

別著急，聽我慢慢道來！

你是否對以下的反模式非常熟悉呢？

反模式1：將需求文檔轉(zhuǎn)成故事

這種情況最常發(fā)生在團(tuán)隊(duì)剛剛做敏捷轉(zhuǎn)型時(shí)。那個(gè)時(shí)候已經(jīng)有需求文檔存在了，我們總不能立刻把需求文檔扔到垃圾桶，從零開始寫用戶故事吧，所以大多數(shù)人干的事情就是用需求文檔中的信息填充用戶故事。從表面上看，寫用戶故事的工作就是把需求文檔換一個(gè)格式。

特別是在大公司，業(yè)務(wù)方和研發(fā)團(tuán)隊(duì)又不在一個(gè)團(tuán)隊(duì)，甚至不在一個(gè)部門。在研發(fā)團(tuán)隊(duì)把需求文檔轉(zhuǎn)成一堆用戶故事的同時(shí)，業(yè)務(wù)方還在同時(shí)繼續(xù)寫需求文檔。就這樣，周而復(fù)始，沒完沒了，真的是轉(zhuǎn)不完的用戶故事?。?/span>

如此一來，團(tuán)隊(duì)就困惑了。先寫需求文檔，再轉(zhuǎn)用戶故事，敏捷是不是吃飽了撐的，直接按需求文檔寫代碼不就完了嗎，何必“脫了褲子放屁”呢？

反模式2：只在迭代開始前寫故事

馬上就要開始下個(gè)迭代了，Product Backlog里還沒有東西呢，怎么辦？

那就寫??！一頓狂趕，終于寫完了，足足一個(gè)迭代的，還奔兒詳細(xì)，老有面子了！

這樣做有問題嗎？為啥是反模式？看完后面你自然就明白了！

反模式3：所有故事都太詳細(xì)

有人說了，不管Product Backlog里的故事是打算什么時(shí)候做的，只要放進(jìn)去，就一定要詳細(xì)，工作嘛，一定要像樣！不成熟的想法放進(jìn)去是會惹禍的，也顯得草率?。?/span>這樣做真的可取嗎？

推薦模式

終于到正題了！下面我來聊聊推薦的用戶故事書寫模式。

1）找到需求的始作俑者，就是寫需求文檔的那個(gè)人；

2）請他從現(xiàn)在開始停止寫需求文檔，否則你還是逃脫不了需求文檔轉(zhuǎn)用戶故事的命運(yùn)；

3）請他把要做的事情一股腦全放到Product Backlog中；

• 一定要以用戶的視角來寫；
• 一件事情一條；
• 不管是短期要做的，還是很久以后要做的，都要放進(jìn)去；
• 只寫一句話標(biāo)題，不填寫詳細(xì)內(nèi)容。

把所有要做的東西都放到Product Backlog中的好處是：

• 可以清空大腦，每天開心清爽；
• 需求池作為需求的唯一來源，防止疏漏。

4）請他為Product Backlog中的故事排優(yōu)先級，優(yōu)先級高的放上面，優(yōu)先級低的放下面。

5）看看Product Backlog頂端大概1-2個(gè)迭代的量，故事描述得夠不夠詳細(xì)，有沒有把事情說清楚，拆分的夠不夠細(xì)，能不能放入一個(gè)迭代（通常建議用戶故事最好能在迭代長度的一半時(shí)間內(nèi)完成）。如果沒有，那么就想盡各種辦法去搞定，包括和利益相關(guān)人溝通，當(dāng)然也包括研發(fā)人員。

以上步驟3-步驟5要高頻定期或不定期進(jìn)行循環(huán)（這就是傳說中Product Backlog Refinement的內(nèi)容了），這時(shí)你就會發(fā)現(xiàn)：

• Product Backlog中的故事會隨著時(shí)間推移增加甚至是刪除（如果發(fā)現(xiàn)確實(shí)不需要了）；
• Product Backlog中故事的相對優(yōu)先級會動(dòng)態(tài)調(diào)整。

這樣我們就能夠始終在做當(dāng)前最高優(yōu)先級的事情，而不是當(dāng)初設(shè)定的優(yōu)先級，因?yàn)榄h(huán)境在變，我們的優(yōu)先級也要隨著變！敏捷性由此體現(xiàn)！

注意事項(xiàng)

千萬不要在遙遠(yuǎn)的故事上花費(fèi)大量的時(shí)間，切記切記！一句話標(biāo)題用來占位足夠，再不成可以加上怕自己忘記的幾個(gè)要點(diǎn)。因?yàn)槲磥淼氖聝赫l也說不好，也許過一段時(shí)間想法就變了，或者無限期擱置，甚至有可能不需要了，過早做就是浪費(fèi)！

在Product Backlog頂端的高優(yōu)先級故事，如果拆的更小，也許你會發(fā)現(xiàn)，拆出來的故事可能只有一部分會保持原來的優(yōu)先級，其余的也許可以調(diào)到更低的優(yōu)先級，為其他更高優(yōu)先級的故事讓路。

說明：從一個(gè)想法到一堆的用戶故事，可能會用到用戶畫像、影響地圖、用戶故事地圖等工具來做轉(zhuǎn)化，因?yàn)椴皇潜疚恼f明的重點(diǎn)，所以就不進(jìn)行詳述。

總結(jié)

傳統(tǒng)的需求和敏捷的用戶故事，真的有可能在寫完的時(shí)候長的差不多。我認(rèn)為根本的區(qū)別是它們形成的過程和書寫的時(shí)機(jī)。

用戶的視角、細(xì)致的拆分、漸進(jìn)明細(xì)、優(yōu)先級動(dòng)態(tài)調(diào)整、減少浪費(fèi)、快速響應(yīng)等等優(yōu)勢的綜合體，讓用戶故事在敏捷世界里更具競爭力！

IDCF DevOps黑客馬拉松，獨(dú)創(chuàng)端到端DevOps體驗(yàn)，精益創(chuàng)業(yè)+敏捷開發(fā)+DevOps流水線的完美結(jié)合，2021年僅有的3場公開課，數(shù)千人參與并一致五星推薦的金牌訓(xùn)練營，追求卓越的你一定不能錯(cuò)過！

11月6-7日，深圳站，企業(yè)組隊(duì)參賽&個(gè)人參賽均可，一年等一回，錯(cuò)過等一年，趕緊上車~??