在做敏捷咨詢的這些年頭里庆杜，小馬哥最深的體會便是在大部分客戶眼里，”敏捷“一直等同于”改變“碟摆，并且敏捷就必須要改變晃财。相信這些場景對于在做敏捷交付的團隊來說都是切膚之痛：

場景A: 項目臨近交付，上線在即典蜕，客戶突然要求加一個新需求断盛，當(dāng)團隊嘗試解釋時間上來不及時，客戶爸爸說：”你們不是敏捷嗎愉舔？怎么加個需求都不行钢猛？“

場景B：團隊花費兩個月做好了一套登錄系統(tǒng)，且已經(jīng)被客戶成功驗收了轩缤，結(jié)果過了兩天客戶跑來說：”哎呀我之前沒想好命迈，我覺得微信登錄這一塊得重做。咱們是敏捷團隊火的，肯定沒啥問題吧壶愤？“

場景C：迭代開始后，客戶突然要求所有人停下手中的工作馏鹤，去搶修一個生產(chǎn)環(huán)境的bug公你。奮斗兩天后bug終于修好了，客戶卻告知團隊原先的迭代計劃也必須要完成假瞬，理由是”敏捷團隊嘛陕靠，你們每天少開點會，多干一會兒活肯定能補回來的脱茉〖艚妫“

以上的場景只是冰山一角，當(dāng)客戶或者團隊的敏捷素質(zhì)普遍不高的時候琴许，”敏捷“通常只會成為一個空泛偏激的理解税肪，是客戶隨意改需求的理由，也是團隊成員偷懶榜田，不愿寫文檔的借口益兄。

作為敏捷團隊的項目經(jīng)理，我們必須要身兼數(shù)職箭券，既要做客戶和團隊的敏捷教練净捅，也必須要以scrum master的身份，將真正的敏捷實踐融入到項目開發(fā)流程當(dāng)中辩块。今天要著重分享的蛔六，便是在項目規(guī)劃階段，以及執(zhí)行過程中如何通過貫徹敏捷思想去做交付計劃废亭。

為什么要用敏捷交付計劃?

用敏捷的思維去做項目的交付計劃是快速響應(yīng)市場環(huán)境變化的最優(yōu)對策国章，相對于預(yù)測性計劃或者說瀑布式的計劃它具有以下幾個非常明顯的優(yōu)勢：

1. 能夠應(yīng)對在交付開始后的優(yōu)先級改變，并接受在整個項目開發(fā)周期的需求變更豆村，快速修改計劃

2. 能夠在需求尚未完全清晰的情況下完成計劃液兽，并通過適應(yīng)性生命周期的開發(fā)方式漸進明細(xì)，最終在規(guī)定的時間盒內(nèi)完成交付

3. 能夠通過MVP的短周期形式向客戶提供增量式的商業(yè)價值掌动，在計劃階段清晰標(biāo)出里程碑

那么四啰，具體要怎么做才能體現(xiàn)出以上幾個優(yōu)勢呢？

需求收集階段

任何的項目都源于原始需求坏匪，在需求收集階段拟逮，敏捷項目經(jīng)理需要和商業(yè)分析師緊密合作，力求在項目初期收集到盡可能多的需求适滓，對于項目的整體范圍有一個相對清晰的理解敦迄。如果想要達到最佳實踐，需要做到以下幾點：

敏捷宣言強調(diào)交流凭迹，弱化文檔罚屋，最好的收集需求的方式是客戶或者產(chǎn)品經(jīng)理能和團隊面對面坐下來，進行充分的討論和協(xié)同設(shè)計嗅绸，在盡可能早的階段達到一定的align脾猛。為了達到這個目的，任何的前期投資都是必要的?（飛機票或者酒店貴鱼鸠？這筆錢花的超值!）猛拴。

采用撒網(wǎng) – 收網(wǎng)的收集方式羹铅。不要一開始就拘泥于需求的細(xì)節(jié)，而要更專注于big picture愉昆，充分理解完整的流程职员。

