要想成為一個(gè)好的項(xiàng)目經(jīng)理，您需要弄清項(xiàng)目經(jīng)理所面臨的問題、機(jī)會(huì)和期望，明白項(xiàng)目團(tuán)隊(duì)將會(huì)有沖突，弄清誰是利益的關(guān)系者，明白判斷項(xiàng)目成功的四個(gè)標(biāo)準(zhǔn)：預(yù)算、進(jìn)度、效績標(biāo)準(zhǔn)和客戶滿意，還要為組建一個(gè)和諧的團(tuán)隊(duì)，充當(dāng)教練、領(lǐng)隊(duì)和沖突仲裁人。不能因?yàn)轫?xiàng)目中的挫折而止步不前，更不能安于現(xiàn)狀。你在整個(gè)項(xiàng)目實(shí)施中，是領(lǐng)導(dǎo)也是小兵。那么，做一個(gè)成功的項(xiàng)目經(jīng)理究竟要做哪些事情，這里作者總結(jié)了軟件項(xiàng)目實(shí)施過程中的一些經(jīng)驗(yàn)，希望與讀者共享。

如何組織開發(fā)團(tuán)隊(duì)

如何構(gòu)建軟件開發(fā)團(tuán)隊(duì)取決于可供選擇的人員、項(xiàng)目的需求以及組織的需求。本文闡述了項(xiàng)目實(shí)施過程中各種團(tuán)隊(duì)組織的策略。

有效的軟件項(xiàng)目團(tuán)隊(duì)由擔(dān)當(dāng)各種角色的人員所組成。每位成員扮演一個(gè)或多個(gè)角色；可能一個(gè)人專門負(fù)責(zé)項(xiàng)目管理，而另一些人則積極地參與系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)。常見的一些項(xiàng)目角色包括：分析師、策劃師、數(shù)據(jù)庫管理員、設(shè)計(jì)師、操作／支持工程師、程序員、項(xiàng)目經(jīng)理、項(xiàng)目贊助者、質(zhì)量保證工程師、需求分析師、主題專家（用戶）、測試人員。

作為一個(gè)項(xiàng)目經(jīng)理人，您是如何組織項(xiàng)目團(tuán)隊(duì)的？是采用垂直方案、水平方案還是混合方案？以垂直方案組織的團(tuán)隊(duì)由多面手組成，每個(gè)成員都充當(dāng)多重角色。以水平方案組織的團(tuán)隊(duì)由專家組成，每個(gè)成員充當(dāng)一到兩個(gè)角色。以混合方案組織的團(tuán)隊(duì)既包括多面手，又包括專家。

一個(gè)重要的考慮因素是可供選擇的人員的性質(zhì)。如果大多數(shù)人員是多面手，則您往往需要采用垂直方案，同樣，如果大多數(shù)人員是專家，則采用水平方案。如果您正引入一些新人，即使這些人員都是合同工，則仍然需要優(yōu)先考慮您的項(xiàng)目和組織。本文描述了形成團(tuán)隊(duì)組織的垂直、水平和混合方案，并指出了它們各自的優(yōu)缺點(diǎn)。本次討論的一個(gè)重要含意是您的團(tuán)隊(duì)組織和用于管理項(xiàng)目的手段之間應(yīng)構(gòu)成默契；任何方法上的失諧都很可能導(dǎo)致項(xiàng)目產(chǎn)生問題。

垂直團(tuán)隊(duì)組織

垂直團(tuán)隊(duì)由多面手組成。用例分配給了個(gè)人或小組，然后由他們從頭至尾地實(shí)現(xiàn)用例。

優(yōu)點(diǎn)

● 以單個(gè)用例為基礎(chǔ)實(shí)現(xiàn)平滑的端到端開發(fā)。
● 開發(fā)人員能夠掌握更廣泛的技能。

缺點(diǎn)

● 多面手通常是一些要價(jià)很高并且很難找到的顧問。 　
● 多面手通常不具備快速解決具體問題所需的特定技術(shù)專長。
● 主題專家可能不得不和若干開發(fā)人員小組一起工作，從而增加了他們的負(fù)擔(dān)。
● 所有多面手水平各不相同。

