假設(shè)你在一個(gè)使用敏捷軟件開(kāi)發(fā)流程的項(xiàng)目組，但是，你們組沒(méi)有做嚴(yán)格的kickoff。某一天你領(lǐng)了一個(gè)文件上傳的用戶故事卡的需求，你覺(jué)得很簡(jiǎn)單，因此沒(méi)有做kickoff，就開(kāi)始開(kāi)發(fā)了。

花了2天時(shí)間，你自認(rèn)為寫(xiě)了一個(gè)很漂亮的文件上傳模塊。但是，在需求驗(yàn)收環(huán)節(jié)結(jié)果卻是，你的實(shí)現(xiàn)，業(yè)務(wù)分析人員想要的樣子，測(cè)試人員以為的樣子，這三者竟然都不一樣。

這個(gè)結(jié)果無(wú)疑是一個(gè)悲劇，經(jīng)過(guò)一番思考，我們會(huì)發(fā)現(xiàn)這個(gè)問(wèn)題的根因是：與這個(gè)story相關(guān)的人都犯了同樣的一個(gè)錯(cuò)誤：做了一個(gè)包含以下兩點(diǎn)的假設(shè)：
1： 我對(duì)這個(gè)需求的理解是正確的
2：其他人的理解和我的理解相同

如果繼續(xù)發(fā)掘，會(huì)發(fā)現(xiàn)讓大家產(chǎn)生偏差的理解的材料，卻是唯一的：那張唯一的用戶故事卡。

那為什么僅僅只是憑借那張包含文字描述，或許還輔以圖片的用戶故事卡, 無(wú)法傳達(dá)出唯一的，準(zhǔn)確的需求呢？為了回答這個(gè)問(wèn)題，有必要先來(lái)認(rèn)識(shí)一下用戶故事卡。

用戶故事是什么，不是什么

在《用戶故事與敏捷方法》一書(shū)里面，對(duì)用戶故事有這樣的描述：
由于用戶故事的描述信息以傳統(tǒng)的手寫(xiě)方式寫(xiě)在紙質(zhì)卡片上，所有Ron Jeffries(2001) 對(duì)這三個(gè)方面起了一個(gè)非常好的以相同英文字母開(kāi)頭的名字：
1 卡片（Card）
2 對(duì)話（Conversation）
3 確認(rèn)（Confirmation）

“卡片”包含用戶故事的文字描述，然而需求細(xì)節(jié)要在“對(duì)話”中獲取，并在“確認(rèn)”部分得以記錄。

所以，我們似乎可以回答前面關(guān)于用戶故事是什么，不是什么的問(wèn)題了：用戶故事代表客戶需求而不是記錄需求。

用戶故事的目的之一是讓大家交談。需要交談是因?yàn)闀?shū)面語(yǔ)句，對(duì)于表達(dá)像軟件這么復(fù)雜的需求是比較有限的。

而用戶故事卡的kickoff環(huán)節(jié)，正是這樣一個(gè)把相關(guān)人員集中到一起交談的環(huán)節(jié)。

那么 kickoff 需要那些角色參與？誰(shuí)來(lái)主導(dǎo)？需要確認(rèn)什么呢？

參與角色

一般來(lái)說(shuō)需要4個(gè)人：
1 寫(xiě)這個(gè)需求的業(yè)務(wù)分析師（BA）
2 負(fù)責(zé)UI設(shè)計(jì)的設(shè)計(jì)師（UX），如果這張卡涉及UI的話
3 準(zhǔn)備去實(shí)現(xiàn)這個(gè)需求的開(kāi)發(fā)（Dev）
4 準(zhǔn)備去測(cè)這個(gè)需求的測(cè)試人員（QA）

誰(shuí)來(lái)講解

在BA，UX，Dev， QA這四個(gè)角色中，一般會(huì)讓BA或者Dev來(lái)講解這個(gè)需求的內(nèi)容。

讓BA來(lái)講解的優(yōu)點(diǎn)在于BA是對(duì)這個(gè)需求的上下文，需要特別注意的細(xì)節(jié)，是否和其他卡有一定聯(lián)系這些方面最了解的人，如果由BA來(lái)講解會(huì)輸出非常全面的信息。

讓Dev來(lái)講解的好處在于，比起單純地從BA那里被動(dòng)輸入信息，Dev會(huì)提前閱讀用戶故事，自己先消化，會(huì)加深對(duì)這個(gè)需求的理解，也能在kickoff環(huán)節(jié)產(chǎn)生更多有價(jià)值的提問(wèn)，確認(rèn)盡可能多的待確認(rèn)項(xiàng)。

所以，比較推薦由Dev來(lái)主導(dǎo)解讀用戶故事的需求，而B(niǎo)A可以補(bǔ)充上下文和細(xì)節(jié)。

確認(rèn)什么

