توسعه تیم‌های مربی‌گری TSP(SM)

most Modern Software Development Projects Require Teams, And Good Teamwork Largely Determines A Project’s Success. The Team Software Process (tsp), Created By watts S. Humphrey, Is A Set Of Engineering Practices And Team Concepts That Produce Effective Teams, Thereby Helping Developers Deliver High-quality Products On Time And Within Budget. Tsp Bridges Humphrey’s Seminal Work On The Capability Maturity Model (cmm), An Improvement Framework For The Entire Software Organization, And His Personal Software Process (psp), Practices Designed To Improve The Work Of Individual Developers. typical First-time Tsp Teams Increase Productivity By More Than 50 Percent While Greatly Increasing The Quality Of Their Delivered Products. However, Tsp Teams Only Continue To Improve Under The Guidance Of A Capable Coach. One Industrial-strength Team, For Example, Increased Its Productivity By An Additional 94 Percent And Reduced Test Defects By 85 Percent Through Three Consecutive Tsp Quarterly Product Release Cycles. Without Competent Coaching, Teams Often Do Not Progress Much Beyond The Initial One-time Improvement Seen After The Introduction Of The Tsp. humphrey Distinguishes Between Tsp Coaching And Tsp Leadership, Explaining Why The Skillful Performance Of Both Functions Is Critical. In This Practical Guide, He Shares Coaching Methods That Have Repeatedly Inspired Tsp Teams And Steered Them Toward Success. With The Help Of A Coach, Tsp Teams Undergo A Brief But Intense Project Launch In Which They Define Their Own Processes, Make Their Own Plans, And Negotiate Their Commitments With Management, Resulting In Dramatically Enhanced Performance. whether You Are Considering The Tsp Or Are Actively Implementing It, tsp sm –coaching Development Teams Provides The Invaluable Examples, Guidelines, And Suggestions You Need To Get Started And Keep Developing As A Team Coach. It’s Meant To Complement Humphrey’s Other Books, tsp sm –leading A Development Team And psp sm : A Self-improvement Process For Software Engineers. Together, The Three Works Offer A Rich Resource For Improving Your Software Development Capabilities. Contents Preface PART I: TEAM FORMATION Chapter 1 DEVELOPMENT TEAMS 1.1 TSP Overview 1.2 Why Teams Are Needed 1.3 What Are Teams? 1.4 Kinds of Teams 1.5 The Nature of Self-Directed Teams 1.6 The Team Leader and Coach Roles 1.7 Coaching Workload 1.8 Summary Chapter 2 TEAM BEHAVIOR 2.1 The Team Life Cycle 2.2 Kinds of Groups 2.3 Team Styles 2.4 Why Teams Fail 2.5 Summary Chapter 3 THE COACHING JOB 3.1 Coaching Principles 3.2 Launching a TSP Team 3.3 Coaching the Team Members 3.4 Coaching Experienced Teams 3.5 Coaching the Team Leader 3.6 Coaching Management 3.7 Summary Chapter 4 TEAMBUILDING 4.1 What Makes Teams Successful? 4.2 Teambuilding Approaches 4.3 The TSP Teambuilding Strategy 4.4 How the Launch Builds Teams 4.5 Getting Involvement 4.6 Summary PART II: LAUNCHING A TSP TEAM Chapter 5 LAUNCH PREPARATION 5.1 When to Launch a Project 5.2 Team Scope 5.3 Team-Member Selection 5.4 Preparation Topics 5.5 Common Preparation Problems 5.6 Launch Preparation Steps 5.7 Weekly Launch Preparation Status Meeting 5.8 Summary Chapter 6 THE TEAM CHARTER 6.1 Establishing the Team Charter 6.2 The Opening Management Meeting 6.3 Start with a Positive Attitude 6.4 Issues and Considerations 6.5 Summary Chapter 7 TEAM GOALS 7.1 What Goals Are 7.2 The Importance of Feedback 7.3 Goal Priorities 7.4 Measurable Goals 7.5 Kinds of Goal Measures 7.6 The Problem with Measurements 7.7 Kinds of Goals 7.8 The TSP Goal-Setting Process 7.9 Goal Tracking 7.10 A Goal Measurement Example 7.11 Summary Chapter 8 TEAM-MEMBER ROLES 8.1 What Roles Are 8.2 Why Roles Are Needed 8.3 Selecting Team Roles 8.4 The TSP Roles 8.5 Other Team-Member Roles 8.6 Roles and Team Size 8.7 Coaching the Role Managers 8.8 The Role Manager Commitment 8.9 Summary Chapter 9 TEAM PLANNING 9.1 The TSP Planning Process 9.2 Launch Meeting 3 9.3 Product Conceptual Design 9.4 Team Strategy 9.5 The Products to Be Produced 9.6 The Development Process 9.7 Process and Support Plans 9.8 CCB Membership 9.9 Launch Meeting Documentation 9.10 Summary Chapter 10 THE OVERALL PLAN 10.1 Launch Meeting 4 10.2 The Size Estimate 10.3 Determining Project Tasks 10.4 The Overall Resource Estimate 10.5 Resource Availability 10.6 Generating and Assessing the Overall Plan 10.7 Optimum Staffing 10.8 Summary Chapter 11 THE QUALITY PLAN 11.1 The Importance of Quality 11.2 Quality Goals 11.3 The Cost of Defects 11.4 Measuring Software Quality 11.5 Percent Defect Free (PDF) 11.6 Making the Quality Plan 11.7 Summary Chapter 12 DETAILED PLANNING 12.1 How Far Out Should Teams Plan? 12.2 How Detailed Should Plans Be? 12.3 How Plans Can Improve Efficiency 12.4 Whether to Plan Now or to Plan Later 12.5 The Need for Balanced Plans 12.6 The TSP Detailed Planning Process 12.7 Summary Chapter 13 MANAGING RISK 13.1 What Are Risks? 13.2 The Importance of Risk Management 13.3 The Principles of Risk Management 13.4 The TSP Risk Management Process 13.5 Risk Identification 13.6 Risk Evaluation 13.7 The Risk Evaluation Process 13.8 Assigning Risks 13.9 Risk Mitigation 13.10 Risk Management Examples 13.11 Risk Tracking and Management 13.12 Summary Chapter 14 THE MANAGEMENT MEETING 14.1 Preparing for the Management Meeting 14.2 Presenting the Team’s Plan 14.3 Alternative Plans 14.4 Risks 14.5 Closing the Meeting 14.6 Presentation Suggestions 14.7 Summary Chapter 15 THE LAUNCH POSTMORTEM 15.1 The Postmortem Attitude 15.2 The Postmortem Process 15.3 Postmortem Coaching Strategies 15.4 Summary Chapter 16 RELAUNCHING A TEAM PROJECT 16.1 What Is a Relaunch? 16.2 Why Do a Relaunch? 16.3 When to Relaunch 16.4 How to Do a Relaunch 16.5 The Relaunch Process 16.6 Revising the Quality Plan 16.7 A Quality Replanning Example 16.8 Concluding the Relaunch 16.9 Summary PART III: COACHING A TSP PROJECT Chapter 17 POST-LAUNCH COACHING 17.1 Starting New Teams 17.2 The Coaching Process 17.3 The Post-Launch Briefing 17.4 The Weekly Team Meeting 17.5 The Daily Stand-Up Meeting 17.6 The Weekly Status Report 17.7 Coaching Inspections 17.8 Coaching Individuals 17.9 Coaching Role Managers 17.10 Coaching the Team Leader 17.11 The Project Notebook 17.12 The Team-Member Notebook 17.13 The Checkpoint Review 17.14 The Coaching Plan 17.15 Summary Chapter 18 MAINTAINING THE PLAN 18.1 Plan Types 18.2 Plan Dynamics 18.3 Maintaining the Team’s Plan 18.4 A Workload Imbalance Example 18.5 Facing Facts 18.6 When to Update the Plan 18.7 Updating Individual Plans 18.8 Dynamic Load Balancing 18.9 Interpreting Plan Data 18.10 Management Reporting 18.11 Summary Chapter 19 MANAGING QUALITY 19.1 Principles of Quality Management 19.2 Why Manage Quality? 19.3 The Quality Journey 19.4 The Developer’s Responsibility for Quality 19.5 The Team’s Responsibility for Quality 19.6 Quality Management Methods 19.7 Interpreting Quality Data 19.8 Reporting Quality Data 19.9 Defect Reporting Considerations 19.10 Summary Chapter 20 THE PROJECT POSTMORTEM 20.1 The Purpose of the Postmortem 20.2 The Desired Data 20.3 Postmortem Preparation 20.4 The Postmortem Process 20.5 Teamwork Assessment 20.6 Coaching and Leadership Assessment 20.7 Coaching the Postmortem 20.8 The Team-Member Postmortem 20.9 Summary PART IV: TSP EXTENSIONS Chapter 21 TEAM VARIATIONS 21.1 Work Perspectives 21.2 Team Structure 21.3 Team Communication 21.4 Functional Teams 21.5 Distributed Teams 21.6 Multiple Teams 21.7 System-Wide Teams 21.8 Coaching Guidelines 21.9 Summary Chapter 22 FUNCTIONAL TEAMS 22.1 Why Functional Teams Are Needed 22.2 The Functional-Team Strategy 22.3 Preparing for a Functional-Team Launch 22.4 Goal Setting 22.5 Launching Functional Teams 22.6 Coaching a Functional-Team Launch 22.7 Coaching a Functional Team 22.8 Summary Chapter 23 MULTIPLE TEAMS 23.1 What Is a Multi-Team? 23.2 The TSP Multi-Team Strategy 23.3 Forming a Multi-Team 23.4 The TSPm Launch Preparation Process 23.5 Launching a Multi-Team 23.6 Coaching a Multi-Team Launch 23.7 Launching a Distributed Multi-Team 23.8 Coaching Multi-Teams 23.9 Tracking and Reporting on Multi-Teams 23.10 Summary Chapter 24 INTEGRATED DEVELOPMENT TEAMS 24.1 Process Principles for Large-Scale Teams 24.2 The Program-Initiation Team 24.3 The Program-Management Problem 24.4 Program Launching and Coaching Strategies 24.5 The Role-Manager Teams 24.6 Program Monitoring and Reporting 24.7 Summary PART V: MAINTAINING A TSP TEAM Chapter 25 DEVELOPING TEAMWORK 25.1 Team-Member Communication 25.2 Principled Negotiation 25.3 The TSP Communication Strategy 25.4 Maintaining Team Communication 25.5 Process Discipline 25.6 Summary Chapter 26 COACHING ETHICS 26.1 The Coach’s Responsibilities 26.2 The Coaching Commitment 26.3 Handling Team and Individual Data 26.4 Measuring People 26.5 Relating to Management 26.6 Handling Difficult Team Members 26.7 Summary Chapter 27 THE COACHING TEAM 27.1 Coaching in Organizations 27.2 Why Use a Coaching Team? 27.3 Forming a Coaching Team 27.4 Launching a Coaching Team 27.5 Managing and Tracking Coaching Teams 27.6 Coaching a Coaching Team 27.7 Being on a Coaching Team 27.8 Summary Chapter 28 BEING A TEAM COACH 28.1 Building Understanding and Motivation 28.2 Building a Coaching Team 28.3 Success Is Invisible 28.4 Reporting to Management 28.5 Coaching Yourself 28.6 Summary Index A B C D E F G H I J K L M N O P Q R S T U V W Y Z Annotation Most modern software development projects require teams, and good teamwork largely determines a project's success. The Team Software Process (TSP), created by Watts S. Humphrey, is a set of engineering practices and team concepts that produce effective teams, thereby helping developers deliver high-quality products on time and within budget. TSP bridges Humphrey's seminal work on the Capability Maturity Model (CMM), an improvement framework for the entire software organization, and his Personal Software Process (PSP), practices designed to improve the work of individual developers. Typical first-time TSP teams increase productivity by more than 50 percent while greatly increasing the quality of their delivered products. However, TSP teams only continue to improve under the guidance of a capable coach. One industrial-strength team, for example, increased its productivity by an additional 94 percent and reduced test defects by 85 percent through three consecutive TSP quarterly product release cycles. Without competent coaching, teams often do not progress much beyond the initial one-time improvement seen after the introduction of the TSP. Humphrey distinguishes between TSP coaching and TSP leadership, explaining why the skillful performance of both functions is critical. In this practical guide, he shares coaching methods that have repeatedly inspired TSP teams and steered them toward success. With the help of a coach, TSP teams undergo a brief but intense project launch in which they define their own processes, make their own plans, and negotiate their commitments with management, resulting in dramatically enhanced performance. Whether you are considering the TSP or are actively implementing it, TSPSM--Coaching Development Teams provides the invaluable examples, guidelines, and suggestions you need to get started and keep developing as a team coach. It's meant to complement Humphrey's other books, TSPSM--Leading a Development Team and PSPSM: A Self-Improvement Process for Software Engineers. Together, the three works offer a rich resource for improving your software development capabilities. Most modern software development projects require teams, and good teamwork largely determines a projects success. The Team Software Process (TSP), created by Watts S. Humphrey, is a set of engineering practices and team concepts that produce effective teams, thereby helping developers deliver high-quality products on time and within budget. TSP bridges Humphreys seminal work on the Capability Maturity Model (CMM), an improvement framework for the entire software organization, and his Personal Software Process (PSP), practices designed to improve the work of individual developers. Typical first-time TSP teams increase productivity by more than 50 percent while greatly increasing the quality of their delivered products. However, TSP teams only continue to improve under the guidance of a capable coach. One industrial-strength team, for example, increased its productivity by an additional 94 percent and reduced test defects by 85 percent through three consecutive TSP quarterly product release cycles. Without competent coaching, teams often do not progress much beyond the initial one-time improvement seen after the introduction of the TSP. Humphrey distinguishes between TSP coaching and TSP leadership, explaining why the skillful performance of both functions is critical. In this practical guide, he shares coaching methods that have repeatedly inspired TSP teams and steered them toward success. With the help of a coach, TSP teams undergo a brief but intense project launch in which they define their own processes, make their own plans, and negotiate their commitments with management, resulting in dramatically enhanced performance. Whether you are considering the TSP or are actively implementing it, TSP SM Coaching Development Teams provides the invaluable examples, guidelines, and suggestions you need to get started and keep developing as a team coach. Its meant to complement Humphreys other books, TSP SM Leading a Development Team and PSP SM : A Self-Improvement Process for Software Engineers. Together, the three works offer a rich resource for improving your software development capabilities.