成功因素

● 每個(gè)成員都按照一套共同的標(biāo)準(zhǔn)與準(zhǔn)則工作。
● 開發(fā)人員之間需要進(jìn)行良好的溝通，以避免公共功能由不同的組來實(shí)現(xiàn)。
● 公共和達(dá)成共識(shí)的體系結(jié)構(gòu)需要盡早在項(xiàng)目中確立。

水平團(tuán)隊(duì)組織

　　水平團(tuán)隊(duì)由專家組成。此類團(tuán)隊(duì)同時(shí)處理多個(gè)用例，每個(gè)成員都從事用例中有關(guān)其自身的方面。

優(yōu)點(diǎn)

● 能高質(zhì)量地完成項(xiàng)目各個(gè)方面（需求、設(shè)計(jì)等）的工作。
● 一些外部小組，如用戶或操作人員，只需要與了解他們確切要求的一小部分專家進(jìn)行交互。

缺點(diǎn)

● 專家們通常無法意識(shí)到其它專業(yè)的重要性，導(dǎo)致項(xiàng)目的各方面之間缺乏聯(lián)系。
● “后端”人員所需的信息可能無法由“前端”人員來收集。
● 由于專家們的優(yōu)先權(quán)、看法和需求互不相同，所以項(xiàng)目管理更為困難。

成功因素

● 團(tuán)隊(duì)成員之間需要有良好的溝通，這樣他們才能彼此了解各自的職責(zé)。
● 需要制定專家們必須遵循的工作流程和質(zhì)量標(biāo)準(zhǔn)，從而提高移交給其他專家的效率。

混合團(tuán)隊(duì)組織

混合團(tuán)隊(duì)由專家和多面手共同組成。多面手繼續(xù)操作一個(gè)用例的整個(gè)開發(fā)過程，支持并處理多個(gè)使用例中各部分的專家們一起工作。

優(yōu)點(diǎn)

● 擁有前兩種方案的優(yōu)點(diǎn)。
● 外部小組只需要與一小部分專家進(jìn)行交互。
● 專家們可集中精力從事他們所擅長的工作。
● 各個(gè)用例的實(shí)現(xiàn)都保持一致。

缺點(diǎn)

● 擁有前兩種方案的缺點(diǎn)。
● 多面手仍然很難找到。
● 專家們?nèi)匀徊荒苷J(rèn)識(shí)到其他專家的工作并且無法很好地協(xié)作，盡管這應(yīng)該由多面手來調(diào)節(jié)。
● 項(xiàng)目管理仍然很困難。

成功因素

● 項(xiàng)目團(tuán)隊(duì)成員需要良好的溝通。
● 需要確定公共體系結(jié)構(gòu)。
● 必須適當(dāng)?shù)囟x公共流程、標(biāo)準(zhǔn)和準(zhǔn)則。

項(xiàng)目團(tuán)隊(duì)士氣是項(xiàng)目成功的一個(gè)因素

大部分項(xiàng)目成功的定義說的是項(xiàng)目如何按時(shí)完成、是否在預(yù)算內(nèi)以及是否滿足用戶的需要。但是，在如今要找到好的軟件專業(yè)人員都非常困難，更不用說留住他們的這種情況下，還需要將項(xiàng)目成功的定義擴(kuò)展為包括項(xiàng)目團(tuán)隊(duì)的士氣?？赡茉谂ν瓿梢粋€(gè)軟件項(xiàng)目后，不料卻因?yàn)閴赫ニ麄冞^度而失去了重要的開發(fā)人員，這樣做可能會(huì)符合組織的短期需要，但它對構(gòu)建一個(gè)高效的軟件部門的長遠(yuǎn)利益來說肯定是有害的。衡量項(xiàng)目成功與否的一個(gè)重要手段是項(xiàng)目結(jié)束后團(tuán)隊(duì)的士氣。在項(xiàng)目結(jié)束之際，項(xiàng)目團(tuán)隊(duì)的各個(gè)成員是否覺得他們從自己的經(jīng)歷中學(xué)到了一些知識(shí)、是否喜歡為這次項(xiàng)目工作，以及是否希望參與組織的下一個(gè)項(xiàng)目都是非常重要的。

