本节书摘来自异步社区《团队软件过程（修订版）》一书中的第1章1.3节TSPi的设计，作者【美】 Watts S. Humphrey（沃茨·S. 汉弗莱），更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.3 TSPi的设计

团队软件过程（修订版）设计一个过程有很多方式，TSPi的设计思想主要体现在以下7个方面。

（1）在个体软件过程（PSP）的基础上提供一个简单的团队培训框架。

（2）在几个周期内开发产品。

（3）建立标准的质量和绩效度量。

（4）为团队和学生提供精确度量。

（5）进行角色和团队评估。

（6）需要过程规范。

（7）提供团队问题的指导。

接下来，依次讨论每个话题。

1.3.1 在个体软件过程（PSP）的基础上提供一个简单的框架

过程的目的是帮助你完成任务，例如开发产品或学习如何执行团队项目。如果过程太复杂，就要花费过多时间弄清楚要做什么，会使你很容易忘记真正的目标。另一方面，如果过程太简单，就不能提供足够的指导信息。这样一来，你就必须在工作中自己建立过程，而这又会导致时间的浪费，重大错误的出现，甚至整个项目的失败。

虽然TSPi有很多表格和脚本，但是其中的大多数都与你曾在PSP中使用过的相似。因此，如果你接受过PSP培训，虽然仍然要学习整个TSPi方法，但是你已经理解了TSPi的“语言”。如果你没有接受过PSP培训，TSPi过程会显得太过庞大。这就是TSPi课程要求PSP作为先修课的原因。

即使已经接受过PSP培训，你还是要学习大量的新任务和新活动。然而，基于角色划分，TSPi允许你把精力集中在你个人需要学习的基本要素上。TSPi角色明确了计划、跟踪、质量、支持以及领导等任务分别由谁来完成。这些角色还减少了一开始你要掌握的资料数量。你可以集中精力完成特定角色的具体任务，而不必考虑其他角色的职责，至少在现阶段是这样的。

在一个多周期的TSPi项目中，尽量多尝试几个不同的团队角色。这能让你更广泛地接触TSPi过程，让你对团队软件开发的更多内容有更深入的理解。另外，这还能帮你更好地认识自己的兴趣和能力。

1.3.2 在几个周期内开发产品

在一个完整的TSPi课程中，你会在一个学期内完成两个或三个开发周期。每个开发周期都涵盖了完整的需求、设计、实现和测试过程。在第一个周期中，你会开发一个包含最终产品核心功能的产品内核。如果能让这个产品内核运行起来，就可以确保在课程结束时得到一个工作产品。同时，后续的开发周期也有了坚实的基础。这种策略更有可能在项目早期就发现设计、性能、可用性等方面的问题，从而相对轻松地解决这些问题。

第二个周期建立在第一个周期的基础上。你可能会更换团队角色，调整过程，或者使用更加规范的质量控制方法。在第二个周期结束时，你将得到两个完整项目的数据。如果时间允许，你就能第三次甚至第四次重复这些周期。经过两个以上的周期之后，你就会发现自己在开发方面已经像个老手了。基于清晰和有力的证据，你就能知道在你的团队中什么方法最有效，同时，你也建立了继续在工作中使用这些方法的信心。

1.3.3 建立标准的质量和绩效度量

度量是持续的高质量工作的重要组成部分。PSP提供了基本的度量和度量方法，你可以用来度量和评估工作的质量。但是，在你真正在项目中使用这些度量之前，你很难认识到它们的价值。TSPi告诉你该如何理解PSP度量，该如何在项目中使用它们。

TSPi要求你和你的团队除了建立团队目标，也要建立个人目标。虽然这项工作看起来可能并不重要，但是工程教育的一个核心部分就是学习建立富有挑战性的可达目标。TSPi对目标和度量的强调，会帮你认识质量度量、项目计划与跟踪等工作的价值。合理有效的计划和跟踪还能帮你管理日常工作。

1.3.4 为团队和学生提供精确的度量

有了TSPi度量，你和你的团队的表现会一目了然。尽管每个人都知道努力做好工作的重要性，一些成员的贡献还是不能达到分配给他们的任务要求，这是团队工作的常见问题。

虽然TSPi度量的主要目的是帮你更好地工作，但这些度量也同时让你的个人表现清晰地呈现在整个小组面前。然而，这正是团队协作的本质：每个人都知道其他人在做什么。也就是说，如果你工作不努力，你可以想象团队中的其他人对你的评价会是什么。

1.3.5 进行角色和团队评价

有些工作组喜欢互评这种方式，有些则不喜欢。TSPi提供了一种互评机制，指导教师可以根据实际情况有选择地使用。互评的优势在于，学生自己最清楚团队和每个人的表现。如果他们能给出诚实的评价，指导教师就更能了解实际情况，就更有可能给出公平合理的成绩。

因为学生一般都不愿意评价同学，所以TSPi选择了团队和角色评估。主要思路是评估每个角色表现如何，而不是评价个人行为如何。虽然角色评估可能被解读为对担当该角色的个人的评价，但是，TSPi强调的是评估过程执行得怎样，而不是评价个人表现得怎样。

1.3.6 需要过程规范

软件工程师很难持续地进行有规范的个人工作。有以下3个主要原因。

（1）软件工程没有规范个人表现的传统。因此，学生和现实工作中的工程师都没有模范可以仿效。

（2）软件过程没有对工程师的自然约束。软件开发与硬件工程不同，硬件设计工程师要把设计方案交给工厂进行规模化生产，硬件生产工程师必须首先审核并接受设计方案，然后才能以一定的进度、成本和生产率来制造产品。对于软件来说，我们没有工厂，没有生产工程师，因此，软件工程师必须自己约束自己。

（3）在任何领域中持续地进行规范的工作都需要很高的标准和足够的支持。这也是为什么在体育运动和艺术表演领域需要教练、训练师、指挥和导演的原因。在工业领域，一些有经验的经理人已经学会了如何担当教练的角色；在大学课程中，指导教师要扮演团队教练的角色。不幸的是，很少有人知道如何做一个成功的教练，这种教练方式也还没有在软件领域广泛实施。

在TSPi课程中，指导教师会要求学生遵循过程并收集数据。学生必须填写表格，还要分析和使用数据。如果不做这些，就不能得到TSPi课程的全部好处。

1.3.7 提供团队问题的指导

即使在运转良好的项目中，团队协作问题也普遍存在。你和你的团队有不同的角色，每个角色有自己的目标，当这些目标冲突时，就可能出现意见不一致的情况。事实上，如果你跟你的团队没有任何分歧，一定会让大家惊讶。不要把这些看作个性问题，除非冲突已经严重到无法解决的程度。一般来说，团队协作问题都是由过程问题导致的。

有时，学生会有与团队工作的问题。这不仅是因为他们缺乏经验，还因为他们的知识背景和个人性格不适应团队工作的要求。然而，经过适当的指导和帮助，大多数工程师都能成为优秀的团队成员。解决团队问题最根本的力量来自于同事之间的压力。多数人都很在意同事的看法，渴望融入团队并获得尊重。只要有足够的时间并获得适当的训练，大多数聪明且上进的工程师都能学会如何做一个优秀的团队成员。

如果团队成员不能有效地一起工作，向指导教师寻求帮助。与团队配合，指导教师通常都能帮他们克服这些问题。如果问题还是得不到解决，就有必要对团队的人员组成做出适当调整，比如从团队中调出有问题的成员。虽然这是个敏感的工作，但是一般来说，只要团队的其他成员都要求指导教师这样做，也不会出什么大问题。第11、16和17章对此有更详细的介绍。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。