互聯網消費金融項目敏捷開發實施研究
——基于Scrum方法的單案例研究

(中國人民大學 北京 100000)

一、引言

我國居民生活水平逐漸提高，消費需求比較旺盛，超前消費意識也逐漸增強，接受新型金融產品的能力較強。使用消費信貸手段來緩解由于預算約束帶來的消費不足的理念日漸深入。銀行、電商平臺等各互聯網公司紛紛加入互聯網消費金融大軍，市場日益競爭激烈。如何快速且更有針對性的滿足用戶需求，快速響應環境得變化，不斷優化迭代產品成為各家互聯網金融公司研究得重心。

二、文獻綜述及理論背景

(一)國內外研究現狀

1.國外研究現狀

在國外軟件企業中，幾乎將近一半企業已采用敏捷方法的，一些著名的公司如 Google、Microsoft、Yahoo 以及很多中小公司都已經采用敏捷開發，其中Scrum方法最為流行，而且很多公司已經采用了很長時間。他們通常做法是先選擇幾個開發團隊來試用敏捷開發模式，然后再將開發經驗推廣到其他的開發團隊中去。中小型軟件公司以其靈活創新的特點，更加適合敏捷開發，許多公司都已經把開發團隊完全轉型到敏捷開發模式下。

2.國內研究現狀

敏捷開發出現并傳入中國已經有是五六年年歷史了，根據云棲社區發布的《2017開發者調查報告》中有一項數據：45%開發者所在的組織采用了敏捷開發方法，在各種開發方法學中位居第一。在通訊行業，2005年底，諾基亞在杭州的研發中心開始試點敏捷；2018年諾西多個產品也開始大面積實施敏捷，同年愛立信也開始使用Scrum方法運作項目，并引入持續集成。華為公司2006年小試點后，至2010年也全面推廣使用。互聯網畢竟身處時代大潮的前沿，時刻關注海量用戶的真是反饋，每一點的轉變都有可能影響到經濟效益，所以促使互聯網行業更有動力推廣敏捷。當互聯網行業迅猛發展時，其他行業CIO也紛紛加入敏捷大軍，比如汽車、金融、零售、教育等。

(二)敏捷開發方法理論及思想

敏捷開發方法不是某一種方法論、過程或框架，而是一種價值觀和原則。這些價值觀和原則由17位軟件開發領域的領軍人物在2001年通過《敏捷宣言》傳遞給世界，也在那個時候宣告了全球敏捷開發運動的開始。敏捷宣言和價值觀如下：(1)個體與交互重于過程和工具；(2)可用的軟件重于完備的文檔；(3)客戶協作重于合同談判；(4)響應變化優于遵循計劃。

敏捷開發目前應用比較多的主流開發方法有：(1)Scrum，Scrum講究以人為核心，是一個迭代式的增量開發過程，迭代即不斷優化需求，增量即將整個項目進行拆分成多個子項目。Scrum包括了一系列實踐和預定義角色的過程骨架，三個角色主要是產品負責人、敏捷主管、開發團隊。(2)XP極限編程，XP極限編程是1996年由KentBeck提出，是一個輕量級、靈巧的軟件開發方法，其主要目的是降低需求變化的成本。XP強調開發人員與業務人員之間的緊密協作、面對面溝通，開發過程頻繁交付軟件版本，團隊建設緊湊而自我組織型，能夠更好的適應需求變化。極限編程規定了一些實踐和簡單規則，包括：編寫用戶故事、架構規范、迭代計劃、代碼開發、單元測試、驗收測試等。(3)精益軟件開發，精益思想來源于豐田公司的軟件開發方法。和其他敏捷方法相比，精益軟件開發更重要的是不斷完善開發過程，因此，將精益模式與其他敏捷開發模式一起使用將會取到比較好的效果。

三、案例研究方法

(一)選擇案例

A公司是一家專注于智能產品自主研發的移動互聯網公司。2015年開展互聯網金融業務成立金服事業部，面向個人提供金融服務，包括但不限于:投資理財、貸款、證券、保險等。“XX貸款”是其邁向個人消費金融的開端，也是打造“從行為到金融”新型征信模式的關鍵一步。

選擇A公司作為研究對象公司得原因有如下幾點：

1.A公司是金融事業部專注互聯網消費金融的發展，近幾年風口浪尖的一個業務就數互聯網金融了，16和17年發展迅猛，暴漏出很多問題。18年監管收緊、經濟形式下滑，導致業務出現縮水。如此大起大落的環境變化，對軟件開發的響應能力要求更高。

