Scrum敏捷開發方法在跨境電商平臺的實踐

孫杰成，顏錦奎

(上海大學 通信與信息工程學院，上海 200000)

0 引 言

在Scrum框架中，人們可以解決復雜的自適應難題，同時也能高效并創造性地交付盡可能高價值的產品。Scrum框架由Scrum團隊以及與之相關的角色、事件、工件和規則組成。框架中的每個部分都有其特定的目的，其對于Scrum的成功與使用至關重要。Scrum的規則把事件、角色和工件組織在一起，管理它們之間的關系和交互。

傳統計劃驅動型的瀑布模型將軟件的開發過程劃分為提出需求、制定計劃、編碼、測試等過程，相比之下Scrum將整個開發過程分為重復迭代式增量，稱為Sprint沖刺。

1 Scrum敏捷開發方法

Scrum是一個重復迭代式增量敏捷開發框架，可以對客戶提出的變化需求做出快速響應[1]。相比傳統的計劃型軟件開發過程，比如以過程為核心的“瀑布式”開發方法，敏捷開發更加重視人在整個軟件開發過程中的作用。Scrum于1995年由Advanced Development Methodologies,Inc提出，并在2001年“敏捷聯盟(Agile Alliance)”形成后受到了更多的關注。2001年，以Kent Beck等為代表的敏捷開發擁護者共同簽署了“敏捷軟件開發宣言”，據Version One公司2013年的調查顯示，在全球收集的3 501份調查報告中有88%的公司采用敏捷開發方法，Google、華為等大型軟件公司也采用了敏捷開發[2]。Scrum名稱來自于橄欖球比賽時，隊員在爭球時擺出的陣型，寓意為每個隊員為了最后的勝利作為一個整體，一起去完成一個任務。為達到這種敏捷性，必須要堅持一些必要的設計原則和設計模式，敏捷的核心就是價值觀、原則和實踐[3]。

1.1 Scrum實踐敏捷宣言

敏捷宣言中說到“我們總是在開發實踐中探尋更加出色的敏捷方法，身體力行的同時也幫助他人”,由此建立了如下4條價值觀：

(1)“個體和互動”高于“流程和工具”；

(2)“工作的軟件”高于“詳盡的文檔”；

(3)“客戶合作”高于“合同談判”；

(4)“響應變化”高于“遵循計劃”。

想要理解這四條價值觀就要明白它的定義表示偏好，而不是可以彼此替代的選擇，也就是說，盡管右項有其價值，但更加重視左項的價值。

Scrum很好地實踐了敏捷的這4條價值觀：

(1)個體與互動：自組織自管理的團隊賦予團隊以權利，同處一室，面對面交流，直接溝通，而非文檔溝通；

(2)工作的軟件：每個迭代可交付產品的增量；

(3)客戶合作：直接與客戶溝通需求，及時收集客戶反饋；

(4)響應變化：每個迭代完成對于客戶最有價值的功能，及時地基于用戶反饋做出調整。

所以，通過這個實踐可以給出一個Scrum的完整定義：Scrum是一個重復迭代式增量敏捷開發框架，由一個大約7個人的多功能，自組織的團隊使用固定的迭代時長(沖刺/sprint)去開發可交付的產品增量。

1.2 Scrum中的“人”

Scrum方法中是以人為核心構建的，主要分成3個角色：產品負責人(product owner)、研發團隊(team)和Scrum Master。產品負責人主要負責與客戶溝通產品需求，以得到最大化商業價值為目標，決定產品路線，制定并管理項目的需求訂單列表(project backlog)[4]。產品負責人需要根據商業價值調整功能的優先級，并且每一個sprint完成后要驗收產品功能。任務(包括新功能、改進、缺陷等)的優先級由產品經過多個因素的分析后，獨立判斷決定。當迭代過程中出現更高優先級的任務時，首先這個任務肯定是出自產品經理之手，因為只有產品經理能夠決定任務的優先級。在遇到這類任務時，請按照以下流程處理：將該任務的描述、類型、優先級等在產品清單中明確闡述，對于非Bug類任務，請Scrum Master、Tech Leader協調資源，評估任務的可行性和復雜度，并對任務進行初步的拆解或者細化；如果復雜度在當前剩余迭代中能夠完成，就可以將任務加入當前迭代，(郵件)通知團隊該任務已經加入迭代，請相關同事注意及時處理[5]。

