《軟件項(xiàng)目管理原理與實(shí)踐》 教案 第10章-敏捷項(xiàng)目管理

第10章敏捷項(xiàng)目管理

內(nèi)容提要

10.1概述

10.1.1敏捷概述

10.1.2敏捷項(xiàng)目管理的焦點(diǎn)

10.1.3敏捷項(xiàng)目管理指導(dǎo)原則

10.1.4敏捷流程架構(gòu)

10.2管理的角色與職責(zé)

10.2.1角色

10.2.2職責(zé)

10.3敏捷項(xiàng)目管理的特征

10.3.1敏捷方法的特點(diǎn)

10.3.2敏捷方法的核心思想

10.3.3敏捷項(xiàng)目管理方式

內(nèi)容提要

10.4主要敏捷方法

10.4.1XP極限編程

10.4.2Scrum工具

10.4.3Cockbum的水晶系列方法

10.4.4開放式源碼

10.4.5Coad的功用驅(qū)動(dòng)開發(fā)方法

10.4.6自適應(yīng)軟件開發(fā)方法

10.4.7DevOps

10.5案例分析：敏捷開發(fā)技術(shù)在電子商務(wù)軟件的應(yīng)

10.5.1項(xiàng)目背景說明

10.5.2項(xiàng)目組織機(jī)構(gòu)

10.5.3項(xiàng)目實(shí)施過程

10.5.4項(xiàng)目實(shí)施效果

10.6小結(jié)

極限項(xiàng)目管理

極限項(xiàng)目管理

極限項(xiàng)目管理

敏捷項(xiàng)目管理

敏捷項(xiàng)目管理(AgileProjectManagement,APM)是近來流行的項(xiàng)目管理方法論。

APM是該領(lǐng)域的新概念，敏捷宣言是所有APM模型的指導(dǎo)原則。

多數(shù)APM模型源于軟件開發(fā)，因此對軟件開發(fā)實(shí)踐的針對性很強(qiáng).

原型和適應(yīng)性項(xiàng)目框架是APM模型中僅有的適用于所有類型的項(xiàng)目的模型。

由于開發(fā)周期短，對需求管理恰當(dāng)，敏捷項(xiàng)目管理正在從軟件研發(fā)行業(yè)延伸到已經(jīng)采取項(xiàng)目化

管理的大部分行業(yè)中。

敏捷項(xiàng)目管理

敏捷方法允許軟件開發(fā)者更快速地反應(yīng)，提供更好的方法處理變化和捕捉機(jī)會(huì)，弱化了經(jīng)典的

軟件生命周期，允許開發(fā)團(tuán)隊(duì)在同一軟件系統(tǒng)的不同部分開展工作。

剛開始開發(fā)軟件時(shí)，并不需要一個(gè)完整的軟件需求說明，很可能只有一個(gè)關(guān)于這個(gè)軟件基本想

法的簡短描述。

以此作為起點(diǎn)，團(tuán)隊(duì)開始根據(jù)現(xiàn)實(shí)情況的要求創(chuàng)建需求規(guī)格說明、編碼和測試。

可能第一天編碼，第二天撰寫軟件需求規(guī)格說明，第三天一調(diào)試程序。

敏捷軟件開發(fā)

開始，敏捷軟件開發(fā)并沒有一套固定的步驟，更多體現(xiàn)為一套準(zhǔn)則。

敏捷方法的創(chuàng)始者確定了兩條基本準(zhǔn)則。

以通過快速響應(yīng)為客戶提供高質(zhì)量的軟件為目標(biāo)，使開發(fā)的軟件能適應(yīng)不斷變化的環(huán)境。

之后，敏捷軟件開發(fā)已經(jīng)形成一套有關(guān)最佳實(shí)踐和方法的論著，但這些并不是經(jīng)典軟件工程中

那些固定的技術(shù)。

敏捷軟件工程是一種態(tài)度、一種管理風(fēng)格而不是硬性規(guī)定。

敏捷屬性

10.1概念及簡介

敏捷項(xiàng)目管理的概念來源于敏捷軟件開發(fā)“隨著敏捷軟件開發(fā)的發(fā)展，極限項(xiàng)目管理(Ex:reme

ProjectManagement)和敏捷項(xiàng)目管理(AgileProjectManagement)的概念和方法被相繼提出，

并仍在不斷發(fā)展。

實(shí)際上，敏捷項(xiàng)目管理只是各種敏捷軟件開發(fā)方法相應(yīng)項(xiàng)目管理的統(tǒng)稱。

10.1概念及簡介

10.1.1敏捷概述

1.敏捷簡介

多數(shù)軟件開發(fā)仍然是一個(gè)顯得混亂的活動(dòng)，即典型的“邊寫邊改(codeandfix)”。

設(shè)計(jì)過程充斥著短期的，即時(shí)的決定，而無完整的規(guī)劃。

這種模式對小系統(tǒng)開發(fā)其實(shí)很管用，但是當(dāng)系統(tǒng)變得越大越復(fù)雜時(shí)，要想加入新的功能就越來

越困難。

同時(shí)，錯(cuò)誤故障越來越多，越來越難于排除。

一個(gè)典型的標(biāo)志，就是當(dāng)系統(tǒng)功能完成后有一個(gè)很長的測試階段.有時(shí)甚至有遙遙無期之感，

從而對項(xiàng)目的完成產(chǎn)生嚴(yán)重的影響。

1.敏捷簡介

我們使用這種開發(fā)模式已有很長時(shí)間了，不過我們實(shí)際上也有另外一種選擇，那就是“正規(guī)方

法(methodology)"<>

這些方法，對開發(fā)過程有著嚴(yán)格而詳盡的規(guī)定，使軟件開發(fā)更有可預(yù)設(shè)性并提高效率，這種思

路是借鑒了其他工程領(lǐng)域的實(shí)踐。

這些正規(guī)方法已存在了很長時(shí)間了，但是并沒有取得令人矚目的成功，甚至就沒怎么引起人們

的注意。

對這些方法最常聽見的批評(píng)就是它們的官僚繁瑣，要是按照它的要求來，那么有做太多的事情

需要做，而延緩整個(gè)開發(fā)法程。

所以它們通常被認(rèn)為是“繁瑣滯重型”方法，或“巨型(monumental)”方法。

軟件開發(fā)的發(fā)展

1.敏捷簡介

1.敏捷簡介

敏捷簡史一意識(shí)的代理人

雪鳥城、敏捷宣言

猶他州(Utah)的雪鳥城(Snowbird)位于鹽湖城外約25英里的地方，2001年2月11日至13

日，就在這里.一個(gè)滑雪勝地，17個(gè)人聚到一起，交談、滑雪、休閑，當(dāng)然還有聚餐。制定并

簽署了行業(yè)歷史上最重要的文件之一：關(guān)于編碼集的獨(dú)立宣言。

2001年2月會(huì)上寫敏捷學(xué)院的軟件工程師

《敏捷軟件開發(fā)宣言》的簽署，推動(dòng)了敏捷方法的發(fā)展，敏捷宣言本質(zhì)是揭示一種更好的軟件

開發(fā)方法，啟迪人們重新思考軟件開發(fā)中的價(jià)值和如何更好的工作。

10.1概念及簡介

《敏捷軟件開發(fā)宣言》的簽署，推動(dòng)了敏捷方法的發(fā)展，敏捷宣言本質(zhì)是揭示一種更好的軟件

開發(fā)方法，啟迪人們重新思考軟件開發(fā)中的價(jià)值和如何更好的工作。

《敏捷軟件開發(fā)宣言》四大核心價(jià)值

(1)個(gè)人和互動(dòng)高于流程和工具。