項(xiàng)目規(guī)劃技巧

項(xiàng)目計(jì)劃技巧對于現(xiàn)今的軟件開發(fā)人員來說是必需的。這里有一些幫助您有效地計(jì)劃下一個(gè)項(xiàng)目的建議。

認(rèn)識(shí)到信心來自規(guī)劃的過程，而不是計(jì)劃本身。

創(chuàng)建項(xiàng)目計(jì)劃會(huì)迫使您早在編寫代碼之前就考慮如何構(gòu)建您的系統(tǒng)——減少項(xiàng)目的風(fēng)險(xiǎn)，因?yàn)槟呀?jīng)考慮了各種策略和方法并且已經(jīng)選擇了最有意義的一項(xiàng)。您的目的不應(yīng)該只是不花氣力產(chǎn)生一個(gè)計(jì)劃；它應(yīng)該是一個(gè)實(shí)際可行的計(jì)劃，您可以根據(jù)它來成功管理您的項(xiàng)目。

軟件過程推動(dòng)計(jì)劃的開發(fā)

每個(gè)軟件過程都有一個(gè)不同的集合，它包括組織團(tuán)隊(duì)的活動(dòng)方法以及規(guī)劃項(xiàng)目常用的技術(shù)。由于這個(gè)原因，基于 Rational Unified Process (RUP)的項(xiàng)目規(guī)劃不同于OOSP項(xiàng)目的規(guī)劃，而OOSP項(xiàng)目的規(guī)劃也不同于eXtreme Programming (XP) 項(xiàng)目的規(guī)劃。不同的過程有不同的計(jì)劃。

從粗粒度的計(jì)劃開始

在項(xiàng)目將要開始時(shí)，應(yīng)該制定一個(gè)粗粒度的、確定項(xiàng)目高級活動(dòng)和預(yù)期里程碑的計(jì)劃。粗粒度的計(jì)劃將組織成迭代——根據(jù)項(xiàng)目的大小和性質(zhì)，每次迭代通常在三周到八周之間發(fā)生（四周到六周為更佳）。其中一些迭代將集中在項(xiàng)目初期，而很多迭代將集中在整個(gè)應(yīng)用的功能部分開發(fā)，還有一些迭代集中在將您的系統(tǒng)轉(zhuǎn)變成產(chǎn)品。

實(shí)施者應(yīng)該是計(jì)劃人員

創(chuàng)建項(xiàng)目計(jì)劃的最佳人員是負(fù)責(zé)實(shí)施該計(jì)劃的人員。當(dāng)規(guī)劃由一個(gè)人創(chuàng)建而由另一個(gè)人實(shí)施時(shí)，如果項(xiàng)目不能按時(shí)完成或超出預(yù)算，他們不太會(huì)相信計(jì)劃，而很有可能會(huì)責(zé)備它。也就是說，參與項(xiàng)目的每個(gè)人都應(yīng)該投入到項(xiàng)目計(jì)劃的開發(fā)和進(jìn)展中。

不要忘記“不該忘記的事”

計(jì)劃不僅要反映需求設(shè)計(jì)、建模、編程和測試的“真實(shí)”工作，而且還應(yīng)該反映輔助活動(dòng)（然而仍是重要的），它包括：休假和法定假日、培訓(xùn)和教育、項(xiàng)目管理活動(dòng)（如規(guī)劃和人員管理）、開銷（如系統(tǒng)當(dāng)機(jī)時(shí)間、會(huì)議和回復(fù)電子郵件）、體系結(jié)構(gòu)定義、測試之后的系統(tǒng)返工、系統(tǒng)交付、與重用相關(guān)的活動(dòng)（如普遍化 ）。

將任何設(shè)想和約束編入文檔

