廢話連篇：

? ? ? ?前段時間連著看了許多有關(guān)提高工作效率的書籍（我管它叫工具書），比如說《金字塔原理》《刻意練習(xí)》《番茄工作法圖解》《麥肯錫方法》《麥肯錫工作法：麥肯錫精英的39個工作習(xí)慣》《麥肯錫工作法：個人競爭力提升50%的7堂課》等，主要是覺得自己在工作效率方面有待提升，再往之前看了一些有關(guān)數(shù)據(jù)分析基礎(chǔ)以及和運(yùn)營方面的書籍比如《誰說菜鳥不會數(shù)據(jù)分析系列》《SQL必知必會》《精益數(shù)據(jù)分析》等以及《參與感》《增長黑客》之類的，當(dāng)然也有一些有關(guān)產(chǎn)品思維和創(chuàng)業(yè)的書籍，如《互聯(lián)網(wǎng)獨(dú)孤九劍》《失控》《必然》《讓大象飛》《精益創(chuàng)業(yè)》等，越往后越覺得需要讀一些很前沿的書籍，最近想閱讀一些有關(guān)用戶和設(shè)計層面的書籍，還真別說，PM最吸引我的地方就是你每天都可以如新生嬰兒一樣不斷的汲取更多領(lǐng)域外的知識，包括思維、溝通、設(shè)計、前瞻性，最重要的是可以讀書啊！小嘚瑟一把，最近加入了一個3年讀書圈，想繼續(xù)自己記筆記的習(xí)慣，已經(jīng)堅持了2年，當(dāng)然除了和思維有關(guān)的也讀了一些文學(xué)類的書籍，偏技術(shù)一些，基本上都記錄在博客里面了，但文學(xué)類的書籍適合交流分享感悟，都記錄在自己的有道云筆記了，讓我們繼續(xù)下一個3年哦！今天廢話多了些（打心里不覺得是廢話^_^）~共勉！！！

導(dǎo)言

? ? ? ?如果果要開始一個敏捷項目，應(yīng)該如何開始和逐步進(jìn)行下去呢？有沒有一些套路是我們可以學(xué)習(xí)和借鑒的呢？其實(shí)在之前了解項目管理的時候，有認(rèn)真了解了一下敏捷開發(fā)，也做過相應(yīng)的筆記，回頭可看《Scrum敏捷開發(fā)》，無論在項目管理還是在日常事務(wù)管理中，其實(shí)一些方法論真的是很有必要的，當(dāng)然如果自己已經(jīng)形成了很好的習(xí)慣就沒必要去改變了，前提是他真的很有效的幫助到你！今天就來和大家分享一下這本我一晚上看完的書o(*￣︶￣*)o

目錄

一 識別用戶

二 與用戶代理合作

三 搜集故事

四 編寫故事

五 估算故事

六 確定故事優(yōu)先級

七 確定團(tuán)隊工作速率

八 創(chuàng)建發(fā)布計劃

九 驗收測試

十 迭代計劃

十一 測量并監(jiān)控速率

補(bǔ)充

---

一 識別用戶

識別盡可能多，全方位全維度的各類型用戶。

• 頭腦風(fēng)暴、整理角色、整合角色、提煉角色

具體操作方法為：讓盡可能多的干系人先各自在卡片上寫下自己認(rèn)為的用戶。然后將卡片貼在墻上，經(jīng)過一輪又一輪的討論，最終達(dá)成一致的意見。

• 兩個額外的技術(shù)

虛擬人物：用戶的假象代表。注意：雖然是假象的，但要將這個用戶盡量的具體，盡量的真實(shí)。
極端人物：一些平時不太容易出現(xiàn)，但確實(shí)存在的人物。（在極端人物上花費(fèi)大量時間是不值得的，切忌揀了芝麻丟了西瓜。）

---

二 與用戶代理合作

• 當(dāng)我們識別用戶后，理想的情況當(dāng)然是想跟真正的用戶開展接下去的工作。然而，在大部分情況下，真正的用戶（就是真正使用這款產(chǎn)品／軟件的人）是可望而不可及的。

實(shí)際情況下，愿意跟我們這些技術(shù)人員聯(lián)系的是他們：用戶的經(jīng)理、開發(fā)經(jīng)理、銷售人員、領(lǐng)域?qū)＜摇⑹袌鰻I銷團(tuán)隊、以前的用戶、客戶、培訓(xùn)師、技術(shù)支持、業(yè)務(wù)分析師或系統(tǒng)分析師。
這些人我們統(tǒng)一稱為：用戶的代理。應(yīng)該如何處理用戶代理的情況呢？
讓我們分兩種情況進(jìn)行討論：