(2)工作軟件高于理解文檔。

(3)客戶協(xié)作高于合同協(xié)酉。

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

《敏捷軟件開發(fā)宣言》12條原則

(1)通過早期和連續(xù)型的高價(jià)值工作交付滿足“客戶”。

(2)大工作分成可以迅速完成的較小組成部門。

(3)識(shí)別最好的工作是從自我組織的團(tuán)隊(duì)中出現(xiàn)的，

(4)為積極員工提供他們需要的環(huán)境和支持，并相信他們可以完成工作。

(5)創(chuàng)建可以改善可持續(xù)工作的流程。

(6)維持完整工作的不變的步調(diào)。

(7)歡迎改變的需求，即使是在項(xiàng)目后期。

(8)在項(xiàng)目期間每天與項(xiàng)目團(tuán)隊(duì)和業(yè)務(wù)所有者開會(huì)。

(9)在定期修正期，讓團(tuán)隊(duì)反映如何能高效，然后進(jìn)行相應(yīng)地行為調(diào)整。

(10)通過完成的工作量L量工作進(jìn)度。

(11)不斷地追求完善。

(12)利用調(diào)整獲得競爭優(yōu)勢。

1.敏捷開發(fā)方式簡介

2.與傳統(tǒng)開發(fā)方法比較

2.敏捷開發(fā)方式與傳統(tǒng)開發(fā)方法的比較

2.與傳統(tǒng)開發(fā)方法比較

傳統(tǒng)開發(fā)是一種瀑布式的流程

2.與傳統(tǒng)開發(fā)方法比較

敏捷開發(fā)流程

2.與傳統(tǒng)開發(fā)方法比較

二者之間的主要區(qū)別如下：

(1)敏捷開發(fā)是以人為中心，而傳統(tǒng)開發(fā)以過程為中心。并不是說，傳統(tǒng)開發(fā)就沒有人的參與，

或者說人不是一個(gè)重要因素。應(yīng)該說的是，敏捷開發(fā)和傳統(tǒng)開發(fā)的側(cè)重點(diǎn)、中心不同。

那么，為什么會(huì)是這個(gè)樣子呢？

因?yàn)椋瑐鹘y(tǒng)開發(fā)中，設(shè)計(jì)已經(jīng)是在初始階段完成了，在實(shí)現(xiàn)階段不再修改，換句話說，實(shí)現(xiàn)階

段就是對設(shè)計(jì)的完成，設(shè)計(jì)方案是不可改變的了。

這樣就忽略了用戶的反饋、忽略了開發(fā)人員的設(shè)計(jì)的主觀能動(dòng)性，使得開發(fā)人員只是專注于代

碼層面的事情。

(2)敏捷開發(fā)是有適應(yīng)能力的，而傳統(tǒng)開發(fā)是計(jì)劃驅(qū)動(dòng)的。

傳統(tǒng)開發(fā)，設(shè)計(jì)階段完成了，整個(gè)的過程就是按照設(shè)計(jì)方案進(jìn)行，在設(shè)計(jì)階段的后續(xù)過程中，

無法再對設(shè)計(jì)方案進(jìn)行修改，而敏捷開發(fā)需要一次次的迭代完成，正是這些迭代完成了對客戶

真實(shí)需求的軟件的演進(jìn)。

瀑布模型和敏捷開發(fā)流程

傳統(tǒng)軟件開發(fā)與敏捷軟件開發(fā)的對比

10.1.2敏捷項(xiàng)目管理的焦點(diǎn)

主管期望在項(xiàng)目管理流程中得到什么呢？

豐倍相徨至IIQ小半犍的中西■

首先：?主管希望這個(gè)流蓑是可靠的，每個(gè)項(xiàng)目都可以產(chǎn)生創(chuàng)新的結(jié)果。

第二，主管希望這個(gè)流程是可預(yù)見的，這樣他可以有效地計(jì)劃和管理諸如財(cái)務(wù)管理、人員配備

和產(chǎn)品投放等企業(yè)活動(dòng)。

第三，主管想得到可信的、符合實(shí)際的信息，因?yàn)闃?gòu)想可能是錯(cuò)的、商業(yè)模式可能是錯(cuò)的、人

們可能遇到不能跨越的障礙、項(xiàng)目進(jìn)展并不總是一帆風(fēng)順。

如果項(xiàng)目需要終止，他想及早結(jié)束而不是等到后期才結(jié)束，可信的進(jìn)度報(bào)告可以讓經(jīng)理盡早采

取適當(dāng)?shù)拇胧?/p>

10.1.2敏捷項(xiàng)目管理的焦點(diǎn)

可靠但不重復(fù)

在評(píng)估項(xiàng)目績效時(shí)，不能區(qū)分高度不確定性和高度確定性的項(xiàng)目環(huán)境會(huì)造成很多混亂。

這種混亂源于兩個(gè)地方，即范圍的定義、估計(jì)和限制之間的區(qū)別。

可靠流程將重點(diǎn)放在輸出，而不是輸入?？煽啃允且越Y(jié)果為推動(dòng)力，重復(fù)性是以輸入為推動(dòng)力。

敏捷項(xiàng)目中需要考慮的正確范圍不是限定的要求，而是清晰明白的產(chǎn)品構(gòu)想。

“整個(gè)產(chǎn)品是否符合客戶或者產(chǎn)品營銷的構(gòu)想？”混亂的另一個(gè)源泉是將成本和進(jìn)度看作是估

計(jì)，而不是限制。

進(jìn)度報(bào)告

敏捷項(xiàng)S管理并不放棄控制，它確定了責(zé)任，修訂了對控制內(nèi)容的定義。

10.1.2敏捷項(xiàng)目管理的焦點(diǎn)

(1)可靠但不重復(fù)

在評(píng)估項(xiàng)目績效時(shí)，不能區(qū)分高度不確定性和高度確定性的項(xiàng)目環(huán)境會(huì)造成很多混亂。

這種混亂源于兩個(gè)地方，即范圍的定義、估計(jì)和限制之間的區(qū)別。

可靠流程將重點(diǎn)放在輸出，而不是輸入。

可靠性是以結(jié)果為推動(dòng)力，重復(fù)性是以輸入為推動(dòng)力。敏捷項(xiàng)目中需要考慮的正確范圍不是限

定的要求，而是清晰明白的產(chǎn)品構(gòu)想。

“整個(gè)產(chǎn)品是否符合客戶或者產(chǎn)品營銷的構(gòu)想？”混亂的另一個(gè)源泉是將成本和進(jìn)度看作是估

計(jì)，而不是限制。

(2)進(jìn)度報(bào)告

敏捷項(xiàng)目管理并不放棄控制，它確定了責(zé)任，修訂了對控制內(nèi)容的定義。

10.1.3敏捷項(xiàng)目管理指導(dǎo)原則

人是受價(jià)值觀驅(qū)使的，敏捷項(xiàng)目管理因而也是以價(jià)值觀為唯動(dòng)力的。

一個(gè)團(tuán)隊(duì)可以采用敏捷做法，但如果它不接受敏捷價(jià)值觀和原則，它將不能得到敏捷開發(fā)的潛

在好處。

原則性強(qiáng)的領(lǐng)導(dǎo)是高效團(tuán)隊(duì)最為關(guān)鍵的特征之一。在業(yè)績優(yōu)良的團(tuán)隊(duì)中、領(lǐng)導(dǎo)管理原則，而原

則管理團(tuán)隊(duì)。

敏捷宣言的核心價(jià)值觀派生出6條原則，而正是這6條原則指導(dǎo)著敏捷項(xiàng)目管理。

