PF-AGUI-60-G01 用戶故事指南

YY/PF/AGUI/60/G01PAGEPAGE12024用戶故事指南文檔編號(hào)：YY/PF/AGUI/60/G01文檔信息：組織級(jí)過程文件文檔名稱：用戶故事指南文檔類別：過程改進(jìn)類密級(jí)：內(nèi)部版本信息：1.0建立日期：2015/12/30創(chuàng)建人：韓亞平審核者：謝東、羅濤批準(zhǔn)人：謝志華批準(zhǔn)日期：2016/01/26文檔修訂記錄版本編號(hào)或者更改記錄編號(hào)*變化狀態(tài)簡要說明（變更內(nèi)容和變更范圍）日期變更人批準(zhǔn)日期批準(zhǔn)人V0.2A新建2015/12/30韓亞平V0.3M修改2016/01/20陳姝、孔令宇V1.0M修改2016/01/21韓亞平*變化狀態(tài)：A——增加，M——修改，D——?jiǎng)h除文檔評(píng)審記錄序號(hào)評(píng)審人角色評(píng)審日期簽字備注1謝東2016/012羅濤2016/013文檔審批信息序號(hào)審批人角色審批日期簽字備注目錄1. 簡介 41.1 指南目的 41.2 適用范圍 41.3 術(shù)語與縮略語 41.4 參考資料 42. 概述 53. 實(shí)施步驟 63.1用戶故事 63.1.1用戶故事模板： 63.1.2用戶故事三個(gè)屬性： 63.1.3優(yōu)秀用戶故事特征（INVEST原則）： 73.2用戶角色模型 83.2.1建立用戶角色模型 83.3用戶故事場景 93.3.1用戶故事場景介紹： 93.3.2場景的類型： 93.3.3場景描述方法： 103.4用戶故事驗(yàn)收標(biāo)準(zhǔn) 103.5用戶故事分級(jí)&拆分 103.5.1拆分原則： 103.5.2用戶故事的大小 103.5.3用戶故事的分級(jí) 103.5.4用戶故事拆分 113.6用戶故事優(yōu)先級(jí) 113.6.1用戶故事優(yōu)先級(jí)排序介紹 113.6.2用戶故事優(yōu)先級(jí)排序放法 113.7用戶故事估算 133.7.1用戶故事估算介紹 133.7.2估算方法 143.7.3開發(fā)速率 154. 常見問答 154.1當(dāng)發(fā)現(xiàn)用戶故事之間互相依賴怎么解決? 154.2用戶故事拆分任務(wù)時(shí)遇到的常見問題有哪些？ 154.3用戶故事的幾種類型？ 164.4用戶故事的幾個(gè)衡量標(biāo)準(zhǔn)是什么？ 164.5用戶故事與用例的區(qū)別有哪些？ 164.6將大的用戶故事分割成小的用戶故事有哪些好處？ 16

簡介

指南目的本指南主要描述編制用戶故事需要關(guān)注的一些關(guān)鍵活動(dòng)和方法。通過本指南能夠引導(dǎo)相關(guān)角色識(shí)別用戶故事、編制用戶故事。適用范圍

本指南適用于所有團(tuán)隊(duì)，指南的主要閱讀者包括執(zhí)行敏捷過程的團(tuán)隊(duì)、敏捷教練、產(chǎn)品負(fù)責(zé)、需求人員、研發(fā)團(tuán)隊(duì)成員等。術(shù)語與縮略語用戶故事：用于描述對(duì)用戶有價(jià)值的功能。用戶故事展現(xiàn)形式主要包含三方面內(nèi)容：用戶故事主題（用于計(jì)劃和備忘）、交談（故事細(xì)化描述）、驗(yàn)收標(biāo)準(zhǔn)（驗(yàn)證故事實(shí)現(xiàn)）；用戶角色（UserRole）：是一組屬性的集合，這些屬性刻畫了一群人的特征以及這群人與系統(tǒng)可能的交互。是使用軟件的用戶的分類。參考資料

