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