《用户故事与敏捷方法》 笔记
最近想學(xué)習(xí)下項(xiàng)目管理方面的方法論，找PMO借了一本書《用戶故事與敏捷方法》 。兩天看完，覺得有些內(nèi)容還是挺有用的，雖然參與敏捷開發(fā)模式有兩年多時(shí)間，實(shí)操和業(yè)務(wù)流程都會(huì)，但再回過頭看一些理論，會(huì)有一些新的啟發(fā)。特地做了一下筆記。
2019-8-21
第1章 概覽
一個(gè)需求可被認(rèn)為是故事（Story），如果一個(gè)故事很大，可稱之為史詩(shī)故事（Epic）
Epic>Story>Task
?
第2章 編寫故事
在這一章中,我們將關(guān)注故事編寫。 為了構(gòu)造好的故事,我們關(guān)注六個(gè)特征。一個(gè)優(yōu)秀的故事應(yīng)該具備以下特點(diǎn):
獨(dú)立的(Independent)
可討論的(Negotiable)
對(duì)用戶或客戶有價(jià)值的(Valuable to Purchasers or Users)
可估計(jì)的(Estimatable)
小的(Small)
可測(cè)試的(Testable)
《探索極限編程》和《重構(gòu)工作手冊(cè)》的作者BillWake,建議用英文縮寫 INVEST來代表這六個(gè)特征(Wake 2003a).
?
可估計(jì)的(Estimatable)：如果故事無法估計(jì)會(huì)因?yàn)殚_發(fā)人員不張我所涉及的技術(shù)，可讓一個(gè)or多個(gè)開發(fā)區(qū)進(jìn)行極限編程（XP）中所謂的探針實(shí)驗(yàn)（spike），探針實(shí)驗(yàn)限制一個(gè)最大時(shí)間量（時(shí)間箱，timebox）。
一個(gè)不可估的故事變成2個(gè)：
1、一個(gè)快速的探針故事；
2、一個(gè)故事（真正實(shí)現(xiàn)功能）
備注這兩個(gè)盡量放在不同的迭代中
?
小的(Small)：分割故事：史詩(shī)故事通常分為：
復(fù)合故事（compound story）：由多個(gè)小的故事組成的史詩(shī)故事
復(fù)雜故事（complex story）：其本身很大且不容易分解的故事
?
故事太小可合并故事
?
第3章 用戶角色建模
用戶角色 角色建模的步驟：
1、頭腦風(fēng)暴，列出初始的用戶角色集合；
2、整理最初的角色集合；
3、整合角色；
4、提煉角色
兩個(gè)額外的技術(shù)：
1、虛構(gòu)人物（最常用的用戶）；
2、極端人物（最少用的用戶），但投入大量時(shí)間不值得
?
第4章 搜集故事
引出和捕捉是不合用的
方法：
1、用戶訪談；開放式問題和背景無關(guān)問題
2、問卷調(diào)查；不建議捕撈故事使用
3、觀察；
4、故事編寫工作坊
?
第5章 與用戶代理合作
用戶的經(jīng)理、開發(fā)經(jīng)理、銷售人員、領(lǐng)域?qū)＜摇⑹袌?chǎng)營(yíng)銷團(tuán)隊(duì)、以前的用戶、客戶、培訓(xùn)師和技術(shù)支持、業(yè)務(wù)分析師或系統(tǒng)分析師、設(shè)立客戶團(tuán)隊(duì)
?
第6章 用戶故事驗(yàn)收測(cè)試
在寫代碼之前寫測(cè)試
客戶定義測(cè)試
測(cè)試是過程的一部分。而不是編碼完成后要做的事
測(cè)試類型：故事測(cè)試主要是功能性測(cè)試
1、用戶交互測(cè)試；
2、可用性測(cè)試；
3、性能測(cè)試；
4、壓力測(cè)試
?
第7章 優(yōu)秀用戶故事準(zhǔn)則
從目標(biāo)故事開始
切蛋糕（將大故事分解成小故事）
編寫封閉的故事
卡片約束（必須要遵守而不需要直接實(shí)現(xiàn)）
根據(jù)實(shí)現(xiàn)時(shí)間來確定故事規(guī)模
不要過早涉及用戶界面？
有些需求并不是故事
在故事中包含用戶角色
只為一個(gè)用戶編寫
以主動(dòng)語態(tài)編寫
由客戶編寫
向故事卡編號(hào)說“不”
不要忘記意圖
?
第8章 估算用戶故事
故事點(diǎn)（story point），NUT（Nebulous Units of Time），一個(gè)故事點(diǎn)的工作量作為一個(gè)理想日的工作。
小結(jié)
用故事點(diǎn)估算故事,故事點(diǎn)是故事復(fù)雜度、工作量或工期的相對(duì)估算。
應(yīng)由團(tuán)隊(duì)估算故事,估算屬于團(tuán)隊(duì)而不是個(gè)人。
通過和其他估算進(jìn)行比較來進(jìn)行三角測(cè)量。
團(tuán)隊(duì)是否使用結(jié)對(duì)編程對(duì)故事點(diǎn)估算沒有影響。結(jié)對(duì)編程影響的是團(tuán)隊(duì)的速率,
不是他們的估算。
?
第9章 發(fā)布計(jì)劃
什么時(shí)候發(fā)布？發(fā)布哪些功能？
排列故事優(yōu)先級(jí)（成本改變優(yōu)先級(jí)，如一個(gè)次重要功能需要開發(fā)時(shí)間較長(zhǎng)，則可降低優(yōu)先級(jí)）
混合優(yōu)先級(jí)。如果在確定一個(gè)故事的優(yōu)先級(jí)時(shí)遇到問題，可能要分割故事
高風(fēng)險(xiǎn)故事
根據(jù)架構(gòu)需要安排優(yōu)先級(jí)
選擇迭代長(zhǎng)度。迭代長(zhǎng)度一般1至4周，如果不確定則盡量選擇短迭代，因?yàn)殚L(zhǎng)迭代更容易犯錯(cuò)
從故事點(diǎn)到預(yù)計(jì)工期。初始速率：1、使用歷史值；2、執(zhí)行一輪初始迭代，使用那輪迭代的速率；3、猜測(cè)。
創(chuàng)建發(fā)布計(jì)劃
?
第10章 迭代計(jì)劃
迭代計(jì)劃概覽
迭代計(jì)劃會(huì)議一般內(nèi)容：
1、討論故事；
2、從故事中分解出任務(wù)；
3、開發(fā)人員承擔(dān)每個(gè)任務(wù)的職責(zé)；（一旦確定故事的所有任務(wù)，需要所有團(tuán)隊(duì)成員自愿執(zhí)行任務(wù)，認(rèn)領(lǐng)。迭代期間可以調(diào)整）
4、討論過所有故事，并接受所有任務(wù)后，開發(fā)人員單獨(dú)估計(jì)他們承擔(dān)的任務(wù)。
估算并確認(rèn)
?
第11章 測(cè)量并監(jiān)控速率
測(cè)量速率
計(jì)劃速率和實(shí)際速率
迭代燃盡圖（每日燃盡圖反映的是剩余工作量，而不是在一個(gè)故事或任務(wù)上所花費(fèi)的工作量）
小結(jié)
計(jì)算速率時(shí)只考慮那些已完成的故事,即通過驗(yàn)收測(cè)試的故事。 不要計(jì)算迭代中團(tuán)隊(duì)未全部完成的故事。
為每輪迭代計(jì)劃和實(shí)際完成的故事點(diǎn)數(shù)畫圖是監(jiān)測(cè)實(shí)際和計(jì)劃速率區(qū)別的好方法。
不要在一兩輪迭代后就忙著預(yù)測(cè)速率趨勢(shì)。
完成一個(gè)任務(wù)或故事所花費(fèi)的實(shí)際小時(shí)數(shù)對(duì)速率沒有影響。
在大家都能看到的公共區(qū)域貼一些大而可見的圖。
累計(jì)故事點(diǎn)圖很有用,因?yàn)槲覀兛梢詮闹锌闯雒枯喌型瓿傻墓适曼c(diǎn)。
迭代燃盡圖展示了用完成的故事點(diǎn)表示的進(jìn)度和剩余故事的改變。
每日燃盡圖在迭代中十分有用,它展示了迭代中每天剩余的小時(shí)數(shù)。
設(shè)計(jì)及檢測(cè)一個(gè)平均每個(gè)故事點(diǎn)出現(xiàn)的缺陷數(shù)目的圖表可以幫助我們發(fā)現(xiàn)團(tuán)隊(duì)速率的提高是不是以犧牲質(zhì)量為代價(jià)。
?
第12章 故事不是什么
故事區(qū)別于其他三種常見的需求方法：用例（use case）、IEEE830軟件需求規(guī)格、交互設(shè)計(jì)場(chǎng)景
用戶故事和應(yīng)用里場(chǎng)景類似，但用例往往比單個(gè)故事要大
?
第13章 用戶故事的優(yōu)勢(shì)
有那么多各種各樣的處理需求的方法,為什么我們要選擇用戶故事?本章我們會(huì)看看與其他方式方法相比，使用用戶故事到底能帶來哪些好處.
用戶故事強(qiáng)調(diào)口頭溝通。
人人都可以理解用戶故事。
用戶故事的大小適合做計(jì)劃。
用戶故事適合于迭代開發(fā)。
用戶故事鼓勵(lì)延遲細(xì)節(jié)。
用戶故事支持隨機(jī)應(yīng)變的開發(fā)。
用戶故事鼓勵(lì)參與性設(shè)計(jì)。
用戶故事傳播隱性知識(shí)。
?
討論完用戶故事的種種好處之后,本章結(jié)束時(shí)會(huì)給出用戶故事幾個(gè)潛在的不足：
1、在大型項(xiàng)目中，故事之間關(guān)系可能錯(cuò)綜復(fù)雜；
2、開發(fā)過程規(guī)定要有需求的可追溯性，離不開額外的文檔；
3、不適用于特大規(guī)模多團(tuán)隊(duì)的結(jié)構(gòu)
?
第14章 用戶故事不良癥兆一覽
小結(jié)
在本章中,我們了解了以下一些不良癥兆:
故事太小
故事互相依賴
鍍金
故事中包含太多的細(xì)節(jié)
過早包含用戶界面細(xì)節(jié)
想得太遠(yuǎn)
故事劃分太過頻繁
很難為故事安排優(yōu)先級(jí)
客戶不愿意寫用戶故事,為故事安排優(yōu)先級(jí)
?
第15章 Scrum與用戶故事
Scrum 是一種迭代和遞增的過程。
Scrum每30天一輪迭代,稱為Sprinto晴公珍黛 品氣課館畫食外必類人
ScrumMaster相當(dāng)于傳統(tǒng)的項(xiàng)目經(jīng)理,但更像是領(lǐng)導(dǎo)者和組織者,而不是經(jīng)理。
一般的Scrum團(tuán)隊(duì)包括4~7個(gè)開發(fā)人員。
產(chǎn)品 Backlog 是一個(gè)待開發(fā)的功能需求列表,里面的條目要么還沒有實(shí)現(xiàn)到產(chǎn)
品中,要么還沒有計(jì)劃在當(dāng)前 Sprint 中開發(fā)。
Sprint Backlog是一個(gè)團(tuán)隊(duì)承諾在當(dāng)前Sprint完成的任務(wù)列表。
在極限編程里面的客戶角色,在Scrum 中稱為產(chǎn)品負(fù)責(zé)人。
產(chǎn)品負(fù)責(zé)人負(fù)責(zé)給產(chǎn)品Backlog排列優(yōu)先級(jí)。
在Sprint開始，團(tuán)隊(duì)從產(chǎn)品Backlog中選擇下一個(gè)Sprint要完成的任務(wù)。
在每日Scrum簡(jiǎn)會(huì)中，每個(gè)團(tuán)隊(duì)成員需要回答三個(gè)問題：我昨天完成了什么？今天我要做什么？我碰到了哪些問題？
每個(gè)Sprint都要完成一部分可以潛在交付的產(chǎn)品功能增量。
在Sprint結(jié)束時(shí)，團(tuán)隊(duì)在Sprint評(píng)審會(huì)議上演示所完成的功能。
?
第16章 其他話題
處理非功能性需求
紙質(zhì)還是軟件？看具體情況
用戶故事和用戶界面
保留故事（卡片）
把小的缺陷報(bào)告用一個(gè)封面故事卡裝訂在一起，并把他們當(dāng)成一個(gè)單一故事
?
第IV部分 一個(gè)完整的實(shí)例
第17-21章 舉了一個(gè)購(gòu)物網(wǎng)站的項(xiàng)目例子
總結(jié)
以上是生活随笔為你收集整理的《用户故事与敏捷方法》 笔记的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 产品读书《用户故事与敏捷方法》
- 下一篇： 用户故事与敏捷方法—估算用户故事