規(guī)劃時(shí)您總要作一些假設(shè)，如能夠及時(shí)獲得應(yīng)用程序服務(wù)器的新發(fā)行版，或可以得到熟悉您正在應(yīng)用的技術(shù)和技巧的開發(fā)人員。同時(shí)，您將在一些約束下工作，如影響計(jì)劃的強(qiáng)制截止期限或資源限制。將這些假設(shè)和約束編入文檔，這樣，當(dāng)您實(shí)施項(xiàng)目的任何時(shí)候更新計(jì)劃時(shí)，都可以記起您先前做出的一些“不尋?！睕Q定。

認(rèn)識(shí)到不同的資源意味著不同的計(jì)劃

十名有經(jīng)驗(yàn)的開發(fā)人員組成的團(tuán)隊(duì)創(chuàng)造出的成效要遠(yuǎn)遠(yuǎn)多于十名初學(xué)者組成的團(tuán)隊(duì)所創(chuàng)造的成效。要想更加實(shí)際的話，您的計(jì)劃必須反映項(xiàng)目可使用的資源的真實(shí)情況。

創(chuàng)建現(xiàn)實(shí)的計(jì)劃

項(xiàng)目組必須相信其項(xiàng)目的目的、估價(jià)和時(shí)間表。要做到這點(diǎn)，您必須真實(shí)地規(guī)劃，避免規(guī)劃超出您能理解的范圍。僅當(dāng)您打算研究未知事項(xiàng)時(shí)，才能容忍無知。

只規(guī)劃有價(jià)值的事

IBM DeveloperWorks 網(wǎng)站提供了許多可應(yīng)用于您項(xiàng)目的最佳實(shí)踐。然而，根據(jù)項(xiàng)目的性質(zhì)，不是所有這些技術(shù)都將適合于您的獨(dú)特情況。要將這些最佳實(shí)踐簡單地看作是您放置在“項(xiàng)目管理工具箱”中的工具，您可以根據(jù)需要適當(dāng)使用這些工具。

適當(dāng)使用項(xiàng)目管理工具

一些項(xiàng)目管理工具，如 Microsoft Project，提供了重要功能， 如Gantt圖表（活動(dòng)時(shí)間表）的開發(fā)、規(guī)劃與實(shí)際結(jié)果的比較、PERT 圖表（網(wǎng)絡(luò)圖表）的開發(fā)、任務(wù)的定義、任務(wù)之間相關(guān)性的定義、對任務(wù)的資源分配和資源平衡。所有這些事情似乎象是一個(gè)好主意，并且它們通常是好主意——但它們還需要許多精力來創(chuàng)建和維護(hù)，而且很少為項(xiàng)目組提供實(shí)際價(jià)值。的確，它讓一些項(xiàng)目管理人員感到富有成效。的確，高級管理喜歡看見您有一個(gè)計(jì)劃。但是，沒有一行代碼是由所有這個(gè)活動(dòng)產(chǎn)生的。規(guī)劃是有價(jià)值的活動(dòng)；但投入大量的時(shí)間來創(chuàng)建規(guī)劃圖表通常不是有價(jià)值的活動(dòng)。

謹(jǐn)慎應(yīng)用技術(shù)方案處理管理問題

對于在項(xiàng)目中遇到的問題，您確信需要用技術(shù)來解決嗎？本文改編自作者所著的Process Patterns 的第五章，Scott Ambler建議改進(jìn)管理，而不是新技術(shù)，可能就是您的解決方案。

還沒有一種點(diǎn)能表明用部署最新技術(shù)中來解決通過改變管理實(shí)踐去解決問題的（請參閱參考資料中 The Squandered Computer）。事實(shí)上是，您不應(yīng)該將所有商業(yè)過程所得的好處都?xì)w功于支持這些更改的軟件項(xiàng)目。沒有這些新的軟件或硬件，您可能會(huì)得到同樣的好處。

將技術(shù)解決方案識(shí)別成非技術(shù)問題是經(jīng)常重復(fù)發(fā)生在信息技術(shù)界的常見錯(cuò)誤。這種經(jīng)常發(fā)生的錯(cuò)誤將其看成是稱作 Apply Technical Solution to Non-Technical Problem（將技術(shù)解決方案應(yīng)用到非技術(shù)問題）自身的過程反模式（過程反模式是一種已證明在實(shí)際運(yùn)行當(dāng)中并不是行之有效的方法）。