《敏捷開發(fā)與用戶故事》《集團(tuán)敏捷研發(fā)管理體系V2.5》概述用戶故事相關(guān)主要過程如下圖所示：說明：序號(hào)活動(dòng)描述角色1提出原始需求客戶向PO提出原始需求客戶/PO/需求人員2進(jìn)行需求規(guī)劃和分解PO采用自頂向下的方式進(jìn)行需求分解，根據(jù)主題級(jí)、史詩級(jí)、用戶故事三層進(jìn)行逐步分解，形成樹形結(jié)構(gòu)的故事。PO/需求人員2.1應(yīng)用場景分析PO根據(jù)客戶的描述進(jìn)行應(yīng)用場景分析，形成場景分析圖，結(jié)合場景分解出不同層級(jí)的用戶故事PO/需求人員/開發(fā)人員/測試人員2.2業(yè)務(wù)流程圖結(jié)合場景，針對(duì)復(fù)雜業(yè)務(wù)形成業(yè)務(wù)流程圖，從業(yè)務(wù)流程途中分解出不同層級(jí)的用戶故事PO/需求人員/開發(fā)人員/測試人員2.3角色建模進(jìn)行用戶角色的建模活動(dòng)，形成產(chǎn)品的角色特征表，作為用戶故事描述的角色基礎(chǔ)PO/需求人員/開發(fā)人員/測試人員3用戶故事活動(dòng)根據(jù)用戶故事樹中的用戶故事，進(jìn)行相關(guān)活動(dòng)，完善用戶故事描述和驗(yàn)收標(biāo)準(zhǔn)等相關(guān)內(nèi)容，為后續(xù)開發(fā)做好準(zhǔn)備PO/需求人員/開發(fā)人員/測試人員3.1業(yè)務(wù)活動(dòng)/操作分析根據(jù)用戶故事主題進(jìn)行用戶故事的細(xì)化描述，針對(duì)細(xì)節(jié)操作和活動(dòng)進(jìn)行闡述，常采用討論方式PO/需求人員/開發(fā)人員/測試人員3.2優(yōu)先級(jí)排序已形成的用戶故事進(jìn)行優(yōu)先級(jí)排序，形成MVP，為后續(xù)開發(fā)順序做好準(zhǔn)備，優(yōu)先級(jí)為單一數(shù)據(jù)PO/需求人員3.3用戶故事估算根據(jù)故事點(diǎn)評(píng)估在此用戶故事規(guī)模PO/需求人員/開發(fā)人員/3.4用戶故事驗(yàn)收標(biāo)準(zhǔn)用戶故事通過的標(biāo)準(zhǔn)。PO/需求人員/測試人員實(shí)施步驟3.1用戶故事3.1.1用戶故事模板：作為一個(gè)用戶故事，必須包含如下的內(nèi)容：主題：采用三段論的方式進(jìn)行用戶故事描述。描述：對(duì)故事的詳細(xì)描述，：故事場景業(yè)務(wù)流程驗(yàn)收標(biāo)準(zhǔn)：優(yōu)先級(jí)：估算值：用戶故事的估算針對(duì)每一部分在后續(xù)章節(jié)中有詳細(xì)的描述3.1.2用戶故事三個(gè)屬性：用戶故事描述了對(duì)用戶、系統(tǒng)或軟件購買者有價(jià)值的功能。其包括：描述：總體描述，用來做計(jì)劃和行為提示，用戶故事描述包含三個(gè)要素：角色、活動(dòng)以及商業(yè)價(jià)值。描述方式為：作為XXX（用戶角色）能夠XXX（動(dòng)作），以便于XXX（目的）其中：用戶角色：誰要使用這個(gè)功能，在本指南中可以采用用戶建模中的角色；活動(dòng)：需要完成什么樣的功能；商業(yè)價(jià)值：為什么需要這個(gè)功能，這個(gè)功能帶來什么樣的價(jià)值。有關(guān)故事的具體化細(xì)節(jié):故事相關(guān)活動(dòng)的細(xì)化說明，主要包含的內(nèi)容：在這個(gè)故事中，每個(gè)角色需要參與的工作（活動(dòng)）及實(shí)現(xiàn)的結(jié)果；在這個(gè)故事中，每個(gè)角色的工作流程；每個(gè)工作流節(jié)點(diǎn)的具體工作內(nèi)容及具體業(yè)務(wù)控制邏輯要求和邏輯條件。包括在故事在團(tuán)隊(duì)討論中內(nèi)容形成的注釋。驗(yàn)收標(biāo)準(zhǔn)：用于表達(dá)和明確故事細(xì)節(jié)且可用于確定故事何時(shí)完成，用于明確團(tuán)隊(duì)完成故事的標(biāo)準(zhǔn)。提示:用戶故事要使用用戶可以接受的業(yè)務(wù)語言來描述故事，不能夠使用技術(shù)語言來描述。用戶故事的質(zhì)量是后續(xù)工作順利完成的基礎(chǔ)，因此盡可能保證用戶故事的質(zhì)量，不要因?yàn)橛脩艄适碌牟磺逦沟迷陂_發(fā)中過多的投入到故事論述中，導(dǎo)致開發(fā)結(jié)果沒有完成。3.1.3優(yōu)秀用戶故事特征（INVEST原則）：I–Independent，獨(dú)立性，可獨(dú)立交付給客戶：要盡可能的讓一個(gè)用戶故事獨(dú)立于其他的用戶故事。用戶故事之間的依賴使得制定計(jì)劃，確定優(yōu)先級(jí)，工作量估算都變得很困難。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。N–Negotiable，可協(xié)商性，便于與客戶交流：一個(gè)用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。一個(gè)用戶故事卡片上只是對(duì)用戶故事的一個(gè)簡短的描述，不包括太多的細(xì)節(jié)。具體的細(xì)節(jié)在溝通階段產(chǎn)出。一個(gè)用戶故事卡帶有了太多的細(xì)節(jié)，實(shí)際上限制了和用戶的溝通。V-Valuable，價(jià)值性，對(duì)客戶有價(jià)值：每個(gè)故事必須對(duì)客戶具有價(jià)值（無論是用戶還是購買方）。一個(gè)讓用戶故事有價(jià)值的好方法是讓客戶來寫下它們。一旦一個(gè)客戶意識(shí)到這是一個(gè)用戶故事并不是一個(gè)契約而且可以進(jìn)行協(xié)商的時(shí)候，他們將非常樂意寫下故事。E-Estimable，估算性，能估計(jì)出工作量：開發(fā)團(tuán)隊(duì)需要去估計(jì)一個(gè)用戶故事以便確定優(yōu)先級(jí)，工作量，安排計(jì)劃。但是讓開發(fā)者難以估計(jì)故事的問題來自：對(duì)于領(lǐng)域知識(shí)的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時(shí)需要把故事切分成小些的）。S-Small，短?。悍纸獾阶畹讓拥挠脩艄适铝６缺M量小，至少在一個(gè)迭代中能完成，一個(gè)好的故事在工作量上要盡量短小，最好不要超過一個(gè)迭代周期的工作量,要確保的是在一個(gè)迭代中能夠完成。用戶故事越大，在安排計(jì)劃，工作量估算等方面的風(fēng)險(xiǎn)就會(huì)越大。T-Testable，可測試性:一個(gè)用戶故事要是可以測試的，以便于確認(rèn)它是可以完成的。如果一個(gè)用戶故事不能夠測試，那么你就無法知道它什么時(shí)候可以完成。一個(gè)不可測試的用戶故事例子：軟件應(yīng)該是易于使用的。3.2用戶角色模型3.2.1建立用戶角色模型建立用戶角色模型即梳理用戶角色:把客戶和開發(fā)人員聚集到一個(gè)房間中，通過頭腦風(fēng)暴，列出初始的用戶角色集合，然后整理最初的角色集合，通過整合角色和提煉角色，最終確定出使用軟件的角色。具體操作方法可以參考如下：所有相關(guān)人員包括開發(fā)人員、需求人員、客戶等均聚集在一起，通過頭腦風(fēng)暴首先列出原始的用戶角色：只需要在卡片中寫出自己想到的角色，不需要討論和評(píng)估；將卡片讀出來，粘貼到展示板中；直到大家沒有新的角色提出；要注意列出的角色是產(chǎn)品實(shí)際使用用戶。初步分類：將第一步形成的用戶角色進(jìn)行初步分類，形成角色集合：將卡片進(jìn)行初步分組，標(biāo)明角色間的關(guān)系；相同的進(jìn)行重疊；包含關(guān)系通過卡片的覆蓋進(jìn)行體現(xiàn)；系統(tǒng)角色盡量是一個(gè)具體的人。整合角色：去掉完全重合的卡片角色，討論中可能會(huì)新增新的卡片；丟棄對(duì)系統(tǒng)不重要的角色。提煉角色，建立角色卡片：經(jīng)過前期的討論，已經(jīng)對(duì)角色之間的關(guān)系有了基本的了解；通過提煉的角色，描述角色特征，角色特征可以從如下幾個(gè)方面進(jìn)行考慮：用戶使用軟件的頻率；用戶在相關(guān)領(lǐng)域的知識(shí)水平；用戶使用軟件和計(jì)算機(jī)的熟悉程度；用戶使用該軟件的目標(biāo)和特點(diǎn)，如用戶特別關(guān)注便捷性、關(guān)注用戶體驗(yàn)；本軟件對(duì)該用戶有幫助的特征；將特征形成用戶角色特征卡片。為了讓角色更加完整，在用戶故事后續(xù)重更加生動(dòng)準(zhǔn)確?？梢赃M(jìn)行如下兩個(gè)角色的補(bǔ)充，根據(jù)產(chǎn)品實(shí)際情況進(jìn)行，非必需。虛擬角色：虛構(gòu)出一個(gè)實(shí)際用戶，闡述他的特點(diǎn)和可能使用的場景，該角色需要真正代表產(chǎn)品的目標(biāo)客戶，作為軟件虛擬使用人員，可以配以名字、照片、相關(guān)信息描述，在項(xiàng)目中可以理解為是真實(shí)存在的。極端角色：可以找到一些遺漏的故事，根據(jù)產(chǎn)品需要決定是否有必要；3.3用戶故事場景3.3.1用戶故事場景介紹：定義：從用戶的角度出發(fā)，描述了一組典型用戶在典型工作環(huán)境下的典型需要、想法、工作習(xí)慣等，是指一個(gè)應(yīng)用(通常就是你的那個(gè)產(chǎn)品)被使用的時(shí)候，用戶“最可能的”所處場景。用戶故事場景的設(shè)計(jì)，主要從以下幾個(gè)方面考慮：對(duì)每一個(gè)場景，設(shè)計(jì)一個(gè)場景入口，就是描述場景如何開始用戶故事主要是描述典型用戶在這個(gè)場景中所處的內(nèi)部和外部環(huán)境（內(nèi)部環(huán)境指心理因素等）需要給場景劃分優(yōu)先級(jí)，并按優(yōu)先級(jí)排序用戶場景有大有小，適度、平衡即可用戶和系統(tǒng)有成百上千種可能的交互情況，在寫場景的時(shí)候要有針對(duì)性用戶故事場景的特征：

