Scrum workflow

收集及整理 User Case

用戶故事是描述對用戶有價值的功能，好的用戶故事應該包括角色、功能和商業(yè)價值三個要素。

用戶故事通常的格式為：作為一個<角色>, 我想要<功能>, 以便于<商業(yè)價值>。一個好的用戶故事包括三個要素：

1. 角色：誰要使用這個功能。
2. 功能：需要完成什么樣的功能。
3. 價值：為什么需要這個功能，這個功能帶來什么樣的價值。

用戶故事通常按照如下的格式來表達：

中文：作為一個<角色>, 我想要<功能>, 以便于<商業(yè)價值>

舉例：“作為招聘網(wǎng)站注冊用戶，我想要查看最近3天發(fā)布的招聘信息，以便于我看到最新的招聘信息”。

為了構造好的用戶故事，我們關注六個特征。一個優(yōu)秀的故事應該具備以下特點：

• 獨立的（Independent）：我們要盡量避免故事間的相互依賴。在對故事排列優(yōu)先級時，或者使用故事做計劃時，故事間的相互依賴會導致工作量估算變得更加困難。通常我們可以通過兩種方法來減少依賴性：1.將相互依賴的故事合并成一個大的、獨立的故事；2.用一個不同的方式去分割故事。
• 可討論的（Negotiable）：故事卡是功能的簡短描述，細節(jié)將在客戶團隊和開發(fā)團隊的討論中產生。故事卡的作用是提醒開發(fā)人員和客戶進行關于需求的對話，它并不是具體的需求本事。一個用戶故事卡帶有了太多的細節(jié)，實際上限制了和用戶的溝通。
• 對用戶或客戶有價值的（Valuable）：用戶故事應該很清晰地體現(xiàn)對用戶或客戶的價值，最好的做法是讓客戶編寫故事。一旦一個客戶意識到這是一個用戶故事并不是一個契約而且可以進行協(xié)商的時候，他們將非常樂意寫下故事。
• 可估算的（Estimable）：開發(fā)團隊需要去估計一個用戶故事以便確定優(yōu)先級，工作量，安排計劃。但是讓開發(fā)者難以估計故事的問題來自：1.開發(fā)人員缺少領域知識；2.開發(fā)人員缺少技術知識；3.故事太大了。
• 小的（Small）：一個好的故事在工作量上要盡量小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風險就會越大。
• 可測試的（Testable）：故事必須是可測試的。成功通過測試可以證明開發(fā)人員正確地實現(xiàn)了故事。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成。一個不可測試的用戶故事例子：用戶必須覺得軟件很好用。

** 此環(huán)節(jié)的產出物為「User Case」**

細化需求

PD將 User Case 細化成具體需求，我們可以認為這個過程是定義問題的過程。

** 此環(huán)節(jié)的產出物為「PRD文檔」 **

KickOff Meeting

Kickoff 會議應該控制在最長20分鐘以內,為通氣會.只講解需求,不提出任何解決方案

參會人員: 需求方,PD,設計,技術,功能使用方,利益沖突方

出席人員推薦是相關部門 Leader 或者相關負責人
相關參會者必須參加,如果有事,必須指定一個人到場參加,會后由指定的人負責轉述相關事宜. 并且認同指定的人做出的任何決定.

在這個會議內，需要傳達的信息有如下幾點。參會者進行討論,提出意見. 最終對以下信息明確并達成一致:

• 背景與意義
• 目的與目標
• 做法、功能點概述
• 需要那些資源
• 初步計劃(必須清楚 1.時間點,里程碑 2.各個時間需要的資源)

** 此環(huán)節(jié)的輸出物為「對上述信息達成的共識」 **

Solution Design

Done is better than perfect
Move fast and break things

在此環(huán)境中PD將依據(jù)上一環(huán)節(jié)達成的共識完成產品原型的設計并針對里程碑完成適當?shù)牡鸾?。同時在整個過程中,要權衡實現(xiàn)原型需要的時間是否符合之前設定的時間點,各個階段的資源調度是否會有問題。

需要注意的是：

• 解決方案是為了在計劃時間內解決計劃任務而采取的方案。在制定整個解決方案的過程中要杜絕追求完美.很多時候我們的想法并沒有得到用戶的認可,也并不知道是否用戶一定能認可,所以需要第一時間上一個完成版本獲得用戶反饋而不是做到自我以為的完美,結果發(fā)現(xiàn)80%的功能沒人使用.小步快走,才能更快的得到反饋進行改進。
• 根據(jù)冰山理論 iceberg_model 你認為的未必真的是你認為的那么簡單,所以產生解決方案的過程中,需要充分進行溝通。