如果沒有這些指導(dǎo)原則，那么，即使敏捷做法，如迭代交付，通常也會(huì)被錯(cuò)誤使用，甚至更糟

糕的是，團(tuán)隊(duì)自以為自己使用的是敏捷做法而其實(shí)卻不然。

10.1.3敏捷項(xiàng)目管理指導(dǎo)原則

1.客戶價(jià)值和創(chuàng)新產(chǎn)品

(1)提供客戶價(jià)值；

(2)采用迭代的、基于功能的交付方式；

(3)支持卓越技術(shù)。

2.領(lǐng)導(dǎo)一協(xié)作管理

(1)鼓勵(lì)探索；

(2)建立適應(yīng)能力(自我組織、自律)強(qiáng)的團(tuán)隊(duì)；

(3)簡單化。

敏捷項(xiàng)目管理指導(dǎo)原則

這6條原則有效地組合在一起，組成了一個(gè)原則體系。雖然，各條原則分開來也可能有幫助，

但6條原則合在一起則可以創(chuàng)造一個(gè)促進(jìn)突發(fā)結(jié)果的環(huán)境,

10.1.4敏捷流程架構(gòu)

流程也許不如人那么重要，但絕非不重要。

像其他事物一樣，流程必多頁與企業(yè)目標(biāo)聯(lián)系起來。如果企業(yè)目標(biāo)是重復(fù)性的制造，那么常規(guī)性

流程是完全適當(dāng)?shù)?而如果企業(yè)目標(biāo)是可靠的創(chuàng)新，則流程架構(gòu)必須是有機(jī)的、靈活的和容易

改變的。

敏捷流程架構(gòu)需要體現(xiàn)其核心原則，除了支持企業(yè)目標(biāo)外，該架構(gòu)還需要：

(1)支持構(gòu)想、探索、適應(yīng)文化；

(2)支持自我組織、自律的團(tuán)隊(duì)；

(3)根據(jù)項(xiàng)目的不確定性程度，盡量提高可靠性和連貫性；

(4)保持靈活和易于變化；

(5)支持流程的透明化；

(6)與學(xué)習(xí)結(jié)合起來；

(7)將支持各個(gè)階段的做法包括在內(nèi)；

(8)提供管理檢查點(diǎn)(Checkpoint)、對該構(gòu)架進(jìn)行評(píng)估,

10.1.4敏捷流程架構(gòu)

該架構(gòu)中各階段的命名與傳統(tǒng)的階段命名(如開始、計(jì)劃、定義、設(shè)計(jì)、構(gòu)建、測試)完全不

同，其意義重大。

第一，“構(gòu)想”代替較傳統(tǒng)的“開始”，指出構(gòu)想的重要性。

第二，推測階段代替計(jì)劃階段。每個(gè)詞都傳達(dá)一定的意義而各個(gè)意義來自他們長期的系統(tǒng)用

法。"計(jì)劃”一詞已經(jīng)與預(yù)測和相對確定性相關(guān)聯(lián)，而“推測”表示未來是不確定的。許多面臨

不確定未來的項(xiàng)目經(jīng)理仍在試圖“計(jì)劃”排除該不確定性，我們必須學(xué)會(huì)推測和適應(yīng)，而不是

計(jì)劃和建造。

第三，敏捷項(xiàng)目管理模式用探索代替通常的設(shè)計(jì)、構(gòu)建和測試階段。以迭代交付的方式，很明

顯探索是非線性的、并存的、非瀑布式的模式。在推測階段提出的問題需要“探索

鑒于結(jié)果不能完全預(yù)測，推測暗示著靈活性的需求基于現(xiàn)實(shí)。

敏捷項(xiàng)目管理模式強(qiáng)調(diào)執(zhí)行以及探索性而非確定性。

實(shí)施敏捷項(xiàng)目管理的團(tuán)隊(duì)密切關(guān)注構(gòu)想、監(jiān)控信息，從而適應(yīng)當(dāng)前情況，這就是適應(yīng)階段。最

后，敏捷項(xiàng)目管理模式以結(jié)束階段收尾，這個(gè)階段的主要目標(biāo)是傳遞知識(shí)。

敏捷項(xiàng)目管理流程

敏捷項(xiàng)目管理模式的結(jié)構(gòu)：構(gòu)想一推測一探索一適應(yīng)一結(jié)束

1.構(gòu)想

構(gòu)想，需要確定產(chǎn)品構(gòu)想、項(xiàng)目范圍、項(xiàng)目社團(tuán)以及團(tuán)隊(duì)共同工作的方式。

構(gòu)想階段為客戶和項(xiàng)目團(tuán)隊(duì)創(chuàng)造構(gòu)想，該構(gòu)想包括提供什么、誰提供和如何提供。

如果沒有構(gòu)想，其他的項(xiàng)目啟動(dòng)活動(dòng)都是無用之功。

用商業(yè)話語來說，構(gòu)想是項(xiàng)目早期“成功的關(guān)鍵因素”。

首先，我們需要構(gòu)想提供什么，即產(chǎn)品及項(xiàng)目范圍構(gòu)想。

其次，我們需要構(gòu)想?yún)⑴c的人是誰，客戶、產(chǎn)品經(jīng)理、項(xiàng)目團(tuán)隊(duì)成員和利益相關(guān)方組成的社團(tuán)。

最后，項(xiàng)目團(tuán)隊(duì)成員必須構(gòu)想他們打算如何共同工作。

2.推測

推測，需要制定基于功能的發(fā)布計(jì)劃、里程碑和迭代計(jì)劃，確保交付構(gòu)想的產(chǎn)品。

“推測”一詞首先讓人們想到不計(jì)后果的冒險(xiǎn)景象，但實(shí)際上字典對它的定義是“根據(jù)不完全

的事實(shí)或者信息猜測某事二這正是這個(gè)階段要做的事情。

“計(jì)劃”一詞具有確定和預(yù)測的含義，而計(jì)劃的更有用的定義，至少對于探索性項(xiàng)目來說，是

基于不完全的信息推測或者猜測。

人們認(rèn)為制定計(jì)劃可以產(chǎn)生確定性，但事實(shí)遠(yuǎn)非如此。

他們帶來的只不過是衡量他們績效的東西，而一旦這個(gè)衡量尺度與現(xiàn)實(shí)出現(xiàn)偏差，他們又不能

重新計(jì)劃。

2.推測

敏捷項(xiàng)目管理更多的是構(gòu)想、探索，而不是計(jì)劃、執(zhí)行，它迫使我們面對這樣的現(xiàn)實(shí)：

不穩(wěn)定的商業(yè)環(huán)境和變化多端的產(chǎn)品開發(fā)環(huán)境。

推測階段實(shí)際上是構(gòu)想階段的延伸并與它相互影響，它包括：

(1)收集初始的、廣泛的產(chǎn)品要求。

(2)將工作量定義為一個(gè)產(chǎn)品功能清單。

(3)制訂一個(gè)交付計(jì)劃(發(fā)布、里程碑、迭代)，包括那些功能的進(jìn)度表和資源分配。

(4)在估計(jì)項(xiàng)目成本這個(gè)計(jì)劃中加入風(fēng)險(xiǎn)降低策略，并生成其他必要的行政管理和財(cái)務(wù)信息。

3.探索

探索，需要在短期內(nèi)提供經(jīng)測試的功能，不斷致力于減少項(xiàng)目風(fēng)險(xiǎn)和不確定性。

探索階段提供產(chǎn)品功能。從項(xiàng)目管理的角度看，此階段有三個(gè)關(guān)鍵的活動(dòng)區(qū)域。