1．場景的背景：典型用戶用戶的需求、迫切需要解決的問題假設(shè)行業(yè)背景等2．場景：關(guān)于這個(gè)場景的文字描述：要列出這故事中出彩的地方,例如：軟件的哪些功能讓用戶特別滿意?邏輯和界面設(shè)計(jì)要注意哪些因素?第一次使用的用戶和多次使用的用戶在體驗(yàn)上有何區(qū)別對(duì)待?3．其他參考資料（工作規(guī)程、組織機(jī)構(gòu)圖、工作職責(zé)清單等）場景通常在限定的條件內(nèi)而存在，場景包括時(shí)間、空間、設(shè)備支持、社交及用戶情緒等多個(gè)方面，進(jìn)行應(yīng)用場景的判斷和描述的時(shí)候，盡量把這些都考慮完整。3.3.2場景的類型：基于故事目標(biāo)或者任務(wù)的場景：主要描述用戶想做什么，不包含用戶如何完成任務(wù)的任何信息。精細(xì)化的場景:提供了更多的用戶使用細(xì)節(jié)。這些細(xì)節(jié)能幫助團(tuán)隊(duì)更深入的理解用戶特點(diǎn)。全面的場景描述:場景和人物角色還可以結(jié)合起來，分類呈現(xiàn)不同類型的用戶使用產(chǎn)品的原因，有什么樣的需求，揭示出“什么樣的人”在“什么樣的場景”下會(huì)有“什么樣的行為”。測試場景:說明預(yù)期的用戶是如何完成這個(gè)任務(wù)的所有路徑和步驟，包括用戶可能使用的主要的入口或者其他的入口，供觀察人員和記錄人員在測試中使用。而在測試后，可對(duì)比下你的預(yù)期過程和用戶完成任務(wù)的真實(shí)過程。3.3.3場景描述方法：場景描述中需要明確：環(huán)境-人員-事情-產(chǎn)生的價(jià)值；用戶故事可以采用卡片、故事訪談鏈接、用戶場景截圖、故事板等方式表達(dá)故事的場景。3.4用戶故事驗(yàn)收標(biāo)準(zhǔn)驗(yàn)收標(biāo)準(zhǔn)：定義故事是否完成的標(biāo)準(zhǔn)，讓團(tuán)隊(duì)和產(chǎn)品負(fù)責(zé)人對(duì)此達(dá)成一致面向用戶的價(jià)值設(shè)定驗(yàn)收標(biāo)準(zhǔn)，業(yè)務(wù)驗(yàn)收標(biāo)準(zhǔn)主要包含：PO或需求從業(yè)務(wù)的角度描述此功能的驗(yàn)收標(biāo)準(zhǔn)，在故事進(jìn)入迭代計(jì)劃之前該驗(yàn)收標(biāo)準(zhǔn)明確清晰；按照用戶的需要，產(chǎn)品Backlog條目完成；PO或需求在Sprint結(jié)束時(shí)接受或拒絕接受開發(fā)團(tuán)隊(duì)的工作成果，對(duì)每個(gè)演示的故事和主要缺陷，PO表示接受（符合預(yù)期和驗(yàn)收標(biāo)準(zhǔn)）或拒絕（不符合預(yù)期或不滿足驗(yàn)收標(biāo)準(zhǔn)），并給予團(tuán)隊(duì)反饋或意見；PO或需求根據(jù)用戶的價(jià)值確定功能優(yōu)先級(jí)，并確認(rèn)功能已經(jīng)開發(fā)完成；PO確認(rèn)已經(jīng)達(dá)成產(chǎn)品的投資回報(bào)率(ROI)。3.5用戶故事分級(jí)&拆分3.5.1拆分原則：縮短完成用戶故事的時(shí)間；減少用戶故事大小的差異性；采用逐級(jí)分解細(xì)化方式，最終拆解為用戶故事。3.5.2用戶故事的大小用戶故事的大小與完成時(shí)間不是成正比的，故事增加兩倍，投入時(shí)間可能增加5倍；當(dāng)前我們通過時(shí)間盒的方法控制用戶故事的大小。目前我們的要求是：用戶故事大小不能超過迭代周期。史詩：通常為大一點(diǎn)的用戶故事，通常分為兩種：復(fù)合故事（compoundstory）：由多個(gè)小的故事組成；復(fù)雜故事（complexstory）：本身就很大且不容易分解的故事。通常通過分層的方式體現(xiàn)，有些需要采用探針實(shí)驗(yàn)進(jìn)行驗(yàn)證3.5.3用戶故事的分級(jí)用戶故事可以兩個(gè)維度進(jìn)行劃分：一個(gè)是產(chǎn)品展現(xiàn)形式，一個(gè)是產(chǎn)品顆粒度。產(chǎn)品展現(xiàn)形式分為以下三部分：客戶可見:產(chǎn)品史詩、產(chǎn)品功能、產(chǎn)品增強(qiáng)，描述產(chǎn)品的賣點(diǎn)(展現(xiàn)給客戶)產(chǎn)品經(jīng)理可見:產(chǎn)品優(yōu)化、產(chǎn)品約束、產(chǎn)品條件、產(chǎn)品性能等開發(fā)團(tuán)隊(duì)可見三部分進(jìn)行區(qū)分：產(chǎn)品缺陷，產(chǎn)品重構(gòu)產(chǎn)品顆粒度采用樹形結(jié)構(gòu)的形式進(jìn)行細(xì)分，上級(jí)故事也可稱為史詩級(jí)別的故事。3.5.4用戶故事拆分主要是要從客戶角度對(duì)用戶故事進(jìn)行劃分，具體可以：按照不同操作—即根據(jù)動(dòng)作對(duì)故事進(jìn)行分解，添加、刪除、修改、瀏覽等按照數(shù)據(jù)—即根據(jù)數(shù)據(jù)邊界進(jìn)行分解，可以瀏覽產(chǎn)品名和介紹、可以瀏覽產(chǎn)品價(jià)格按照特性—易用性、性能、兼容性、并發(fā)性等等按照角色—從不同用戶角度按照投入的人力-比如要完成信用卡支付(Visa,Master,AmericanExperess)，可以分成三個(gè)故事來實(shí)現(xiàn)按照實(shí)現(xiàn)復(fù)雜程度、步驟—解為探針實(shí)驗(yàn)調(diào)研以及實(shí)現(xiàn)兩部分進(jìn)行分解；按照流程:即根據(jù)業(yè)務(wù)流程進(jìn)行分段，明確輸入輸出產(chǎn)品缺陷：分為兩類，一類是客戶發(fā)現(xiàn)的，需要展現(xiàn)給用戶，一類是我們自己發(fā)現(xiàn)。3.6用戶故事優(yōu)先級(jí)3.6.1用戶故事優(yōu)先級(jí)排序介紹PO負(fù)責(zé)排序Story，產(chǎn)品總監(jiān)負(fù)責(zé)排序Eipc和拍板有爭議的story，排列優(yōu)先級(jí)時(shí)需要考慮下面幾點(diǎn)：1) 大部分用戶和客戶對(duì)特定特性的渴望程度；2) 小部分重要用戶和客戶對(duì)特定特性的渴望程度；3) 故事之間的互補(bǔ)或依賴關(guān)系。3.6.2用戶故事優(yōu)先級(jí)排序放法Kano模型我們根據(jù)用戶需求重要性將需求分為三種類型：基本型需求>期望性需求>興奮型需求，這三種需求根據(jù)績效指標(biāo)分類就是基本因素、績效因素和激勵(lì)因素。需求類型定義不滿足時(shí)滿足時(shí)基本型需求顧客認(rèn)為產(chǎn)品“必須有”的屬性或功能當(dāng)其特性不充足（不滿足顧客需求）時(shí)，顧客很不滿意當(dāng)其特性充足（滿足顧客需求）時(shí)，無所謂滿意不滿意，顧客充其量是滿意期望型需求要求提供的產(chǎn)品或服務(wù)比較優(yōu)秀，但并不是“必須”的產(chǎn)品屬性或服務(wù)行為有些期望型需求連顧客都不太清楚，但是是他們希望得到的當(dāng)沒有滿意這些需求時(shí)，顧客就不滿意在市場調(diào)查中，顧客談?wù)摰耐ǔＪ瞧谕托枨?，期望型需求在產(chǎn)品中實(shí)現(xiàn)的越多，顧客就越滿意興奮型需求要求提供給顧客一些完全出乎意料的產(chǎn)品屬性或服務(wù)行為，使顧客產(chǎn)生驚喜當(dāng)其特性不充足時(shí)，并且是無關(guān)緊要的特性，則顧客無所謂當(dāng)產(chǎn)品提供了這類需求中的服務(wù)時(shí)，顧客就會(huì)對(duì)產(chǎn)品非常滿意，從而提高顧客的忠誠度通過兩個(gè)問題確定功能的分類：關(guān)于產(chǎn)品中具有這項(xiàng)功能，用戶會(huì)覺得怎樣——功能存在形式關(guān)于產(chǎn)品中沒有這項(xiàng)功能，用戶又會(huì)覺得怎樣——功能缺失形式對(duì)每個(gè)問題采用五點(diǎn)度量方式進(jìn)行問答我希望這樣我預(yù)期就是這樣我沒有意見我可以忍受這樣我不希望這樣答案分類，得到每條需求的分類維護(hù)在維度內(nèi)進(jìn)行數(shù)字優(yōu)先級(jí)排序多人問卷調(diào)查，提高準(zhǔn)確性實(shí)施：通過excel進(jìn)行。相對(duì)權(quán)重法考慮一項(xiàng)功能所帶來的正面益處，和缺乏他所產(chǎn)生的負(fù)面影響。評(píng)估如果實(shí)現(xiàn)它所帶來的收益、如果不實(shí)現(xiàn)它所會(huì)招致的懲罰。同故事點(diǎn)估算一樣，對(duì)收益和懲罰也是采用1-9的尺度進(jìn)行相對(duì)度量。提示：優(yōu)先級(jí)=價(jià)值百分比/成本百分比價(jià)值百分比=功能價(jià)值/價(jià)值總和3.7用戶故事估算3.7.1用戶故事估算介紹故事估算的目的主要是如下幾點(diǎn)：獲取更多的知識(shí)，基于更多的知識(shí)進(jìn)行決策；讓團(tuán)隊(duì)成員更加了解需求，保證需求驗(yàn)證的合理性；營造團(tuán)隊(duì)內(nèi)良好的溝通氛圍；估算不是為了更加的準(zhǔn)確，單純的為了能夠制定合適的迭代計(jì)劃。估算并不是唯一的解決途徑，根據(jù)迭代開發(fā)結(jié)果對(duì)下一次的估算進(jìn)行調(diào)整，從而讓項(xiàng)目的估算更加接近項(xiàng)目的實(shí)際開發(fā)效率，當(dāng)項(xiàng)目團(tuán)隊(duì)全力以赴的時(shí)候，估算就可以越來越弱化。估算的方法有很多，最常用的是故事點(diǎn)估算方法。故事點(diǎn)團(tuán)隊(duì)達(dá)成共識(shí)的一個(gè)代表標(biāo)準(zhǔn)規(guī)模的衡量單位。一個(gè)故事點(diǎn)可以是一個(gè)理想工作日（沒有任何干擾的一個(gè)8小時(shí)工作日）、一個(gè)熟知的功能點(diǎn)（團(tuán)隊(duì)內(nèi)某開發(fā)能力的人完成此的功能點(diǎn)需要的實(shí)際規(guī)模被團(tuán)隊(duì)共同認(rèn)可）。故事點(diǎn)估算就是評(píng)估我們要實(shí)現(xiàn)的用戶故事，相對(duì)于這個(gè)標(biāo)準(zhǔn)故事點(diǎn)的相對(duì)值；通過衡量故事點(diǎn)的評(píng)估，使我們更容易對(duì)團(tuán)隊(duì)有效的工作效率進(jìn)行把握；在這里我們推薦使用理想工作日的方法進(jìn)行估算。故事的估算通常由整個(gè)團(tuán)隊(duì)來進(jìn)行，在這里需要強(qiáng)調(diào)一下與任務(wù)估算的差異，任務(wù)估算通常由承擔(dān)任務(wù)的人直接進(jìn)行。而用戶故事由于是團(tuán)隊(duì)共同的責(zé)任，因此團(tuán)隊(duì)共同對(duì)結(jié)果進(jìn)行負(fù)責(zé)，所以估算由團(tuán)隊(duì)來進(jìn)行，故事的實(shí)現(xiàn)后期由團(tuán)隊(duì)通過站立會(huì)議進(jìn)行集體跟蹤，對(duì)問題集體進(jìn)行處理，屬于團(tuán)隊(duì)共同完成的用戶故事。估算前需要明確估算的范圍，即估算的內(nèi)容包含完成此用戶故事所有的規(guī)模投入時(shí)間，而不是單純的開發(fā)或者測試等單方面的工作投入。3.7.2估算方法Delphi估算方法推薦使用最多并被業(yè)界推崇的Delphi方法（也稱估算撲克），詳細(xì)過程如下：所有團(tuán)隊(duì)成員聚集在一起，包括需求人員和開發(fā)人員以及與故事相關(guān)的所有人；準(zhǔn)備好空白卡片和筆；用戶故事講解人員，選取一個(gè)故事，進(jìn)行闡述，開發(fā)等相關(guān)人員盡可能的發(fā)出疑問，達(dá)成一致；沒有疑問后，每個(gè)開發(fā)人員在卡片上寫出一個(gè)估算值；以一個(gè)標(biāo)準(zhǔn)故事點(diǎn)（理想工作日）為參照，評(píng)估需要多少故事點(diǎn)；寫過后不要給其他人看；所有人同時(shí)翻開卡片，通常差異較大；估算值最高和最低的人，對(duì)估算依據(jù)進(jìn)行解釋。在這個(gè)環(huán)節(jié)不能存在攻擊現(xiàn)象；針對(duì)疑問達(dá)成公示后，再重新進(jìn)行估算；通常2-3輪候，數(shù)據(jù)基本達(dá)成一致，這里并不需要所有卡片都統(tǒng)一成一個(gè)數(shù)字，估算結(jié)果合理即可，不需要絕對(duì)的精確。在討論過程中可以將一些解釋或者注意點(diǎn)、關(guān)鍵活動(dòng)標(biāo)注在卡片上，形成注釋，也可能產(chǎn)生新的故事；提示：估算時(shí)候需要充分考慮，可能遇到的問題和需要執(zhí)行的活動(dòng)；估算時(shí)候需要明確對(duì)一個(gè)故事完成的標(biāo)準(zhǔn)，完成故事需要的活動(dòng)內(nèi)容，如單元測試、自我驗(yàn)證等。三角測量法估算完畢后，將故事點(diǎn)采用三角測量的方法，總體瀏覽一下估算是否存在偏差，是否對(duì)標(biāo)準(zhǔn)故事點(diǎn)理解一直沒有偏差。即以故事點(diǎn)為維度，對(duì)已經(jīng)評(píng)估的故事點(diǎn)根據(jù)估算大小進(jìn)行一下排序，比較一下估算的大小是否與預(yù)期的故事大小順序一致，相同的估算點(diǎn)故事是否大致相同，這樣做是避免在評(píng)估過程中大家對(duì)標(biāo)準(zhǔn)故事點(diǎn)產(chǎn)生偏移。3.7.3開發(fā)速率速率：一個(gè)團(tuán)隊(duì)在于給迭代中完成的故事點(diǎn)數(shù)。根據(jù)速率評(píng)估下一個(gè)迭代的工作內(nèi)容，進(jìn)行計(jì)劃安排，這個(gè)速率一定是常態(tài)的速率。每個(gè)迭代完成后得到這個(gè)迭代的速率后，對(duì)團(tuán)隊(duì)速率的評(píng)估需要考慮如下因素，從而得到一個(gè)團(tuán)隊(duì)常態(tài)的速率：需要評(píng)估本輪迭代工作是否存在異常。例如是否加班，是否本迭代中有其他工作的引入，是否人員變化等。每個(gè)迭代的速率是否平穩(wěn)一致，參照歷史迭代速率。常見問答4.1當(dāng)發(fā)現(xiàn)用戶故事之間互相依賴怎么解決?對(duì)于相互依賴的故事，可以采用以下處理方式：1）將相互依賴的故事合并為一個(gè)故事；2）考慮其它的劃分方法，如根據(jù)動(dòng)作對(duì)故事進(jìn)行分解（增加、刪除、修改）、根據(jù)數(shù)據(jù)邊界進(jìn)行分解；3）在故事卡上標(biāo)明依賴關(guān)系；原則上，用戶故事需要具有獨(dú)立性，我們?cè)诰幹朴脩艄适碌臅r(shí)候，要盡可能避免故事之間存在依賴關(guān)系。故事間的依賴關(guān)系會(huì)產(chǎn)生優(yōu)先級(jí)和規(guī)劃問題，即依賴關(guān)系越復(fù)雜，故事的不確定性就會(huì)越強(qiáng)。一般可以通過組合用戶故事或者分割用戶故事來減少用戶故事間的相互依賴性。如果無法避免依賴，則必須在用戶故事中標(biāo)明此用戶故事對(duì)其他故事的依賴，標(biāo)明依賴的順序。被依賴的故事，優(yōu)先級(jí)必定提高，只有被依賴的用戶故事完成才能繼續(xù)開發(fā)依賴的用戶故事。4.2用戶故事拆分任務(wù)時(shí)遇到的常見問題有哪些？如果故事中某個(gè)任務(wù)特別難估算，則最好將這個(gè)任務(wù)從故事的其它任務(wù)中分離出來；如果一個(gè)故事的任務(wù)可以很容易的分給多個(gè)開發(fā)人員，則分割他們；如果有必要讓客戶了解故事中某一部分的完成情況，則可以把這部分拿出來作為一個(gè)任務(wù)。4.3用戶故事的幾種類型？各種“用戶故事”中，大致可以分為史詩Epic、故事Story、增強(qiáng)Enhancement、缺陷Def