Scrum敏捷開(kāi)發(fā)方法在跨境電商平臺(tái)的實(shí)踐

孫杰成，顏錦奎

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

0 引 言

在Scrum框架中，人們可以解決復(fù)雜的自適應(yīng)難題，同時(shí)也能高效并創(chuàng)造性地交付盡可能高價(jià)值的產(chǎn)品。Scrum框架由Scrum團(tuán)隊(duì)以及與之相關(guān)的角色、事件、工件和規(guī)則組成。框架中的每個(gè)部分都有其特定的目的，其對(duì)于Scrum的成功與使用至關(guān)重要。Scrum的規(guī)則把事件、角色和工件組織在一起，管理它們之間的關(guān)系和交互。

傳統(tǒng)計(jì)劃驅(qū)動(dòng)型的瀑布模型將軟件的開(kāi)發(fā)過(guò)程劃分為提出需求、制定計(jì)劃、編碼、測(cè)試等過(guò)程，相比之下Scrum將整個(gè)開(kāi)發(fā)過(guò)程分為重復(fù)迭代式增量，稱為Sprint沖刺。

1 Scrum敏捷開(kāi)發(fā)方法

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

1.1 Scrum實(shí)踐敏捷宣言

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

(1)“個(gè)體和互動(dòng)”高于“流程和工具”；

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

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

(4)“響應(yīng)變化”高于“遵循計(jì)劃”。

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

Scrum很好地實(shí)踐了敏捷的這4條價(jià)值觀：

(1)個(gè)體與互動(dòng)：自組織自管理的團(tuán)隊(duì)賦予團(tuán)隊(duì)以權(quán)利，同處一室，面對(duì)面交流，直接溝通，而非文檔溝通；

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

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

