軟件領(lǐng)域，到處都是易變、不確定、復(fù)雜、模糊的需求。客戶說不清楚究竟要什么，開發(fā)者聽不明白到底做什么。因此，敏捷軟件開發(fā)方法引入“客戶”角色并使用用戶故事實(shí)時(shí)溝通需求，確保開發(fā)團(tuán)隊(duì)交付用戶真正需要的產(chǎn)品。

用戶故事說起來簡單，用好它卻不是一件容易的事情，團(tuán)隊(duì)一不小心就會(huì)掉進(jìn)各種陷阱。

那么，用戶故事都有哪些常見的陷阱？該如何有效地避開這些坑，高效地使用用戶故事呢？

【陷阱一：用在什么時(shí)候？】

用戶故事，是描述了“什么人用了軟件中的什么功能實(shí)現(xiàn)了什么目的或獲取了什么利益”的一個(gè)記錄。要實(shí)現(xiàn)一個(gè)功能，首先要問這個(gè)功能是為誰服務(wù)的，然后思考用戶為什么要用這個(gè)功能，最后才去思考怎么實(shí)現(xiàn)這個(gè)功能。

那么，哪些事情適合使用用戶故事呢？通常來講，用戶故事是用于業(yè)務(wù)價(jià)值陳述的一種簡便格式，適合各種與用戶直接相關(guān)的需求事項(xiàng)，特別是軟件功能性特性。

對于團(tuán)隊(duì)需要投入時(shí)間完成的一些事項(xiàng)，也可以用戶故事的形式來描述、跟蹤和確認(rèn)。但必須清楚的是，這些事項(xiàng)無法向客戶交付實(shí)際價(jià)值，嚴(yán)格意義上并不能算作“用戶故事”，只是某個(gè)“任務(wù)”的記錄。

還有一些事項(xiàng)，比如基礎(chǔ)架構(gòu)的構(gòu)建，是為交付項(xiàng)目而必須做的基礎(chǔ)工作，使用“用戶故事”來跟蹤當(dāng)然沒問題。但這些工作的用戶是技術(shù)人員本身，以技術(shù)人員的語言來寫，基于共同的技術(shù)語言，則更方便技術(shù)團(tuán)隊(duì)的溝通和交流。

【避坑指南一】

對于每個(gè)代辦事項(xiàng)：

• 先弄清用戶是誰，再想為什么要這么做，最后確定做什么

• 對用戶相關(guān)的需求，使用用戶故事

• 對技術(shù)問題，使用相關(guān)人員聽得明白的共同語言

下列需求或事項(xiàng)，比較適合使用用戶故事來描述、跟蹤和確認(rèn)：

• 功能性需求

• 撰寫文檔、用戶手冊等文檔

• 非功能性需求

• 用戶報(bào)告的缺陷

• 針對不確定性，獲取知識(shí)的原型、概念驗(yàn)證、實(shí)驗(yàn)、探針等知識(shí)獲取性需求。

下列事項(xiàng)，可以使用相關(guān)語言來描述：

• 架構(gòu)、基礎(chǔ)設(shè)施等方面的事項(xiàng)

• 內(nèi)部發(fā)現(xiàn)的功能和代碼問題

• 重構(gòu)等技術(shù)債

【陷阱二：誰來寫】

下個(gè)迭代要開始，但用戶故事還沒有著落。產(chǎn)品待辦事項(xiàng)列表中的用戶故事屈指可數(shù)，遠(yuǎn)不是下個(gè)迭代的全部工作。該誰來寫用戶故事、什么時(shí)候?qū)?，團(tuán)隊(duì)沒有共識(shí)，大家覺得應(yīng)該別人來寫，不是自己的事兒。

用戶故事是團(tuán)隊(duì)的需求描述和溝通方式。那么，應(yīng)該由誰來編寫用戶故事呢？通常并沒有嚴(yán)格的規(guī)定應(yīng)該由誰來負(fù)責(zé)編寫用戶故事。通常的原則是，誰靠近用戶誰優(yōu)先負(fù)責(zé)，也可以授權(quán)給別人。

