敏捷項(xiàng)目要不要做計(jì)劃？
常常聽到有人在講，“我們敏捷項(xiàng)目，不用做計(jì)劃，到了該完成的時(shí)候自然就完成了。因?yàn)槊艚菪岳锊皇钦f響應(yīng)變化高于遵循計(jì)劃，所以敏捷項(xiàng)目做計(jì)劃是沒有意義的?！?/p>
做計(jì)劃是Scrum的基礎(chǔ)。開發(fā)團(tuán)隊(duì)承諾開發(fā)最有價(jià)值的功能，要實(shí)現(xiàn)這個(gè)承諾，團(tuán)隊(duì)必須對(duì)每個(gè)功能有明確的開發(fā)成本估算，以及需要對(duì)每一個(gè)功能的最佳上線時(shí)間做出判斷。
敏捷里怎樣做計(jì)劃？
逐步完善計(jì)劃
首先應(yīng)該逐步完善Product Backlog, 未來比較長(zhǎng)一段時(shí)間要開發(fā)的功能寫成Epic Story加入到Backlog里， 然后隨著時(shí)間前移以及迭代的交付逐漸把它拆分成更小的Story,直到拆到不可再拆的粒度為止。Story拆成最小后，還需要逐步完善故事，增加AC使其達(dá)到DoR的標(biāo)準(zhǔn)。
一個(gè)簡(jiǎn)單的DoR示例
近期做的幾個(gè)項(xiàng)目，團(tuán)隊(duì)里都欠缺一個(gè)清晰的DoR導(dǎo)致常常發(fā)生故事卡進(jìn)入迭代后仍不清楚怎么實(shí)現(xiàn)的問題, 這里介紹一個(gè)比較簡(jiǎn)單易推廣的DoR評(píng)估表格。我們把一個(gè)故事是否能夠移動(dòng)Ready For Dev相關(guān)的3個(gè)重要因素打分，分值從0到3. 最后加總3個(gè)因素的得分，分值大于6分的可以視為滿足DoR。不滿足而優(yōu)先級(jí)又特別高的故事就得添加Spike卡去把它梳理清楚。
| 因素 | 非常清楚 | 清楚 | 有一些待確認(rèn)的問題 | 完全不清楚 |
|---|---|---|---|---|
| 需求 | 3 | 2 | 1 | 0 |
| 實(shí)現(xiàn) | 3 | 2 | 1 | 0 |
| 因素 | 有依賴且不清楚找誰 | 有依賴不清楚如何集成 | 外部依賴Ready | 沒有外部依賴 |
|---|---|---|---|---|
| 依賴 | 3 | 2 | 1 | 0 |
舉個(gè)例子，Backlog里有以下5個(gè)故事卡，評(píng)分分別如下表：
| 故事 | 需求 | 實(shí)現(xiàn) | 依賴 | 總分 | 能否進(jìn)入下一迭代 |
|---|---|---|---|---|---|
| Story 1 - 從附近商家列表、商家標(biāo)簽頁跳轉(zhuǎn)各場(chǎng)景商家詳情 | 3 | 1 | 0 | 4 | N |
| Story 2 - 創(chuàng)建訂單時(shí)，需要記錄已經(jīng)使用的優(yōu)惠 | 3 | 3 | 0 | 6 | N |
| Story 3 - 技術(shù)卡，使用redis inc 機(jī)制生成訂單編號(hào) | 3 | 3 | 3 | 9 | Y |
| Story 4 - 點(diǎn)擊訂單列表?xiàng)l目跳轉(zhuǎn)訂單詳情頁 | 3 | 3 | 3 | 9 | Y |
| Story 5 - 創(chuàng)建訂單時(shí)，需要記錄已經(jīng)使用的優(yōu)惠 | 2 | 1 | 3 | 6 | N |
怎么樣開好一個(gè)Sprint Planning Meeting?
經(jīng)常會(huì)有人抱怨：
- 我不想花那么多的時(shí)間參加Sprint Planning Meeting, 因?yàn)楦杏X沒有任何價(jià)值。
- 會(huì)議開太久，好像和我并沒有太大關(guān)系，為什么要整個(gè)團(tuán)隊(duì)都參加。
- BA和TL就決定了所有的需求和實(shí)現(xiàn)細(xì)節(jié)，要不讓他們開就行了。
- 故事太不清楚了，我根本不知道怎么估點(diǎn)。
許多項(xiàng)目都存在以上問題，為了解決它我想以下這些方實(shí)踐可以比較好的減少這些困惑，提高Planning Meeting的效率。
增加Backlog Grooming環(huán)節(jié)。
在開Spring Planning 前需要做backlog grooming, 與整個(gè)團(tuán)隊(duì)一起先梳理優(yōu)先級(jí)高的，接下來可能要納入Sprint的Story.
在這個(gè)環(huán)節(jié)PO/BA會(huì)向團(tuán)隊(duì)講解Story細(xì)節(jié)， 讓團(tuán)隊(duì)了解他們接下要做什么；在這個(gè)環(huán)節(jié)團(tuán)隊(duì)可以問問題，有可能PO/BA不能當(dāng)場(chǎng)給出答案，這樣在Sprint Planning前他需要去找到答案，不然就不能納入下一迭代里；在這個(gè)環(huán)節(jié)團(tuán)隊(duì)可以對(duì)一些過大的Story進(jìn)行再一步的拆解，讓它變更容易估算準(zhǔn)確；在這個(gè)環(huán)節(jié)開發(fā)團(tuán)隊(duì)可以開始討論如何實(shí)現(xiàn)以及有沒有外部依賴等細(xì)節(jié)。定義團(tuán)隊(duì)Capacity
我們前面說到要做計(jì)劃，每件迭代需要承諾交付高優(yōu)先級(jí)的產(chǎn)品功能；這就需要明確團(tuán)隊(duì)的交付容量，在Sprint Planning時(shí)根據(jù)團(tuán)隊(duì)的容量來選擇Story.這個(gè)容量是隨著團(tuán)隊(duì)的熟悉程度，合作默契程度的提高會(huì)不斷變化的，所以需要及時(shí)調(diào)整。保持一定的Capacity余量
盡量不要把Capacity全部用完， 在一個(gè)迭代里難免會(huì)出現(xiàn)一些意外， 以及團(tuán)隊(duì)成員突然被一些項(xiàng)目外的事情耽誤一天半天的。一個(gè)沒有任何彈性的Sprint Plannig最終的結(jié)果就是團(tuán)隊(duì)將會(huì)無法應(yīng)對(duì)任何的變數(shù)，一旦變數(shù)發(fā)生團(tuán)隊(duì)就會(huì)疲于奔命，或是加班加點(diǎn)，或是抱怨連連，極度影響團(tuán)隊(duì)士氣。