能接觸到用戶代理但訪問受限時：
對策: 邀請幾個到幾十個真正的用戶成立"用戶顧問團(tuán)隊"，顧問團(tuán)隊能夠提出意見和建立，但真正的決定依然有用戶代理來做。

實(shí)在不能接觸到用戶時：

使用多個用戶代理，博采眾長，也能規(guī)避一定的風(fēng)險。

盡早發(fā)布產(chǎn)品，盡早讓真正的用戶能夠使用產(chǎn)品，也就能夠盡早得到真正用戶的反饋。

---

三 搜集故事

方法:

• 用戶訪談
• 問卷調(diào)查
• 觀察
• 故事編寫工作坊：會議，快速捕獲故事最有效辦法，結(jié)合頭腦風(fēng)暴最佳要素和簡單原型法

金句:

• 搜集需求要像拖網(wǎng)（Trawling）一樣：不同大小的網(wǎng)用來捕獲不同大小的需求；需求會像魚一樣，會成長，也可能會死亡；捕獲的過程中，也可能撈到一些廢棄的貨物
• 確定需求是一個漸進(jìn)明細(xì)的過程。一開始無法給出一個明確的需求，但是依然可以給出一個故事來作為"占位符"。

---

四 編寫故事

INVEST

• I：Independent（獨(dú)立的）
• N：Negotiable（可討論的）
• V：Valuable to Purchasers Or Users（對用戶或客戶有價值的）
• E：Estimatable（可估計的）
• S：Small（小的）:對于無法做估計的復(fù)雜故事，將它分解成一個做調(diào)研的故事（用探針實(shí)驗）和一個開發(fā)的故事。
• T：Testable（可測試的）：盡量用自動化測試。

故事的套路：我作為（角色），想要（功能），以此實(shí)現(xiàn)（商業(yè)價值）。。。

---

五 估算故事

• 用故事點(diǎn)進(jìn)行估算，常用一個理想工作日的工作來表示一個故事估算點(diǎn)。
• 估算是團(tuán)隊估算的結(jié)果，不是個人的。（可以采用頭腦風(fēng)暴的方法）
• 通過和其他估算進(jìn)行比較來進(jìn)行三角測量。

---

六 確定故事優(yōu)先級

故事的優(yōu)先級由客戶決定，但也要考慮開發(fā)人員的意見。

敏捷項目與傳統(tǒng)規(guī)范過程區(qū)別
1）傳統(tǒng)規(guī)范過程：在項目早期正確地獲取寫出所有的需求
2）敏捷項目：沒有一種理想辦法可以在一個單一階段獲取所有用戶故事，先做最有價值的東西

如何發(fā)布計劃
發(fā)布計劃排列優(yōu)先級方法：莫斯科（MoSCow）規(guī)則
1）必須有Must，指系統(tǒng)的基本功能
2）應(yīng)該有hould，指很重要但短期內(nèi)有替代解決方法的功能
3）可以有Could，指如果沒有時間就可以在發(fā)布中不予考慮的功能
4）這次不會有Won't have this time，指客戶期望擁有但同時承認(rèn)需要在后續(xù)發(fā)布中實(shí)現(xiàn)的功能

---

七 確定團(tuán)隊工作速率

• 速率：團(tuán)隊在一個迭代周期內(nèi)完成的故事點(diǎn)數(shù)（或期望完成的故事點(diǎn)數(shù)）。

如何確定團(tuán)隊速率

使用歷史值執(zhí)行一輪初始迭代，使用那輪迭代的速率。

猜測：考慮到各種各樣因素的干擾，一般我們把i 輪迭代改進(jìn)的1/3到一半的開發(fā)日作為預(yù)計速率。如一個團(tuán)隊6個人，十個工作日為一個迭代周期，則總的工作日為60,計劃的速率則應(yīng)該為20~30個故事點(diǎn)。

---

八 創(chuàng)建發(fā)布計劃

• 根據(jù)故事的點(diǎn)數(shù)，故事的優(yōu)先級，團(tuán)隊的速率，創(chuàng)建發(fā)布計劃。
• 理想情況下，開發(fā)人員和客戶可以談一個日期范圍，而不是一個具體日期。
• 誠實(shí)的把發(fā)布期限告知開發(fā)人員，而不是故意告訴一個提前的日子。
• 開發(fā)人員和客戶共同選擇迭代長度，難以確定時，請選擇短迭代而不是長迭代。

---

九 驗收測試

• 為什么需要驗收測試？

驗收測試將用戶與開發(fā)人員之間交流的部分更加的明確化和細(xì)化，從而保證了開發(fā)人員的設(shè)計滿足用戶的要求。

• 什么時候?qū)戲炇諟y試呢？

