序
读此书之前建议先了解PSP（Personal Software Process），在PSP当中可以学到一个工程师如何能够成为工业化的开发团队中一员，只有这样你才具备了应用本书中所提供的方法和原则的基础。当你掌握了PSP之后，你所需要的是将你掌握的知识运用到整个软件过程的各个阶段当中去。这就是TSP最主要的任务，他为软件开发过程提供了一个充分使用工程学方法的框架基础。这本书会花大量的部分来讲解这个框架基础，和它所包含的元素。TSPi为你讲解团队的概念，并且带领你漫步在一系列构建团队和在团队的工作过程中。
【TSPi并不像我们通常所接触的说教式课程，实际上是一种训练课程。注重通过实践来积累和理解软件工程学方法的运用，一下的内容就说明了这一点。这也是在翻译过程中没有略过序直接翻译章节当中内容的原因】
•TSPi怎么帮助工程师们
这本书为工程师们讲解了关于软件开发的协作工作。TSPi通过构建一系列步骤，展示给工程师们应该如果去做每一步，并示范如何连接每一个步骤从而创造一个完整的产品。TSPi同时提供了两个有趣并具有合理化挑战性的项目来作为练习。其中小的项目足够几周内完成，大的项目可以媲美于一个真实的项目。按照本书中提供的指导，最终将完成一个工作产品。
在TSPi的策略中，建议把团队开发一个产品过程分为两到三个周期。在第一个周期当中创建一个小的工作产品的核心。以后每个成功的周期当中的功能将被添加到这个里面。这种策略示范了使用上一个项目的数据来制定新项目计划的好处。同时通过在每个周期当中接受新的角色，工程师们将在一个项目中有两到三个完全不同类型的经验。在几个开发周期以后，工程师们将对团队的开发方法有一个广泛的接触，这样他们将会愿意在他们自己的项目中继续的使用TSPi的方法。
•为什么TSPi课程是必须的
现在越来越多的大学【当然是指美国的大学，以前看见介绍Borland的核心开发团队，通常只有十几个工程师。就足以开发出像Delphi那样的产品，而我们几十人的团队都“无所事事”时而感到惊叹。我们就应该知道教育方法的重要性】为即将步入软件工程师生涯的学生提供项目相关的课程，并且被证明对他们以后的工作产生了很大的影响。在很多成功的项目实践课程中，有三点问题非常突出：第一很多学生总是试图尝试那些规模更大的项目，再次他们总是热衷于关注产品本身而忽略过程【忽略过程，这也是我们很多团队中的工程师所经常犯错误，只注重结果本身。不仅会给他们的自身发展带来很大的障碍，而且一旦这些人将来成为了团队的管理者以后，对团队的管理水平的提升和项目管理本身带来的危害都是巨大的。严重点说：个人觉得这是项目管理中一切问题的根源】，第三总有一个甚至更多组员被忽视。尽管TSPi也不能阻止全部的那些问题，但是它提供了避免和降低这些问题出现的指导原则。
为了更有效的使用课程时间，团队软件开发课程应该在被验证的项目的基础上仔细的构建。如果没有一个被定义的过程或者结构化团队架构，工程师们就必须靠自己来找出开展项目的方法。没有这样的过程和框架，一个组织也必须在尝试-失败的过程来学会团队建设和开展团队工作。这样付出的代价既昂贵有没有必要。因为开展团队工作的原则是众所周知和简单明了。
TSPi利用有效的团队工作的方法通过带领他们进行一个项目构建的过程和使用可量化以及被定义过程来开发一个软件产品来指导工程师们。假如工程师通过了PSP的培训,他们能够按照TSPi的描述和使用TSPi提供的工具去计划和管理他们的工作。接下来TSPi能让他们的项目更高效和允许他们专著于学习软件工程学而不是花费过多的时间在团队建设和团队的管理问题。
TSPi提供分配到团队成员的被定义的团队角色。每一个角色被规定什么是被期待的，什么时候以及如何完成每项任务。当所有的团队成员清楚他们自己以及别人应该做什么以后，他们就能在一个合理位置成为一个团队进行高效的工作。如果任意一个成员没能完成自己的工作，其他人就会知道，并且处理这个问题。当团队自己不能在内部够解决问题，他们会被告知向导师和经理去寻求帮助。导师会按照本书提供的方法来处理所有团队工作的共同问题。【本人在自己的团队中一直反复强调这样一种观点，组织的存在并不是要管理谁，每个人都应该管理好自己。组织的存在是发现“问题”，也就是谁需要帮助，我们的工程师甚至包括我们的客户，当我们面临着很严峻的Schedule和从上流（比如需求，设计等等）遗留有问题的时候，怎么样通过合理的管理流程和方法，来使工作的进行合理化，减轻我们工程师的压力。】
当团队成员的职责和角色被清晰并明确的定义后，导师能提供更直接并且详细的等级，每个成员的评定依据于个人的表现和在团队中为达到团队结果的表现。这不仅能促进一个更好的绩效，也是个比较公平的方式来给团队和成员评级。
•应用标准的预定义问题
尽管TSPi适用于大多数的项目，这本书提供了两个标准的预定义问题使之能够满足各种变化需求的课程。尽管使用实际客户的问题更有利，但是有三个原因使之不被推荐。第一，课程有固定不变的日程。尽管大多数客户在初期认同一个固定的时间范围，但几乎没有客户知道开发一个软件真正需要多长时间。并且，对于连固定日程的项目都不能真正的知道如何来管理的初学者而言，那样项目的失败几率会很高。
第二个原因是作为一个标准，预定义练习是一个团队课程应被设计成一个明确的课程。尽管一个项目的目标应该建立一个工作产品，我们主要的课程目标应该示范使用软件工程学的好处。作为一个实际的客户问题，应优先满足客户。作为需求变更或者客户花时间来回答问题，这样的工作将节外生枝。一旦这个日程被压缩，团队就不得不急于完成任务而忽略了整个过程。不幸的是，从这个课程中往往得到了教训而不是如何来开发软件。
第三个原因是使用一个标准的预定义问题是允许每一个团队与其他团队比较他们的成绩。同样的问题有不同的执行方法，所有的团队能够分享课程的结果。每一个团队能叙述他们的分析并回答那些设计，执行和测试的问题。这个过程详尽的展示了不同开发步骤的效果和提供了大量的参考数据给未来项目的评估。
尽管以上那些是使用一个标准预定义练习的好处，但是他们不能向学生们揭示那些重要的观点。例如，没有实际的经验，很难懂得客户需求中的不准确性和困惑。与变换的和不明确的需求做斗争是很重要的一个经验，这些能教会你专注于这个需求过程。这个方法在这里被推荐的原因是想首先教会大家一个团队工作和过程管理的方法，然后在后续的课程中，会关注于大规模软件开发中复杂的问题。
－－－原创转载需注明