第一，是通過管理工作量和使用適當(dāng)?shù)募夹g(shù)方法和風(fēng)險(xiǎn)降低策略，交付計(jì)劃的功能。

第二，是建立協(xié)作的、自我組織的項(xiàng)目社團(tuán)，這是每個(gè)人的責(zé)任但需要由項(xiàng)目經(jīng)理推動(dòng)。

第三，是管理團(tuán)隊(duì)與客戶、產(chǎn)品經(jīng)理和其他利益相關(guān)方的相互交流。

敏捷項(xiàng)目管理的構(gòu)想和探索周期

探索，需要在短期內(nèi)提供經(jīng)測試的功能，不斷致力于減少項(xiàng)目風(fēng)險(xiǎn)和不確定性。

4.適應(yīng)

適應(yīng)，需要審核提交的結(jié)果、當(dāng)前情況以及團(tuán)隊(duì)的績效，必要時(shí)做出調(diào)整。

適應(yīng)意味著修改或改變而不是成功或失敗。如果項(xiàng)目的指導(dǎo)哲學(xué)認(rèn)為，適應(yīng)變化比執(zhí)行計(jì)劃更

重要，則將失敗歸罪于計(jì)劃的變更是不會(huì)有任何結(jié)果的。

非常特別的流程并不能從錯(cuò)誤中吸取教訓(xùn)，而吸取教訓(xùn)是敏捷項(xiàng)目管理的關(guān)鍵。

自構(gòu)想階段以后，其循環(huán)通常是“推測-探索-適應(yīng)"，每次迭代都不斷對產(chǎn)品進(jìn)行提煉。

但要是團(tuán)隊(duì)收集到新的信息，定期地回到構(gòu)想階段也很有必要。

在適應(yīng)階段，需要從客戶、技術(shù)、人員和流程績效、以及項(xiàng)目狀況等方面對結(jié)果進(jìn)行評(píng)估。

該分析將會(huì)對比實(shí)際結(jié)果和計(jì)劃的結(jié)果，但更重要的是，要根據(jù)項(xiàng)目得到的最新信息，思考實(shí)

際的與修訂后的項(xiàng)目前景。

修改后的結(jié)果將返回、融入到重新計(jì)劃工作中，開始新的迭代。

5.結(jié)束

結(jié)束，表明終止項(xiàng)目、交流主要的學(xué)習(xí)成果并慶祝。

在某種程度上，項(xiàng)目根據(jù)開始和結(jié)束來界定。

許多組織由于沒有明確項(xiàng)目的終結(jié)點(diǎn)，通常在客戶之間會(huì)造成理解問題。項(xiàng)目應(yīng)該以慶祝方式

結(jié)束。

結(jié)束階段以及每次迭代末尾的“小型"結(jié)束的主要目標(biāo)，是學(xué)習(xí)并將學(xué)到的東西融入到下一次

迭代工作中，或者傳遞給下一個(gè)項(xiàng)目團(tuán)隊(duì)。

5.結(jié)束

在敏捷項(xiàng)目管理的每個(gè)階段中，都有與敏捷價(jià)值觀和指導(dǎo)原則相一致的具體做法。

這些做法，應(yīng)該看作是一個(gè)“做法系統(tǒng)”，因?yàn)樗鼈冏鳛橐粋€(gè)系統(tǒng)相互補(bǔ)充，與價(jià)值觀和原則保

持一致。

但它們并不局限于保持一致，它們還著眼于實(shí)施。

沒有做法的原則只是個(gè)空殼，而沒有原則的做法，往往會(huì)毫無判斷地被生搬硬套。

沒有原則，我們就不知道如何實(shí)施做法，比如說，沒有簡單原則，我們往往會(huì)過多地看重做法

的形式和儀式。

原則指導(dǎo)做法，做法用實(shí)際例子證明原則，它們是相輔相成的。

5.結(jié)束

在選擇和使用這些做法時(shí)，采用了如下指導(dǎo)原則：

(1)簡單的；

(2)再生的而非常規(guī)性的；

(3)與敏捷價(jià)值觀和原則一致的；

(4)集中于交付活動(dòng)(增值)而非合規(guī)活動(dòng)；

(5)最少數(shù)量(剛剛可以完成工作)的；

(6)相互支持的(做法系統(tǒng))。

10.2管理的角色與職責(zé)

10.2.1角色

在敏捷項(xiàng)目管理中主要的角色：

項(xiàng)目經(jīng)理、主任業(yè)務(wù)分析師、項(xiàng)目團(tuán)隊(duì)和產(chǎn)品所有者。

1.項(xiàng)目經(jīng)理

在敏捷世界中把項(xiàng)目經(jīng)理描述成項(xiàng)目領(lǐng)導(dǎo)者

2.業(yè)務(wù)分析師

業(yè)務(wù)分析師是產(chǎn)品管理、營銷、會(huì)計(jì)等的一部分或需要向這些機(jī)構(gòu)報(bào)告，而項(xiàng)目團(tuán)隊(duì)需要向首

席信息官(ChiefInformaticnOfficer,CIO)或者首席技術(shù)官(ChiefTechnologyOfficer.CTO)

報(bào)告。

10.2管理的角色與職責(zé)

3.產(chǎn)品所有者

從項(xiàng)目投資組合的角度看，這個(gè)角色是主要的派遣人，如果當(dāng)前的沖刺中有與功能有關(guān)的問題

出現(xiàn)時(shí)，他也是整個(gè)項(xiàng)目團(tuán)隊(duì)的聯(lián)系點(diǎn)。

4.項(xiàng)目03隊(duì)

項(xiàng)目團(tuán)隊(duì)成員從他們的日?；顒?dòng)繼承了項(xiàng)目的衡量標(biāo)準(zhǔn)，他們會(huì)在團(tuán)隊(duì)、產(chǎn)品所有者和其他項(xiàng)

目利益相關(guān)者中傳播這種衡量標(biāo)準(zhǔn)。

10.2.2職責(zé)

10.2.2職責(zé)

(1)清除障礙

在敏捷項(xiàng)目管理中有兩種機(jī)制來處理這些障礙。

第一個(gè)，是每曰例會(huì)，在這里人們將問題表達(dá)出來并且尋求解決的方案。

第二個(gè)，是項(xiàng)目經(jīng)理的角色，他負(fù)責(zé)處理那些阻礙團(tuán)隊(duì)進(jìn)展的問題。

10.2.2職賁

(2)制定迭代計(jì)劃

迭代的時(shí)間通常為2~6周，越短越好，尤其是在項(xiàng)目的早期階段。

10.2.2職責(zé)

(3)回顧

回顧并不是學(xué)習(xí)教訓(xùn)。

傳統(tǒng)的“學(xué)習(xí)-教訓(xùn)|-總結(jié)"安排在項(xiàng)目的末尾進(jìn)行。

敏捷項(xiàng)目在迭代與迭代之間執(zhí)行回顧。

(4)評(píng)估

敏捷項(xiàng)目中，只有開發(fā)團(tuán)隊(duì)才能估算結(jié)果。敏捷項(xiàng)目經(jīng)理要獲取并跟蹤估算的結(jié)果。

采用哪種估算的方法，選擇哪種評(píng)估技巧要以易用以及能快速采用為準(zhǔn)。

10.2.2職責(zé)

⑸報(bào)告

在敏捷項(xiàng)目中，報(bào)告的力量極為強(qiáng)大，因?yàn)閳F(tuán)隊(duì)可以分享內(nèi)部和外部所完成的需求，項(xiàng)目的進(jìn)

展以及系統(tǒng)的質(zhì)量。

(6)每日例會(huì)

主持會(huì)議包括確保團(tuán)隊(duì)成員以同事的方式互相報(bào)告狀態(tài)，在會(huì)議上提出可能阻礙問題需進(jìn)行記