BA和UX作為需求的提出者，在kickoff的過(guò)程中承擔(dān)著解釋和確認(rèn)的工作。Dev和QA作為需求的實(shí)現(xiàn)和驗(yàn)收者在kickoff中則主要作為問(wèn)題的提出者，盡可能多地提出和這個(gè)用戶故事相關(guān)的問(wèn)題，比如：
1 這個(gè)需求的價(jià)值（就某些不那么顯而易見(jiàn)，且沒(méi)在用戶故事卡里寫(xiě)明的情況）。
2 確認(rèn)需求細(xì)節(jié)。比如一個(gè)上傳文件的模塊，確認(rèn)可支持上傳的文件類型。
3 確認(rèn)scope(范圍)。比如要替換一個(gè)logo，是否是每個(gè)頁(yè)面都需要替換。
4 性能問(wèn)題。比如一個(gè)上傳文件模塊，上傳超時(shí)時(shí)間是多少。
5 如過(guò)Dev已經(jīng)提前有了一些實(shí)現(xiàn)的思路，也可能會(huì)和QA交流，QA由此獲得一些測(cè)試的思路。
6 某條需求點(diǎn)是否是可靈活變動(dòng)的（比如某個(gè)前端的組件UX是接受開(kāi)發(fā)的具體實(shí)現(xiàn)和現(xiàn)有的設(shè)計(jì)不是100%匹配的）。

理想的kickoff就是，BA， UX， Dev， QA大家對(duì)這個(gè)用戶故事所包含的需求的理解是一致的。

然而現(xiàn)實(shí)情況卻往往不那么完美，我們也或多或少遭遇了一些kickoff的困難，讓我們來(lái)看看經(jīng)典的都有哪些，以及如何解決。

kickoff的困難

1 經(jīng)常湊不齊人
2 參與人員參與度不高
3 故事卡本身達(dá)不到可以被kickoff的標(biāo)準(zhǔn)

經(jīng)常湊不齊人

如果是偶爾一兩次湊不齊人，倒也不是特別嚴(yán)重的問(wèn)題。但是，如果經(jīng)常出現(xiàn)這種情況（常常是因?yàn)轫?xiàng)目里面某些角色太忙，會(huì)議占據(jù)太多時(shí)間），那就是一個(gè)需要被重視和解決的問(wèn)題。一般可以采取兩種方案：
1：提前約時(shí)間
2：每天固定一個(gè)時(shí)間段做kickoff

參與人員參與度不高

這個(gè)情況常常出現(xiàn)在參與人員沒(méi)有提前讀需求（或者沒(méi)有時(shí)間提前讀），導(dǎo)致在kickoff的時(shí)候只是被動(dòng)的接收需求宣讀。理想的kickoff是參與人員都提前讀需求，帶著待確認(rèn)項(xiàng)來(lái)參與kickoff。不然就會(huì)出現(xiàn)，在kickoff之后還需要反復(fù)確認(rèn)一下問(wèn)題，確認(rèn)的問(wèn)題又需要再一次都同步到相關(guān)的所有人，這個(gè)是比較耗費(fèi)時(shí)間和拉低效率的事情。

如何解決這個(gè)問(wèn)題？這里提供一個(gè)思路：
因?yàn)閗ickoff常常由Dev發(fā)起，所以Dev在決定要kickoff某張用戶故事卡之前，可以先通知到相關(guān)的人員你稍后準(zhǔn)備kickoff那張卡，這樣大家都可以提前讀需求，然后帶著問(wèn)題去參加kickoff。

故事卡本身達(dá)不到可以被kickoff的標(biāo)準(zhǔn)

這個(gè)情況其實(shí)不常出現(xiàn)，但是確實(shí)也有出現(xiàn)過(guò)的情況。比如，在kickoff過(guò)程中，大家交談下來(lái)發(fā)現(xiàn)，這張卡其實(shí)和另外一張卡有依賴（雖然從用戶故事卡的原則出發(fā)，這種情況不應(yīng)該出現(xiàn)）或者有待確認(rèn)項(xiàng)目前無(wú)法得到確認(rèn)等因素導(dǎo)致Dev和QA目前無(wú)法開(kāi)始工作。
這種情況的話，就也許需要把這張卡從Ready for Dev一欄移走，需要BA進(jìn)行更多的分析工作。

結(jié)語(yǔ)

寫(xiě)這篇文章的過(guò)程中，和不同的角色（BA, UX, QA， Dev）進(jìn)行了交流，獲取了大家對(duì)kickoff這一環(huán)節(jié)的想法，不同的角色看問(wèn)題的角度會(huì)有很多不同，但是相同的一點(diǎn)是：kickoff是敏捷軟件開(kāi)發(fā)流程里特別重要的一個(gè)環(huán)節(jié)，希望項(xiàng)目人員對(duì)kickoff有盡可能全面和深入的理解以及保持敏感：如果kickoff環(huán)節(jié)出現(xiàn)了問(wèn)題，需要及時(shí)糾正回來(lái)。