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