【文章內(nèi)容簡(jiǎn)介】 。 ? 小組的核心是由以下人員組成的 ： ? 一個(gè)高級(jí)工程師 （ “ 主程序員 ” ），負(fù)責(zé)計(jì)劃、協(xié)調(diào)和復(fù)審小組的所有技術(shù)活動(dòng)； ? 技術(shù)人員 （一般 2到 5個(gè)人），執(zhí)行分析和開發(fā)活動(dòng)；及 ? 一個(gè)后備工程師， 支持高級(jí)工程師的活動(dòng)，并能在項(xiàng)目進(jìn)行過程中以最小的代價(jià)取代高級(jí)工程師的工作。 (14) ? 主程序員可以由一個(gè)或多個(gè)專家（如電訊專家，數(shù)據(jù)庫設(shè)計(jì)者）、支持人員（如技術(shù)文檔寫作者，行政人員）和軟件資料員來配合。資料員為多個(gè)小組服務(wù)，完成以下功能：維護(hù)和控制所有軟件配置（即，文檔，源程序，數(shù)據(jù)和磁介質(zhì)）；幫助收集和格式化軟件生產(chǎn)率數(shù)據(jù)；分類和索引可復(fù)用軟件構(gòu)件；輔助小組進(jìn)行研究、評(píng)估及文檔準(zhǔn)備。資料員的重要性不能過分強(qiáng)調(diào)。資料員充當(dāng)了軟件配置的控制者、協(xié)調(diào)者及潛在的評(píng)估者。 (15) ? Constantine提出了民主分權(quán)式小組的一個(gè)變種，他主張具有創(chuàng)新獨(dú)立性的小組，其工作的方式最好稱之為 “ 創(chuàng)新的無政府狀態(tài) ” 。雖然自由精神的軟件工作方式是有吸引力的，但是，引入創(chuàng)新的能量到高性能的小組中必須是軟件工程組織的一個(gè)中心目標(biāo)。為了達(dá)成一個(gè)高性能的小組： ? * 小組成員必須相互信任。 ? * 技能的分布必須適合于問題。 ? * 鬧獨(dú)立的人員必須被排斥于小組之外，如果需要保持小組凝聚力。 (16) ? 不考慮小組的組織，每一個(gè)項(xiàng)目管理者的目標(biāo)都是幫助建立一個(gè)有凝聚力的小組。在其論著 人件（ Peopleware） 中， DeMarco和Lister討論了這個(gè)問題： ? ? 我們?cè)谏虡I(yè)中往往是隨便使用小組這個(gè)詞，把任何被分配在一起工作的一組人都稱為一個(gè) “ 小組 ” 。但很多這樣的組并不象小組。它沒有統(tǒng)一的對(duì)于成功的定義，沒有任何可標(biāo)識(shí)的團(tuán)隊(duì)精神。它們所缺少的是一種很珍貴的東西，我們稱之為凝聚力。 (17) ? 一個(gè)有凝聚力的小組是一組團(tuán)結(jié)緊密的人，他們的整體力量大于個(gè)體力量的總和 ...... ? 一旦一個(gè)小組具有凝聚力，成功的可能性就大大提高。這個(gè)小組可以變得不可阻擋，成為成功的象征 ......他們不需要按照傳統(tǒng)的方式進(jìn)行管理，也不需要去激勵(lì)。他們已經(jīng)有了動(dòng)力。 (18) ? DeMarco和 Lister認(rèn)為有凝聚力小組的成員比起一般的小組而言具有更高的生產(chǎn)率和更大的動(dòng)力。他們共享一個(gè)共同的目標(biāo)、共同的文化，而且在很多情況下， “ 精英的感覺 ”使得他們獨(dú)一無二。 ? 但是，并非所有小組均具有凝聚力，事實(shí)上，很多小組都受害于 Jackman稱為 “ 小組毒性 ”的東西。她定義了 5個(gè) “ 培育潛在有毒的小組環(huán)境 ” 的因素： (19) ? 1. 一個(gè)狂亂的工作環(huán)境 ，在其中小組成員浪費(fèi)能量并失去對(duì)將要完成的工作目標(biāo)的關(guān)注。 ? 2. 導(dǎo)致小組成員間磨擦的個(gè)人、業(yè)務(wù)或技術(shù)因素所產(chǎn)生的 高的挫敗率 。 ? 3. 變成完成任務(wù)的障礙的 “ 碎片式的或糟糕協(xié)調(diào)的規(guī)程 ” 或一個(gè)糟糕定義的或不適當(dāng)選擇的過程。 ? 4. 導(dǎo)致責(zé)任缺乏和指責(zé)的不清楚的角色定義 。 ? 5. 導(dǎo)致信息信心缺乏和道德下降的 “ 連續(xù)的和重復(fù)的失敗 ” 。 (20) ? Jackman提出了一組 “ 抗毒素 ” 以對(duì)付這些常見問題。 ? 為了避免狂亂的工作環(huán)境，項(xiàng)目管理者應(yīng)該確保小組可訪問完成工作所需的所有信息，以及主要的目標(biāo)一旦定義，不到萬不得已，不應(yīng)該修改。 ? 此外，壞消息不應(yīng)該保守為秘密，而是應(yīng)該盡可能早的傳遞給小組（當(dāng)仍有時(shí)間以一種合理的和控制的方式作出反應(yīng)時(shí)）。 (21) ? 雖然挫敗有很多原因，但是，軟件人員經(jīng)常在他們?nèi)鄙贆?quán)威去控制其情況時(shí)才感覺到。一個(gè)軟件小組如果被給予了盡可能多的決策的責(zé)任，則該小組可以避免挫敗。給予小組的對(duì)過程和技術(shù)決策的控制越多，小組成員感受到的挫敗就越少。 ? 一個(gè)不適當(dāng)選擇的軟件過程可以通過 兩種方式避免 ： (1) 確定將被建造的軟件的特征符合所選擇的過程的嚴(yán)格性 ，以及 ? (2) 允許小組去選擇過程 。 ? 有很多原因使軟件項(xiàng)目陷入困境。許多開發(fā) 項(xiàng)目規(guī)模大 ，導(dǎo)致復(fù)雜性高、混亂、難以協(xié)調(diào)小組成員間的關(guān)系。 不確定性 是經(jīng)常存在的，它會(huì)引起困擾項(xiàng)目組的一連串的改變。 互操作性 已成為許多系統(tǒng)的關(guān)鍵特性。新的軟件必須與已有的軟件通信，并遵從系統(tǒng)或產(chǎn)品所加諸的預(yù)定義約束。 ? 現(xiàn)代軟件的這些特性 ―― 規(guī)模、不確定性和互操作性 ―― 都是現(xiàn)實(shí)的問題。 ? 為了有效地處理它們，軟件工程小組必須建立有效的方法以協(xié)調(diào)參與工作的人。 ? 要完成這項(xiàng)任務(wù)，必須建立小組成員之間及多個(gè)小組之間的正式的和非正式的通信機(jī)制。正式的通信是通過 “ 文字、會(huì)議及其它相對(duì)而言非交互的和非個(gè)人的通信渠道 ” 來實(shí)現(xiàn)。非正式的通信則更加個(gè)人化。軟件工程小組的成員在一個(gè)特別的基礎(chǔ)上共享其想法，出現(xiàn)問題時(shí)請(qǐng)求幫助，且每天互相交流。 ? Kraul和 Streeter調(diào)查了一系列的 項(xiàng)目協(xié)調(diào)技術(shù) ，并將其分為以下幾類： ? 正式的、與人無關(guān)的方法 ：包括軟件工程文檔和交付物（如源程序）、技術(shù)備忘錄、項(xiàng)目里程碑、進(jìn)度和項(xiàng)目控制工具、改變請(qǐng)求及相關(guān)文檔、錯(cuò)誤跟蹤報(bào)告、和中心庫數(shù)據(jù)。 ? 正式的、人員間的規(guī)程 ：集中于應(yīng)用于軟件工程工作產(chǎn)品的質(zhì)量保證活動(dòng)。包括狀態(tài)復(fù)審會(huì)議及設(shè)計(jì)和代碼檢查。 ? 非正式的、人員間的規(guī)程 ：包括信息傳播、問題解決及 “ 需求和開發(fā)人員配置 ” 的小組會(huì)議。 ? 電子通信 ：包括電子郵件、電子公告欄、Web站點(diǎn)以及基于視頻的會(huì)議系統(tǒng)。 ? 人員間的網(wǎng)絡(luò) ：與項(xiàng)目組之外的人進(jìn)行的非正式的討論，這些人可能有經(jīng)驗(yàn)或見解，能夠幫助項(xiàng)目組成員。 ? ? ？ ：我們?nèi)绾螀f(xié)調(diào)項(xiàng)目組成員間的動(dòng)作？ ? 為了評(píng)估這些項(xiàng)目協(xié)調(diào)技術(shù)的功效， Kraul和Streeter調(diào)研了 65個(gè)軟件項(xiàng)目，其中包含上百個(gè)技術(shù)人員。 ? 圖 （ [KRA95]中描述的變種）表明了上述協(xié)調(diào)技術(shù)的價(jià)值及使用。在圖中給出了不同的協(xié)調(diào)和通信技術(shù)的認(rèn)知價(jià)值（總分為 7）及它們?cè)陧?xiàng)目中的使用頻率之間的關(guān)系。落在回歸線之上的技術(shù)“ 被判定為，就給定的它們被使用的總量而言，相對(duì)而言價(jià)值較高 ” 。落在線之下的技術(shù)被認(rèn)為價(jià)值較低。 ? 人員間網(wǎng)絡(luò) 被評(píng)為具有最高的協(xié)調(diào)和通信價(jià)值的技術(shù)。早期的質(zhì)量保證機(jī)制（需求和設(shè)計(jì)復(fù)審）被認(rèn)為比起后期的源代碼評(píng)估（代碼檢查）更具價(jià)值。 ? 軟件項(xiàng)目管理者從軟件工程項(xiàng)目一開始就面臨著 進(jìn)退兩難的局面 。需要定量的估算和有組織的計(jì)劃，但卻沒有可靠的信息可以使用。 ? 對(duì)軟件需求的詳細(xì)分析可以提供必要的估算信息，但分析常常要花數(shù)周甚至數(shù)月的時(shí)間才能完成。 ? 需求可能是不固定的，隨著項(xiàng)目的進(jìn)展經(jīng)常發(fā)生改變。不過，無論如何計(jì)劃仍是 “ 現(xiàn)在 ” 就需要的！ ? 軟件項(xiàng)目管理的第一個(gè)活動(dòng)是 軟件范圍的確定 。范圍是通過回答下列問題來定義的： ? ? 語境 ：待建造的軟件如何適應(yīng)于大型的系統(tǒng)、產(chǎn)品或商業(yè)的語境，在該語境下要加什么約束？ ? 信息目標(biāo)： 軟件要產(chǎn)生什么樣的客戶可見的數(shù)據(jù)對(duì)象作為輸出？需要什么樣的數(shù)據(jù)對(duì)象作為輸入？ ? 功能和性能： 軟件要執(zhí)行什么樣的功能使得輸入數(shù)據(jù)變換成輸出？需要滿足任何特殊的性能特征嗎？ ? ? ADVICE：如果你不能把握你將建造的軟件的某特征。將該特征作為一個(gè)專業(yè)的項(xiàng)目風(fēng)險(xiǎn)列出。 ? 軟件項(xiàng)目范圍 在管理層和技術(shù)層都必須是無二義性的和可理解的。 ? 對(duì)軟件范圍的描述必須是 界定的 。即， 明確給出定量的數(shù)據(jù) （如同時(shí)用戶的數(shù)目、郵件列表的大小、允許的最大響應(yīng)時(shí)間）； ? 說明約束和 /或局限 （如產(chǎn)品成本限制內(nèi)存大?。灰约? ? 描述其它的緩解因素 （如，希望的算法能夠被很好地理解并寫成 C++程序）。 ? 問題分解，有時(shí)稱為劃分或問題詳細(xì)描述，是一個(gè)軟件需求分析的核心活動(dòng)。在確定軟件范圍的活動(dòng)中并不試圖完全分解問題。而是將分解應(yīng)用于兩個(gè)主要方面： ? （ 1）必須交付的功能； ? （ 2）用于交付功能的過程 。 ? ? KEYPOINT：為了開發(fā)合理的項(xiàng)目計(jì)劃，你必須功能地分界將被求解的問題。