Team Software Process - Versionsgeschichte

Ilumeo: /* Funktionsweise */

2021-03-22T19:59:55Z

Funktionsweise

← Nächstältere Version		Version vom 22. März 2021, 21:59 Uhr
Zeile 13:		Zeile 13:

	== Funktionsweise ==		== 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.		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:		Wichtige Konzepte:

Zimt-Speculatius am 4. März 2019 um 10:39 Uhr

2019-03-04T10:39:16Z

← Nächstältere Version		Version vom 4. März 2019, 12:39 Uhr
Zeile 13:		Zeile 13:

	== Funktionsweise ==		== 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 ~~werden~~ 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.		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:		Wichtige Konzepte:

Aniramm am 4. März 2019 um 10:37 Uhr

2019-03-04T10:37:35Z

← Nächstältere Version		Version vom 4. März 2019, 12:37 Uhr
Zeile 13:		Zeile 13:

	== Funktionsweise ==		== 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 werden ~~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.		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 werden 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:		Wichtige Konzepte:
Zeile 29:		Zeile 29:

	== Weblinks ==		== Weblinks ==
	* http://www.sei.cmu.edu/tsp/index.cfm
	* Capers Jones: {{Webarchiv \| url=http://namcookanalytics.com/evaluating-ten-software-development-methodologies/ \| wayback=20130915171920 \| text=Evaluating ten software development methodologies}} vom 2. Mai 2013 als snapshot vom 15. September 2013 auf archive.org, abgerufen am 14. Juli 2016		* Capers Jones: {{Webarchiv \| url=http://namcookanalytics.com/evaluating-ten-software-development-methodologies/ \| wayback=20130915171920 \| text=Evaluating ten software development methodologies}} vom 2. Mai 2013 als snapshot vom 15. September 2013 auf archive.org, abgerufen am 14. Juli 2016
	* http://www.processdash.com/		* http://www.processdash.com/

Ocrho: Wikilink erstellt auf SEI

2018-10-23T04:48:25Z

Wikilink erstellt auf SEI

← Nächstältere Version		Version vom 23. Oktober 2018, 06:48 Uhr
Zeile 1:		Zeile 1:
	Der '''Team Software Prozess''' ('''TSP''') ist eine Methode für [[Softwareentwicklung]]steams zur Selbst[[optimierung]].		Der '''Team Software Prozess''' ('''TSP''') ist eine Methode für [[Softwareentwicklung]]steams zur Selbst[[optimierung]].

	Sie wurde von [[Watts S. Humphrey]] am ''Software Engineering Institute'' (SEI) an der [[Carnegie Mellon University]]/[[Pittsburgh]] entwickelt, um den [[Software-Entwickler]]n eine Methode an die Hand zu geben, mit der sie die Anforderungen des [[Capability Maturity Model]] (CMM) konkret umsetzen können.		Sie wurde von [[Watts S. Humphrey]] am [[Software Engineering Institute]] (SEI) an der [[Carnegie Mellon University]]/[[Pittsburgh]] entwickelt, um den [[Software-Entwickler]]n 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.		Für einzelne Entwickler wurde der [[Personal Software Process]] (PSP) entwickelt.

Ocrho: /* Literatur */Herausnahme SM, weil kommt im Originalbuchtitel nicht vor

2018-10-23T04:44:15Z

Literatur: Herausnahme SM, weil kommt im Originalbuchtitel nicht vor

← Nächstältere Version		Version vom 23. Oktober 2018, 06:44 Uhr
Zeile 21:		Zeile 21:

	== Literatur ==		== Literatur ==
	* Watts S. Humphrey: ''TSP~~(SM)~~ - Coaching Development Teams''. Addison-Wesley, 2006, ISBN 0-201-73113-4.		* Watts S. Humphrey: ''TSP - Coaching Development Teams''. Addison-Wesley, 2006, ISBN 0-201-73113-4.
	* Watts S. Humphrey: ''TSP~~(SM)~~ - Leading a Development Team''. Addison-Wesley, 2005, ISBN 0-321-34962-8.		* Watts S. Humphrey: ''TSP - Leading a Development Team''. Addison-Wesley, 2005, ISBN 0-321-34962-8.
	* Watts S. Humphrey: ''Introduction to the Team Software Process~~(SM)~~''. Addison-Wesley, 2000, ISBN 0-201-47719-X.		* Watts S. Humphrey: ''Introduction to the Team Software Process''. Addison-Wesley, 2000, ISBN 0-201-47719-X.

	== Einzelnachweise ==		== Einzelnachweise ==

Ocrho: Typo (Herausnahme SM)

2018-10-23T04:43:04Z

Typo (Herausnahme SM)

← Nächstältere Version		Version vom 23. Oktober 2018, 06:43 Uhr
Zeile 1:		Zeile 1:
	Der '''Team Software Prozess ~~<small>(SM)</small>~~''' (~~kurz~~ '''TSP''' ~~<small>(SM)</small>~~) ist eine Methode für [[Softwareentwicklung]]steams zur Selbst[[optimierung]].		Der '''Team Software Prozess''' ('''TSP''') ist eine Methode für [[Softwareentwicklung]]steams zur Selbst[[optimierung]].

	Sie wurde von [[Watts S. Humphrey]] am ''Software Engineering Institute'' (SEI) an der [[Carnegie Mellon University]]/[[Pittsburgh]] entwickelt, um den [[Software-Entwickler]]n eine Methode an die Hand zu geben, mit der sie die Anforderungen des [[Capability Maturity Model]] (CMM) konkret umsetzen können.		Sie wurde von [[Watts S. Humphrey]] am ''Software Engineering Institute'' (SEI) an der [[Carnegie Mellon University]]/[[Pittsburgh]] entwickelt, um den [[Software-Entwickler]]n 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]] ~~<small>~~(~~SM)</small> (kurz~~ PSP ~~<small>(SM)</small>~~) entwickelt.		Für einzelne Entwickler wurde der [[Personal Software Process]] (PSP) entwickelt.

	== Zielsetzungen ==		== Zielsetzungen ==

