軟件體系結構

(SoftwareArchitecture)講義14：以體系結構為中心的軟件項目管理軟件體系結構

(SoftwareArchitecture)內容內容簡介以體系結構為中心的軟件項目計劃全局分析管理期望項目組織建立項目文化和小組軟件項目經(jīng)理的角色權衡和項目決策增量式開發(fā)創(chuàng)建可視性與避免意外在激烈的競爭中保持冷靜需關注的度量什么是“出色的工作”總結內容內容簡介技術和管理是項目成功的兩個基石好的設計和項目管理技巧對于項目的成功大有幫助作為一個產(chǎn)業(yè)，我們還未能非常成功地管理成功的軟件項目。成功的項目是指達到計劃的開發(fā)進度、提供承諾的功能并交付高質量軟件的項目據(jù)1995年StandishGroupCHAOS的報告，他們對軟件項目的研究表明：16%的軟件項目完全成功，31%的項目被完全取消，53%的項目嚴重超出預算、延期并交付少于預期的功能到1998年，成功地項目增多了：26%完全成功，28%被完全取消，46%超過預算、延期和缺少功能情況在改善，但是，對于成功完成的軟件開發(fā)項目，業(yè)界的紀錄依舊很糟糕技術和管理是項目成功的兩個基石好的設計和項目管理技巧對于項目體系結構在管理中的作用(1/3)以技術為中心的體系結構的作用觀點，基于以下的基本假設體系結構是開發(fā)軟件系統(tǒng)的關鍵體系結構是實現(xiàn)商業(yè)目標、達到軟件質量品質的基礎為提高軟件質量而設計軟件體系結構，以及如何評估軟件體系結構是否完全實現(xiàn)它的質量目標如果說體系結構是實現(xiàn)系統(tǒng)所要達到的商業(yè)目標的核心，那么，體系結構也必須成為項目經(jīng)理和軟件架構師的工作核心“在缺少高層體系結構的情況下，工作的時間進度和工作量的估算是毫無價值的”項目經(jīng)理需要根據(jù)體系結構來制定進度計劃、進行估算和管理人員體系結構在管理中的作用(1/3)以技術為中心的體系結構的作用體系結構在管理中的作用(2/3)估算的經(jīng)驗值，項目開發(fā)時間的分配40%用于設計：最多用3個月的時間進行高層設計，剩下的用于底層設計20%用于編碼40%用于測試：需要在開發(fā)小組內著重強調對體系結構的縱向劃分使得系統(tǒng)能夠增量式地添加其它功能，并調整功能以適應各種版本正如體系結構體現(xiàn)了各種質量之間的權衡，進度計劃也體現(xiàn)了交付時間、質量和功能之間的權衡。要向開發(fā)小組明確三者之間的優(yōu)先級，并利用進度的壓力來避免對質量和功能的過度強調通過較短周期（8周）的增量式提交，有可能開發(fā)有限銷售的功能，并選取在一次增量開發(fā)時間內那些以可接受的質量實現(xiàn)的功能體系結構在管理中的作用(2/3)估算的經(jīng)驗值，項目開發(fā)時間的體系結構在管理中的作用(3/3)進度表依賴于體系結構，而增量式提交依賴于進度表，這種控制是以體系結構為基礎的軟件開發(fā)的根本特性以體系結構為中心的項目管理技術是同現(xiàn)有的管理技術緊密相關的制定明確的進度表得到股東的支持確定切實可行的期望值對員工的弱點感覺敏銳在動蕩中保持冷靜在任何環(huán)境中，這些都是好的項目經(jīng)理應具備的素質體系結構在管理中的作用(3/3)進度表依賴于體系結構，而增量項目經(jīng)理的職責(1/2)項目經(jīng)理的主要工作計劃（Planning）組織（Organizing）：建立項目組和確定組成員的角色實現(xiàn)（Implementation）：根據(jù)制定的項目計劃，進行項目實現(xiàn)，并應付各種事先無法預測的情況度量（Measurement）：在項目開發(fā)過程中及項目開發(fā)結束后，評估項目進度、項目組及各成員的業(yè)績、提交的產(chǎn)品的有效性其它任務項目領導、控制、設定用戶期望、革新、決策、指導以及提供幫助項目經(jīng)理的職責(1/2)項目經(jīng)理的主要工作項目經(jīng)理的職責(2/2)項目經(jīng)理的成功與否在很大程度上取決于如何分配時間。永遠也不會有足夠的時間干完所有的事情，項目經(jīng)理需要謹慎地決定各個任務的優(yōu)先級，并成功地平衡時間好的項目經(jīng)理常常都有均衡的技術和人員管理的技能人員管理的技能通常表現(xiàn)在交流、理解、領導能力、情感、教學、個人魅力等多方面通常，項目組的技術能力可以通過任用強有力的軟件架構師得到增強項目經(jīng)理的職責(2/2)項目經(jīng)理的成功與否在很大程度上取決于以體系結構為中心的項目管理(1/3)以體系結構為中心的軟件項目計劃（Architecture-CenteredSoftwareProjectPlanning,ACSPP）方法根據(jù)軟件體系結構來估算開發(fā)項目的費用和進度這里所描述的項目管理實踐可以稱為“中量級”的過程，介于能力成熟度模型（CMM）和Rational統(tǒng)一過程（RUP）所描述的重量級過程與極限編程這樣的輕量級過程之間在前期準備工作中多花一些時間，包括為預想的產(chǎn)品設計軟件體系結構以及制定項目計劃。實現(xiàn)中采取增量開發(fā)方法，以便迅速占領市場，并在實現(xiàn)體系結構的同時，增量式地更新項目計劃以體系結構為中心的項目管理(1/3)以體系結構為中心的軟件項以體系結構為中心的項目管理(2/3)基本特征體系結構的設計和描述項目計劃：進度表、工作量估算和項目組織結構增量式開發(fā)項目經(jīng)理/架構師小組：分別對應管理決策和技術決策權衡分析：靈活管理各種開發(fā)風險軟因素：小組建設、士氣、管理的影響、業(yè)務的影響、人員經(jīng)驗和文化等項目經(jīng)理需要做許多與設計無關的事情，但明確的是，在管理項目的過程中，需要確定一個體系結構設計，它將能夠代表將要開發(fā)的產(chǎn)品的理念和外觀軟件開發(fā)計劃說明如何實現(xiàn)體系結構所代表的理念管理開發(fā)就是在計劃的指導下，逐步實現(xiàn)體系結構開發(fā)計劃需要做許多中間過程的修正，但希望體系結構在實現(xiàn)過程中能夠保持不變以體系結構為中心的項目管理(2/3)基本特征以體系結構為中心的項目管理(3/3)需求分析全局分析風險分析版本發(fā)布計劃版本交付管理開發(fā)小組軟件開發(fā)計劃體系結構設計市場需求產(chǎn)品因素風險和緩解進度次序如何做、誰承擔、何時進行中間過程的修正產(chǎn)品產(chǎn)品因素體系結構描述問題和策略模塊視圖以體系結構為中心的項目管理(3/3)需求分析全局分析風險分析計劃工作項目計劃開始于定義一系列的系統(tǒng)需求，結束于生成軟件開發(fā)計劃。項目計劃與軟件體系結構的設計并行進行，并在開發(fā)過程的每一次增量式版本發(fā)布之前進行需求分析全局分析體系結構評估風險分析軟件開發(fā)計劃版本發(fā)布計劃項目策略體系結構設計市場需求產(chǎn)品因素風險和緩解風險和緩解項目目標進度順序產(chǎn)品因素體系結構描述問題和策略設計風險如何做、誰承擔、何時進行模塊視圖計劃工作項目計劃開始于定義一系列的系統(tǒng)需求，結束于生成軟件開組織工作項目經(jīng)理需要組織體系結構設計小組、開發(fā)小組和與項目管理相關的所有活動。項目管理活動包括和組織內其他功能的接口，如市場、質量保證、系統(tǒng)測試和文檔編寫組織設計小組自底向上的估算組織開發(fā)小組領導開發(fā)小組軟件開發(fā)計劃體系結構設計市場需求紙面設計每一構件所需的工作量開發(fā)小組如何做、誰承擔、何時進行產(chǎn)品實現(xiàn)軟件架構師體系結構描述項目組成員組織工作項目經(jīng)理需要組織體系結構設計小組、開發(fā)小組和與項目管實現(xiàn)工作項目經(jīng)理負責根據(jù)軟件開發(fā)計劃實現(xiàn)項目。體系結構設計所得到的模塊視圖是組織項目開發(fā)小組的基本依據(jù)組織開發(fā)小組風險分析版本發(fā)布計劃軟件開發(fā)計劃版本交付狀態(tài)會議管理開發(fā)小組體系結構設計組織的因素組織的因素進度順序如何做、誰承擔、何時進行中間過程的修正產(chǎn)品模塊視圖問題和策略緩解模塊視圖市場因素工作進展實現(xiàn)工作項目經(jīng)理負責根據(jù)軟件開發(fā)計劃實現(xiàn)項目。體系結構設計所度量工作項目策略版本發(fā)布計劃軟件開發(fā)計劃軟件開發(fā)事后復審版本交付狀態(tài)會議體系結構設計市場需求目標進度預算工作進展中間過程的修正產(chǎn)品改善行動問題和策略模塊視圖進度順序市場需求體系結構草圖根據(jù)軟件開發(fā)計劃可以定義一些項目度量標準，作為項目開發(fā)的目標。這些目標包括開發(fā)預算、重要里程碑、規(guī)模度量和質量度量度量工作項目策略版本發(fā)布軟件開發(fā)軟件開發(fā)事后復審版本交付狀態(tài)內容內容簡介以體系結構為中心的軟件項目計劃全局分析管理期望項目組織建立項目文化和小組軟件項目經(jīng)理的角色權衡和項目決策增量式開發(fā)創(chuàng)建可視性與避免意外在激烈的競爭中保持冷靜需關注的度量什么是“出色的工作”總結內容內容簡介以體系結構為中心的軟件項目計劃以體系結構為中心的軟件項目計劃（Architecture-CenteredSoftwareProjectPlanning,ACSPP）方法根據(jù)軟件體系結構來估算開發(fā)項目的費用和進度好的軟件項目管理始于好的計劃，合適的計劃時間是在體系結構進行設計的時候在軟件開發(fā)初期給出的工作量和時間的估算可能是極其不準確的在沒有高層體系結構設計的情況下，所生成的工作量和時間的估計只有很小的價值當設計完成后，才可以創(chuàng)建項目計劃、進度表和人力資源分配方案，所有這些都依賴于該產(chǎn)品的軟件體系結構以體系結構為中心的軟件項目計劃以體系結構為中心的軟件項目計劃ACSPP的時機(1/2)在軟件開發(fā)初期給出的工作量和時間的估算可能是極其不準確的[Boehm1981,Boehmetal.2000]ACSPP是在系統(tǒng)需求分析完成之后進行的產(chǎn)品需求定義（市場人員）系統(tǒng)需求分析（系統(tǒng)工程師）高層設計（架構師）詳細設計（軟件工程師）編碼單元測試、集成測試、系統(tǒng)測試市場需求說明（MRS）系統(tǒng)需求說明（SRS）高層設計文檔（HLDD）詳細設計文檔（DDD）ACSPPACSPP的時機(1/2)在軟件開發(fā)初期給出的工作量和時間的ACSPP的時機(2/2)根據(jù)Boehm[1981]的說法，對于在需求說明結束后所給出的成本估算，實際的投入可能是其1.5倍；對于在需求分析完成前，項目啟動時所給出的估算，實際的投入可能是其4倍。在高層設計完成后，通過應用ACSPP和估算進度表，進度估算可以精確到15%~20%采用小增量式開發(fā)，更有助于項目經(jīng)理把握項目——一系列短周期的簡單計劃要比一個大而復雜的計劃更容易管理業(yè)務經(jīng)理經(jīng)常會樂于接受一個很早的進度計劃，用其與潛在的客戶溝通，并努力使開發(fā)小組按照此進度交付軟件產(chǎn)品。這樣經(jīng)常會引起客戶的不滿，因為產(chǎn)品沒有達到他們對于交付的期望，初始版本質量低下，開發(fā)小組疲憊不堪ACSPP的時機(2/2)根據(jù)Boehm[1981]的說法，ACSPP方法(1/2)高層設計自底向上的估算項目進度表軟件開發(fā)計劃自頂向下的進度表版本發(fā)布計劃個人進度表ACSPP方法(1/2)高層設計自底向上的項目進度表軟件開發(fā)ACSPP方法(2/2)軟件體系結構的高層設計由一個小型的設計小組發(fā)起與此平行，項目經(jīng)理制定自頂向下的進度計劃高層設計和自頂向下的進度估算成為版本發(fā)布計劃的輸入在高層設計中確定的軟件構件是自底向上的估算過程的一部分項目經(jīng)理然后可以計算各個軟件構件規(guī)模和工作量的估算之和，并與自頂向下的進度相比較根據(jù)所有這些信息，項目經(jīng)理制定項目開發(fā)進度計劃。這個進度計劃與人員分配和項目組織結構共同組成軟件開發(fā)計劃（SDP）項目組成員以SDP為框架，制定個人進度計劃ACSPP方法(2/2)軟件體系結構的高層設計由一個小型的設體系結構的四視圖和層次圖圖形用戶界面（GUI）應用程序應用程序服務探查服務圖像處理數(shù)據(jù)庫服務系統(tǒng)服務操作系統(tǒng)層通信硬件概念模塊代碼源代碼運行硬件體系結構的四視圖和層次圖圖形用戶界面（GUI）應用程序應用程自頂向下的進度表進度表包括的內容：工作量，成本和進度，開發(fā)主要階段的持續(xù)時間，以及對具有各種開發(fā)技能的人員的需求自頂向下的方法是軟件項目經(jīng)理估算新項目常用的方法項目經(jīng)理有很多可用的估算模型Cocomo模型SLIMPRICE-S功能點分析（FPA）就其本身而言，估算模型通常不是很精確，因此需要對模型進行較準，但很多組織缺少進行校準所需的采用類似技術的項目的歷史數(shù)據(jù)項目估算模型的結果確實很有用，因為它有助于項目經(jīng)理在計劃項目時，不至于忘記任何重大的工作量投入自頂向下計劃的估算模型也有助于管理人員了解新軟件產(chǎn)品開發(fā)的范圍和風險自頂向下的進度表進度表包括的內容：工作量，成本和進度，開發(fā)主自底向上的估算在高層設計定義了所有構件之后，每個項目組成員進行指定構件的“紙面設計”，并估算每個構件的詳細設計、編碼和單元測試所需的工作量項目經(jīng)理應該把需估算的構件分配給最可能實現(xiàn)該構件的項目組成員。這樣做可以增加估算的全面所有權，并且將個人與他們參與的系統(tǒng)各個部分聯(lián)系起來這時也是將其他成員引進項目組、開始進行自底而上估算的時機。一直到這時，開發(fā)小組主要由項目經(jīng)理和高層設計小組組成，由軟件架構師領導構件設計概要估算是與規(guī)模、信心水平、復雜度以及相關設計、編碼和測試工作量等因素有關的自底向上的估算在高層設計定義了所有構件之后，每個項目組成員進版本發(fā)布計劃軟件開發(fā)計劃可以被設計成一系列不斷增加功能的增量式工程版本第一個版本將包含體系結構層次圖的“縱向分塊”，作為體系結構的原型最后一個版本將是可以打包銷售給客戶的第一個功能集合還可以計劃內部測試或主要用戶測試的α或β版本需要計劃版本的增量和測試，這樣開發(fā)人員可以得到測試結果，以在下個版本中對錯誤進行修改為這些增量版本定義的時間周期將依賴于測試和特征開發(fā)所需的時間，同時也依賴于商業(yè)的限制版本發(fā)布計劃軟件開發(fā)計劃可以被設計成一系列不斷增加功能的增量構造計劃特征發(fā)布規(guī)格說明（FRS）經(jīng)過市場部門和服務部門咨詢，編寫FRS，并詳細說明每個工程版本包括哪些產(chǎn)品特征構件發(fā)布規(guī)格說明（CRS）描述必要的構件版本發(fā)布，以實現(xiàn)在每個工程版本中所要求的特征構件版本發(fā)布的責任被分派給小組成員，小組成員根據(jù)這些文檔制定他們自己的個人進度表在整個開發(fā)周期中，版本發(fā)布計劃通常由一系列主要特征來標識目標版本；構造計劃更多地集中于描述在下一個增量版本（即“內部工程版本”）中要開發(fā)的詳細特征的實現(xiàn)順序構造計劃特征發(fā)布規(guī)格說明（FRS）項目進度計劃根據(jù)自頂向下的進度、自底而上的估算、FRS和CRS，可以制定項目的進度綱要，以使得每個內部工程版本都可以在預期的里程碑之內完成設計、編碼、單元測試、集成以及系統(tǒng)測試等工作對于每個版本，都可將每個構件的開發(fā)按照開發(fā)階段（如詳細設計、編碼、單元測試、錯誤修正）分解為子任務，并在每一增量式發(fā)布的過程中重復這些階段。根據(jù)自底而上估算過程所得到的工作量估算，制定每一個構件的進度表計劃提高計劃的可見度，讓每一個人都了解“項目戰(zhàn)斗室”：所有項目進度計劃表都被張貼到一個會議室的墻上，并每周更新項目進度，用彩筆標注出哪些項目已經(jīng)完成，哪些已經(jīng)遲于進度計劃了項目進度計劃根據(jù)自頂向下的進度、自底而上的估算、FRS和CR實例：高層軟件開發(fā)進度綱要實例：高層軟件開發(fā)進度綱要軟件開發(fā)計劃（SDP）軟件開發(fā)計劃是一個短的文檔，包括項目進度表工程版本定義人員需求子承包商的應用項目組織成本估算開發(fā)工具及過程任務分配風險硬件平臺……SDP引用該組織的軟件開發(fā)過程、高層設計文檔（HLDD）、功能發(fā)布說明（FRS）以及構件發(fā)布說明（CRS）軟件開發(fā)計劃（SDP）軟件開發(fā)計劃是一個短的文檔，包括實例：軟件開發(fā)計劃大綱1.0引論