錄，列入項(xiàng)目經(jīng)理需要做的工作列表中。

10.2.2職責(zé)

(7)領(lǐng)導(dǎo)

在迭代中，需要發(fā)揮領(lǐng)導(dǎo)技能讓團(tuán)隊(duì)前進(jìn)。

團(tuán)隊(duì)中典型的問題都是這樣的，瑣碎的或者非常具有挑戰(zhàn)的未被解決的瑕疵、沒有開發(fā)人員主

動(dòng)去解決生成的崩潰問題、開發(fā)人員結(jié)對的時(shí)間太長而需要其他人員更多地融合以及需要對需

求進(jìn)行協(xié)商等。

敏捷項(xiàng)目經(jīng)理提醒團(tuán)隊(duì)成員吧工作做好、隨時(shí)了解關(guān)鍵條目的最新狀態(tài)并且記錄已完成的事項(xiàng)。

10.3敏捷項(xiàng)目管理的特征

10.3.1敏捷方法的特點(diǎn)

敏捷型方法主要有兩個(gè)特點(diǎn)

10.3敏捷項(xiàng)目管理的特征

1.適應(yīng)性和預(yù)設(shè)性

軟件過程不可能照搬其它工程領(lǐng)域原有的方法，需要有適應(yīng)其特點(diǎn)的新的開發(fā)方法。

10.3敏捷項(xiàng)目管理的特征

2.面向人而非面向過程

敏捷方法特別強(qiáng)調(diào)開發(fā)中相關(guān)人員之間的信息交流。

項(xiàng)目失敗的原囚最終都可以追溯到信息沒有及時(shí)準(zhǔn)確地傳究到應(yīng)該接受它的人。

在開發(fā)過程中，項(xiàng)目的需求是在不斷變化的，管理人員之司、開發(fā)人員之間以及管理人員和開

發(fā)人員之間，都必須不斷地了解這些變化，對這些變化做出反應(yīng)，并實(shí)施在隨后的開發(fā)過程中。

3.方法的敏捷，而不僅是軟件的敏捷

當(dāng)前，軟件開發(fā)敏捷度的推進(jìn)，反映了對軟件工藝化的認(rèn)同。

面對不可避免的變化的需求時(shí)，敏捷軟件開發(fā)的目的，是為了提升軟件的靈活性、適應(yīng)性。

這是通過推行“小增量”產(chǎn)發(fā)來生產(chǎn)軟件，在快速迭代過程中獲得反饋，并根據(jù)需要對軟件不

斷調(diào)整來實(shí)現(xiàn)的。

敏捷軟件開發(fā)團(tuán)隊(duì)，有自己的工作方式，根據(jù)手上的項(xiàng)目選擇他們需要的方法來開發(fā)軟件，并

根據(jù)項(xiàng)目實(shí)際情況調(diào)整開發(fā)過程。

實(shí)際上，軟件開發(fā)過程中，敏捷開發(fā)團(tuán)隊(duì)需要像他們開發(fā)軟件那樣敏捷地改進(jìn)其方法。

10.3.2敏捷方法的核心思想

1.核心思想

敏捷軟件開發(fā)(AgileSoftwareDevelopment)是一組強(qiáng)調(diào)在不確定和混亂的情況下適應(yīng)軟件需

求快速變化的、基于迭代式開發(fā)的軟件開發(fā)方法、實(shí)踐。

當(dāng)前，敏捷方法是一種主流軟件開發(fā)方法，廣泛應(yīng)用于各種軟件開發(fā)中，也包括很多規(guī)模較大

的軟件開發(fā)中。

敏捷軟件開發(fā)主要由有經(jīng)驗(yàn)的軟件工程師和咨詢師提出，而非來自于學(xué)術(shù)界的研究成果。

在2001年“雪鳥會(huì)議”期間，與會(huì)者形成了一些關(guān)于軟件開發(fā)的共同觀點(diǎn)，即敏捷宣言“個(gè)體

和互動(dòng)勝過流程和工具，可以工作的軟件勝過詳盡的文檔客戶合作勝過合同談判，響應(yīng)變化

勝過遵循計(jì)劃”。

該宣言定義了，敏捷軟件下發(fā)的核心價(jià)值觀和原則，而這些原則具體是由敏捷實(shí)踐、敏捷實(shí)踐

的組合，即敏捷方法來實(shí)現(xiàn)的。

1.核心思想

敏捷方法的核心思想，主要有下面三點(diǎn)：

(1)敏捷方法是適應(yīng)型，而非可預(yù)測型。與傳統(tǒng)方法不同，敏捷方法擁抱變化，也可以說它的

初衷就是適應(yīng)變化的需求，利用變化來發(fā)展，甚至改變自己，最后完善自己。

(2)敏捷方法是以人為本而非以過程為本。傳統(tǒng)方法以過程為本，強(qiáng)調(diào)充分發(fā)揮人的特性，

不去限制它。

并且軟件開發(fā)在無過程控制和過于嚴(yán)格繁瑣的過程控制中取得一種平衡，以保證軟件的質(zhì)量。

(3)迭代增量式的開發(fā)過程。敏捷方法以原型開發(fā)思想為基礎(chǔ)，采用迭代增量式開發(fā)，發(fā)行版

本小型化。

它根據(jù)客戶需求的優(yōu)先級(jí)和開發(fā)風(fēng)險(xiǎn)，制定版本發(fā)行計(jì)劃每一發(fā)行版都是在前一成功發(fā)行版

的基礎(chǔ)上進(jìn)行功能需求擴(kuò)充，最后滿足客戶的所有功能需求。

2.基本特征

我們把軟件開發(fā)過程中擁有大量中間產(chǎn)品(如需求規(guī)約、設(shè)計(jì)模型等)和復(fù)雜控制的軟件開發(fā)

方法稱為重型方法。

由此，我們稱中間產(chǎn)品較少的方法為輕型方法。

從表象來看,重型方法注重開發(fā)文檔的完備性和充分性；而敏捷型方法認(rèn)為最根本的文檔應(yīng)該

是源碼，而不是繁瑣的文檔。

從實(shí)質(zhì)上說，有如下兩方面更深層次的區(qū)別，

(1)敏捷型方法的思想是“自適應(yīng)”的，而非如“預(yù)設(shè)”的重型方法試圖預(yù)先固定需求并擬定

詳細(xì)開發(fā)計(jì)劃。

敏捷型方法適應(yīng)需求的變化，甚至可以說其初衷就是針對變化的需求的。

(2)敏捷型方法的思考角度是“面向人”的，而非“面向開發(fā)過程”的。

重型方法在實(shí)踐原則中總是把開發(fā)者看作是一個(gè)泛化的生產(chǎn)要素.而忽視了作為決定性因素的

人的特殊性；而敏捷型方法則強(qiáng)調(diào)以人為本，并貫穿實(shí)踐哈終。

由上可知敏捷型方法其實(shí)是軟件開發(fā)方法論從無到重型再進(jìn)一步發(fā)展的成果。

3.適用范圍

實(shí)際上，滿足工程設(shè)計(jì)標(biāo)準(zhǔn)的唯一文檔是源代碼清單。軟「牛項(xiàng)目的設(shè)計(jì)，是一個(gè)抽象的概念。

它涉及了程序的概括形狀、結(jié)構(gòu)以及每一模塊、類和方法的詳細(xì)形狀。系統(tǒng)設(shè)計(jì)得到了有關(guān)系

的一個(gè)清晰的“圖像”，這一圖像可以保持到首次發(fā)布。