研發團隊是一支多功能團隊，包括開發者、分析師、測試員等。每個人各有專長且能獨立完成分析、設計、實現、測試和部署。他們歸屬于一個項目，同處于一個房間。研發團隊是一支可以自組織和自管理的團隊，自主承擔開發任務，自主領取任務、安排工作，負責在沖刺結束前完成可交付產品增量。

Scrum Master負責保證所有人都能正確地理解并實施Scrum。Scrum Master要確保Scrum團隊遵循Scrum的理論、實踐和規則。原則上Scrum Master是由團隊成員集體推選的，僅僅負責敏捷流程的實施和監督，最終目的是通過保證敏捷實施的質量，提高產品迭代開發的效率和質量。Scrum Master和產品負責人不能是同一人[6]。Scrum Master是一個Scrum項目成敗的關鍵，但他并不是開發團隊的管理員，而是服務于整個開發團隊，為團隊提供敏捷和Scrum的指導。在項目進行的時期，促成開發的流程，主要工作有組織會議，確保時間盒的執行和保持團隊成員工作的可見性。當有其他項目干擾到Scrum的進程時，保護團隊以防被外界干擾，維護Scrum的進程。Scrum Master以各種方式服務于開發團隊，幫助開發團隊創造高價值的產品；移除開發團隊工作進展中的障礙以及在Scrum還未完全采納和理解的組織環境中指導開發團隊。

Tech Leader獨立負責產品中一個子系統或模塊；根據整體產品路線，規劃、落實所負責模塊的技術路線，推進團隊開發進度；承擔技術指導、技術支持和關鍵技術攻關；負責團隊之間的溝通工作；負責團隊建設；以身作則，實踐敏捷開發。

Scrum角色如表1所示。

1.3 實施Scrum

Scrum分成三個步驟：

(1)項目啟動。產品負責人根據用戶現有需求制定產品路線，明確用戶需求，將用戶需求的價值最大化，根據需求的優先級管理需求形成產品的Product Backlog，那么各種類型的需求是如何制定的？目前經常接觸到的任務類型，大致分為新功能(new feature)、改進(improvement)、缺陷(bug等)以及任務(task)。正常情況下，產品經理只能創建新功能、改進和缺陷；并且缺陷只能指向QA，目的是要經過QA驗證；QA只能創建改進和缺陷；研發在開發中可以創建任務、子任務等；研發創建的新功能、缺陷要經過產品和QA的驗證才能進入開發流程。由產品負責人在已經生成的Product Backlog中，選擇要加入到Sprint Backlog的任務開始進行迭代。

表1 Scrum角色

(2)Sprint迭代過程。每一個Sprint開始的時候，項目相關人員(包括產品負責人、研發團隊和Scrum Master)全部到場進行啟動會[7]。產品負責人在會前將高優先級任務加入到產品清單，也可以在啟動會最初開始是由Scrum Master和產品負責人協商決定這個Sprint將做什么。研發團隊從產品清單里選擇優先級最高的任務，研發團隊中的每個人可以根據自己所擅長的技術領域，也可以根據自己在項目中最熟悉的模塊入手，主動領取任務。如果有長度超過一個迭代的任務，研發團隊人員應該告知產品負責人進行拆分。研發團隊人員為每個領取的任務評分，將完成評分的任務放到產品清單。最后評審交付計劃[8]。整個啟動會時間要控制在1～2個小時以內。Sprint開始，Scrum中的所有成員要進行15分鐘的每日站會。每日站會中，每個人向團隊匯報進度，主要包括昨天做了哪些工作，今天要做什么工作和有什么障礙。要注意的是每日站會關注過程，不討論任務細節，所有的問題線下討論。一個Sprint結束后要進行評審會。評審會中產品負責人邀請Scrum團隊和主要的利益攸關者參加，由團隊成員向評審成員展示當前沖刺完成的功能。評審會成員對demo進行討論并提問，產品負責人需要收集反饋并列入產品清單。時間限定在1～2個小時。評審會結束后，Scrum當前團隊的所有成員參加回顧會。