1.1項目概論

1.2項目交付物2.0參考資料

2.1說明

2.2標準3.0項目組織

3.1過程模型

3.2組織結構

3.3組織邊界和接口

3.4項目職責4.0管理過程

4.1管理目標和優(yōu)先級

4.2假設、依賴關系和約束

4.3監(jiān)督和控制機制

4.4人員安排和培訓

4.5子承包商管理5.0技術過程

5.1方法、工具和技術

5.2軟件文檔

5.3項目支持功能6.0風險管理7.0工作要素、進度和預算

7.1工作包

7.2依賴關系

7.3資源需求

7.4預算和資源分配

7.5高層軟件開發(fā)過程實例：軟件開發(fā)計劃大綱1.0引論5.0技術過程個人進度表一旦包括項目進度在內的SDP完成，就應該把它交給項目開發(fā)組的所有成員。根據(jù)項目進度表、軟件開發(fā)過程以及任務分配，每個成員制定個人進度表這個進度表非常細，可以監(jiān)控項目組每個人每周的開發(fā)情況建議項目經(jīng)理每周檢查個人進度，并根據(jù)項目的規(guī)模和復雜程度，每兩周或每月更新項目進度一旦每個人對其所負責開發(fā)的構件在整個軟件體系結構中的位置和作用都了解了，構件的開發(fā)將會變得更加簡單和可以預測項目經(jīng)理和軟件架構師作為開發(fā)小組的教練，而不是如工頭一樣迫使小組接受計劃并強制執(zhí)行個人進度表一旦包括項目進度在內的SDP完成，就應該把它交給項經(jīng)驗數(shù)據(jù)(1/2)與估算有關的工作所占用時間的經(jīng)驗數(shù)據(jù)高層設計持續(xù)時間：至多3個月開發(fā)小組規(guī)模：最多6個架構師估算的構件數(shù)目：最多150個每個構件的紙面設計時間：最多4小時自底而上的估算時間：最多3個星期工程版本發(fā)布間隔：最多8個星期進度偏移：最多20%項目總體工作量分配

