Editing Personal software process (section)

==Using the PSP==
The PSP is intended to help a developer improve their personal process; therefore PSP developers are expected to continue adapting the process to ensure it meets their personal needs.

===PSP and the TSP===
In practice, PSP skills are used in a TSP team environment. TSP teams consist of PSP-trained developers who volunteer for areas of project responsibility, so the project is managed by the team itself. Using personal data gathered using their PSP skills; the team makes the plans, the estimates, and controls the quality.

Using PSP process methods can help TSP teams to meet their schedule commitments and produce high quality software. For example, according to research by Watts Humphrey, a third of all software projects fail,<ref>Humphrey, Watts S. "Why Big Software Projects Fail: The 12 Key Questions." CrossTalk Mar. 2005 http://www.crosstalkonline.org/storage/issue-archives/2005/200503/200503-Humphrey.pdf {{Webarchive|url=https://web.archive.org/web/20191105150756/http://www.crosstalkonline.org/storage/issue-archives/2005/200503/200503-Humphrey.pdf |date=2019-11-05 }}</ref> but an SEI study on 20 TSP projects in 13 different organizations found that TSP teams missed their target schedules by an average of only six percent.<ref>Davis, Noopur, and Julia Mullaney. The Team Software Process SM (TSP SM) in Practice: A Summary of Recent Results. Pittsburgh, PA: Software Engineering Institute, Sept. 2003.</ref>

Successfully meeting schedule commitments can be attributed to using historical data to make more accurate estimates, so projects are based on realistic plans – and by using PSP quality methods, they produce low-defect software, which reduces time spent on removing defects in later phases, such as integration and acceptance testing.

===PSP and other methodologies===
The PSP is a personal process that can be adapted to suit the needs of the individual developer. It is not specific to any programming or design methodology; therefore it can be used with different methodologies, including [[Agile software development]].

Software engineering methods can be considered to vary from predictive through adaptive. The PSP is a predictive methodology, and Agile is considered adaptive, but despite their differences, the TSP/PSP and Agile share several concepts and approaches – particularly in regard to team organization. They both enable the team to:

* Define their goals and standards.
* Estimate and schedule the work.
* Determine realistic and attainable schedules.
* Make plans and process improvements.

Both Agile and the TSP/PSP share the idea of team members taking responsibility for their own work and working together to agree on a realistic plan, creating an environment of trust and accountability. However, the TSP/PSP differs from Agile in its emphasis on documenting the process and its use of data for predicting and defining project schedules.

===Quality===
High-quality software is the goal of the PSP, and quality is measured in terms of defects. For the PSP, a quality process should produce low-defect software that meets the user needs.

The PSP phase structure enables PSP developers to catch defects early. By catching defects early, the PSP can reduce the amount of time spent in later phases, such as Test.

The PSP theory is that it is more economical and effective to remove defects as close as possible to where and when they were injected, so software engineers are encouraged to conduct personal reviews for each phase of development. Therefore, the PSP phase structure includes two review phases:

* Design Review
* Code Review

To do an effective review, you need to follow a structured review process. The PSP recommends using checklists to help developers to consistently follow an orderly procedure.

The PSP follows the premise that when people make mistakes, their errors are usually predictable, so PSP developers can personalize their checklists to target their own common errors. Software engineers are also expected to complete process improvement proposals, to identify areas of weakness in their current performance that they should target for improvement. Historical project data, which exposes where time is spent and defects introduced, help developers to identify areas to improve.

PSP developers are also expected to conduct personal reviews before their work undergoes a peer or team review.