【正文】 角度），而不考慮這些目標(biāo)如何實(shí)現(xiàn)。 產(chǎn)品 (3) ? 一旦了解了產(chǎn)品的目的和范圍，就要開(kāi)始考慮備選的解決方案了。 過(guò)程 ? 軟件過(guò)程提供了一個(gè)框架，在該框架下可以建立一個(gè)軟件開(kāi)發(fā)的全面計(jì)劃。 ? 若干不同的任務(wù)集合 ―― 每一個(gè)集合都由任務(wù)、里程碑、工作產(chǎn)品以及質(zhì)量保證點(diǎn)組成 ―― 使得框架活動(dòng)能被修改以適應(yīng)于不同軟件項(xiàng)目的特征和項(xiàng)目組的需求。庇護(hù)性活動(dòng)獨(dú)立于任何一個(gè)框架活動(dòng)，且貫穿于整個(gè)過(guò)程。 ? 1998年，產(chǎn)業(yè)數(shù)據(jù)表明 26％的軟件項(xiàng)目徹底失敗 ，而 46％的項(xiàng)目經(jīng)歷了成本和進(jìn)度超出預(yù)算 。 人員 (1) ? 在 IEEE發(fā)表的一項(xiàng)研究中，三個(gè)大型的技術(shù)公司的主管工程的副總裁被問(wèn)到一個(gè) 成功軟件項(xiàng)目中最重要的因素是什么 。 人員 (2) ? 第二位 ：一個(gè)項(xiàng)目成功的最重要的因素是有聰明的 人 ......我想不出其它的因素 ......你為一個(gè)項(xiàng)目所做的最重要的事情是選擇人員 ......軟件開(kāi)發(fā)組織的成功與其招募優(yōu)秀人才的能力密切相關(guān)。 人員 (3) ? 這是對(duì)軟件工程過(guò)程中 人 的重要性的強(qiáng)有力的證明。管理者表態(tài)說(shuō)人員是主要的，但他們的行為有時(shí)與說(shuō)話不符。 項(xiàng)目參與者 ? 參與軟件過(guò)程（及每一個(gè)軟件項(xiàng)目）的人員可以分為以下五類(lèi)： ? ? 1． 高級(jí)管理者 ：負(fù)責(zé)定義業(yè)務(wù)問(wèn)題，這些問(wèn)題往往對(duì)項(xiàng)目產(chǎn)生很大影響。 ? 3． 開(kāi)發(fā)人員 ：負(fù)責(zé)開(kāi)發(fā)一個(gè)產(chǎn)品或應(yīng)用所需的專(zhuān)門(mén)技術(shù)。 項(xiàng)目參與者 ? 5． 最終用戶(hù) ：一旦軟件發(fā)布成為產(chǎn)品，最終用戶(hù)是直接與軟件進(jìn)行交互的人。為了達(dá)到有效，項(xiàng)目組的組織必須最大限度地發(fā)揮每個(gè)人的技術(shù)和能力。 項(xiàng)目負(fù)責(zé)人 (1) ? 項(xiàng)目管理是集中于人的活動(dòng)，因此，勝任的開(kāi)發(fā)人員常常是拙劣的項(xiàng)目負(fù)責(zé)人。 ? 如 Edgemon所說(shuō)： “ 很不幸而且是很經(jīng)常地，似乎人們碰巧落在項(xiàng)目管理者的位置上，也就意外地成為了項(xiàng)目管理者 ” 。 ? 組織（ Organization） ：建模已有的過(guò)程的一種能力，以使得最初的概念能夠轉(zhuǎn)換成最終的產(chǎn)品。 項(xiàng)目負(fù)責(zé)人 (3) ? Weinberg提出 ：成功的項(xiàng)目負(fù)責(zé)人應(yīng)采用一種解決問(wèn)題的管理風(fēng)格，即，軟件項(xiàng)目經(jīng)理應(yīng)該集中于理解待解決的問(wèn)題，管理新想法的交流，同時(shí)，讓項(xiàng)目組的每一個(gè)人知道 質(zhì)量很重要 ，不能妥協(xié)。 ? 管理者的特性 ：一個(gè)好的項(xiàng)目經(jīng)理必須掌管整個(gè)項(xiàng)目。 項(xiàng)目負(fù)責(zé)人 (5) ? 成就 ：為了提高項(xiàng)目組的生產(chǎn)率，項(xiàng)目經(jīng)理必須獎(jiǎng)勵(lì)具有主動(dòng)性和作出成績(jī)的人。 ? 影響和隊(duì)伍建設(shè) ：一個(gè)有效的項(xiàng)目經(jīng)理必須能夠 “ 讀懂 ” 人；他必須能夠理解語(yǔ)言的和非語(yǔ)言的信號(hào)，并對(duì)發(fā)出這些信號(hào)的人的要求作出反應(yīng)。 (1) ? 軟件開(kāi)發(fā)的人員組織結(jié)構(gòu)幾乎與開(kāi)發(fā)軟件的組織一樣多。關(guān)心組織改變所產(chǎn)生的實(shí)際的及政策上的后果并不是軟件項(xiàng)目管理者的責(zé)任范圍。 ? ? QUOTE：并非每個(gè)小組都是開(kāi)發(fā)隊(duì)伍，并非每個(gè)開(kāi)發(fā)隊(duì)伍都是有效的。 ? 2． n個(gè)人被分配到 m個(gè)不同的功能任務(wù) （ mn），這樣要建立非正式的 “ 小組 ” ；需指定專(zhuān)門(mén)的小組負(fù)責(zé)人；小組之間的協(xié)調(diào)由軟件管理者負(fù)責(zé)。 ? ? 雖然對(duì)于上述的每一種方法都可以找到其優(yōu)點(diǎn)和缺點(diǎn)，但 越來(lái)越多的證據(jù)表明正式的小組組織（第 3種方法）是生產(chǎn)率最高的 。 Mantei提出了 三種一般的小組組織方式： ? 民主分權(quán)式 （ Democratic Decentralized， DD）：這種軟件工程小組沒(méi)有固定的負(fù)責(zé)人。問(wèn)題和解決方法的確定是由小組討論決策的。 (5) ? 控制分權(quán)式 （ Controlled Decentralized， CD）：這種軟件工程小組有一個(gè)固定的負(fù)責(zé)人，他協(xié)調(diào)特定的任務(wù)及負(fù)責(zé)子任務(wù)的二級(jí)負(fù)責(zé)人。子組和個(gè)人間的通信是水平的，但也會(huì)發(fā)生沿著控制層次產(chǎn)生的垂直通信。負(fù)責(zé)人和小組成員之間的通信是垂直的。 ? * 產(chǎn)生的程序的規(guī)模，以代碼行或者功能點(diǎn)來(lái)衡量。 ? * 問(wèn)題能夠被模塊化的程度。 ? * 交付日期的嚴(yán)格程度。 ? ? ？ ：當(dāng)組織軟件隊(duì)伍時(shí)，我們應(yīng)該考慮什么因素？ (8) ? 因?yàn)榧惺降慕Y(jié)構(gòu)能夠更快地完成任務(wù)，因此最適合處理簡(jiǎn)單問(wèn)題。因?yàn)?CD小組 是集中式地解決問(wèn)題，所以 CD或 CC小組結(jié)構(gòu)能夠成功地應(yīng)用于簡(jiǎn)單的問(wèn)題 。 ? 因?yàn)樾〗M的表現(xiàn)與必須進(jìn)行的通信量成反比，所以 很大的項(xiàng)目最好采用 CC或 CD結(jié)構(gòu)的小組 ，如果子組劃分是能夠很容易地進(jìn)行的話。發(fā)現(xiàn) DD小組結(jié)構(gòu)能夠產(chǎn)生較高的士氣和工作滿意度，因此適合生命期較長(zhǎng)的小組。 (10) ? DD小組結(jié)構(gòu)最適于解決模塊化程度較低的問(wèn)題， 因?yàn)樗枰嗟耐ㄐ拧? ? CC和 CD小組已被發(fā)現(xiàn)能夠產(chǎn)生比 DD小組更少的缺陷， 但這些數(shù)據(jù)與小組所采用的特定的質(zhì)量保證活動(dòng)密切相關(guān)。 (11) ? Constantine提出了軟件工程小組的四個(gè) “ 組織范型 ” ： ? ? 1． 封閉式范型 ：按照傳統(tǒng)的權(quán)利層次來(lái)組織小組（類(lèi)似 CC小組）。 ? 2． 隨機(jī)式范型 ：松散地組織小組，并依賴(lài)于小組成員個(gè)人的主動(dòng)性。但當(dāng)需要 “ 有次序的完成 ” 時(shí)，這種小組就會(huì)陷入困境。工作的完成結(jié)合了大量的通信和基于小組一致意見(jiàn)的決策。 ? 4． 同步式范型 ：依賴(lài)于問(wèn)題的自然劃分，組織小組成員各自解決問(wèn)題的片斷，他們之間沒(méi)有什么主動(dòng)的通信 。這種結(jié)構(gòu)由 Harlan Mills首先提出，并由 Baker描述出來(lái)的。 (14) ? 主程序員可以由一個(gè)或多個(gè)專(zhuān)家（如電訊專(zhuān)家，數(shù)據(jù)庫(kù)設(shè)計(jì)者）、支持人員（如技術(shù)文檔寫(xiě)作者，行政人員）和軟件資料員來(lái)配合。資料員的重要性不能過(guò)分強(qiáng)調(diào)。 (15) ? Constantine提出了民主分權(quán)式小組的一個(gè)變種，他主張具有創(chuàng)新獨(dú)立性的小組，其工作的方式最好稱(chēng)之為 “ 創(chuàng)新的無(wú)政府狀態(tài) ” 。為了達(dá)成一個(gè)高性能的小組： ? * 小組成員必須相互信任。 ? * 鬧獨(dú)立的人員必須被排斥于小組之外，如果需要保持小組凝聚力。在其論著 人件（ Peopleware） 中， DeMarco和Lister討論了這個(gè)問(wèn)題： ? ? 我們?cè)谏虡I(yè)中往往是隨便使用小組這個(gè)詞，把任何被分配在一起工作的一組人都稱(chēng)為一個(gè) “ 小組 ” 。它沒(méi)有統(tǒng)一的對(duì)于成功的定義，沒(méi)有任何可標(biāo)識(shí)的團(tuán)隊(duì)精神。 (17) ? 一個(gè)有凝聚力的小組是一組團(tuán)結(jié)緊密的人，他們的整體力量大于個(gè)體力量的總和 ...... ? 一旦一個(gè)小組具有凝聚力，成功的可能性就大大提高。他們已經(jīng)有了動(dòng)力。他們共享一個(gè)共同的目標(biāo)、共同的文化，而且在很多情況下， “ 精英的感覺(jué) ”使得他們獨(dú)一無(wú)二。她定義了 5個(gè) “ 培育潛在有毒的小組環(huán)境 ” 的因素： (19) ? 1. 一個(gè)狂亂的工作環(huán)境 ，在其中小組成員浪費(fèi)能量并失去對(duì)將要完成的工作目標(biāo)的關(guān)注。 ? 3. 變成完成任務(wù)的障礙的 “ 碎片式的或糟糕協(xié)調(diào)的規(guī)程 ” 或一個(gè)糟糕定義的或不適當(dāng)選擇的過(guò)程。 ? 5. 導(dǎo)致信息信心缺乏和道德下降的 “ 連續(xù)的和重復(fù)的失敗 ” 。 ? 為了避免狂亂的工作環(huán)境，項(xiàng)目管理者應(yīng)該確保小組可訪問(wèn)完成工作所需的所有信息，以及主要的目標(biāo)一旦定義，不到萬(wàn)不得已，不應(yīng)該修改。 (21) ? 雖然挫敗有很多原因，但是，軟件人員經(jīng)常在他們?nèi)鄙贆?quán)威去控制其情況時(shí)才感覺(jué)到。給予小組的對(duì)過(guò)程和技術(shù)決策的控制越多，小組成員感受到的挫敗就越少。 ? 有很多原因使軟件項(xiàng)目陷入困境。 不確定性 是經(jīng)常存在的，它會(huì)引起困擾項(xiàng)目組的一連串的改變。新的軟件必須與已有的軟件通信，并遵從系統(tǒng)或產(chǎn)品所加諸的預(yù)定義約束。 ? 為了有效地處理它們，軟件工程小組必須建立有效的方法以協(xié)調(diào)參與工作的人。正式的通信是通過(guò) “ 文字、會(huì)議及其它相對(duì)而言非交互的和非個(gè)人的通信渠道 ” 來(lái)實(shí)現(xiàn)。軟件工程小組的成員在一個(gè)特別的基礎(chǔ)上共享其想法，出現(xiàn)問(wèn)題時(shí)請(qǐng)求幫助，且每天互相交流。 ? 正式的、人員間的規(guī)程 ：集中于應(yīng)用于軟件工程工作產(chǎn)品的質(zhì)量保證活動(dòng)。 ? 非正式的、人員間的規(guī)程 ：包括信息傳播、問(wèn)題解決及 “ 需求和開(kāi)發(fā)人員配置 ” 的小組會(huì)議。