團隊軟體過程（Team Software Process，簡稱 TSP）
什麼是團隊軟體過程
團隊軟體過程是為開發軟體產品的開發團隊提供指導，TSP的早期實踐側重於幫助開發團隊改善其質量和生產率，以使其更好的滿足成本及進度的目標。TSP被設計為滿足2~20人規模的開發團隊，大型的多團隊過程的TSP被設計為大約最多為150人左右的規模。
團隊軟體過程(TSP)加上PSP幫助高績效的工程師在一個團隊中工作，來開發有質量保證的軟體產品，生產安全的軟體產品，改進組織中的過程管理。通過TSP，一個組織能夠建立起自我管理的團隊來計畫追蹤他們的工作、建立目標，並擁有自己的過程和計畫。這些團隊可以是純粹的軟體開發團隊，也可以是集成產品的團隊，規模可以從3到20個工程師不等。TSP團隊在廣泛領域裡可能運用XP, RUP或其它方法。TSP使具備PSP的工程人員組成的團隊能夠學習並取得成功。如果你的組織運用TSP，它會幫助您的組織建立一套成熟規範的工程實踐，確保全全可靠的軟體。
TSP團隊軟體過程
軟體過程控制是軟體企業成功的關鍵，但過去一直缺乏一套可操作的規範來具體指導和規範項目組的開發。PSP和TSP為企業提供了規範軟體過程的一整套方案，從而解決了長期困擾軟體開發的一系列問題，有助於企業更好地應對挑戰。PSP主要指導軟體工程師個人如何更好地進行軟體設計與編碼，關注個人軟體工程師的能力的提高，從而保證個人承擔的軟體模組的質量，對於大型項目中的項目組如何協同工作、共同保證項目組的整體產品質量則沒有給出任何指導性的原則。個人能力的提高同時需要一個有效地工作在一個團體(小組)環境，並知曉如何一致創造高質量的產品。為了提高團隊的質量及生產能力，更加精確地達到費用、時間要求，結合PSP的原則提出了TSP以提高小組的性能，從而提供工程質量。TSP能夠指導項目組中的成員如何有效地規劃和管理所面臨的項目開發任務並且告訴管理人員如何指導軟體開發隊伍始終以最佳狀態來完成工作。
團隊軟體過程TSP基於以下4條基本原理：
- 應該遵循一個確定的、可重複的過程並迅速獲得反饋，這樣才能使學習和改革最有成效；
- 一個群組是否有效，是由明確的目標、有效的工作環境、有能力的教練和積極的領導這4方面因素的綜合作用所確定的，因此應在這4個方面同時努力，而不能偏廢其中任何—個方面；
- 應注意及時總結經驗教訓，當學員在項目中面臨各種各樣的實際問題並尋求有效的解決問題方案時，就會更深刻地體會到TSP的威力；
- 應注意借鑑前人和他人的經驗，在可知利用的工程、科學和教學法經驗的基礎上來規定過程改進的指令。
在軟體開發(或維護)過程中，首先需要按照群組軟體過程框架定義—個過程。在設計TSP過程時，需要按照以下7條原則：
- 循序漸進的原則，首先在PSP的基礎上提出一個簡單的過程框架，然後逐步完善；
- 疊代開發的原則，選用增量式疊代開發方法，通過幾個循環開發—個產品；
- 質量優先的原則，對按TSP開發的軟體產品，建立質量和性能的度量標準；
- 目標明確的原則，對實施TSP的群組及其成員的工作效果提供準確的度量；
- 定期評審的原則，在TSP的實施過程中，對角色和群組進行定期的評價；
- 過程規範的原則，對每一個項目的TSP規定明確的過程規範；
- 指令明確的原則，對實施TSP中可能遇到的問題提供解決問題的指南。
在實施群組軟體過程TSP的過程中，應該自始至終貫徹集體管理與自我管理相結合的原則。具體地說，應該實施以下6項原則：
- 計畫工作的原則，在每一階段開始時要制訂工作H劃，規定明確的目標；
- 實事求是的原則，目標不應過高也個應過低而應實事求是，在檢查計畫時如果發現未能完成或者已經超越規定的目標，應分析原因，並根據實際情況對原有計畫做必要的修改；
- 動態監控的原則，一方面應定期追蹤項目進展狀態並向有關人員匯報，另一方面應經常評審自己是否按PSP原理進行工作；
- 自我管理的原則，開發小組成員如發現過程不合適，應主動、及時地進行改進，以保證始終用高質量的過程來生產高質量的軟體，任何消極埋怨或坐視等待的態度都是不對的；
- 集體管理的原則，項目開發小組的全體成員都要積極參加和關心小組的工作規劃、進展追蹤和決策制訂等項工作；
- 獨立負責的原則，按TSP原理進行管理，每個成員都要擔任一個角色。
在TSP的實踐過程中，TSP的創始人Humphrey建議在—個軟體開發小組內把管理的角色分成客戶界面、設計方案、實現技術、工作規劃、軟體過程、產品質量、工程支持以及產品測試8類。如果小組成員的數目較少，則可將其中的某些角色合併；如果小組成員的數目較多，則可將其中的某些角色拆分。總之，每個成員都要獨立相當一個用色。
軟體開發小組按TSP進行生產、維護軟體或提供服務，其質量可用兩組元素來表達；一組元素用以度量開發小組的素質，稱之為開發小組素質度量元；另一組用以度量軟體過程的質量，稱之為軟體過程質量度量元。
開發小組素質的基本度量元有以下5項：
- 所編文檔的頁數；所編代碼的行數；
- 花費在各個開發階段或花費在各個開發任務上的時間(以分鐘為度量單位)；
- 在各個開發階段中注入和改正的缺陷數目；
- 在各個階段對最終產品增加的價值。
應該指出，這5個度量元是針對軟體產品的開發來陳述的，對軟體產品的維護或提供其他服務，可以參照這些條款給出類似的陳述。
軟體過程質量的基本度量元有以下5項：
- 設計工作量應大於編碼工作量；
- 設計評審工作量應占一半以上的設計工作量；
- 代碼評審工作量應占一半以上的代碼編制的工作量；
- 每千行源程式在編譯階段發現的差錯不應超過10個；
- 每千行源程式在測試階段發現的差錯不應超過5個。
無論是開發小組的素質，還是軟體過程的質量，都可用一個等五邊形來表示，其中每一個基本度量元是該等五邊形的一個頂。基本度量元的實際度量結果，落在其頂點與等五邊形中心的連線上，其取值可以根據事先給出的定義來確定。在套用TSP時，通過對必要數據的收集，項目組在進入集成和系統測試之前能夠初步確定模組的質量。如果發現某些模組的質量較差，就應對該模組進行精心的複測，有時甚至有必要對質量特別差的模組重新進行開發，以保證生產出高質量的產品，且能節省大量的測試和維護時間。
TSP的結構
TSP由一系列階段和活動組成。各階段均由計畫會議發起。在首次計畫中，TSP組將制訂項目整體規劃和下階段詳細計畫。TSP組員在詳細計畫的指導下跟蹤計畫中各種活動的執行情況。首次計畫後，原定的下階段計畫會在周期性的計畫制訂中不斷得到更新。通常無法制訂超過3到4個月的詳細計畫。所以，TSP根據項目情況，每3-4個月為一階段，並在各階段進行重建。無論何時，只要計畫不再適應工作，就進行更新。當工作中發生重大變故或成員關係調整時，計畫也將得到更新。在計畫的制訂和修正中，小組將定義項目的生命周期和開發策略，這有助於更好地把握整個項目開發的階段、活動及產品情況。每項活動都用一系列明確的步驟、精確的測量方法及開始、結束標誌加以定義。在設計時將制訂完成活動所需的計畫、估計產品的規模、各項活動的耗時、可能的缺陷率及去除率，並通過活動的完成情況重新修正進度數據。開發策略用於確保TSP的規則得到自始至終的維護。圖1中描述的只是TSP階段、活動的標準集合，實際的TSP更像是分成階段的眾多循環構成的。TSP過程遵循互動性原則，以便每—階段和循環都能在上一循環所獲信息的基礎上得以重新規劃。
本條目在以下條目中被提及
- CMMI
- 項目管理
