In combination with the personal software process (PSP), the team software process (TSP) provides a defined operational process framework that is designed to help teams of managers and engineers organize projects and produce software products that range in size from small projects of several thousand lines of code (KLOC) to very large projects greater than half a million lines of code. The TSP is intended to improve the levels of quality and productivity of a team's software development project, in order to help them better meet the cost and schedule commitments of developing a software system.
The initial version of the TSP was developed and piloted by Watts Humphrey in the late 1990s and the Technical Report for TSP sponsored by the U.S. Department of Defense was published in November 2000. The book by Watts Humphrey, Introduction to the Team Software Process, presents a view 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.
Maps, Directions, and Place Reviews
How TSP works
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. 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. 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.
Software Development Teams Video
Latest developments
TSP has been adapted to work with other types of knowledge work, including systems engineering and services.
Mapping TSP to CMMI practices was documented in 2010, and piloted as an alternative path to implement CMMI process improvement. A body of knowledge (BOK) was issued in 2010. The coach mentor program guidebook was released in 2010.
According to a study by Capers Jones TSP is one of the most successful development methodologies regarding schedule, quality and budget (TCO)
Publications
- TSP: Leading a Development Team 2005
- TSP: Coaching Development Teams 2005
Source of the article : Wikipedia
EmoticonEmoticon