技術(shù)解決方案僅適用于解決技術(shù)問題。例如，“網(wǎng)絡(luò)計(jì)算機(jī)”的概念仍然是計(jì)算機(jī)界中熱衷的時(shí)尚。其基本概念就是通過網(wǎng)絡(luò)計(jì)算機(jī)來替代個(gè)人計(jì)算機(jī)，組織就可以大大縮減支持計(jì)算機(jī)軟硬件的開支。

研究表明，如果包括培訓(xùn)和支持這些計(jì)算機(jī)費(fèi)用的話，那每年支持一臺(tái)個(gè)人計(jì)算機(jī)的平均開支大約在 $5,000 到 $30,000 之間。網(wǎng)絡(luò)計(jì)算機(jī)（也稱之為 Java 終端，因?yàn)樗鼈儍H運(yùn)行已經(jīng)打包成 Java 字節(jié)代碼的程序）理論上將縮減開支，因?yàn)樗鼈儍H需要簡單的維護(hù)和支持。盡管做了大量的廣告宣傳，但迄今為止，網(wǎng)絡(luò)計(jì)算機(jī)的銷售量十分可憐。從表面上看，網(wǎng)絡(luò)計(jì)算機(jī)試圖解決的問題看起來是技術(shù)性的。但當(dāng)您想到這一點(diǎn)的時(shí)候，問題實(shí)際已經(jīng)成為管理問題之一了。

一些組織一年要花費(fèi) $30,000來支持計(jì)算機(jī)的原因不是因?yàn)閭€(gè)人計(jì)算機(jī)，而是由于對個(gè)人計(jì)算機(jī)的誤用。這些組織不是由具有資格的專業(yè)人員來安裝公共配置，而是讓用戶選擇和安裝他們自己的軟件。一旦用戶遇到了麻煩，組織的開支就飛漲。另外還有文件格式不相容的問題。若沒有公共的軟件套件，用戶得浪費(fèi)大量時(shí)間在同一供應(yīng)商所提供的不同軟件版本之間轉(zhuǎn)換文件，或從不同供應(yīng)商所提供的不同軟件之間轉(zhuǎn)換文件?；陬愃频脑?，當(dāng)用戶購買他們自己的設(shè)備時(shí)，硬件培訓(xùn)和支持也變得更加困難。

在這種情況下所發(fā)生的問題是與過程相關(guān)：個(gè)人計(jì)算機(jī)軟硬件的管理不當(dāng)。因而購置網(wǎng)絡(luò)計(jì)算機(jī)這一技術(shù)解決方案是否能夠解決問題值得懷疑。技術(shù)解決方案適用于技術(shù)問題，管理解決方案適應(yīng)于管理問題，而過程解決方案則適用于過程問題。在談完了所有內(nèi)容之后，我真正的意思也許僅僅是在工作中要使用正確的工具。

基于需求的規(guī)劃策略：按優(yōu)先次序排序

成功的項(xiàng)目組認(rèn)識(shí)到不能等同地創(chuàng)建所有的需求，因此，需要對需求進(jìn)行優(yōu)先次序排序并按此順序操作。

某些需求比其它需求重要得多。例如，對于聯(lián)機(jī)銀行的需求來說，對帳戶間資金轉(zhuǎn)移的支持要比銀行每月聲明的 Elbonian語言版本重要得多。成功的軟件團(tuán)隊(duì)將首先集中精力構(gòu)建最重要的功能，盡可能地滿足用戶需求中關(guān)鍵的功能，而那些次關(guān)鍵性功能留到以后處理。需求排序使您的團(tuán)隊(duì)能夠?yàn)榻M織的軟件利潤作出最大貢獻(xiàn)。然而，要有效地對需求進(jìn)行優(yōu)先次序排序，必須考慮幾個(gè)因素：商業(yè)價(jià)值、交付成本、交付日期、交付復(fù)雜程度、風(fēng)險(xiǎn)（請參閱提示“控制風(fēng)險(xiǎn)：不讓風(fēng)險(xiǎn)控制您”）、與其它需求的關(guān)系、何時(shí)需要該需求。