Aka: Abkürzung korrigiert, Leerzeichen in Überschrift

2018-03-23T18:47:42Z

Abkürzung korrigiert, Leerzeichen in Überschrift

← Nächstältere Version		Version vom 23. März 2018, 20:47 Uhr
Zeile 5:		Zeile 5:
	Für einzelne Entwickler wurde der [[Personal Software Process]] <small>(SM)</small> (kurz PSP <small>(SM)</small>) entwickelt.		Für einzelne Entwickler wurde der [[Personal Software Process]] <small>(SM)</small> (kurz PSP <small>(SM)</small>) entwickelt.

	==Zielsetzungen==		== Zielsetzungen ==
	Durch die Verwendung von TSP sollen folgende Ziele erreicht werden:		Durch die Verwendung von TSP sollen folgende Ziele erreicht werden:
	* Bessere und genauere Planung (dadurch bessere Erfüllung von geplanten Daten)		* Bessere und genauere Planung (dadurch bessere Erfüllung von geplanten Daten)
Zeile 12:		Zeile 12:
	Laut einer Studie von Capers Jones ist TSP eine der erfolgreichsten Entwicklungsmethoden bezüglich Zeitplanung, Qualität und Budget.<ref>{{cite web\|last=Jones\|first=Capers\|title=Evaluating ten software development methodologies\|year=2013\|url=http://namcookanalytics.com/evaluating-ten-software-development-methodologies/\|archiveurl=https://web.archive.org/web/20130915171920/http://namcookanalytics.com/evaluating-ten-software-development-methodologies/\|archivedate=2013-09-15}}</ref>		Laut einer Studie von Capers Jones ist TSP eine der erfolgreichsten Entwicklungsmethoden bezüglich Zeitplanung, Qualität und Budget.<ref>{{cite web\|last=Jones\|first=Capers\|title=Evaluating ten software development methodologies\|year=2013\|url=http://namcookanalytics.com/evaluating-ten-software-development-methodologies/\|archiveurl=https://web.archive.org/web/20130915171920/http://namcookanalytics.com/evaluating-ten-software-development-methodologies/\|archivedate=2013-09-15}}</ref>

	==Funktionsweise==		== 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 werden 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.		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 werden 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:		Wichtige Konzepte:

2003:ED:3BC5:87A0:55FB:C2E8:B907:CF3: Änderung 173573449 von 2003:ED:3BC5:87A0:55FB:C2E8:B907:CF3 rückgängig gemacht;

2018-02-01T20:43:15Z

Änderung 173573449 von 2003:ED:3BC5:87A0:55FB:C2E8:B907:CF3 rückgängig gemacht;

← Nächstältere Version		Version vom 1. Februar 2018, 22:43 Uhr
Zeile 13:		Zeile 13:

	==Funktionsweise==		==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 werden 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.		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 werden 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:		Wichtige Konzepte:
	* selbstorganisierende Teams (das Team erstellt den Plan)		* selbstorganisierende Teams (das Team erstellt den Plan)
	* agiler Umgang mit Prozessen (das Team reflektiert die Prozesse regelmäßig und verbessert sie)		* 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]])		* Iterative Vorgehensweise (Aufbrechen der Entwicklung in Cycles, analog der Sprints von Scrum)

	== Literatur ==		== Literatur ==

