I am pullling this one from my archive mails. I attended this training almost a 10 moths ago. Here it goes ...

What is PSP?

 In a nutshell: A “common sense” – a self disciplined approach to work at an individual level.

 The important elements of PSP  

  1. Plan your work – Irrespective of size and complexity of unit of work, have a plan – documented plan is recommended.  
  2. Estimate the size of work – For developers – it is LOC ( could be function points or any other size measures)  – Use Historical data.

Gaps I see in PSP: Nothing specific for testers. Complexity is not considered as a parameter 

  1. Estimate the effort - how much time it takes to do the work Gaps I see in PSP – Complexity is not considered as a parameter.  
  2. Schedule the work – Have an idea of finishing time/date.  
  3. Log your time – This is the most important aspect of PSP, without this all the rest becomes meaningless. PSP recommends Logging time in “Minutes”. This looks not feasible at least to start with.  
  4. Be watchful about Quality – Manage the defects create/injected by you. Be open and pragmatic about number, types of bug/defect. Track “Phase injected” and “Phase removed”. An ideal situation would be that these two events happen in same phase of SDLC if not “as close” to as possible.

Gaps I see: PSP is heavily dev oriented - there are no major/specific “mentions” about test in PSP core material. Terms like “defect injection” does not apply to test as test does not inject any defects per se. However, one could interpret that a defect missed by test is equivalent to “defect injected” – proper terminology needs to be in place. I am not sure of any tailored versions of PSP for test as of now. Need to take the initiative to bring this matter with SEI and suggest suitable amendments to include test related issues. Same may hold good for “support” related roles and teams.

  1. Have/Devise formal review mechanism for Review – Every phase in SDLC ideally should end with Review and corrective action so that point No 6 is taken care of. Device efficient checklists to guide and bring consistency in review. Every review should aim at improving checklists. Use Defect data collected in Point No 6 as prime input for design of checklists – concentrate on “typical mistakes made”.


How about TSP:

                        It is about a team at work – A team that consists of PSP trained/practicing individuals with a shared common goal and an established communication protocol.

            TSP strives to make every team a “successful” team.   

            Pre-requisite: All the team members should have undergone 10day “PSP” training.

             Note: TSP is not suitable for teams consisting of 2-3 people and those projects of 1-1.5 month’s duration.

            1.       Clearly defined roles - agreed upon during TSP launches.

 2.       TSP launches and Re-launches –  Key events that happen ( lasts for about 4 days) in a TSP. Team decides upon roles for individuals in the team – there are eight such roles that team should decide ( details are in training material). One person can play multiple roles.

 3.       TSP re-launches happen when there is significant change happens for the project changes – like major scope changes, few new members getting added to team and so on.

 4.       Rest of activities like time tracking, Defect tracking, and review – keep happening at individual level.

             5.       A coach or guide – guides the team throughout the project cycle.

 PSP/TSP vis-à-vis Stadandard Quality models like – CMM or six sigma

            Standard quality models are at Organization level – attempt to achieve higher levels of Customer satisfaction and improved productivity – A top down approach.

PSP/TSP attempt to inculcate these at individual level and team level respectively - A bottom up approach.  Both of these can co-exist.