可能的優(yōu)先級別范圍

只要明確的定義了優(yōu)先級并且在應(yīng)用上保持一致，那么使用什么優(yōu)先級別范圍是無關(guān)緊要的。一般的優(yōu)先級別范圍包括：

● 高級、中等、低級

● 必需的、條件的、可選的

● 數(shù)字的（例如，1、2、3）

如何對需求按優(yōu)先次序排序

您應(yīng)該讓授權(quán)的個(gè)人或小組來建立并確認(rèn)指派的優(yōu)先權(quán)。對需求的優(yōu)先級進(jìn)行優(yōu)先次序排序通常是一個(gè)協(xié)商的過程，它涉及到許多項(xiàng)目參與者，包括您的用戶、用戶管理、高級管理、開發(fā)人員、操作人員和支持部門。

大多數(shù)項(xiàng)目小組將組織成一個(gè)“配置控制委員會(huì) (CCB)”——有時(shí)稱為“更改控制委員會(huì)”或“項(xiàng)目籌劃指導(dǎo)委員會(huì)” ——它由系統(tǒng)中關(guān)鍵的并且希望是知識(shí)淵博的參與者組成。通常由該小組定期開會(huì)決定任何新需求的優(yōu)先級和指派（對于系統(tǒng)的發(fā)布或者對于在現(xiàn)有開發(fā)成果中的重復(fù)）。

為何對需求進(jìn)行優(yōu)先次序排序？

需求排序列表是輸入進(jìn)項(xiàng)目定界過程中的關(guān)鍵因素。項(xiàng)目早期，需要認(rèn)識(shí)到，最困難的事之一是不要打算能交付項(xiàng)目參與者要求的每個(gè)功能。項(xiàng)目范圍定義了項(xiàng)目組將要交付的范圍。這是很重要的，因?yàn)樗兄诒苊狻俺龇秶?，即，?xiàng)目進(jìn)展的附加的新需求。已定義的項(xiàng)目范圍使您能協(xié)商是否有責(zé)任交付新確定的需求，并判斷新需求對于交付日期／成本的增加的合理性以及討論是否應(yīng)該在后續(xù)發(fā)行版中交付該需求。缺少確定的范圍，項(xiàng)目組將承擔(dān)無法交付的風(fēng)險(xiǎn)，因?yàn)榻?jīng)常要向正在構(gòu)建的項(xiàng)目中添加“再多一條功能”。

規(guī)劃迭代：及時(shí)開發(fā)詳細(xì)計(jì)劃

項(xiàng)目不斷進(jìn)行時(shí)，需要詳細(xì)規(guī)劃即將實(shí)施的迭代活動(dòng)。在當(dāng)今日新月異的環(huán)境中，提前幾個(gè)月甚至幾年做詳細(xì)規(guī)劃是毫無價(jià)值的，但您可以對下幾周（典型的迭代的時(shí)間跨度）進(jìn)行成功地詳細(xì)規(guī)劃。

項(xiàng)目規(guī)劃的普遍且難以置信的有效方法是從粗略的項(xiàng)目規(guī)劃開始（請參閱“項(xiàng)目規(guī)則技巧”），即從項(xiàng)目開始時(shí)開發(fā)，然后在完成構(gòu)成項(xiàng)目的各種迭代時(shí)緩慢發(fā)展形成。隨著項(xiàng)目不斷進(jìn)展，需要更新整個(gè)粗略的項(xiàng)目規(guī)劃，更新它以反映近來努力的實(shí)際成果以及您的團(tuán)隊(duì)將繼續(xù)從事的下一個(gè)（或兩個(gè)）迭代的規(guī)劃細(xì)節(jié)。在為單一迭代開發(fā)細(xì)致的規(guī)劃時(shí)，應(yīng)該執(zhí)行這些步驟。

實(shí)行真實(shí)性檢查

