Scrum workflow

收集及整理 User Case

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

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

1. 角色：誰(shuí)要使用這個(gè)功能。
2. 功能：需要完成什么樣的功能。
3. 價(jià)值：為什么需要這個(gè)功能，這個(gè)功能帶來(lái)什么樣的價(jià)值。

用戶故事通常按照如下的格式來(lái)表達(dá)：

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

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

為了構(gòu)造好的用戶故事，我們關(guān)注六個(gè)特征。一個(gè)優(yōu)秀的故事應(yīng)該具備以下特點(diǎn)：

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

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

細(xì)化需求

PD將 User Case 細(xì)化成具體需求，我們可以認(rèn)為這個(gè)過(guò)程是定義問(wèn)題的過(guò)程。

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

KickOff Meeting

Kickoff 會(huì)議應(yīng)該控制在最長(zhǎng)20分鐘以內(nèi),為通氣會(huì).只講解需求,不提出任何解決方案

參會(huì)人員: 需求方,PD,設(shè)計(jì),技術(shù),功能使用方,利益沖突方

出席人員推薦是相關(guān)部門 Leader 或者相關(guān)負(fù)責(zé)人
相關(guān)參會(huì)者必須參加,如果有事,必須指定一個(gè)人到場(chǎng)參加,會(huì)后由指定的人負(fù)責(zé)轉(zhuǎn)述相關(guān)事宜. 并且認(rèn)同指定的人做出的任何決定.

在這個(gè)會(huì)議內(nèi)，需要傳達(dá)的信息有如下幾點(diǎn)。參會(huì)者進(jìn)行討論,提出意見(jiàn). 最終對(duì)以下信息明確并達(dá)成一致:

• 背景與意義
• 目的與目標(biāo)
• 做法、功能點(diǎn)概述
• 需要那些資源
• 初步計(jì)劃(必須清楚 1.時(shí)間點(diǎn),里程碑 2.各個(gè)時(shí)間需要的資源)

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

Solution Design

Done is better than perfect
Move fast and break things

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

需要注意的是：

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

舉個(gè)例子：

付費(fèi)購(gòu)買的月費(fèi)會(huì)員系統(tǒng)
假定簡(jiǎn)單設(shè)計(jì)的feature list應(yīng)該包括:
* 會(huì)員付費(fèi)開(kāi)通
 ** 支付渠道-支付寶
 ** 支付渠道-微信
 ** 支付渠道-銀聯(lián)
 * 會(huì)員續(xù)費(fèi)
 ** 手動(dòng)續(xù)費(fèi)
 ** 自動(dòng)續(xù)費(fèi)
 * 會(huì)員特權(quán)
 ** 特權(quán)1
 ** 特權(quán)2
 * 等級(jí)特權(quán)
 ** 會(huì)員等級(jí)(成長(zhǎng)值)
 **  成長(zhǎng)累計(jì)
 **  成長(zhǎng)折扣
 * 會(huì)員積分兌換

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

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

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

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

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

* 問(wèn)題找錯(cuò)  辛辛苦苦做了一個(gè)世界獨(dú)一無(wú)二的可以吹頭發(fā)的皮鞋，可是用戶沒(méi)這問(wèn)題，做出來(lái)的產(chǎn)品沒(méi)人要。

* 解決方案做錯(cuò)  辛辛苦苦花了一年做了一個(gè)獨(dú)一無(wú)二的可以吹頭發(fā)的皮鞋，可是用戶需要的是可以吹頭發(fā)的手機(jī)，做出來(lái)的產(chǎn)品沒(méi)人要。

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

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

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

Spring Planning Meeting

• 針對(duì)下一迭代周期內(nèi)計(jì)劃交付的結(jié)果進(jìn)行排期，每個(gè)任務(wù)明確到責(zé)任人。
• 通過(guò) T-shirt size 法預(yù)估耗時(shí)。
• 注意預(yù)留用于修復(fù)bug的時(shí)間。

每日站立會(huì)議

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

在會(huì)議上，每個(gè)團(tuán)隊(duì)成員需要回答三個(gè)問(wèn)題：

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

測(cè)試 上線 及 驗(yàn)收

參會(huì)人應(yīng)該在 kickoff 會(huì)議人基礎(chǔ)上包含 測(cè)試 及具體開(kāi)發(fā)者.

這一階段主要是來(lái)驗(yàn)證成果是否滿足了預(yù)期的需求.

沒(méi)有問(wèn)題則準(zhǔn)備上線,有問(wèn)題則匯總問(wèn)題后進(jìn)入下一個(gè)周期循環(huán).

Sprint Retrospective Meeting

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

線上問(wèn)題反饋及響應(yīng)

所有問(wèn)題請(qǐng)直接反饋給PD或測(cè)試, 由 PD或測(cè)試 負(fù)責(zé)記錄并根據(jù)緊急程度決定是否轉(zhuǎn)達(dá)給研發(fā).

針對(duì) Bug 我們暫定4種級(jí)別：

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

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

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

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

Tech Weekend

每月組織1-2次的（外部或內(nèi)部）技術(shù)分享