2003:ED:3BC5:87A0:55FB:C2E8:B907:CF3: Wörter "Scrum" im Text mit entsprechendem Wiki-Artikel verknüpft

2018-02-01T20:41:05Z

Wörter "Scrum" im Text mit entsprechendem Wiki-Artikel verknüpft

← Nächstältere Version		Version vom 1. Februar 2018, 22:41 Uhr
Zeile 13:		Zeile 13:

	==Funktionsweise==		==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 werden 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.		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 werden 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:		Wichtige Konzepte:
	* selbstorganisierende Teams (das Team erstellt den Plan)		* selbstorganisierende Teams (das Team erstellt den Plan)
	* agiler Umgang mit Prozessen (das Team reflektiert die Prozesse regelmäßig und verbessert sie)		* 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)		* Iterative Vorgehensweise (Aufbrechen der Entwicklung in Cycles, analog der Sprints von [[Scrum]])

	== Literatur ==		== Literatur ==

Invisigoth67: /* Zielsetzungen */ typo

2017-12-28T16:27:24Z

Zielsetzungen: typo

← Nächstältere Version		Version vom 28. Dezember 2017, 18:27 Uhr
Zeile 10:		Zeile 10:
	* Verbesserung der Qualität des Produktes		* Verbesserung der Qualität des Produktes
	* Niedrigere Kosten von Projekten (Total Cost of Ownership)		* 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 <ref>{{cite web\|last=Jones\|first=Capers\|title=Evaluating ten software development methodologies\|year=2013\|url=http://namcookanalytics.com/evaluating-ten-software-development-methodologies/\|archiveurl=https://web.archive.org/web/20130915171920/http://namcookanalytics.com/evaluating-ten-software-development-methodologies/\|archivedate=2013-09-15}}</ref>		Laut einer Studie von Capers Jones ist TSP eine der erfolgreichsten Entwicklungsmethoden bezüglich Zeitplanung, Qualität und Budget.<ref>{{cite web\|last=Jones\|first=Capers\|title=Evaluating ten software development methodologies\|year=2013\|url=http://namcookanalytics.com/evaluating-ten-software-development-methodologies/\|archiveurl=https://web.archive.org/web/20130915171920/http://namcookanalytics.com/evaluating-ten-software-development-methodologies/\|archivedate=2013-09-15}}</ref>

	==Funktionsweise==		==Funktionsweise==