混合團隊由專家和多面手共同組成。多面手繼續操作一個用例的整個開發過程，支持并處理多個使用例中各部分的專家們一起工作。
優點
● 擁有前兩種方案的優點。
● 外部小組只需要與一小部分專家進行交互。
● 專家們可集中精力從事他們所擅長的工作。
● 各個用例的實現都保持一致。
缺點
● 擁有前兩種方案的缺點。
● 多面手仍然很難找到。
● 專家們仍然不能認識到其他專家的工作并且無法很好地協作，盡管這應該由多面手來調節。
● 項目管理仍然很困難。
成功因素
● 項目團隊成員需要良好的溝通。
● 需要確定公共體系結構。
● 必須適當地定義公共流程、標準和準則。
項目團隊士氣是項目成功的一個因素
大部分項目成功的定義說的是項目如何按時完成、是否在預算內以及是否滿足用戶的需要。但是，在如今要找到好的軟件專業人員都非常困難，更不用說留住他們的這種情況下，還需要將項目成功的定義擴展為包括項目團隊的士氣�？赡茉谂ν瓿梢粋�軟件項目后，不料卻因為壓榨他們過度而失去了重要的開發人員，這樣做可能會符合組織的短期需要，但它對構建一個高效的軟件部門的長遠利益來說肯定是有害的。衡量項目成功與否的一個重要手段是項目結束后團隊的士氣。在項目結束之際，項目團隊的各個成員是否覺得他們從自己的經歷中學到了一些知識、是否喜歡為這次項目工作，以及是否希望參與組織的下一個項目都是非常重要的。
項目規劃技巧
項目計劃技巧對于現今的軟件開發人員來說是必需的。這里有一些幫助您有效地計劃下一個項目的建議。
認識到信心來自規劃的過程，而不是計劃本身。
創建項目計劃會迫使您早在編寫代碼之前就考慮如何構建您的系統——減少項目的風險，因為您已經考慮了各種策略和方法并且已經選擇了最有意義的一項。您的目的不應該只是不花氣力產生一個計劃；它應該是一個實際可行的計劃，您可以根據它來成功管理您的項目。
軟件過程推動計劃的開發
每個軟件過程都有一個不同的集合，它包括組織團隊的活動方法以及規劃項目常用的技術。由于這個原因，基于 Rational Unified Process (RUP)的項目規劃不同于OOSP項目的規劃，而OOSP項目的規劃也不同于eXtreme Programming (XP) 項目的規劃。不同的過程有不同的計劃。
從粗粒度的計劃開始
在項目將要開始時，應該制定一個粗粒度的、確定項目高級活動和預期里程碑的計劃。粗粒度的計劃將組織成迭代——根據項目的大小和性質，每次迭代通常在三周到八周之間發生（四周到六周為更佳）。其中一些迭代將集中在項目初期，而很多迭代將集中在整個應用的功能部分開發，還有一些迭代集中在將您的系統轉變成產品。
實施者應該是計劃人員
創建項目計劃的最佳人員是負責實施該計劃的人員。當規劃由一個人創建而由另一個人實施時，如果項目不能按時完成或超出預算，他們不太會相信計劃，而很有可能會責備它。也就是說，參與項目的每個人都應該投入到項目計劃的開發和進展中。
不要忘記“不該忘記的事”
計劃不僅要反映需求設計、建模、編程和測試的“真實”工作，而且還應該反映輔助活動（然而仍是重要的），它包括：休假和法定假日、培訓和教育、項目管理活動（如規劃和人員管理）、開銷（如系統當機時間、會議和回復電子郵件）、體系結構定義、測試之后的系統返工、系統交付、與重用相關的活動（如普遍化 ）。
將任何設想和約束編入文檔
規劃時您總要作一些假設，如能夠及時獲得應用程序服務器的新發行版，或可以得到熟悉您正在應用的技術和技巧的開發人員。同時，您將在一些約束下工作，如影響計劃的強制截止期限或資源限制。將這些假設和約束編入文檔，這樣，當您實施項目的任何時候更新計劃時，都可以記起您先前做出的一些“不尋�！睕Q定。
認識到不同的資源意味著不同的計劃
十名有經驗的開發人員組成的團隊創造出的成效要遠遠多于十名初學者組成的團隊所創造的成效。要想更加實際的話，您的計劃必須反映項目可使用的資源的真實情況。
創建現實的計劃
項目組必須相信其項目的目的、估價和時間表。要做到這點，您必須真實地規劃，避免規劃超出您能理解的范圍。僅當您打算研究未知事項時，才能容忍無知。
只規劃有價值的事
IBM DeveloperWorks 網站提供了許多可應用于您項目的最佳實踐。然而，根據項目的性質，不是所有這些技術都將適合于您的獨特情況。要將這些最佳實踐簡單地看作是您放置在“項目管理工具箱”中的工具，您可以根據需要適當使用這些工具。
適當使用項目管理工具
一些項目管理工具，如 Microsoft Project，提供了重要功能， 如Gantt圖表（活動時間表）的開發、規劃與實際結果的比較、PERT 圖表（網絡圖表）的開發、任務的定義、任務之間相關性的定義、對任務的資源分配和資源平衡。所有這些事情似乎象是一個好主意，并且它們通常是好主意——但它們還需要許多精力來創建和維護，而且很少為項目組提供實際價值。的確，它讓一些項目管理人員感到富有成效。的確，高級管理喜歡看見您有一個計劃。但是，沒有一行代碼是由所有這個活動產生的。規劃是有價值的活動；但投入大量的時間來創建規劃圖表通常不是有價值的活動。
謹慎應用技術方案處理管理問題
對于在項目中遇到的問題，您確信需要用技術來解決嗎？本文改編自作者所著的Process Patterns 的第五章，Scott Ambler建議改進管理，而不是新技術，可能就是您的解決方案。
還沒有一種點能表明用部署最新技術中來解決通過改變管理實踐去解決問題的（請參閱參考資料中 The Squandered Computer）。事實上是，您不應該將所有商業過程所得的好處都歸功于支持這些更改的軟件項目。沒有這些新的軟件或硬件，您可能會得到同樣的好處。
將技術解決方案識別成非技術問題是經常重復發生在信息技術界的常見錯誤。這種經常發生的錯誤將其看成是稱作 Apply Technical Solution to Non-Technical Problem（將技術解決方案應用到非技術問題）自身的過程反模式（過程反模式是一種已證明在實際運行當中并不是行之有效的方法）。
技術解決方案僅適用于解決技術問題。例如，“網絡計算機”的概念仍然是計算機界中熱衷的時尚。其基本概念就是通過網絡計算機來替代個人計算機，組織就可以大大縮減支持計算機軟硬件的開支。
研究表明，如果包括培訓和支持這些計算機費用的話，那每年支持一臺個人計算機的平均開支大約在 $5,000 到 $30,000 之間。網絡計算機（也稱之為 Java 終端，因為它們僅運行已經打包成 Java 字節代碼的程序）理論上將縮減開支，因為它們僅需要簡單的維護和支持。盡管做了大量的廣告宣傳，但迄今為止，網絡計算機的銷售量十分可憐。從表面上看，網絡計算機試圖解決的問題看起來是技術性的。但當您想到這一點的時候，問題實際已經成為管理問題之一了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
