„Team Software Process“ – Versionsunterschied

Versionsgeschichte interaktiv durchsuchen

[gesichtete Version]

← Zum vorherigen Versionsunterschied Zum nächsten Versionsunterschied →

Inhalt gelöscht Inhalt hinzugefügt

Inline

Version vom 23. März 2018, 20:47 Uhr

Der Team Software Prozess (SM) (kurz TSP (SM)) 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 (SM) (kurz PSP (SM)) 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.^[1]

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.

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)

Literatur

Watts S. Humphrey: TSP(SM) - 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: Introduction to the Team Software Process(SM). Addison-Wesley, 2000, ISBN 0-201-47719-X.

Einzelnachweise

↑ Capers Jones: Evaluating ten software development methodologies. 2013, archiviert vom Original am 15. September 2013; abgerufen im 1. Januar 1.

Weblinks

http://www.sei.cmu.edu/tsp/index.cfm
Capers Jones: Evaluating ten software development methodologies (Memento vom 15. September 2013 im Internet Archive) vom 2. Mai 2013 als snapshot vom 15. September 2013 auf archive.org, abgerufen am 14. Juli 2016
http://www.processdash.com/

[1] Capers Jones: Evaluating ten software development methodologies. 2013, archiviert vom Original am 15. September 2013; abgerufen im 1. Januar 1.

[1]

@@ Zeile 5: / Zeile 5: @@
 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:
 * 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>
-==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.&nbsp;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: