《用戶故事與敏捷方法》 Mike Cohn 著

用戶故事：從客戶角度出發(fā)描述功能。我作為（角色），相要（功能），以此（商業(yè)價(jià)值）；
? ? ? ?* 獨(dú)立的、可討論的、有價(jià)值的（客戶/用戶，商業(yè)價(jià)值）、可估計(jì)的、小的、可測(cè)試的（故事描述中的細(xì)節(jié)和關(guān)注點(diǎn)，注釋）
? ? ? ?*?用戶角色定義的是人，因此需要為用戶考慮、整合和提煉角色，構(gòu)建角色模型、行為規(guī)范，促成角色定義。因此使用角色定義用戶故事（虛構(gòu)人物，創(chuàng)建數(shù)據(jù)、操作流程、模擬系統(tǒng)操作、創(chuàng)建業(yè)務(wù)場(chǎng)影），以抽像到具像，完成用戶故事的測(cè)試。同時(shí)考慮極端用戶（個(gè)性鮮明、操作獨(dú)特），以兼容不同的需要。
? ? ? * 自動(dòng)化完成驗(yàn)收測(cè)試，驗(yàn)收測(cè)試的是缺陷，不是覆蓋率，有所測(cè)重。
用戶期望內(nèi)容，可以、最好以驗(yàn)收測(cè)試的的形式被記錄下來(lái)，傳遞額外信息。--?讓客戶參與進(jìn)來(lái)
高效溝通：組織與客戶的高效溝通，組織內(nèi)部高效溝通；客戶與用戶在項(xiàng)目整個(gè)過(guò)程中全程參與。--?聽起來(lái)很不錯(cuò)，實(shí)際運(yùn)行時(shí)盡量、努力實(shí)現(xiàn)吧
實(shí)現(xiàn)用戶價(jià)值：客戶、用戶，商業(yè)價(jià)值
明確需求的過(guò)程：其實(shí)就是不斷探尋的過(guò)程，不斷重復(fù)，逐步澄清：需求的業(yè)務(wù)本身意義；用戶需求的真實(shí)目的。拆解需求成為不同的故事，對(duì)于開發(fā)者來(lái)講就是估算和做計(jì)劃。
計(jì)劃是展開項(xiàng)目相關(guān)活動(dòng)所依賴的基礎(chǔ) --?所有的評(píng)估最終都要?jiǎng)潥w到時(shí)間限：完成日期、發(fā)布日期
故事點(diǎn)是代表時(shí)間的模糊單位，表地故事的復(fù)雜度、工作量--（無(wú)量綱），速率表示單個(gè)時(shí)間（可能是單位時(shí)間或是一個(gè)迭代 ）可以完成的故事點(diǎn)數(shù)，故事點(diǎn)在同一項(xiàng)目中對(duì)比才有意義
成本是確認(rèn)優(yōu)先級(jí)時(shí)應(yīng)當(dāng)考慮的內(nèi)容
評(píng)估速率時(shí)，只計(jì)劃已經(jīng)完成的故事，以確保評(píng)估的相對(duì)準(zhǔn)確性，同時(shí)保證評(píng)估標(biāo)準(zhǔn)在整個(gè)過(guò)程的一致性：改變完成速率，而不是評(píng)估值

軟件需求確實(shí)被識(shí)別為最常見的痛苦之源。
一目了然，格式一致的用戶故事描述用戶需求。
產(chǎn)出真正價(jià)值的軟件，成果可以被審核、驗(yàn)證，交付使用。
如何在難以接觸到用戶的情況下與充當(dāng)用戶角色的人在一起工作？--?盡可能與真正的用戶工作在一起
不要在項(xiàng)目開始時(shí)就做一套包羅萬(wàn)象的決策。--?項(xiàng)目的決定因素時(shí)刻都在有變化，一成不變的決策無(wú)法完全應(yīng)對(duì)變化。
EPIC，史詩(shī)故事，很大的故事；史詩(shī)故事可以分解為多個(gè)更小的用戶故事。復(fù)合故事，復(fù)雜故事
商業(yè)語(yǔ)言、技術(shù)語(yǔ)言。--?對(duì)待不同的人要用對(duì)方可以聽得懂的話來(lái)講：行話；需求應(yīng)當(dāng)用所有利益相關(guān)者都能聽得懂的語(yǔ)言進(jìn)行描述。
迭代（iterator）->?用戶故事（user story） ->?故事點(diǎn)數(shù)（story point）->?速率（veloicy，單位時(shí)間可以完成的故事點(diǎn)數(shù)）
通過(guò)優(yōu)先級(jí)（可能是成本原因），對(duì)項(xiàng)目運(yùn)行不斷進(jìn)行評(píng)估、調(diào)整，以適應(yīng)新的變化。
保持故事的獨(dú)立性，避免故事間依賴，分割故事，加入故事細(xì)節(jié)
故事卡：簡(jiǎn)單描述 +?必要提醒（驗(yàn)收、測(cè)試）；目的是促進(jìn)對(duì)話，促進(jìn)問(wèn)題的澄清
如果故事不可估計(jì)，可能時(shí)因?yàn)?#xff1a;缺少領(lǐng)域知識(shí)，缺少技術(shù)知識(shí)，故事太大了
故事必須是可測(cè)試的，因此需要定義其驗(yàn)證/驗(yàn)收標(biāo)準(zhǔn)，需要盡可能早的發(fā)現(xiàn)問(wèn)題（使用自動(dòng)化可能是唯一的方法）
故事澄清過(guò)程中需要關(guān)注當(dāng)前發(fā)布（時(shí)間線，速率，問(wèn)題），最終目標(biāo)是長(zhǎng)遠(yuǎn)的終期發(fā)布
需求溝通的過(guò)程要注意技巧：盡可能減少封閉性問(wèn)題、有明確指向的問(wèn)題、有暗示性或?qū)蛐缘膯?wèn)題；盡可能讓問(wèn)題脫了實(shí)際背景，由用戶/客戶自我意識(shí)到真正想要的
快速捕獲故事，由草圖 ->?模型 ->?規(guī)范化，由粗到細(xì)，逐步層級(jí)化；在開發(fā)中由用戶故事形成一系列待辦事項(xiàng)列表，同時(shí)不斷求證
用戶團(tuán)隊(duì)組成應(yīng)多元化：不同的利益相關(guān)者對(duì)故事的描述、實(shí)現(xiàn)細(xì)節(jié)有著不同的理解，由于自身位置、利益、習(xí)慣的不同，因此對(duì)故事的理解會(huì)有較大差別
用戶故事編寫的目的是提醒開發(fā)人員和客戶進(jìn)行對(duì)話
自動(dòng)化需要完成驗(yàn)收測(cè)試用例
三角測(cè)量：評(píng)估時(shí)，將當(dāng)前故事與其他幾個(gè)故事進(jìn)行對(duì)比，確認(rèn)故事點(diǎn)評(píng)估和速率的正確性
迭代：從粗到細(xì)，迭代完成結(jié)束后項(xiàng)目才完成；增量：針對(duì)項(xiàng)目中的某個(gè)功能，每次完成一個(gè)完整的功能，不斷增加項(xiàng)目可實(shí)現(xiàn)的內(nèi)容
避免過(guò)早的捕獲當(dāng)下故事還需要的細(xì)節(jié)，先從高層次、精粒度、抽像的了解和分析故事
不要過(guò)早的涉及用戶界 --?也許這就是為什么要強(qiáng)調(diào)單元測(cè)試的重要性，而將UI層驗(yàn)證放在最末端，一個(gè)問(wèn)題：用戶操作的是UI不是邏輯
將用戶故事轉(zhuǎn)化為故事點(diǎn)，以評(píng)估每個(gè)用戶故事完成的時(shí)間，測(cè)試速率，評(píng)估進(jìn)度，調(diào)整計(jì)劃
控制節(jié)奏，確認(rèn)發(fā)布時(shí)間，確認(rèn)優(yōu)先級(jí)，確認(rèn)發(fā)布內(nèi)容，交付價(jià)值
DSDM，故事優(yōu)先級(jí)排列方法，稱為MoSCoW莫斯科規(guī)則：must必須有，should應(yīng)當(dāng)有，could可以有，won't不會(huì)有
迭代數(shù) =?故事點(diǎn) / 速率
迭代計(jì)劃會(huì)議：討論故事，分解任務(wù)，確認(rèn)承擔(dān)者
Scenario場(chǎng)景 -> Use Case用例 -> User Story用戶故事 ->?Story Point故事點(diǎn)，由大到小
SCRUM是迭代和遞增的過(guò)程。
以使用為中心的設(shè)計(jì)usage centered design，任務(wù)案例 task case
交付周期、迭代周期、速率
XP：溝通、簡(jiǎn)單、反饋、勇氣，communication, simplicicy, feedback, courage

總結(jié)

以上是生活随笔為你收集整理的读书笔记：《用户故事与敏捷方法》的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。