2.恰逢A公司也在逐步拓展更加適合互聯網金融公司發展的新的技術和軟件開發管理路線。

3.公司現有軟件開發方法中也暴露出了很多問題，比如軟件質量問題、進度問題、團隊建設問題等。

如果將敏捷開發方法應用在A公司互聯網金融項目中，會不會解決公司目前的問題。本文作者開始了互聯網消費金融項目中敏捷開發的實施研究，基于敏捷方法之一的Scrum方法進行研究。

(二)收集數據

數據收集是案例研究方法非常重要的內容，做好數據收集工作可以為后面的研究提供有力的支持。數據收集第一階段主要是查找與我研究相關的文獻資料，包括單不限于知網別人研究的內容，相關的理論課程。文獻查找主要在于本文研究內容相關的項目管理、敏捷開發和互聯網金融三個領域。第二階段主要是基于現在公司中項目管理的材料收集。包括但不局限于公司組織架構、項目管理文檔、歷史項目管理文檔。第三階段直接參與項目中，通過實踐方式收集資料。

(三)分析資料

通過數據收集進行整理分析，發現公司內比較突出的問題有以下幾點：

1.組織架構復雜，導致流程比較長，比如產品部門和研發部門分開，就會導致兩個部門人員之間不夠團結，產品提了需求研發虛報工作量等。

2.公司內開發流程繁瑣，從研發到測試到上線驗證，跨部門垮機構，需要很長時間。

3.項目進度管理不受控，項目延期情況頻繁發生，大約有90%的項目沒有按照評審計劃的時間點上線。

4.項目質量管理不當，頻繁出現問題，導致上線后的產品Bug多，嚴重影響用戶的體驗，時間久了用戶就會不斷的流失。

經過分析A公司金融部門現在內憂外患，內有項目管理中存在的諸多問題，外有競爭對手的壓力。因此，A公司金融部門目前急需一套可靠的軟件開發流程，本論文作者在此引入Scrum敏捷開發管理方法，根據Scrum開發模型結合A公司金融部門的實際情況形成一套個性化的Scrum流程，將很有效的解決了以上一系列問題，具體的改進方案將在第四章中詳細介紹。

四、A公司基于Scrum流程優化

(一)團隊組建

根據第三章對A公司項目管理中存在問題的提出和分析，通過改善其組織架構，使其更加適合敏捷開發。應用Scrum敏捷方法對A公司金融部門建立一個自組織、跨職能、靈活的敏捷團隊。團隊中定義了三個角色，分別是產品負責人、Scrum主管、開發團隊。Scrum教程里倡導的Scrum團隊的理想人數是7人，即1個Product Owner和1個Scrum Master，開發團隊應有5人，三個開發人員，兩個測試人員。

(二)開發流程重構

前面章節分析了A公司項目管理流程中出現的問題，為了解決這些問題引入敏捷開發方法，在本章節中，主要應用敏捷開發方法中最常用的Scrum開發方法對公司的管理流程進行優化，形成基于A公司的Scrum模型。

Scrum開發全生命周期工作流程，如圖1：

圖1 Scrum工作流

首先，需要確定一個目標，所有團隊成員，包括產品負責人、敏捷主管、開發團隊一起確定。目標確定后，產品負責人(Product Owner)會維護一個文檔即Product Backlog，產品負責人維護好Product Backlog，并且將Backlog 按照需求優先級進行排序。每次計劃會議時根據優先級順序挑選優先級高的需求，然后把需求拆分成一個個的開發周期即一個Sprint。每一個Sprint開始的時候，需要進行一個Sprint計劃會。Sprint計劃會需要全部成員參加，通過Backlog從優先級最高的需求開始進行闡述。然后將Backlog 拆分成更細粒度的任務，每個成員在每日站會中領任務并完成。為了讓大家對整個項目有個全局觀，每日站會時，大家圍在白板前明確項目進度和任務完成情況。團隊人員可以在這個會議上了解整個迭代的進展情況，然后Sprint結束后團隊開一個Sprint評審會大家一起交流本次Sprint中哪做得好哪做的不好。最后敏捷主管再開一次回顧會。整個過程都由敏捷主管組織和把控，這樣每一個團隊人員都清楚項目的目標、項目整體進展等情況。

(三)項目會議制設計

Scrum敏捷開發四個會議分別指，Sprint計劃會議、Sprint評審會議、每日站會、Sprint回顧會議。