編寫用戶故事的時候（將測試要點(diǎn)紀(jì)錄在故事卡的背面）

在一輪迭代的正式編碼前。

在開發(fā)中或之后的任何時候發(fā)現(xiàn)新的測試的時候。
切忌：在正式編碼要有驗收測試的ＣＡＳＥ．

金句：

• 一個優(yōu)秀的開發(fā)團(tuán)隊會為很多詳細(xì)的用例寫單元測試。
• 測試的是缺陷，而不是覆蓋率。如果一個團(tuán)隊一直強(qiáng)調(diào)我們的測試覆蓋率是多少多少，那么很有可能他們做了很多用戶并不需要的工作。如果測試對產(chǎn)品是有價值的，不管他的覆蓋率是多少，都要繼續(xù)測試下去。反之，一旦測試沒有價值，就立即停掉。（問題是，怎么判定測試是否還有價值呢？）

---

十 迭代計劃

• 其實(shí)就是sprint planning meeting
• 在迭代開始時進(jìn)行這個會議，會議中團(tuán)隊討論每個故事，然后從故事中分解出任務(wù)。每個任務(wù)需要有一個對應(yīng)的負(fù)責(zé)人，以及每個任務(wù)所需的估算時間。
• 團(tuán)隊中需要有人記錄下上述討論的內(nèi)容，可以記錄在項目的白板上。
• 在整輪迭代中，負(fù)責(zé)監(jiān)控自己剩余的工作，同時也需要監(jiān)控隊友剩余的工作。如果很快就能完成自己的工作，就有責(zé)任幫助隊友承擔(dān)部分工作。

---

十一 測量并監(jiān)控速率

• 用集中全部力量完成一個故事的方法會提高團(tuán)隊的意識，好過所有的故事都只完成一部分。也建議一個故事完成后再做下一個。
• 讓程序員覺得增加剩余時間估算和減少是一樣正常的。
• 在公共區(qū)域的一個地方，掛上白板，用黑膠布作為固定的坐標(biāo)軸線，這樣在修改圖的時候不會被擦掉。接著就定期更新下面這三個圖：累計故事點(diǎn)、剩余故事點(diǎn)燃盡圖、剩余小時每日燃盡圖。

---

補(bǔ)充

用戶故事 ：描述了對用戶、系統(tǒng)或軟件購買者有價值功能。

用戶故事的組成
1）一份書面的故事描述，用來做計劃和作為提示；
2）有關(guān)故事的對話，用來具體化故事細(xì)節(jié)；
3）測試，用于表達(dá)和編制故事細(xì)節(jié)且可用于確定故事何時完成。

用戶故事的特征
1）獨(dú)立的
2）可討論的
3）對用戶或客戶有價值的
4）可估計的
5）小的
6）可測試的

用戶故事的優(yōu)勢
1）用戶故事強(qiáng)調(diào)口頭溝通
2）人人都可以理解用戶故事
3）用戶故事適合于迭代開發(fā)
4）用戶故事鼓勵延遲細(xì)節(jié)
5）用戶故事的大小適合做計劃
6）用戶故事支持隨機(jī)應(yīng)變的開發(fā)
7）用戶故事鼓勵參與性設(shè)計
8）用戶故事傳播隱性知識

用戶故事準(zhǔn)則
1）從目標(biāo)故事開始
2）切蛋糕（slicing the cake）
3）編寫封閉的故事，值那種隨著一個有意義的目標(biāo)的實(shí)現(xiàn)而結(jié)束的故事，能讓用戶使用后覺得他完成了某個任務(wù)
4）卡片約束
5）根據(jù)實(shí)現(xiàn)時間來確定故事規(guī)模
6）不要過早涉及用戶界面
7）有些需求并不是故事
8）在故事里包括用戶角色
9）只為一個用戶編寫
10）以主動語態(tài)編寫
11）由客戶編寫故事
12）向故事卡編號說“不”
13）不要忘記意圖

用戶故事的不足
1）在用于大量用戶故事大型項目中，故事間關(guān)系錯綜復(fù)雜，難于捉摸
2）如果開發(fā)過程規(guī)定要有需求可追溯性，必然離不開額外文檔
3）不適用特大規(guī)模，多團(tuán)隊結(jié)構(gòu)

如何估算故事
1）無論什么時候獲得有關(guān)故事新信息，都允許我們之間改變想法
2）適用于史詩故事和小故事
3）不需要花很多時間
4）提供進(jìn)度和剩余工作的有用信息
5）不太精確的估算也不會有太大問題
6）可以用來制定發(fā)布計劃

