This book is for students and engineers who have already learned and,
preferably, applied the Personal Software Process (PSP)SM.
You may have learned the PSP in a graduate or senior-level course (1)
or in an earlier introductory course (2). Alternatively, you may be a
practicing engineer who seeks guidance on how to use the PSP in an industrial
team environment. In any case, when you have learned the PSP, you have
the background to use the methods and practices in this book.
After you have learned the PSP, you may need guidance on applying it
to the many tasks of the software process. This is the principal role
of the Team Software Process (TSP)SM:
to provide a framework for using sound engineering methods while developing
software.
There is a great deal to say about teamwork, and this book covers the
basic elements. TSPi (the introductory Team Software Process) introduces
team concepts and walks you through the steps of building teams and working
on a team. Note, however, that this text is designed for an introductory
course and does not cover all the material that you will need to use the
TSP for larger-scale industrial projects.
How TSPi Helps Engineers
This book teaches engineers about software development teamwork. TSPi
provides a structured set of steps, shows engineers what to do at each
step, and demonstrates how to connect these steps to produce a completed
product. TSPi also provides two interesting and reasonably challenging
project exercises. Each is at the same time small enough to be completed
in a few weeks and large enough to simulate a typical small project. When
capable engineers follow the guidance provided in this book, they will
invariably produce a finished working product.
In the suggested TSPi strategy, teams develop a product in two or three
cycles. In the first cycle, teams build a small working product kernel.
With each succeeding cycle function is added to this base. This strategy
demonstrates the benefits of using data from a prior project to plan a
new project. Also, by taking new roles for each cycle, engineers will
have two or three quite different experiences in just one project. After
several development cycles, engineers will have had a broad exposure to
teaming methods, and they are likely to continue using the TSPi methods
on their own.
Why TSPi Courses Are Needed
Because project courses have proven to be effective in preparing students
for software engineering careers, a growing number of universities now
offer them. These courses are often oversubscribed. Students seek material
that applies to their future jobs, and they see team courses as meeting
this need. After graduation, students and employers report that software
project courses are useful preparation for work in industry.
There is now a large body of experience with team project courses (3).
Although many of these courses have been successful, three problems are
common. First, the students often attempt projects that are too large.
Second, they frequently concentrate on the product and ignore the process.
Finally, one or more team members are disruptive. Although TSPi cannot
prevent all these problems, it provides guidance on how to avoid or mitigate
them.
To make effective use of curriculum time, team software courses should
be carefully structured and based on proven project experience. Without
a defined process or a structured team framework, engineers must figure
out for themselves how to run their projects. Without this process and
structure, these groups must learn team-building and teamwork basics through
an often painful trial-and-error process. This is both expensive and unnecessary
because teamwork principles are well known and straightforward.
TSPi guides engineers in effective teamwork methods. It does this by
walking them through a team-building process and then using a measured
and defined framework for developing products. Assuming that the engineers
are PSP-trained, they can follow the TSPi scripts and use the TSPi support
tool to plan and manage their work.4 Following TSPi makes engineers' projects
much more efficient and permits them to concentrate on learning about
software engineering rather than spend an excessive amount of time on
team-building and team management issues.
TSPi provides defined team roles that are allocated among the team members.
Each role specifies what is expected and when and how each task is to
be done. When all team members know what they and everyone else should
do, they are in a better position to work effectively as a team. If a
team member does not do his or her job, the other team members will know
it, and they can deal with the problem. When teams cannot solve interpersonal
problems themselves, they are told to call on their instructor or manager
for help. The Instructor's Guide for this book suggests methods for handling
many common teamwork issues. When student team members have explicit roles
and the role responsibilities are clearly defined and visible, instructors
can provide fairer and more specific grades. Each student can then be
rated on individual performance as well as on the overall team's results.
Not only does this approach motivate better performance, but it is also
a fairer way to grade team courses.
The Organization of This Book
This book is designed to lead teams through the TSPi process. Following
the first two introductory chapters (Part I), the chapters in Part
II walk teams through a complete development cycle. The text explains
the process scripts and gives examples of the completed TSPi forms. Part
III provides detailed descriptions of the TSPi team-member roles:
team leader, development manager, planning manager, quality/process manager,
and support manager. After reading the chapter on your personal role,
you can use these TSPi role scripts for reference while working on the
project.
At the start of the TSPi course, each student completes an INFO form
(see Appendix F) describing his or her interests and background.
The instructor uses this information to divide the class into five-engineer
teams and to assign initial roles to the team members. If one or two teams
have four or six members, the instructor must make some role adjustments.
All the roles must be assigned, and each engineer should have at least
one role. For a four-engineer team, the support manager role should be
distributed among the team members. For a six-engineer team, the quality/process
manager role should be split into two: the quality manager and the process
manager.
With the teams selected and roles assigned, the teams start their projects
and report on their progress. At the end of each development cycle, the
engineers assess the team's overall performance as well as that of each
individual role. With this information, the instructor can evaluate the
work and better assign team-member roles for the next development cycle.
If necessary, the instructor may make some team membership changes, but,
unless there are serious problems, teams should be kept together throughout
the course.
Using Standard, Predefined Problems
Although TSPi will work for almost any project, this book provides two
standard, predefined problems that are designed to meet the needs of a
wide variety of courses. Although there could be advantages to using actual
customer problems, this practice is not recommended for three reasons.
First, courses have firm and unvarying schedules. Although most customers
will initially agree to a fixed time scale, few customers know how long
it really takes to develop software. Also, because beginning engineers
do not generally know how to manage projects on firm schedules, the chances
of project failure are high. This problem is compounded by the fact that
actual customer requirements are notoriously vague and unstable, leading
to frequent changes and extensive delays.
The second reason to use a standard, predefined exercise is that a teamwork
course should be designed to teach specific lessons. Although one goal
of the project should be to build a working product, the principal course
objective should be to demonstrate the benefits of using proven software
engineering methods. With an actual customer problem, the first priority
must be to satisfy the customer. As the requirements change or the customer
takes time to answer questions, the work will slip. As the schedule gets
compressed, teams often concentrate on finishing the product and ignore
the process. Unfortunately, the principal lesson often learned from such
courses is how not to develop software.
The third reason to use a standard, predefined problem is that it permits
each team to compare its performance with that of other teams. With several
implementations of the same problem, all the teams can participate in
the class evaluations. Each team can describe its approach and answer
questions about its design, implementation, and test choices. This process
graphically shows the effectiveness of various development approaches
and provides a body of reference data for evaluating future teams.
Although there are advantages to using standard predefined exercises,
they do not expose students to some important issues. For example, without
actual experience, it is hard to appreciate the confusion and imprecision
of customer need statements. Struggling with vague and changing requirements
is an important experience, but it can be taught best in a course that
concentrates on the requirements process. The approach recommended here
is to first teach effective teamwork and process methods and then, in
later courses, focus on the complex issues of larger-scale development
projects.
|
