(網(wǎng)經(jīng)社訊)本文是關(guān)于作者在To B 項目敏捷開發(fā)的一點(diǎn)個人心得，希望能對處于相同環(huán)境的朋友提供一點(diǎn)參考，一起來文中看看~
通過盡早和不斷交付有價值的軟件滿足客戶需要——敏捷宣言。
筆者于2015年第一次接觸敏捷開發(fā)且第一次碰觸Scrum，當(dāng)時scrum的理念確實(shí)為筆者的打開了一扇開發(fā)的窗，但結(jié)合自身境遇，仔細(xì)分析后認(rèn)定敏捷比較適合于做內(nèi)部的產(chǎn)品，不適合做ToB解決方案型項目（以下簡稱Tob項目），原因如下：
立場：Tob項目甲乙雙方關(guān)系為被服務(wù)與服務(wù)的關(guān)系，甲方希望最少成本做最多的事，節(jié)約成本，乙方希望項目可以利潤最大化，提高收益。
背景：ToB項目甲方期初需要經(jīng)歷項目可行性研究、項目立項、項目評審等過程，前后需準(zhǔn)備大量的描述材料，如果實(shí)施結(jié)果與預(yù)期目標(biāo)偏差過大，會被審計組審計。同時，也會對項目申請人的能力產(chǎn)生質(zhì)疑，因此客戶的建設(shè)理念往往傾向于傳統(tǒng)瀑布模式，注重交付成果的一致性。
合同：ToB項目以固定總價合同模式居多，固定總價合同前期就有明確的范圍、進(jìn)度、成本、交付成果等要求。
觀點(diǎn)：ToB項目團(tuán)隊往往會由甲乙雙方共同組成，雙方背后都有不同的利益組織，因此觀點(diǎn)比較復(fù)雜，針對共同目標(biāo)雙方患難與共，但同時又因各為其主，會在一些細(xì)節(jié)上產(chǎn)生分歧，尤其是在變更的時候，因?yàn)闀婕暗匠杀尽⑦M(jìn)度等要素，弄得每一次變更都像打架一樣。
傾注：ToB項目建設(shè)往往由甲方業(yè)務(wù)方申請，IT部門承建，受益人與負(fù)責(zé)人不為同一人，由于利益、職責(zé)不同，甲方負(fù)責(zé)人的投入熱忱也不盡相同。
因此ToB解決方案型項目使用敏捷模式可謂如履薄冰，稍有不慎便有需求蔓延、影響交付的風(fēng)險。
2018年1月，筆者所在的公司承接了某地產(chǎn)龍頭的云視頻平臺建設(shè)項目，該集團(tuán)信息化事業(yè)部有著比較豐富的項目建設(shè)經(jīng)驗(yàn)，本項目為總價合同模式，預(yù)計建設(shè)周期9個月，合同簽定之初甲方項目總監(jiān)就要求項目快速上線，盡早滿足該集團(tuán)業(yè)務(wù)訴求，優(yōu)惠條件是項目組可以不用駐場開發(fā)（筆者所在公司與項目現(xiàn)場相隔千里）。
筆者權(quán)衡再三，與甲方約定項目采用敏捷開發(fā)模式，并且達(dá)成了具體落地方法，具體如下：
一、架構(gòu)職責(zé)
架構(gòu)職責(zé)：由甲方項目總監(jiān)、產(chǎn)品經(jīng)理、乙方項目經(jīng)理、產(chǎn)品經(jīng)理、開發(fā)經(jīng)理、測試經(jīng)理組成項目核心團(tuán)隊。
甲方項目總監(jiān)：負(fù)責(zé)甲方整體項目把控工作；
甲方項目經(jīng)理：負(fù)責(zé)需求篩選，優(yōu)先級排序，協(xié)調(diào)甲方技術(shù)、業(yè)務(wù)人員配合本項目建設(shè)等工作；
乙方項目經(jīng)理：負(fù)責(zé)編寫WBS、編制項目計劃、信息同步、風(fēng)險跟蹤等工作；
乙方產(chǎn)品經(jīng)理：負(fù)責(zé)需求收集、梳理、分析、原型制作、需求確認(rèn)、改進(jìn)方案等工作；
乙方技術(shù)經(jīng)理：負(fù)責(zé)構(gòu)建系統(tǒng)架構(gòu)、指導(dǎo)開發(fā)、外部接口對接、重點(diǎn)問題攻堅工作等工作；
乙方測試經(jīng)理：負(fù)責(zé)組織測試規(guī)劃、方案、用例、BUG管理、培訓(xùn)等工作。
二、拆分階段
拆分階段：將原9個月的建設(shè)周期拆分成三個階段，即每三個月一個大階段，每階段里再拆分成3個小迭代，每個小迭代均提供有價值的交付物。
每個大階段提前三周做需求收集、需求分析、需求排序等工作，規(guī)劃好本階段的工作內(nèi)容，以及完成第一個小迭代的交互稿細(xì)化；
每個小迭代前兩周做需求收集、需求分析、需求排序、交互稿細(xì)化等工作；
每個小迭代內(nèi)如無特殊情況，不做項目變更；
第一個階段不做小迭代拆分（建設(shè)初期初始化的事情太多：如確定需求基線、整體架構(gòu)設(shè)計、硬件資源、網(wǎng)絡(luò)資源、域名、安全檢查、各種評審以及新團(tuán)隊成員組建磨合等）；
三、溝通模式
溝通模式：現(xiàn)場會議、電話會議、IM、郵件等。
項目周報：郵件形式面向項目組全體成員，每周一次。
會議紀(jì)要：郵件形式面向項目組與會人員及雙方領(lǐng)導(dǎo)，每次會議。
階段成果確認(rèn)：郵件形式面向?qū)?yīng)負(fù)責(zé)人及雙方領(lǐng)導(dǎo)，每階段。
乙方內(nèi)部敏捷溝通模式：站會、周會、回顧會。
各大階段前兩周，甲乙雙方當(dāng)面交流，一般交流周期為一周（很重要?。?。
四、需求范圍
需求范圍：以需求規(guī)格說明書為需求基線，并輔以需求變更單.
以需求規(guī)格說明書為需求基線；
需求收集、需求分析、需求排序階段甲乙雙方共同參與，并達(dá)成共識；
統(tǒng)一思想，擁抱變更，重點(diǎn)強(qiáng)調(diào)本項目會有較多變更，大家心里上一定要認(rèn)同這一點(diǎn)，當(dāng)出現(xiàn)變更時，雙方一同分析變更影響（含工作量、工期、建設(shè)節(jié)奏等），達(dá)成共識后，迅速對變更需求給予確認(rèn)；
在雙方達(dá)成共識的基礎(chǔ)上，該項目基本按即定計劃執(zhí)行，項目整體提前1個月，即用時8個月建設(shè)完成，在完成的同時也整理一下個人的心得。
互信：互信非常重要，本項目由于分小迭代上線，在對最終用戶需求做出及時反饋的同時，項目組也面對著大量的變更，是否符合變更，變更工作量多少均達(dá)成共識，雖然大家是為一個項目服務(wù)，但背后利益群體不同，達(dá)成互信非常不易；
互助：本項目在建設(shè)的過程中除遇到變更外，因甲方客觀情況需要，曾嘗試過雙周迭代，項目組很好的滿足了甲方高層級的業(yè)務(wù)需求，雙方的友誼更進(jìn)了一步；
互補(bǔ)：甲方項目經(jīng)理出身產(chǎn)品設(shè)計，本項目中兼了甲方產(chǎn)品經(jīng)理和甲方項目經(jīng)理兩個職務(wù)，由于項目管理經(jīng)驗(yàn)和技術(shù)能力相對薄弱，項目組會對該項目經(jīng)理給予一定的幫助，一同面對項目中的問題，幫助其快速成長，該項目經(jīng)理成長后，在很大程度上對項目起了推動作用；
迅速確認(rèn)：由于本項目有大量的變更，為防止這些變更遺漏、事后無法追述等情況，在確定變更后，雙方迅速確認(rèn)；同時，階段性成果也要迅速確認(rèn)；
節(jié)奏：本項目直接參與建設(shè)人員平均人數(shù)為30人，峰值時達(dá)到45人左右，如何保障大團(tuán)隊能一直高效的工作，節(jié)奏很重要，項目組通過提前規(guī)劃需求、提前出交互稿的形式，使大團(tuán)隊每輪迭代后均后新任務(wù)執(zhí)行；
不足：ToB項目，尤其是首次合作的ToB項目，項目的約束條件會很多，干系人溝通渠道的很大，需要用大量的時間來識別及應(yīng)對，而此時實(shí)現(xiàn)短期項目上線，進(jìn)度風(fēng)險特別大，本項目第一階段就因溝通不夠充分，導(dǎo)致延期上線一周。
最后，此次項目雖然通過敏捷的方式取得了成功，但個人總結(jié)ToB項目在總價合同的模式下，想要實(shí)現(xiàn)敏捷必須要具備以下幾點(diǎn)要素：
甲方IT建設(shè)的成熟度要高；
雙方理解并認(rèn)同敏捷的模式；
甲方會對本項目做出大量的建設(shè)投入；
乙方項目經(jīng)理要有很好的控場能力，并且對項目的走向有一定的前瞻能力。
以上為我在To B 項目敏捷開發(fā)的一點(diǎn)個人心得，希望能對處于相同環(huán)境的朋友提供一點(diǎn)參考。（來源：人人都是產(chǎn)品經(jīng)理 文/王磊 編選：電子商務(wù)研究中心）