設計：40%

編碼：20%

測試：40%跟蹤里程碑：每周進度更新和風險評估：每月或是在每一個版本發(fā)布之前經(jīng)驗數(shù)據(jù)(1/2)與估算有關的工作所占用時間的經(jīng)驗數(shù)據(jù)高層設經(jīng)驗數(shù)據(jù)(2/2)對于中等規(guī)模的項目應用這些經(jīng)驗值，我們估計高層設計階段大約占總共開發(fā)成本的5%我們假設，由4~5人工作3個月所進行的高層體系結構設計，將對一個由20個人工作一年甚至更長時間所開發(fā)的項目，產(chǎn)生深遠的影響這20個小組成員還將對體系結構中的每個構件進行設計，稱為詳細設計因此，和設計有關的活動的工作量有可能占到整個項目成本投入的40%；但是最初的5%的對軟件體系結構的投入，將對開發(fā)產(chǎn)生最為深刻的影響經(jīng)驗數(shù)據(jù)(2/2)對于中等規(guī)模的項目應用這些經(jīng)驗值，我們估計提示“當時間不夠時，停止高層設計”問題：高層設計和詳細設計的界限是什么？軟件架構師的回答：當設計已詳細到可以將每一個模塊交給開發(fā)人員進行詳細設計時，高層設計就結束了對于實踐的項目經(jīng)理來說，這些界限是模糊的，是以里程碑為驅動的建議：成功的做法是大致按照上表所提供的經(jīng)驗數(shù)據(jù)，限制高層設計的時間。體系結構的設計永遠不會完全結束，但是，確定一個必須完成和復查的時間將有助于指導設計小組提示“當時間不夠時，停止高層設計”內容內容簡介以體系結構為中心的軟件項目計劃全局分析管理期望項目組織建立項目文化和小組軟件項目經(jīng)理的角色權衡和項目決策增量式開發(fā)創(chuàng)建可視性與避免意外在激烈的競爭中保持冷靜需關注的度量什么是“出色的工作”總結內容內容簡介什么是全局分析在著手設計一個新的軟件系統(tǒng)體系結構時，一個眾所周知的問題是：隨著市場需求、技術、硬件和業(yè)務等因素的變化，系統(tǒng)的設計和實現(xiàn)也將相應地改變其中一些影響因素影響整個系統(tǒng)，而其中某些因素和其他因素直接沖突。為了避免潛在的大量返工，這些因素必須在高層設計的開始就予以考慮全局分析就是分析對系統(tǒng)體系結構設計產(chǎn)生全局性影響的組織、技術和產(chǎn)品等方面的因素全局分析是體系結構設計的一個組成部分，在設計階段的開始便應用到體系結構的各個視圖中全局分析的結果是一組全局策略，可用于指導體系結構設計并提高系統(tǒng)對于各種已識別的影響因素的應變能力全局分析得到的策略將影響體系結構的設計和項目計劃什么是全局分析在著手設計一個新的軟件系統(tǒng)體系結構時，一個眾所全局分析方法分析組織因素分析技術因素分析產(chǎn)品因素影響因素為實現(xiàn)、構造能力和可變能力的改善制定策略全局分析方法分析組織因素分析技術因素分析產(chǎn)品因素影響因素為實全局分析活動采用兩種工具輔助全局分析并記錄結果因素表問題卡片分析因素確定和描述因素描述因素的靈活性和可變性分析因素的影響開發(fā)策略確定問題和影響因素制定解決方案和特殊策略確定相關的策略全局分析活動采用兩種工具輔助全局分析并記錄結果分析因素開發(fā)策通用因素表：組織因素組織因素靈活性和可變性影響O1:<因素分類>O1.1:<因素分類><因素的描述>O1.2:<因素分類><因素的描述>O2:<因素分類>O2.1:<因素分類><因素的描述>O2.2:<因素分類><因素的描述><因素的哪些方面是靈活的或是可變的><因素的哪些方面是靈活的或是可變的><因素的哪些方面是靈活的或是可變的><因素的哪些方面是靈活的或是可變的><受因素或因素變化影響的構件><受因素或因素變化影響的構件><受因素或因素變化影響的構件><受因素或因素變化影響的構件>通用因素表：組織因素組織因素靈活性和可變性影響O1:<因素分實例：因素表組織因素靈活性和可變性影響O1:管理

O1.1:新的管理對于IS2000項目新的項目管理O2:人員

O2.1:士氣低落小組成員的士氣低落造成軟件開發(fā)人員的流動性大O4:開發(fā)進度表

O4.1:投入市場的時間要求投入市場的時間是兩年

