Team Software Process
# Team Software Process

Der Team Software Prozess (TSP) ist eine Methode für Softwareentwicklungsteams zur Selbstoptimierung.

Sie wurde von Watts S. Humphrey am Software Engineering Institute (SEI) an der Carnegie Mellon University/Pittsburgh entwickelt, um den Software-Entwicklern eine Methode an die Hand zu geben, mit der sie die Anforderungen des Capability Maturity Model (CMM) konkret umsetzen können.

Für einzelne Entwickler wurde der Personal Software Process (PSP) entwickelt.

## Zielsetzungen

Durch die Verwendung von TSP sollen folgende Ziele erreicht werden:

* Bessere und genauere Planung (dadurch bessere Erfüllung von geplanten Daten)
* Verbesserung der Qualität des Produktes
* Niedrigere Kosten von Projekten (Total Cost of Ownership)

Laut einer Studie von Capers Jones ist TSP eine der erfolgreichsten Entwicklungsmethoden bezüglich Zeitplanung, Qualität und Budget.

## Funktionsweise

TSP basiert auf PSP, d. h. jeder Entwickler muss PSP anwenden. Auch weitere Teammitglieder wie der Teamlead (analog Scrum Master) und Tester sollten ein spezielles Training erhalten. Jede neues Entwicklungsprojekt beginnt mit dem sogenannten Launch, in diesem wird die Grobplanung zur Erfüllung der Managementziele gemacht (und auch inwiefern diese Ziele nicht erfüllt werden können), das Backlog wird erstellt und eine Detailplanung des nächsten Cycles (der nächsten Iteration / des nächsten Sprints). Die Dauer des Cycles kann zwischen zwei Wochen und drei Monaten liegen. Innerhalb des Cycles wird in regelmäßigen Teammeetings (mind. wöchentlich) der Projektfortschritt besprochen und bei Bedarf der Plan angepasst. Am Ende des Cycles wird der Cycle im sog. PostMortem analysiert (analog der Retroperspektive von Scrum), Probleme besprochen, möglicherweise Verbesserungen für die Zukunft geplant (lessons learned), und der nächste Cycle im Detail geplant. Während des gesamten Projektes sollte ein TSP Coach das Team betreuen.

Wichtige Konzepte:

* selbstorganisierende Teams (das Team erstellt den Plan)
* agiler Umgang mit Prozessen (das Team reflektiert die Prozesse regelmäßig und verbessert sie)
* Iterative Vorgehensweise (Aufbrechen der Entwicklung in Cycles, analog der Sprints von Scrum)
