敏捷項(xiàng)目要不要做計(jì)劃？
常常聽(tīng)到有人在講逐沙，“我們敏捷項(xiàng)目哲思，不用做計(jì)劃，到了該完成的時(shí)候自然就完成了酱吝。因?yàn)槊艚菪岳锊皇钦f(shuō)響應(yīng)變化高于遵循計(jì)劃也殖，所以敏捷項(xiàng)目做計(jì)劃是沒(méi)有意義的∥袢龋”
做計(jì)劃是Scrum的基礎(chǔ)忆嗜。開(kāi)發(fā)團(tuán)隊(duì)承諾開(kāi)發(fā)最有價(jià)值的功能，要實(shí)現(xiàn)這個(gè)承諾崎岂，團(tuán)隊(duì)必須對(duì)每個(gè)功能有明確的開(kāi)發(fā)成本估算捆毫，以及需要對(duì)每一個(gè)功能的最佳上線時(shí)間做出判斷。
敏捷里怎樣做計(jì)劃冲甘？
逐步完善計(jì)劃
首先應(yīng)該逐步完善Product Backlog, 未來(lái)比較長(zhǎng)一段時(shí)間要開(kāi)發(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)的問(wè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)的問(wèn)題 | 完全不清楚 |
|---|---|---|---|---|
| 需求 | 3 | 2 | 1 | 0 |
| 實(shí)現(xiàn) | 3 | 2 | 1 | 0 |
| 因素 | 有依賴且不清楚找誰(shuí) | 有依賴不清楚如何集成 | 外部依賴Ready | 沒(méi)有外部依賴 |
|---|---|---|---|---|
| 依賴 | 3 | 2 | 1 | 0 |
舉個(gè)例子，Backlog里有以下5個(gè)故事卡本姥，評(píng)分分別如下表：
| 故事 | 需求 | 實(shí)現(xiàn) | 依賴 | 總分 | 能否進(jìn)入下一迭代 |
|---|---|---|---|---|---|
| Story 1 - 從附近商家列表肩袍、商家標(biāo)簽頁(yè)跳轉(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)訂單詳情頁(yè) | 3 | 3 | 3 | 9 | Y |
| Story 5 - 創(chuàng)建訂單時(shí)氛赐，需要記錄已經(jīng)使用的優(yōu)惠 | 2 | 1 | 3 | 6 | N |
怎么樣開(kāi)好一個(gè)Sprint Planning Meeting?
經(jīng)常會(huì)有人抱怨：
- 我不想花那么多的時(shí)間參加Sprint Planning Meeting, 因?yàn)楦杏X(jué)沒(méi)有任何價(jià)值。
- 會(huì)議開(kāi)太久先舷，好像和我并沒(méi)有太大關(guān)系鹰祸，為什么要整個(gè)團(tuán)隊(duì)都參加。
- BA和TL就決定了所有的需求和實(shí)現(xiàn)細(xì)節(jié)密浑，要不讓他們開(kāi)就行了。
- 故事太不清楚了粗井，我根本不知道怎么估點(diǎn)尔破。
許多項(xiàng)目都存在以上問(wèn)題，為了解決它我想以下這些方實(shí)踐可以比較好的減少這些困惑浇衬，提高Planning Meeting的效率懒构。
增加Backlog Grooming環(huán)節(jié)。
在開(kāi)Spring Planning 前需要做backlog grooming, 與整個(gè)團(tuán)隊(duì)一起先梳理優(yōu)先級(jí)高的耘擂，接下來(lái)可能要納入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ì)可以問(wèn)問(wèn)題醉冤，有可能PO/BA不能當(dāng)場(chǎng)給出答案秩霍，這樣在Sprint Planning前他需要去找到答案，不然就不能納入下一迭代里蚁阳；在這個(gè)環(huán)節(jié)團(tuán)隊(duì)可以對(duì)一些過(guò)大的Story進(jìn)行再一步的拆解铃绒，讓它變更容易估算準(zhǔn)確；在這個(gè)環(huán)節(jié)開(kāi)發(fā)團(tuán)隊(duì)可以開(kāi)始討論如何實(shí)現(xiàn)以及有沒(méi)有外部依賴等細(xì)節(jié)螺捐。定義團(tuán)隊(duì)Capacity
我們前面說(shuō)到要做計(jì)劃颠悬，每件迭代需要承諾交付高優(yōu)先級(jí)的產(chǎn)品功能矮燎；這就需要明確團(tuán)隊(duì)的交付容量，在Sprint Planning時(shí)根據(jù)團(tuán)隊(duì)的容量來(lái)選擇Story.這個(gè)容量是隨著團(tuán)隊(duì)的熟悉程度赔癌，合作默契程度的提高會(huì)不斷變化的诞外，所以需要及時(shí)調(diào)整。保持一定的Capacity余量
盡量不要把Capacity全部用完灾票， 在一個(gè)迭代里難免會(huì)出現(xiàn)一些意外峡谊， 以及團(tuán)隊(duì)成員突然被一些項(xiàng)目外的事情耽誤一天半天的。一個(gè)沒(méi)有任何彈性的Sprint Plannig最終的結(jié)果就是團(tuán)隊(duì)將會(huì)無(wú)法應(yīng)對(duì)任何的變數(shù)铝条，一旦變數(shù)發(fā)生團(tuán)隊(duì)就會(huì)疲于奔命靖苇，或是加班加點(diǎn)，或是抱怨連連班缰，極度影響團(tuán)隊(duì)士氣贤壁。