但隨著項(xiàng)目的開發(fā)，程序“片段”就可能像不斷腐化的“面包碎片二發(fā)出“臭味”，并不斷蔓

延和積累，使得系統(tǒng)越來越難以維護(hù)，以至于不得不要求重新設(shè)計(jì)。但這樣的重新設(shè)計(jì)，是很

難成功的。

因此，與這種傳統(tǒng)的方法相比，敏捷方法比較適合需求變化比較大或者開發(fā)前期對需求不是很

清晰的項(xiàng)目，以它的靈活性來適應(yīng)需求的變化，有效地控制項(xiàng)目進(jìn)度和成本。

另外，敏捷方法對設(shè)計(jì)者、開發(fā)者和客戶之間的有效溝通和及時(shí)反饋要求比較高，所以不易在

開發(fā)團(tuán)隊(duì)比較龐大的項(xiàng)目中實(shí)施，當(dāng)然這也不是絕對的。

10.3敏捷項(xiàng)目管理的特征

10.3.3敏捷型方法的含義及其特征

(1)敏捷型方法的思想是“自適應(yīng)”的，而非如“預(yù)設(shè)”的重型方法試圖預(yù)先固定需求并擬定

詳細(xì)開發(fā)計(jì)劃

(2)敏捷型方法的思考角度是“面向人”的，而非“面向開發(fā)過程”的

10.3.3敏捷項(xiàng)目管理方式

提供產(chǎn)品價(jià)值，即在目標(biāo)時(shí)間范圍內(nèi)生產(chǎn)的產(chǎn)品功能，是敏捷項(xiàng)目管理的基礎(chǔ)，并且客戶是其

流程的推動(dòng)力。

為了在提供該價(jià)值方面有效而又及時(shí)地創(chuàng)新，敏捷團(tuán)隊(duì)采用了迭代、基于功能的交付。

最后，為了確保該價(jià)值在現(xiàn)在以及未來的提供，產(chǎn)品可以在開發(fā)期間和第一次使用后都能夠適

應(yīng)客戶不斷變化的需要，項(xiàng)目經(jīng)理和團(tuán)隊(duì)需要?jiǎng)?chuàng)造環(huán)境，將卓越技術(shù)看作是一個(gè)關(guān)鍵的優(yōu)先考

慮事項(xiàng)。

1.鼓勵(lì)探索

探索是困難的，它會(huì)引發(fā)焦慮、顫抖，甚至有時(shí)是恐懼。

敏捷項(xiàng)目管理需要鼓勵(lì)和激發(fā)團(tuán)隊(duì)成員渡過這些高度變化環(huán)境造成的困難。這種鼓勵(lì)包括保持

自我鎮(zhèn)靜、鼓勵(lì)試驗(yàn)、借鑒成功和錯(cuò)誤，以及幫助團(tuán)隊(duì)成員理解產(chǎn)品構(gòu)想。

鼓勵(lì)型領(lǐng)導(dǎo)者，知道好目標(biāo)和壞目標(biāo)之間的區(qū)別。領(lǐng)導(dǎo)者幫助弄清目標(biāo)，團(tuán)隊(duì)透徹了解這些目

標(biāo)并以此鼓勵(lì)自己。

演示、原型、模擬和模型是相互交流的催化劑，它們組成了“共享空間二其中開發(fā)者、市場人

員、客戶和經(jīng)理可以做有意義的相互交流。

共享空間有兩個(gè)要求一直觀化和公共性。公共性意味著原型需要得到開發(fā)工作的所有相關(guān)方

的理解。

2.建立團(tuán)隊(duì)

建立自我組織的框架必須要：

(1)找到適當(dāng)?shù)娜?/p>

流程可以為人們的高效工作提供共同框架，但它不能代替能力和技能；產(chǎn)品是由能干、技術(shù)熟

練的個(gè)人制造的，而不是由流程制造的。

(2)清楚表述產(chǎn)品構(gòu)想、界限和團(tuán)隊(duì)角色。

(3)鼓勵(lì)團(tuán)隊(duì)之間的相互交流和信息流動(dòng)

健康團(tuán)隊(duì)關(guān)系的核心是信任和尊重。項(xiàng)目經(jīng)理需要將精力放在相互交流、協(xié)作上，需要先協(xié)調(diào)，

然后再準(zhǔn)備適當(dāng)?shù)奈臋n，因?yàn)槲臋n會(huì)妨礙交流。

(4)促進(jìn)參與式?jīng)Q策

決策是協(xié)作的心臟和靈魂。團(tuán)隊(duì)如何作出決策確定了團(tuán)隊(duì)是否真正協(xié)作。選擇雙贏思維模式，

用重新構(gòu)思代替妥協(xié)。重新構(gòu)思意味著將多種想法合并起來，創(chuàng)造一種比任何一個(gè)單獨(dú)想法更

好的東西。

(5)堅(jiān)持負(fù)責(zé)

責(zé)任和負(fù)責(zé)創(chuàng)造了高效的自我組織團(tuán)隊(duì)。如圖10-16所示，信任是協(xié)作的基石，而履行承諾是

建立信任的核心。

(6)引導(dǎo)而不是控制

那些想建立適應(yīng)能力強(qiáng)的、自我組織的項(xiàng)目團(tuán)隊(duì)的經(jīng)理應(yīng)該引導(dǎo)而不是控制，他們影響、輕推、

促進(jìn)、勸告，以及在某些情況下指導(dǎo)，他們將自己看作是教練。

2.建立團(tuán)隊(duì)

同時(shí)，自律是自由、授權(quán)的前提。

(1)自律的個(gè)人可以對結(jié)果負(fù)責(zé)。

(2)用嚴(yán)謹(jǐn)?shù)乃季S對抗現(xiàn)實(shí)。

(3)參與激烈的交流和爭論。

(4)愿意在自我組織框架為工作。

(5)尊重同事。

3簡化流程

如果你想X速而又敏捷，那么，就要使事情保持簡單。

速度不是簡化的結(jié)果，但簡化能提高速度。

當(dāng)你去掉詳細(xì)的任務(wù)和工作、簡化流程時(shí)，你就強(qiáng)迫人們思考和交流，因?yàn)闊o論是他們或他們

的經(jīng)理都不能用結(jié)構(gòu)作為一個(gè)拐杖。

(1)再生規(guī)則：簡單規(guī)則是復(fù)雜性理論“群集智能”的一面。其想法是正確的一套簡單規(guī)則,

一旦應(yīng)用到一群充分交流的個(gè)人之中，會(huì)產(chǎn)生諸如創(chuàng)新和創(chuàng)造力之類的復(fù)雜性為。

一套正確的規(guī)則應(yīng)該是為創(chuàng)新和生產(chǎn)設(shè)立界限最少的一組規(guī)則，它們制定簡單的、但產(chǎn)生復(fù)雜

行為的規(guī)則組，營造創(chuàng)新環(huán)境。

(2)剛剛足夠的方法論：在決定流程、方法、做法、文檔以及產(chǎn)品開發(fā)的其他方面時(shí)，簡化的

警告將我們引向剛剛足夠、引向精簡、引向?qū)嵤氨葎倓倝蛏僖稽c(diǎn)”。必須快速適應(yīng)，但永遠(yuǎn)

不要失去控制。

10.4主要敏捷方法

手工作坊式的軟件生產(chǎn)方式，已經(jīng)被無數(shù)次的項(xiàng)目失敗證明為低效和應(yīng)被舍棄的。

傳統(tǒng)軟件開發(fā)方法(如ISO9000和CMM)在規(guī)范和保證開發(fā)進(jìn)程的同時(shí)，由于其繁瑣的過程

