“讓我們推動(dòng)大鐵球”
老王是一個(gè)典型的H人－充滿激情和執(zhí)行力極強(qiáng)，他憂慮地跟我說：“這個(gè)項(xiàng)目就像一個(gè)大鐵球，人人都知道很重，但是光滑的表面讓所有人不知如何使勁”。我的回復(fù)是：“你需要一個(gè)敏捷里的項(xiàng)目啟動(dòng)”。
這樣的項(xiàng)目都有一個(gè)類似的特征：一個(gè)被拍腦袋的，誰也不知道能不能完成的結(jié)束日期；一堆還未明確的需求；一群缺乏計(jì)劃的開發(fā)人員；和一個(gè)必須看到團(tuán)隊(duì)至少應(yīng)該干點(diǎn)什么的項(xiàng)目經(jīng)理。以往的項(xiàng)目開始也許是當(dāng)項(xiàng)目不得不開始的時(shí)候，大家停止?fàn)幊痴f：好吧，一起開始?？赡苁虑椴蝗缥蚁嘈诺哪菢颖^，但是在上線前幾天沒人知道團(tuán)隊(duì)到底能做到什么程度，應(yīng)該是確定的。
于是，敏捷項(xiàng)目啟動(dòng)的關(guān)鍵在于確定項(xiàng)目范圍，圍繞在這個(gè)周圍的是：故事拆分、優(yōu)先級(jí)、工作量、和迭代計(jì)劃。
故事拆分
首先，讓我們一起拆分故事。需求在初期一定是不明確的，為了把需求不明確造成的返工浪費(fèi)減到最小，我們把一個(gè)大需求根據(jù)業(yè)務(wù)場(chǎng)景拆分成若干用戶故事，也許只是一個(gè)標(biāo)題而已。標(biāo)題的格式最好采用“XXX可以XXX”這樣業(yè)務(wù)語言的格式，例如“營(yíng)業(yè)員可以查看客戶訂購(gòu)的服務(wù)列表”，而不是“客戶訂購(gòu)關(guān)系列表”這樣功能語言的格式。業(yè)務(wù)語言而不是功能語言可以制造一種業(yè)務(wù)價(jià)值導(dǎo)向的開發(fā)氛圍，努力杜絕做“不增加價(jià)值”的事情。此外，還有很多必要的技術(shù)任務(wù)被識(shí)別出來。這樣我們就得到一個(gè)包含各種用戶故事和技術(shù)任務(wù)的列表。
值得提出的一點(diǎn)，容易產(chǎn)生混淆的是“分拆用戶故事”和“分拆技術(shù)功能點(diǎn)”的區(qū)別。傳統(tǒng)思維中，需求被拆分成許多獨(dú)立功能點(diǎn)，每個(gè)功能點(diǎn)可能在多個(gè)業(yè)務(wù)場(chǎng)景下被用到，我們認(rèn)為把這樣重復(fù)使用的功能點(diǎn)或模塊單獨(dú)進(jìn)行開發(fā)，可以減少工作量，考慮也更加周全（單個(gè)功能在多個(gè)業(yè)務(wù)場(chǎng)景下可能有不同），是一種非常高效，且理所當(dāng)然的工作模式。這樣做的結(jié)果是，到項(xiàng)目開始后的很長(zhǎng)時(shí)間，都不能完成一個(gè)較為完整的業(yè)務(wù)場(chǎng)景（每個(gè)場(chǎng)景可能都開始，但都是零散的功能點(diǎn)）。這里便是規(guī)模生產(chǎn)和精益單件流生產(chǎn)模式的本質(zhì)不同，關(guān)于此點(diǎn)我將另在文章中解釋，此處不贅述。
排優(yōu)先級(jí)
當(dāng)我們有足夠的故事卡片被拆分出來，為了讓核心團(tuán)隊(duì)對(duì)整個(gè)項(xiàng)目交付計(jì)劃有個(gè)初步的感覺，我們把卡片平鋪在一張大桌子上，分成三個(gè)區(qū)域“基礎(chǔ)”、“提升”和“特殊”。每個(gè)區(qū)域的分別含義是：
- 基礎(chǔ)：核心的技術(shù)任務(wù)和最基本業(yè)務(wù)流程框架中的用戶故事，拿開戶業(yè)務(wù)為例，“可以開戶”就是一個(gè)基礎(chǔ)用戶故事；
- 提升：在基礎(chǔ)的用戶故事上進(jìn)行提升的特性，例如“在開戶時(shí)可以看到可用號(hào)碼列表”就是一個(gè)提升型用戶故事——開戶是基礎(chǔ)特性，可用手機(jī)號(hào)碼的選擇可以先采用手工輸入方式；
- 特殊：一些非必要的，滿足客戶更細(xì)化的要求，例如“在開戶時(shí)可以看到帶8的可選號(hào)碼列表”就是一個(gè)特殊型用戶故事——這樣的需求相對(duì)獨(dú)立，不影響業(yè)務(wù)主場(chǎng)景的實(shí)現(xiàn)；
從軟件開發(fā)層次上考慮這三個(gè)等級(jí)便是：Usable(可用的)、Useful(好用的)和Engaged(信賴的)。
我們需要做的事情是把拆分好的卡片放進(jìn)相應(yīng)的區(qū)間里，目的是在后階段實(shí)踐中，我們盡量把時(shí)間花在第一個(gè)區(qū)間“基礎(chǔ)”的卡片上，對(duì)于后兩個(gè)區(qū)間的卡片，盡量不要陷入到細(xì)節(jié)的爭(zhēng)論中去。
估計(jì)工作量
往往出現(xiàn)的情況是我們忽視真正需要進(jìn)行代碼開發(fā)的人對(duì)工作量的估計(jì)——某個(gè)擁有權(quán)威和經(jīng)驗(yàn)的系統(tǒng)專家給出一個(gè)讓開發(fā)團(tuán)隊(duì)敢怒不敢言的工作量，經(jīng)常讓開發(fā)進(jìn)度陷入不可控的艱難境地。工作量的估計(jì)是為了設(shè)置一個(gè)合適的迭代工作量目標(biāo)，不要過大，也不要過小。注意我們只能知道昨天的天氣，迭代能完成的量不是恒定，在迭代正式開始后，需要根據(jù)上一迭代的情況進(jìn)行調(diào)整。
估算工作量的方法是召集5到7個(gè)開發(fā)人員