全球化團(tuán)隊(duì)的敏捷開發(fā)模式

唐 涌， 馬振勇， 張道林

（1．東華理工大學(xué)軟件工程學(xué)院，江西 南昌 330013;2．上?；萜沼邢薰?，上海 201203）

計(jì)算機(jī)從誕生以來，技術(shù)的革命就從來沒有停止過。軟件開發(fā)也在進(jìn)步著，人們提出許多改進(jìn)軟件開發(fā)過程的方法。每一種方法都被吹捧為“重大成果性突破”，每一種方法都聲稱“使過程可控”。雖然有很多改進(jìn)的方法，但是管理混亂的軟件開發(fā)過程仍然隨處可見，投入越來越多的人力、財(cái)力，所有人都變得疲憊不堪，但是整個(gè)項(xiàng)目卻在進(jìn)度的泥淖中越陷越深。2001年，為了解決許多公司的軟件團(tuán)隊(duì)陷入不斷增長(zhǎng)的過程泥潭，業(yè)界一批專家一起概括出了一些可以讓軟件開發(fā)團(tuán)隊(duì)具有快速工作、響應(yīng)變化能力的價(jià)值觀和原則，并把這些價(jià)值觀和原則稱為敏捷開發(fā)，他們稱自己為敏捷聯(lián)盟，隨后創(chuàng)建了敏捷聯(lián)盟宣言。自《敏捷宣言》發(fā)布以來，敏捷開發(fā)正在以前所未有的速度改變著整個(gè)開發(fā)流程。經(jīng)過了十幾年的嘗試和完善之后，越來越受到大家的重視。越來越多的開發(fā)者開始學(xué)習(xí)敏捷開發(fā)，越來越多的團(tuán)隊(duì)開始嘗試敏捷開發(fā)，越來越多的公司開始全面推行敏捷開發(fā)。這無不說明，敏捷開發(fā)確實(shí)能夠幫助開發(fā)團(tuán)隊(duì)適應(yīng)當(dāng)前的開發(fā)環(huán)境，更快速有效的發(fā)布自己的產(chǎn)品。

1 敏捷開發(fā)理論

1．1 敏捷開發(fā)的定義

敏捷開發(fā)是軟件項(xiàng)目的一個(gè)概念框架。敏捷即靈活性，快速響應(yīng)。它是一種以人為核心，迭代、循序漸進(jìn)的開發(fā)方法。在敏捷開發(fā)中，會(huì)把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。最大限度地降低短期固定時(shí)間的迭代式軟件的開發(fā)風(fēng)險(xiǎn)。敏捷開發(fā)給企業(yè)也已帶來了巨大的收益。據(jù)業(yè)內(nèi)資深人士和長(zhǎng)期從事敏捷咨詢的服務(wù)公司透露，采用敏捷開發(fā)的團(tuán)隊(duì)一般會(huì)提高3至10倍的效率，軟件的質(zhì)量也有了更加可靠的保證。同時(shí)，敏捷開發(fā)的應(yīng)用也給團(tuán)隊(duì)內(nèi)的每個(gè)成員提供了良好的發(fā)展機(jī)會(huì)。他們的技術(shù)和合作水平都能得到相應(yīng)的提高。敏捷的成功來源于其方法本身的適用性和團(tuán)隊(duì)對(duì)它的深入理解和合理運(yùn)用。敏捷開發(fā)由幾種輕量級(jí)的軟件開發(fā)方法組成。它們包括:極限編程（XP）、Scrum、精益開發(fā)、動(dòng)態(tài)系統(tǒng)開發(fā)方法、特征驅(qū)動(dòng)開發(fā)、水晶開發(fā)等。

1．2 敏捷開發(fā)的現(xiàn)狀

