軟件領(lǐng)域，到處都是易變、不確定、復(fù)雜、模糊的需求?？蛻粽f不清楚究竟要什么，開發(fā)者聽不明白到底做什么。因此，敏捷軟件開發(fā)方法引入“客戶”角色并使用用戶故事實時溝通需求，確保開發(fā)團隊交付用戶真正需要的產(chǎn)品。
用戶故事說起來簡單，用好它卻不是一件容易的事情，團隊一不小心就會掉進(jìn)各種陷阱。
那么，用戶故事都有哪些常見的陷阱？該如何有效地避開這些坑，高效地使用用戶故事呢？
【陷阱一：用在什么時候？】
用戶故事，是描述了“什么人用了軟件中的什么功能實現(xiàn)了什么目的或獲取了什么利益”的一個記錄。要實現(xiàn)一個功能，首先要問這個功能是為誰服務(wù)的，然后思考用戶為什么要用這個功能，最后才去思考怎么實現(xiàn)這個功能。
那么，哪些事情適合使用用戶故事呢？通常來講，用戶故事是用于業(yè)務(wù)價值陳述的一種簡便格式，適合各種與用戶直接相關(guān)的需求事項，特別是軟件功能性特性。
對于團隊需要投入時間完成的一些事項，也可以用戶故事的形式來描述、跟蹤和確認(rèn)。但必須清楚的是，這些事項無法向客戶交付實際價值，嚴(yán)格意義上并不能算作“用戶故事”，只是某個“任務(wù)”的記錄。
還有一些事項，比如基礎(chǔ)架構(gòu)的構(gòu)建，是為交付項目而必須做的基礎(chǔ)工作，使用“用戶故事”來跟蹤當(dāng)然沒問題。但這些工作的用戶是技術(shù)人員本身，以技術(shù)人員的語言來寫，基于共同的技術(shù)語言，則更方便技術(shù)團隊的溝通和交流。
【避坑指南一】
對于每個代辦事項：
-
先弄清用戶是誰，再想為什么要這么做，最后確定做什么
-
對用戶相關(guān)的需求，使用用戶故事
-
對技術(shù)問題，使用相關(guān)人員聽得明白的共同語言
下列需求或事項，比較適合使用用戶故事來描述、跟蹤和確認(rèn)：
-
功能性需求
-
撰寫文檔、用戶手冊等文檔
-
非功能性需求
-
用戶報告的缺陷
-
針對不確定性，獲取知識的原型、概念驗證、實驗、探針等知識獲取性需求。
下列事項，可以使用相關(guān)語言來描述：
-
架構(gòu)、基礎(chǔ)設(shè)施等方面的事項
-
內(nèi)部發(fā)現(xiàn)的功能和代碼問題
-
重構(gòu)等技術(shù)債
【陷阱二：誰來寫】
下個迭代要開始，但用戶故事還沒有著落。產(chǎn)品待辦事項列表中的用戶故事屈指可數(shù)，遠(yuǎn)不是下個迭代的全部工作。該誰來寫用戶故事、什么時候?qū)?，團隊沒有共識，大家覺得應(yīng)該別人來寫，不是自己的事兒。
用戶故事是團隊的需求描述和溝通方式。那么，應(yīng)該由誰來編寫用戶故事呢？通常并沒有嚴(yán)格的規(guī)定應(yīng)該由誰來負(fù)責(zé)編寫用戶故事。通常的原則是，誰靠近用戶誰優(yōu)先負(fù)責(zé)，也可以授權(quán)給別人。
用戶故事一般是用業(yè)務(wù)語言寫成，因此最好由客戶或產(chǎn)品負(fù)責(zé)人來寫。如果用戶不愿意，開發(fā)團隊可以幫助代行編寫用戶故事。但是，團隊編寫的用戶故事，尤其是驗收標(biāo)準(zhǔn)，必須由客戶或產(chǎn)品負(fù)責(zé)人進(jìn)行確認(rèn)。用戶故事和待辦事項列表的優(yōu)先級排序也一定要由能夠代表用戶的角色來確定，比如代理產(chǎn)品負(fù)責(zé)人。
開發(fā)團隊可以通過訪談、問卷調(diào)查、觀察和故事編寫工作坊等形式來開展用戶故事編寫。而故事編寫工作坊是快速創(chuàng)作用戶故事最有效的方法之一，可以在開始每個發(fā)布計劃之前舉辦。
【避坑指南二】
編寫用戶故事的職責(zé)，依次降低：
-
項目中的客戶、用戶
-
項目中的市場、業(yè)務(wù)方面的人員
-
產(chǎn)品負(fù)責(zé)人，或代理產(chǎn)品負(fù)責(zé)人
-
研發(fā)團隊中的熟悉用戶和業(yè)務(wù)的業(yè)務(wù)分析人員、測試人員
-
研發(fā)團隊技術(shù)成員
注：在具體的軟件項目實踐中，很多時候尤其是在項目前期，團隊通過工作坊的形式來編寫初始的一些粗粒度用戶故事。如果給團隊顯式明確了編寫用戶故事責(zé)任的優(yōu)先級順序，可能會造成技術(shù)人員覺得編寫用戶故事不是技術(shù)人員的責(zé)任，因而消極甚至拒絕編寫用戶故事。為此，也可以不給團隊明確責(zé)任排序，以促進(jìn)自組織和團隊成員的積極性。
【陷阱三：用戶角色是誰？】
技術(shù)團隊容易陷入“以技術(shù)為中心”思維，自以為是地閉門造車，想當(dāng)然地認(rèn)為自己理解的就是用戶需要的。但用戶是誰，卻不清楚。
有時候，團隊所認(rèn)為的用戶過于單一抽象，用戶范圍過大、過于抽象，比如“銷售人員”，導(dǎo)致定義不清。而另一個極端是，用戶角色過于精細(xì)，角色過多，導(dǎo)致團隊對需求的精準(zhǔn)理解產(chǎn)生混亂。
有時候，開發(fā)的軟件可能是給別的軟件或者系統(tǒng)用的，比如中間件、微服務(wù)等。一個復(fù)雜系統(tǒng)包含很多各自獨立但又緊密關(guān)聯(lián)的軟件和組件，各個部分是整個軟件或系統(tǒng)的組成部分，有自己的上下游接口。此外，團隊自己內(nèi)部系統(tǒng)的不同組件也可能相互調(diào)用。所以，很難為這類系統(tǒng)或組件定義清楚的“人類”用戶，團隊很容易陷入以技術(shù)為中心的思維，只關(guān)注接口，忘記其實上下游系統(tǒng)及本身不同部分都是“用戶”——系統(tǒng)用戶。
那么， 該怎么來精準(zhǔn)定義用戶角色呢？
【避坑指南三】
團隊可以使用設(shè)計思維工具進(jìn)行用戶研究：
-
用戶畫像
-
用戶訪談
-
同理心圖
-
用戶體驗地圖
-
干系人圖
針對系統(tǒng)用戶，可以嘗試：
-
定義上游的“供應(yīng)方”和下游的“消費者”用戶，它們是軟件系統(tǒng)、組件或者接口。
-
“供應(yīng)方”和“消費者”加強溝通和協(xié)調(diào)：明確彼此的需要和依賴，比如接口類型、數(shù)據(jù)格式等技術(shù)參數(shù)。
-
將系統(tǒng)用戶的需求納入待辦事項管理：由下游向上游提出需求，編寫用戶故事，明確技術(shù)指標(biāo)，放入上游團隊的待辦事項列表，統(tǒng)一進(jìn)行優(yōu)先級排序，納入發(fā)布計劃和迭代計劃。
【陷阱四：使用不規(guī)范】
需求千萬條，價值第一條；
故事不規(guī)范，交付兩行淚。
日常工作中，諸如格式不完整、用戶不明確、價值描述不清晰等問題非常常見，而由此導(dǎo)致的交付失敗也時有發(fā)生。那么，怎么才算是規(guī)范的用戶故事呢？
因此，好的用戶故事，應(yīng)當(dāng)格式規(guī)范、要素完整、各自獨立。故事之間還要盡量避免相互依賴。用戶故事之間相互依賴，會導(dǎo)致排列優(yōu)先級時，或者做迭代規(guī)劃時出現(xiàn)問題，而且使用戶故事的估計變得困難。
因此，規(guī)范使用用戶故事，如何做到格式規(guī)范、要素完整、各自獨立呢？
【避坑指南四】
規(guī)范使用用戶故事，要做到：
-
使用故事標(biāo)準(zhǔn)格式：使用“作為<角色>，我想要<功能>，以實現(xiàn)<商業(yè)價值>”模版。
-
遵循 INVEST原則，即：
-
獨立的
-
可協(xié)商的
-
有價值的
-
可估算的
-
小的
-
可測試的
-
定義“就緒定義”：定義團隊一致共識的“就緒狀態(tài)”檢查表。
-
定義“完成定義”：定義團隊一致共識的“完成定義”檢查表。
-
定義“驗收標(biāo)準(zhǔn)”：就如何確認(rèn)和驗收用戶故事達(dá)成一致并進(jìn)行測試。
如果依賴不可避免，則盡量嘗試：
-
重新整合用戶故事，換一種方式對故事進(jìn)行分割。
-
低優(yōu)先級的故事依賴于高優(yōu)先級的故事
-
被依賴的故事給個較高的故事點，依賴其他故事的給個較低的故事點
-
將相互依賴的故事放到一個迭代中進(jìn)行開發(fā)和交付
-
將相互依賴的故事分配給同一個人
【陷阱五：故事點大PK?承諾】
老板：小王，你看隔壁團隊這個迭代完成了120個故事點，為什么你們團隊只完成了50個？
小王：他們承諾了130個故事點卻只完成了120個，而我們承諾了45個故事點但完成了50個故事點，還超出了承諾呢。
老板：。。。。。。
故事點考慮了事項的復(fù)雜度、不確定性、工作量及風(fēng)險等因素，只是要完成工作的一個大致相對估計。故事點沒有統(tǒng)一的大小和普遍的度量基準(zhǔn)，不同團隊故事點基準(zhǔn)的設(shè)定不盡相同。
因此，上述情景出現(xiàn)了兩方面的錯誤理解：
-
用故事點來橫向比較不同團隊的績效。
-
用故事點估計當(dāng)做團隊的承諾。
【避坑指南五】
-
關(guān)注價值，而非故事點。 關(guān)注迭代交付了多少功能，而非故事點。
-
故事點只用來記錄團隊的工作速率并進(jìn)行迭代計劃。
-
不做團隊之間的橫向比較。
-
采用相對估算：定義基點之后，其他故事以基點為參照確定大小并進(jìn)行排序。
-
必須理解，估算包含很多不確定性。沒必要追求100%的準(zhǔn)確性，也不是團隊的最終承諾。
-
隨著估算數(shù)值增大，其包含的不確定性、復(fù)雜度和風(fēng)險也會成倍增加。采用斐波那契數(shù)列來確定用戶故事的點數(shù)，拉大估算數(shù)值，體現(xiàn)點數(shù)所代表的不確定性和風(fēng)險的大小。
-
使用規(guī)劃撲克：規(guī)劃撲克是來自于寬帶德爾斐方法的一種集體估算方法，包含了心理學(xué)的某些原理。
來也匆匆！
用戶故事在放入迭代進(jìn)行開發(fā)之前，需要經(jīng)過深度討論、排序，確保用戶故事是“就緒”的。這需要用戶、團隊一起確定一個明確的“就緒”的定義，明確用戶故事具備了什么條件后才算“準(zhǔn)備好了”，可以納入迭代規(guī)劃進(jìn)行開發(fā)。
“就緒”定義通常是一個檢查列表，明確列出大家達(dá)成一致共識的檢查事項，只有滿足該檢查表的各個條目，才可以將用戶故事納入迭代計劃進(jìn)行開發(fā)。不滿足“就緒”條件的用戶故事，不應(yīng)該放入迭代計劃進(jìn)行開發(fā)。
【避坑指南六】
定義“就緒定義”：團隊需要提前就什么是“就緒”達(dá)成一致。
-
明確標(biāo)準(zhǔn)：制定檢查列表，明確列出一致達(dá)成共識的檢查事項，只有滿足該檢查表的各個條目，才算“準(zhǔn)備好了”。
-
在團隊或項目范圍內(nèi)，針對不同類型的用戶故事，可以制定不同的“就緒”定義。但無需為每個故事制定 “就緒定義”。
-
定期回顧“就緒”定義中的條目，根據(jù)實際對其進(jìn)行更新。
去別匆匆！
用戶故事怎樣才算是完成了呢？如果沒有統(tǒng)一的共識，很可能出現(xiàn)“自己覺得故事完成了但別人卻不認(rèn)為完成”這樣的情況。
比如，功能代碼寫完就算完成嗎？還是功能測試之后才算完成？還是功能上線到生產(chǎn)環(huán)境才算呢？
又比如，需求級別不同，比如史詩故事、特性和用戶故事，是否要制定完全一致的完成標(biāo)準(zhǔn)呢？用戶故事類型不同，比如功能性、非功能性、探索性的，它們的完成標(biāo)準(zhǔn)是否要一致呢？
還有，團隊眼中的“完成”和用戶眼中的“完成”是否一致？用戶故事最重要的是客戶價值，團隊“完成”，用戶還需要進(jìn)行最終“完成”的確認(rèn)。
這是兩種不同的“完成”標(biāo)準(zhǔn)。團隊需要確定在迭代級別的“完成”，確保所有必須的工作都做完了。用戶需要驗收完成的功能，確認(rèn)收到了滿足需要的軟件功能。
前一種是團隊眼中的“完成定義”，即常說的 Definitions of Done，簡稱DoD；后一種是用戶視角的接收標(biāo)準(zhǔn)，即Acceptance Criteria，簡稱AC。
本文探討了技術(shù)團隊在使用用戶故事過程中常見的問題并提供了應(yīng)對之策。
用戶故事是敏捷軟件開發(fā)的基本實踐之一，有著十分重要的作用。有效、高效地使用用戶故事管理和跟蹤用戶需求，對軟件項目的成功至關(guān)重要。
編輯：青藍(lán)咨詢
來源于：網(wǎng)絡(luò)，如有侵權(quán)請及時聯(lián)系我們
【聯(lián)系青藍(lán)咨詢】
地址： 深圳市南山區(qū)高新南一道06號TCL大廈B座3樓309室 （公交站：大沖 地鐵站：一號線高新園C出口）
郵編：518057
電話：0755-86950769
網(wǎng)址：http://www.mycalorietracker.com
