チームソフトウェアプロセス

チーム ソフトウェア プロセス ( TSP ) は、パーソナルソフトウェア プロセス( PSP)と組み合わせて、マネージャーとエンジニアのチームがプロジェクトを編成し、数千行のコード (KLOC) の小規模プロジェクトから 50 万行を超えるコードまでの非常に大規模なプロジェクトまで、さまざまな規模の製品用のソフトウェアを作成するのに役立つように設計された、定義された運用プロセス フレームワークを提供します。TSP は、チームのソフトウェア開発プロジェクトの品質と生産性のレベルを向上させ、ソフトウェア システムの開発にかかるコストとスケジュールのコミットメントをより適切に満たすことを目的としています。^{[1] [2] [3] [4]}

TSP の最初のバージョンは、1990 年代後半に Watts Humphrey によって開発され、試験運用されました^[5] 。TSP の技術レポート^[6]は、米国国防総省の後援を受けて 2000 年 11 月に発行されました。Watts Humphrey の著書「チーム ソフトウェア プロセス入門」^[7] では、学術的な環境での使用を目的とした TSP の考え方が紹介されており、ソフトウェア制作チームの構築、チーム目標の設定、チームの役割の分配、その他のチームワーク関連のアクティビティのプロセスに焦点を当てています。

TSP の主な目標は、自主的なチームを確立して維持し、PSP フレームワークの基盤として規律ある個々の作業をサポートするためのチーム環境を作成することです。自主的なチームとは、チームが自らを管理し、作業を計画して追跡し、作業の品質を管理し、チームの目標を達成するために積極的に取り組むことを意味します。TSP には、チーム構築とチーム作業という 2 つの主要なコンポーネントがあります。チーム構築は、各チーム メンバーの役割を定義し、TSP の起動と定期的な再起動を通じてチーム作業を確立するプロセスです。チーム作業は、チームが使用するエンジニアリング プロセスとプラクティスを扱うプロセスです。つまり、TSP は、エンジニアとマネージャーに、スケジュールと予算内で高品質のソフトウェアを作成するためにチームを確立して管理する方法を提供します。

エンジニアがTSPに参加するには、TSPが効果的に機能できるように、PSPについてすでに学習している必要があります。他のチームメンバー、チームリーダー、および経営陣のトレーニングも必要です。TSPソフトウェア開発サイクルは、特別にトレーニングを受けた認定または暫定的なコーチが主導するローンチと呼ばれる計画プロセスから始まります。^{[8] [9]} ローンチはチーム構築プロセスを開始するために設計されており、この期間中にチームとマネージャーは目標を設定し、チームの役割を定義し、リスクを評価し、労力を見積もり、タスクを割り当て、チーム計画を作成します。実行フェーズでは、開発者は計画された労力と実際の労力、スケジュール、および欠陥を追跡し、定期的に（通常は毎週）会議を開いて状況を報告し、計画を修正します。開発サイクルは、パフォーマンスを評価し、計画パラメータを修正し、プロセス改善のために学んだ教訓を記録するポストモーテムで終了します。

コーチの役割は、直接的なプロジェクト管理の責任から独立しながら、プロセスの専門家としてチームとチーム内の個人をサポートすることに重点を置いています。^{[10] [11]}チームリーダーの役割は、チームリーダーが製品とプロジェクトの結果について経営陣に責任を負い、コーチが個人とチームのパフォーマンスを向上させる責任を負うという点で、コーチの役割とは異なります。^{[12] [13]}

TSPは、システムエンジニアリング^{[14]やサービス[ 15]を含む他の種類の}知識労働にも適応できるように適応されています 。 [16]

TSPを能力成熟度モデル統合（CMMI）プラクティスにマッピングする手法は2010年に文書化され、^[17] CMMIプロセス改善を実装するための代替パスとして試験的に導入されました。^{[18] [19]} 知識体系（BOK）は2010年に発行されました。^[20]コーチメンタープログラムガイドブックは2010年にリリースされました。^[21]

ケイパーズ・ジョーンズの研究によると、TSPはスケジュール、品質、予算（TCO）に関して最も成功した開発手法の一つである^[22]

• TSP: 開発チームのリーダーシップ 2005
• TSP: コーチング開発チーム 2005

• パーソナルソフトウェアプロセス（PSP）
• ワッツ・ハンフリー

• TSPホームページ