(3)產品功能性測試，持續集成，持續發布。當整個產品完成了所有迭代，所有利益相關者參加產品驗收會，當然這是在產品功能性測試通過后。產品驗收成功后，軟件產品進行集成發布到生產環境。但如果產品驗收不成功，整個Scrum團隊需要反思驗收失敗的原因和迭代過程中的缺陷及漏洞，并把這些經驗添加到整個項目的wiki中由團隊管理，最后把存在問題的功能重新加入到產品清單中，準備進行下一輪的迭代。

Scrum過程如圖1所示。

2 Scrum在跨境電商平臺的實踐

2.1 跨境電商平臺的背景

線下交易一直都是跨境電商的一個痛點，線下交易不僅過程周期長，手續繁瑣，而且極其容易出錯。所以自從2000年阿里巴巴電商開啟了線上的市場需求后，電商平臺如雨后春筍般涌現出來。近幾年跨境電商平臺成為電商發展的新方向，但由于客戶與平臺開發者由于地域和語言等障礙，開發進度緩慢，平臺完成度不高以及開發出的平臺與客戶的需求有偏差等一系列原因，現將Scrum敏捷開發方法應用到跨境電商平臺的開發迭代中，可以很好地解決上述問題。

圖1 Scrum過程

2.2 平臺架構

跨境電商平臺需要解決的是在多種終端上建立起一個統一的交易平臺，解決從選購到訂單發貨一站式服務。平臺選擇使用開源組織Apache提供的基于項目對象模型(project object model，POM)的Maven項目管理工具[9]。它包含了一個項目對象模型、一組標準集合、一個項目生命周期、一個依賴管理系統和用來運行定義在生命周期階段中插件目標的邏輯。Maven可以讓開發人員快速地構建一個項目，有效地解決包管理和項目發布問題，并且可以與持續集成進行無縫對接。對于大型系統，采用Maven作為項目管理工具，可以有效地進行分工協作。Maven有效地管理了項目對于外界jar包的名稱和版本號等問題的依賴，也可以把現階段開發項目的公共部分抽取出來當成對象模型，加入到所有的項目的依賴中。跨境電商平臺的Maven依賴關系如圖2所示。

圖2 平臺Maven依賴關系

將整個項目的名稱定義成absolute，其中absolute-parent成為整個平臺的根項目，包含其他3個項目，主要定義了本平臺涉及到的依賴庫及其版本。Absolute-website定義了平臺的前臺網站項目，主要包含客戶注冊登錄模塊、產品模塊、訂單模塊和新聞模塊等以客戶為中心所要展示的項目。Absolute-admin定義了管理前臺網站的后臺服務項目，此項目主要針對前臺數據進行管理。同時，Absolute-admin還進行了權限管理，財務、采購經理、銷售經理和業務員登錄到后臺管理系統時，只能進行對應自己權限的操作，使得整個平臺分工明確，高效運轉。最后介紹這個架構最核心的部分Absolute-core。此項目定義了整個平臺的實體類，包含基本數據、客戶、產品、詢價和訂單等表結構的設計，Absolute-admin和Absolute-website都與Absolute-core相關，也就是說平臺的前臺網站和后臺管理系統共用一套表結構，這樣設計的目的是加快整個平臺的開發速度，而且當前后臺項目需要聯通時，這樣的設計更加符合整個業務邏輯，也更加方便并且有利于前后臺邏輯代碼的聯調。

2.3 演進式設計

(1)多層測試。Scrum敏捷開發中的一個核心就是測試。將整個平臺設計進行分層，分成基礎服務層、業務層、Web層和頁面展示層。每一層必須包含單元測試，以保證代碼的覆蓋率，更加明確地反饋出代碼的質量與缺陷。之所以要將整個平臺分層設計并進行多層測試，其目的就是Scrum敏捷開發的核心理念：適應。適應產品開發過程中的每次需求改動，保證每次需求改動或者添加不影響已有的功能，而且使調整工作可以盡快執行。

(2)持續集成和測試驅動開發。對于Scrum敏捷開發方法來說，持續集成(continuous integration)和測試驅動開發(test-driven development)同樣是其兩大基石。持續集成就是頻繁地將代碼合成到主干，尤其是在多人開發并使用GitLab這種代碼管理系統時，每個人都在自己的分支上進行編碼，但是如果同時有多人在編輯同一個文件，這樣就容易造成沖突[10]。而持續集成就是要解決這樣的問題。它的好處是快速發現錯誤，防止分支大幅偏離主干。持續集成的目的，就是讓開發可以快速迭代，在保證開發速度的同時還要兼顧質量，這正契合了Scrum所提倡的敏捷原則。它的核心措施是，代碼集成到主干之前，必須通過自動化測試，也就是說每一次的代碼提交都觸發了多層測試。哪怕只是有一個單元測試用例失敗，就不能集成到主分支代碼[11]。

