Contents

Team software process

The initial version of the TSP was developed and piloted by Watts Humphrey in the late 1990s^[5] and the Technical Report^[6] for TSP sponsored by the U.S. Department of Defense was published in November 2000. The book by Watts Humphrey,^[7] Introduction to the Team Software Process, presents a view of the TSP intended for use in academic settings, that focuses on the process of building a software production team, establishing team goals, distributing team roles, and other teamwork-related activities.

Introduction to TSP[edit]

The primary goal of TSP is to create a team environment for establishing and maintaining a self-directed team, and supporting disciplined individual work as a base of PSP framework. Self-directed team means that the team manages itself, plans and tracks their work, manages the quality of their work, and works proactively to meet team goals. TSP has two principal components: team-building and team-working. Team-building is a process that defines roles for each team member and sets up teamwork through TSP launch and periodical relaunch. Team-working is a process that deals with engineering processes and practices utilized by the team. TSP, in short, provides engineers and managers with a way that establishes and manages their team to produce the high-quality software on schedule and budget.

How TSP works[edit]

Before engineers can participate in the TSP, it is required that they have already learned about the PSP, so that the TSP can work effectively. Training is also required for other team members, the team lead and management. The TSP software development cycle begins with a planning process called the launch, led by a coach who has been specially trained, and is either certified or provisional.^[8][9] The launch is designed to begin the team building process, and during this time teams and managers establish goals, define team roles, assess risks, estimate effort, allocate tasks, and produce a team plan. During an execution phase, developers track planned and actual effort, schedule, and defects meeting regularly (usually weekly) to report status and revise plans. A development cycle ends with a Post Mortem to assess performance, revise planning parameters, and capture lessons learned for process improvement.

The coach role focuses on supporting the team and the individuals on the team as the process expert while being independent of direct project management responsibility.^[10][11] The team leader role is different from the coach role in that, team leaders are responsible to management for products and project outcomes while the coach is responsible for developing individual and team performance.^[12][13]

Latest developments[edit]

TSP has been adapted to work with other types of knowledge work, including systems engineering^[14] and services.^[15][16]

Mapping TSP to Capability Maturity Model Integrated (CMMI) practices was documented in 2010,^[17] and piloted as an alternative path to implement CMMI process improvement.^[18][19] A body of knowledge (BOK) was issued in 2010.^[20] The coach mentor program guidebook was released in 2010.^[21]

According to a study by Capers Jones TSP is one of the most successful development methodologies regarding schedule, quality and budget (TCO) ^[22]

Publications[edit]

• TSP: Leading a Development Team 2005
• TSP: Coaching Development Teams 2005

See also[edit]

• Personal software process (PSP)
• Watts Humphrey

References[edit]

External links[edit]

• TSP homepage