控制和嚴(yán)格的文檔要求招致了開發(fā)者潛在的抵觸。

此外，開發(fā)人員流動(dòng)性大于軟件的可持續(xù)開發(fā)之間的矛盾日漸顯露，如何保證軟件的高可傳承

性以及盡可能地延長軟件生命周期，成了擺在開發(fā)者和管理者面前的難題。

為了應(yīng)對這種局面，近年來，已經(jīng)出現(xiàn)很多敏捷型方法，它們有許多的共同特征，但也有一些

重要的不同之處。

這里，就其中影響比較大的幾種敏捷方法作做一些簡單的介紹。

10.4.1XP極限編程

極限編程(ExtremeProgramming,XP)是一種輕量級(jí)的軟件開發(fā)方法，它使用快速的反饋，大

量而迅速的交流，經(jīng)過保證的測試來最大限度的滿足用戶的需求。

10.4.1XP極限編程

10.4.1XP極限編程

10.4.1XP極限編程

XP流程

XP強(qiáng)調(diào)4個(gè)因素。

交流(Communication):

XP要求程序員之間以及和用戶之間有大量而迅速的交流。

簡單(Simplicity):

XP要求設(shè)計(jì)和實(shí)現(xiàn)簡單和干凈。

反饋(Feedback)：

通過測試得到反饋，盡快提交軟件并根據(jù)反饋修改。

勇氣(Courage)：

勇敢的面對需求和技術(shù)上的變化。

10.4.2Scrum工具

Scrum中有三種角色：

產(chǎn)品經(jīng)理(ProductOwner),

ScrumMaster(相當(dāng)于項(xiàng)目經(jīng)理)

團(tuán)隊(duì)(Team)

scrum:兼顧計(jì)劃與靈活的敏捷開發(fā)

scrum:兼顧計(jì)劃與靈活的敏捷開發(fā)

10.4.2Scrum工具

10.4.2Scrum工具

另外Scrum的三大特點(diǎn)，和傳統(tǒng)瀑布式的項(xiàng)目管理的最大區(qū)別如下。

(1)"可能性的”藝術(shù)：強(qiáng)調(diào)想事情的時(shí)候不應(yīng)該把注意力集中在"不能做的事情”上，而是

關(guān)注當(dāng)下“什么事情可以做或者可能做"，不要被諸多的不確定性因素所困擾，先做可以做的，

然后看有什么新的發(fā)現(xiàn)，有什么新的思維出現(xiàn)。

(2)團(tuán)隊(duì)自組織，自管理：強(qiáng)調(diào)"放權(quán)"，讓團(tuán)隊(duì)自己尋找解決問題的最佳方案?？梢约ぐl(fā)團(tuán)

隊(duì)創(chuàng)造力，增強(qiáng)團(tuán)隊(duì)責(zé)任感，顯著提高生產(chǎn)力。

(3)面對面溝通：強(qiáng)調(diào)面對面的溝通，以有效減少溝通障礙。

10.4.2Scrum工具

敏捷方法之極限編程(XP)和Scrum區(qū)別

(1)迭代長度的不同。

XP的一個(gè)Sprint的迭代長度大致為1-2周，而Scrum的迭代長度一般為2-4周。

(2)在迭代中，是否允許修改需求。XP在一個(gè)迭代中，如果一個(gè)UserStory(用戶素材，也就

是一個(gè)需求)還沒有實(shí)現(xiàn)，則可以考慮用另外的需求將其替換，替換的原則是需求實(shí)現(xiàn)的時(shí)間

量是相等的。

而Scrum是不允許這樣做的，一旦迭代開工會(huì)完畢，任何需求都不允許添加進(jìn)來，并有Scrum

Master嚴(yán)格把關(guān)，不允許開發(fā)團(tuán)隊(duì)受到干擾。

(3)在迭代中，UserStory是否嚴(yán)格按照優(yōu)先級(jí)別來實(shí)現(xiàn)。

XP是務(wù)必要遵守優(yōu)先級(jí)別的。但Scrum在這點(diǎn)做得很靈活，可以不按照優(yōu)先級(jí)別來做，Scrum

這樣處理的理由是：如果優(yōu)先問題的解決者，由于其它事情耽擱，不能認(rèn)領(lǐng)任務(wù)，那么整個(gè)進(jìn)

度就耽誤了。另外一個(gè)原因是.如果按優(yōu)先級(jí)排序的UserStory#6和#10,雖然#6優(yōu)先級(jí)高，

但是如果#6的實(shí)現(xiàn)要依賴于#10,則不得不優(yōu)先做#10。

(4)軟件的實(shí)施過程中，是否采用嚴(yán)格的工程方法，保證進(jìn)度或者質(zhì)量。

Scrum沒有對軟件的整個(gè)實(shí)施過程開出工程實(shí)踐的處方。要求開發(fā)者自覺保證，但XP對整個(gè)流

程方法定義非常嚴(yán)格，規(guī)定需要采用TDD,自動(dòng)測試，結(jié)對編程，簡單設(shè)計(jì)，重構(gòu)等約束團(tuán)隊(duì)

的行為。

敏捷方法之極限編程(XP)和Scrum區(qū)別

10.4.3Cockbum的水晶系列方法

水晶系列方法與XP方法一樣，都有以人為中心的理念，但在實(shí)踐上有所不同。

Alistair考慮到人們一般很難嚴(yán)格遵循一個(gè)紀(jì)律約束很強(qiáng)的過程，因此，與XP的高度嚴(yán)格紀(jì)

律性不同，Alistair探索了用最少紀(jì)律約束而仍能成功的方法，從而在產(chǎn)出效率與易于運(yùn)作上達(dá)

到一種平衡。也就是說，雖然水晶系列不如XP那樣的產(chǎn)出效率，但會(huì)有更多的人能夠接受并遵

循它。

Crystal系列開發(fā)方法，分為CrystalClear,CrystalYellow,CrystalOrange和CrystalRed分別適

用于不同的項(xiàng)目。項(xiàng)目可以按照參加的人員和重要性劃分。

CrystalClear的七大特征

10.4.4開放式源碼

這里提到的開放式源碼，指的是開放源碼界所用的一種運(yùn)咋方式。

開放式源碼項(xiàng)目有一個(gè)特另J之處，就是程序開發(fā)人員在地域上分布很廣，這使得它和其它他敏

捷方法不同，因?yàn)橐话愕拿艚莘椒ǘ紡?qiáng)調(diào)項(xiàng)目組成員在同一地點(diǎn)工作

o開放源碼的一個(gè)突出特點(diǎn)就是查錯(cuò)排障（Debug）的高度并行性，任何人發(fā)現(xiàn)了錯(cuò)誤都可將

改正源碼的“補(bǔ)丁”文件發(fā)給維護(hù)者。

然后由維護(hù)者將這些“補(bǔ)丁”或是新增的代碼并入源碼庫。

10.4.4開放式源碼

多數(shù)開放源碼項(xiàng)目有一個(gè)或多個(gè)源碼維護(hù)者。只有維護(hù)者才能將新的或修改過的源碼段并入源

碼庫。

其他眾人可以修改源碼，但需將他們所做的改動(dòng)送交給維護(hù)者，由維護(hù)者對這些改動(dòng)進(jìn)行審核

并決定是否并入源碼庫

通常來說，這些改動(dòng)是以“補(bǔ)丁”文件的形式，這樣處理起來容易一些。維護(hù)者負(fù)責(zé)協(xié)調(diào)這些

改動(dòng)并保持設(shè)計(jì)的一致性。

維護(hù)者的角色在不同的項(xiàng)目中有不同的產(chǎn)生和處理方式。