測試驅動開發的基本思路就是通過測試來推動整個開發的進行。而測試驅動開發技術并不只是單純的測試工作。測試驅動開發就是通過編寫測試用例，先考慮代碼的使用需求(包括功能、過程、接口等)，而且這個描述是無二義的，可執行驗證的[12]。通過編寫這部分代碼的測試用例，對其功能的分解、使用過程、接口都進行了設計。但是在實際應用到跨境電商平臺上時，發現測試先寫測試代碼并不高效，此時對需求的了解還不夠充分，即使寫出了測試代碼，當寫功能代碼時經常還會修改原先的測試代碼，這樣反復的過程并不高效。為了提高Scrum敏捷開發方法以及測試驅動開發的效率，把書寫測試文檔作為測試驅動開發的開始。通過書寫文檔，梳理整個需求鏈路，確定類、方法的名稱，以及方法的返回值和參數列表，然后按照文檔先寫測試代碼，再寫功能代碼，效率明顯提升[13]。

(3)重構與簡潔設計。及時重構。重構時堅持單一職責原則、開閉原則、里氏替換原則、接口隔離原則、依賴反轉原則，及時避免設計糟糕、邏輯混亂的意大利面式代碼[14]。保證設計演進，以滿足每次需求改動或者添加。簡潔設計保證不過度設計以致難以重構。

3 結束語

針對傳統的計劃型驅動開發模式不考慮需求變化，隨著計劃進行對需求的修改代價越來越高等致命缺陷，把Scrum敏捷開發方法引入到跨境電商平臺的開發過程中[15]。讓開發能適應變化，將反饋代碼質量，反饋產品需求是否滿足，反饋迭代流程是否有效，反饋設計思路是否正確等Scrum的優點通過演進式設計都運用到平臺的開發過程中，明顯提高了效率，保證了迭代質量。

[1] SCHWABER K, BEEDLE M．Agile software development with scrum[M]．[s.l.]：Prentice Hall,2001.

[2] ALLIANCE A. Manifesto for agile software development[J].Lecture Notes in Computer Science,2001,37(12):26-34.

[3] 胥 康.Scrum方法在軟件項目管理中的應用[J].信息系統工程,2017(1):55.

[4] 丁順鶯.基于Scrum敏捷方法的出租屋用電管理系統研究[J].計算機時代,2016(11):8-10.

[5] 尚會斌.CMMI和敏捷開發過程的分析比較[J].通訊世界,2016(13):294-295.

[6] 王萬意.Scrum敏捷開發在線教育系統[J].電子技術與軟件工程,2016(8):70-71.

[7] 蔡振凡.基于J2EE的跨境電商平臺的設計與實現[D].長春:吉林大學,2016.

[8] 陳國棟,羅省賢.Scrum敏捷軟件開發方法實踐中的改進和應用[J].計算機技術與發展,2011,21(12):97-99.

[9] 芮雄健,王忠民.基于敏捷軟件開發方法的基金管理信息系統開發[J].計算機應用,2004,24(11):162-165.

[10] DINGS?YR T,NERUR S,BALIJEPALLY V G,et al.A decade of agile methodologies:towards explaining agile software development[J].Journal of Systems & Software,2012,85(6):1213-1221.

[11] CMMI Product Team.CMMI for development,version 1.2[M].Pittsburgh:Carnegie Mellon University Software Engineering Institute,2006.

[12] 謝 琳.基于SCRUM的小型團隊軟件項目開發應用與研究[D].長春:東北師范大學,2011.

[13] 張智海,周國祥.Scrum方法的研究與分析[J].合肥工業大學學報:自然科學版,2010,33(2):197-200.

[14] 張敬周,錢樂秋,朱三元.Agile方法研究綜述[J].計算機應用與軟件,2002,19(6):1-9.

[15] 施擁軍.上海貝爾敏捷SCRUM模式下軟件質量改進措施的研究[D].上海:復旦大學,2013.