Carnegie Mellon Software Engineering Institute - Team Software Process (TSP) Body of Knowledge (BOK)
“The Team Software Process Body of Knowledge (TSP BOK) was drafted to define the fundamental knowledge and skills that set TSP-trained individuals apart from other software professionals. It helps individual practitioners to assess and improve their own skills, provides employers with an objective baseline for assessing the process improvement skills and capabilities of their development team members, and guides academic institutions that want to incorporate TSP into their software and other engineering courses or curricula. The TSP BOK also facilitates the development of TSP certification programs that are based on a well-established standard set of knowledge and skills.” [GD: Description leached in full]
From the PDF;
“…
The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange.
This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. …” [GD: Our tax dollars at work ;]
I’m not really sure we need another software development TLA or certification program, but I also know the software development process it still very chaotic and entirely too much re-inventing of the process wheel is still going on (for a very simple example, how many businesses still make up as they go their own dev position descriptions…? like all of them?).
What struck me about this document was that it seemed that the entire team was addressed, from leadership to end-users/stakeholders. It also seemed pretty “real world” with discussion of team dynamics, administration stuff like weekly meetings, checkpoints, coaching, etc. I also liked, “…It helps individual practitioners to assess and improve their own skills…” I feel that the only person responsible for improving your skills is you, so this personal responsibility message struck a cord with me.
In short this doesn’t seem to be just blue sky/perfect world/lost in academia stuff…
Added to me “Should Read This Soon” pile.
Here’s some snips and content from the PDF;
Here’s an dump of the ToC so
Table of Contents i
List of Figures v
Acknowledgments vii
Executive Summary ix
Abstract xi
1 Introduction 1
1.1 Purpose for the TSP BOK 2
1.2 Sources and Influences 3
1.3 Document Organization 3
2 TSP BOK Structure and Terminology 5
2.1 Structure of the BOK 5
2.2 Operational Definition of Terms 5
3 The TSP Body of Knowledge 7
Competency Area 1: TSP Foundations and Fundamentals 9
Knowledge Area 1.1: Knowledge Work 9
Knowledge Area 1.2: TSP Prerequisite Knowledge 12
Knowledge Area 1.3: TSP Principles 14
Knowledge Area 1.4: TSP Process Elements and Measures 15
Knowledge Area 1.5: TSP Quality Practices 17
Competency Area 2: Team Foundations 19
Knowledge Area 2.1: Teams and Teambuilding 19
Knowledge Area 2.2: Team Types, Styles, and Dynamics 22
Knowledge Area 2.3: Team Formation and Membership 26
Knowledge Area 2.4: Team Member Responsibilities 28
Knowledge Area 2.5: Team Member Roles 29
Knowledge Area 2.6: Team Leader Role 34
Knowledge Area 2.7: Coach Role 37
Competency Area 3: Project Planning with TSP 41
Knowledge Area 3.1: Change Management Fundamentals 41
Knowledge Area 3.2: Piloting TSP in an Organization 45
Knowledge Area 3.3: Preparing Management and Teams for TSP Implementation 48
Knowledge Area 3.4: The TSP Launch Meetings 51
Knowledge Area 3.5: The TSP Relaunch 57
Competency Area 4: Project Implementation and Tracking with TSP 61
Knowledge Area 4.1: Weekly Meetings 62
Knowledge Area 4.2: Checkpoints 64
Knowledge Area 4.3: Communicating with Stakeholders 65
Knowledge Area 4.4: Replanning 67
Knowledge Area 4.5: Phase, Cycle, and Project Postmortems 70
Competency Area 5: Gathering and Using TSP Data 72
Knowledge Area 5.1: Data Recording 73
Knowledge Area 5.2: Gathering and Using Size Data 73
Knowledge Area 5.3: Gathering and Using Schedule Data 75
Knowledge Area 5.4: Gathering and Using Quality Data 75
Knowledge Area 5.5: Gathering and Analyzing Postmortem Data 79
Competency Area 6: Scaling Up the TSP 82
Knowledge Area 6.1: Organizational Implementation 82
Knowledge Area 6.2: TSP Process Variations 84
Knowledge Area 6.3: Large-scale TSP Teams 90
Appendix A: Engineering Guidelines 92
A1 Principles of Modern Engineering Work 92
Appendix B: Project Management Guidelines 94
B1 Operational Processes for Project Management 94
B2 Project Management Using TSP 94
B3 Managing TSP Plans 96
B4 Managing Team Communication 97
B5 Managing Team Project Focus 97
B6 Managing Team Roles 98
Appendix C: TSP Coaching Guidelines 104
C1 The TSP Coach Role 104
C2 Guidelines for Introducing TSP into an Organization 105
C3 Guidelines for Launching Teams 107
C4 Guidelines for Coaching Teams 109
C5 Guidelines for Coaching Role Managers 111
C6 Guidelines for Assessing Team Characteristics 112
C7 Guidelines for Coaching Plan Management Issues 114
C8 Guidelines for Coaching Data Management Issues 116
C9 Guidelines for Data Analyses 118
C10 Guidelines for Coaching the Team’s Quality Management 120
C11 Guidelines for Coaching the Team’s Schedule Tracking 120
C12 Guidelines for Coaching the Postmortem 122
C13 Guidelines for Coaching TSP Multi-teams (TSPm) 122
C14 Guidelines for Coaching Other TSP Team Types 124
Appendix D: TSP Team Leader Guidelines 126
D1 The Team Leader Role 126
D2 Team Leader Guidelines for Plan Management 127
D3 Team Leader Guidelines for Quality Management 128
D4 Developing the Team 128
D5 Protecting the Team 129
D6 Working with the TSP Coach 129
Acronyms Used 131
References 132
The Executive Summary;
“… As the character of engineering technology has changed in the post-industrial revolution, an increasing proportion of engineered products are actually components of entire systems of products that directly support end-use applications such as driving, flying, or medical diagnoses and treatments. These products and systems must meet critical performance, safety, security, survivability, and usability requirements. Not only must these modern engineering products be of the highest possible quality, but they also must meet business-critical schedule and budget constraints.
Modern engineering work requires teams for work products that are too large or too complex to be completed by a single engineer. Furthermore, the modern engineering workforce must work in close cooperation with people who have the variety of domain skills required for the system’s design and implementation. This requires a work environment in which people with vastly different skills can work together to produce quality products that meet their functional, architectural, and property requirements. The Personal Software ProcessSM (PSPSM) and Team Software ProcessSM (TSPSM) technologies provide such an environment by proving individuals and teams with a framework for creating or tailoring processes that all members can follow, for communicating in a common vocabulary, and for planning and tracking their work using a commonly accepted set of measurements and standards.
The Team Software Process Body of Knowledge (TSP BOK) was drafted to define the fundamental knowledge and skills that set TSP-trained individuals apart from other software professionals. It helps individual practitioners to assess and improve their own skills, provides employers with an objective baseline for assessing the process improvement skills and capabilities of their development team members, and guides academic institutions that want to incorporate TSP into their software and other engineering courses or curricula. The TSP BOK also facilitates the development of TSP certification programs that are based on a well-established standard set of knowledge and skills.
The TSP BOK is intended to provide a high-level comprehensive overview of the competencies that compose the essential knowledge and skills required for the competent implementation of the TSP as a team member, team leader, coach, or manager of a TSP team. This document is not meant to provide detailed descriptions or in-depth explanations of the concepts, practices, and procedures of every component in the TSP. Rather, the purpose of this document is to provide an overview of the competencies, knowledge areas, and key concepts and skills that constitute the essential knowledge, skills, and abilities of competent TSP practitioners.
…”
(via Architects Rule! - Team Software Process (TSP) Body of Knowledge (BOK))
No comments:
Post a Comment
NOTE: Anonymous Commenting has been turned off for a while... The comment spammers are just killing me...
ALL comments are moderated. I will review every comment before it will appear on the blog.
Your comment WILL NOT APPEAR UNTIL I approve it. This may take some hours...
I reserve, and will use, the right to not approve ANY comment for ANY reason. I will not usually, but if it's off topic, spam (or even close to spam-like), inflammatory, mean, etc, etc, well... then...
Please see my comment policy for more information if you are interested.
Thanks,
Greg
PS. I am proactively moderating comments. Your comment WILL NOT APPEAR UNTIL I approve it. This may take some hours...