有些項(xiàng)目只有一個(gè)維護(hù)者，有些項(xiàng)目把整個(gè)系統(tǒng)分成若干個(gè)模塊，每個(gè)模塊有一個(gè)維護(hù)者。有

些是輪流做維護(hù)者，有些是同一個(gè)源碼部分有多個(gè)維護(hù)者，有些則是這些方式的組合。

許多開放源碼項(xiàng)目的參與者只是部分時(shí)間（或業(yè)余時(shí)間），如果項(xiàng)目要求是全日制的，那么這

有一個(gè)問題，就是怎樣才能把這些開發(fā)人員有效地協(xié)調(diào)組織起來。

10.4.4開放式源碼

開放源碼的一個(gè)突出特點(diǎn)就是查錯(cuò)排故（Debug）的高度并行性，因?yàn)樵S多人都能同時(shí)參與查

錯(cuò)排故。

如果他們發(fā)現(xiàn)了錯(cuò)誤，他們可將改正源碼的"補(bǔ)丁”文件發(fā)給維護(hù)者。

這種查錯(cuò)排故角色對非維護(hù)者來說合適，對那些設(shè)計(jì)能力不是很強(qiáng)的人來說，也是一項(xiàng)挺好的

工作。

開源軟件是一種源代碼可以任意獲取的計(jì)算機(jī)軟件。

開源軟件開發(fā)方法是伴隨著互聯(lián)網(wǎng)在全球的快速發(fā)展而興起的。

以Linux為例，Linux起步發(fā)展的時(shí)間（1993年-1994年）與互聯(lián)網(wǎng)在全球的快速發(fā)展幾乎是同

步的。

開源軟件開發(fā)方法，依賴于分散在全球的開發(fā)者和使用者的協(xié)作，而只有互聯(lián)網(wǎng)才能為這種大

規(guī)模協(xié)助提供交流溝通的工具。廉價(jià)的互聯(lián)網(wǎng)是Linux模式得以發(fā)展的必要條件。

10.4.4開放式源碼

開源軟件開發(fā)方法還啟發(fā)了一種稱之為眾包（CrowdSourcing）的軟件開發(fā)組織方式。

眾包的方式繼承了開源軟件開發(fā)的大部分實(shí)踐，但與傳統(tǒng)開源軟件開發(fā)方法還存在一些差異。

10.4.4開放式源碼

10.4.5Coad的功用驅(qū)動(dòng)開發(fā)方法

特征驅(qū)動(dòng)開發(fā)(FeatureDrivenDevelopments,FDD)是由JeffDeLuca和PeterCoad提出來

的。

像其它他方法一樣，它致力于短時(shí)的迭代階段和可見可用的功能。在FDD中，一個(gè)迭代周期一

般是兩周。

在FDD中，編程開發(fā)人員分成兩類：首席程序員和"類"程序員(classowner)o

首席程序員是最富有經(jīng)驗(yàn)的開發(fā)人員，他們是項(xiàng)目的協(xié)調(diào)者、設(shè)計(jì)者和指導(dǎo)者，而“類”程序

員則主要做源碼編寫。

FDD流程圖

10.4.5Coad的功用驅(qū)動(dòng)開發(fā)方法

關(guān)于特性驅(qū)動(dòng)開發(fā)需要知道的7件事

10.4.5Coad的功用驅(qū)動(dòng)開發(fā)方法

(1)開發(fā)整體模型

這是FDD開始一個(gè)項(xiàng)目的初始工作,在主設(shè)計(jì)師的指導(dǎo)下，帶領(lǐng)領(lǐng)域?qū)＜液烷_發(fā)小組成員一起

工作。

主要是收集系統(tǒng)的功能需求，然后使用四色原型進(jìn)行域建模。在此階段中，能夠得出系統(tǒng)的架

構(gòu)設(shè)計(jì)圖。

(2)構(gòu)建功能列表

這個(gè)過程確定所有用于支持需求的功能。由領(lǐng)域?qū)＜液烷_發(fā)小組進(jìn)行功能分解。根據(jù)領(lǐng)域?qū)＜?/p>

對領(lǐng)域的劃分，將整個(gè)領(lǐng)域分成一定數(shù)量的區(qū)域(主要功能集)，每個(gè)區(qū)域再細(xì)化為一定數(shù)量的

活動(dòng)。

活動(dòng)中的每一步被劃分稱為一個(gè)功能。形成了具有層次結(jié)構(gòu)的分類功能列表。在此階段中，能

夠形成系統(tǒng)的概要設(shè)計(jì)。

(3)計(jì)劃功能開發(fā)

項(xiàng)目經(jīng)理、開發(fā)經(jīng)理和開發(fā)小組根據(jù)功能的依賴性、開發(fā)小組的工作負(fù)荷以及要實(shí)現(xiàn)的功能的

復(fù)雜性，計(jì)劃實(shí)現(xiàn)功能的順序，完成一個(gè)功能開發(fā)計(jì)劃。

它提供了對項(xiàng)目的高層視圖，讓業(yè)務(wù)代表了解功能開發(fā)、測試和發(fā)布日期，以便業(yè)務(wù)代表和部

署小組能夠計(jì)劃交付哪些功能的日期。本階段的主要成果，是能夠形成項(xiàng)目開發(fā)計(jì)劃。

10.4.5Coad的功用驅(qū)動(dòng)開發(fā)方法

(4)按照功能設(shè)計(jì)

項(xiàng)目經(jīng)理和上一階段指定的各個(gè)功能集的主要程序員一起對功能進(jìn)行詳細(xì)設(shè)計(jì)。

同時(shí)在域模型的基礎(chǔ)上進(jìn)行分析、設(shè)計(jì)，得出分析模型、設(shè)計(jì)模型。由于一次設(shè)計(jì)并不全面，

因此也可以直接進(jìn)入設(shè)計(jì)模型。

根據(jù)設(shè)計(jì)的結(jié)果制定出項(xiàng)目的里程碑。這里會(huì)有一個(gè)設(shè)計(jì)評(píng)審的環(huán)節(jié)。本階段的成果，應(yīng)該包

括詳細(xì)設(shè)計(jì)、項(xiàng)目里程碑計(jì)劃等。

(5)按照功能構(gòu)建

按照設(shè)計(jì)進(jìn)行編碼實(shí)現(xiàn)，由程序員實(shí)現(xiàn)各自負(fù)責(zé)的類。在代碼完成后有必要的組織代碼復(fù)查、

評(píng)審。在測試和檢查通過后檢入到配置管理庫中進(jìn)行構(gòu)建。

第5和第4階段是一個(gè)迭代的過程，迭代周期一般為2個(gè)星期。這樣經(jīng)過不斷的迭代，不斷的

實(shí)現(xiàn)功能集中的功能。

每一個(gè)里程碑的時(shí)候進(jìn)行評(píng)估、回顧。并考慮下一個(gè)里程碑的繼續(xù)，直到最后項(xiàng)目的完成。

10.4.6自適應(yīng)軟件開發(fā)方法

自適應(yīng)軟件開發(fā)(AdaptiveSoftwareDevelopment,ASD)方法由世界知名的敏捷專家、《敏捷

宣言》的創(chuàng)始人吉姆海史密斯(JimHighsmith)提出。其核心是三個(gè)非線性的、重疊的開發(fā)階

段：猜測、合作與學(xué)習(xí)。

吉姆?海史密斯和自適應(yīng)軟件開發(fā)

10.4.7DevOps

DevOps(Development和。perations的組合詞)是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開

發(fā)(應(yīng)用程序/軟件工程)、技術(shù)運(yùn)營和質(zhì)量保障(QA)部門之間的溝通、協(xié)作與整合。

De