1.Sprint計劃會議

在Scrum中，Sprint計劃會需要參會的人員包括開發團隊、敏捷主管、產品負責人，產品負責人向開發團隊介紹排好序的產品待辦事項，由整個Scrum團隊共同理解溝通這些工作。根據優先級選擇本次Sprint需要做的產品事項。Sprint中需要完成的事項數目完全由開發團隊決定。每天做多少工作也由開發團隊成員決定，產品負責人或任何其它人都不能給開發團隊強加更多的工作量。

2.每日站會

開發團隊是自組織的，通過每日站會來確認他們可以實現Sprint的目標。站會顧名思義就是站著開會，團隊成員圍城一個圈，每一個開發團隊成員需要提供以下三點信息：(1)我完成了什么？(2)我計劃完成什么？(3)有什么阻礙了進展。每日站會時間一般情況下不超過15分鐘，每日站會中可能有簡要的問題說明和回答，但是不應該有任何話題的討論。會上敏捷主管需要修改燃盡圖，對迭代的任務進展情況進行跟蹤，并根據實際情況對迭代計劃進行細微調整。

3.Sprint評審會議

Sprint結束時，Scrum團隊和相關人員一起評審Sprint的產出。所有Scrum會議都是限定時長的，Sprint評審會議的推薦時長是Sprint中的每一周對應一個小時。團隊每個人都可以在Sprint評審會議上發表意見。產品負責人會對未來做出最終的決定，并適當地調整產品待辦事項列表。通常都會在Sprint評審會議中調整產品待辦事項列表，Sprint評審會議向團隊中每個人展示了當前產品增量的情況。

4.Sprint回顧會議

在每個Sprint結束后，Scrum團隊會聚在一起開Sprint回顧會議，目的是回顧一下Sprint過程中，團隊在流程、人以及工具方面有沒有什么問題，做的如何，需要團隊成員全部參加。團隊識別出哪些做得好，哪些做得不好，并找出改進事項，為將來的改進制定計劃。Sprint回顧會議的推薦時長也是兩小時。

(四)輔助工具組建

工欲善其事必先利其器，敏捷開發方法的持續交付，在一定程度上導致了交付的碎片化，這樣就需要引入好的管理工具。

下面逐一介紹下使用到的工具

1.JIRA：敏捷管理神器

JIRA被廣泛應用于敏捷管理中，完美支持了Scrum和看板方法，易用性、靈活性、擴展性都得到業界的廣泛認可。JIRA配置靈活、功能全面、部署簡單、擴展豐富等，徹底貫徹了敏捷開發方法所倡導的去中心化、靈活、透明、集體討論、信息共享等原則。

2.文檔管理工具

敏捷并不是說不需要文檔，它認為文檔應該少且精煉，不需要冗余的文檔。文檔也是作為細化部分，在每個迭代過程中不斷重構。文檔是用來準確傳遞信息，幫助理解事物，沉淀知識。Wiki是一種在網絡上開放且可供多人協同編輯的超文本系統，Wiki站點可以有多人維護，每個人都可以發表自己的意見，或者對共同的主題進行擴展或者探討。wiki對于團隊成員的學習和技能的提升有著非常重要的作用，它可以幫助公司和團隊不斷積累業務和技術知識。

五、研究結論

通過聯合貸項目驗證A公司Scrum開發模型，有如下幾點變化：

1.響應變化的速度變快，當市場有變化需要調整時，及時響應，最重要的總是排在最優做。

2.可持續向用戶交付有價值軟件產品，不停的通過每次迭代和升級，進行產品的優化和提升，用戶借款體驗越來越好，投訴數量減少。

3.團隊更透明，產品和研發之間已經沒有明顯得隔閡，也不會出現產品與研發的撕戰，大家都是為了一個目標，團隊內成員不僅可以了解自己的項目也可以了解其他成員的工作。

4.軟件成本降低，Scrum敏捷開發方法帶來的價值就是允許產品快速試錯，即使錯了，浪費的最多也是一個迭代的資源，而不像傳統瀑布開發方法，浪費的可能是好幾個月的資源。

5.投資回報率提高，成本降低，開發模式高效，回報率自然就會提高了。

最后，Scrum敏捷開發方法不能杜絕問題，只是幫助團隊減少出現問題的概率，敏捷開發方法的核心是人，是團隊的敏捷意識和對工作的責任感。敏捷開發方法不是萬能的，不能解決掉所有的問題。Scrum敏捷開發方法只是解決辦法之一。