(4)響應(yīng)變化：每個(gè)迭代完成對(duì)于客戶最有價(jià)值的功能，及時(shí)地基于用戶反饋?zhàn)龀稣{(diào)整。

所以，通過(guò)這個(gè)實(shí)踐可以給出一個(gè)Scrum的完整定義：Scrum是一個(gè)重復(fù)迭代式增量敏捷開(kāi)發(fā)框架，由一個(gè)大約7個(gè)人的多功能，自組織的團(tuán)隊(duì)使用固定的迭代時(shí)長(zhǎng)(沖刺/sprint)去開(kāi)發(fā)可交付的產(chǎn)品增量。

1.2 Scrum中的“人”

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

研發(fā)團(tuán)隊(duì)是一支多功能團(tuán)隊(duì)，包括開(kāi)發(fā)者、分析師、測(cè)試員等。每個(gè)人各有專長(zhǎng)且能獨(dú)立完成分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試和部署。他們歸屬于一個(gè)項(xiàng)目，同處于一個(gè)房間。研發(fā)團(tuán)隊(duì)是一支可以自組織和自管理的團(tuán)隊(duì)，自主承擔(dān)開(kāi)發(fā)任務(wù)，自主領(lǐng)取任務(wù)、安排工作，負(fù)責(zé)在沖刺結(jié)束前完成可交付產(chǎn)品增量。

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

Tech Leader獨(dú)立負(fù)責(zé)產(chǎn)品中一個(gè)子系統(tǒng)或模塊；根據(jù)整體產(chǎn)品路線，規(guī)劃、落實(shí)所負(fù)責(zé)模塊的技術(shù)路線，推進(jìn)團(tuán)隊(duì)開(kāi)發(fā)進(jìn)度；承擔(dān)技術(shù)指導(dǎo)、技術(shù)支持和關(guān)鍵技術(shù)攻關(guān)；負(fù)責(zé)團(tuán)隊(duì)之間的溝通工作；負(fù)責(zé)團(tuán)隊(duì)建設(shè)；以身作則，實(shí)踐敏捷開(kāi)發(fā)。

Scrum角色如表1所示。

1.3 實(shí)施Scrum

Scrum分成三個(gè)步驟：

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

表1 Scrum角色

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

(3)產(chǎn)品功能性測(cè)試，持續(xù)集成，持續(xù)發(fā)布。當(dāng)整個(gè)產(chǎn)品完成了所有迭代，所有利益相關(guān)者參加產(chǎn)品驗(yàn)收會(huì)，當(dāng)然這是在產(chǎn)品功能性測(cè)試通過(guò)后。產(chǎn)品驗(yàn)收成功后，軟件產(chǎn)品進(jìn)行集成發(fā)布到生產(chǎn)環(huán)境。但如果產(chǎn)品驗(yàn)收不成功，整個(gè)Scrum團(tuán)隊(duì)需要反思驗(yàn)收失敗的原因和迭代過(guò)程中的缺陷及漏洞，并把這些經(jīng)驗(yàn)添加到整個(gè)項(xiàng)目的wiki中由團(tuán)隊(duì)管理，最后把存在問(wèn)題的功能重新加入到產(chǎn)品清單中，準(zhǔn)備進(jìn)行下一輪的迭代。

Scrum過(guò)程如圖1所示。

2 Scrum在跨境電商平臺(tái)的實(shí)踐

2.1 跨境電商平臺(tái)的背景

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

圖1 Scrum過(guò)程

2.2 平臺(tái)架構(gòu)

跨境電商平臺(tái)需要解決的是在多種終端上建立起一個(gè)統(tǒng)一的交易平臺(tái)，解決從選購(gòu)到訂單發(fā)貨一站式服務(wù)。平臺(tái)選擇使用開(kāi)源組織Apache提供的基于項(xiàng)目對(duì)象模型(project object model，POM)的Maven項(xiàng)目管理工具[9]。它包含了一個(gè)項(xiàng)目對(duì)象模型、一組標(biāo)準(zhǔn)集合、一個(gè)項(xiàng)目生命周期、一個(gè)依賴管理系統(tǒng)和用來(lái)運(yùn)行定義在生命周期階段中插件目標(biāo)的邏輯。Maven可以讓開(kāi)發(fā)人員快速地構(gòu)建一個(gè)項(xiàng)目，有效地解決包管理和項(xiàng)目發(fā)布問(wèn)題，并且可以與持續(xù)集成進(jìn)行無(wú)縫對(duì)接。對(duì)于大型系統(tǒng)，采用Maven作為項(xiàng)目管理工具，可以有效地進(jìn)行分工協(xié)作。Maven有效地管理了項(xiàng)目對(duì)于外界jar包的名稱和版本號(hào)等問(wèn)題的依賴，也可以把現(xiàn)階段開(kāi)發(fā)項(xiàng)目的公共部分抽取出來(lái)當(dāng)成對(duì)象模型，加入到所有的項(xiàng)目的依賴中?？缇畴娚唐脚_(tái)的Maven依賴關(guān)系如圖2所示。

圖2 平臺(tái)Maven依賴關(guān)系

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

2.3 演進(jìn)式設(shè)計(jì)

(1)多層測(cè)試。Scrum敏捷開(kāi)發(fā)中的一個(gè)核心就是測(cè)試。將整個(gè)平臺(tái)設(shè)計(jì)進(jìn)行分層，分成基礎(chǔ)服務(wù)層、業(yè)務(wù)層、Web層和頁(yè)面展示層。每一層必須包含單元測(cè)試，以保證代碼的覆蓋率，更加明確地反饋出代碼的質(zhì)量與缺陷。之所以要將整個(gè)平臺(tái)分層設(shè)計(jì)并進(jìn)行多層測(cè)試，其目的就是Scrum敏捷開(kāi)發(fā)的核心理念：適應(yīng)。適應(yīng)產(chǎn)品開(kāi)發(fā)過(guò)程中的每次需求改動(dòng)，保證每次需求改動(dòng)或者添加不影響已有的功能，而且使調(diào)整工作可以盡快執(zhí)行。

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

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

(3)重構(gòu)與簡(jiǎn)潔設(shè)計(jì)。及時(shí)重構(gòu)。重構(gòu)時(shí)堅(jiān)持單一職責(zé)原則、開(kāi)閉原則、里氏替換原則、接口隔離原則、依賴反轉(zhuǎn)原則，及時(shí)避免設(shè)計(jì)糟糕、邏輯混亂的意大利面式代碼[14]。保證設(shè)計(jì)演進(jìn)，以滿足每次需求改動(dòng)或者添加。簡(jiǎn)潔設(shè)計(jì)保證不過(guò)度設(shè)計(jì)以致難以重構(gòu)。

3 結(jié)束語(yǔ)

針對(duì)傳統(tǒng)的計(jì)劃型驅(qū)動(dòng)開(kāi)發(fā)模式不考慮需求變化，隨著計(jì)劃進(jìn)行對(duì)需求的修改代價(jià)越來(lái)越高等致命缺陷，把Scrum敏捷開(kāi)發(fā)方法引入到跨境電商平臺(tái)的開(kāi)發(fā)過(guò)程中[15]。讓開(kāi)發(fā)能適應(yīng)變化，將反饋代碼質(zhì)量，反饋產(chǎn)品需求是否滿足，反饋迭代流程是否有效，反饋設(shè)計(jì)思路是否正確等Scrum的優(yōu)點(diǎn)通過(guò)演進(jìn)式設(shè)計(jì)都運(yùn)用到平臺(tái)的開(kāi)發(fā)過(guò)程中，明顯提高了效率，保證了迭代質(zhì)量。

[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方法在軟件項(xiàng)目管理中的應(yīng)用[J].信息系統(tǒng)工程,2017(1):55.

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

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

[6] 王萬(wàn)意.Scrum敏捷開(kāi)發(fā)在線教育系統(tǒng)[J].電子技術(shù)與軟件工程,2016(8):70-71.

[7] 蔡振凡.基于J2EE的跨境電商平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[D].長(zhǎng)春:吉林大學(xué),2016.

[8] 陳國(guó)棟,羅省賢.Scrum敏捷軟件開(kāi)發(fā)方法實(shí)踐中的改進(jìn)和應(yīng)用[J].計(jì)算機(jī)技術(shù)與發(fā)展,2011,21(12):97-99.

[9] 芮雄健,王忠民.基于敏捷軟件開(kāi)發(fā)方法的基金管理信息系統(tǒng)開(kāi)發(fā)[J].計(jì)算機(jī)應(yīng)用,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的小型團(tuán)隊(duì)軟件項(xiàng)目開(kāi)發(fā)應(yīng)用與研究[D].長(zhǎng)春:東北師范大學(xué),2011.

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

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

[15] 施擁軍.上海貝爾敏捷SCRUM模式下軟件質(zhì)量改進(jìn)措施的研究[D].上海:復(fù)旦大學(xué),2013.