The document discusses Team Software Process (TSP) and Personal Software Process (PSP) for building effective development teams. It describes how TSP uses a series of workshops called a "launch" to establish team goals, roles, processes and a project plan. Individuals use PSP for self-management and improvement to become effective team members. The workshops cover requirements, role assignment, process definition, planning, quality, risk assessment and project execution.

1. Development Team Building ( Team Software Process™/Personal Software Process™ ) Presented by : Frédérick Lussier November 2009, version 1.2 tm Personal Software Process, PSP and Team Software Process, TSP are service marks of Carnegie Mellon University ® Capability Maturity Model, Capability Maturity Modeling, Carnegie Mellon, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

23. Workshop 2 – Assign roles and define team goals Roles summary (1/5)

24. Workshop 2 – Assign roles and define team goals Roles summary (2/5) The test manager is not necessarily an official tester in your organization. If you want to introduce a new unit test methodology, it would be preferable to assign the tester manager role to a unit test “expert”; so it could be a developer.

25. Workshop 2 – Assign roles and define team goals Roles summary (3/5)

26. Workshop 2 – Assign roles and define team goals Roles summary (4/5) Your team leader is too busy to be responsible for quality. If nobody is in charge of quality, then nobody will take time to make things right.

27. Workshop 2 – Assign roles and define team goals Roles summary (5/5) Use title names that have meanings for you.

32. Workshop 3 – Produce development process and strategy Agile adaptation Test Integration, non regression and functional test execution Plan Tests and design Design review and inspection Code Code review and inspection Code analysis Tests execution Post mortem Requirements and spec. Customer requirements, Technical requirements, Story, Acceptance test, Prioritized “backlog” High level architecture and design Conceptual design , Interfaces, Scenario, Use case, ... Release 1 Rel. 2 Rel. n Iteration1 Iteration 2 ... ... Regular project status meeting Validation Acceptance test Continuous integration Implementation Preparation, demonstration and installation Daily standup meeting Environment War room, Servers, Continuous integration, Development tools, Tests environment, Processes, Standards, Training, ... Iteration 3 Architecture Team vision Iteration 0 Coach Cycle

49. Performance data The Team Software Process (TSP) in Practice: A Summary of Recent Results CMU/SEI-2003-TR-014 and CMU/SEI-2000-TR-015 We developed a 450 KLOC business operating system in 55 000 hours. We delivered it on time. The customer reported 17 bugs for a total defect density of 0.038 bugs/KLOC. Gerardo López, Towa, CEO & President TSP Symposium 2008 1/3 of projects have no defects Measures With TSP average min. – max. Typicalproject System test defects (defects/KLOC) 0.4 0 to 0.9 15 Released defects (defects/KLOC) 0.06 0 to 0.2 7.5 System test effort (% of total effort) 4% 2% to 7% 40% System test schedule (% of total duration) 18% 8% to25% 40% Duration of system test (days/KLOC) 0.5 0.2 to 0.8 5 1 to 7.7 Unit Test - cost of quality 17% 4% to 38% 50% Project schedule error 6% -20% to 27% 180% Measures Average Productivity improvement 78%

51. Thank you for your attention