自《敏捷宣言》發(fā)布以來，這種倡導(dǎo)團(tuán)隊(duì)價(jià)值和溝通的開發(fā)方式迅速在業(yè)界擴(kuò)散和傳播，經(jīng)過十余年的發(fā)展，敏捷開發(fā)已經(jīng)從最初的概念走向?qū)嵺`，敏捷開發(fā)方法也經(jīng)過不斷的迭代在人們的實(shí)踐中走向普及。敏捷開發(fā)在國(guó)外得到了很好地推廣，大部分使用敏捷方法的公司都集中在外資跨國(guó)企業(yè)。如HP、IBM、SUN，以及一些軟件外包公司。同時(shí)也有一些比較前沿的國(guó)內(nèi)公司率先推廣了敏捷開發(fā)。如華為、騰訊等。在中國(guó)只有很少的一些有關(guān)組織和公司在近幾年開始使用敏捷方法。所以，中國(guó)的敏捷開發(fā)采用率仍然停留在技術(shù)采納生命周期的初期試用階段。不過中國(guó)的一些知名企業(yè)如騰訊、百度、華為、中興等正在推廣敏捷開發(fā)模式。根據(jù)Forrester/Dr．Dobb’s 2009年的調(diào)查，敏捷開發(fā)已經(jīng)占到所有開發(fā)比例的35%，而且他們預(yù)言，在2013年將會(huì)超過80%［1］。具體數(shù)據(jù)如圖1所示。

圖 1 Forrester/Dr．Dobb’s Global Developer Technographics Survey，Q3 2009

1．3 敏捷開發(fā)與傳統(tǒng)開發(fā)方法的區(qū)別

（1）敏捷開發(fā)注重個(gè)人的創(chuàng)造力和創(chuàng)新能力，團(tuán)隊(duì)相互溝通。設(shè)計(jì)無處不在，開發(fā)人員有更多的靈活性。

（2）敏捷開發(fā)能快速響應(yīng)需求的變化。在敏捷開發(fā)中，盡量多的發(fā)布產(chǎn)品給客戶進(jìn)行試用，就會(huì)從客戶那里得到更多的反饋來改進(jìn)產(chǎn)品。因?yàn)楫a(chǎn)品發(fā)布頻繁，每一個(gè)版本新增加的功能設(shè)計(jì)簡(jiǎn)單，沒有復(fù)雜的架構(gòu)，當(dāng)客戶有新的需求或?qū)π枨筮M(jìn)行變動(dòng)，也能很快適應(yīng)。

（3）注重代碼（產(chǎn)品）超過注重文檔。傳統(tǒng)軟件開發(fā)方法往往先做需求分析，然后做概要設(shè)計(jì)，然后試圖對(duì)一個(gè)軟件開發(fā)項(xiàng)目在很長(zhǎng)的時(shí)間跨度內(nèi)作出詳細(xì)的計(jì)劃［2］，然后依照詳細(xì)設(shè)計(jì)書進(jìn)行開發(fā)。這類方法在計(jì)劃制定完成后拒絕變化，而敏捷開發(fā)方法則擁抱變化，并能根據(jù)客戶反饋隨時(shí)對(duì)計(jì)劃作出相應(yīng)的調(diào)整來適應(yīng)變化。

（4）傳統(tǒng)項(xiàng)目管理

● 事先對(duì)整個(gè)項(xiàng)目進(jìn)行估計(jì)、計(jì)劃、分析。

● 反對(duì)變更;變更需要重新估計(jì)、重新規(guī)劃。

● 嚴(yán)密的合同來減少風(fēng)險(xiǎn)，如果改變需求要走CR流程。

● 項(xiàng)目作為一個(gè)“黑盒子”，對(duì)客戶與供應(yīng)商的可視性差。

● 產(chǎn)品化和測(cè)試階段是分離的。

● 文檔和計(jì)劃驅(qū)動(dòng)的方法。

● 軟件交付時(shí)間晚，意識(shí)到風(fēng)險(xiǎn)的時(shí)間晚。

（5）敏捷項(xiàng)目管理:

● 對(duì)整個(gè)項(xiàng)目做一個(gè)粗略的估計(jì)，每一次迭代都有詳細(xì)的計(jì)劃。

● 鼓勵(lì)變化，客戶價(jià)值驅(qū)動(dòng)開發(fā)。

● 信任和賦予權(quán)力;合約使變更變得簡(jiǎn)單，增加價(jià)值。

● 客戶和開發(fā)人員之間是緊密的連續(xù)的合作關(guān)系。

● 每次迭代都產(chǎn)生可交付的軟件。

● 專注于交付軟件。

● 第一次迭代就可交付能工作的版本，風(fēng)險(xiǎn)發(fā)現(xiàn)得早。

1．4 為什么需要敏捷開發(fā)

傳統(tǒng)的軟件開發(fā)，采用的是瀑布式的開發(fā)模式。在前面開發(fā)階段，整個(gè)流程都是依據(jù)需求在進(jìn)展，從最初的需求提出到需求分析，從概要設(shè)計(jì)到詳細(xì)設(shè)計(jì)，從功能的設(shè)計(jì)到編碼，最后到編碼的測(cè)試、整合與部署，一環(huán)扣一環(huán)。所以說，只有你很小心，才能做得很好。而且做設(shè)計(jì)的時(shí)候，做開發(fā)的人要等待;做開發(fā)的時(shí)候，做測(cè)試的人要等待。所以，大家都在等待上一個(gè)環(huán)節(jié)做好才能做下一個(gè)環(huán)節(jié)。如果開發(fā)過程中發(fā)現(xiàn)設(shè)計(jì)有問題，則需要更改設(shè)計(jì)書。如果發(fā)現(xiàn)了需求有問題，那就要做詳細(xì)的需求變更的評(píng)估了。然而，目前，我們的項(xiàng)目過程中，卻經(jīng)常返工，這其中一個(gè)很重要的原因就是——變化是永恒存在的，敏捷對(duì)于要求不停的在變化，我們一個(gè)迭代就會(huì)發(fā)布給客戶一個(gè)版本，如果客戶覺得好的話，我們會(huì)把它留下來。最后，我們會(huì)不斷使我們的產(chǎn)品變成客戶最想要的版本。采用敏捷方法得當(dāng)?shù)脑挘梢?

● 更加透明，隨時(shí)跟蹤項(xiàng)目的狀態(tài)和進(jìn)展情況，及早發(fā)現(xiàn)問題和風(fēng)險(xiǎn)。

● 快速交付，每次迭代都能交付可運(yùn)行的軟件。

● 最高風(fēng)險(xiǎn)和最高優(yōu)先級(jí)的需求，最優(yōu)先進(jìn)行開發(fā)。

● 改善應(yīng)對(duì)變更能力，減少大量的重計(jì)劃。

● 改善項(xiàng)目溝通。

● 更好地客戶參與，避免錯(cuò)誤的假設(shè)。

2 Scrum開發(fā)方法

2．1 Scrum開發(fā)的定義

Scrum是一種常用的敏捷開發(fā)方法。Scrum是一個(gè)迭代性、增量性的流程，適用于幾乎任何的產(chǎn)品開發(fā)以及工作管理。Scrum將軟件開發(fā)團(tuán)隊(duì)比擬成橄欖球隊(duì)，有明確的最高目標(biāo)，熟悉開發(fā)流程中所需具備的最佳典范與技術(shù)，具有高度自主權(quán)，緊密地溝通合作，以高度彈性解決各種挑戰(zhàn)，確保每天、每個(gè)階段都朝向目標(biāo)并有明確的推進(jìn)。

Scrum開發(fā)方法是由 Ken Schwaber和 Jeff Sutherland提出，名稱來自英式橄欖球，表示“并列爭(zhēng)球”［3］，在比賽中每個(gè)隊(duì)員都應(yīng)時(shí)刻保持對(duì)場(chǎng)上全局的判斷，然后通過集體的快速行為，奮力實(shí)現(xiàn)同一個(gè)目標(biāo)——?jiǎng)倮?/p>

2．2 Scrum 概述

Scrum是由一個(gè)開發(fā)過程、三種角色以及一套規(guī)范的實(shí)施方法組成。它可以被運(yùn)用于軟件開發(fā)、項(xiàng)目維護(hù)、軟件測(cè)試，也可以被用來作為一種管理敏捷項(xiàng)目的框架。在Scrum中，產(chǎn)品需求被定義為產(chǎn)品需求清單。產(chǎn)品需求清單可以是用戶案例，獨(dú)立的功能描述，技術(shù)要求等。所有的產(chǎn)品需求清單都是從一個(gè)簡(jiǎn)單的想法開始，并逐步被細(xì)化，直到可以被開發(fā)的程度。

圖2 橄欖球隊(duì)在爭(zhēng)球

Scrum將開發(fā)過程分為多個(gè)Sprint周期，每個(gè)Sprint有固定的時(shí)間長(zhǎng)度，一般是2至4周的開發(fā)周期。首先，產(chǎn)品需求被分成很多的產(chǎn)品需求清單條目。然后，在Sprint計(jì)劃會(huì)議上，會(huì)把最重要或者是最具價(jià)值的產(chǎn)品需求清單被優(yōu)先安排到下一個(gè)Sprint周期中。同時(shí)，在Sprint計(jì)劃會(huì)上，將會(huì)預(yù)先估計(jì)所有已經(jīng)分配到Sprint周期中的產(chǎn)品需求清單的工作量，并對(duì)每個(gè)條目進(jìn)行設(shè)計(jì)和任務(wù)分配。在Sprint開發(fā)過程中，開發(fā)團(tuán)隊(duì)每天都會(huì)進(jìn)行一次簡(jiǎn)短的Scrum每日例會(huì)。Scrum每日例會(huì)上，每個(gè)團(tuán)隊(duì)成員需要向團(tuán)隊(duì)匯報(bào)各自的進(jìn)展情況，同時(shí)提出目前遇到的各種障礙。每個(gè)Sprint周期結(jié)束后，都會(huì)有一個(gè)可以被使用的系統(tǒng)交付給客戶，并進(jìn)行Sprint評(píng)審會(huì)議。評(píng)審會(huì)上，開發(fā)團(tuán)隊(duì)將會(huì)向客戶或最終用戶演示新的系統(tǒng)功能。同時(shí)，客戶會(huì)提出意見以及一些需求變化。這些可以以新的產(chǎn)品需求清單的形式保留下來，并在隨后的Sprint周期中得以實(shí)現(xiàn)。Sprint回顧會(huì)隨后總結(jié)上次Sprint周期中有哪些不足需要改進(jìn)，以及有哪些值得肯定的方面。最后整個(gè)過程將從頭開始，開始一個(gè)新的Sprint計(jì)劃會(huì)議。Scrum的整個(gè)流程如圖3所示。

2．3 Scrum中三種主要角色

Scrum中有三種重要的角色，他們分別是產(chǎn)品負(fù)責(zé)人、Scrum教練和Scrum團(tuán)隊(duì)。

2．3．1 產(chǎn)品負(fù)責(zé)人

圖3 Scrum framework

產(chǎn)品負(fù)責(zé)人主要負(fù)責(zé)確定產(chǎn)品的功能和達(dá)到要求的標(biāo)準(zhǔn)，指定軟件的發(fā)布日期和交付的內(nèi)容，確保每個(gè)成員明晰需求列表內(nèi)容、明確哪些條目具有最高優(yōu)先級(jí)，同時(shí)產(chǎn)品負(fù)責(zé)人有權(quán)力接受或拒絕開發(fā)團(tuán)隊(duì)的工作成果。在我們看來，產(chǎn)品經(jīng)理是最重要的一個(gè)角色，他負(fù)責(zé)最大化Scrum團(tuán)隊(duì)的工作價(jià)值。我們認(rèn)為，很多產(chǎn)品沒有真正得到用戶的認(rèn)可是因?yàn)闆]有像喬布斯一樣的產(chǎn)品負(fù)責(zé)人［4］。產(chǎn)品負(fù)責(zé)人的職責(zé)主要?dú)w納為以下幾點(diǎn):

● 定義產(chǎn)品特性。

● 決定發(fā)布日期和內(nèi)容。

● 對(duì)產(chǎn)品收益負(fù)責(zé)（ROI）。

● 根據(jù)商業(yè)價(jià)值排定特性的優(yōu)先級(jí)。

● 根據(jù)需要在每個(gè)迭代中調(diào)整產(chǎn)品特性和優(yōu)先級(jí)。

● 接受或否決開發(fā)結(jié)果。

2．3．2 Scrum 教練

Scrum Master主要負(fù)責(zé)整個(gè)Scrum流程在項(xiàng)目中的順利實(shí)施和進(jìn)行，以及清除客戶和開發(fā)工作之間的溝通障礙，使得客戶可以直接驅(qū)動(dòng)開發(fā)。他的重要之處在于，他能保證自己的團(tuán)隊(duì)不受外界干擾，能夠更快更好地實(shí)現(xiàn)Scrum團(tuán)隊(duì)的工作價(jià)值。同時(shí)他負(fù)責(zé)確保成員都能理解并遵循過程，就像舵手，要迅速調(diào)整團(tuán)隊(duì)方向。Scrum Master的職責(zé)主要?dú)w納為以下幾點(diǎn):

● 對(duì)項(xiàng)目組來說代表管理層。

● 負(fù)責(zé)制定Scrum價(jià)值觀念和實(shí)踐，確保每一個(gè)成員都認(rèn)同Scrum價(jià)值觀和遵守其游戲規(guī)則。

● 組織每天的Daily Scrum會(huì)議。

● 幫助Scrum Team規(guī)劃Sprint計(jì)劃。

● 清除障礙。

● 確保團(tuán)隊(duì)功能完備富有效率。

● 促進(jìn)所有角色和職能的緊密協(xié)作。

● 替團(tuán)隊(duì)抵御外部干擾。

2．3．3 Scrum 團(tuán)隊(duì)

Scrum團(tuán)隊(duì)是Scrum的中心角色，產(chǎn)品交付要依靠團(tuán)隊(duì)。Scrum團(tuán)隊(duì)主要負(fù)責(zé)軟件產(chǎn)品在Scrum規(guī)定流程下進(jìn)行開發(fā)工作，人數(shù)控制在5至10人左右，每個(gè)成員可能負(fù)責(zé)不同的技術(shù)方面，但要求每個(gè)成員必須要有很強(qiáng)的自我管理能力，同時(shí)具有一定的表達(dá)能力;成員可以采用任何工作方式，只要能達(dá)到Sprint的目標(biāo)。Scrum團(tuán)隊(duì)的職責(zé)主要?dú)w納為以下幾點(diǎn):

● 跨部門:程序員，測(cè)試員，界面設(shè)計(jì)人員等等。

● 成員必須是全職投入:可以有例外 （例如數(shù)據(jù)庫管理員等）。

● 團(tuán)隊(duì)自我組織:理想情況下，團(tuán)隊(duì)成員是平等的，不分頭銜。

● 一個(gè)sprint中保持成員穩(wěn)定。

● 負(fù)責(zé)將Product Backlog轉(zhuǎn)化成Sprint中的工作項(xiàng)目。

● 所有團(tuán)隊(duì)成員協(xié)調(diào)，合作完成Sprint中每一個(gè)規(guī)定的工作。

● 所有團(tuán)隊(duì)成員和Scrum Master負(fù)責(zé)每一個(gè)Sprint的成功。

2．4 Scrum中三種產(chǎn)出工件

Scrum中有三種產(chǎn)出工件，分別為產(chǎn)品需求清單、沖刺訂單和燃盡圖。

2．4．1 產(chǎn)品需求清單

產(chǎn)品需求清單是囊括了開發(fā)產(chǎn)品可能需要的所有事項(xiàng)的優(yōu)先排列表。產(chǎn)品需求清單也可稱為User Stories（用例），因?yàn)樗鼈兡軌蚪o產(chǎn)品的用戶帶來價(jià)值。產(chǎn)品負(fù)責(zé)人負(fù)責(zé)產(chǎn)品需求清單的內(nèi)容、可用性和優(yōu)先級(jí)。產(chǎn)品需求清單永遠(yuǎn)不會(huì)是全面的，最初的版本只列出最基本的和眾所周知的需求。產(chǎn)品需求清單根據(jù)產(chǎn)品和開發(fā)環(huán)境的變化而演進(jìn)。產(chǎn)品需求清單是動(dòng)態(tài)的，它經(jīng)常發(fā)生變化以確保產(chǎn)品更合理、更具競(jìng)爭(zhēng)力和更有用。只要產(chǎn)品存在，產(chǎn)品需求清單就存在。基本上，產(chǎn)品需求清單是為了實(shí)現(xiàn)產(chǎn)品的功能所需要的工作的列表，包括:

● 功能方面的需求，功能點(diǎn)。

● 非功能方面的需求，如性能改進(jìn)。

● 要修改的Bug，上一版本的已知錯(cuò)誤。

● 新技術(shù)，如支持新的操作系統(tǒng)或者平臺(tái)。

● 不確定項(xiàng)，如新的功能。

● 產(chǎn)品需求清單是不斷完善的。

Product Owner在項(xiàng)目進(jìn)行過程中可以隨時(shí)更新:增加、刪除、修改功能，變更優(yōu)先級(jí)等。下一次迭代中要包含較高優(yōu)先級(jí)的需求。

2．4．2 沖刺訂單

沖刺訂單是由Scrum團(tuán)隊(duì)在Sprint計(jì)劃會(huì)議中確認(rèn)的待辦任務(wù)列表。團(tuán)隊(duì)選擇了Product Backlog中的一些項(xiàng)目，通常是用戶故事的形式，并且明確每個(gè)用戶故事需要完成的任務(wù)。大多數(shù)團(tuán)隊(duì)會(huì)估算每個(gè)任務(wù)需要多少時(shí)間去完成。

許多條目在Sprint計(jì)劃會(huì)議中已經(jīng)定義。這些就是團(tuán)隊(duì)確認(rèn)的完成Sprint目標(biāo)所必須做的工作。Sprint待辦事項(xiàng)列表?xiàng)l目必須被分解。進(jìn)行充分的分解，那么過程中發(fā)生的變化就可以在每日例會(huì)上得到理解。一天或一天之內(nèi)的工作量對(duì)Sprint待辦事項(xiàng)列表?xiàng)l目來說是比較適合的。

團(tuán)隊(duì)在整個(gè)Sprint內(nèi)都會(huì)修改Sprint待辦事項(xiàng)列表，同時(shí)在Sprint內(nèi)合并Sprint待辦事項(xiàng)列表。因?yàn)樗轻槍?duì)每個(gè)成員的任務(wù)，所以可能有時(shí)任務(wù)會(huì)偏多或偏少，亦或某項(xiàng)任務(wù)耗費(fèi)的時(shí)間超出或提前于預(yù)期。當(dāng)出現(xiàn)新工作時(shí)，團(tuán)隊(duì)需要將其追加到Sprint待辦事項(xiàng)列表中去。隨著任務(wù)進(jìn)行或者被完成，需要更新每項(xiàng)任務(wù)的估算剩余工作量。如果某項(xiàng)任務(wù)失去開發(fā)的意義，就可以將其除去。在Sprint內(nèi)只有團(tuán)隊(duì)可以對(duì)Sprint待辦事項(xiàng)列表進(jìn)行修改，也只有團(tuán)隊(duì)可以對(duì)列表的內(nèi)容或估算進(jìn)行修改。Sprint待辦事項(xiàng)列表是高可見度的，是對(duì)團(tuán)隊(duì)計(jì)劃在當(dāng)前Sprint內(nèi)完成工作的實(shí)時(shí)反映，并且，該列表只屬于團(tuán)隊(duì)。

2．4．3 燃盡圖

Sprint待辦事項(xiàng)列表燃盡圖展現(xiàn)的是當(dāng)前Sprint內(nèi)剩余的Sprint待辦事項(xiàng)列表工作數(shù)量。創(chuàng)建該圖需要通過累計(jì)Sprint中每日待辦事項(xiàng)列表估算來確定剩余工作量。Sprint內(nèi)的剩余工作量就是所有Sprint待辦事項(xiàng)列表的剩余工作總量。每天對(duì)這些數(shù)據(jù)進(jìn)行跟蹤，并繪制燃盡圖，時(shí)刻顯示剩余工作量。用線將圖上的點(diǎn)依次連接起來，團(tuán)隊(duì)就可以控制完成Sprint工作的進(jìn)程。所耗時(shí)長(zhǎng)并不屬于Scrum的關(guān)注范圍，剩余工作量和完成日期才是利益相關(guān)因素。

2．5 Scrum中五種儀式

Scrum中有五種重要的儀式，他們分別是Sprint、Sprint計(jì)劃、Spring 評(píng)審、Sprint回顧、Scrum每日例會(huì)。

2．5．1 Sprint

Sprint的本意是指沖刺，在 Scrum中，一個(gè)Sprint就是一個(gè)迭代，Scrum項(xiàng)目通過一系列的Sprints來推進(jìn)，Sprint長(zhǎng)度通常2－4周，它是一個(gè)時(shí)間箱，在項(xiàng)目進(jìn)行過程中不允許延長(zhǎng)或縮短Sprint長(zhǎng)度。

2．5．2 Sprint計(jì)劃

Sprint計(jì)劃會(huì)議制定迭代計(jì)劃。對(duì)于一個(gè)月為周期的Sprint，計(jì)劃會(huì)議的時(shí)間盒限定為8小時(shí)。對(duì)于較短的Sprint，根據(jù)Sprint的長(zhǎng)度，按比例縮小會(huì)議的時(shí)間。Sprint計(jì)劃會(huì)議的內(nèi)容包括以下兩個(gè)部分:在第一部分中決定Sprint需要做什么。第二部分（4小時(shí)的時(shí)間盒對(duì)應(yīng)一個(gè)月的Sprint），團(tuán)隊(duì)研究在Sprint內(nèi)如何將功能構(gòu)建成產(chǎn)品增量。

2．5．3 Spring 評(píng)審

Sprint末尾時(shí)要舉行Sprint評(píng)審會(huì)議，一個(gè)月的Sprint通常對(duì)應(yīng)4小時(shí)時(shí)間盒的評(píng)審會(huì)議。對(duì)于時(shí)間少于一個(gè)月的Sprint來說，根據(jù)Sprint的長(zhǎng)度，按比例縮小會(huì)議的時(shí)間。在Sprint評(píng)審會(huì)議中，Scrum團(tuán)隊(duì)和利益相關(guān)人溝通Sprint中完成了哪些工作。然后，根據(jù)完成情況和Sprint期間產(chǎn)品待辦事項(xiàng)列表的變化，他們確定接下來的工作。這是一個(gè)非正式會(huì)議，會(huì)議中進(jìn)行功能演示，以促進(jìn)下一步工作的互助與合作

2．5．4 Sprint回顧

在Sprint評(píng)審會(huì)議結(jié)束之后和下個(gè)Sprint計(jì)劃會(huì)議之前，Scrum團(tuán)隊(duì)需要舉行Sprint回顧會(huì)議。對(duì)于長(zhǎng)度為一個(gè)月的Sprint，這是一個(gè)3小時(shí)時(shí)間盒的會(huì)議（根據(jù)Sprint的長(zhǎng)度，按比例縮小會(huì)議的時(shí)間）。在這個(gè)會(huì)議上，Scrum Master鼓勵(lì)團(tuán)隊(duì)在Scrum過程框架和時(shí)間的范圍內(nèi)，對(duì)自己的開發(fā)過程進(jìn)行改進(jìn)，使下一個(gè)Sprint的效率更高、更易工作。許多書籍都介紹了召開回顧會(huì)議的技巧。

2．5．5 Scrum 每日例會(huì)

團(tuán)隊(duì)每天進(jìn)行15分鐘的檢驗(yàn)和適應(yīng)的會(huì)議就稱為Scrum每日例會(huì)。每日例會(huì)在各個(gè)Sprint都是在同一時(shí)間、同一地點(diǎn)進(jìn)行。會(huì)議上，每個(gè)團(tuán)隊(duì)成員需要匯報(bào)以下三個(gè)問題:

1．從上次會(huì)議到現(xiàn)在都完成了哪些工作;

2．下次每日例會(huì)之前準(zhǔn)備完成什么;

3．工作中遇到了哪些障礙。

每日例會(huì)可以增強(qiáng)交流溝通、省略其他會(huì)議、確定并排除開發(fā)遇到的障礙、強(qiáng)調(diào)和提倡快速?zèng)Q策、提高每個(gè)成員對(duì)項(xiàng)目的認(rèn)知程度。

3 全球化團(tuán)隊(duì)的敏捷開發(fā)模式

3．1 HP的全球化開發(fā)團(tuán)隊(duì)和敏捷開發(fā)模式

HP是一個(gè)全球化的公司，擁有著數(shù)量龐大的全球化開發(fā)團(tuán)隊(duì)。我們開發(fā)的一些大型應(yīng)用一般會(huì)有十幾個(gè)甚至幾十個(gè)子應(yīng)用程序，它們之間的依賴關(guān)系有的時(shí)候非常復(fù)雜，如圖4所示。這樣就需要不同應(yīng)用程序開發(fā)團(tuán)隊(duì)之間的相互協(xié)作，溝通很重要。比如，我們總共有600個(gè)人在開發(fā)一個(gè)大型應(yīng)用，我們可以分為20個(gè)開發(fā)團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)大概30人。

圖4 多個(gè)子應(yīng)用程序以及關(guān)聯(lián)關(guān)系

這還不夠，一般每一個(gè)應(yīng)用程序開發(fā)團(tuán)隊(duì)都是一個(gè)全球化的團(tuán)隊(duì)。所以，30個(gè)人可能包含一個(gè)美國(guó)團(tuán)隊(duì)、一個(gè)歐洲團(tuán)隊(duì)、一個(gè)中國(guó)團(tuán)隊(duì)、一個(gè)印度團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)7－8人。全球化的團(tuán)隊(duì)就需要我們更多的團(tuán)隊(duì)合作了。如圖5所示。

圖5 多個(gè)子應(yīng)用程序的全球化開發(fā)團(tuán)隊(duì)

這么復(fù)雜的應(yīng)用程序，這么復(fù)雜的人員編排，如果沒有很好的管理方式，根本無從下手。Scrum似乎很好地解決了這個(gè)問題，把團(tuán)隊(duì)拆分成一個(gè)個(gè)的小團(tuán)隊(duì)，每個(gè)小團(tuán)隊(duì)都在執(zhí)行Scrum，一個(gè)迭代一個(gè)迭代地往前推進(jìn)。如圖6所示。

圖6 多個(gè)子應(yīng)用程序的全球化Scrum開發(fā)團(tuán)隊(duì)

3．2 Scrum of Scrum

正因?yàn)橛腥绱她嫶蟮娜蚧疭crum團(tuán)隊(duì)，需要Scrum of Scrum來管理好Scrum團(tuán)隊(duì)。其實(shí)Scrum of Scrum就是Scrum的項(xiàng)目管理，用Scrum的方式來管理 Scrum團(tuán)隊(duì)。在 HP，每周會(huì)有 Scrum of Scrum，每個(gè)Scrum團(tuán)隊(duì)的Scrum Master一般都會(huì)參加。Scrum of Scrum不只是有一層，項(xiàng)目大的情況下，會(huì)有Scrum（of scrums（of scrums…）。如圖7所示。

圖7 Scrum of Scrum

3．3 風(fēng)險(xiǎn)控制和成本控制

風(fēng)險(xiǎn)控制和成本控制是項(xiàng)目管理中非常重要的兩個(gè)部分。“風(fēng)險(xiǎn)發(fā)現(xiàn)得越早，消除風(fēng)險(xiǎn)的成本就越低”［5］。在Scrum中，把項(xiàng)目分成一個(gè)個(gè)的迭代，即使一個(gè)迭代出現(xiàn)了問題，在回顧會(huì)議的時(shí)候發(fā)現(xiàn)問題，及時(shí)改正，這樣損失的只是一個(gè)迭代。而且還會(huì)通過持續(xù)集成、自動(dòng)測(cè)試、頻繁交付、客戶參與等方法極大程度地降低傳統(tǒng)意義上的開發(fā)風(fēng)險(xiǎn)。

3．4 持續(xù)集成

傳統(tǒng)的瀑布式開發(fā)，測(cè)試和集成一直延遲到項(xiàng)目結(jié)束時(shí)才執(zhí)行，問題往往發(fā)現(xiàn)得太晚，如果要解決問題，則有可能導(dǎo)致錯(cuò)過最后期限。所以，持續(xù)集成對(duì)敏捷開發(fā)非常重要。持續(xù)集成是一種軟件開發(fā)實(shí)踐，要求團(tuán)隊(duì)成員經(jīng)常集成他們的工作。每個(gè)人至少每天集成一次，這導(dǎo)致每天有多個(gè)集成。在HP，很多的應(yīng)用程序要頻繁做集成，這些集成是通過自動(dòng)化的構(gòu)建進(jìn)行驗(yàn)證的，這些構(gòu)建運(yùn)行回歸測(cè)試，以盡快檢測(cè)集成錯(cuò)誤。我們發(fā)現(xiàn)，這種方法會(huì)導(dǎo)致集成問題大幅減少，更快地實(shí)現(xiàn)有凝聚力的軟件開發(fā)。

4 結(jié)束語

敏捷開發(fā)，不代表沒有設(shè)計(jì)，沒有文檔。敏捷開發(fā)帶來的更多的是一種思想，它要求團(tuán)隊(duì)能夠充分合作，有激情，有熱情，循序漸進(jìn)地朝著正確的方向前進(jìn)，并且能夠快速地發(fā)現(xiàn)問題，快速地糾正錯(cuò)誤。Scrum則是敏捷開發(fā)的一個(gè)典型，只有把目標(biāo)拆分，一個(gè)沖刺一個(gè)沖刺地去實(shí)現(xiàn)，才能更好地把握項(xiàng)目的進(jìn)度和風(fēng)險(xiǎn)。HP等很多國(guó)外公司已經(jīng)全面開始推行敏捷開發(fā)，相信未來更多的國(guó)內(nèi)公司能夠認(rèn)識(shí)敏開發(fā)，并從敏捷開發(fā)中受益。

［1］任思迷．論敏捷開發(fā)中的團(tuán)隊(duì)建設(shè)［J］．計(jì)算機(jī)光盤軟件與應(yīng)用，2013，29（2）:114-118．

［2］程志梅，陸鋼，劉光萍．基于B/S模式的網(wǎng)絡(luò)教學(xué)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)［J］．東華理工大學(xué)學(xué)報(bào):社會(huì)科學(xué)版，2009，28（2）:185-187．

［3］王哲．Android敏捷開發(fā)指南［J］．程序員，2012，21（9）:53-56．

［4］許惠清．基于網(wǎng)絡(luò)環(huán)境下教學(xué)模式的研究［J］．東華理工大學(xué)學(xué)報(bào):社會(huì)科學(xué)版，2008，27（3）:276-278．

［5］胡文生，趙明，楊劍峰，等．敏捷開發(fā)過程中的迭代策略分析［J］．微電子學(xué)與計(jì)算機(jī)，2012，27（5）:276-278．