因為之前工作是做產(chǎn)品經(jīng)理，為了及時地迭代產(chǎn)品功能、滿足客戶需求，我之前待的兩個團隊都有實踐過敏捷開發(fā)。

在某一個迭代的需求澄清會上，作為產(chǎn)品經(jīng)理的我準備了下個迭代要做的幾個需求。當時，研發(fā)經(jīng)理提出來說 “需求澄清會跟下個迭代要做什么是沒有關(guān)系的，產(chǎn)品經(jīng)理要講手頭上可講的所有需求。然后，研發(fā)再篩出來可做的需求來安排工作”?！?嗯？？” 心想，要回去系統(tǒng)地再了解看看。

然后回家開始翻起16年就購買的書：《用戶故事與敏捷方法》，作者是Mike Cohn。

《用戶故事與敏捷方法》書封面

如何實踐敏捷？

1. 首先，收集故事

作者提出了收集故事很形象的一個詞，叫“拖網(wǎng)”（trawling）。收集需求的過程，就像捕撈魚一樣，要用不同大小的網(wǎng)來捕獲不同大小的需求。因為需求像魚一樣，會成長，也可能會死亡。重要性可能會降低，有時甚至降低到我們認為這些需求已經(jīng)無效。

搜集故事的方法有：

• 用戶訪談
• 問卷調(diào)查
• 觀察
• 故事編寫工作坊

同時，也可以通過與用戶代理合作來收集故事?？梢院献鞯挠脩舸碛校?/p>

• 用戶的經(jīng)理：比如客戶A是直接使用產(chǎn)品的用戶，那找A的上司
• 開發(fā)經(jīng)理：最壞的選擇之一，除非軟件就是給開發(fā)經(jīng)理用的。要不然開發(fā)往往為了提早使用令人興奮的新技術(shù)，講故事的優(yōu)先級不以產(chǎn)品的“價值”來做排序。
• 銷售人員：最危險的選擇。對銷售人員來說，最重要的故事是那些如果沒有實現(xiàn)，就會導(dǎo)致她“丟單”的故事，因此銷售主導(dǎo)的產(chǎn)品不會有一個全面的藍圖。但這些資源我們要充分利用，通過他們把客戶引薦給我們。

2. 根據(jù)收集來的需求，編寫用戶故事，并放入產(chǎn)品Backlog中

2.1 編寫故事前，先對用戶角色進行建模（約1小時）

方法：列表 >> 整合 >> 排列 >> 提煉

先頭腦風(fēng)暴，將這個產(chǎn)品目標用戶的不同角色進行羅列，列個列表。這里要堅持的原則是，用戶角色定義的是人，而不是其他外部系統(tǒng)。

根據(jù)上面列的用戶角色，再做角色的整合。將多個類似角色，合并成一個單一的角色，也要丟棄對系統(tǒng)成功不太重要的角色。

之后是通過排列角色，展示已選角色之間的關(guān)系。最后，來提煉角色，描繪角色特征。

在這一個角色建模的過程中，我們可以從以下幾點，對該角色進行特征描述：

• 用戶使用軟件的頻率
• 用戶在相關(guān)領(lǐng)域的知識水平
• 用戶使用計算機和軟件的總體水平
• 用戶對當前正在開發(fā)的軟件的熟練程度
• 用戶使用該軟件的總體目標。有些用戶注重實用的便捷性、有些關(guān)注豐富的用戶體驗等等。

2.2 用卡片，記錄用戶故事

記錄故事前，要先明白 “用戶故事不是什么”。

• 不是IEEE830： 故事不是關(guān)于如何編寫軟件需求規(guī)格的指南。比如不能寫成“系統(tǒng)應(yīng)該允許公司使用信用卡支付招聘廣告費用”，主語不應(yīng)該是“系統(tǒng)”，應(yīng)該是用戶角色。
• 不是用例： 用例是對系統(tǒng)之間以及用戶之間交互的一般性描述，比較容易包括用戶界面的細節(jié)。因為用例編寫者會過早地關(guān)注軟件實現(xiàn)，而不是去關(guān)注商業(yè)目標，會失去交流碰撞來完善故事的意義。
• 不是場景： 場景是用戶與計算機交互的詳細描述，跟用戶故事的主要的區(qū)別是范圍和細節(jié)?？匆韵吕樱?
  • 場景可以理解為是交互設(shè)計：Maria 用用戶名和口令登陸到站點。是否所有用戶都需要登錄？或者登錄后是否允許Maria使用某些功能？
  • 故事可以理解為是需求設(shè)計：用戶可以通過電子郵件給好友發(fā)送工作信息。

好，開始記錄故事。

卡片代表的是客戶需求，而不是記錄需求。需求細節(jié)在“對話”中獲得，并在“確認”部分得以記錄。推遲細節(jié)很重要，因為這樣一來，我們在不確定是否真正需要某個新特性時，可以不花過多時間來考慮它。

卡片正面記錄故事

模板：“作為（角色），我想要（功能），以此（商業(yè)價值）?！?/p>

有時，上面還附著另一張卡片寫著驗收條件，也可以寫約束故事卡片（約束卡不需要估算，也不會像普通卡片那樣被安排到迭代中），標注“約束”。

卡片背面寫測試故事的提示語句

可以是簡短、不完整的描述。比如“A可以填寫工作描述”的故事，可以寫成“用空的工作描述來試試”或“用很長的工作描述來試試”等。

3. 召開一個Sprint計劃會

有些團隊會把Sprint需求的說明會和Sprint工作計劃會隔開，我以前在的團隊就是第二周周四是 “需求澄清會”，周五是“Sprint計劃會”。具體看團隊需求的量，以及溝通頻次，哪個合適選哪一種。書里的做法是，將這兩個會議放在一起了，即用“前半段” 和 “下半段” 來不同會議主題切分開了。

3.1 會議前半段，由產(chǎn)品負責(zé)人講解故事

產(chǎn)品負責(zé)人把待開發(fā)的高優(yōu)先級的功能介紹給Scrum團隊，將下個迭代要進行的故事進行講解，沒有必要介紹產(chǎn)品Backlog的所有條目。（看到?jīng)]，我看這本書的目的達到了，找到了答案?。?/p>

團隊成員在講解過程中，不斷提出問題，討論其中的一些用戶故事，細化故事細節(jié)，確定驗收標準。

3.2 會議下半段，團隊決定下一迭代工作量

團隊成員用計劃撲克估算故事點。程序員估算一個故事時，要注意，應(yīng)考慮完成這個故事需做的所有事。比如要全盤考慮測試代碼、和客戶討論、可能幫助客戶計劃或自動化驗收測試等諸多因素，不只是要考慮敲代碼的時間。

?由程序員將故事分成一些小的任務(wù)，并估算工作時間后，根據(jù)歷史值或預(yù)測來確定下個迭代的工作量，即確定要完成多少個故事點的需求。

之后，將故事放入Sprint Backlog中，并按照優(yōu)先級排序。排列優(yōu)先級需要考慮的事項有：

• 大部分用戶和客戶對特定特性的渴望程度。
• 小部分重要用戶和客戶對特定特性的渴望程度。
• 故事之間的關(guān)系。例如，“縮小”功能，這個故事的優(yōu)先級可能不高，但是它可能被看作是高優(yōu)先級的，因為它與高優(yōu)先級的另一個故事“放大”互補。

4. 執(zhí)行Sprint

4.1 初始階段，各同學(xué)要干嘛

準備一個Dashboard，將故事卡片和任務(wù)卡片都貼在白板上

Sprint一開始，將故事卡片和任務(wù)卡片都放在白板的Todo欄，團隊成員按照故事的優(yōu)先級挑選任務(wù)，將任務(wù)卡片挪到Doing欄。

故事的任務(wù)完成后，產(chǎn)品負責(zé)人驗收并確認故事已完成，將故事卡片挪到Done欄。

確認測試用例

故事開發(fā)的初始階段，測試人員和產(chǎn)品負責(zé)人一起確認測試用例。

注意，只有團隊成員才向Sprint添加工作

即使是CEO也不能讓團隊去做產(chǎn)品負責(zé)人沒有提出的工作。產(chǎn)品負責(zé)人也不可以改變主意，往該Sprint添加更多的功能。只有在團隊覺得，自己已經(jīng)把Sprint承諾的所有任務(wù)都完成的前提下，才可以向Sprint中增加新的故事。

如果，真有十分重要的事情發(fā)生了，需要調(diào)整，那就把現(xiàn)在的Sprint取消，重新開新的Sprint計劃會，然后啟動新的Sprint。

4.2 Sprint每日例會

會議組織者確保所有人只回答3個問題：

• 昨天做了什么？
• 今天打算做什么？
• 有什么困難？

4.3 監(jiān)控Sprint速率

有一個注意點，不用實際小時作為速率。計算速率是用迭代開始前分配的故事點數(shù)來計算。一旦迭代完成，就不要改變迭代中團隊獲得的任何故事點數(shù)。舉個例子，假如一個故事估算是4個故事點，但其實更大。后來團隊發(fā)現(xiàn)他們應(yīng)該估7個故事點。在計算速率時，這個故事應(yīng)該算4個點，而不是7個點。

主要的可視圖表有：

• 計劃速率 vs .實際速率對比圖

  • 圖：計劃速率和實際速率

• 累計計劃故事點和實際故事點：可以看出每輪迭代中完成的故事點

  • 圖：累計計劃和實際故事點

• 迭代燃盡圖：更好展現(xiàn)項目的整體進展

  • 圖：燃盡圖說明

4.4 故事驗收測試

測試工作可以包括從故事卡背面寫下測試描述開始，到將測試放入到自動化測試工具中的所有工作。一般在下面這些時候?qū)憸y試：

• 開發(fā)人員和客戶討論故事且需要記錄明確的細節(jié)時
• 在迭代開始時，在寫代碼前作為一項專門的任務(wù)
• 在開發(fā)中或之后的任何時候發(fā)現(xiàn)新的測試時

測試類型有：

• 用戶交互測試：確保所有交互組建如期工作
• 可用性測試：確保程序好用
• 性能測試：測量應(yīng)用程序在各種負荷下的工作狀況
• 壓力測試：使應(yīng)用程序在用戶和事務(wù)的極限值情況或其他任何讓程序處在壓力下的情況運行

4.5 確定發(fā)布計劃

如何確定發(fā)布功能優(yōu)先級方面，可借用來自DSDM中排列優(yōu)先級的方法，稱之為莫斯科（MoSCoW）規(guī)則：

• 必須有（Must have）：系統(tǒng)的基本功能
• 應(yīng)該有（Should have）：很重要但短期內(nèi)有替代解決方法的功能
• 可以有（Could have）：如果沒時間就可以在發(fā)布中不予考慮的功能
• 這次不會有（Won't have this time）：客戶期望擁有但同時承認需要在后續(xù)發(fā)布中實現(xiàn)的功能

5. Sprint評審會

由開發(fā)人員演示本期迭代已開發(fā)的內(nèi)容，團隊審視自己是否達到了Sprint目標。

以上是一個完整敏捷迭代生命周期中的流程工作，比較簡潔。如有任何問題，可留言繼續(xù)交流。