用戶故事一般是用業(yè)務(wù)語言寫成，因此最好由客戶或產(chǎn)品負(fù)責(zé)人來寫。如果用戶不愿意，開發(fā)團(tuán)隊(duì)可以幫助代行編寫用戶故事。但是，團(tuán)隊(duì)編寫的用戶故事，尤其是驗(yàn)收標(biāo)準(zhǔn)，必須由客戶或產(chǎn)品負(fù)責(zé)人進(jìn)行確認(rèn)。用戶故事和待辦事項(xiàng)列表的優(yōu)先級排序也一定要由能夠代表用戶的角色來確定，比如代理產(chǎn)品負(fù)責(zé)人。

開發(fā)團(tuán)隊(duì)可以通過訪談、問卷調(diào)查、觀察和故事編寫工作坊等形式來開展用戶故事編寫。而故事編寫工作坊是快速創(chuàng)作用戶故事最有效的方法之一，可以在開始每個(gè)發(fā)布計(jì)劃之前舉辦。

【避坑指南二】

編寫用戶故事的職責(zé)，依次降低：

• 項(xiàng)目中的客戶、用戶

• 項(xiàng)目中的市場、業(yè)務(wù)方面的人員

• 產(chǎn)品負(fù)責(zé)人，或代理產(chǎn)品負(fù)責(zé)人

• 研發(fā)團(tuán)隊(duì)中的熟悉用戶和業(yè)務(wù)的業(yè)務(wù)分析人員、測試人員

• 研發(fā)團(tuán)隊(duì)技術(shù)成員

注：在具體的軟件項(xiàng)目實(shí)踐中，很多時(shí)候尤其是在項(xiàng)目前期，團(tuán)隊(duì)通過工作坊的形式來編寫初始的一些粗粒度用戶故事。如果給團(tuán)隊(duì)顯式明確了編寫用戶故事責(zé)任的優(yōu)先級順序，可能會(huì)造成技術(shù)人員覺得編寫用戶故事不是技術(shù)人員的責(zé)任，因而消極甚至拒絕編寫用戶故事。為此，也可以不給團(tuán)隊(duì)明確責(zé)任排序，以促進(jìn)自組織和團(tuán)隊(duì)成員的積極性。

【陷阱三：用戶角色是誰？】

技術(shù)團(tuán)隊(duì)容易陷入“以技術(shù)為中心”思維，自以為是地閉門造車，想當(dāng)然地認(rèn)為自己理解的就是用戶需要的。但用戶是誰，卻不清楚。

有時(shí)候，團(tuán)隊(duì)所認(rèn)為的用戶過于單一抽象，用戶范圍過大、過于抽象，比如“銷售人員”，導(dǎo)致定義不清。而另一個(gè)極端是，用戶角色過于精細(xì)，角色過多，導(dǎo)致團(tuán)隊(duì)對需求的精準(zhǔn)理解產(chǎn)生混亂。

有時(shí)候，開發(fā)的軟件可能是給別的軟件或者系統(tǒng)用的，比如中間件、微服務(wù)等。一個(gè)復(fù)雜系統(tǒng)包含很多各自獨(dú)立但又緊密關(guān)聯(lián)的軟件和組件，各個(gè)部分是整個(gè)軟件或系統(tǒng)的組成部分，有自己的上下游接口。此外，團(tuán)隊(duì)自己內(nèi)部系統(tǒng)的不同組件也可能相互調(diào)用。所以，很難為這類系統(tǒng)或組件定義清楚的“人類”用戶，團(tuán)隊(duì)很容易陷入以技術(shù)為中心的思維，只關(guān)注接口，忘記其實(shí)上下游系統(tǒng)及本身不同部分都是“用戶”——系統(tǒng)用戶。

那么， 該怎么來精準(zhǔn)定義用戶角色呢？

【避坑指南三】

團(tuán)隊(duì)可以使用設(shè)計(jì)思維工具進(jìn)行用戶研究：

• 用戶畫像

• 用戶訪談

• 同理心圖

• 用戶體驗(yàn)地圖

• 干系人圖

針對系統(tǒng)用戶，可以嘗試：

• 定義上游的“供應(yīng)方”和下游的“消費(fèi)者”用戶，它們是軟件系統(tǒng)、組件或者接口。

• “供應(yīng)方”和“消費(fèi)者”加強(qiáng)溝通和協(xié)調(diào)：明確彼此的需要和依賴，比如接口類型、數(shù)據(jù)格式等技術(shù)參數(shù)。

• 將系統(tǒng)用戶的需求納入待辦事項(xiàng)管理：由下游向上游提出需求，編寫用戶故事，明確技術(shù)指標(biāo)，放入上游團(tuán)隊(duì)的待辦事項(xiàng)列表，統(tǒng)一進(jìn)行優(yōu)先級排序，納入發(fā)布計(jì)劃和迭代計(jì)劃。