新的項目管理有可能改變項目目標隨著人員的離開和替代，小組組成將發(fā)生變化由于是業(yè)務需求,該時間要求必須滿足為了適應新的目標，需求和體系結構設計有可能改變剩下的或是新上任的小組成員需要理解體系結構設計。高層設計文檔應該完整并易于閱讀開發(fā)時間短將對設計選擇和項目計劃產(chǎn)生很大的影響實例：因素表組織因素靈活性和可變性影響O1:管理通用問題卡片〈體系結構設計問題的名稱〉<問題描述>影響因素:<影響因素對該設計問題的影響以及它們是如何影響的>解決方案:<對于設計問題的通用解決方案的討論,并附有相關策略的列表>策略:<策略名稱><對策略的解釋>策略:<策略名稱><對策略的解釋>相關策略:<對于相關策略的引用,并討論這些策略如何與該設計問題相關>通用問題卡片〈體系結構設計問題的名稱〉<問題描述>實例：問題卡片Pr1：積極的進度表就估算的工作量以及可以獲得的資源，在兩年內可能難以完成軟件的開發(fā)影響因素：O1.1:經(jīng)常更換新的管理層并改變項目目標有可能減緩項目的開發(fā)O1.2:士氣低落有可能造成員工離職，引起小組規(guī)模減小O4.1:兩年的時限是根據(jù)商業(yè)情況得到的。如果沒有新的產(chǎn)品發(fā)布，公司難以生存解決方案：需要長于兩年的時間來重新設計和開發(fā)所有的軟件。有3種可能的策略：軟件復用、購買商用成品（commercialoff-the-shelf,COTS）構件，以及采用增量式開發(fā)和功能版本發(fā)布策略：S1.1:復用S1.1:從已有的項目中,復用一些公司內部的面向特定領域的構件策略:S1.2:購買COTSS1.2:盡可能地購買市場上可以得到的軟件,而不是重新建造策略:S1.3:增量式開發(fā)S1.3:增量式開發(fā)和功能版本發(fā)布,使得可以較晚地添加優(yōu)先級較低的產(chǎn)品功能實例：問題卡片Pr1：積極的進度表就估算的工作量以及可以獲得組織的影響因素一些組織因素（例如進度表和預算）只能應用于現(xiàn)在正在設計的產(chǎn)品，其他組織因素（例如組織的態(tài)度、文化、開發(fā)場所的位置和軟件開發(fā)過程）會影響組織每一個開發(fā)的項目一些組織因素可以控制，但在許多組織中，這些因素是固定的，因此，體系結構的設計必須在這些限制之內。在很多情況下，組織因素是項目經(jīng)理必須接受和容忍的。組織因素（如組織結構、開發(fā)過程、人員和環(huán)境）經(jīng)常不易改變，或是只有在很長一段時間后才會改變組織因素一般包括以下幾類：O1——管理O2——員工技能、興趣、強項、弱項O3——過程及開發(fā)環(huán)境O4——開發(fā)進度表O5——開發(fā)預算組織的影響因素一些組織因素（例如進度表和預算）只能應用于現(xiàn)在技術的影響因素技術因素將設計的選擇局限于現(xiàn)有的硬件、軟件、體系結構技術以及標準產(chǎn)品必須能夠適應于技術的不斷變化，因此體系結構設計時應保持靈活。由于技術變化快、廠家競爭等原因，技術因素和選擇平臺的決策是當前軟件開發(fā)的重要問題技術因素一般包括以下幾類T1——通用硬件T2——領域特定硬件T3——軟件技術T4——體系結構技術T5——標準技術的影響因素技術因素將設計的選擇局限于現(xiàn)有的硬件、軟件、體產(chǎn)品的影響因素產(chǎn)品因素包括產(chǎn)品的功能及質量，例如性能、可信賴性、安全性以及成本。這些因素也許會在后來的版本中有所不同，因此需要設計體系結構以支持預期的變化例如，為了支持產(chǎn)品線體系結構，產(chǎn)品影響因素的一個例子是，圖形用戶界面需要能夠對不同應用程序適應于不同類型的用戶產(chǎn)品因素一般包括以下幾類P1——功能P2——用戶界面P3——性能P4——可信賴性P5——故障檢測、報告、恢復P6——服務P7——產(chǎn)品成本P8——可維護性產(chǎn)品的影響因素產(chǎn)品因素包括產(chǎn)品的功能及質量，例如性能、可信賴對項目計劃采用全局分析全局分析的問題和策略影響著設計和項目計劃的活動需求分析體系結構設計體系結構評估風險分析軟件開發(fā)計劃版本發(fā)布計劃項目策略全局分析市場需求產(chǎn)品因素風險和緩解風險和緩解項目目標進度順序產(chǎn)品因素體系結構描述問題和策略項目策略結論如何做、誰承擔、何時進行模塊視圖組織因素技術因素設計任務項目計劃全局分析在開發(fā)過程中的位置和作用對項目計劃采用全局分析全局分析的問題和策略影響著設計和項目計項目策略決定(1/2)作為項目經(jīng)理，可以采用由全局分析得到的問題和策略作為軟件開發(fā)計劃的輸入計劃應該說明在產(chǎn)品開發(fā)中希望引起注意的所有主要的風險，定義項目策略結論是一種好的方式，用以明確項目的重點和目標，并保持一個簡短的策略列表，使得所有開發(fā)組成員都了解。這些策略應該成為全體開發(fā)組成員的指導原則，有助于定義項目的目標和降低風險項目策略決定(1/2)作為項目經(jīng)理，可以采用由全局分析得到的項目策略決定(2/2)實例：DPS2000項目的一些項目策略決策增量式地開發(fā)DPS2000項目，以保證在期望的開發(fā)階段內完成和發(fā)布一些基本的功能，并開始創(chuàng)收將滿足進度要求作為最高的項目優(yōu)先級。如果需要的話，可以權衡功能來適應發(fā)布日期復用已有產(chǎn)品的構件，購買而不是開發(fā)，以減少必要的新開發(fā)工作量設計策略決定了體系結構的優(yōu)先級和制約條件，有助于確定軟件系統(tǒng)實現(xiàn)有關的潛在風險DPS2000全局分析的結果是確定了24個全局策略，我們驗證這些策略可以解決影響因素。從這24個設計策略中，得到了6個主要的項目策略結論，它們可以作為DPS2000體系結構設計和產(chǎn)品開發(fā)的指導原則項目策略決定(2/2)實例：DPS2000項目的一些項目策略體系結構評估體系結構權衡分析方法（ATAM）是體系結構評估中應用最為廣泛的方法。ATAM根據(jù)非功能性需求評估軟件體系結構，例如可伸縮性、安全性和性能。這些非功能性需求或是質量屬性經(jīng)常是在全局分析產(chǎn)生的因素表中所確定的因素在全局分析中制定的設計和項目策略是ATAM復查小組的好的輸入。隨著有關不同的體系結構風格問題的提出，你可以在復查中討論并確認這些策略體系結構評估體系結構權衡分析方法（ATAM）是體系結構評估中風險分析(1/2)風險由條件、結果以及周圍的環(huán)境構成。在軟件項目計劃方面，風險可能是技術、政治、經(jīng)濟、資源或是其他一些事件，可以對項目開發(fā)、市場占有率或是達到項目目標（如盡速、預算、質量）造成災難性的后果項目經(jīng)理對風險的計劃、預期和反應的技能將直接影響項目的成功。應將風險緩解加入軟件開發(fā)計劃的任務中，以便于減少風險對項目產(chǎn)生負面影響的可能性風險分析試圖定量地分析一個特定的風險發(fā)生的可能性。風險分析工作是收集和考慮全局分析和ATAM復查中得到的問題，或是其他類型的體系結構評估方法得到的問題問題卡片記錄了全局分析得到的問題ATAM簡檔記錄了ATAM得到的風險，通常是由復查小組制作的演示圖風險分析(1/2)風險由條件、結果以及周圍的環(huán)境構成。在軟件風險分析(2/2)當開發(fā)新的產(chǎn)品來取代現(xiàn)有產(chǎn)品時，可能需要一個單獨的風險緩解計劃，既討論技術風險也討論市場風險及相關緩解方案可能的策略：你也許需要對開發(fā)新產(chǎn)品這一計劃保密如果你的用戶都得知了你的項目，他們也許會決定等用新的產(chǎn)品，而不再投資購買現(xiàn)有的產(chǎn)品。這有可能對現(xiàn)有產(chǎn)品的銷售產(chǎn)生負面的影響向用戶保密可能會造成失去及時得到用戶反饋的機會，而要等到最終產(chǎn)品發(fā)布之后產(chǎn)品發(fā)布可能與交易聯(lián)系在一起，這也許需要在發(fā)布之前有一個增量的版本，使得產(chǎn)品可以示范給潛在的用戶風險分析(2/2)當開發(fā)新的產(chǎn)品來取代現(xiàn)有產(chǎn)品時，可能需要一開發(fā)項目策略對問題、風險以及風險緩解的分析有助于制定項目策略及目標。每一個項目應該對滿足進度、質量和功能目標之間的相對優(yōu)先級有一個清楚的說明實例：IS2000項目的項目目標滿足進度要求比質量要求的優(yōu)先級更高，質量要求比功能要求的優(yōu)先級更高項目經(jīng)理對目標的說明：“我必須滿足發(fā)布的進度要求，我的軟件質量看起來不錯，但是我未能提供一些簡單的功能。不管怎樣，讓我們先把產(chǎn)品發(fā)布出去吧。”對項目目標的簡短說明有助于小組成員牢記他們正在努力實現(xiàn)的目標。這些目標應該記錄在軟件開發(fā)計劃中，并根據(jù)需要在開發(fā)過程中加以修改開發(fā)項目策略對問題、風險以及風險緩解的分析有助于制定項目策略全局分析和版本發(fā)布計劃定義了風險、風險緩解和項目目標，這些確實有助于制定版本發(fā)布計劃。因為版本發(fā)布計劃將轉化成關于開發(fā)任務的進度計劃，注意開發(fā)任務的次序將進一步緩解風險在版本發(fā)布計劃的過程中，需要將功能特性映射到工程版本，以描述這些功能的實現(xiàn)序列的計劃全局分析和版本發(fā)布計劃定義了風險、風險緩解和項目目標，這些確全局分析和軟件開發(fā)計劃軟件開發(fā)計劃是用于計劃開發(fā)的主要依據(jù)，并在每一次開發(fā)增量前，由項目經(jīng)理更新由全局分析得到的問題、策略、項目策略結論以及關于風險和可能的緩解計劃的列表均記錄在SDPSDP是一個非常重要的文檔，因為各次工程發(fā)布之間間隔時間并不長，在項目經(jīng)理委托開發(fā)小組按照規(guī)定的發(fā)布日期開發(fā)下一個版本之前，每個小組成員都需要重溫SDP在重溫SDP時，小組成員通常馬上跳到相應的進度表，查看下一個增量版本的任務分配定期地更新文檔使得項目經(jīng)理可以修改、補充或是更好地交流重要的風險和策略全局分析和軟件開發(fā)計劃軟件開發(fā)計劃是用于計劃開發(fā)的主要依據(jù)，對測試計劃采用全局分析系統(tǒng)測試計劃的首要依據(jù)是系統(tǒng)的需求說明。系統(tǒng)的測試小組主要是測試系統(tǒng)能否成功地實現(xiàn)功能需求。因此，他們的興趣主要集中在產(chǎn)品的影響因素上由全局分析得到的問題卡片有助于對測試計劃提供重要的輸入。如果有與產(chǎn)品功能相關的關鍵問題，這些問題是系統(tǒng)測試需要重視的地方例如，對于人為風險高的部分，將會設計更徹底的測試用例對測試計劃采用全局分析系統(tǒng)測試計劃的首要依據(jù)是系統(tǒng)的需求說明內容內容簡介以體系結構為中心的軟件項目計劃全局分析管理項目組織建立項目文化和小組軟件項目經(jīng)理的角色權衡和項目決策增量式開發(fā)創(chuàng)建可視性與避免意外在激烈的競爭中保持冷靜需關注的度量什么是“出色的工作”總結內容內容簡介引子：管理層的期望實例：在IS2000項目中，管理層對于正在設計的軟件體系結構的潛在開發(fā)費用表示擔憂每天都要多次被問及實現(xiàn)所需的工作量有多大，因此不得不在體系結構小組與管理層之間進行交流如果提供的估算值過高，會使管理層感到沮喪；如果提供的估算值過低，會增高期望值，給開發(fā)小組帶來額外的壓力“正確的”答案是一個切實的估算值，這只有在我們有足夠的時間進行需求分析，并提交一份有信心實現(xiàn)的體系結構時才能說明項目經(jīng)理需要合適的時間進行項目計劃，未經(jīng)計劃的軟件項目難以成功實現(xiàn)。項目計劃的活動應在被稱為“項目高層設計階段”的期間進行在項目計劃的過程中管理期望值。如果管理層在項目的開始階段期望正確，則有可能制定切實可行的開發(fā)計劃，并在整個開發(fā)過程中得到支持引子：管理層的期望實例：在IS2000項目中，管理層對于正在何時計劃及何時提交(1/2)對于以體系結構為中心的軟件項目計劃，項目計劃應與體系結構設計并行。大約5%的開發(fā)預算以及20%的開發(fā)時間用于高層設計階段對項目進度和開發(fā)成本進行早期估算，通常給項目經(jīng)理造成很大的壓力在高層設計階段，項目經(jīng)理同體系結構小組的成員一起探究各種情況，在隊伍規(guī)模、進度計劃以及開發(fā)成本之間加以權衡。項目經(jīng)理也同管理層一起探究軟件開發(fā)有關的業(yè)務和組織的限制，但在體系結構設計的過程中，項目經(jīng)理應該只明確各種場景，而不是討論具體的計劃一旦制定、存檔和復查了最初的體系結構設計，項目經(jīng)理就可以考慮提交開發(fā)計劃何時計劃及何時提交(1/2)對于以體系結構為中心的軟件項目計何時計劃及何時提交(2/2)計劃提交是非常關鍵的環(huán)節(jié)經(jīng)理層同意支持項目并提供相應的資源項目經(jīng)理同意按照計劃管理開發(fā)組同意生產(chǎn)產(chǎn)品何時計劃及何時提交(2/2)計劃提交是非常關鍵的環(huán)節(jié)向上的管理(1/2)當項目經(jīng)理正在考慮開發(fā)產(chǎn)品的各種情形和策略，投向結構小組忙于設計體系結構時，管理層通常已經(jīng)迫不及待地想了解開發(fā)的成本及何時可以得到產(chǎn)品。尤其是，市場和銷售經(jīng)理試圖得到任何有關產(chǎn)品功能和可用性的信息，以提供給關鍵的用戶在這種環(huán)境下，非常重要的是對于項目小組正在考慮的各種項目開發(fā)情景的細節(jié)，應限制與外界交流。以使與管理層分離的體系結構小組能夠更好地制定計劃并得到管理層的支持項目經(jīng)理和首席軟件架構師必須完全相信他們能充分實現(xiàn)項目計劃。無論項目經(jīng)理或是首席軟件架構師缺乏這種基本信心，項目都注定要失敗。所有的小組成員都必須在某種程度上也具有這種信心，但他們通常是在項目經(jīng)理和首席軟件架構師的領導之下向上的管理(1/2)當項目經(jīng)理正在考慮開發(fā)產(chǎn)品的各種情形和策向上的管理(2/2)如果項目經(jīng)理認為受到壓力而必須提交一份他認為不可能實現(xiàn)的計劃，那么項目經(jīng)理必須準備離開該項目這一點最好在開發(fā)開始之前就認識到，而不是在開發(fā)失敗、未能達到項目目標后才認識到。如果項目經(jīng)理的管理層不接受他建議的計劃，他最好在高層設計階段結束時離開項目，并推薦任命其他的項目經(jīng)理來接管。如果管理層認識到項目經(jīng)理希望按期完成任務并對其承諾很嚴肅，通常他們愿意接受提交的計劃大多數(shù)的美國項目經(jīng)理努力在小的偏差范圍內達到項目目標，他們傾向于用苛刻的目標挑戰(zhàn)自我及其項目小組，并且在努力實現(xiàn)這些目標的過程中感到滿足項目經(jīng)理是否正確地確定期望，并始終如一地實現(xiàn)承諾，是項目經(jīng)理需要逐漸學會與上級溝通的方法向上的管理(2/2)如果項目經(jīng)理認為受到壓力而必須提交一份他橫向的管理項目經(jīng)理還需管理對等平行機構的期望，這是在開發(fā)過程中需要處理的，包括諸如系統(tǒng)測試、軟件質量管理、用戶文檔、產(chǎn)品管理、市場以及銷售等在很多情況下，項目經(jīng)理需要這些相關功能部門的合作與支持，但是他對其活動不能直接控制和管理。因此，由于缺乏控制權，項目經(jīng)理必須通過增加交流加以補償，以明確項目的需求以及他的期望項目經(jīng)理與支撐功能最常見的交流就是系統(tǒng)測試。采用增量式的開發(fā)方式，項目經(jīng)理需要每4~8周對增量版本進行系統(tǒng)測試另一個重要的接口是負責定義產(chǎn)品功能的人員，他們通常兼有產(chǎn)品管理、市場或系統(tǒng)工程功能。如果這個角色被稱為產(chǎn)品經(jīng)理，項目經(jīng)理需要與他建立密切的工作關系，包括經(jīng)常討論和細化產(chǎn)品計劃或是實現(xiàn)的功能特征橫向的管理項目經(jīng)理還需管理對等平行機構的期望，這是在開發(fā)過程信息流對于項目管理，在高層設計階段，需要管理與項目有關的期望，包括與上級的關系及橫向的交流，在這中間，重要的是管理信息流產(chǎn)品經(jīng)理首席軟件架構師項目經(jīng)理測試經(jīng)理研發(fā)管理層業(yè)務管理層體系結構設計小組特征計劃項目計劃測試計劃項目技術設計信息流對于項目管理，在高層設計階段，需要管理與項目有關的期望內容內容簡介以體系結構為中心的軟件項目計劃全局分析管理期望項目組織建立項目文化和小組軟件項目經(jīng)理的角色權衡和項目決策增量式開發(fā)創(chuàng)建可視性與避免意外在激烈的競爭中保持冷靜需關注的度量什么是“出色的工作”總結內容內容簡介項目組織有多人參與的項目需要加以組織，以使得每一個小組成員都有特定的角色和交流途徑小組成員的技能不同，有些是專家，有些僅是普通技術人員有些是經(jīng)驗豐富的軟件件開發(fā)人員，有些則是新手項目經(jīng)理必須建立好項目的組織結構，以便圓滿地完成任務——產(chǎn)品的開發(fā)有一種方便的方法定義項目的組織，即根據(jù)正在開發(fā)的產(chǎn)品的軟件體系結構項目組織有多人參與的項目需要加以組織，以使得每一個小組成員都利用軟件體系結構定義項目組織體系結構的模塊視圖不僅為項目經(jīng)理提供了一個構件的列表，用以估算開發(fā)成本，還洞察了開發(fā)組織方式模塊視圖描述了軟件系統(tǒng)是如何分解為各個子系統(tǒng)和功能模塊的。我們可以將此視圖映射到項目組織，使項目組織反映體系結構，這有助于在項目中加強體系結構的概念，并根據(jù)小組成員所擅長的工作，分配各自的角色在實際的項目中，體系結構層次圖與項目的組織結構之間不可能是完全的一一對應關系考慮各個小組的規(guī)模，保持在7(±2)個人左右注意在項目組織中，兼職人員數(shù)量以及與此有關的一些問題另外，還要考慮人員之間的人際關系利用軟件體系結構定義項目組織體系結構的模塊視圖不僅為項目經(jīng)理開發(fā)過程中體系結構小組的角色在項目的高層設計階段，開發(fā)小組主要局限于體系結構設計小組和項目經(jīng)理在高層設計結束時，通常需要更大的隊伍來開發(fā)產(chǎn)品，并引入額外的小組成員，參與自底而上的估算。也就在這時，項目經(jīng)理開始組建項目組最好是由可能負責設計和開發(fā)特定功能構件的小組成員負責該構件的估算，這有利于提高進度估算的精確性及對其的承諾，同時有助于彌補小組成員不同的經(jīng)驗水平建立項目小組的一種方法是，在開發(fā)組內部，任命體系結構設計小組的成員作為各開發(fā)小組的負責人對體系結構有更清楚的理解將體系結構知識傳遞到整個開發(fā)組內有助于在開發(fā)中加強體系結構，使得開發(fā)隊伍中的每一個人都了解所實現(xiàn)的構件在整個產(chǎn)品中的作用開發(fā)過程中體系結構小組的角色在項目的高層設計階段，開發(fā)小組主軟件架構師的角色主要職責建立作為產(chǎn)品來實現(xiàn)的體系結構的理念項目的關鍵技術顧問制定技術決策培訓小組成員協(xié)調小組成員的工作實現(xiàn)產(chǎn)品次要職責參與編程軟件架構師的角色主要職責支持功能矩陣在許多組織中，與產(chǎn)品開發(fā)有關的支持功能會以矩陣的形式分配給特定的項目開發(fā)組，這是因為這些功能可能為多個項目組服務，這些服務小組有可能要并行地開發(fā)產(chǎn)品。這對于設計和實現(xiàn)產(chǎn)品線體系結構的組織尤其適用支持功能的分配矩陣對項目經(jīng)理來說是特殊的挑戰(zhàn)，項目經(jīng)理處理功能矩陣分配和管理的最好辦法是通過充分計劃項目經(jīng)理必須提供給支持功能的經(jīng)理產(chǎn)品開發(fā)計劃、對需要提供支持的復雜性和規(guī)模的估算以及有可能出錯的事件項目經(jīng)理必須通知所有的支持功能他們有可能受影響的軟件開發(fā)計劃的細節(jié)當支持功能物理上相隔遙遠時，情況有可能變得更加復雜為了項目的成功，項目經(jīng)理必須與所有矩陣分配的支持功能建立友好的關系和相互信賴支持功能矩陣在許多組織中，與產(chǎn)品開發(fā)有關的支持功能會以矩陣的項目經(jīng)理的權力在矩陣管理中，項目經(jīng)理看起來更類似于員工，而不是生產(chǎn)線的管理者。你對開發(fā)組成員惟一能夠造成實際影響的就是，你會影響其收入及他們在組織中未來的發(fā)展如果與分配到項目組的成員的能力相比，你的手段過于軟弱，并且沒有任何實際的或感覺到的權力，你將很難實現(xiàn)項目目標一些項目經(jīng)理將其權力的大小與其所領導的開發(fā)組的規(guī)模相混淆。非常明確的是，小型開發(fā)隊伍效率更高，因為他們能更方便地交流。因此，為了使你工作更簡單并更有可能實現(xiàn)項目的目標，最好能將隊伍保持在盡可能最小的規(guī)模上項目經(jīng)理的權力在矩陣管理中，項目經(jīng)理看起來更類似于員工，而不系統(tǒng)測試和質量保證稱職的質量保證和系統(tǒng)測試工作可以幫助項目經(jīng)理在用戶之前發(fā)現(xiàn)產(chǎn)品中的錯誤。與軟件測試工作和質量保證工作充分合作，將給項目經(jīng)理帶來最大的利益項目經(jīng)理和測試經(jīng)理需要共同工作，以身作則，以使測試成為建設性的而不是破壞性的工作測試人員發(fā)現(xiàn)的每一個錯誤都使得用戶可以少發(fā)現(xiàn)一個開發(fā)人員有責任復查和處理每一個錯誤，即使還要保留在產(chǎn)品中不能改正，也要使每個錯誤都得到解答項目經(jīng)理還需要與質量保證工作建立起良好的工作關系好的計劃和對項目目標的清晰交流對于保證所有人為共同的目標努力是十分必要的如果項目目標是迅速開發(fā)出低質量的原型產(chǎn)品，以便從最終用戶處得到反饋意見，那么，需要告知QA人員，以便他們相應地調整工作系統(tǒng)測試和質量保證稱職的質量保證和系統(tǒng)測試工作可以幫助項目經(jīng)責任、角色、權限和所有權軟件開發(fā)項目組有幾種主要的角色及職責。除了首席軟件架構師及項目經(jīng)理外，一些重要的角色包括小組負責人開發(fā)人員構造師（buildmeister）系統(tǒng)測試經(jīng)理市場或產(chǎn)品經(jīng)理責任、角色、權限和所有權軟件開發(fā)項目組有幾種主要的角色及職責內容內容簡介以體系結構為中心的軟件項目計劃全局分析管理期望項目組織建立項目文化和小組軟件項目經(jīng)理的角色權衡和項目決策增量式開發(fā)創(chuàng)建可視性與避免意外在激烈的競爭中保持冷靜需關注的度量什么是“出色的工作”總結內容內容簡介引子：團隊文化在對西門子公司的一個軟件開發(fā)組織進行審計的過程中，我發(fā)現(xiàn)他們小組中的每一個成員都認為良好的團隊協(xié)作精神是在那里工作的最突出的特點，其認同的一致性令我驚訝。按照能力成熟度模型（CMM）的等級，這個機構僅處于1級水平，但是，他們的產(chǎn)品得到了用戶的高度評價，其軟件品質優(yōu)良，而且生產(chǎn)效率相對較高由此，我們可以推斷出團隊精神是他們這個機構取得成功的一個關鍵因素引子：團隊文化在對西門子公司的一個軟件開發(fā)組織進行審計的過程確定項目目標(1/2)軟件開發(fā)小組獲取成功的關鍵因素之一就是讓他們清楚地認識到什么是他們必須完成的目標，以及成功的具體標準。這就意味著所確立的項目目標能夠被每一個小組成員了解和接受，并且他們堅信這個目標一定能實現(xiàn)項目目標通常要涉及進度、工作量（成本）、品質和功能等方面的優(yōu)先級要求同時滿足以上幾個方面，即不但要保證產(chǎn)品按時發(fā)送、總的預算不超過預算，還要確保卓越的品質和完整的功能特征，這是不切實際的要求最佳的選擇就是明確什么是最重要的，然后確定一個目標使得在進度、成本、品質和功能四個方面中至少有一個限制程度較低而易于達到要求確定項目目標(1/2)軟件開發(fā)小組獲取成功的關鍵因素之一就是確定項目目標(2/2)舉例，更切實際的項目目標描述我們一定會在截止日期前完成高質量的項目，但是要盡可能多地加入事先討論通過的功能特性，而且無需過分考慮研發(fā)所需費用如果加大工作量能夠確保優(yōu)良的品質和按期完成，那么我們可以考慮增加預算確定項目目標的目的幫助所有組成員了解大家在努力實現(xiàn)什么，并且在每個人權衡決策時，確定其工作重點在達到目標之后，整個小組（以及管理層）能夠意識到成功如果主要目標是一定要按期完成，而且所有人都持續(xù)不懈地為之努力，那么大家就會對項目組的成功有一致的認同確定項目目標(2/2)舉例，更切實際的項目目標描述成功小組的特點(1/3)在成功的小組中，無論什么時候，只要有某個成員遇到了棘手的問題，其他人就會主動伸出援助之手幫助解決通常成功的小組中的人際關系都是十分寬松和舒適的，這一點可以表現(xiàn)在平時相互之間的經(jīng)常地開玩笑和對各自特征善意的打趣成功的小組成員之間能夠取長補短、交換意見，相互沖突的意見也通?？梢缘玫搅⒓刺幚砗蛨A滿解決成功的小組中的成員相互之間都非常了解，通常他們可以預見對方對所提出的建議的反應在他們的主要工作之外，成功的小組中的成員有時候也共同參加其它活動，如一起進餐或參加社交活動成功的小組中的成員都盡職盡責，而且認為這是為圓滿完成任務并對其他成員的一種義務成功小組的特點(1/3)在成功的小組中，無論什么時候，只要有成功小組的特點(2/3)成功小組中的每個人都承諾達到小組的目標在講述有關成就的時候，小組成員通常使用我們而不僅僅是我優(yōu)秀的小組需要一定的時間才能建立起來。人員的變動會阻礙項目的進展，而且新的成員需要一段時間才能融合到小組中被其他人所接受。但是一旦小組明確了新的成員的角色，那么整個集體就會繼續(xù)進步在開始階段，需要有負責人讓大家學會如何成為一個優(yōu)秀的小組。但是，隨著時間的推移，負責人的作用逐漸弱化，更多的將會是小組的自主驅動。此時，負責人更像是一個“教練”而非“導演”小組成員的協(xié)同技能、見解、背景和價值觀等都不盡相同，但是卻可以相互彌補和促進。通常情況下，大家都明確地知道自己的任務和職責成功小組的特點(2/3)成功小組中的每個人都承諾達到小組的目成功小組的特點(3/3)成功的小組還具備了一定的成功經(jīng)驗，這也有助于形成小組的自豪感并且為小組成員樹立信心通常也會有成員曾經(jīng)在其他小組中犯過錯誤，或者曾在不成功的小組中工作優(yōu)秀的小組都堅信能夠圓滿地完成工作任務盡管很容易識別一個成功的小組，但是，建立一個成功的小組要難許多。要想組建軟件開發(fā)小組，使其成為一個未來的成功集體，就需要尤其注意建立適當?shù)捻椖课幕晒π〗M的特點(3/3)成功的小組還具備了一定的成功經(jīng)驗，這建立項目文化每一個成員都知曉項目文化的特點，并且確保此文化與項目目標保持一致信任、公開與交流為了取得項目的成功，小組成員與項目經(jīng)理之間必須是相互信任、彼此公開和經(jīng)常交流的。信任需要經(jīng)過一段時間才能建立，是通過言行一致、承擔責任和兌現(xiàn)諾言等建立起來消除隔閡與文化差異處理個性沖突“懇談會”項目經(jīng)理在這種會議上將工作目標傳達給屬下并提出相應的要求和期望樹立信心只有每個成員都堅信自己能圓滿完成工作任務，整個小組才能獲得最終的成功建立項目文化每一個成員都知曉項目文化的特點，并且確保此文化與內容內容簡介以體系結構為中心的軟件項目計劃全局分析管理期望項目組織建立項目文化和小組軟件項目經(jīng)理的角色權衡和項目決策增量式開發(fā)創(chuàng)建可視性與避免意外在激烈的競爭中保持冷靜需關注的度量什么是“出色的工作”總結內容內容簡介引子：項目經(jīng)理的職業(yè)技能作為一名項目經(jīng)理，他將有機會接觸組織中的很多人：軟件架構師、總工程師、開發(fā)人員、測試人員、銷售經(jīng)理、質量保證專家和用戶等，若想成為一個成功的項目經(jīng)理，必須知曉以上這些人對你的期望以及你應該期待從他們身上獲得什么項目經(jīng)理必須具備的職業(yè)技能優(yōu)秀軟件工程師領導者政治家運動員教練交流者……引子：項目經(jīng)理的職業(yè)技能作為一名項目經(jīng)理，他將有機會接觸組織項目經(jīng)理的角色工作任務具體描述所需技能建立項目理念交流項目成功實現(xiàn)的理念了解市場、業(yè)務氛圍、技術發(fā)展趨勢、先前工作經(jīng)驗、交流溝通、制定目標、收集和統(tǒng)一意見命令、訓練及指導根據(jù)實際情況，給缺乏經(jīng)驗的成員以命令，給經(jīng)驗豐富的成員以指導溝通、感情投入、掌握技術制定決策作出及時的項目決策，保證不阻礙小組成員的工作進展全局分析、溝通、權衡分析、了解市場和政治環(huán)境協(xié)調協(xié)調員工之間必要的交流，并提供管理的支持以避免浪費小組成員的時間時間管理、組織、溝通協(xié)同工作與所有成員通力合作，尤其是與首席軟件架構師小組建設、溝通、收集和統(tǒng)一意見、人際關系、社交、文化交流項目經(jīng)理的角色工作任務具體描述所需技能建立項目交流項目成功實建立一種理念項目經(jīng)理要對成功的項目建立一種理念不能一廂情愿地認為整個開發(fā)過程中的每件事情都會按照計劃順利實現(xiàn)項目經(jīng)理要對有可能存在的主要風險有基本認識，一旦發(fā)生就要選擇適當方案進行應對，以保證項目獲得全部成功項目經(jīng)理要確信這種理念是完全可以實現(xiàn)的作為領導者，這種對于獲取最終成功的堅定信心，會給整個小組帶來積極的影響建立一種理念項目經(jīng)理要對成功的項目建立一種理念訓練隨著整個小組的經(jīng)驗越來越豐富，項目經(jīng)理必須為小組成員做出的指導也越來越少一旦出現(xiàn)這種情形，項目經(jīng)理的角色就應該由指揮員向教練員轉化確保每個小組成員都清楚項目的目標了解每個成員的情況參與指導活動，這是一種對缺乏經(jīng)驗的員工進行訓練和支持的好形式訓練隨著整個小組的經(jīng)驗越來越豐富，項目經(jīng)理必須為小組成員做出決策項目經(jīng)理要為整個項目的發(fā)展方向制定決策，而首席架構師要做出技術方面的決策項目經(jīng)理做出的決策會影響到項目整體，包括進度、成本、品質和功能等方面對于項目小組來講，做決策時最重要的一點就是要有實效性在小組成員等待指導或問題的解決方案時，項目經(jīng)理要做的最重要的事情就是盡快制定決策有些時候，沒有決策還不如做出一個錯誤的決策項目經(jīng)理要做的最重要的決策就是為了滿足用戶需求，是否需要發(fā)布一個新版本的軟件產(chǎn)品到了預定的發(fā)布日期，錯誤永遠都改不完，功能也永遠不能全部完善如果在發(fā)布日期的前一天，測試人員發(fā)現(xiàn)了一個相當嚴重的程序錯誤，那么此時墨菲法則（Murphy’slaw——“凡事可能出岔子，就一定會出岔子”）就會產(chǎn)生效果決策項目經(jīng)理要為整個項目的發(fā)展方向制定決策，而首席架構師要做協(xié)調項目經(jīng)理通常在協(xié)調工作上花費大量的時間將正確的信息傳達給有需要的員工協(xié)調好員工之間的工作以使他們通力合作項目經(jīng)理的工作更像是一個信息經(jīng)紀人他試圖把正確的信息在合適的時間傳遞給員工，使得他們自己做出正確的決策如果對信息的有效性有所懷疑的話，項目經(jīng)理就應該選擇盡力溝通的方法進行解決項目經(jīng)理還要在后勤上花費很多的時間如何打包發(fā)送軟件產(chǎn)品在外地會議期間挑選合適的飯店，……出色的組織能力和對細節(jié)的洞察力對于一個成功的項目經(jīng)理來說是非常重要的協(xié)調項目經(jīng)理通常在協(xié)調工作上花費大量的時間與項目組成員協(xié)同工作項目經(jīng)理能否取得事業(yè)上的成功在很大程度上取決于他所管理的開發(fā)小組的能力和業(yè)績，并同小組項目目標的順利實現(xiàn)緊密聯(lián)系在一起成功的特征包括與具有各種性格的人協(xié)同工作的能力卓有成效的溝通豐富的開發(fā)經(jīng)驗小組合作精神協(xié)同工作首席軟件架構師其他小組成員：當項目進入實現(xiàn)階段之后，高層設計小組的成員很有可能負責主要的子系統(tǒng)；開發(fā)人員有責任在子系統(tǒng)中實現(xiàn)已選定的構件，他們還可能負責代碼開發(fā)以外的其他項目功能，如集成和測試；項目經(jīng)理需要和小組成員充分交流并告知他們具體的責任與項目組成員協(xié)同工作項目經(jīng)理能否取得事業(yè)上的成功在很大程度上與首席軟件架構師協(xié)同工作項目經(jīng)理和首席軟件架構師都是項目獲得成功的必不可少的角色，因此要保持良好的合作關系軟件架構師需要向項目經(jīng)理匯報工作；同時，項目經(jīng)理要信任軟件架構師的能力，并且充分給予他技術方面的權力如果首席軟件架構師缺乏理念和信心，要敢于更換他！工作任務項目經(jīng)理軟件架構師軟件開發(fā)組織項目、管理資源、預算以及進度表圍繞設計及組織小組，管理相互依賴關系需求同市場部門協(xié)商復查需求技術介紹新技術推薦新技術、培訓和工具質量確保產(chǎn)品質量跟蹤設計質量度量生產(chǎn)效率、規(guī)模及質量度量設計度量與首席軟件架構師協(xié)同工作項目經(jīng)理和首席軟件架構師都是項目獲得軟件項目管理是一種職業(yè)(1/2)軟件項目管理對于樂于處于主導位置的軟件工程師們來說是一種很有回報的職業(yè)，他們敢于面對與項目相關的人和未知風險，不會被諸如確定進度表、制定版本發(fā)布標準、協(xié)調各方面工作以及后勤保障等瑣碎的問題所困擾成為一個項目經(jīng)理之后，潛在的負面影響就是有可能對技術方面的問題越來越生疏，因為要投入更多的時間和精力在組織工作上面這也是需要將項目經(jīng)理和軟件架構師分開來成為兩種職業(yè)的原因，對于由眾多開發(fā)人員組成的小組來說，這兩個角色一定要分開、各自獨立每個項目經(jīng)理都應該適當做一些技術工作，或是開發(fā)過程中的一些工作（例如測試人員），或是其引以為樂的工作。但是不能干涉其他成員的正常工作，因為那樣會招來怨恨軟件項目管理是一種職業(yè)(1/2)軟件項目管理對于樂于處于主導軟件項目管理是一種職業(yè)(2/2)此外，項目經(jīng)理要對小組的規(guī)模進行適當調整使得人盡其才、物盡其用，這也會耗費大量的時間把自己從協(xié)調工作中分離出來而匆匆忙忙投入到編寫代碼的工作中，極有可能起到完全相反的作用，因為溝通工作被忽視了，決策不能及時制定，而且后勤也得不到應有的保障認識到項目經(jīng)理所扮演的角色，軟件工程師也許會認為轉行從事項目經(jīng)理的工作不如想象中的那么好，很可能會事倍功半但是如果能夠成功地開發(fā)出一個軟件產(chǎn)品，的確可以獲得與所承擔責任相應的回報。與僅僅參與了一小部分的專業(yè)工作相比，項目經(jīng)理會感覺自己對整個開發(fā)過程產(chǎn)生了更重要的影響軟件項目管理是一種職業(yè)(2/2)此外，項目經(jīng)理要對小組的規(guī)模內容內容簡介以體系結構為中心的軟件項目計劃全局分析管理期望項目組織建立項目文化和小組軟件項目經(jīng)理的角色權衡和項目決策增量式開發(fā)創(chuàng)建可視性與避免意外在激烈的競爭中保持冷靜需關注的度量什么是“出色的工作”總結內容內容簡介引子：權衡和決策在ISO2000這個項目上，遵循開發(fā)計劃對于公司的成功來說至關重要。因此，很多決策都傾向于在分配的時間框架之內實現(xiàn)進度計劃每當項目經(jīng)理試圖實現(xiàn)一個項目的時候，都需要在某些方面進行一些權衡性的決策，包括進度、品質、功能和開發(fā)費用等，而這些決策將影響到項目的開發(fā)過程與結果項目經(jīng)理要認識到?jīng)Q策的原因，并多與項目組成員及管理層交流這些原因，記錄下你所做的決策，這樣，你就能在以后評估這些決策的影響，并在適當?shù)臅r候推翻或者修正這些決策引子：權衡和決策在ISO2000這個項目上，遵循開發(fā)計劃對于根據(jù)項目目標制定決策成功的項目經(jīng)理在做出任何決策時，都必須考慮項目的目標如果你正在開發(fā)一個品質要求非常高的項目——比如說安全性要求很高的軟件，或者一個將被廣泛使用的并難以被替換的嵌入式軟件（例如汽車的控制器）——那么你的絕大多數(shù)決策都應該首先考慮品質因素當品質具有最高優(yōu)先級的時候，你應該將進度和費用設置為相對較低的優(yōu)先級確定清晰、簡單的項目目標，并且讓開發(fā)小組的所有成員都非常了解項目目標，為以后的決策提供依據(jù)如果你的項目的主要目標是有關品質的，而且你的大多數(shù)決策都首先考慮了品質，整個開發(fā)小組就會對你的決策能力和優(yōu)秀的決策樹立起信心，時間長了，組員在制定決策時，也會首先考慮品質問題根據(jù)項目目標制定決策成功的項目經(jīng)理在做出任何決策時，都必須考管理功能蔓延和體系結構漂移(1/3)在實現(xiàn)項目的過程中，項目經(jīng)理總是希望能嚴格按照事先精心策劃的計劃執(zhí)行。不幸的是，事物總是在不斷地變化，完全按照事先的計劃執(zhí)行幾乎是不可能的事實上，靈活性是相當重要的，當業(yè)務和環(huán)境的一些條件改變了，需要快速地對原計劃做出修改。這在產(chǎn)品開發(fā)過程中常會發(fā)生，例如當出現(xiàn)新的要求或者小組成員發(fā)生變化時，就會考慮新的設計方案但是，項目經(jīng)理必須審核各項修改，確保每一個修改都是仔細考慮以后才決定的。項目經(jīng)理就好像是整個開發(fā)組中的保守派，但他自始至終都要意識到，開發(fā)小組一開始執(zhí)行計劃，就可能要對開發(fā)計劃進行修改管理功能蔓延和體系結構漂移(1/3)在實現(xiàn)項目的過程中，項目管理功能蔓延和體系結構漂移(2/3)項目計劃改變的主要原因之一就是需求變化，或稱為需求擾動（requirementschurn）不可能事先確定所有的需求以及需求之間的優(yōu)先級有些需求只有在開發(fā)過程中才會出現(xiàn)，因為這些需求在事先是未知的項目經(jīng)理需要處理每一個修改的請求，以管理需求擾動做這件事的最佳方法是計算出每一個修改所需要的工作成本，這能促使客戶、產(chǎn)品經(jīng)理或市場人員為他們提出的每一個修改制定優(yōu)先級當他們提出一個新的修改要求時，你可以這樣回答：“我們非常樂意增加這個功能來完善我們的產(chǎn)品，但是需要另外增加一些人手來實現(xiàn)這個功能，或者把計劃延長幾個月”不可避免地會出現(xiàn)新的想法以使產(chǎn)品更加完善。你必須心甘情愿地站在一個業(yè)務經(jīng)理的角度上來考慮新想法是否能給你的產(chǎn)品帶來市場上的成功管理功能蔓延和體系結構漂移(2/3)項目計劃改變的主要原因之管理功能蔓延和體系結構漂移(3/3)另一個在開發(fā)過程中可能改變的計劃就是體系結構設計隨著時間的推移，整個項目的體系結構將相對原來的理念有一定的漂移對需求和設計有了更深入的理解沒有與先考慮到正在開發(fā)的產(chǎn)品可能是產(chǎn)品線上的一個部分。新用戶可能需要他們認為“特殊”的新特征，對于這種情況最好的方法是設計一個產(chǎn)品線體系結構管理功能蔓延和體系結構漂移(3/3)另一個在開發(fā)過程中可能改承擔責任項目管理中有一個需要注意的細節(jié)，那就是既要對整個項目負責，又要給每個開發(fā)組成員足夠的自由來制定他自己的決策控制好項目的一個好方法是對項目負責，這意味著所有的項目組員都能明顯地看到項目經(jīng)理對項目的結果負責，所有的組員都相信項目經(jīng)理對項目、組員、產(chǎn)品和項目的最終實現(xiàn)都十分關心假設項目經(jīng)理已經(jīng)承擔起整個項目的職責，每個組員必須承擔起他自己那部分工作的職責如果一個工程師對于他所做的工作并不是很關心，那么工作質量就可能會差一些項目經(jīng)理的職責也包括對組員的工作效率、行為、福利和職業(yè)發(fā)展前景的責任承擔責任項目管理中有一個需要注意的細節(jié)，那就是既要對整個項目何時接受或拒絕修改對項目計劃而言，一個通用的規(guī)則是，最好仔細分析每一個修改的請求并持保留的態(tài)度太多的修改會使開發(fā)組疲于奔命，并可能對任務、計劃和項目目標產(chǎn)生誤解應當將任何一個對于項目修改的重要決策發(fā)布給開發(fā)組的所有成員接受或拒絕某個修改請求的標準只接受那些從費用、品質或銷售前景的角度可以明顯改善產(chǎn)品的修改請求，或者從進度、費用或效率方面可以改善產(chǎn)品的修改請求極端的例子：如果一個項目組成員有一個提議，能夠將產(chǎn)品上市時間縮減到以前的一半，不要覺得這會影響你的計劃，而應當評估這個提議的優(yōu)點和風險，是否做任何違法或者違反道德的事情、是否會對產(chǎn)品的其他方面（如費用、品質等）產(chǎn)生負面影響何時接受或拒絕修改對項目計劃而言，一個通用的規(guī)則是，最好仔細項目經(jīng)理制定道德方面的決策對項目經(jīng)理而言，有一種請求是必須拒絕的會導致項目經(jīng)理或者開發(fā)組的任何成員做出違法或者不道德的事情的請求，否則對項目、公司、個人利益和名譽損失的風險太大。軟件項目經(jīng)理應當注意不要過分貪心到使用違法手段獲利的地步項目經(jīng)理制定道德方面的決策對項目經(jīng)理而言，有一種請求是必須拒內容內容簡介以體系結構為中心的軟件項目計劃全局分析管理期望項目組織建立項目文化和小組軟件項目經(jīng)理的角色權衡和項目決策增量式開發(fā)創(chuàng)建可視性與避免意外在激烈的競爭中保持冷靜需關注的度量什么是“出色的工作”總結內容內容簡介引子在IS2000項目中，鑒于時間和人力的原因，項目組是無法完成市場對產(chǎn)品要求的所有功能的。增量式開發(fā)給我們提供了定義功能版本發(fā)布的另一種途徑，在這一過程中，通過對市場需求的復查，每次實現(xiàn)一小部分功能。這不僅使我們能根據(jù)市場對產(chǎn)品功能的要求來安排各個功能的優(yōu)先級，而且能幫助安排開發(fā)順序，并提供一個可以作為一個軟件包銷售的、最初的優(yōu)先功能集由于產(chǎn)品是按逐個功能開發(fā)的，增量式開發(fā)（又稱迭代式開發(fā)）能減少與需求擾動、上市時間、可用性、質量等相關的風險經(jīng)驗表明，每個版本發(fā)布之間的時間間隔應該為8周或更短。當開發(fā)人員在準備下一個版本時，系統(tǒng)測試人員可以檢查最近的增量版本，并為開發(fā)人員提供測試結果，從而產(chǎn)品的質量能在開發(fā)過程中得到提高引子在IS2000項目中，鑒于時間和人力的原因，項目組是無法建立軟件開發(fā)計劃的基線在軟件開發(fā)計劃（SDP）中的開發(fā)進度表的詳細程度僅適用于第一個增量版本，然后需要重新制定進度表，或是將其作為下一個版本增量開始時的基線對于增量式開發(fā)，這種方法的作用是隨著產(chǎn)品的開發(fā)，項目計劃持續(xù)發(fā)展。當將此SDP設定為基線時，項目經(jīng)理可以考慮自上一個版本以來有了什么改變，什么被實現(xiàn)了而什么被忽略了，哪些風險需要考慮，開發(fā)組或人員需要做怎樣的調整等設定為基線的SDP還可以作為交流工具，以確定影響項目的重大變更。通過建立多個版本的軟件開發(fā)計劃，你能記下整個開發(fā)過程中的項目修改對于每個增量，SDP都有多個版本，這并不意味著改變整個項目目標、主要的里程碑或是產(chǎn)品的功能建立軟件開發(fā)計劃的基線在軟件開發(fā)計劃（SDP）中的開發(fā)進度表讓每一個人都參與工作在開發(fā)一個項目的時候，讓每一個人都在計劃、努力取得成功、達到里程碑的工程中出一份力，這是很重要的制定項目計劃的有效方法：征求開發(fā)組每個成員對計劃的建議或意見，從而使計劃成為整個項目組的計劃如果一個開發(fā)組確信他們能履行計劃，那么，他們就一定能履行計劃。這是一個自行實現(xiàn)的諾言對提議的進度表的反應方式就是：每個小組成員向項目經(jīng)理反饋任何問題，并制定“個人進度表”，確定在進度計劃期間他每周的任務計劃。這就成為每個成員對全力完成進度計劃的“個人承諾”如果對提議的進度表項目經(jīng)理沒有收到反饋，那么他可以認為這個進度表是可行的，而通過采納統(tǒng)一建議和協(xié)商修改而確定的最終的進度表，就成為整個項目組對其管理層承諾，保證在已確定的里程碑日期提交產(chǎn)品讓每一個人都參與工作在開發(fā)一個項目的時候，讓每一個人都在計劃跟蹤工作進展養(yǎng)成一個好習慣：每周都將當前的開發(fā)情況與開發(fā)計劃相比較，這樣使項目經(jīng)理有機會及時采取改正措施，以保證嚴格遵守計劃，最多延遲不超過一周有兩種基本的方法來跟蹤開發(fā)工作進展個人詢問：這可以通過“走訪管理”（managementbywalkingaround）來實現(xiàn)，通過這種方式，可以非正式地詢問每個成員當前項目的開發(fā)情況每周召開例會：組員根據(jù)其個人進度計劃，在會上匯報一周的工作成果。如果每周都在固定的時間召開例會，并且例會的時間比較短，大多數(shù)組員不會感到這個例會特別繁瑣經(jīng)驗：作者常在接近周末的時候安排這種會議，這樣如果有緊急任務必須要馬上完成，組員可以計劃在周末加班跟蹤工作進展養(yǎng)成一個好習慣：每周都將當前的開發(fā)情況與開發(fā)計劃實例：每周例會的目的和議程目的：回顧項目開發(fā)進展情況，在小組成員之間交流信息結果：大家了解了開發(fā)狀況，并針對中間過程的修正提出了行動方案參加者：項目經(jīng)理和所有項目組成員成功的標準：交流了個人的開發(fā)進展，提出了問題，并指明了相應的處理措施時間表：