用戶故事與IEE830軟件需求規(guī)格、用例和交互場景設(shè)計的區(qū)別
1）用戶故事與IEE830需求規(guī)格
a.IEE830側(cè)重于關(guān)注需求的檢查清單，而不是用戶目標(biāo)
b.IEE830在寫下所有需求前，每個需求成本是不可見的
2）用戶故事與用例
a.范圍：故事范圍小，對故事大小有限制
b.完整性
c.壽命：用例作為永久性工作持續(xù)存在，故事不會超過包含他們的迭代
d.用例容易包括用戶界面和細(xì)節(jié)
e.目的：編寫故事是為了更方便發(fā)布計劃和迭代計劃
3）用戶故事與交互場景設(shè)計：范圍和細(xì)節(jié)

Scrum
1）迭代的過程是一種持續(xù)改進(jìn)的過程，類似于雕刻
2）遞增的過程是指團(tuán)隊按照功能點(diǎn)開發(fā)和發(fā)布軟件
3）Scrum和XP都是基于遞增和迭代方式的過程
4）采用30天為周期迭代，稱為Sprint
5）Scrum沒有區(qū)分架構(gòu)師和測試人員角色，而是有產(chǎn)品負(fù)責(zé)人和ScrumMaster
a.產(chǎn)品負(fù)責(zé)人：主要負(fù)責(zé)管理product backlog內(nèi)容和排列優(yōu)先級
b.ScrumMaster：負(fù)責(zé)為團(tuán)隊排除障礙
6）產(chǎn)品backlog：所有待開發(fā)產(chǎn)品功能列表
7）一旦sprint開始，只有團(tuán)隊成員才能向sprint中添加工作
8）每日scrum短會：
a.你昨天做了什么
b.你今天打算做什么
c.有什么困難
9）每日scrum短會目的
讓每個人在自己以及同事面前做出承諾，是團(tuán)隊成員之間的承諾
10）用戶故事、sprint評審會議
好處就是很容易評估sprint中哪些部分已經(jīng)完成
11）用戶故事、每日scrum短會
確保整個團(tuán)隊關(guān)注于完成余下面向客戶和最終用戶的任務(wù)

XP極限編程
1）XP的12種實(shí)踐
a.短交付周期（small releases）：每輪迭代通常是1-3周時間
b.計劃游戲（the planning game）：發(fā)布計劃和迭代計劃名稱
c.重構(gòu)（refactoring）：重組或重寫代碼以改善代碼
d.測試（testing）
e.結(jié)對編程（pair programming）
f.持續(xù)一致的速度（sustainable pace）
g.團(tuán)隊代碼所有權(quán)（team code ownership）
h.編碼標(biāo)注（coding standard）
i.簡單設(shè)計（simple design）
j.隱喻（metaphor）：提供了一個他們?nèi)绾嗡伎枷到y(tǒng)的參照體系
k.持續(xù)集成（continuos intergration）
l.現(xiàn)場客戶（on-site customer）
2）XP的價值
a.溝通
b.簡單
c.反饋
d.勇氣
3）XP的關(guān)鍵原則
a.快速反饋
b.假設(shè)簡單
c.增量變化
d.擁抱變化

其它名詞定義
1）史詩故事（epic）：指故事很大
2）面向瀑布模型和故事驅(qū)動
a.面向瀑布模型：用戶和客戶在搜集需求后到驗收之間的這段時間幾乎都不參與
b.故事驅(qū)動：客戶與用戶在項目過程中全程參與
3）故事卡由客戶團(tuán)隊編寫
a.最了解如何表達(dá)需要實(shí)現(xiàn)需求
b.共同確定故事細(xì)節(jié)和安排故事優(yōu)先級
4）速率：是開發(fā)人員可以在一輪迭代中完成的工作量
5）拖網(wǎng)
描述收集需求的過程，需求像魚一樣，會成長也會死亡，需求會隨著時間推移變化，需要一些技巧來發(fā)現(xiàn)需求
6）故事點(diǎn)代表時間的模糊單位，或叫NUT（XP編程）
7）迭代計劃會議內(nèi)容：
a.討論故事
b.從故事中分解出任務(wù)
c.開發(fā)人員承擔(dān)每個任務(wù)的職責(zé)
d.討論過所有故事，并且接受所有任務(wù)后，開發(fā)人員單獨(dú)估計他們承擔(dān)的任務(wù)，以確保他們不會做出額過于樂觀承諾。
8）迭代計劃是發(fā)布計劃進(jìn)一步計劃，但只在迭代即將開始時才開始做迭代計劃
9）迭代燃盡圖：展示以故事點(diǎn)表示的每輪迭代末剩余工作量
10）計算速率時只考慮那些已完成的故事，即通過驗收測試的故事，不要計算迭代中團(tuán)隊未全部完成的故事。

總結(jié)

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

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