舉個例子：

付費購買的月費會員系統(tǒng)
假定簡單設計的feature list應該包括:
* 會員付費開通
 ** 支付渠道-支付寶
 ** 支付渠道-微信
 ** 支付渠道-銀聯(lián)
 * 會員續(xù)費
 ** 手動續(xù)費
 ** 自動續(xù)費
 * 會員特權
 ** 特權1
 ** 特權2
 * 等級特權
 ** 會員等級(成長值)
 **  成長累計
 **  成長折扣
 * 會員積分兌換

 方案一:每個功能都開發(fā)好后上線版本..耗時4周.

 方案二:
 1. 開發(fā)完成一個支付渠道的會員付費和核心特權 耗時一周 首個里程碑發(fā)布
 2. 開發(fā)會員續(xù)費+部分特權 耗時一周 第二個里程碑發(fā)布
 3. 開發(fā)會員等級系統(tǒng)+部分特權 耗時一周 第三個里程碑發(fā)布
 4. 開發(fā)會員積分兌換+部分特權 耗時一周 第四個里程碑發(fā)布

理想情況下:
方案二比方案一提早上線3周.意味著可以先一步獲取用戶的反饋.多獲得了3周的付費用戶.

試想極端情況:
上線后,發(fā)現(xiàn)根本沒有用戶想為會員買單.  方案一耗時4周得到了這個結論.方案二用了1周.

在精益創(chuàng)業(yè)the_lean_startup 這本書中作者提出了杜絕浪費的理念,在提出解決方案的過程中值得參考,看看是否有造成沒必要的浪費:

* 問題找錯  辛辛苦苦做了一個世界獨一無二的可以吹頭發(fā)的皮鞋，可是用戶沒這問題，做出來的產品沒人要。

* 解決方案做錯  辛辛苦苦花了一年做了一個獨一無二的可以吹頭發(fā)的皮鞋，可是用戶需要的是可以吹頭發(fā)的手機，做出來的產品沒人要。

* 過早優(yōu)化  一個可以吹頭發(fā)的手機都沒賣出去，就在苦苦思考如何把它變得更加輕薄，花大把時間精力追求 0.5cm 的設計。

* 過早擴張  一個可以吹頭發(fā)的皮鞋都沒賣出去，就在苦苦思考如何尋找風投，建廠，找地皮，等等。

** 本環(huán)節(jié)輸出物為PRD文檔及技術實現(xiàn)方案的概要設計 **

Spring Planning Meeting

• 針對下一迭代周期內計劃交付的結果進行排期，每個任務明確到責任人。
• 通過 T-shirt size 法預估耗時。
• 注意預留用于修復bug的時間。

每日站立會議

• 會議準時開始。對于遲到者團隊常常會制定懲罰措施（例如罰款，做俯臥撐，在脖子上掛橡膠雞玩具）
• 不論團隊規(guī)模大小，會議被限制在15分鐘。
• 所有出席者都應站立。（有助于保持會議簡短）
• 會議應在固定地點和每天的同一時間舉行。

在會議上，每個團隊成員需要回答三個問題：

• 昨天你完成了那些工作？
• 今天你打算做什么？
• 完成你的目標是否存在什么障礙？（Scrum主管需要記下這些障礙）

測試 上線 及 驗收

參會人應該在 kickoff 會議人基礎上包含 測試 及具體開發(fā)者.

這一階段主要是來驗證成果是否滿足了預期的需求.

沒有問題則準備上線,有問題則匯總問題后進入下一個周期循環(huán).

Sprint Retrospective Meeting

• 本Spring迭代內計劃交付的功能、成功交付的功能、未交付功能的原因
• 與會者回顧本Spring迭代周期內，覺得做的不錯需要保持的點 以及 覺得需要得到改善的點。 （可以是技術上、產品上、協(xié)助過程中、流程優(yōu)化上 任意的point）

線上問題反饋及響應

所有問題請直接反饋給PD或測試, 由 PD或測試 負責記錄并根據(jù)緊急程度決定是否轉達給研發(fā).

針對 Bug 我們暫定4種級別：

• 1-urgent,系統(tǒng)大面積不可用,必須馬上改,需要申請緊急發(fā)布

• 2-high,明顯的bug,需要修改,下一次發(fā)布修復

• 3-medium,不嚴重的bug,時間夠時下一次發(fā)布修復

• 4-low ,可以忽略的 bug, 視難度及時間決定

Tech Weekend

每月組織1-2次的（外部或內部）技術分享