盡可能的收集相關(guān)信息二庵，比如項目的假設(shè)铐刘、風(fēng)險、依賴和一些限制條件

以下是一些常用的敏捷工具躏筏，可以很好的幫助團隊完成需求的收集芳室，我以后會專門寫文章來詳細(xì)介紹它們的用法：

用戶旅程地圖（User Journey Map）

User Journey是在需求收集工作坊里最常采用的工具之一专肪，它通過關(guān)注實際用戶的完整交互體驗來完成設(shè)計，發(fā)現(xiàn)需求和痛點堪侯。使用用戶旅程地圖的一大好處便是可以從全局出發(fā)嚎尤，由大至小的去總覽整個項目，確保不漏掉關(guān)鍵的史詩級需求和功能抖格。以下是一個常見的用戶旅程地圖的操作指南：

先為產(chǎn)品完成Persona和場景設(shè)定诺苹。 找出將用于旅程地圖的關(guān)鍵用戶角色,為整個User Journey活動做準(zhǔn)備。

準(zhǔn)備好一大卷紙或者白板,用于繪制顧客旅程地圖,并且要 可以在整個工作坊期間粘貼即時貼

在水平方向上,標(biāo)記出整個生命周期中的關(guān)鍵舞臺(例如: 觸發(fā)點,考慮因素,支付,消耗,擁護）

在垂直方向上標(biāo)記出和顧客接觸的渠道,例如媒體雹拄、商店收奔、 在線或是電話中心

用不同顏色的即時貼,識別出接觸的層級,例如痛點,獎勵, 以及行動

作為一個團隊,邀請參與者為顧客旅程每個舞臺貢獻他們自己的見解

史詩故事（Epic Story）

用戶故事(User Story)是敏捷開發(fā)的基礎(chǔ)，它從用戶的角度來對需求進行描述滓玖，而史詩故事可以看做是顆粒度較粗的用戶故事集坪哄。比如”注冊“就可以理解為一個史詩故事。在項目初期势篡，需求往往還不明晰翩肌，如果強行寫用戶故事可能會產(chǎn)生無法定義驗收標(biāo)準(zhǔn)（AC）的情況，這個時候史詩故事便可以很好的緩解這個問題禁悠。史詩故事通常沒有細(xì)致的AC念祭，它的估算往往通過專家經(jīng)驗（合理的拍腦袋）的進行。史詩故事可以幫助團隊在不完全了解需求細(xì)節(jié)的情況下進行估算和計劃碍侦，然后在交付階段對其進行再分解和精確估算粱坤。需要注意的是史詩故事也必須滿足INVEST原則。

RAIDs分析法

RAIDs分析法是在項目初期以及項目交付過程中記錄和跟蹤項目相關(guān)信息的重要工具瓷产，非常的簡單實用站玄。簡單來講它就是一個四分圖表，從風(fēng)險(Risks)濒旦， 假設(shè) （Assumptions）, 問題（Issues）以及依賴（Dependencies）四個維度來識別項目的相關(guān)信息株旷。這些信息對于項目計劃的緩沖設(shè)計以及估算的精確度都有著非常重要的影響，是敏捷計劃中不可缺少的一環(huán)尔邓，并且建議越早做越好晾剖，并且在整個項目階段持續(xù)更新锉矢。

排列需求優(yōu)先級階段

軟件開發(fā)里一直有一大誤區(qū)，便是絕大部分的團隊都喜歡先對整個項目的各個需求進行估算齿尽，然后再進行需求的優(yōu)先級排列沈撞，其實這是一個錯誤的操作步驟。 需求的優(yōu)先級應(yīng)當(dāng)永遠(yuǎn)以商業(yè)價值雕什、用戶體驗以及功能的依賴等作為輸入，交付層面的信息永遠(yuǎn)都不應(yīng)成為決定因素之一显晶，只有這樣才能真正的實現(xiàn)以用戶價值為中心的開發(fā)理念贷岸。那么，在需求優(yōu)先級排列階段又需要注意哪些事情呢磷雇？小馬哥大概總結(jié)了這幾個原則：

商業(yè)價值驅(qū)動原則偿警。除了上面說的，項目經(jīng)理必須具備戰(zhàn)略層面的視角唯笙，看到功能背后的商業(yè)價值螟蒸。

MVP原則。高優(yōu)先級的需求集必須是一個能夠獨立上線的完整產(chǎn)品崩掘，這是敏捷持續(xù)交付的核心七嫌。

關(guān)注依賴原則。盡管我們盡量符合Invest原則苞慢，但在軟件開發(fā)中诵原，由于組織架構(gòu)或者系統(tǒng)復(fù)雜性的原因，互相依賴的需求總是會存在挽放，而項目經(jīng)理必須確保處于被依賴方的需求要排在依賴方之前绍赛。

前兩個原則往往需要項目負(fù)責(zé)人或者產(chǎn)品經(jīng)理的高素質(zhì)產(chǎn)出，但是項目經(jīng)理對于第三原則是有絕對的發(fā)言權(quán)和責(zé)任的辑畦。通常在一些大型的IT公司中吗蚌，部門的劃分往往并不和業(yè)務(wù)線高度吻合。比如一家大型的游戲公司可能服務(wù)端和客戶端就是兩個不同的部門纯出，這就導(dǎo)致了在做一款大型游戲時依賴的必然存在蚯妇。 為了化解這種依賴帶來的浪費和損失，項目經(jīng)理必須在計劃階段完成依賴的識別潦刃。具體的依賴方式通常有這么幾種：

完成到開始 （Finish to Start） 即前面的活動完成了侮措，后面的活動才能開始。這個最常見乖杠。

完成到完成 （Finish to Finish）即前面的活動完成了分扎，后面的活動才能完成。比如單元測試和代碼的提交

開始到開始 （Start to Start）?即前面的活動開始了胧洒，后面的活動才能開始畏吓。通常用于并行但共享資源的兩個活動

開始到完成 （Start to Finish）即前面的活動開始了墨状，后面的活動才能結(jié)束。比如新的系統(tǒng)上線了菲饼，老的系統(tǒng)才能關(guān)掉肾砂。

需求估算階段

敏捷需求的估算是一套復(fù)雜的方法論，但它也并不難操作宏悦。項目經(jīng)理只需要強調(diào)一點镐确，并讓團隊充分執(zhí)行便可以了：估算是有依據(jù)有道理的猜測。

敏捷項目的估算分為迭代級別的估算和項目初期的整體估算饼煞。在項目初期的估算其實并不要求花費太多的精力源葫，也不要求太高的精確度，這是遵循了提高效率砖瞧，避免浪費的原則息堂。敏捷之父Martin Fowler說過：””Estimation is valuable when helps you make a significant decision”。只有當(dāng)團隊對達成一個目標(biāo)的工作量以及完成它之后的“收益”有明確的認(rèn)知块促， 才能做出明智的決定荣堰。所以關(guān)鍵點其實在“達成一致”而不是”精確的估算“。

因為竭翠，就我個人的經(jīng)驗而言振坚，項目初期的精確估算是并不存在的，并且它遵循如下原則 （請原諒我拙劣的畫技）：

“二八原則”一定是這個世界上最偉大的發(fā)現(xiàn)逃片，小馬哥認(rèn)為對于項目初期的估算屡拨，我們只需要投入團隊20%的資源就能達到80%的效果，而這對于適應(yīng)性生命周期的敏捷開發(fā)而言褥实，其實已經(jīng)足夠了呀狼。

關(guān)于估算我會另外專門寫文章來詳述，這里就拋磚引玉啦损离。

計劃階段

終于哥艇，在完成了以上的一系列操作之后，我們終于進入了制定計劃階段僻澎。如果你認(rèn)真的執(zhí)行了上面幾個階段貌踏，并達到了預(yù)期的效果的話，相信你一定會發(fā)現(xiàn)：哎窟勃？怎么感覺做計劃其實很簡單的樣子祖乳？？是的秉氧，在完成了所有的緊前活動后眷昆，真正計劃的制定其實只是一個整合的過程而已。

不信的話，和我一起來試著看一下這個標(biāo)準(zhǔn)的敏捷交付計劃(真實的計劃會比這個復(fù)雜很多亚斋，但意思到了就對了哈)：

這個計劃大概體現(xiàn)了如下一些元素：

來自移動端作媚，網(wǎng)頁端和平臺不同用戶場景的全景式需求 （需求收集階段）

需求的優(yōu)先級排列以及依賴 （需求優(yōu)先級階段，F(xiàn)S, SS, SF, FF都有體現(xiàn)）

粗顆粒度的估算 （需求估算階段帅刊，嚴(yán)格意義上講只精確到了月）

項目兩大里程碑分別為網(wǎng)站纸泡，安卓和IOS產(chǎn)品的上線 （需求優(yōu)先級排列階段，兩個里程碑充分體現(xiàn)了MVP原則赖瞒，每一個里程碑都是一個可以上線的產(chǎn)品級交付）

這個計劃跟很多瀑布計劃的甘特圖比起來看似簡陋女揭，但其實卻表達了敏捷交付計劃的本質(zhì)：我們關(guān)注的永遠(yuǎn)都不是計劃本身，而是支持計劃制定的一系列的核心要素栏饮。一旦搞清楚了這些核心要素田绑，我們便擁有了應(yīng)變的資本，在每一次變更到來的時候抡爹，我們便可以用充滿信心的去擁抱變化，而不是束手無策芒划。

輕量級項目管理計劃或者規(guī)則

最后冬竟，即使再敏捷的項目，都需要制定最基本的一些管理規(guī)則民逼，來保證項目計劃能夠在可承受的帶寬里面進行變更泵殴。畢竟哪怕是彈簧，也有自己的極限拼苍。和傳統(tǒng)項目管理需要制定詳細(xì)的管理和變更計劃相比笑诅，敏捷項目管理計劃滿足以下一些特征：（都是實踐出真知的干貨喲！）

輕量級疮鲫，往往并不會單獨寫一個計劃吆你，而是將其歸類到WoW （Way of Working）文檔中。

并不會制定專門的變更計劃俊犯，敏捷擁抱變化的本質(zhì)并不會隨變更范圍而改變妇多，所以并不提倡用文檔來約束變更。但同時燕侠，項目經(jīng)理需要對敏捷素質(zhì)不高的客戶或產(chǎn)品經(jīng)理進行一些基本的敏捷訓(xùn)練者祖，確保他們對于變更的理解，并保持高效的溝通來盡早識別變更的可能性绢彤。

專注于對每個迭代的管理七问。敏捷開發(fā)以迭代為周期，理想情況下每個迭代作為一個短開發(fā)周期茫舶，不提倡進行大范圍的需求變更和計劃更改械巡。如果有變更往往會通過更改下一個迭代計劃的方式來實現(xiàn)。從這個角度來考慮的話，每個迭代周期的長短其實也反應(yīng)了團隊?wèi)?yīng)變帶寬的程度坟比。

必要的文檔：變更的記錄芦鳍。 雖然敏捷不那么重視文檔，但是對于變更的記錄也是非常必要的葛账。作為敏捷項目經(jīng)理柠衅，我們可以通過用戶故事卡（物理或者虛擬）等形式對于變更的需求進行記錄，這樣更方便于風(fēng)險與范圍管理等籍琳。

以上就是完成一個敏捷項目計劃的手把手指南菲宴。以后我會寫一些具體工具的推薦和實操手冊，不過我相信趋急，只要你能掌握敏捷交付計劃中幾個階段的實踐原則喝峦，搞定客戶，帶領(lǐng)團隊實現(xiàn)目標(biāo)是一定木有問題的呜达！

更多有趣的文章谣蠢，歡迎來小馬哥的個人網(wǎng)站：www.himateng.com