開始會議，宣布議程：9:30

總體項目進展和相關信息：9:35

個人進展情況匯報：9:45

需要后續(xù)行動的問題：10:15

總結與反饋：10:25

結束：10:30實例：每周例會的目的和議程目的：回顧項目開發(fā)進展情況，在小組增量式測試增量式開發(fā)的一個優(yōu)點就是它支持增量式測試。每當一個工程版本定型后，就可以提交給系統(tǒng)測試。為測試提交的每個版本應當附加一些發(fā)布信息，包括自上一個版本以來的更改列表（新加入的功能和已修正的缺陷）當系統(tǒng)測試正在測試最近的工程版本時，開發(fā)組成員就在開發(fā)下一個版本了。這使得開發(fā)和測試能同時進行。如果測試組能在下一個版本完成以前提供一些測試結果，將會非常有利于下一步的開發(fā)，在下一個版本中就能包括對這些缺陷的修正要在添加新功能的同時保證軟件產(chǎn)品的品質不是一件容易的事。因此，在開發(fā)一個新版本的過程中，保留一些中間測試的結果是很重要的。這樣，開發(fā)人員就能在前一段時間內注重增加新的功能，而在后一段的時間內注重修正缺陷增量式測試增量式開發(fā)的一個優(yōu)點就是它支持增量式測試。每當一個版