【陷阱四：使用不規(guī)范】

需求千萬條，價(jià)值第一條；

故事不規(guī)范，交付兩行淚。

日常工作中，諸如格式不完整、用戶不明確、價(jià)值描述不清晰等問題非常常見，而由此導(dǎo)致的交付失敗也時(shí)有發(fā)生。那么，怎么才算是規(guī)范的用戶故事呢？

因此，好的用戶故事，應(yīng)當(dāng)格式規(guī)范、要素完整、各自獨(dú)立。故事之間還要盡量避免相互依賴。用戶故事之間相互依賴，會(huì)導(dǎo)致排列優(yōu)先級時(shí)，或者做迭代規(guī)劃時(shí)出現(xiàn)問題，而且使用戶故事的估計(jì)變得困難。

因此，規(guī)范使用用戶故事，如何做到格式規(guī)范、要素完整、各自獨(dú)立呢？

【避坑指南四】

規(guī)范使用用戶故事，要做到：

• 使用故事標(biāo)準(zhǔn)格式：使用“作為<角色>，我想要<功能>，以實(shí)現(xiàn)<商業(yè)價(jià)值>”模版。

• 遵循 INVEST原則，即：

• 獨(dú)立的

• 可協(xié)商的

• 有價(jià)值的

• 可估算的

• 小的

• 可測試的

• 定義“就緒定義”：定義團(tuán)隊(duì)一致共識(shí)的“就緒狀態(tài)”檢查表。

• 定義“完成定義”：定義團(tuán)隊(duì)一致共識(shí)的“完成定義”檢查表。

• 定義“驗(yàn)收標(biāo)準(zhǔn)”：就如何確認(rèn)和驗(yàn)收用戶故事達(dá)成一致并進(jìn)行測試。

  
  

如果依賴不可避免，則盡量嘗試：

• 重新整合用戶故事，換一種方式對故事進(jìn)行分割。

• 低優(yōu)先級的故事依賴于高優(yōu)先級的故事

• 被依賴的故事給個(gè)較高的故事點(diǎn)，依賴其他故事的給個(gè)較低的故事點(diǎn)

• 將相互依賴的故事放到一個(gè)迭代中進(jìn)行開發(fā)和交付

• 將相互依賴的故事分配給同一個(gè)人

【陷阱五：故事點(diǎn)大PK?承諾】

老板：小王，你看隔壁團(tuán)隊(duì)這個(gè)迭代完成了120個(gè)故事點(diǎn)，為什么你們團(tuán)隊(duì)只完成了50個(gè)？

小王：他們承諾了130個(gè)故事點(diǎn)卻只完成了120個(gè)，而我們承諾了45個(gè)故事點(diǎn)但完成了50個(gè)故事點(diǎn)，還超出了承諾呢。

老板：。。。。。。

故事點(diǎn)考慮了事項(xiàng)的復(fù)雜度、不確定性、工作量及風(fēng)險(xiǎn)等因素，只是要完成工作的一個(gè)大致相對估計(jì)。故事點(diǎn)沒有統(tǒng)一的大小和普遍的度量基準(zhǔn)，不同團(tuán)隊(duì)故事點(diǎn)基準(zhǔn)的設(shè)定不盡相同。

因此，上述情景出現(xiàn)了兩方面的錯(cuò)誤理解：

• 用故事點(diǎn)來橫向比較不同團(tuán)隊(duì)的績效。

• 用故事點(diǎn)估計(jì)當(dāng)做團(tuán)隊(duì)的承諾。

  
  

【避坑指南五】

• 關(guān)注價(jià)值，而非故事點(diǎn)。 關(guān)注迭代交付了多少功能，而非故事點(diǎn)。

• 故事點(diǎn)只用來記錄團(tuán)隊(duì)的工作速率并進(jìn)行迭代計(jì)劃。

• 不做團(tuán)隊(duì)之間的橫向比較。

• 采用相對估算：定義基點(diǎn)之后，其他故事以基點(diǎn)為參照確定大小并進(jìn)行排序。

• 必須理解，估算包含很多不確定性。沒必要追求100%的準(zhǔn)確性，也不是團(tuán)隊(duì)的最終承諾。