通過詢問并且回答一些難題來開始詳細(xì)的規(guī)劃工作：項(xiàng)目是否仍在按計(jì)劃進(jìn)行？您的方法是否仍有意義？您的團(tuán)隊(duì)是否由合適的人員組成？您是否仍有資金管理者支持？如果其中任何一個(gè)問題的答案是否，則需要解決問題，這可能意味著新（且非常短）迭代使您的團(tuán)隊(duì)回到正常軌道上。對處于困境的項(xiàng)目進(jìn)行大計(jì)劃是毫無價(jià)值的。

標(biāo)識(shí)詳細(xì)的任務(wù)

在項(xiàng)目開始時(shí)，體系結(jié)構(gòu)和轉(zhuǎn)移迭代只是列出需要實(shí)現(xiàn)的任務(wù)列表。然而，要規(guī)劃迭代，必須評估已為它指定的需求（請參閱“基于需求的規(guī)劃策略”）。隨著項(xiàng)目發(fā)展，您將對于對個(gè)別需求有更好理解。您可能會(huì)發(fā)現(xiàn)，現(xiàn)在需要更改給迭代指定的原始需求，這些需求最初是有意義的。或許已經(jīng)標(biāo)識(shí)并添加了新的需求；或許已經(jīng)擴(kuò)展或縮減了需求；或許已經(jīng)更改了優(yōu)先級。不管什么原因，您會(huì)發(fā)現(xiàn)您需要重新定義打算在該迭代中實(shí)現(xiàn)的內(nèi)容。根據(jù)需求，標(biāo)識(shí)需要實(shí)現(xiàn)的任務(wù)。

標(biāo)識(shí)任務(wù)相關(guān)性

某些任務(wù)取決于其它任務(wù)。例如，在部署源代碼之前，必須先編寫它。測試案例的開發(fā)可以在編碼之前開始。實(shí)際代碼的測試必須等待，直到已經(jīng)編寫了某些代碼（盡管或許不是所有代碼）為止。問題是某些任務(wù)必須在其它任務(wù)完成之后才能開始；某些任務(wù)必須等待，直到另一個(gè)任務(wù)開始了為止，它才可以開始；某些任務(wù)不能完成，直到另一個(gè)任務(wù)完成為止；某些任務(wù)不能完成，直到另一個(gè)任務(wù)開始了為止。

均衡資源

需要緊記的重要事情是，每個(gè)人一次只可處理那么多任務(wù)，并且在工作的那一天只有那么多時(shí)間。這個(gè)概念稱為資源均衡，確保任務(wù)分派是合理的。 指定用 10% 的時(shí)間完成 10 項(xiàng)任務(wù)很可能無法完成任何任務(wù)， 而且指定用 50% 的時(shí)間完成 5 項(xiàng)任務(wù)的人員也不可能完成這些任務(wù)。確?，F(xiàn)實(shí)的規(guī)劃的最好方法是，讓執(zhí)行計(jì)劃的人員參與計(jì)劃開發(fā)。

保持迭代短小

迭代周期應(yīng)該保持比較短。應(yīng)該將大于 8 周的迭代分割，以便讓您迅速將軟件交付給用戶。因?yàn)檎趪L試彌補(bǔ)在先前迭代中跳過的工作（如文檔編制），或者因?yàn)槟男枨笳谠黾佣鴽]有添加新的迭代來反映這一事實(shí)，所以當(dāng)項(xiàng)目進(jìn)展時(shí)迭代長度增長是一種趨勢。執(zhí)行真實(shí)性檢查并按照它們的結(jié)果行動(dòng)，將幫助您使迭代周期保持簡短。

考慮并行開發(fā)

分幾個(gè)子團(tuán)隊(duì)來同時(shí)進(jìn)行系統(tǒng)的不同部分始終是一種有效的辦法，尤其對于系統(tǒng)縱向片段的開發(fā)。并行開發(fā)可以大大地縮短產(chǎn)品的上市時(shí)間，這是當(dāng)今高度市場競爭性的一個(gè)重要因素，盡管它以增加協(xié)調(diào)工作為代價(jià)。共同的體系結(jié)構(gòu)、共享知識(shí)視野、共同的開發(fā)實(shí)踐、定期團(tuán)隊(duì)會(huì)議及共享工作場地使并行開發(fā)成為可能。

【?發(fā)表評論?0條?】