• 隨著估算數(shù)值增大，其包含的不確定性、復(fù)雜度和風(fēng)險(xiǎn)也會(huì)成倍增加。采用斐波那契數(shù)列來確定用戶故事的點(diǎn)數(shù)，拉大估算數(shù)值，體現(xiàn)點(diǎn)數(shù)所代表的不確定性和風(fēng)險(xiǎn)的大小。

• 使用規(guī)劃撲克：規(guī)劃撲克是來自于寬帶德爾斐方法的一種集體估算方法，包含了心理學(xué)的某些原理。

來也匆匆！

用戶故事在放入迭代進(jìn)行開發(fā)之前，需要經(jīng)過深度討論、排序，確保用戶故事是“就緒”的。這需要用戶、團(tuán)隊(duì)一起確定一個(gè)明確的“就緒”的定義，明確用戶故事具備了什么條件后才算“準(zhǔn)備好了”，可以納入迭代規(guī)劃進(jìn)行開發(fā)。

“就緒”定義通常是一個(gè)檢查列表，明確列出大家達(dá)成一致共識(shí)的檢查事項(xiàng)，只有滿足該檢查表的各個(gè)條目，才可以將用戶故事納入迭代計(jì)劃進(jìn)行開發(fā)。不滿足“就緒”條件的用戶故事，不應(yīng)該放入迭代計(jì)劃進(jìn)行開發(fā)。

【避坑指南六】

定義“就緒定義”：團(tuán)隊(duì)需要提前就什么是“就緒”達(dá)成一致。

• 明確標(biāo)準(zhǔn)：制定檢查列表，明確列出一致達(dá)成共識(shí)的檢查事項(xiàng)，只有滿足該檢查表的各個(gè)條目，才算“準(zhǔn)備好了”。

• 在團(tuán)隊(duì)或項(xiàng)目范圍內(nèi)，針對不同類型的用戶故事，可以制定不同的“就緒”定義。但無需為每個(gè)故事制定 “就緒定義”。

• 定期回顧“就緒”定義中的條目，根據(jù)實(shí)際對其進(jìn)行更新。

去別匆匆！

用戶故事怎樣才算是完成了呢？如果沒有統(tǒng)一的共識(shí)，很可能出現(xiàn)“自己覺得故事完成了但別人卻不認(rèn)為完成”這樣的情況。

比如，功能代碼寫完就算完成嗎？還是功能測試之后才算完成？還是功能上線到生產(chǎn)環(huán)境才算呢？

又比如，需求級別不同，比如史詩故事、特性和用戶故事，是否要制定完全一致的完成標(biāo)準(zhǔn)呢？用戶故事類型不同，比如功能性、非功能性、探索性的，它們的完成標(biāo)準(zhǔn)是否要一致呢？

還有，團(tuán)隊(duì)眼中的“完成”和用戶眼中的“完成”是否一致？用戶故事最重要的是客戶價(jià)值，團(tuán)隊(duì)“完成”，用戶還需要進(jìn)行最終“完成”的確認(rèn)。

這是兩種不同的“完成”標(biāo)準(zhǔn)。團(tuán)隊(duì)需要確定在迭代級別的“完成”，確保所有必須的工作都做完了。用戶需要驗(yàn)收完成的功能，確認(rèn)收到了滿足需要的軟件功能。

前一種是團(tuán)隊(duì)眼中的“完成定義”，即常說的 Definitions of Done，簡稱DoD；后一種是用戶視角的接收標(biāo)準(zhǔn)，即Acceptance Criteria，簡稱AC。

本文探討了技術(shù)團(tuán)隊(duì)在使用用戶故事過程中常見的問題并提供了應(yīng)對之策。

用戶故事是敏捷軟件開發(fā)的基本實(shí)踐之一，有著十分重要的作用。有效、高效地使用用戶故事管理和跟蹤用戶需求，對軟件項(xiàng)目的成功至關(guān)重要。

編輯：青藍(lán)咨詢

來源于：網(wǎng)絡(luò)，如有侵權(quán)請及時(shí)聯(lián)系我們

【聯(lián)系青藍(lán)咨詢】

地址： 深圳市南山區(qū)高新南一道06號TCL大廈B座3樓309室 （公交站：大沖   地鐵站：一號線高新園C出口） 

    郵編：518057 

    電話：0755-86950769

    郵箱：peixun@shzhchina.com 

    網(wǎng)址：http://www.mycalorietracker.com